Inhaltsverzeichnis
Merkmalsauswahl (Sprintplanung – Teil eins)
Viele Teams legen ein Gesamtziel für die Iteration fest, um die Auswahl der Funktionen zu erleichtern. Zu Beginn des Meetings werden in der Regel die Features mit der höchsten Priorität ausgewählt release planen. Wenn die Iteration ein übergeordnetes Ziel hat, können einige Funktionen mit niedrigerer Priorität ausgewählt werden, wenn sie besser mit dem Ziel übereinstimmen. Die vorherige Geschwindigkeit ist entscheidend, damit das Team einen realistischen Arbeitsaufwand planen kann.
Wenn das Team beispielsweise zuvor geplant hatte, Produktfunktionen im Wert von 40 Story Points zu erhalten, aber nur 30 Story Points erfolgreich lieferte, sollten 30 Story Points als aktuelle Geschwindigkeit für die nächste Iteration betrachtet werden. Frühere Geschwindigkeitsschätzungen im Vergleich zu tatsächlichen Zahlen sind auf der Iterationsebene, der Feature-Ebene und der Aufgabenebene nützlich. All dies hilft dem Team zu bestimmen, für wie viel es sich in der nächsten Iteration anmelden kann. Wenn die Iteration überbucht ist, muss der Kunde auswählen, welche Funktionen auf eine zukünftige Iteration verschoben werden sollen. Während des Iterationsplanungsmeetings bespricht der Kunde die Funktionen mit dem Team und versucht, alle Fragen des Teams zu beantworten.
Aufgabenplanung (Sprintplanung – Teil zwei)
Das Team wird die Funktionen in Aufgaben aufteilen. Entwickler melden sich dann für Aufgaben an und schätzen diese. Die Dauer der Aufgaben liegt in der Regel zwischen vier Stunden und zwei Tagen, wobei die meisten Aufgaben innerhalb eines Tages erledigt werden können. Aufgaben, die länger als zwei Tage dauern, sollten grundsätzlich in kleinere Aufgaben aufgeteilt werden. Gelegentlich stellt sich bei der Aufgabenplanung heraus, dass eine Funktion im Original völlig unterschätzt wurde release Plan. In diesem Fall muss das Team mit dem Kunden zusammenarbeiten, um einen korrigierten Kostenvoranschlag zu erstellen und zu ermitteln, welche Funktion(en) sich dadurch möglicherweise verzögern müssen.
Iterationsanpassungen
Wenn während der Iteration noch Zeit verbleibt, nachdem alle Funktionen bereitgestellt wurden, kann das Team den Kunden auffordern, zusätzliche Funktionen zu identifizieren, die der Iteration hinzugefügt werden sollen. Wenn andererseits offensichtlich ist, dass nicht alle Funktionen bereitgestellt werden können, arbeitet das Team mit dem Kunden zusammen, um zu ermitteln, welche Funktionen verzögert oder möglicherweise aufgeteilt werden könnten, um bis zum Iterationstermin den größtmöglichen Nutzen zu liefern.
Warnsignale
- Wenn das Team über eine Reihe von Iterationen hinweg weiterhin Funktionen in die Zukunft verschiebt, ist dies ein Zeichen dafür, dass das Team seiner vorherigen Geschwindigkeit mehr Aufmerksamkeit schenken sollte, um kontinuierliche Überbuchungen zu minimieren und die Planungsgenauigkeit zu maximieren.
- Wenn das Team bei jeder Iteration dieselben Funktionen vorantreibt, kann dies ein Signal dafür sein, dass das Team bestimmte Funktionen absichtlich vermeidet und die Grundursachen untersucht werden sollten.
- Wenn das Team zu sehr ins Detail geht und jede Funktion vollständig entwirft, besteht möglicherweise die Möglichkeit, sich stärker auf die Ermittlung der erforderlichen Aufgabenarbeit zu konzentrieren.
FAQs
Wie gehen wir mit Abhängigkeiten zwischen Aufgaben um?
Diese Frage kommt ziemlich häufig vor. Im Rahmen der Iterationsplanung sollte das Team danach streben, Aufgabenabhängigkeiten bei der Aufteilung von Features zu minimieren. Spezifische Techniken sind in Mike Cohns hervorragendem Buch reichlich vorhanden Angewandte User Stories. Als nächstes sollte das Team eine Zusammenarbeit anstreben, um die Auswirkungen unvermeidbarer Abhängigkeiten zu minimieren. Agile Teams nutzen in der Regel einfache, lose gekoppelte, anpassungsfähige Designs, die Abhängigkeiten minimieren. Eine hervorragende Quelle für die Entwicklung und Verfeinerung solcher Architekturen ist Bob Martins bahnbrechendes Buch Agile Softwareentwicklung: Prinzipien, Muster und Praktiken. Agile Teams verwenden außerdem Techniken, Tools und Praktiken, die es ihnen ermöglichen, gleichzeitig an voneinander abhängigen Subsystemen und Modulen zu arbeiten. Testgetriebene Entwicklung, automatisierte Testumgebungen und Scheinobjekte helfen Teams dabei, Abhängigkeiten zwischen Aufgaben zu minimieren und zu bewältigen. Eine kontinuierliche und enge Zusammenarbeit kann hier der Schlüssel sein; Am selben Ort ansässige Teams finden es einfacher, Abhängigkeitsherausforderungen während der gesamten Iteration gemeinsam und just-in-time zu lösen.
Iterationen dauern nur eine begrenzte Zeit, wodurch das Risiko verringert wird, dass eine einzige lauernde Abhängigkeit das Projekt zum Erliegen bringt. PERT-Diagramme und CPM sind zwar potenziell wertvoll für das allgemeine Systemverständnis, neigen jedoch sehr stark dazu, unter dem Stress der schnellen, iterativen Softwareentwicklung zusammenzubrechen. Der zusätzliche Zeit- und Arbeitsaufwand für die Erstellung eines Abhängigkeitsmodells für eine zweiwöchige Iteration lohnt sich selten. Durch automatisierte Tests und Code erhalten Sie mindestens genauso schnell genaueres und ausführbares Feedback.
Für wie viel sollte sich ein Teammitglied anmelden?
Ein Teammitglied sollte sich selten für mehr als die Gesamtschätzung der Aufgaben anmelden, die es in der vorherigen Iteration erledigen konnte. Wenn während der Iterationsplanung keine Aufgaben angemeldet werden, wird mehr Wert darauf gelegt, sicherzustellen, dass sich das Team nicht für zu viele Arbeiten anmeldet, indem es mit den Funktionen und der Aufgabengeschwindigkeit der vorherigen Iteration verglichen wird.
Wie planen Sie Iterationen, wenn die Teamgröße variiert?
Ohne die Fähigkeit, sich auf konsequente Teamarbeit zu verlassen, bietet kein Projektansatz, weder agil noch anders, viele Erkenntnisse. Bei der iterativen Softwareentwicklung gibt es jedoch zumindest typischerweise eine gewisse Historie, die im Laufe der Zeit aufgebaut wird und als Grundlage für die Planung dient. Wenn Sie bei der iterativen Entwicklung mehrere Iterationen mit einem zehnköpfigen Team mit einer durchschnittlichen Geschwindigkeit von 20 idealen Tagen oder 200 Stunden pro Iteration durchgeführt haben und Ihr Team halbiert wird, sollte eine einfache Berechnung dazu führen, dass Sie nicht mehr als zehn planen Ideale Tage für die bevorstehende Iteration (zumindest anfangs). Wenn wichtiges Personal entfernt wurde oder Sie feststellen, dass Sie falsch liegen, werden Sie es in den nächsten Wochen erfahren und können sich schnell auf zukünftige Iterationen einstellen.
Wie berücksichtigen Sie den Overhead (Besprechungen, E-Mail usw.)?
Teams verbringen im Allgemeinen nicht viel Zeit damit, kleinere Gemeinkosten zu verfolgen. Im Laufe einiger Iterationen spiegeln sich diese Unterbrechungen in immer konsistenteren (wenn auch unerwarteten) tatsächlichen Geschwindigkeitswerten wider. Einige Teams integrieren größere Unterbrechungen und Störungen explizit in ihre Iterationspläne, um das Risiko zu reduzieren und die Sichtbarkeit zu erhöhen.
Wie berücksichtigen Sie die Fehlerbehebung bei der Iterationsplanung?
Es gibt verschiedene Möglichkeiten, wie Teams mit der Fehlerbehebung umgehen. Eine der einfachsten Möglichkeiten besteht darin, Fehler als explizite Eingabe in die Iterationsplanung einzubeziehen, sie zu priorisieren und die damit verbundenen Aufgaben abzuschätzen. Fehler und Funktionen sind im Wesentlichen gleichwertige Arbeitseinheiten für Planungszwecke. Einige Teams entscheiden sich dafür, Fehler außerhalb ihres Iterationsprozesses separat zu verfolgen. Dies ist etwas riskanter: Wenn der Fehlerbehebungsaufwand zwischen den Iterationen variiert, variiert die Geschwindigkeit des Teams entsprechend, wodurch Schätzungen und Pläne durcheinander gebracht werden. Wenn jedoch der Aufwand zur Fehlerbehebung konstant gehalten wird, kann diese Methode einigermaßen gut funktionieren.
Warum sollten Iterationen immer gleich lang sein?
Iterationen mit gleicher oder sehr ähnlicher Länge bieten einen Rhythmus, auf den sich Teams bei der Schätzung und Planung verlassen können. Ohne Iterationen fester Länge kann es schwierig sein, eine konstante Geschwindigkeit zu erreichen und zu messen. Die Disziplin, die Produktion am Ende einer Iteration einzustellen, konzentriert sich auf alle Beteiligten und übt Druck aus, die Designs einfach zu halten und einer Vergoldung oder Scope Creep zu widerstehen. Die gesamte Organisation gewöhnt sich schnell an ein stetiges Summen von Input, Planung, Ausführung, Output und Rückblick. Ohne diesen Rhythmus ist das Team weniger effizient. Gelegentlich gibt es gute Gründe, bestimmte Iterationen zu strecken oder zu komprimieren, um sie an Fristen, größere Unterbrechungen oder Feiertage anzupassen. Aber das sollte die Ausnahme sein, nicht die Regel.
Wie berechne ich die Test- und Dokumentationszeit?
Tests und Dokumentationsaktualisierungen sollten wie jede andere wichtige Aktivität, die die Zeit eines Entwicklers erfordert, priorisiert, geschätzt und geplant werden. Sie werden häufig als Aufgaben unter bestimmten Funktionen erstellt, können aber auch als eigene Funktion gruppiert werden.
Sollten Feature-Schätzungen während der Iterationsplanung überarbeitet werden?
Feature-Schätzungen sollten während der Iterationsplanung nur dann überarbeitet werden, wenn sich herausstellt, dass die ursprüngliche Schätzung weit von der Basis abweicht und der neue Aufwand erhebliche Auswirkungen auf die Fähigkeit des Teams hat, andere Arbeiten abzuschließen.
Sollten Aufgabenschätzungen während einer Iteration überarbeitet werden?
Die ursprüngliche Aufgabenschätzung sollte nach Abschluss der Iterationsplanung nicht mehr überarbeitet werden. Andererseits sollten die Schätzungen für zukünftige Iterationen kontinuierlich überprüft werden, um eine genaue Einschätzung der verbleibenden Arbeit widerzuspiegeln.
Sollten alle Teams nach dem gleichen Iterationsplan arbeiten?
Es bietet Vorteile, wenn alle Teams nach dem gleichen Iterationsplan arbeiten. Das Rollieren des Iterationsstatus zwischen den Teams ist nur dann sinnvoll, wenn die Teams den gleichen Zeitplan einhalten. Es ist nicht hilfreich, einen numerischen Status für ein Team zusammenzufassen, dessen Iteration gerade erst beginnt, zusammen mit einem anderen, das kurz vor dem Abschluss steht. Der Nachteil daran, dass alle Teams denselben Iterationsplan haben, besteht darin, dass die Iterationen gleichzeitig gestartet und abgeschlossen werden müssen. Wenn gemeinsame Ressourcen (z. B. ein Kunde oder das Management) projektübergreifend genutzt werden, schätzen sie möglicherweise einen gestaffelten Iterationsplan über die Teams hinweg.
