13.9.2020
JIRA ist eine Software zur Vorgangs- und Projektverfolgung.
Für einfache Projekte reicht das Standardvorgehen vollkommen aus. Bei komplexeren Anwendungsfällen müssen aber auch komplexere Abläufe in JIRA angewandt werden. Einen solchen Fall stelle ich im Folgenden vor.
Mit steigender Anzahl der Bearbeiter wird das Vorgehen nach und nach komplizierter. Dazu werden in diesem Artikel die jeweils wichtigsten Prinzipien erklärt. Die für die jeweilige Vorgehen erlernten Grundlagen werden in der jeweils nächsten Stufe aufgegriffen.
Es gibt einen Entwickler und einen Projektleiter.
Der Projektleiter ist für die Priorisierung, Zuweisung und Prüfung der Tickets zuständig.
Der Entwickler ist für die Umsetzung der in den Tickets beschriebenen Anforderungen zuständig.
Es werden 5 Status benötigt, um das Vorgehen abzubilden:
Es gibt zwei Möglichkeiten mit Tickets, die einmal den Status “Erledigt” erreicht haben und sich im Nachhinein als fehlerhaft erweisen, umzugehen.
Das Ticket wird erneut geöffnet und in der nächsten Iteration bearbeitet.
Diese Methode funktioniert, hat aber den Nachteil, dass aus den Tickets nicht zu erkennen ist, dass eine neue Funktion im Produkt zu finden ist.
Werden die Releasenotes erstellt und das Ticket ist wieder in Bearbeitung, so ist der Quellcode bereits im Produkt, ohne das der Kunde das erkennen kann.
Werden erst Releasenotes erstellt und das Ticket dann erneut bearbeitet, so taucht dasselbe Ticket doppelt in zwei Releasenotes auf und ist nicht klar zuzuordnen.
Es wird ein neuer Fehler mit einem Verweis auf das Ursprungsticket geöffnet.
In diesem Ticket werden nicht mehr alle Informationen aufgelistet, die im Originalticket erhalten waren. Lediglich die Punkte die nachgebessert werden sollen tauchen in der Beschreibung auf. Werden mehr Informationen benötigt, schaut man sich das Originalticket an.
Dieses Szenario beschreibt, dass es 2 Entwickler mit unterschiedlichen Zuständigkeiten gibt, z.B. Frontend und Backend. Der Backendentwickler (ab jetzt BE) kann auf den Frontendentwickler (ab jetzt FE) angewiesen sein, um ein Ticket zu bearbeiten.
Es besteht die Möglichkeit für jeden Entwicklertypen zusätzliche Status anzulegen, der Ablauf wäre wie folgt:
Das Vorgehen funktioniert, hat jedoch zwei Probleme. Zum einen skaliert dieses Vorgehen nicht, wenn eine weitere Fertigungsstufe hinzukommt. Zum anderen müssen die Tickets erst den FE durchlaufen, um dann zum BE zu gelangen.
Man setzt auf das zuvor beschriebene Vorgehen für einen Bearbeiter. Dabei gibt es zwei Szenarien. Zum einen baut der BE auf der Arbeit des FE auf. Zum anderen gibt es den Fall, dass der BE unabhängig vom FE die Aufgaben erledigen kann.
Im Status “Zur Bearbeitung vorgemerkt” wird das Ticket zunächst dem FE zugewiesen. Bis zum Status QS verändert sich das Vorgehen nicht. Im QS Status jedoch wird bei korrekter Umsetzung das Ticket nicht geschlossen, sondern wieder in den Status “Zur Bearbeitung vorgemerkt” gesetzt und dem BE zugewiesen.
Zum Nachverfolgen, welche Tätigkeiten bereits abgeschlossen sind können Tags wie “Frontend fertig” und “Backend fertig” verwendet werden.
Das schöne an dieser Vorgehensweise ist, dass man die Reihenfolge auch vertauschen könnte. So könnte z.B. der BE zunächst eine Schnittstelle bereitstellen, auf die der FE zugreift.
In diesem Fall werden Tags verwendet um zu kennzeichnen, dass es im Frontend oder Backend nichts zu erledigen gibt.
Besteht nun Bedarf an weiteren Fertigungslinien, so können beliebig viele Tags für das Vorgehen “2 Bearbeiter - Mit bestehendem Vorgehen weiterarbeiten” angelegt werden.
Es gibt jedoch einen Nachteil, der bei diesem Vorgehen noch nicht berücksichtigt worden ist. Die Arbeit läuft immer seriell und nicht parallel. Wenn das gegeben sein soll, dann müssen mehrere Tickets angelegt und miteinander verknüpft werden. Ist paralleles Arbeiten eher die Regel als die Ausnahme, so sollte ein anderes Vorgehen gewählt werden.
Wenn man sich von Anfang an Gedanken dazu macht, wie viele Bearbeiter im Prozess beteiligt sein sollen kann man eine entsprechende Lösung finden. Das schöne ist, wenn man die Lösung für n Bearbeiter wählt, ist die Komplexität bei nur einem Bearbeiter nicht viel höher, als beim Vorgehen für 20. Dafür kann der Prozess unendlich skaliert werden.