Dieser Blogbeitrag soll einen Einblick in den Projektalltag mit Atlassians Projektmanagement (PM) Tool JIRA geben und die Erfahrungen, die ich mit dem Aufsetzen von JIRA und der Einführung in unser Team gemacht habe beispielhaft darstellen. Dabei möchte ich erläutern auf welche unterschiedliche Art man JIRA nutzen kann und wie die Umsetzung und der anschließende Gebrauch des Tools gelungen ist.
Bevor man anfangen kann JIRA als PM-Tool zu nutzen, müssen eine Reihe an Voreinstellungen gemacht werden, die den Ablauf von Arbeitsprozessen beeinflussen. Diese Einstellungen sollten im Vorfeld gut überlegt sein, damit jedes Teammitglied das Tool in seinen Arbeitsablauf mit einbinden kann.
Hier eine kleine Auswahl an Punkten, die meiner Meinung nach unbedingt angepasst werden sollten bevor man das erste Projekt mit JIRA startet:
User-Rollen
User-Rechte
Benachrichtigungen
die Festlegung der Issue Types
das Anlegen der Eingabemasken für die Issue-Erstellung
und die Erstellung von Workflows
Die größte Herausforderung war es, einen funktionierenden Workflow zu erstellen, der alle notwendigen Arbeitsschritte berücksichtigt und gleichzeitig einen sinnvollen Ablauf der Ticketbearbeitung ermöglicht. Den Standard-JIRA-Workflow als Vorlage nutzend habe ich angefangen einzelne Arbeitsschritte hinzuzufügen und neu zur verknüpfen. Hierbei hat es mir am meisten geholfen mich mit Kollegen auszutauschen. Dabei ist uns aufgefallen, dass gewisse Arbeitsschritte bis jetzt vermisst oder vernachlässigt worden sind und durch die Einbindung in den JIRA Workflow allen erneut ins Gedächtnis gerufen werden.
Am Ende ist ein Workflow entstanden, den wir sowohl für Software, als auch Service Desk Projekte verwenden können. Wobei nicht bei jedem Projekt alle Arbeitsschritte benötigt werden, da manche Projekte einen anderen Aufbau haben. Auch hierfür gibt es eine Lösung von JIRA. Jeder Step eines Workflows wird in dem jeweiligen Projektboard einer Statusspalte zugewiesen, z.B. wenn ein Issue grundsätzlich erledigt ist, aber noch die Freigabe des Kunden benötigt wird, dann hat das Issue den Status "Kundenfreigabe" ist aber schon in der Statusspalte "Erledigt" zu finden. Gibt es ein Projekt, dass keine Kundenfreigabe benötigt kann der Status in die Kategorie "Unmapped Statutest" fallen und wird in dem jeweiligen Projektboard nicht berücksichtigt. Durch die Vielzahl an Einstellungsmöglichkeiten ist es uns möglich trotz eines vereinheitlichtem Workflows jedes Projekt individuell über sein Board zu gestalten und unnötige Arbeitsschritte wegfallen zu lassen. Ändert sich der Projektablauf einmal können auch die Einstellungen des Boards und des Workflows erneut angepasst werden.
Projekttypen und ihre Unterschiede
Bei den Software Projekten - Scrum software developmentist es wichtig gewesen einen passenden Workflow für die Arbeitsweise des Teams zu erstellen. Der Workflow sollte den einzelnen Schritten eines Sprints zugeordnet werden können. Sprints gliedern ein Software Projekt in zeitliche Abschnitte. Innerhalb eines Sprints werden Issues von Open über -> Progress -> Review -> in Done geschoben.
Mit Hilfe der Sprints erhält jedes Teammitglied einen Überblick über die derzeitig anfallenden Aufgaben. Alle weiteren Tasks, die zu einem späteren Zeitpunkt des Projekts gehören, liegen im Backlog. Die Möglichkeit einzelnen Teammitgliedern Issues zuweisen zu können, vereinfacht die Bearbeitung, durch mehrere Personen. Zu jedem Zeitpunkt ist einsehbar wer an welchem Issue arbeitet und in welchem Bearbeitungsstatus sich der Task befindet. Für den PM ergibt das die Möglichkeit zu jedem Zeitpunkt den Überblick über den Status des Projekts zu behalten.
Auch die Requests unsererService Desk Projektewerden mit dem selben Workflow, wie bei den Software Projekten, bearbeitet. Hier werden die einzelnen Issues jedoch nicht wie bei den Software Projekten in Sprints aufgeteilt, sondern sammeln sich alle in einer Liste. Der PM des Service Desk kann sich überlegen nach welcher Reihenfolge die Issues bearbeitet werden sollen. Für uns ist es am praktischsten die Issues nach Priorität zu bearbeiten. Bei Projekten, die über einen Pflegevertrag laufen, richten sich die Prioritäten der Requests nach den Zeiten des SLAs (Service-Level-Agreement).
Im Service Desk kann der Kunde Requests erstellen, die dann in der Liste auflaufen und Teammitgliedern zugewiesen werden können.
Für den Service Desk können die Benachrichtigungen so eingestellt werden, dass der Kunde, wenn gewünscht, über jedes Statusupdate per Email informiert wird. Wenn das nicht sein soll gibt es die Möglichkeit den Kunden über der Kommentarfunktion des jeweiligen Issues auf dem Laufenden zu halten oder bei Rückfragen in den Bearbeitungsprozess mit einzubeziehen.
Neben Software und Service Desk Projekten können bei JIRA auch Business Projektegetrackt werden. Je nach Projekt kann zwischen drei unterschiedlichen Arten der Bearbeitung gewählt werden:
Projectmanagement
Taskmanagement
Processmanagement
Jede dieser drei Möglichkeiten beinhaltet einen eigenen Workflow, der mehrere oder weniger Arbeitsschritte beinhaltet. Diese können je nach Projektinhalt angepasst werden sollte ein Projekt einen größeren Umfang beanspruchen. JIRA Business Projekte sind optimal dafür geeignet interne Themen zu bearbeiten und deren Verlauf zu beobachten.
Für unseren Projektalltag verwenden wir hauptsächlich Software und Service Desk Projekte in JIRA. Über den Service Desk koordinieren und bearbeiten wir Kunden Issues, die zumeist auf den Inhalt bezogen sind oder kleinere Änderungswünsche beinhalten, die programmatisch gelöst werden. Sind bearbeitungsintensivere Änderungen an Funktionalitäten oder Layout gewünscht wird das jeweilige Issue in das zugehörige Software Projekt dupliziert. So entsteht ein Linked Issue. Für Linked Issues kann eine Automationeingestellt werden die es ermöglicht, dass ein Statusupdate bei Linked Issues beidseitig geschieht. So bleiben Service Desk und Software Projekt immer auf dem gleichen Stand und der PM kann gegebenenfalls den Kunden über die Kommentarfunktion informieren.
Theorie und Praxis
Soweit zur Theorie und meiner Vorstellung, die ich hatte als ich JIRA aufgesetzt habe. In der Realität sieht es dann so aus:
Nicht alle Kunden nutzen den Service Desk. Es ist schwer Kunden an einen neuen Kommunikationsweg zu gewöhnen. Beim Großteil der Kunden ist es Gang und Gebe Anfragen über Email zu machen.
Teammitglieder vergessen ihre Tasks zu updaten. Auch die Teammitglieder müssen sich daran gewöhnen ihre Arbeitsfortschritte in einem System zu dokumentieren. Zu Anfang wird häufig vergessen Tasks auf dem neusten Stand zu halten und regelmäßig den Status zu updaten.
Tasks werden nicht angelegt: „Das erledige ich ganz schnell, dafür benötigen wir kein extra Issue“. Tasks, die als klein und schnell zu erledigen angesehen werden, werden häufig erst gar nicht vom Team angelegt. Für manche Teammitglieder ist das Anlegen von kleineren Tasks in JIRA verschwendete Zeit, die für das Erledigen der Aufgabe verwendet werden könnte. Allerdings, steht hier die Dokumentation der Aufgabe und eventueller Absprachen im Vordergrund.
Wenn es einen Approver für bestimmte Tasks mit Status "In Review" gibt, wie z.B. der PM, muss auch dieser an seine Aufgabe denken die Tasks zu reviewen und als "Done" oder "Reopened" zu markieren. Erst nach diesem Arbeitsschritt ist ein Task abgeschlossen und ein Prozess erfolgreich.
Natürlich gibt es immer eine Hürde die überwunden werden muss, wenn ein neues System eingeführt wird. Es ist verständlich, dass sich Teammitglieder unterschiedlich schnell an die Arbeit mit dem Projekt-Tool gewöhnen, da jedes Mitglied auf eine andere Art und Weise seine Aufgaben angeht.
Unsere Vorgehensweise
Um JIRA als Projekt-Tool einfach in unseren Arbeitsprozess zu integrieren halten wir unser wöchentliches Standup Meeting nicht mehr an unserem Whiteboard sondern versammeln uns vor dem Bildschirm im Konfi. Auf diese Weise können wir alle zusammen den vergangenen Wochensprint abschließen und die neue Woche planen. Abgeschlossene Issues verschwinden aus dem Backlog und alle nicht abgeschlossenen Issues können automatisch in den neuen Wochensprint übertragen werden, ohne, dass sie ihren aktuellen Status verlieren.
Durch die aktive Beteiligung aller Kollegen bei der gemeinsamen Organisation der Woche in JIRA wird die Nutzung des Tools jede Woche aufs neue dem Team ins Gedächtnis gerufen. Dennoch, kommt es immer wieder vor, dass von einem Kollegen mal vergessen wird ein Issue einzustellen, den Status des Issues zu updaten oder auch anderen ein Issue zuzuweisen.
Unser Team steht noch am Anfang der internen JIRA-Nutzung. Ein erster Schritt hin zur besseren und vermehrten Nutzung von JIRA in unserem Arbeitsalltag war unser manuelles Statusboard in JIRA zu spiegeln und so unsere Wochenplanung zu organisieren. Sicherlich wird uns im Laufe der nächsten Wochen und Monate immer wieder eine Idee kommen, wie wir unsere Nutzung noch optimieren können. Schließlich soll das Tool unsere Projektarbeiten vereinfachen und nicht unnötig komplizierter machen.
Ebenfalls interessant
- UNSERE LEISTUNGEN – Überzeugen Sie sich von den vielseitigen Angeboten unseres Unternehmens
- UNSERE EXPERTISE – Wir kombinieren unsere Kompetenzen aus den Bereichen Startup, Corporate und Entrepreneurship für zielgerichtete Innovation
- CORPORATE INNOVATION KIT – Entwickeln und testen Sie neue Geschäftsideen innerhalb von nur vier Wochen