Skip to main content

Agiler Workflow statt Kommunikationschaos

Der folgende Beitrag gibt eine Übersicht zu dem von uns verwendeten agilen Projekt-Workflow, den wir mit Hilfe des Issue- und Bugtracking- Systems Youtrack umsetzen. Das Ganze aus der Perspektive eines Entwicklers.

Ein Rückblick

Wer kennt es nicht, Änderungswünsche von Kunden kommen idR. per Mail oder in ganz dringenden Fällen per Telefon. Empfänger sind meist die Projektmanager oder Entwickler aber auch gerne mal die Chefin. Jetzt kommt der Knackpunkt: Diese Änderungswunsche wurden dann agenturintern gleich per Mail an die zuständigen Designer, Entwickler oder Projektmanager weitergeleitet - was bei mehreren gleichzeitigen Projekten in der Pipeline unweigerlich im Chaos endete. In scheinbar ganz dringenden oder ganz einfachen Fällen geht aber auch noch direkter - nach dem Prinzip der kürzesten Wege gleich per Zuruf: „Kannst du bitte mal schnell… .“

Gerade Entwicklern kosten solche kleinen Unterbrechungen Studienergebnissen zufolge 15 oder gar 30 Minuten Zeit, um wieder ganz in die ursprüngliche Problemstellung hinein zu finden. Abgesehen davon ist die gesamte Kommunkation zu Änderungswünschen in E-Mails, auf Notizblöcken und vor allem in den Köpfen des Teams gespeichert. Das führt dazu, dass es für alle Beteiligten schwer wird den Überblick zu behalten und konzentriert zu arbeiten. Eine Lösung musste also her, aber klassische Bugtracker sind zu sehr an Entwicklern ausgerichtet und für Projektmanager, Designer und Kunden eher ungeeignet. Nach langem Suchen sind wir aber seit letztem Jahr fündig geworden und möchten euch einen Einblick in unsere Erfahrungen geben.

Die Qual der Wahl

Nach gründlicher Recherche und Tests von vielen Bug-, Issue-Tracking und Projektmanagement-Systemen wie Jira, Redmine, Trac, Erpal, etc. haben wir uns unter anderem aus folgenden Gründen für Youtrack entschieden:

  • Individuell an unseren Workflow anpassbar
  • Zusammenfassung von Projektmanagement, Bug-Tracking und Zeiterfassung
  • Zentrale Dokumentation aller Änderungen und Kommunikation
  • Integration mit unserem Continuous Integration System (wird in einem späteren Beitrag erörtert)
  • Möglichkeit zu schnelleren Strukturierung von Kundenanfragen (Erstellung von Angeboten, wird ebenfalls später gebloggt)
  • Ausgefeiltes Rollensystem, um Kunden Zugriff auf Projektbereiche zu geben

Effizienter und agiler Workflow

Da wir bereits bei der Angebotserstellung die Projekte strukturieren, beschreiben und in kleinere Tasks bzw. Tickets aufteilen, können wir bei Projektstart schneller in die Umsetzung gehen. Es sind bereits alle Features und User stories definiert und werden gegebenenfalls in kleinere Subtickets aufgeteilt.

Kommunikation und Dokumentation von Änderungen Alle Änderungen, zusätzliche Informationen oder Fragen werden zu den jeweiligen Tickets gespeichert. Etwaige Rückfragen an den Kunden werden sofern möglich auch über das System abgewickelt. Kunden können aber auch via E-Mail neue Tickets eröffnen. So ist sichergestellt, dass alle Beteiligten, jederzeit, auf dem gleichen Wissenstand sind.

Priorisierung der Tickets Um abschätzen zu können, wie wichtig die Bearbeitung der Tickets ist werden folgende Prioritäten vergeben:

  • Minor
  • Normal
  • Major
  • Critical
  • Show-Stopper

Als "Critical" und "Show-Stopper" markierte Tickets sind meist Grundbausteine und für den Projekterfolg äußerst wichtig. Diese werden dementsprechend prioritär behandelt und zuerst umgesetzt. Auch Bugs fallen in diese Kategorie.

