Frühes Subtasking zu Beginn jedes Sprints

Ich bin einem neuen Team beigetreten, das Agile / Scrum verwendet, und der Entwicklungsprozess ist wie folgt:

1) Entwickler überprüfen jede Geschichte vor jedem Sprint, um sicherzustellen, dass nichts Kritisches übersehen wird. Dafür gibt es im Workflow einen formalen Status.

2) Während des Sprint-Kickoffs nimmt das gesamte Team eine Schätzung (Pokerplanung) vor, wie viele Story-Punkte jede Story kosten würde.

3) Schließlich muss jeder Entwickler unmittelbar nach dem Start jedes Sprints alle zugewiesenen Storys eifrig in Unteraufgaben mit Zeitschätzungen aufteilen (im Gegensatz zum Subtasking vor dem Starten jeder Story).

Das Hauptargument für den letzten Schritt ist, dass es hilfreich ist, herauszufinden, ob die Implementierung einer Story länger als erwartet dauern würde, und Scrum Master vor möglichen Risiken für fehlende Sprint-Fristen zu warnen.

Ich finde dies jedoch kontraproduktiv, hauptsächlich aus folgenden Gründen:

• Wenn das Ziel eine grobe Schätzung ist, sind Story Points (Schritt 2) das, was die Aufgabe erledigt. Warum sollte man sich sonst überhaupt mit Story Points beschäftigen? - Mach einfach früh Subtasking.
• Wenn das Ziel darin besteht, genaue Schätzungen bereitzustellen, ist dies ein klares Beispiel für das, was unter Als schädlich eingestufte Schalter für menschliche Aufgaben beschrieben wird . Ich denke, dies gilt insbesondere für neue Entwickler, die sich bestehenden Teams in großen Projekten anschließen, bei denen das Verstehen, was getan werden muss, bis zu 50% der Zeit in Anspruch nehmen kann. Sie müssen sich mit Details zu Geschichte Nr. 1, dann zu Geschichte Nr. 2, Nr. 3 usw. usw. befassen, was zu einer Menge Informationsabwanderung führt.

Mir wird auch gesagt, dass eine solche Praxis "nach dem Buch" ist und ich nicht einmal dazu gedacht bin, darüber zu diskutieren. Kann jemand einen Hinweis auf eine solche Praxis geben - ob dies in Scrum-Bibeln klar definiert ist und / oder vielleicht zusätzliche Erkenntnisse liefert?

Dies ist nicht unähnlich dazu, wie wir einen Teil unseres Scrum-Prozesses ausführen. Wir

1. Schätzen Sie Storys in "Story Points" am oberen Rand des Backlogs.
2. Wählen / erklären Sie Geschichten basierend auf den Story-Punkten, von denen wir glauben, dass sie den Sprint "ausmachen"
3. Teilen Sie die Geschichten in detailliertere technische Aufgaben auf
4. Schätzen Sie die technischen Aufgaben und vergleichen Sie sie mit der ursprünglichen Schätzung der Story Points (wir wissen ungefähr, wie viel Entwicklungszeit ein Story Point normalerweise entspricht).

Aber was Sie wissen wollen, ist, warum wir zweimal schätzen!

• Wir haben eine grobe Schätzung (auf der Basis der Geschichte) , weil wir zu prognostizieren zu können, was ist vielleicht in dem seine nächsten Sprint, und vielleicht sogar die eine danach. Letztendlich muss das Management in der Lage sein, mit dem Kunden über wahrscheinliche Zeitskalen zu kommunizieren. Wenn wir diese grobe Skalenschätzung nicht haben, ist eine langfristige Planung praktisch unmöglich.
• Dies bedeutet natürlich, dass wir grobe Schätzungen für mehr als nur den aktuellen Sprint durchführen. Da es keine Garantie gibt, dass sich die Auftragsbestandsreihenfolge für den nächsten Sprint nicht ändert, möchten wir die Zeit nicht in Aufgabenaufschlüsselungen und genaue Schätzungen investieren, bis sie erforderlich sind.
• Wir teilen die Aufgabe auf, um sicherzustellen, dass alle Aufgaben aufgezählt wurden und dass Geschichten einfacher parallel bearbeitet werden können.
• Wir führen feinskalige Schätzungen durch (basierend auf der Aufgabe), da dies zu einem viel glatteren Burn-Down-Diagramm führt (insbesondere dort, wo es keine einfache Möglichkeit gibt, eine große Story in realisierbare "Features" zu zerlegen).
• Da wir beides tun, dienen sie als gegenseitige Überprüfung der geistigen Gesundheit - eine wilde Diskrepanz zeigt an, dass wir irgendwo einen Fehler brauchen, den wir identifizieren müssen. Dies ist ein nützliches Nebenprodukt, aber nicht der Grund an sich, warum wir "zweimal" schätzen.

