INSIGHTS Ticket Police: Mehr Effizienz im Sprint

ABOUT YOU TECH

ABOUT YOU TECH

5 min read

Autor: Florian Weigang

Innerhalb der einzelnen Teams bei ABOUT YOU arbeiten wir mit agilen Entwicklungsmethoden, wie z.B. SCRUM und Kanban. Dabei fallen regelmäßig wiederkehrende Aufgaben an.

Im Scrum bestehen diese aus dem Besprechen und Schätzen einzelner Tickets (Grooming Meeting), dem Commitment des Teams für den nächsten Sprint (Sprint-Planning) und dem Präsentieren der Ergebnisse am Sprint Ende vor den Stakeholdern (Review).
Den Aufwand zur Vorbereitung und Durchführung der einzelnen Arbeitsschritte haben wir durch eine Automation der Ticketverarbeitung minimiert. Das dafür entwickelte System nennen wir Ticket-Police. Ich möchte hier die Vorteile dieses Systems näherbringen.

Einzelne Aufgaben innerhalb eines Sprints

Im wöchentlichen Sprint-Planning vereinbaren alle Entwickler (Frontend und Backend) ein Commitment an Tickets, welche innerhalb eines zweiwöchigen Sprints fertig zu stellen sind. Der Scrum JIRA-Backlog bietet dafür keine geeignete Grundlage, um zu prüfen wie die Auslastung ist, da nicht auf einen Blick ersichtlich ist, wieviele Story-Punkte bis zu welchem Ticket erreicht werden können und wie diese sich auf Frontend und Backend verteilen. Aus diesem Grund implementiert die Ticket-Police eine Planning-Overview, die sich aus den einzelnen Tickets des Sprint Backlogs zusammensetzt.
Sie schlüsselt die Verteilung der einzelnen Story-Punkte auf Frontend und Backend auf und ermöglicht es, das Sprint-Planning bis zu dem Ticket im Backlog durchzuführen, bis das Team ausreichend ausgelastet ist, um darauf aufbauend ein Commitment abgeben zu können.

Die jeweils am höchsten priorisierten Tickets werden zuerst besprochen und geplant, womit sichergestellt wird, dass die Tickets mit dem höchsten Business Value als erstes in den nächsten Sprint übernommen werden und auch als erstes während des Sprints abgeschlossen werden. Jedes Ticket wird im Sprint-Planning noch einmal besprochen und auf Vollständigkeit geprüft, ggf. werden Sub-Tasks für Implementierungsaufgaben erstellt. Der jeweilige DevBuddy eines Tickets soll im Sprint-Planning eine Lösungsskizze präsentieren um das Meeting effizienter zu gestalten. Ein DevBuddy ist der technische Ansprechparter für ein Ticket. Die Zuordnung zwischen Tickets und DevBuddys erfolgt nach dem letzten Grooming Meeting. Dann werden alle Tickets im Backlog bis zum Icelog auf die einzelnen Entwickler aufgeteilt.

Diese Abbildung veranschaulicht die DevBuddy View in der Ticket-Police. Sie zeigt alle Tickets, welche sich über dem Icelog im Scrum Backlog befinden und noch keinem DevBuddy zugewiesen sind und getrennt nach Frontend und Backend gruppiert sind. Diese Tickets können dann den einzelnen Teammitgliedern zugewiesen werden.

Eine weitere Aufgabe, die immer zum Ende eines Sprints anfällt, ist die Auflistung aller Tickets im Sprint ohne Bugs, Fastlane und Sub-Tasks, um daraus die Sprint Review Präsentation für die Stakeholder zu erstellen. Damit der aktuelle Sprint Backlog nicht einzeln durchgegangen werden muss, um die IDs und Titel der Stories zu kopieren, haben wir zusätzlich noch das entwickelt. Dieses gibt uns nur die Stories aus dem aktuellen Sprint zurück. Durch diese Vorauswahl ist es dann einfach möglich, eine Präsentation für das Review zu erstellen.

Aufbau der Ticket-Police

Die Ticket-Police besteht aus einer auf AngularJS basierenden Frontend-Anwendung, die über einen Proxy mit einem kleinen NodeJS-Skript kommuniziert. Dieses wiederum stellt eine einfache API bereit, über welche die JIRA-API angesprochen wird, welche als Datenquelle fungiert. Ich werde die einzelnen Komponenten nun etwas näher erläutern.

