Sich agiler Softwareentwicklung zu verschreiben ist eine grundsätzliche Entscheidung. Bereits 2001 wurde hierzu von den wichtigsten agilen Softwareentwicklern der Zeit das Manifesto for Agile Software Development entworfen, das bis heute von vielen Entwicklern unterzeichnet wird. Dabei geht es darum, bestimmte agile Ziele in der Softwareentwicklung zu verfolgen: die Projektteilnehmer und deren gute Zusammenarbeit in den Mittelpunkt zu stellen, mehr Raum für die eigentliche Softwareentwicklung statt für aufwändige Dokumentationen zu lassen, eng mit den Kunden zusammenzuarbeiten und flexibel auf Änderungswünsche einzugehen.

Was ist das Rapid-Board?

Das Rapid-Board für das JIRA-Plugin Greenhopper gibt es seit August 2011. Seitdem wurde es mehrfach nachgebessert und den Wünschen der Entwickler in aller Welt angepasst. Mit dem Release 5.10 kam im Mai 2012 schließlich ein komplett neues Design für die Scrumplanung und Berichterstattung auf den Markt. Mittlerweile ist ein sehr schönes, intuitiv zu bedienendes Tool für die Planung agiler Projekte in JIRA entstanden. Wird das Greenhopper-Plugin in JIRA installiert, erhält man ein neues Agile-Menü.

Mit Greenhopper lassen sich die Aufgaben in JIRA  in verschiedenen Ansichten übersichtlich darstellen und im Rapid-Board die Arbeitspakete für den nächsten Sprint zusammenstellen.

Anlegen eines neuen Rapid Boards

Zunächst muss hierfür ein neues Rapid-Board angelegt werden.  Man muss sich entscheiden, ob man die Scrum oder Kanban-Variante wählt, je nachdem welche Vorgehensweise im Unternehmen üblich ist.

Dem neuen Rapid Board wird ein Name gegeben und ein JIRA-Projekt ausgewählt, für das es erstellt werden soll. Die Verbindung mit einem Projekt bedeutet, daß alle Vorgänge dieses Projekts im Board als Backlog verfügbar sind. Es ist außerdem möglich das Rapid Board in einem späteren Schritt im Konfigurationsmenü des Boards mit einem Filter zu verknüpfen. Zu diesem Zeitpunkt muss aber ein konkretes Projekt ausgewählt werden.

Sprintplanung

Die nächste Ansicht zeigt das neue Rapid Board im Plan Modus. Auf der linken Seite sind alle noch offenen Vorgänge des Backlogs zu sehen. Es lassen sich Quickfilter auf diesen Backlog anwenden, um nur die relevanten Vorgänge für den nächsten Sprint anzuzeigen. Diese sind im oberen Bereich unter dem Namen des Boards zu sehen. In diesem Beispiel wird ein Filter angewandt, der nur Vorgänge vom Typ „Story“ anzeigt.

Jetzt kann damit begonnen werden den Arbeitsaufwand für die Stories einzuschätzen und sie für den nächsten Sprint so sortieren. Dazu wird eine Story nach der anderen durchgegangen (angeklickt), eine Kurzübersicht wird dabei auf der rechten Seite angezeigt, und jeder Story eine Anzahl von Storypoints zugewiesen (normalerweise zwischen 1= wenig und 5= viel) gemäß dem Arbeitsaufwand, der zur Implementierung der Story geschätzt wird. Außerdem werden Stories die als nächstes zu implementieren sind an den Anfang der Reihe gestellt und Stories deren Bearbeitung noch Zeit hat an das Ende. Dies kann entweder per Drag&Drop geschehen oder indem in dem Auswahlmenü der Story mit dem Zahnrad „Send to top“ oder „Send to bottom“ ausgewählt wird.

Der Sprint Marker wird dazu benutzt die richtige Anzahl an Stories und Storypoints für den nächsten Sprint auszuwählen. Normalerweise einigt man sich im Unternehmen auf eine feste Anzahl an Storypoints pro Sprint die implementiert werden sollen. Die erste Graphik zeigt den Backlog ohne die Anwendung eines Quickfilters und die zweite den Backlog mit dem angewandten „Stories only“ Filter. Der Sprint Marker zählt alle Vorgänge, auch wenn sie durch Quickfilter versteckt sind.

Arbeiten mit Stories in einem Sprint

Wenn diese Aktivitäten die sich „Grooming“ nennen, was wörtlich übersetzt zwar „Putzen“ und „Pflegen“ heißt, aber das Aufräumen und Sortieren des Backlogs meint, dann kann der Sprint gestartet werden. Um dies zu tun klickt man auf „Start Sprint“ auf dem Sprint Marker. Man gibt dem Sprint einen Namen und legt das Start- und Enddatum des Sprints fest. Standardmäßig wird ein Sprint für 2 Wochen angelegt, es kann aber auch nur eine Woche sein, oder in Ausnahmefällen mal 3 Wochen. Man sollte sich aber an einen festen Sprint-Zyklus halten. Dann klickt man auf „Start“.

Jetzt kann an der Implementierung der Stories gearbeitet werden. Wenn an den Stories gearbeitet wird, werden sie in „In Progress“ geschoben und schließlich in „Done“, wenn sie erledigt sind. Um dies zu tun, wählt man die „Work“-Ansicht in seinem Rapid Board aus.

Die Stories können in einem Sprint-Meeting zum Ende des Sprints gemeinsam mit dem ganzen Team bearbeitet werden. Alle Stories des Sprints werden durchgegangen und in „Done“ verschoben, wenn sie erledigt wurden. Was nicht geschafft wurde, bleibt in der ToDo-Reihe und wandert wieder in den Backlog, wenn der Sprint beendet wird. Wenn alle Stories den richtigen Status haben, kann der Sprint beendet werden, indem auf den Pfeil in der rechten oberen Ecke der Done-Reihe geklickt wird.

Sprint beenden und Reports anschauen

Es wird eine Übersicht der Vorgänge angezeigt die erledigt wurden und derer, die wieder in den Backlog wandern. Klicke auf „Complete“.

Der Sprint ist jetzt beendet und Du kannst Dir die dazugehörigen Reports mit allen Daten und Fakten zu dem Sprint anschauen.

Links:

• Produkt Vorstellung: http://www.atlassian.com/software/greenhopper/overview
• User Guide: https://confluence.atlassian.com/display/GH/GreenHopper+User%27s+Guide