Beim erneuten Lesen Ihrer Frage und Ihres Kommentars sehe ich einige Unterschiede zwischen unserem und Ihrem Workflow.

• Wir machen Pannen als Team . Obwohl der Overhead größer ist, ist die technische Diskussion, die wir daraus erhalten, oft sehr wertvoll und kann Mängel in unserer Geschichte erkennen. Wenn wir Erfahrung, Wissen oder Fähigkeitsunterschiede haben, können in dieser Diskussion auch diejenigen mit mehr helfen, die weniger haben (sehr nützlich bei Neueinstellungen).
• Wir machen Schätzungen auf Aufgabenebene als Team . Einer der Gründe, warum "Planen von Poker" funktioniert, ist das Phänomen "Weisheit der Menge" - wie ich in den Kommentaren erwähne, sollte das Schätzen einer Aufgabe zu diesem Zeitpunkt weniger als 30 Sekunden dauern Der Overhead ist also vernachlässigbar.

Es hört sich so an, als ob Ihr Team Aufgabenaufschlüsselungen und Aufgabenschätzungen für einen reibungslosen Abbrand vornimmt. Dies ist in Ordnung. Dies ist Teil der Überwachung des Sprintfortschritts und der frühzeitigen Erkennung und Lösung von Problemen durch Ihren Scrum-Master. Wenn Sie diese Informationen mögen Sie haben die Pannen und Schätzungen zu tun , und Sie müssen sie zuerst tun.

Meiner Meinung nach ist das Wechseln von Aufgaben für Sie hier wahrscheinlich kein Problem. Ich denke nicht, dass das Aufteilen verschiedener Aufgaben wirklich ein Aufgabenwechsel in dem Sinne ist, dass das Umschalten von der Entwicklung einer Funktion auf eine andere auf halbem Weg ein Aufgabenwechsel ist . Ich denke, ein Verständnis der gesamten "Architektur" des Sprints zu erlangen, ist wahrscheinlich eine nützliche Sache.

Ich denke jedoch, dass es einige andere Probleme geben könnte, die Sie in Betracht ziehen könnten. Wie immer bei Agile sollten Sie ein Problem identifizieren und eine Lösung vorschlagen und dann entscheiden, ob Ihre Lösung im Nachhinein funktioniert hat . Dies ist der Kern des Aufbaus einer agilen Lösung, die für Ihr Unternehmen und Ihr Team funktioniert. Einige Probleme, die Sie möglicherweise haben:

• Sie machen Pannen individuell - wie lernen Ihre Junior- / unerfahrenen Teammitglieder von Ihren Senior-Teammitgliedern? Sicher, sie können wahrscheinlich alles selbst lernen - aber sie werden schneller lernen, wenn sie betreut werden. Nehmen sich Junior-Teammitglieder viel Zeit, um die Dinge zusammenzubrechen? Machen sie Fehler oder fehlen Dinge, die das Team auf lange Sicht Zeit kosten? Hier kann es hilfreich sein, als Team zusammenzubrechen.
• Sie führen Schätzungen einzeln durch - das Gleiche gilt für den ersten Punkt. Sind diese Schätzungen jedoch weniger genau als sie sein könnten?
• Es hört sich so an, als würden Aufgaben zu Beginn des Sprints zugewiesen. Wenn dies jedoch der Fall ist, wie teuer ist es dann, wenn Sie die Zuordnung ändern müssen? Wenn jemand zurückfällt oder krank ist, wie einfach ist es für einen anderen, seine Aufgaben zu erledigen? Müssen sie die Aufgabenaufschlüsselungen durchgehen und versuchen, sie zu verstehen, ohne den ursprünglichen Beauftragten zu unterbrechen? Wenn Sie als Team zusammenbrechen und schätzen, sollte jeder in der Lage sein, an allem zu arbeiten!
• Sind deine Geschichten zu groß? Wenn der Zusammenbruch 50% der Zeit in Anspruch nimmt, klingen die Geschichten so, als wären sie sehr involviert - vielleicht können sie kleiner gemacht werden? Wir halten unsere Geschichten innerhalb von 1 Mannwoche nach der Arbeit.
• Sind deine Aufgaben zu klein? Wenn Sie lange Zeit damit verbringen, Aufgabenlisten zu erstellen, gehen Sie vielleicht zu sehr ins Detail? Wir haben in der Regel Aufgaben im Wert von 1 bis 8 Mannstunden, so dass jeder im Laufe eines Tages Fortschritte macht, um beim nächsten täglichen Aufstehen Bericht zu erstatten.