Wöchentliche Sprints Meist 2-4 Wochen im Voraus wird durch die Projektmanager aus den laufenden Projekten und etlichen Tickets ein wöchentlicher Sprint zusammengestellt und gleich einzelnen Personen zugeordnet. Im so genannten Agile Board haben nun alle Projektbeteiligten einen Überblick über die anstehenden Aufgaben, kategorisiert nach Priorität. Die Tickets sind entweder wie erwähnt bereits zugeordnet oder aber "Unassigned". So können am Projekt beteiligte Teammitglieder die Tickets selbst untereinander aufteilen.

Tägliche Bearbeitung der Tickets Auf Basis der für die Woche definierten Sprints wird je nach Priorität mit den wichtigsten Tickets begonnen. Der Status des Tickets wird dabei auf "In Progress" gesetzt und auch im oben genannten Agile Board abgebildet. So bekommt jeder einen Überblick, woran gearbeitet wird. Dadurch entfallen täglich mehrmalige Nachfragen, woran gerade gearbeitet wird und was bereits gefixt wurde.

Gibt es Rückfragen oder Unklarheiten wird direkt das entsprechende Ticket kommentiert und einfach dem gewünschten Teammitglied zugeordnet. Dieses erhält eine Benachrichtigung und kann darauf direkt per Mail (wird im Ticket gespeichert) oder über die UI reagieren. So bleibt die gesamte Kommunikation an zentraler Stelle und ist nicht in Mails, auf Zetteln oder in den Köpfen verstreut.

Nach Umsetzung des Tickets wird der Status auf "Fixed" gesetzt um zu signalisieren, dass vorerst alles fertig ist. Youtrack informiert automatisch die Projektverantwortlichen bzw. den/die ErstellerIn des Tickets und weist es zu. Ist die Umsetzung überprüft und vollständig wird das Ticket endgültig geschlossen. Sollte es noch etwas zu tun geben kann demenstprechend der Status wieder auf "Open" gesetzt werden.

Durch die Integration von Youtrack mit unserem Continuous Integration System können Tickets auch mit einer entsprechenden Commit-Message geschlossen und auf "Fixed" gesetzt werden. Dazu wird mein Kollege Sebastian in Kürze einen Beitrag schreiben.

Stolpersteine und Verbesserungspotenzial

Nur ein "bisschen" Issue-Tracking, Projektmanagement und Continuous Integration funktioniert nicht wirklich. Wir haben festgestellt, dass es äußerst wichtig ist wirklich alles im System abzubilden und einzutragen - nur so ist sichergestellt dass die Flut von Informationen und Änderungswünschen im Zaum gehalten wird und der Überblick nicht verloren geht. Kundenanfragen via Mail oder Telefon sollten direkt eingetragen und damit dokumentiert werden.

Bei "nur kurz" oder "geht das" Nachfragen tendieren wir im Team teilweise noch dazu das System zu umgehen. Ist eine Frage oder Änderungswunsch trivial erscheint es uns manchmal keinen Sinn zu machen diese als Ticket einzutragen. Dass man mit einer scheinbar kurzen Nachfrage die Kollegen unter Umständen unterbricht und aus der Konzentration bringt (kostet wie oben bereits beschrieben bis zu 30 Minuten Arbeitszeit) ist einem in der Situation nicht klar. Da müssen wir uns noch strikter an den Workflow halten.

Für Tätigkeiten, die nicht direkt einem Ticket zuordenbar sind oder mehrere Tickets umfassen, fällt es oft schwer den tatsächlichen Aufwand zu erfassen bzw. ist einem nicht sofort klar, dass ein eigenes Ticket erstellt werden sollte. Zum Beispiel beim Testen des gesamten Projekts vor Live-Schaltung.

Fazit

Keine Frage, das System ist bereits jetzt eine enorme Effizienzsteigerung für unseren internen Workflow. Wir wollen es alle nicht mehr missen. Aufgrund der Flexibilität von Youtrack ist sichergestellt, dass wir nach und nach mit den richtigen Stellschrauben unseren Workflow weiter ausbauen und optimieren.

Wird nicht veröffentlicht