Scrum/Agile: Wie planen Sie interne Verbesserungen?

Question

Ich habe jetzt in den letzten zwei Jahren an zwei verschiedenen Teams gearbeitet, die den Agile/Scrum-Ansatz verwenden, und beide Teams waren bestrebt, die Art und Weise, wie sie die Softwareentwicklung angehen, zu verbessern. Im ersten Team konnten wir unseren Product Owner leicht davon überzeugen, Zeit für interne Dinge wie die Verbesserung des Build-Systems, die Einrichtung besserer Integrationstests, eine bessere Release-Strategie usw. zu bekommen. Derzeit ist die PO auch bereit, uns Zeit zu geben er drückt mehr zurück, was vernünftig ist, da er auch seine Sachen erledigen muss.

Wie auch immer meine Frage ist, wie gehen andere Teams damit um? Schaffst du eine Verbesserungsgeschichte und legst sie während der Planung auf den Tisch oder behälst du einen "Eimer" Zeit für solche Dinge? Wie schwer ist es Ihrer Erfahrung nach, den Product Owner davon zu überzeugen, Zeit für Verbesserungen zu haben? Nach all diesen Verbesserungen wird das Team profitieren, aber nicht direkt oder sofort der Eigentümer/das Unternehmen.

Answer 1

Große Frage. Ich denke, es gibt verschiedene Arten von "Action Items" aus Retrospektiven, die unterschiedliche Ansätze verdienen.

1) technische Aufgaben, um Dinge wie technische Schulden oder Infrastrukturverbesserungen anzugehen - wie "Wir sollten sicherstellen, dass wir keine Datenbankaufrufe in der Ansichtsebene unserer Anwendung haben, weil wir in dieser letzten Iteration Zeit verschwendet haben ... jemand sollte den Code durchsuchen, um sicherzustellen, dass wir das nicht woanders machen. "

2) Prozessverbesserungen (zB „Leute zu den Standups auf Zeit sind nicht ... ein $ 1 für wohltätige Zwecke spenden können kommen, wann immer jemand spät starten“.)

Die erste Kategorie bedeutende Arbeit sein kann, oder es könnte einfach sein. Das Beispiel, das ich zeigte, war ziemlich einfach ... aber könnte andere Aufgaben generieren, die geplant werden müssen (z. B. das Entfernen der Datenbankaufrufe an den fünf Orten, an denen sie entdeckt wurden).

Die zweite Kategorie sollte vom Iterationsmanager, Projektmanager, Scrum Manager, etc. gehandhabt werden. Ich (normalerweise als Scrum Master oder Projektmanager) liste sie in einem Projekt Wiki auf und bespreche sie in Retrospektiven, check sie aus, wenn sie angesprochen werden, und berichten dem Team über den Status. Ich halte das Feuer an.

Ich denke, der Fehler in der ersten Kategorie - technische Aufgaben - ist, dass wir keine Akzeptanzkriterien definieren. Ihre Beispiele beinhalteten "Verbesserung des Build-Systems, Einrichtung besserer Integrationstests, bessere Release-Strategie". Diese sind nicht deterministisch und müssen in klaren Worten aufgezählt werden (wenn nötig mit Spikes). Also - die Verbesserung des Build-Systems könnte mit einer technischen Aufgabe oder einem Spike beginnen, um die Optionen zu bewerten.

Wir müssen auch technische Aufgaben zusammenfassen und priorisieren (zB könnten "bessere Integrationstests" mit einer technischen Aufgabe beginnen, die aktuelle Integrationsabdeckung zu definieren, oder den Prozentsatz der Fehler bewerten, die Integrationsfehler zugeschrieben werden könnten) Bauen Sie den Fall für die Investition dort auf

Sobald Sie Ihre Prioritäten gesetzt haben, können Sie den Wert der hohen Priorität Elemente vermitteln und verhandeln mit dem Product Owner für die Zeit, um sie zu verbringen. Ich bin kein großer Fan von Vordefinierte Buckets für alles ausgeben ... aber die Konversation mit dem Product Owner mit klaren Anforderungen, ROI und Akzeptanzkriterien ist der Schlüssel.

Answer 2

Ich würde einen "Spike" für solche Dinge verwenden. Eine interne/Prozessverbesserung könnte keine User Story sein, aber sie würde eine perfekte Spitze bilden.

Answer 3

Verbesserungen sollten Teil des Sprints sein, genauso wie neue Funktionen. Es liegt am Team, dem Product Owner zu zeigen, dass diese Verbesserungen für den kommenden Sprint notwendig sind. Dies kann die Geschwindigkeit verlangsamen, mit der neue Merkmale erzeugt werden, ist aber am Ende für das Produkt nützlich.