Wenn Ihr Unternehmen auf diese Weise seine Entwicklung durchführen und die Diskussion beenden möchte, sind Ihre Auswahlmöglichkeiten begrenzt, oder Sie laufen zumindest Gefahr, Menschen zu verärgern.

Angesichts der Tatsache, dass das ultimative Ziel von Agile die Arbeit mit wertvoller Software ist, können Sie versuchen, zu helfen, indem Sie die Lieferfähigkeit Ihres Teams messen (gelieferte / geschätzte Punkte, Fehler im Sprint, Anzahl der Tests, Codeabdeckung, Verfügbarkeit, generierte Verkäufe - was auch immer). Seien Sie auf alle Ergebnisse vorbereitet - es kann sein, dass diese Arbeitsweise für sie funktioniert, auch wenn sie für Sie keinen Sinn ergibt. Wenn Sie Recht haben, wird der Abfall offensichtlich.

Seien Sie vorsichtig, wenn Sie den Prozess um des Prozesses willen befolgen - dies verschwendet Zeit und liefert immer noch schlechte Produkte. Ein gutes agiles Team experimentiert, misst und lernt. Der beste Weg, um das Verhalten zu ändern, ohne in eine Meinung zu verfallen, sind evidenzbasierte Entscheidungen.

Das ist auch meine Meinung. Ich schlage vor, Sie versuchen es selbst und messen das Ergebnis - sehen Sie, was ich dort getan habe :)

Ich würde annehmen, dass Ihr Sprint Kickoff das Sprint Planning Meeting bedeutet. Ich denke, Ihr Scrum Master hat falsch interpretiert, wie dieses Meeting verlaufen soll. Sie entscheiden nicht nur, welche Storys entwickelt werden sollen, Sie testen sie auch Ihrem Team gegenüber, um sicherzustellen, dass sie nichts verpassen (normalerweise mit INVEST ), und Sie unterteilen diese Storys in Aufgaben. Um Mike Cohn (einen der Gründer der Scrum Alliance) zu zitieren ;

Der Sprint-Rückstand ist die andere Ausgabe der Sprint-Planung. Ein Sprint-Backlog ist eine Liste der Produkt-Backlog-Elemente, zu deren Bereitstellung sich das Team verpflichtet hat, sowie die Liste der Aufgaben, die für die Bereitstellung dieser Produkt-Backlog-Elemente erforderlich sind. Jede Aufgabe im Sprint-Backlog wird normalerweise ebenfalls geschätzt.

Das Aufteilen und Schätzen von Geschichten ist Teil der Sprint-Planungssitzung. nicht nach Abschluss der Planungssitzung und nicht einzeln.

Um weitere Einblicke zu erhalten, sieht unser Workflow während des Sprint Planning-Meetings wie folgt aus:

1. Wir nehmen eine Geschichte aus dem oberen Bereich des Produkt-Backlogs und teilen sie in Aufgaben auf. Als Faustregel sollte eine Aufgabe im Allgemeinen kleiner als ein Tag sein.

2. Wir schätzen die Geschichte angesichts der Aufgaben, die wir abgezogen haben. Wenn die Geschichte groß wird, versuchen wir, die Geschichte in kleinere Geschichten aufzuteilen.

3. Spülen und wiederholen, bis die Gesamtzahl der geschätzten Punkte erreicht ist

Im Gegensatz zu dem, was Cohn sagt, habe ich festgestellt, dass es nicht wirklich notwendig ist, jede der Aufgaben separat zu schätzen, da die Aufgaben kleiner als ein Tag sind. Angesichts der Tatsache, dass Aufgaben kleiner als ein Arbeitstag sind, können Sie während des täglichen Standups leicht feststellen, dass eine Aufgabe länger als erwartet dauert, da die Person, die an der spezifischen Aufgabe arbeitet, angibt, dass sie noch daran arbeitet.

Während des Sprints arbeitet sich das Team durch die Geschichten und am Ende sollte das Team darüber nachdenken, wie viel tatsächlich getan wurde. Dafür ist das Scrum Retrospective Meeting gedacht. Wenn noch Geschichten auf dem Tisch liegen, können Sie daraus schließen, dass Ihre Einschätzung zu optimistisch war, und für den nächsten Sprint darauf reagieren. Alternativ könnte es bestimmte Vorfälle gegeben haben, die sich darauf auswirken, wie viel Sie getan haben usw. Sie werden feststellen, dass die Schätzungen mit der Zeit besser werden, wenn Sie darüber nachdenken.