Die JIRA-API
Alle Funktionen von JIRA werden auch über die REST-API zur Verfügung gestellt. Um diese zu nutzen, muss man sich gegenüber der API authentifizieren. In unserem Fall authentifiziert sich die Ticket-Police mit einem Useraccount über Basic-Auth. Nach erfolgter Authentifizierung stehen mehrere Endpunkte zur Verfügung, um Daten abzufragen. Für uns ist vor allem der Endpunkt interessant, durch den man über Anfragen an die gewünschten Daten gelangt. JQL (Jira Query Language) stellt dabei eine Jira spezifische Abfragesprache dar, die SQL ähnelt.

Die Ticket-Police muss zwei spezifische Anfragen an die API durchführen: Für die Review müssen alle Tickets aus dem aktuellen Sprint, für das Planning und die Verteilung der DevBuddys alle Tickets aus dem Backlog geladen werden.

Um die Tickets für das Planning zu erhalten, wird folgende Anfrage gestellt:

PROJECT = “AboutYou Development”

AND (status = open OR status = blocked)

AND type != Sub-task

AND type != Bug

ORDER BY Rang ASC

Dabei werden alle Tickets aus dem ABOUT YOU Development Projekt betrachtet und alle Tickets, die nicht im Planning Beachtung finden sollen, werden herausgefiltert, wie z.B Subtasks und Bugs.

Die Tickets des aktuellen Sprints erhalten wir durch

PROJECT = “AboutYou Development”

AND Sprint = ID

AND type != Sub-task

AND type != Bug

ORDER BY Rang ASC

Dabei werden alle relevanten Tickets aus dem Projekt “ABOUT YOU Development” geladen, die mit einem entsprechen Sprint über eine ID verknüpft sind. Beide Abfragen werden an JIRA über https://url.to.jira/rest/api/2/search?jql=JQL gestellt. Die Daten aus diesen beiden Endpunkten bieten die Grundlage für unsere Anwendung.

AngularJS Anwendung

Die Datenaufbereitung erfolgt über eine AngularJS Anwendung. Dabei haben wir als Mittelschicht eine NodeJS Skript installiert, welche einen Proxy darstellt, um nicht in die Cross-Origin Restriktion zu geraten.

Die obige Abbildung beschreibt den Aufbau der Ticket-Police. Ein zentraler TicketService spricht über einen Proxy mit einem Express Server, welcher wiederum die gewünschten Daten von der Jira API abfragt. Über den Proxy wird dadurch sichergestellt, dass die Anwendung die entsprechende Ressource verwenden darf. Dieser Proxy wurde mittels dem connect-Framework erstellt. Die erhaltenen Roh-Daten werden für das Ticket Model aufgearbeitet, um daraus einzelne Ticket Objekte zu erstellen. Durch diese Objekte ist ein einheitliches Arbeiten mit den Daten innerhalb der Anwendung möglich. Die entsprechenden Collections von Ticket-Modells werden an die einzelnen Controller weitergegeben. Diese bereiten die Daten dann innerhalb von Views entsprechend für das Planning, Review oder die DevBuddys innerhalb von Views auf. Die größte Logik liegt hierbei in dem PlanningController, da er jedes Ticket je nach Spezialisierung (Frontend oder Backend) anders gruppiert und die Storypunkte entsprechend aufsummiert. Er bietet außerdem die Möglichkeit, ausschließlich Frontend oder Backend-Tickets in das Planning mit aufzunehmen. Buddy- und Review-Controller stellen innerhalb der zugehörigen Views dabei nur eine Liste der relevanten Tickets dar. Die einzelnen Views wurden dabei im Sinne von Rapid-Prototyping mit Twitter Bootstrap umgesetzt.

Nächste Schritte

Dieses simple System erlaubt es uns, Tickets wesentlich effizienter in unseren Arbeitsablauf zu integrieren, als JIRA selbst das ermöglicht. Gerade im Planning ist der Nutzen offensichtlich, da in jedem Moment des Meetings ein genauer Überblick über die Auslastung der einzelnen Spezialisierungen möglich ist. Dadurch können wir die Zuverlässigkeit unseres Commitments steigern.
Darüber hinaus ist geplant, einen Sanity Check im Backlog einzubauen, um Tickets auf fehlende Attribute zu überprüfen. Das würde uns weitere Arbeit abnehmen und die Ticketqualität erhöhen.