Wir implementieren ein Epos. Bei der Verfeinerung dieses Epos haben wir festgestellt, dass viele unserer aktuellen Funktionen davon betroffen sein werden.
Ich verstehe, dass wir beim Aufteilen von User Stories aus verschiedenen Gründen Stories vertikal aufteilen sollten.
Einige der Techniken, um dies zu tun, sind
Wenn wir unsere Stories auf diese Weise aufteilen, stellen wir jedoch fest, dass bei der Bereitstellung einiger User Stories andere vorhandene Funktionen nicht funktionsfähig bleiben. Wie gehen wir mit dieser Situation um?
Ich denke derzeit an 3 Möglichkeiten
Wie sollen wir vorgehen?
Sehr interessantes Problem. Alle drei davon sind potenzielle Optionen, aber die dritte scheint die wahrscheinlichste zu sein. Ich konnte den ersten sehen, wenn es aus irgendeinem Grund einen geschäftlichen Nutzen hatte, Leute für eine Weile daran zu hindern, eine Reihe von Funktionen zu verwenden (z. B. wenn eine Vorschrift die Verwendung dieser alten Funktionen inakzeptabel machte). Die zweite könnte in die Kategorie "No Harm No Foul" fallen, wenn Sie nicht in die Produktion gehen, aber dann kein Inkrement von veröffentlichbarem Code haben. Ich würde dies nur tun, wenn die Kosten für Nr. 3 so hoch wären, dass dies die einzige vernünftige Geschäftsoption wäre.
Also weiter zu Nr. 3: Dies ist im Grunde ein Feature-Toggle. Sie senden Ihre App auf den alten Pfad, es sei denn, diese Funktion wird mit einer Konfigurationseinstellung oder einem im Browser gesendeten Attribut aktiviert. Wenn Sie bereit sind, vollständig umzuschalten, schalten Sie die neue Funktion dauerhaft ein und löschen die alten Sachen danach. Ein guter Feature-Toggle lässt zu, dass beide Pfade erfolgreich funktionieren. Dies erfordert jedoch einen zusätzlichen Aufwand. Dieser Aufwand kann gering sein (z. B. wenn Sie diesen Ansatz bereits verwenden und alles mit dieser Option erstellt haben) oder sehr teuer (z. B. wenn Sie eine komplexe 30 Jahre alte Mainframe-App haben). Ich habe noch nie einen Fall gesehen, in dem es unmöglich war, aber ich habe gesehen, dass es unerschwinglich teuer war, und da kommt Nr. 2 ins Spiel.
Darauf gibt es keine absolut richtige Antwort. Dies hängt von Ihren Geschäfts-/Zeitplan-/PO-Einschränkungen und Prioritäten ab.
Deaktivieren Sie alle vorhandenen Funktionen im Zusammenhang mit dem Epos
Dies ist gut, wenn Sie entweder a) sicher sind, dass Sie kein Inkrement veröffentlichen müssen, bis das Epic fertig ist, oder b) es keinen wesentlichen Verlust des Geschäftswerts durch die vorübergehende Deaktivierung der Funktionalität gibt
Lassen Sie sie sein und sie sind nicht funktionsfähig, ist außerhalb des Umfangs (bekanntes Problem, wird
in einer zukünftigen Version behoben)
Das ist gut, wenn Sie sicher sind, dass Sie kein Inkrement veröffentlichen müssen, bis das Epic fertig ist.
Lassen Sie die Funktionen parallel existieren und deaktivieren Sie die alte, sobald die neue vollständig ist
Dies ist der risikoärmste Weg, wenn Sie den Codepfad mit einem Flag auswählen. Auf diese Weise können Sie das alte für die Entwicklung deaktivieren und das neue deaktivieren, wenn Sie es veröffentlichen müssen, bevor Sie fertig sind.
Eine andere Möglichkeit wäre, das Epic erneut aufzuteilen, um zu sehen, ob Sie dieses Problem vermeiden können. Zumal Sie sagen, dass Sie erst nach der Aufteilung erkannt haben, dass die bestehenden Funktionen betroffen sein würden, könnte es sich lohnen, mehr Zeit damit zu verbringen, nach einer besseren Lösung zu suchen.
An dieser Stelle würde ich mich jedoch mit meinen Stakeholdern beraten, insbesondere mit denen, die Entscheidungen über den Zeitplan treffen. Wenn sie mit einer der drei von Ihnen vorgeschlagenen Optionen einverstanden sind, großartig; Wenn sie möchten, dass Sie einen anderen Split versuchen, fragen Sie sie, wie viel Zeit Sie noch damit verbringen sollten, dies zu versuchen, bevor Sie zu dem Schluss kommen, dass es keine Möglichkeit gibt.