Ich bin der Produktmanager für zwei Anwendungssätze meines Unternehmens und bin auf einige Schwierigkeiten gestoßen, als ich versuchte, zukünftige Versionen zu verwalten und sie am besten zu verschieben. Wenn ich Version 2.2 derzeit in der Entwicklung habe, habe ich die Versionen 2.3-2.5 bereits in Bugzilla geplottet. Wir planen jedoch jetzt, einige Elemente aus 2.2 zu verbessern und ein paar andere kleine Elemente hinzuzufügen, um eine schnelle Veröffentlichung mit dem Namen 2.3 zu erstellen.
Wenn ich weiterhin meinem aktuellen System folge, muss ich alle 2.5-Aufgaben auf 2.6, 2.4 auf 2.5 und 2.3 auf 2.4 aktualisieren.
Ich habe darüber nachgedacht, etwas wie Future.10, Future.20, Future.30 zu machen – das würde mir erlauben, Future.15 oder irgendetwas dazwischen hinzuzufügen. Ich habe das Gefühl, dass dies ein Problem ist, das bereits gelöst wurde, aber ich weiß einfach nicht, wie. Gibt es eine bessere, allgemeinere Möglichkeit, die Veröffentlichungsreihenfolge zu planen, bei der ich nicht jede einzelne zukünftige Veröffentlichung anpassen muss, wenn wir eine Veröffentlichung hinzufügen oder Dinge verschieben?
Zur Verdeutlichung: Bei dieser Frage geht es ausschließlich um die Organisation mehrerer Gruppen von Funktionen ("ein Release") vor der Entwicklung und um die beste Möglichkeit, Releases neu zu ordnen, ohne jedes Mal alle Aufgaben zu ändern, wenn ich mich um die beabsichtigte Reihenfolge ändere.
Eines der großartigen Dinge an Softwareentwicklungsversionen ist, dass Sie sie beliebig benennen und jedem beliebigen Muster folgen können, solange sie konsistent und im Kontext Ihres eigenen Workflows sinnvoll sind. Sie sehen dies häufig bei der Versionsnummerierung, wo im Allgemeinen die Zahlen zwischen den Punkten und Bindestrichen (z. B. 2.4.1 oder 5.4 oder 1.3-Patch) für verschiedene Organisationen unterschiedliche Dinge bedeuten.
Ihr spezielles Problem, was mit „schnellen“ Releases zu tun ist, wird oft durch die Verwendung der major.minor[.build[.revision]]Nummerierung (oder einfach ) angesprochen major.minor[.revision]. In diesem Fall würde Ihre Projektplanung um major(2) und minor(3, 4, 5) herum liegen, aber den Platz (in die Dokumentation, den Arbeitsablauf usw.) für Überarbeitungen (1, 2 usw.) zwischen diesen Nebenversionen Dies ist ein Bereich, in dem sich das Gespräch mit Ihrem technischen Leiter als hilfreich erweisen kann, da die Entwickler höchstwahrscheinlich in einem Verzweigungsmodell innerhalb des Software-Versionskontrollsystems, das gut zu dem passt, was Sie mit dem Plan und der Dokumentation tun müssen.
Es gibt Richtlinien und Modelle für bestimmte Arten der Versionierung – eine davon ist insbesondere die semantische Versionierung , die sehr klare Richtlinien für alle möglichen Änderungen während des Entwicklungsprozesses enthält (z. B. „Fehlerbehebungen, die sich nicht auf die API auswirken, erhöhen den Patch Version, abwärtskompatible API-Ergänzungen/Änderungen erhöhen die Nebenversion und abwärtsinkompatible API-Änderungen erhöhen die Hauptversion.") Ich sage nicht, dass Sie diesen Weg gehen (obwohl ich ihn persönlich sehr nützlich finde), nur dass es einen oder mehrere gibt als ein paar Orte, an denen alle bewährten Verfahren dargelegt sind und von Arbeitsgruppen leicht befolgt werden können.
Ich habe das Gefühl, dass dies ein Problem ist, das bereits gelöst wurde, aber ich weiß einfach nicht, wie. Gibt es eine bessere, allgemeinere Möglichkeit, die Veröffentlichungsreihenfolge zu planen, bei der ich nicht jede einzelne zukünftige Veröffentlichung anpassen muss, wenn wir eine Veröffentlichung hinzufügen oder Dinge verschieben?
Eigentlich gibt es einen Weg und er heißt One Track . Das bedeutet, dass Sie nur eine Version haben und immer diese Version bereitstellen und keine unterschiedlichen Versionen pflegen. Es mag ein bisschen weit hergeholt klingen, aber tatsächlich ist es möglich. Ich habe für ein Unternehmen gearbeitet, das genau das gleiche Problem hatte, das Sie jetzt haben, aber sie haben eine eingleisige Lösung eingeführt. Es gab viele Gespräche über Kunden, Versionen und Lieferungen. Nach einer Weile – ein paar Monaten – verstand der Kunde, dass es etwas Gutes für ihn war.
Mein Vorschlag ist also, nur einen Track zu haben und immer von diesem Track zu liefern. Langfristig lohnt es sich.
Ich habe keine andere Lösung auf dem Markt gesehen. Die Situation mit Ihrem jetzigen Vorgehen ist vollkommen nachvollziehbar. Kunden möchten nicht wegen eines Fixes oder einer ausgefallenen Funktion upgraden, weil sie denken, dass es sie Geld kosten wird. Versuchen Sie, mit Ihren Kunden ins Gespräch zu kommen und prüfen Sie, ob eine eingleisige Lösung für sie funktionieren könnte.
Langfristige Pläne können sich immer ändern – ein Umtausch ist daher fast unvermeidlich. Ich habe festgestellt, dass es aus einer internen Perspektive einfacher ist, über Phasen einer Veröffentlichung zu sprechen – dh 2.2 Phase I, 2.2 Phase II usw. Semantik, die ich kenne (2.2.1?, 2.2.2?), aber es ist einfacher, Phasen zusammenzuführen und zu pushen als Versionen, zumindest ist es einfacher, mit der Verwaltung davonzukommen.
Dies hilft jedoch nicht bei in Schrumpffolie verpackten Produkten (dh solchen, die eher extern an Kunden als intern für das Geschäft geliefert werden). In diesem Fall ist es manchmal einfacher, eine Liste von Erweiterungen zu haben als festgeschriebene Versionen – damit meine ich, ein Lieferobjekt nur dann mit einem Release zu verknüpfen, wenn es eine eindeutigere Entscheidung gibt. Diese „Leistungen“ müssen nicht schwebend bleiben, sie können gegen eine Zeitleiste oder eine Abhängigkeitsliste aufgetragen werden. EG-Version 2.2 wird enthalten....bla bla bla....zukünftige Versionen 2.3 Ende Q3 2012, 2.4 Q2 2013.....perf. Erweiterung 6 in Dev Q2/12, Win2008-Version in Dev Q3/12, OSX-Port Q3/12, Unix-Port Q4/12 usw
Natürlich hängt all dies wirklich von den Richtlinien Ihres Unternehmens und der Art und Weise ab, wie sie liefern (und an wen).
Verwenden Sie keine Zahlen oder Namen, die eine semantische Bedeutung haben. Denken Sie an die Google Android-Versionen. Ich glaube, eines hieß Ice Cream Sandwich. Durch die Verwendung generischer Benennungen können Sie Releases neu priorisieren, ohne sich Gedanken über die Neuanordnung von Nummern machen zu müssen. Future.10...n funktioniert, aber Sie sind immer noch etwas durch die Punktzahl eingeschränkt. Versuchen Sie also, mit generischen Release-Benennungen zu entwickeln, dann können Sie das Release bei der Veröffentlichung mit der Versionsnummer des öffentlichen Releases umbenennen.
Wie wäre es, wenn Sie diese von Ihnen erwähnte Schnellveröffentlichung 2.2.1 nennen würden? Oder gibt es irgendwelche äußeren Beschränkungen, die es dir nicht erlauben?
Andreas Klar