Ich habe ein Team von 4 Entwicklern und 1 QA. Mein Workflow in Jira ist:
Backlog -> Analyse -> In Entwicklung -> QA bereit -> QA abgeschlossen -> Fertig
Bei jedem Sprint (1 Woche) gelangen alle Probleme in die QA-Ready-Phase (QA-Mitglied beendet das Testen aller Funktionen in einer Iteration nicht), außerdem werden Probleme nicht verbrannt, bis sie die Done-Phase (Bereitstellung) erreichen. Ich messe also nicht die effektive Teamarbeit pro Sprint.
Ist es (für eine Geschichte) empfehlenswert, ein Problem für Entwickler und ein anderes Problem für QAs zu melden, sodass ich in einem Sprint nur die Probleme einbeziehen kann, die "erledigt" werden?
Dazu muss ich meinen Workflow ändern auf:
To do -> In Bearbeitung -> Erledigt
Auf diese Weise haben Analyseprobleme, Entwicklungsprobleme und QA-Probleme eine kürzere Lebensdauer, aber sie werden verbrannt und pro Iteration gemessen.
Ich mag diese Lösung nicht, weil es dreimal mehr Probleme geben wird.
Die Sache ist, dass das Burndown-Diagramm nicht zeigt, woran das Team arbeitet, selbst wenn ich definiert habe, dass eine Lösung festgelegt wird, wenn das Problem die QA-Bereitschaftsphase erreicht.
Aber Sie messen die effektive Arbeit pro Sprint ganz gut. Wenn das Team Entwicklungsarbeit liefert, aber keine QA für ein paar Storys, zusammen mit einigen Analysen, aber sonst nichts, dann ist die effektive Arbeit für Ihr Team für diesen Sprint gleich null.
Weil nichts Wertvolles an den Kunden geliefert wurde, und das ist der Wert eines Sprints. Nicht die "Story Points", nicht die Menge an Code, nicht die Anzahl an Ideen oder Skizzen, nicht die Anzahl an Entschuldigungen. Das einzige, was Sie messen sollten, ist die Anzahl der tatsächlichen, getesteten, verifizierten und funktionierenden Funktionen.
Der Versuch, Story Points für Dinge zu messen, die keinen Wert liefern, ist nur ein Spiel mit dem System. Alles, was Sie tun können, ist, das eigentliche Problem in Ihrem Workflow zu vermeiden, nämlich dass Dinge nicht erledigt werden. Agile zeigt Ihnen nur, wo die Probleme mit Ihrer Arbeitsweise liegen, es löst Ihre Probleme nicht. Es wieder unter den Teppich zu schieben, indem man Dinge misst, die niemanden interessieren (wie Story Points zu Dingen, die keinen Kundenwert liefern), wird Ihnen in keiner Weise helfen, besser zu werden.
Sie haben also kein Problem damit , die effektive Arbeit des Teams hier zu messen . Sie haben ein Problem, dass die effektive Arbeit sehr gering ist, weil die Brenndauer Ihrer Geschichten sehr hoch ist. Sie müssen versuchen, das zu beheben , wahrscheinlich indem Sie die Storys kleiner schneiden und das gesamte Team früher einbeziehen. Beziehen Sie Ihr Team mit ein und arbeiten Sie mit ihm zusammen, um Wege zu finden, die ganze Geschichte innerhalb einer Woche abzuschließen.
Die Tatsache, dass während eines Sprints nur eine kleine Anzahl von Stories abgeschlossen wird, zeigt eine Dysfunktion Ihres Prozesses und/oder Teams, aber es ist höchst fraglich, ob die Aufteilung der Stories in „Dev Stories“ und „QA Stories“ wirklich das Problem lösen wird Funktionsstörung.
Ziel eines Sprints ist Scrum, ein potenziell veröffentlichbares Produktinkrement zu liefern. Ein potenziell veröffentlichbares Produktinkrement ist eine verbesserte Version des Produkts, die aus Qualitätssicht bereit ist, live zu gehen, aber es kann geschäftliche Gründe geben, die Bereitstellung zu verzögern.
Wenn Sie feststellen, dass viele Storys im Status „QA abgeschlossen“ bleiben, weil sie aus geschäftlichen Gründen nicht bereitgestellt werden können, sollten Sie den Bereitstellungsschritt aus der Definition-of-Done herausnehmen (d. h. die Story wird einmal gebrannt es erreicht QA abgeschlossen).
Wenn Sie auch das Problem haben, dass das Testen nicht mit der Entwicklung Schritt halten kann, müssen Sie möglicherweise Ihre Entwicklungspraktiken überprüfen. Sie erwähnen, dass das Team aus 4 Entwicklern und 1 QA-Mitglied besteht, aber das gesamte Team sollte für die Fertigstellung der Geschichten verantwortlich sein. Wenn die QA-Phase ein Engpass für die Fertigstellung von Stories ist, sollten Sie mit dem Team besprechen, wie jeder mithelfen kann, um die Tests schneller abzuschließen, was bedeuten könnte, dass die Entwickler auch einige Testaktivitäten aufnehmen müssen.
Außerdem sollte das QA-Mitglied vom ersten Tag an in die Geschichten involviert sein, und nicht erst, wenn die Entwickler denken, dass die Implementierung abgeschlossen ist.
Zuallererst: Vermeiden Sie es, Aufgaben nach Teams aufzuteilen. Aufgrund meiner bisherigen Erfahrungen war es immer schmerzhaft, die Teile im Nachhinein zusammenzusetzen. Vermeiden Sie also den Drang, verschiedene Aufgaben zu erstellen.
Basierend auf Ihrem obigen Beispiel haben Sie zwei verschiedene Teams (Entwicklung und Test), die an demselben Ergebnis arbeiten.
Annahmen:
Schnellste Lösung:
Bessere Lösung:
John_C