Jira Cloud Dokumentation

Wie Veronica Advanced Roadmaps nutzt - projektübergreifende Planung



Diese Seite bezieht sich auf die erweiterten Planungsfunktionen, die nur in Jira Software Cloud Premium und Enterprise verfügbar sind. 

Wir haben einen eigenen Bereich für die Dokumentation der Projekt-Zeitleiste, die in allen Jira Software Projekten enthalten ist. Hier geht's zur Dokumentation für Roadmaps auf Projektebene in Jira Software.

In den anderen Abschnitten dieses Leitfadens haben wir alle Instrumente behandelt, die dir in deinem Plan zur Verfügung stehen. Da der Plan aber sehr offen ist, kann es schwierig sein, all diese Konzepte miteinander zu verknüpfen.

Um zu zeigen, wie du alle verfügbaren Funktionen kombinieren kannst, schauen wir uns an, wie die Planer bei Veridian Dynamics Pläne verwenden.


Wer ist Veronica?

Veronica ist die Leiterin der App-Entwicklung und Feature Delivery bei Veridian Dynamics. Das Unternehmen möchte mehrere neue Funktionen hinzufügen, darunter einen QR-Reader, eine neu gestaltete Benutzeroberfläche und eine Möglichkeit, Upgrades zu kaufen. Damit die Arbeit rechtzeitig fertig wird, wird sie auf drei Teams aufgeteilt: das ADR-Team, das IOS-Team und die Frisky Dingos. Jetzt liegt es an Veronica, einen Zeitplan zu koordinieren.


Wie Veronica ihren Plan aufstellt

Veronica beginnt damit, einen Plan mit den Boards zu erstellen, die das ADR-Team, das IOS-Team und das Frisky Dingo-Team als Arbeitsgrundlage verwenden:



Dann fügt sie alle drei Teams zu ihrem Plan hinzu und ordnet die Vorgänge den richtigen Teams zu:



Als Nächstes muss Veronica ihre Vorgangshierarchie so konfigurieren, dass sie für alle Teams gleich funktioniert. Im Moment verwendet nur das ADR-Team die Ebenen über Epic (wie Legend und Odyssey). Sie muss diese Stufen zu den Vorgängen des IOS-Teams und der Frisky Dingos hinzufügen. Dazu geht sie auf die Seite Issue Type Scheme und fügt die bereits konfigurierten Vorgangstypen zu den Schemata dieser Teams hinzu:



Nach der Konfiguration erstellt Veronica auf ihrer Roadmap einen Vorgang auf der Ebene Odyssey, der mit dem Jahresziel der Abteilung übereinstimmt: Continued innovation and refinement. Dann fügt sie einen untergeordneten Vorgang auf der Ebene der Legende mit dem Namen Create new version of app hinzu:



Auf diese Weise richtet Veronica ihren Plan auf die übergeordneten Ziele des Unternehmens aus und wird in der Hierarchieebene immer detaillierter und umsetzbarer. Das Odyssey-Ticket ist etwas, unter dem andere Teams innerhalb ihrer Organisation ihre Arbeit einordnen können, so dass die Führungskräfte die Möglichkeit haben, Projekte nach eigenem Ermessen zu bearbeiten.


Wie Veronika ihren Plan erstellt

Zu Beginn erstellt Veronica Epics, die sich an größeren Abschnitten konkreter Arbeit für ihre Teams orientieren: ein Epic für die Backend-Entwicklung, ein weiteres für jedes Feature, eines für die Frontend-Arbeit und so weiter. Sobald sie ihre Epics erstellt hat, passt sie ihre Hierarchieeinstellungen so an, dass sie Legenden und Odysseen vorerst ausschließt, um sich auf die Arbeit zu konzentrieren, die sie planen muss.

Innerhalb jedes Epics erstellt und schätzt sie Aufgaben auf Story-Ebene, die die tatsächlich zu erledigende Arbeit darstellen, und weist diese den Teams zu. Im Menü Ansichtseinstellungen rollt sie Termine und andere Werte auf und färbt ihre Zeitplanleisten entsprechend der Teamzuweisung ein:



Als nächstes ordnet Veronica ihren Vorgängen Abhängigkeiten zu. Sie teilt dem Plan mit, dass das Epic Back End Development erst beginnen kann, wenn alle Arbeiten im Epic Back End Exploration abgeschlossen sind. Im Moment ist dies nur ein Hinweis auf die Reihenfolge der Planung, aber wenn die Arbeit beginnt, zeigt ihr Plan eine Warnung an, wenn diese Abhängigkeit aus dem Ruder gerät. 

Die letzte Planungsstruktur, die Veronica einbeziehen möchte, sind Releases. Sie wird einzelne Projekt-Releases als Meilensteine und ein abschließendes projektübergreifendes Release als endgültiges Release der neuen App verwenden. Sie geht auf den Tab Releases und erstellt drei projektspezifische Releases (eines für jedes Team) sowie ein projektübergreifendes Release, das alle umfasst:



Wenn sie nun zu ihrem Plan zurückkehrt, werden ihre Releases auf ihrer Zeitleiste markiert. Während ihr Projekt voranschreitet, kann sie die Fortschritte auf dem Weg zu diesem Release verfolgen:




Der letzte Release auf ihrer Zeitleiste ist der projektübergreifende Release, dessen Markierung sich mit dem letzten Release deckt:



Anhand dieses Plans kann Veronica ihren vorläufigen Zeitplan nun der Geschäftsführung und den Stakeholdern des Produktteams vorstellen. Wenn der Plan genehmigt wird, muss Veronica ihre Änderungen nur noch mit der Schaltfläche Review changes (Änderungen überprüfen) oben rechts speichern, und alle Vorgänge, die sie in ihrem Zeitplan vorgenommen hat, werden automatisch in den Boards der Teams angezeigt und können bearbeitet werden.


Andere Beispiele:


Weitere Artikel:





Zurück zum Hauptmenü   Nächstes Thema  







Confluence

Diese Seite wurde zuletzt am 05.05.2024 geändert.