Ist die Akzeptanz „mitten im Sprint“ ein gültiges Konzept in Agile/SCRUM?[geschlossen]
https://stackoverflow.com//questions/9638514
-
10-12-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich bin Teil eines Agile-Scrum-Teams, das an einer Softwareproduktversion arbeitet.Die Sprintdauer beträgt 2 Wochen (~10 Tage).
Hier wird eine besondere Metrik verwendet, die „Akzeptanz in der Mitte des Sprints'.Im Wesentlichen besteht die Erwartung darin, dass die Hälfte der von einem Scrum-Team in einem Sprint festgelegten und geplanten User-Story-Punkte bis zur Mitte dieses Sprints abgeschlossen sein müssen.Sie sagen, dass dies zu einem linearen Punkteabbau führt, was ein starker Indikator dafür ist, dass der Sprint gut verläuft.
Als Team sind unsere Annahmen in der Mitte des Sprints normalerweise schlecht, aber es ist bekannt, dass wir alle zugesagten User-Story-Punkte bis zum Ende des Sprints abschließen.
Ich habe folgende Fragen:
1) Ist die Akzeptanz in der Mitte des Sprints eine gültige Agile/SCRUM-Praxis?Wird es woanders verwendet?
2) Zu erwarten, dass die Hälfte der Arbeit in der Hälfte der Zeit erledigt wird, ist so, als würde man sie als „Fabrikarbeit“ behandeln, bei der die Art und Komplexität der anstehenden Arbeit völlig deterministisch ist.Da es sich bei der Softwareentwicklung um einen „kreativen“ Prozess handelt, sind solch starre Metriken in einer hochflexiblen Methodik wie Agile irrelevant.Was denken Sie?
3) Obwohl mein Scrum-Team alle unsere Verpflichtungen pünktlich zum Sprint erfüllt, werden wir wegen unserer schlechten Akzeptanzmetriken in der Mitte des Sprints befragt.Ist es in Scrum-Teams anderswo völlig normal, dass sie ihren Verpflichtungen erst gegen Ende ihrer Sprints nachkommen?
Vielen Dank im Voraus.
Lösung
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
Von der Mid-Sprint-Akzeptanz habe ich noch nie gehört.Ich glaube nicht, dass es sich um eine gültige Agile/Scrum-Praxis handelt. Diese Seite scheint zuzustimmen: „Sobald sich das Team zur Arbeit verpflichtet hat, kann der Product Owner keine weitere Arbeit hinzufügen, den Kurs mitten im Sprint ändern oder …“ Mikromanagement."
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
Aus den von Ihnen genannten Gründen sind starre Metriken im Allgemeinen keine gute Idee für Entwickler.Außerdem wird es für Entwickler wahrscheinlicher sein, dass sie mehr daran interessiert sind, bei den gemessenen Werten eine Mindestpunktzahl zu erreichen, und nicht an der Herstellung eines Qualitätsprodukts.Das ist einer von Joel Spolskys Käferbären – Hier, Hier Und Hier
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
Ein erfolgreiches Scrum-Team sollte bis zum Ende des Sprints alle seine Verpflichtungen erfüllen.Das Burndown-Diagramm sollte sichtbar sein, um den Fortschritt in Richtung dieses Ziels zu leiten und in der zweiten Hälfte des Sprints sicherlich Aufschluss darüber geben, ob der Sprint wahrscheinlich ein Erfolg wird.Bei erfolgreichen Sprints, an denen ich beteiligt war, ist es normal, stetige Fortschritte bei der Vervollständigung der User Stories zu machen, aber das lässt sich nicht dadurch widerspiegeln, dass die Hälfte der User Stories in der Hälfte der Zeit fertiggestellt wird, und ich würde von einer Metrik dieser Art abraten.
Andere Tipps
Haben Sie versucht, den Umfang Ihrer laufenden Arbeit zu begrenzen?Wenn Sie das gesamte Team dazu bringen, sich auf ein paar Geschichten zu konzentrieren und nicht weiterzumachen, bis diese Geschichten fertig sind, sollte Ihr Burndown viel linearer verlaufen.
Es könnte sich auch lohnen, einen Blick auf die Größe der Geschichten zu werfen.Ich persönlich mag es nicht, eine Geschichte zu sehen, deren Fertigstellung von Anfang bis Ende länger als ein paar Tage dauert.
Es handelt sich nicht um eine Scrum-Praxis.Es könnte als Metrik interpretiert werden, aber eine schlechte.Mit Ihren Zweifeln haben Sie Recht.
Scrum verfügt über ein perfektes Werkzeug, um den Fortschritt zu verfolgen – das Burn-Down-Diagramm.Es ist nicht erforderlich, beliebige Meilensteine hinzuzufügen.
Es scheint, dass Ihr Management das Grundkonzept eines Sprints nicht versteht. Es sollte sich beraten lassen oder an einer Grundschulung teilnehmen.Wenn es für Ihr Management dann immer noch wichtig ist, was innerhalb einer Woche erledigt wird, schlagen Sie stattdessen vor, die Sprintlänge zu halbieren.
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
Ja ist es.
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
Wenn Sie die Aufgaben in wirklich kleine Aufgaben unterteilen, können Sie eine gute Messgröße für die Arbeitsentwicklung erreichen.Daher können Entwurfsaufgaben an einem Arbeitstag erledigt werden und Sie können eine gute Burndown-Metrik-Nutzung erzielen.Wenn Sie lange Aufgaben mit unvorhersehbarer Länge haben, ist die Burndown-Metrik, wie Sie sagten, irrelevant.
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
Das Problem ist nicht das Team, sondern die Aufgabengestaltung.Das Problem betrifft die Aufgabengranularität.Ihr Team kann die Arbeit innerhalb der Sprintzeitmetrik erledigen, aber jetzt müssen Sie die Aufgaben so verfeinern, dass 50 % davon in der Zeitmetrik zur Mitte des Sprints erledigt sind.Teilen Sie die Aufgaben in kleinere Aufgaben auf und Sie können das gewünschte (lineare) Burndown-Diagramm erhalten.
Es handelt sich zwar um eine ungewöhnliche Terminologie, aber an dem, was Ihr Vorgesetzter sagt, ist etwas dran.
Ein Burndown-Diagramm, das endlastig ist (das heißt, es bleibt über einen großen Teil des Diagramms hoch und lässt dann am Ende plötzlich nach) weist auf eine Praxis hin, bei der Aufgaben grobkörnig sind – das heißt, eine Aufgabe wird wahrscheinlich erledigt Die Fertigstellung dauert einen ganzen Sprint – und wird von einzelnen Entwicklern durchgeführt.Bei diesem Muster bleiben alle Aufgaben bis kurz vor dem Ende des Sprints unvollständig.
So soll es wirklich nicht funktionieren:Wenn der Rückstand nach Priorität geordnet ist, warum werden dann Probleme bearbeitet, die nicht die höchste Priorität haben?Darüber hinaus wird dadurch die „Busnummer“ für jede Aufgabe sehr niedrig gesetzt, was das Risiko deutlich erhöhen kann, dass Aufgaben am Ende des Sprints unvollständig bleiben.
Um dies zu beheben, sollten Aufgaben in viel kleinere Abschnitte unterteilt werden.Wenn Sie Planungspoker betreiben und eine Aufgabe mit 8 oder mehr Punkten bewertet wird, ist die Aufgabe wahrscheinlich nicht ausreichend spezifiziert.Es muss abgebaut werden.Versuchen Sie, wenn möglich, 2 Sekunden und 3 Sekunden (oder weniger!) einzuschränken.Auf diese Weise können mehrere Entwickler unabhängig voneinander an demselben Gesamtziel arbeiten, und Ihr Burndown-Diagramm sollte flüssiger und weniger riskant aussehen, selbst wenn die gleiche Arbeit erledigt wird.
Die Akzeptanz während des Sprints ist keine agile Praxis oder funktioniert in der Realität nicht.Wenn Sie für jede User Story und Aufgabe (z. B. bei Rallye) eine korrekte Schätzung haben, zeigt das Burndown-Diagramm deutlich, ob die Sprintarbeit mit dem Plan übereinstimmt und rechtzeitig abgeschlossen werden kann oder nicht.Die Annahme erfolgt erst am Ende der Entwicklung und des Testens der User Story, nicht der Aufgaben.
