Wir haben Mühe, Product Backlog Items (PBIs)/User Stories in Sprint-große Stücke zu zerlegen, da wir mehrere Schritte haben, die linear abgeschlossen werden müssen.
Jede Freigabe durchläuft mehrere Schritte:
Wir können die Entwicklung und das Testen im Allgemeinen in einem Sprint abschließen und die UAT wird im folgenden Sprint abgeschlossen. Es ist sinnvoll, die UAT-Aufgaben unter denselben PBIs zu haben, die für die Entwicklung und das Testen verwendet werden, um eine Duplizierung der PBI/User Story zu verhindern. Das Problem besteht darin, dass PBIs immer für mehr als einen Sprint geöffnet sind, was bedeutet, dass unser Sprint-Rückstand zu groß, schwer zu verwalten und schwer zu erfassen ist. Es stellt auch einen Präzedenzfall dar, wo wir anfangen zu sagen, dass das Testen in einem anderen Sprint stattfinden kann als die Entwicklung usw.
So wie ich es verstehe, haben wir folgende Möglichkeiten:
Aufgrund anderer Prozesse, die wir nicht ändern können, kann sich UAT nicht im selben Sprint wie Entwicklung und Test befinden.
Wir verwenden derzeit Visual Studio Team Services/Azure Dev Ops.
Wäre das die beste Praxis dafür?
Gibt es noch andere Optionen, die ich übersehen habe?
Ihr UAT-Prozess befindet sich derzeit außerhalb Ihres Entwicklungsteams, und Ihre Bereitstellung und Bereitstellung sind eng miteinander verbunden. Ohne die zugrunde liegenden Prozesse oder Geschäftsannahmen zu ändern, gibt es keine Möglichkeit, das, was Sie derzeit tun, „agil“ zu machen.
Sie können jedoch:
Während unterschiedliche Antworten Ihnen verschiedene potenzielle Lösungen bieten können, fallen sie normalerweise in einen dieser vier Eimer. Für welche der verfügbaren Optionen Sie sich entscheiden, ist größtenteils eine geschäftliche oder politische Entscheidung. Berücksichtigen Sie dies also unbedingt in Ihrem Entscheidungsprozess.
Danke, aber wenn wir in die Staging-Umgebung für UAT pushen, müssen wir die gesamte Veröffentlichung auf einmal pushen. Auf diese Weise können wir es wie einen Probelauf behandeln, der unsere Produktionsbereitstellung testet. Das bedeutet, dass die UAT nicht derselbe Sprint wie die Entwicklung sein kann, egal wie lange wir den Sprint machen.
Trotz der ursprünglichen Frage sind die wahren Probleme, wie in den Kommentaren beschrieben , folgende:
UAT ist ein externer Prozess.
Das UAT-Team und der Prozess gehören nicht zum Entwicklungsteam und liegen daher außerhalb der Kontrollspanne.
Lieferung und Freigabe jedes Inkrements sind eng gekoppelt.
Durch die Gleichsetzung von Lieferung mit Freigabe, insbesondere bei einer externen Abhängigkeit, kann Ihr Prozess die Definition of Done nicht innerhalb einer einzigen Iteration erfüllen.
Sobald Sie diese beiden integrierten Prozessprobleme erkannt haben, können Sie mit der Bewertung von Lösungen beginnen.
Es gibt einen großen potenziellen Pool an möglichen Lösungen für Ihre Probleme. Welche politisch akzeptabel sind und welche für Ihr Unternehmen wirtschaftlich sinnvoll sind, wird von Unternehmen zu Unternehmen stark variieren.
In keiner bestimmten Reihenfolge umfassen einige Ihrer Optionen:
Machen Sie Lean oder Kanban, nicht Scrum.
Auch wenn die Frage nicht mit Scrum getaggt war, ist der Begriff „Sprints“ im Allgemeinen ein Zeichen dafür, dass ein Team versucht, Scrum zu folgen. Wenn Sie jedoch aus institutionalisierten Gründen, die sich nicht ändern werden, routinemäßig nicht in der Lage sind, Ihre Sprint-Ziele innerhalb einer einzigen Iteration zu erreichen, ist Scrum möglicherweise nicht das richtige Framework für Sie.
UAT verinnerlichen.
Wenn UAT außerhalb des Teams ist, ist es möglich , es in das Team zu bringen. Ob Ihr Unternehmen das will oder nicht, ist eine ganz andere Frage. Es ist möglich, also lehnen Sie den Gedanken nicht ab, nur weil es nicht so ist, wie der Prozess heute aufgebaut ist.
Ein Scrum Master oder agiler Coach sollte die Geschäftsleitung aktiv über solche grundlegenden Prozessprobleme aufklären. Ermöglichen Sie dem Führungsteam, seinen Gehaltsscheck zu verdienen, indem es organisatorische Prozessprobleme löst.
Entkoppeln Sie die Bereitstellung von der Bereitstellung.
In einem agilen Framework sollte jeder Zyklus oder jede Iteration ein potenziell auslieferbares Arbeitsinkrement liefern. Sie müssen es jedoch nicht wirklich bereitstellen, nur weil es geliefert wurde.
Viele agile Teams verwenden Feature-Toggles und andere Continuous-Delivery-Praktiken, um es dem Team zu ermöglichen, Features an Sprint-Grenzen (oder sogar häufiger) bereitzustellen, ohne diese Änderungen notwendigerweise in Nicht-Entwicklungsumgebungen bereitstellen zu müssen. Indem Sie die Bereitstellung in Ihrer UAT-Umgebung aus Ihrer Definition of Done entfernen und es ihnen überlassen, Feature-Toggles zu aktivieren, wenn sie bereit sind, schaffen Sie die Möglichkeit, diese Elemente Ihres Prozesses zu entkoppeln.
Das bedeutet natürlich, dass alle Probleme, die in UAT entdeckt werden, als neue Arbeit an das Product Backlog oder die Eingabewarteschlange zurückgesendet werden müssen, um sie gemäß Ihrem agilen Framework zu schätzen, zu priorisieren und zu planen. Sie haben viel Flexibilität, wie Sie dies tun, aber das Einzige, was nicht verhandelbar ist, ist, dass Sie keinen externen Prozess haben können, der Ihren internen agilen Prozess kapert oder umgeht.
Durch die Entscheidung für separate Teams oder einen externen Testprozess muss das Management den Kompromiss akzeptieren, dass UAT und Bereitstellung Out-of-Band sind und dass die externen Prozesse nur an Iterationsgrenzen und durch den Verbrauch neue Arbeit für das Team schaffen können von Teamressourcen, die aus anderen Aktivitäten gezogen werden müssen. Auf die eine oder andere Weise gilt dies unabhängig davon, welches agile (oder sogar nicht agile) Framework Sie verwenden!
Es sind auch andere Lösungen möglich. Allen gemeinsam ist jedoch, dass Sie (das kollektive und organisatorische „Sie“) Ihre aktuellen Annahmen neu bewerten und dann überprüfen und anpassen müssen, bis Sie einen effizienteren Prozess erreicht haben. Beachten Sie, dass es auch eine legitime Geschäftsentscheidung ist , die Produktivität und die finanziellen Kosten zu akzeptieren, wenn Sie Ihr Geschäft so fortsetzen, wie Sie es heute tun , aber dass das Management nicht gleichzeitig „Weiter so wie bisher“ und „kontinuierliche Verbesserung“ haben kann. TAANSTAFL.
Tolle Frage. Es hört sich so an, als hätte Ihr Rückstand einen Engpass beim UAT-Entwicklungsstand. Scrum.org hat das Engpassproblem angegangen, indem Kanban-Praktiken in Scrum integriert wurden, um Szenarien wie das von Ihnen beschriebene äußerst transparent zu machen.
Ein ständig wachsendes Sprint-Backlog ist ein Artefakt dieser Art von Engpass, was zu einem schwer zu verwaltenden Sprint-Backlog führt, da die Liste der Arbeitselemente weiter wächst. Dies wird durch das Gesetz von Little angesprochen . Im Wesentlichen ist das grundlegende Ergebnis von Little's Law, dass es für einen bestimmten Prozess im Allgemeinen umso länger dauert, bis jedes dieser Dinge abgeschlossen ist, je mehr Dinge Sie zu einem bestimmten Zeitpunkt (im Durchschnitt) bearbeiten Durchschnitt).
Durch die Begrenzung von Work In Progress (WIP) und die Tatsache, dass Ihr Team seine eigene Definition des Workflows versteht, können Sie die Gründe für diesen Engpass aufdecken, ohne dass die Anstrengungen von Sprint zu Sprint wiederholt werden müssen. Es klingt seltsam, aber die Verlangsamung des Arbeitsablaufs durch die Begrenzung von WIP ist effektiv, um zu verstehen, warum Artikel in bestimmten Zuständen (in Ihrem Fall UAT) hängen bleiben, und gibt Ihnen die Möglichkeit, diese Probleme anzugehen, während gleichzeitig ein Mechanismus bereitgestellt wird, um die Arbeit effizient abzuschließen. Blocker und Ineffizienzen werden durch den Einsatz dieser Techniken qualifizierbar und können so leichter angegangen werden.
All dies finden Sie im 2018 Kanban Guide for Scrum Teams . Hoffe das hilft!
Sie haben eines (oder beide) der folgenden zwei Probleme:
Ich persönlich würde die erste Lösung bevorzugen. Aber wenn Sie Ihre Geschichten bereits so weit wie möglich aufgeteilt haben, dann wäre es besser, längere Sprints zu haben, als immer alles über zwei Sprints zu tragen.
Wenn wir in die Staging-Umgebung für UAT pushen, müssen wir die gesamte Veröffentlichung auf einmal pushen. [...] Das bedeutet, dass die UAT nicht der gleiche Sprint wie die Entwicklung sein kann, egal wie lange wir den Sprint machen.
Ein Ansatz, den ich kürzlich gelesen habe, bestand darin, zwei separate Definitions of Done (DoD) zu haben. Die erste (bis einschließlich UAT) würde dazu führen, dass die Geschichte abbrennt, aber auf dem Sprint-Board würde sie in einer Spalte „Warten auf UAT“ verbleiben. Das zweite DoD wäre für den Zeitpunkt, an dem es bereitgestellt wird.
dom_michalec
Jay