Agile Praktiken

Agile Methodik baut auf agile Prinzipien und nutzt agile Praktiken. Hier beleuchten wir die Praktiken, die wir kategorisieren in organisatorische und technische Praktiken.

Organisatorische Praktiken

In diesem Teil unserer Einfüh­rung in Scrum geht es um die damit verbun­denen orga­nisa­torischen und technischen Praktiken. Dazu zählen die getaktete Vorgehens­­weise, die verschie­denen Treffen, die kontinuierliche Lieferung des Produkts und die testgetriebene Entwicklung.

Getaktete Entwicklung: Der Sprintzyklus

Zu den wesentlichen agile Praktiken gehört das getaktete Arbeiten, in der Regel mit einer Periode von zwischen 1 und 4 Wochen. Die zugehörige feste Zeitperiode wird Sprint, Zyklus oder Iteration genannt. In jedem Zeitintervall wird ein kleines Stück vom Gesamtprojekt abgearbeitet und fertig gestellt. Ziel ist es, nach jeder Iteration ein funktionierendes (Teil-)Produkt zu haben (kontinuierliche Lieferung von Ergebnissen). Die Sprints bieten dem Team die Möglichkeit, frühzeitig Feedback von potentiellen Nutzern und dem Product Owner einzuholen.

Das Kick-off Treffen

Ein Scrum-Projekt beginnt mit einem “Kick-off-Treffen” , in dem das Vorhaben zum ersten mal mit dem Projektteam diskutiert wird. Es werden die Ziele, Kundenerwartungen und das Produkt-Backlog besprochen.

Sprint Planungstreffen

Das Sprint Planungstreffen markiert den Anfang eines Sprints. Dieses erste Treffen besteht aus 2 Teilen. Im ersten Teil verpflichtet sich das Team auf einen Satz von Leistungsmerkmalen, die in diesem Sprint erstellt werden. Im zweiten Teil des Treffens sammelt das Team die Aufgaben, die zu erledigen sind, um die vereinbarten User Stories liefern zu können. Das Sprint-Planungstreffen dauert ein bis zwei Stunden pro Woche Entwicklung.

Daily Scrum

Beim Daily Scrum, der typischerweise am Beginn eines Arbeitstages stattfindet, treffen sich die Teammitglieder für maximal 15 Minuten. Dabei präsentiert jeder, was er seit dem letzten Daily Scrum erledigt hat, was er bis zum nächsten Daily Scrum erledigen wird, und was ihn gebremst hat. Das Ziel des Treffens ist es, die Arbeit der Teammitglieder zu analsieren und gegebenenfalls die Vorgehensweise anzupassen. Die Analyse passiert während des Meetings; die Anpassung kann nach dem Treffen stattfinden. Das Team muss die Probleme also nicht während des Treffens lösen. Es genügt die Schwierigkeiten anzusprechen und zu entscheiden, welches Teammitglied sich darum kümmert.

Sprint-Review

Das Sprint-Review markiert das offizielle Ende des Sprints. Alle Stakeholder sind zu diesem Treffen eingeladen. Das Team zeigt, was es erreicht hat und demonstriert die Stories, die implementiert worden sind. Die Stakeholder können nun sehen, wie sich das Produkt durch diesen Sprint inkrementell verbessert hat. Sie können dem Team Feedback geben, wodurch das Produkt noch besser analysiert und angepasst werden kann. Das Sprint-Review sollte zwischen 30 und 60 Minuten lang sein für jede Woche, die der Sprint dauert. Wenn es dem Team nicht gelungen sein sollte, eine User Story zu implementieren, dann ist dies der Zeitpunkt, es den Stakeholdern mitzuteilen.

Rückschau

Am Ende eines Sprints hat das Team neben dem Sprint-Review ein weiteres Treffen: die Rückschau. Scrum unterstützt den Gedanken der kontinuierlichen Verbesserung. Die am Ende eines jeden Sprints stattfindende Rückschau ist die Zeit für das Team, was im Sprint gelernt wurde und wie das Gelernte angewendet werden kann, um Verbesserung zu erzielen. Die Rückschau dauert ein bis zwei Stunden für jede Woche Entwicklungszeit.

Es ist nicht Ziel der Rückschau, eine lange Liste mit Dingen zu erstellen, die gut oder schlecht gelaufen sind. Es genügt, ein oder zwei Dinge zu finden, die den nächsten Spring effektiver werden lassen.

Gemeinsame Code-Verantwortung

Im Scrum ist immer das gesamte Team für das gesamte Produkt und damit auch für den gesamten Quellcode verantwortlich. Dadurch soll sichergestellt werden, dass ein einheitlicher Programmierstil eingehalten wird und auch bei Austausch von Teammitgliedern das Team in allen Bereichen des Codes handlungsfähig bleibt.

Technische Praktiken

Kontinuierliche Integration

Zu den agile Praktiken gehört auch die “kontinuierlichen Integration”. Mit ihr will man erreichen, dass praktisch jederzeit ein – wenn auch unvollständiges, so doch lauffähiges – System zur Verfügung steht. Dazu teilt man die Implementierung so auf, dass jedes Implementierungs-Inkrement zu einem funktionalen Inkrement für das Gesamtsystem führt. Die Lauffähigkeit des Systems wird z.B. jede Nacht durch automatisierte Tests überprüft.

Test-getriebene Entwicklung

In der Softwareentwicklung hat es sich in vielen Fällen als hilfreich erwiesen, zuerst die Tests für ein Modul zu erstellen, bevor man das Modul selbst erstellt. Diese Vorgehensweise bietet einige Vorteile:

• Die Tests formulieren die Abnahmekriterien
• Funktionalität kann geklärt werden, bevor in die Implementierung investiert wird
• Es wird verhindert, dass auf die Erstellung von Tests aus Zeitmangel verzichtet wird
• Tests sind in Scrum ein wesentliches Mittel zur Qualitätssicherung

Refactoring (Umbau)

Mit “Refactoring” wird der strukturelle Umbau einer existierenden Code-Basis bezeichnet, bei dem sich das äußere Verhalten des Systems nicht ändert. Der Umbau findet in einer Reihe kleiner Schritte statt, in der Hoffnung, dass dabei auch nicht viel falsch laufen kann.

Refactoring wird vor allem dazu benutzt, Defizite im Design zu korrigieren. Anstatt sich vorab viel Gedanken zum Design eines Systems zu machen, nutzt man lieber später Refactoring zu Behebung von Designfehlern. Nur mit Hilfe automatisierter Tests kann nach einem Refactoring nachgewiesen werden, dass das Verhalten äquivalent zu dem vor dem Refactoring ist.

Weitere Informationen

Falls Sie interessiert sind mehr über Scrum Artefakte zu lesen, können Sie dies hier tun. In diesem Artikel können Sie eine Übersicht zu Agilem Projektmanagement sehen.