Jira-Sprints vs. MS Project-Vorgänge
Wer aus dem klassischen Projektmanagement kommt und umschwenkt auf agile Methoden steht meist vor dem Problem Evolution oder Revolution.
Auch wenn die Revolution oft der bessere Weg scheint, ist es doch vielfach so, dass der Umstieg nur in kleinen Schritten passiert. Somit hält man an der alten Welt fest, die ja nicht nur schlecht war, will aber von den modernen Ansätzen ebenso profitieren.
Die alte Welt besteht bei Vielen aus einem Projektplan, der von einem Projektleiter geführt wird. Dieser plant Vorgänge, weist diese seinem Projektmitgliedern zu; diese melden ihre geleistete Arbeit zurück und somit wird der Projektfortschritt verfolgt. Allein schon wegen der Abrechnung von geleisteter Arbeit auf Kostenträger will man dieses Vorgehen nicht unbedingt abschaffen.
Die Ansätze agiler Projektmanagement-Methoden lassen aber immer mehr Entwicklungsabteilungen erkennen, dass die Feinplanung besser im Team stattfinden sollte. Der Projektleiter plant nach wie vor die großen Meilensteine und Abhängigkeiten zu Lieferanten und Parallelprojekten. Das Planen von Vorgängen mit wenigen Stunden Aufwand ist aber eine Sisyphus-Arbeit, die sich keiner gerne antut.
Zudem hat das Team das Detailwissen über die technischen Arbeitsschritte, die eigentlich zu tun sind. Führt man Scrum ein, stellt sich nun schnell die Frage, wie denn das Mapping zwischen klassichen Projektplan und den Scrum-Elementen wie Story und Epic (große Story) aussehen kann. Schließlich müssen die Teammitglieder nach wie vor ihre Stunden auf die klassischen Vorgänge zurückmelden, auch wenn sie sich eigentlich in ihrer agilen Welt befinden. Das beigefügte SysML-Blockdefinitionsdiagramm versucht, einen Ansatz aufzuzeigen.
Gehen wir davon aus, dass wir einen Software-Integrationsplan beschreiben, in dem wir Releases definieren, sagen wir vielleicht drei pro Jahr. Die Funktionale Analyse haben wir durch die Identifikation von Use Cases mit zugehörigen Aktivitätsdiagrammen abgeschlossen. Für einen ersten Versuch wählen wir eine 1:1-Beziehung zwischen Use Cases und Epic. Eine Epic brechen wir runter in mehrere Stories, die den geplanten Releases zugeordnet werden. Wir verwenden das Tool Jira, das von Versionen spricht. Wir haben somit in Jira drei Versionen pro Jahr entsprechend der Releaseplanung unseres Software-Integrationsplans.
Bis zu einem Release gibt es diverse Sprints, in denen Stories abgearbeitet werden. Eine Epic kann sich aber grundsätzlich über mehrere Releases hinziehen. Hier ist zu diskutieren, ob man die Einschränkung macht, dass eine Epic grundsätzlich zwischen zwei Releases zu vollenden ist. Dann lässt sich der Projektplan in Microsoft Projekt auf Epic-Ebene planen. Jeder Entwickler weiß, an welcher Story er gerade arbeitet, und somit auch, an welcher Epic. Somit kann er seine Stunden ohne Problem dem entsprechenden Vorgang im Projektplan zuordnen.
Falls man Epics über mehrere Releases zulässt, muss man im Projektplan eine Epic noch aufteilen, auf mehrere Vorgänge. Diese Teil-Epics lassen sich dann zwischen zwei Meilensteine (Releases) planen.