Wie erfolgt die Versionsnummerierung in einem agilen Projekt?

Question

Derzeit verwenden wir die folgende Version Nummerierungsschema für unsere C# WinForms Projekt:...

"Major Release" "Minor Release" "Iterationszahl" "Build-Nummer innerhalb dieser Iteration"

Wir Ich wollte in der Lage sein, die Iterationsnummer und die Build-Nummer innerhalb dieser Iteration zu identifizieren, indem ich einfach die Versionsnummer ansehe.

In der Vergangenheit hatten wir etwas wie "Major Release". "Minor Release". "Sequentielle Build-Nummer von 1.0". Zum Beispiel würde "4.0.648" bedeuten, dass es 648 Builds seit 1.0 gab - aber diese Information ist ziemlich nutzlos und anekdotisch, weshalb wir geändert haben, um Iterationen und Builds innerhalb von Iterationen widerzuspiegeln.

In Anbetracht dieser neuen agilen Versionsnummerierung haben wir nun das Problem, dass eine andere Produktgruppe Änderungen in ihrer Iteration für unser Projekt vornehmen möchte. In diesem Fall wäre die Versionsnummer nicht sinnvoll, da ihre Iterations- und Build-Nummern nicht übereinstimmen. Zum Beispiel war der letzte Build meines Projekts 1.0.5.1, der den ersten Build von Iteration 5 anzeigt. Nun möchte dieses andere Projekt, das in seiner dritten Iteration Änderungen an meinem Projekt und der Neuerstellung vornehmen möchte.

Wie soll ich mit dieser Situation umgehen? Wie erfolgt die Versionsnummerierung in Ihrem agilen Projekt?

Answer 1

Ich verfolge die Iteration der agilen Projekte, nicht die Iteration der Softwareprojekte. Wenn ein spätes Starter-Projekt nach einem anderen Projekt eintritt, wird es daher mit der aktuellen agilen Projekt-Iteration starten, und es wird keine Fehlausrichtung geben.

Es sollte nicht möglich sein, dass ein technisches Projekt außerhalb der agilen Projektdomäne mit einem Projekt innerhalb der Domäne interagiert. Das wäre ein PM-Fehler des Prozesses und sollte in allen Fällen eliminiert werden, in denen eine gemeinsam genutzte Codebasis mit Verzweigung verwendet wird, die nach Abschluss des Projekts als Bereinigungsschritt in den Hauptpfad gepatcht wird.

Answer 2

Ich ziehe Major.Minor.Build.Revision wo Build - die Zahl der öffentlichen Versionen Revision - eine Revision von Source-Version System

Answer 3

Ich ziehe den Build und Release-Prozess von dem Teamentwicklungsprozess zu trennen, so würde ich das die kaum hinzufügen Iteration, Sprint oder ähnlich der Version. Ihr Fall ist ein gutes Beispiel dafür, dass es nicht einfach ist, beide Dinge gemischt zu haben. Was passiert, wenn Sie die Methodik mitten im Projekt ändern (was auch immer der Grund sein mag)?

Als Antwort auf Ihre Frage verwenden wir seit zwei Jahren Scrum und unser Versionsformat ist das klassische Major.Minor.Upgrade.Build (wir verwenden nur das Upgrade auf Bugfixes). Am Ende ist es nicht zwingend erforderlich, die Build-Nummer zu verwenden, da Sie sie nur benötigen, um verschiedene Pakete von derselben Version zu unterscheiden, aber Sie können ein anderes Symbol verwenden, das eine Art von privater Version darstellt.

Answer 4

Persönlich denke ich, dass die Release-Version, die ich am besten gefallen habe, ist mit dem ganzen major.minor Zeug insgesamt zu beseitigen. Ich denke, dass dies nur für interne Anwendungen wirklich machbar ist, aber dafür macht es das Leben viel einfacher.

In der Regel, wenn Sie Anwendungen entwickeln, die nach innen gerichtet sind, habe ich festgestellt, dass das Unternehmen sich nie wirklich darum kümmert, welche Major/Minor-Version sie verwenden. Stattdessen neigen sie dazu, a) wann ist die nächste Veröffentlichung und b) was wird in oder aus sein - und das ist es. Versuchen Sie, die Tatsache, dass Sie an FOO-4.34.0.1-a und BAR-3.19.4.1 arbeiten, wenn niemand kümmert nur dazu dient, die Kommunikation zu erschweren.

In einer früheren Gruppe hatten wir nicht wirklich große Veröffentlichungen außer einem Projekt Kickoff. Jede Veröffentlichung war so "wichtig" wie die vorherige.

Als Ergebnis denke ich, dass sie das Vernünftige getan haben und stattdessen an das Geschäft als PROJECT_RELEASENUM kommuniziert haben. Die Versionsnummer wurde bei jeder Veröffentlichung um 1 erhöht, mit Patches wie PROJECT_RELEASENUM_PATCHNUM, die ebenfalls um '1' erhöht wurde.

Es funktioniert gut mit der Vorstellung, dass die Entwicklung als eine kontinuierliche Reihe von Sprints durchgeführt wird, bis das Unternehmen alle Funktionen hat, die sie benötigen (was in der Praxis nie passiert - es gibt immer mehr, was sie wollen). Geschäftsinhaber haben es verstanden, Entwickler konnten es kommunizieren, und es hat sich natürlich für das kontinuierliche Entwicklungsmodell, das wir hatten, gelohnt.