"by the book" - das ist dein Problem. Sie ertrinken in mehr Prozessen, als Sie hätten, wenn Sie Wasserfälle bearbeitet hätten.

Es gibt kein "Buch" für Agile, es gibt nur das agile Manifest, das besagt: "Erledige Dinge ohne all den Aufwand". Wenn Sie also Größen schätzen und die Storys dann in Aufgaben aufteilen, um sie neu zu schätzen, ist dies ein sinnloser Prozessaufwand, der effizienter gestaltet werden muss - darum geht es bei Agile. Scrum und alle anderen sind wirklich Ausgangspolitik dafür, wie Sie anfangen, agil zu werden. Während Sie dies tun, sollten Sie diese Punkte identifizieren, die keinen Sinn ergeben oder Ihrem Team nicht helfen, effektiver zu arbeiten, und Sie sollten sie ändern.

Einige Leute denken jedoch, dass verbotene Arbeitsweisen in Stein gemeißelt und niemals abgewichen werden müssen, egal wie dumm sie werden. Ich würde versuchen, Storys vor dem Scrum-Meeting in Aufgaben aufzuteilen. Sie sagen, Entwickler müssen jede Story überprüfen. Nun, hier ist die Möglichkeit, die Aufteilung gleichzeitig als Teil der Überprüfung durchzuführen. Anschließend können Sie die Aufgaben, aus denen sich die Story zusammensetzt, in der Scrum-Besprechung deklarieren (ihnen keine Zeit zuweisen!) Und die Benutzer anhand dieser zusätzlichen Informationen entscheiden lassen, wie groß ein Arbeitspaket ist (was niemals eine schlechte Sache ist). Eine fundierte Entscheidungsfindung ist viel besser als Vermutungen und kann nur durchgeführt werden, wenn Sie Informationen haben, die Sie in die Entscheidungsfindung einfließen lassen können.

Nach dem Meeting können Sie den Aufgaben immer noch Zeiten zuweisen (obwohl ich den Punkt nicht verstehe, basieren Sprints nicht auf der Zeit, sondern auf "wie viel Dinge Sie erwarten", gemessen in Story-Punkten Dies ist ein häufiges Problem bei Scrum. Punkte bedeuten keine Zeit, aber Sie müssen beispielsweise 20 Punkte pro zwei Wochen erledigen, daher 2 Punkte = 1 Arbeitstag. Es soll eine schnelle Vermutung sein, wie viele Aufgaben zu erledigen sind im Sprint sind Sie also weder überlastet noch unterlastet, nicht wie viele tatsächlich erledigt werden. Die besten Sprints sind diejenigen, bei denen noch ein paar Aufgaben übrig sind, was zeigt, dass Sie perfekt geschätzt haben. Wenn Sie jede Aufgabe erledigen, werden die letzten entweder überstürzt oder verspätete Fertigstellung am Ende - beides ist nicht produktiv).

Kurz gesagt: Drucken Sie eine Kopie des Agilen Manifests und der Anti-Agilen-Version aus . Ich wette, du machst mehr Anti als Agilität. Scrum neigt dazu, so zu sein. Die einzige Möglichkeit, dies zu beheben, besteht darin, sich mit Ihrem Team in Verbindung zu setzen und sich für Änderungen zu engagieren. Lassen Sie sich vom Management nicht sagen, wie Ihr Team arbeiten soll, das ist auch nicht agil und wird in The Book geschrieben.

Irgendwann während jedes Sprints sollten Sie ein Product Backlog Refinement Meeting abhalten . In dieser Besprechung stellen Sie sicher, dass der obere Teil des Product Backlogs ausreichend aufgeschlüsselt ist, damit Elemente in diesem Teil zum nächsten Sprint Backlog hinzugefügt werden können.

Wenn die Verfeinerung des Product Backlogs gut verwaltet wird, kann das Sprint Planning Meeting effizienter sein. Im Idealfall würde dies die Notwendigkeit für Entwickler vermeiden, Geschichten nach dem Start des Sprints "eifrig aufzuschlüsseln" .

Wenn Product Backlog-Elemente zum Sprint-Backlog hinzugefügt werden, bevor sie für eine realistische Schätzung ausreichend aufgeschlüsselt werden, ist es schwierig, gute Entscheidungen darüber zu treffen, was dem Sprint hinzugefügt werden soll.