Releases in Softwareprojekten – Versionen planen und ausliefern
Ein Release ist eine benannte Version, etwa v2.1.0, die die Issues und Epics bündelt, die Sie gemeinsam ausliefern wollen. Im Tab Releases legen Sie ein Zieldatum fest, beobachten den Fortschritt, erkennen Risiken früh und sperren die Version, sobald sie ausgeliefert ist.
Auf einen Blick
| Was es ist | Eine Version, die die gemeinsam auszuliefernde Arbeit sammelt |
| Wo Sie es finden | Öffnen Sie ein Softwareprojekt, dann den Tab Releases |
| Wer erstellen, bearbeiten und als veröffentlicht markieren kann | Inhaber/Admin und Projektmanager |
| Wer Arbeitselemente hinzufügen oder entfernen kann | Jedes Mitglied, das kein Gast ist |
| Gäste | Können den Tab sehen, aber nichts ändern |
| Tarif | In jedem Tarif gleich |
Details zu den Rollen finden Sie unter Berechtigungen und Tarife.
So erstellen Sie ein Release
- Öffnen Sie das Softwareprojekt und wählen Sie den Tab Releases.
- Klicken Sie auf Neues Release.
- Geben Sie einen Versionsnamen ein. Er ist Pflicht, bis zu 50 Zeichen lang und im Projekt eindeutig (Groß- und Kleinschreibung gelten als gleich). Das Feld schlägt die nächste Nebenversion vor, zum Beispiel v2.2.0 nach v2.1.0, oder v1.0.0 für das erste Release.
- Wählen Sie ein Zieldatum, falls Sie eines haben.
- Fügen Sie eine Beschreibung hinzu (bis zu 1.000 Zeichen), etwa „Was wird in dieser Version ausgeliefert?“.
- Wählen Sie optional schon jetzt Arbeitselemente im Bereich Arbeitselemente aus.
- Klicken Sie auf Release erstellen.
Wird das Release erstellt, die Arbeitselemente lassen sich aber nicht hinzufügen, sehen Sie eine entsprechende Meldung. Öffnen Sie das Release und fügen Sie sie erneut hinzu.
So fügen Sie Issues oder Epics zu einem Release hinzu
- Klicken Sie im Tab Releases auf den Namen des Releases, um seine Details zu öffnen.
- Klicken Sie auf Arbeitselemente hinzufügen.
- Nutzen Sie den Tab Arbeitselemente oder den Tab Epics, um ein ganzes Epic hinzuzufügen. Suchen Sie nach Schlüssel, Zusammenfassung oder Epic-Name.
- Wählen Sie ein Epic aus, wählt Worklenz die zugehörigen, geeigneten Arbeiten aus. Klappen Sie das Epic auf, um die Liste zu prüfen oder Einträge abzuwählen, die Sie auslassen möchten.
- Prüfen Sie unten die Anzahl ausgewählt und klicken Sie auf Ausgewählte hinzufügen.
Sie können bis zu 500 Elemente in einer Aktion hinzufügen. Um ein Element herauszunehmen, nutzen Sie Aus Release entfernen in seiner Zeile. Sie können auch das Feld Release im Detailbereich eines Issues setzen, wie unter Backlog und Issues beschrieben.
Epics ohne geeignete Arbeit werden als nicht verfügbar angezeigt.
Was bedeuten die Zuversichts-Etiketten?
Jedes Release erhält ein Etikett, das zeigt, wie wahrscheinlich es termingerecht ausgeliefert wird. Die Tabelle der Releases zeigt außerdem Zieldatum, Fortschritt und die Anzahl kritischer Bugs.
| Etikett | Was es bedeutet |
|---|---|
| In Planung | Noch keine Arbeitselemente oder kein Zieldatum. Fügen Sie beides hinzu, um die Zuversicht zu verfolgen. |
| Im Plan | Keine kritischen Bugs oder Blocker, und der Fortschritt hält das Tempo. Ein zu 100 % fertiges Release zählt immer als im Plan. |
| Gefährdet | Offene kritische Bugs, blockierte Arbeit oder weniger als 80 % Fertigstellung innerhalb einer Woche vor dem Ziel. |
| Überfällig | Das Zieldatum ist verstrichen, und es ist noch Arbeit offen. |
| Veröffentlicht | Diese Version wurde ausgeliefert. |
So markieren Sie ein Release als veröffentlicht
- Öffnen Sie die Release-Details.
- Klicken Sie auf Als veröffentlicht markieren.
- Lesen Sie die Bestätigung Release {name}?. Ist manche Arbeit nicht erledigt, steht dort, wie viele Arbeitselemente nicht erledigt sind.
- Bestätigen Sie mit Als veröffentlicht markieren.
Beispiel
Ihr Team liefert v2.1.0 in zwei Wochen aus. Sie erstellen das Release mit diesem Zieldatum, fügen das Epic „Reporting“ hinzu und wählen zwei Stretch-Stories ab. Acht Tage später springt das Etikett auf Gefährdet, weil noch ein kritischer Bug offen ist. Sie beheben den Bug, das Etikett kehrt zu Im Plan zurück, und am Release-Tag klicken Sie auf Als veröffentlicht markieren.
Grenzen und Wissenswertes
- Ein Release-Name darf sich innerhalb desselben Projekts nicht wiederholen.
- Berichte können nach Release gruppieren. Siehe Software-Berichte.
- Sehen Sie Neues Release nicht, sind Sie wahrscheinlich weder Inhaber/Admin noch Projektmanager.
Best Practices
- Prüfen Sie in der Bestätigung die Zahl der nicht erledigten Arbeitselemente, bevor Sie ein Release als veröffentlicht markieren, denn veröffentlichte Versionen werden schreibgeschützt.
- Legen Sie ein Zieldatum fest und fügen Sie Arbeitselemente hinzu, sobald Sie das Release erstellen, denn das Etikett bleibt In Planung, bis es beides hat.
- Fügen Sie ein ganzes Epic hinzu und wählen Sie die Stretch-Einträge ab, denn die Auswahl eines Epics wählt die geeigneten untergeordneten Arbeiten aus, und einzelne Issues können Sie ausschließen.
- Geben Sie jeder Version einen eigenen Namen, denn ein Name darf sich innerhalb eines Projekts nicht wiederholen, und Groß- und Kleinschreibung gelten als gleich.
- Reagieren Sie früh auf das Etikett Gefährdet, denn offene kritische Bugs, blockierte Arbeit oder weniger als 80 % Fertigstellung innerhalb einer Woche vor dem Ziel lösen es aus.