Viele Issue-Tracker unterstützen sogenannte "Meilensteine". Ich habe nie eine Verwendung für sie gefunden. Es scheint, dass Meilensteine ​​nur dann nützlich sind, wenn Sie große, geplante Pushs durchführen, aber nicht, wenn Sie neue Funktionen und Fehlerbehebungen einführen, sobald diese abgeschlossen sind.

Wann / wie würden Sie Meilensteine ​​nutzen, um eine agile Entwicklung zu organisieren?

Einige agile Teams verwenden sie, um mit dem Kunden zu kommunizieren, wenn er mit einer neuen Version der Software rechnen kann (auch wenn diese Version unvollständig ist). Auf diese Weise kann der Kunde die Migration auf die neue Version planen, bevor sie veröffentlicht wird.

Für eine Software, die auf agile Weise entwickelt und alle 6 Monate veröffentlicht wird , könnten beispielsweise die folgenden Meilensteine ​​sein.

Alpha 1 - 19. Dezember

Der erste Satz von Funktionen kommt an, normalerweise fehlerhaft. Dies ist nützlich, um sie auszuprobieren und Feedback zu geben

Alpha 2 - 23. Januar

Nächste Funktionen sowie einige Korrekturen für das Feedback in Alpha

Beta 1 - 27. Februar

Alle Funktionen für die aktuelle Version sind vorhanden, und bis zur endgültigen Veröffentlichung wird niemand hinzugefügt. Neue Entwicklung wird in der nächsten Version sein. Sie können dennoch eine kleine Änderung an der vorhandenen vorschlagen.

Final Beta - 27. März

Das Verhalten der Funktion ist vollständig eingefroren, sofern kein kritischer Fehler gefunden wird. Nur Fehler wird behoben.

Release Candidate - 10. April

Die endgültige Version wird veröffentlicht. Hier soll kein Bug gefunden werden. Wenn einige gefunden werden, wird ein neuer Release-Kandidat erstellt.

Endgültige Veröffentlichung - 17. April

Die unterstützte Version wird für die breite Öffentlichkeit freigegeben, da für den Veröffentlichungskandidaten kein Fehler gefunden wurde

(Hinweis: Ich habe hier nicht genau die Ubuntu-Semantik befolgt)

Mit diesem Release-Plan kann ein Kunde vorausplanen. Wenn eine neue Funktion wirklich erwartet wird, kann er sie während der Alpha-Phase testen, um sicherzustellen, dass sie den Anforderungen entspricht. Programmierer können bereits in der Beta-Phase mit der neuen Funktion experimentieren. Regressionstests können während der Release-Kandidatenphase beginnen.

Zu wissen, wann die Software veröffentlicht wird und was sie enthalten wird, ist für viele Benutzer von enormer Bedeutung. Mithilfe von Meilensteinen können Sie wissen, was wann passieren wird . Die agile Denkweise ist immer noch vorhanden, was sich in der Tatsache manifestiert, dass der Funktionsumfang vor einem bestimmten Datum variabel ist . Dies ist anders als beim Wasserfall , bei dem Sie sowohl die Funktionen als auch das Veröffentlichungsdatum planen . Und natürlich ist die nächste Version nicht eingestellt, wieder anders als bei der Wasserfallmethode.

Um Ihre Frage zu beantworten: In Agile werden Meilensteine ​​verwendet, um anzuzeigen, wann wichtige Entscheidungen und Maßnahmen getroffen werden , auch wenn sich diese Maßnahmen und Entscheidungen selbst ändern können.

Ich denke, der Zweck des Meilensteins ist es, einen Überblick über das Release / Feature-Kandidatenprogramm / die App (oder alles andere, was das Team entwickelt) zu erhalten.

Es könnte für Entwickler / Arbeiter nützlich sein:

Ich kann mir ein Problemverfolgungssystem mit vielen Aufgaben, Bugfixes, Funktionen usw. vorstellen. Es hat ein Meilensteinfeld. Ich denke, wenn Ihr Team zwei Meilensteine ​​hat und nur einer Ihren Kunden bevorzugt, beginnt Ihr Team damit, diese Aufgabe zu erledigen oder diese Fehler zu beheben oder diese Funktionen zu entwickeln, die mit diesem Meilenstein gekennzeichnet sind.

Es könnte für Manager hilfreich sein:

Das ist sehr wichtig, welche Version für die Produktionsumgebung des Kunden freigegeben wird. In diesem Fall ist der Meilenstein die Freigabe für die Produktionsumgebung. Der Meilenstein könnte jedoch ein Paket von Funktionen sein.

Es könnte für den Kunden hilfreich sein:

Möglicherweise möchte der Kunde dieses Programm oder die Bugfixed-Version des Programms oder neue Programmfunktionen für eine andere Person / Organisation anzeigen. Der Kunde benötigt also eine stabile Programmversion. Ich denke, wenn das Programm diesen Meilenstein erreicht, wäre es stabil und lösbar.

Wenn der Kunde, die Manager und die Mitarbeiter Fehler, Einnahmen und Funktionen im Issue-Tracker überprüfen, ist es meiner Meinung nach besser, einen Meilenstein von ihnen zu kennen.

