Ich habe kürzlich diesen Artikel über ein gutes Verhältnis zwischen Entwicklern und Personen der Softwarequalitätssicherung gelesen und frage mich, ob es ein ähnliches Konzept für Entwickler / Nicht-Entwickler in einem SCRUM-Team gibt.
Dies liegt daran, dass aktuelle und frühere Arbeitskontexte für mich sehr unterschiedlich sind:
alter Kontext - SCRUM-Team aus 5-6 Entwicklern, ein Tester (Testfälle, einige manuelle Tests), ein technischer Leiter (sehr technisch, verbrachte die meiste Zeit mit dem Schreiben von Code, erheblicher Anteil während hauptsächlich technischer Besprechungen), der PO, einer Personalmanager, der insgesamt drei SCRUM-Teams leitet, ein Bruchteil eines SCRUM-Masters. People Manager ist typisch „ehemals technisch“, schreibt aber keinen Code in dieser Rolle
Aktueller Kontext - SCRUM-Team aus 2-3 Entwicklern, 1/2 Tester (dh auch in einem anderen Projekt involviert), ein "Teamleiter", der die Aufgaben des Personalmanagers übernehmen und einen erheblichen Teil damit verbringen sollte, Geschichten anzugehen (dh Code zu schreiben), die PO . Der Teamleiter ist in der Regel an so vielen Besprechungen (sowohl technischen als auch nicht-technischen) beteiligt, dass er weniger als 10 % seiner Zeit mit dem Schreiben von Code verbringt
Nachdem ich mehr als ein Jahr in jedem Setup gearbeitet habe, habe ich das Gefühl, dass der erste Kontext, der ein geringeres Verhältnis von Nicht-Entwicklern zu Entwicklern aufweist, wesentlich effizienter ist.
Eine weitere Quelle der Ineffizienz für den zweiten Text könnte damit zusammenhängen, dass dieselbe Person sowohl im „unterbrochenen Modus“ (Meetings, Diskussionen usw.) als auch im „fokussierten Modus“ (kontinuierliche Zeit, die einer einzelnen Aktivität wie Codierung zugewiesen wird) arbeitet. , aber das liegt außerhalb des aktuellen Fragenfokus.
Gibt es Empfehlungen zum Verhältnis zwischen Entwicklern und Nicht-Entwicklern in einem SCRUM-Team?
Es gibt viele Faktoren, die das Verhältnis von Entwicklern zu Nicht-Entwicklern beeinflussen, darunter:
Es gibt nicht nur viele Faktoren, die das Verhältnis beeinflussen, sondern das ideale Verhältnis kann sich im Laufe der Zeit ändern und sogar abhängig von der Arbeit, die das Team gerade leistet.
Ein guter Ansatz für ein Team besteht darin, zu überwachen, wie gut das aktuelle Verhältnis funktioniert. Wie hoch ist beispielsweise die Rate der entgangenen Fehler? Wie ist die Gesamtqualität der Codebasis? Auf der Grundlage dieses Feedbacks kann das Team entscheiden, ob es seine Zusammensetzung ändern oder Wissensaustausch oder Schulungen anbieten muss, um mehr übergreifende Fähigkeiten zu ermöglichen.
Das einzige Verhältnis, das Sie finden werden, ist 1 Product Owner und 1 Scrum Master pro Entwicklungsteam.
Jeder in einem Scrum-Team (außer PO und SM) sollte danach streben, ein Entwickler zu sein.
Ein Entwickler kann jedoch mehrere verschiedene Aufgaben haben. Einige werden eher technisch orientiert sein und so bei der Definition der Architektur helfen. Einige werden mehr menschenorientiert sein und die Last übernehmen, das Team bei Diskussionen mit anderen Kollegen zu vertreten. Einige werden sich mehr darauf konzentrieren, sicherzustellen, dass die Qualität der Software gut ist.
Aber alle sind Entwickler.
Wenn Sie eine QA in Ihrem Team haben, die keine Codierung durchführt, hat Ihr Team möglicherweise nicht die erforderlichen Fähigkeiten entwickelt, um die Qualität der Ergebnisse sicherzustellen.
Das ideale Verhältnis ist dasjenige, das es dem Team am besten ermöglicht, ein Produktinkrement am Ende des Sprints erfolgreich zu liefern.
Der Scrum Guide unterscheidet nicht zwischen Entwicklertypen, sondern verlangt lediglich, dass das Team über alle erforderlichen Fähigkeiten verfügt, um die Arbeit zu erledigen. Die spezifische Mischung hängt davon ab, was Ihr Produkt ist, und wird sich wahrscheinlich im Laufe der Zeit ändern, und die Änderung könnte beinhalten, dass Leute in das Team ein- und aussteigen, oder es könnte Leute beinhalten, die im Team bleiben, aber andere Teile der Arbeit erledigen - Beispielsweise könnten die Personen, die hauptsächlich Tests durchführen, an der Codierung beteiligt sein, oder jemand, der Codierung durchgeführt hat, könnte bei der Geschäftsanalyse helfen, um Benutzeranforderungen zu ermitteln.
Darauf kann das Scrum-Team bei der Retrospektive eingehen – dazu müssen lediglich drei Fragen gestellt werden:
Einige Arten von Produkten und Technologie-Stacks eignen sich für die testgetriebene Entwicklung – in diesem Fall können einige QA-Ingenieure einen großen Beitrag leisten. Andere Produkte erfordern möglicherweise manuelles Testen – beispielsweise erfordert Software, die auf benutzerdefinierter Hardware ausgeführt wird, vollständige Systemtests durch manuelle Tester – und in diesen Fällen benötigen Sie ein gesundes Gleichgewicht zwischen Entwicklern und Qualitätssicherungsingenieuren.
Wenn das Team über 10 Personen hinauswächst und wirklich anfängt, Produktveröffentlichungen herauszubringen, werden Qualität und Zuverlässigkeit wichtig, da das Fehlen dieser Dinge zu einem Reputationsrisiko und einer Erosion des Vertrauens der Kunden führt.
Bogdan
Bart van Ingen-Schenau