Es gibt im JIRA System drei Eckpfeiler als Dimension für Issues, die sich NICHT oder nur über Umwege projektspezifisch einstellen lassen:
- Status
- Resolution
- Priority
Warum dies so ist?! Naja, wie in vielen Fällen der Software Entwicklung tippe ich zu 70% auf hysterisches…ähm…historisches Wachstum und dies restlichen Prozent gehen auf klare Schnittstellen zu externen Systemen.
Schließlich sollten andere Plugins die Chance haben, kritische Bugs, die noch nicht resolved sind, als solche zu erkennen. Wenn jeder da seine eigenen Werte frei konfigurieren könnte, wäre es zumindest schwer, eine gemeinsame Basis zu finden.
JIRA Issue
Jetzt habe ich das wichtigste Artefakt in JIRA bereits vorweggenommen: den Issue.
Was auch immer in JIRA verwaltet, mitverfolgt oder ausgewertet werden möchte, geschieht auf der Basis von Issues.
Issues können also User Stories, Fehler, Features, Bugs, Epics, ToDos, Tasks, wiederkehrende Aufgaben, et. sein.
Ein Issue kann in JIRA nur einem Benutzer zugewiesen werden und durchläuft in einem Projekt einen für diesen Issue Type (Epic, Story, Bug, Task, …) vorgesehenen Arbeitsablauf; besser bekannt als Workflow.
Ein Issue hat einen Typ und das Umwandeln eines Issues vom Typ A in den Typ B geschieht in JIRA durch Verschieben (Move).
Zudem kennt der Issue einige fest vergebene Attribute und aggregierte Komponenten. Er kann aber mit benutzerdefinierten Attributen versehen werden, was die Komplexität der Issues nicht einfacher werden lässt.
Im Folgenden werde ich einige dieser Attribute beschreiben und gebe zudem an, was ich als Projektmanager mir in diesen Feldern für Werte vorstellen würde.
Summary
Die Zusammenfassung (summary) soll im besten Fall ein kurzer sprechender Bezeichner für den Issue sein.
Hier sollte man NICHT bereits eine Kurzbeschreibung finden. Dagegen ist das typische Format einer User Story („Als … möchte man …, um zu …) von Mike Cohn durchaus brauchbar.
Bei Fehlern sollte man im Blick haben, dass bereits die Zusammenfassung, sowohl eine beschreibende als auch eine identifizierende Aufgabe für den Issue hat.
Beispielsweise ist eine Issue mit dem Summary „Fehler im Buchungsprozess“ nur schwer von weiteren evtl. auftretenden Fehlern in diesem Bereich zu unterscheiden.
Zugegeben, da ist ein wenig Kreativität gefragt, aber dafür sind wir ja Software Entwickler.
Security Level
Die Sicherheitsstufe (security level) erlaubt die Sichtbarkeit von Issues auf einzelne Benutzer, Gruppen oder Rollen einzuschränken. Dazu müssten allerdings entsprechende Sicherheitsstufen definiert und konfiguriert sein.
Ich nutze eine Sicherheitsstufe in meinen Projekten gerne für interne Aufgaben bzw. gruppenspezifische Tasks, die dann in den Filterungen und Dashboards der Kollegen nicht auftauchen und auch nur zur Unübersichtlichkeit führen würden.
Um einen Issue eines bestimmten Security Levels sehen zu können, muss einem Benutzer dieses Level zugewiesen worden sein.
Verwendet man keine Levels, so sind diese Issues für alle Benutzer sichtbar.
Priority
Die Priorität (priority) eines Issues ist in vielen Fällen nicht nur eine technische, sondern auch eine politische Größe und wird vor allem deshalb sehr häufig falsch verwendet.
Besonders kurz nach oder vor einem Livegang neigen unterschiedlichste Stake Holder einer Software dazu überzugehen und im Wesentlichen vor allem Fehler als kritisch („Ohne diese Funktionalität macht ja der ganze Bereich keinen Sinn.“) und/oder hoch („Naja, Herr Albrecht, das muss schon laufen, ist ja ein sehr wichtiges Feature“) einzustufen, die diese Priorität häufig nicht verdienen.
Der Grund liegt auf der Hand: Es soll die Bearbeitung dieses Issues vorangetrieben werden und der Durck entsprechend erhöht werden.
(„Herr Albrecht, wir haben immer noch 30 kritische Bugs offen.“ oder „Herr Albrecht, da sind aber noch Fehler hoher Priorität offen.“)
Am Ende einer aufklärenden Sitzung zitiere ich immer gerne folgenden Witz:
Warum sind in Österreich die Busse 1m lang und 20m breit? Weil alle neben dem Fahrer sitzen wollen.
Es kann – wie übrigens in Österreich auch – nicht funktionieren, dass alle neben dem Fahrer sitzen und das hat entweder eine völlige Fehlbewertung der Gesamtsituation zur Folge oder technische Situation, die unlösbar sind.
Wenn alle Bugs kritisch sind, kann ich als Entwickler auch nur einen davon bearbeiten. Ich arbeite – was wäre ich auch für ein Clean Code Developer – nicht fünfmal so schnell, bloß weil entsprechend viele Bugs vorhanden sind.
Umgekehrt müssen natürlich bei einer vernünftigen Priorisierung der Issues auch die Software Entwickler und Dienstleister aufhören, mit der „Schwere offener Bugs“ zu argumentieren. Am Ende wollen wir doch alle das gleiche: Eine perfekt laufende Software, die unseren Kunde zufrieden stellt.
Mir persönlich reichen in der Priorisierung die dem Moscow-Prinzip entnommenen vier Prioritäten:
- Must
- Should
- Could
- Would (ja, ich weiß, offiziell heißt es won’t aber wer braucht das schon)
Nun gibt es aber in JIRA fünf davon und zwar die folgenden:
- Kritisch
- Hoch
- Mittel
- Gering
- Trivial
Vielleicht erlebe ich noch den Tag, an dem ich in einem Projekt OHNE kritische Bugs mitarbeiten darf, aber ich würde mir wünschen, dass nur im Falle sogenannter Expedites wirklich zur kritischen Priorität gegriffen wird und in allen anderen Fällen Coolness und Besonnenheit auf beiden Seiten herrscht.
Fälligkeitsdatum
Hier ließe sich ein bestimmter Zeitpunkt eintragen, zu dem ein Fehler behoben oder ein Feature umgesetzt werden sollte.
Diese Information nutzen wir derzeit nicht. Statt dessen wird die Umsetzung einzelner Issues über Sprints, deren Versionsnummer und Ablaufdatum gesteuert.
Assignee
Wer soll das Ticket bearbeiten?
Automatisch wird jeder Issue dem Projektleiter, also Michael Albrecht, zugewiesen. Ich delegiere dann die Bearbeitung weiter oder nehme den Issue beim nächsten Sprint Planning mit auf.
Autor
Wer hat den Issue erzeugt?
Dies ist wichtig, wenn man mal einen Issue auf Basis eines Telefonats und nach einem Gespräch stellvertretend für jemanden erzeugt. Dann sollte dies hier korrigiert werden.
Epos – Verknüpfung
Stories stehen meist unter einem großen Epos.
Komponente
Komponenten stellen eine weitere Dimensionierung von Issues dar und erlauben eine strukturierte Zerlegung beispielsweise in technische und/oder fachliche Komponenten.
In unserem Fall verwenden wir sie für technische Komponenten wie beispielsweise:
Frontend/HTML → Aufgaben für den Frontendentwickler
TYPO3 → Aufgaben für TYPO3-Experten
Hybris → Aufgaben für die hybris Entwickler
Projektmanagement → Aufgaben für den Scrum Master, Product Owner
betrifft Version(en)
Dieses Fehler soll bei Fehlern unbedingt ausgefüllt werden, damit der Bearbeiter den Fehler evtl. selbst nachvollziehen kann. Die aktuelle Version auf den unterschiedlichen Stages wird ja per Mail kommuniziert.
Lösungsversionen
Darüber legen wir fest, in welche Version die Lösung deployed werden wird. Über dieses Planungsfeld werden dann auch die Releasedokumentationen automatisiert.
Beschreibung
In der Beschreibung kann man ausgiebig alle möglichen Formatierungen und Bilder, Links und sonstige Bezüge verwenden, um den Issue genauer zu beschreiben.
Erwähnt sei an dieser Stelle die @Mention Funktionalität, die es erlaubt, einen Benutzer/Kollegen via Notification auf einen Issue hinzuweisen.
ursprüngliche Schätzung
verbleibende Schätzung
Beide obigen Werte verwenden wir in diesem Projekt NICHT. Zumindest nicht bei der Anlage eines Issues.
Anhang
Als Anhang bzw. Attachment sind alle Arten von Dateien erlaubt. In der Beschreibung kann man dann via !Name_des_Bildes.endung! darauf verweisen. Dies funktioniert, auch wenn JIRA initial einen Fehler angibt, er könne das Bild nicht finden, weil es u.U. parallel hochgeladen wird.
Stichwörter
Stichwörter, Labels, Tags könnten uns sehr behilflich sein, Issues wiederzufinden bzw. die entscheidenden Tags in einer Cloud wiederzuspiegeln.
Sie werden allerdings derzeit nicht gepflegt.
Sprint
In diesem Feld kann man einen Issue automatisch einem Sprint zuweisen. Dies sollte NICHT passieren, sondern ist Aufgabe des Teams in Zusammenarbeit mit dem Product Owner im Sprint.
Story Punkte
Story Punkte erlauben eine Schätzgröße für die Umsetzung von User Stories anzugeben. Auf Basis dieses Felds werden in JIRA sämtliche agilen Charts (Burndown Chart, Release Chart, …) berechnet.