Wenn Sie ein Entwicklungsprojekt starten - unabhängig von der Methodik -, sollten Sie immer einen groben Plan haben, den Sie befolgen, über die "Must-Have" -Funktionen, Kernfunktionen, "wirklich wichtigen" Funktionen, die Sie entwickeln möchten und in denen Auftrag. Idealerweise haben Sie auch eine Vision über die Realisierungszeit. Das Aufschreiben dieses Plans in Form von Meilensteinen macht ihn für alle am Projekt Beteiligten transparent.

Bei jeder Art von realem Projekt muss dieser Plan von Zeit zu Zeit an die Realität angepasst werden. Vielleicht muss man Features verschiedenen Meilensteinen neu zuweisen, manchmal identifiziert man Dinge, die weniger wichtig sind als gedacht, manchmal muss man Ihrem Entwicklungsplan einige fehlende Anforderungen / Features hinzufügen, und manchmal muss man die Liste der Meilensteine ​​selbst ändern . Meiner Meinung nach besteht der Hauptunterschied zwischen einem "Wasserfall" - und einem "agilen" Projekt darin, dass Sie in einem agilen Projekt dem Kunden gegenüber ehrlich sind, dass ab Tag 1 Anpassungen erforderlich sind. In Wasserfallprojekten sind keine Mechanismen zum Ändern des Projekts vorhanden Planen Sie, bevor das Produkt "fertig" (und wahrscheinlich fehlerhaft) ist. In agilen Projekten

Es gibt auch einen Unterschied, zu welchem ​​Zeitpunkt Sie die wichtigsten Details der Anforderungen für einen Meilenstein analysieren. Wasserfallprojekte neigen dazu, jedes Merkmal jedes Meilensteins im Voraus zu stark zu analysieren. In agilen Projekten analysieren Sie normalerweise nur ein Merkmal des nächsten Meilensteins eingehend.

Daher würde ich sagen, dass insbesondere bei agilen Projekten ein Meilensteinplan den Stakeholdern hilft, zu verstehen, dass die Entwicklung nicht völlig willkürlich oder zufällig ist und dass Sie immer noch einem Gesamtplan folgen.

Eine andere Frage ist, ob Sie die Funktion "Meilensteine" Ihres Issue-Trackers benötigen. Ein Meilensteinplan ist normalerweise nur ein Dokument in Ihrem bevorzugten Dokumentformat, sodass Sie es jedem Stakeholder Ihres Projekts problemlos anzeigen können. Sie müssen selbst entscheiden, ob es Ihnen Vorteile bringt, die Meilensteine ​​in Ihr Problemverfolgungssystem zu integrieren, oder ob Sie es lieber auf eine ganz andere Art und Weise pflegen möchten.

Sie haben bereits Ihre eigene Frage beantwortet. "... nützlich, wenn Sie große, geplante Pushs ausführen ..."

Da Sie nur Wartungs- und Aktualisierungsarbeiten durchführen, sind Meilensteine ​​nicht sehr sinnvoll. Außer : Selbst wenn Sie auswählen, welche Funktionen wiederholt werden sollen, ist es schön, einen Überblick darüber zu haben, wohin alle Funktionen führen, damit die agile Entwicklung nicht außer Kontrolle gerät und sich das Projekt zusammenhängend anfühlt.

Meilensteine ​​geben einen Punkt, um zu messen, wie gut langfristige Ziele erreicht werden, und einen Punkt, um anzuhalten und zu überlegen, in welche Richtung die zukünftige Iteration folgen sollte.

Meilensteine ​​sind nützlich für die Kundenbeteiligung, z. B.: Bei der Entwicklung eines Prototyps kann das Team anhand eines Meilensteins wissen, welche Arbeitselemente ausgeführt werden müssen, damit ein Prototyp zur Präsentation bereitsteht.

Es ist auch nützlich für evolutionäre Implementierungen und bietet einen Prüfpfad für die Entwicklung. In einem Team, in dem ich zuvor gearbeitet habe, hat der Teamleiter das Haupt-Repository verlassen, um eine Version des Produkts an diesem bestimmten Meilenstein zu halten. Dies ermöglichte es uns, dem oberen Management die Entwicklung des Produkts zu zeigen und das Budget zu rechtfertigen.

Jedes Feature ist per Definition ein Meilenstein

Eine Aktion oder ein Ereignis, das bzw. das eine wesentliche Änderung oder Entwicklungsstufe kennzeichnet

Die Nützlichkeit der Verfolgung einzelner oder Gruppen von Meilensteinen für Ihr Projekt, Ihr Team und Ihren Kunden ist in erster Linie eine Frage des Geschmacks / Stils

Einige Teams / Kunden kreuzen gerne jeden Tag Meilensteine ​​an, andere geben sich damit zufrieden, dies weniger häufig zu tun

ADDENDUM: Das Schlüsselwort ist "signifikant" - was subjektiv ist. Ihre Meilensteine ​​können variieren. :) :)