Auf der anderen Seite habe ich Probleme mit Sprints, die nur Verbesserungen enthalten. Jeder Sprint sollte eine Ausgabe erzeugen, die dem Product Owner vorgeführt werden kann.

Answer 4

Crystal Methods hat das Konzept des Reflection Workshops als Mittel, um Ihren Entwicklungsprozess zu optimieren. Teams treffen sich regelmäßig (weniger häufig als Ihr Entwicklungszyklus, vielleicht), um Verbesserungen und den Status des Prozesses zu diskutieren. Komm mit 0-3 Sachen, die wir dieses Mal versucht haben, die funktionierten und wir behalten, 1-3 Dinge, die nicht funktionieren, und 1-3 Dinge, um das nächste Mal zu versuchen. Die Idee ist eine schrittweise Verbesserung sowohl im Prozess als auch im Produkt.

Answer 5

Letztes Jahr arbeitete ich für einen der frühesten Agile (xp) Adopters/Berater/Trainer. Er hatte eine gute Herangehensweise, denke ich.

Wir trafen uns jeden Freitag und diskutierten nur, was funktioniert und was nicht. Wir würden sie auf zwei große Zettel schreiben (Er war wirklich in der Papier & Staffelei statt Whiteboard, weil es dauerhafter war und leichter neu positioniert werden konnte).

Die Dinge, die sehr einfach sein gearbeitet könnte - wir interagierten gut als Team Paarung verlief reibungslos usw.

Die Dinge, die nicht nur so einfach und zufällig waren nicht funktioniert. Manche Leute könnten sich wehren, oder sogar "Der Chef hat uns nicht wie versprochen auf sein Boot gebracht".

Jede Woche würden wir auch vergangene "Did not work" besuchen und sehen, ob wir sie behoben haben - Wenn ja, würden sie immer in dieser Woche "Did Arbeit" Spalte aufgeführt werden.

Obwohl wir spezifische Lösungen diskutierten, neigten die Probleme nur zu einem sehr positiven Effekt. Wenn sie drei oder vier Wochen auf der "Did not work" -Liste bleiben würden, würden wir andere/bessere Lösungen diskutieren und mehr bewusst versuchen, sie umzusetzen.

Nachdem ein Artikel eine oder zwei Wochen in der Spalte "Erfolgreich" verbracht hat, werden wir ihn löschen, da er mehr oder weniger erwartet wurde (es sei denn, er wurde weiter verbessert).

Es Freitagnachmittag auch gemacht ein wenig interessanter, da es ein ziemlich Spaß Treffen waren alle teilnehmen konnten.

Answer 6

Nein, ein s Halle nicht technische Benutzergeschichten erstellen: theoretisch, und da sie in der Regel keinen direkten Wert für den Kunden bringen, haben sie sehr wenige Chancen, in einer Iteration ausgewählt werden. Den Product Owner zu überzeugen ist eine Option, um dies zu verringern, aber es gibt ein anderes Tool, das hier verwendet werden kann: slack.

Slack ist ein kleiner Teil Ihrer Iterationszeit, die diesen Verbesserungsaufgaben vorbehalten ist. Wenn während der Iteration alles gut gelaufen ist, können Sie diese Zeit für diese Verbesserungen nutzen. Auf der anderen Seite erhalten Sie eine weitere Chance, Ihre Verpflichtungen zu erfüllen, falls das Team für die Iteration zu viel versprochen hat (oder eine Aufgabe wurde unterschätzt, härter als erwartet ...)

Ein weiterer Vorteil der Verwendung von Slack ist, dass dies wird die Variation der Geschwindigkeit verringern, da Sie Ihre Verpflichtungen wahrscheinlich öfter erfüllen werden, ohne auf Überstunden zurückzugreifen.

Siehe Tom DeMarco Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency (Amazon Link) - ISBN 0767907698.

Answer 7

Ich habe hier nicht viel hinzuzufügen, aber ich finde, dass man eine Ressource haben sollte, die sich mit diesen Problemen der Umweltverbesserung beschäftigt, und die Aufgaben sollten nicht in den Burn-down-Diagrammen enthalten sein. Wenn für dieses Projekt eine zusätzliche Hardware erforderlich ist, sollte diese im fortgeschrittenen Stadium hinzugefügt und budgetiert werden. Letzten Endes sollten sich diese also nicht auf die Verteilung der Stunden auf das Gedränge auswirken, jedoch sollte jede Arbeit, die infolge dieser Probleme betroffen ist, als Rechtfertigung betrachtet werden.