Ich verstehe formales Agile-Scrum-Tasking als die Praxis, Aufgaben zu dokumentieren und die Arbeitsstunden für jede Story oder jedes Produkt-Backlog-Element zu schätzen, zu dem sich ein Team in einer Iteration verpflichtet. Eine Aufgabe definiert einen Teil des „Wie“ der Story. Normalerweise sehe ich, wie Teams ihre Geschichten während oder kurz nach einer Iterationsplanungssitzung bearbeiten.
Folgen Sie immer noch Scrum, wenn ein Team Aufgaben nicht formell austeilt und den Aufgabenfortschritt in einer Iteration verfolgt?
Ich habe mit mehreren, meiner Meinung nach, ausgereiften Teams zusammengearbeitet, die überhaupt keine Aufgaben stellen und bei der Verwaltung ihrer Verpflichtungen ausschließlich auf der Ebene der Story- und Story-Point-Schätzung arbeiten.
Was sind die Vorteile, wenn Sie keine formelle Aufgabe stellen?
Was sind die Risiken?
Einige würden argumentieren, dass Sie Scrum noch mehr folgen, wenn Sie keine Aufgaben verwenden. Was passiert ist, ist, dass wir im Laufe der Zeit eine Verschmelzung von Begriffen und dadurch eine Duplizierung hatten.
Zufälligerweise hat Mike Cohn erst gestern (23. Juni 2015) darüber geschrieben .
Der Scrum-Leitfaden spricht von „Aufgaben“. „User Stories“ stammen von Extreme Programming. Als die ersten beiden agilen Frameworks haben sie begonnen, Begriffe im Laufe der Zeit zusammenzuführen und zu teilen. Eine Aufgabe und eine User Story sollten dasselbe sein.
Was meiner Meinung nach passiert ist, ist eine ziemlich klassische Trennung zwischen denen, die die Anforderungen generieren, und denen, die die Anforderungen erstellen. Product Owner würden die User Story definieren. Diese Geschichten waren oft schlecht übersetzte Produktanforderungen. Infolgedessen fehlte es ihnen an Details und sie waren oft auf hohem Niveau. Während der Planung würden die Entwickler dann Storys in Aufgaben (oder Entwickleraufgaben) aufteilen, um die gesamte Arbeit aufzuschlüsseln, die erledigt werden musste.
Was jedoch passieren sollte, ist eine bessere Erstellung von User Storys. Wenn ein Entwickler eine Story in Aufgaben zerlegen muss, wurde die Story wahrscheinlich nicht ausreichend zerlegt. Product Owner und Entwicklung müssen beim Backlog-Grooming zusammenarbeiten. User Stories sollten vollständig „bereit“ sein, bevor die Entwicklung sie in einem Sprint festschreibt (wir fangen tatsächlich an, den Begriff „Definition of ready“ zu sehen, um dies zu vermerken).
Arbeitsstunden sind wieder eine weitere Erfindung von Organisationen, die sich von traditionell zu agil bewegen. Es kann zu Beginn einer agilen Transformation nützlich sein, da es hilft, diese Brücke in Metriken und Berichten zu schlagen. Es kann jedoch eine Krücke sein und dazu führen, dass Schätzungen auf traditionelle Modelle zurückfallen, die nicht so gut funktioniert haben. Dies hat zu einer relativistischen Schätzung geführt (wobei eine Geschichte mit einer anderen verglichen wird, anstatt eine einzelne Geschichte zu schätzen). Es gibt ein Buch für 0,99 $ bei Amazon , das diese Methode behandelt. Ich gebe einen kurzen Überblick über die Übung auf meinem Blog in "Wie viel für diesen Gorilla im Fenster". `
Fazit: Zerlegen Sie Ihre User Stories auf etwas, das in 2 Tagen erledigt werden kann (für einen zweiwöchigen Sprint). Weisen Sie klare Akzeptanzkriterien zu, damit Entwickler wissen, wie sie fertig werden müssen (erforderlich für „bereit“). Verwenden Sie die relativistische Schätzung.
Lassen Sie die Aufgaben fallen.
Um dieses Thema herum herrscht eine Menge gefährlicher Verwirrung.
Wie ein Autor feststellte, bedeutet sogar der Begriff „Aufgabe“ für verschiedene Menschen unterschiedliche Dinge, also stellen Sie sicher, dass Sie in Ihrem Kontext über das Richtige sprechen.
Wenn Sie „User Story Mapping“, Patton, lesen, werden Sie eine Definition von Aufgaben als die Dinge sehen, die Menschen in einer Story tun möchten, nicht über die „Dinge, die zu tun sind, Arbeitsstrukturplan“. Es ist die letztere Definition, auf die ich mich in dieser Antwort beziehe.
Tasking als Management-Imperativ, um die geleistete Arbeit zu verfolgen, ist äußerst gefährlich.
Vielleicht die schlechteste Praxis aller anderen agilen Anti-Patterns zusammen.
Nun, "Aufgaben" sind per se nicht schlecht.
Ich benutze sie regelmäßig. Die ganze Zeit. Bei der Arbeit, zu Hause ... fast überall.
Aber ich setze sie agil ein. Ich schreibe die Liste auf Papier und lösche sie, wenn mir eine bessere Idee kommt. Ich quäle mich nicht damit, wie lange die Aufgabe dauern wird, weil die Aufgabe dauern wird, was die Aufgabe dauern wird. Komisch ist, dass ich regelmäßig den "Wert" der Sache erreiche, während viele unerledigte oder andere Aufgaben auf der Liste bleiben. Ich benutze sie, um mich zu leiten, aber sie sind nie „das Ding von Wert“.
Hier sind meine Heuristiken für den Einsatz von Tasking als Work-Breakdown-Structure:
Einige bessere Möglichkeiten:
Ich stimme dem oben Gesagten nur teilweise zu. Ich denke, dass Tasking etwas ist, das manchmal fallen gelassen werden kann, wenn ein Scrum-Team reift. Tasking wird am besten früh eingesetzt, wenn es ein Mittel bietet, um das Verständnis eines Teams für die Prozesse, Abhängigkeiten und typischen Arbeitsbelastungen zu beschleunigen, die mit der Bereitstellung einer Story verbunden sind.
Warum tun?
Weil es Ihnen Metriken (z. B. Burn-down) liefert, die Probleme innerhalb eines Sprints aufzeigen, dem Team beim Lernen hilft und dabei hilft, Hindernisse zu erkennen und zu beseitigen. Es hilft Ihnen, die Mechanismen der Übermittlung einer Geschichte auf einer detaillierten Ebene zu verstehen, was zu schnellerer Geschwindigkeit führt.
Warum nicht?
Denn es kostet viel Zeit. Es mag wie eine kleine Aufgabe erscheinen, die verbleibenden Stunden zu verteilen und zu überarbeiten – aber es kann Manntage aus einem Sprint herausholen.
Für mich lohnt es sich also in einem neuen Team oder einem neuen Projekt – aber man muss den Punkt erkennen, an dem man für die investierte Zeit keinen Gegenwert mehr bekommt. Kehren Sie an diesem Punkt nur zu den Geschichten zurück und sehen Sie, wie es läuft.
Ich hoffe das hilft.
Wo widerspreche ich dem oben Gesagten?
Nun, Aufgaben und Geschichten sind NICHT gleich.
Eine Geschichte ist das „Was und Warum“, eine Aufgabe ist nur das „Wie“. Beides darf sich nie überschneiden, da die Unabhängigkeit von Anforderung und Lösung gewahrt bleiben muss. Der Product Owner muss die Story besitzen. Das Team muss die Aufgaben übernehmen.
Jede Überschneidung oder Verwirrung zwischen den beiden legt für mich nahe, dass etwas in der Dynamik des Prozesses sehr falsch ist – normalerweise zu viel Einfluss auf das „Was und Warum“ von den Technikern und / oder zu viel Einfluss auf das „Wie“ von der Product Owner. Und das ist nie gut!
Alan Larimer