Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Agile Methoden im Kurzüberblick: Extreme Programming (XP) und Scrum

Die folgende Beschreibungen agiler Methoden dienen zum Verständnis, da in der weiteren Arbeit des Öfteren darauf eingegangen wird. Es wird kein Methode im Detail betrachtet, da der Fokus der Arbeit auf das Requirements Engineering gerichtet ist. Die zahlreichen Methoden stammen zumeist von Autoren, die maßgeblich an der Definition des agilen Manifests 2001 beteiligt waren.

Extreme Programming (XP)

Kent Beck, einer der Entwickler, bezeichnet Extreme Programming, kurz XP, als eine effiziente, risikoarme, flexible, berechenbare, wissenschaftliche und spaßige Möglichkeit, Software zu entwickeln. XP setzt sich in seiner ersten Fassung aus drei Elementen, den XP-Werten (values), XP-Prinzipien (basic principles) und den XP-Konzepten (practices) zusammen und stellt als agiles Modell die Menschen, d.h. alle Projektbeteiligten in den Mittelpunkt. Dies spiegelt sich in den Werten Einfachheit, Feedback, Kommunikation und Mut wieder, auf denen XP basiert.

Bildergalerie

XP ist ein sehr strenger und disziplinierter Entwicklungsprozess, der sich aber unter anderem durch seine iterative Vorgehensweise von klassischen Modellen klar unterscheidet. Als Methode eignet sich XP für kleine und mittlere Teams bis zu 15 Personen. Sie besteht aus einer Reihe einfacher, aber eng zusammengehöriger Praktiken wie z.B. Pair-Programming. Hier wird jede Software immer in Teams zu je zwei Personen entwickelt, wobei einer kodiert und der zweite kontrolliert. Die Entwicklung in XP ist testgetrieben, d.h. die Entwickler formulieren zuerst die Testfälle, anschließend den Code.

In XP ersetzen die Testfälle die genaue Spezifikation der Anforderungen, sowie den Entwurf. Die Testfälle werden direkt aus User Stories abgeleitet. XP ist unter anderem durch die testgetriebene Entwicklung und das Pair-Programming eine Methode, die extreme Qualitätssicherung fordert. Durch die fehlende Dokumentation ist es sehr schlank, was sich aber ggf. nachteilig auf die Wartung auswirken kann. Die damit eingesparten Kosten können durch Techniken wie Pair-Programming wieder erhöht werden.

Scrum: der De-facto-Standard

Bei Scrum handelt es sich ebenfalls um einen agilen Ansatz, der den Menschen in den Mittelpunkt der Softwareentwicklung stellt. Im Vergleich zu XP ist es nicht technologie- oder tool-orientiert, sondern beschränkt sich auf das Management der Projekte, also die Zusammenarbeit der Beteiligten. Mittlerweile ist Scrum zum De-facto-Standard in der agilen Entwicklung gereift. Scrum besteht aus wenigen klaren Regeln und verfügt über drei Rollen.

Produkt Owner: Er trägt die wirtschaftliche Verantwortung und steuert diese über das priorisierte Produkt Backlog und den Releaseplan. Dabei vertritt er das Projektteam nach außen, z.B. zum Auftraggeber und steuert es aus fachlicher Sicht. Er plant und entscheidet welche Features im nächsten Iterationsschritt, dem sogenannten Sprint, realisiert werden, aber nicht wie. Er arbeitet eng mit dem Team zusammen und sollte daher passiv die täglichen Treffen, Daily Scrum genannt, besuchen.

Scrum Team: Ein Scrum Team organisiert sich selbst, hat also keinen Team-Leiter und sollte so zusammengestellt sein, dass alle anfallenden Herausforderungen gelöst werden können. Aufgrund der engen Zusammenarbeit im Team, müssen die Arbeitsplätze der Mitarbeiter räumlich nahe beieinander liegen, möglichst sogar im selben Raum.

Scrum Master: Die Hauptaufgabe eines Scrum Masters ist die Unterstützung der Beteiligten, um ein Scrum Projekt korrekt durchzuführen und alle Hindernisse zu beseitigen. Er ist nicht Teil des Scrum Teams, moderiert aber die sogenannten Daily Scrum und sorgt dafür, dass die zentralen Scrum-Dokumente aktuell gehalten werden. Ob die Einführung von Scrum gelingt ist stark von den persönlichen Fähigkeiten des Scrum Masters abhängig, da dieser die wichtigste Rolle im Scrum-Prozess bekleidet.

Scrum enthält nur wenige, aber dafür wichtige Dokumente. Das Produkt Backlog, als wichtigstes Dokument, wird aufgrund seiner hohen Relevanz im agilen Requirements Engineering Prozess später in diesem Beitrag genauer erklärt. Alle Anforderungen, die in der nächsten Iteration umgesetzt werden sollen, werden vom Produkt Backlog in das Sprint Backlog übernommen, welches täglich aktualisiert wird. Für die Dokumentation des Arbeitsfortschrittes während eines Sprints ist der Sprint-Burndown-Bericht zuständig. Am Ende eines jeden Sprints wird ein Sprint-Endbericht erstellt, der widerspiegelt, was umgesetzt wurde und was nicht. Speziell in größeren Projekten wird zudem ein Release-Plan und ein Release-Burndown-Bericht erstellt.

Bei Scrum handelt es sich um einen rollenbasierten, iterativen und inkrementellen Prozess, der in Abbildung 2 inklusive der genannten Dokumente und ihrer Zusammenhänge veranschaulicht wird. Die Release-Planung außen vor gelassen, werden Anforderungen aus dem Anforderungsworkshop ins Produkt Backlog überführt. In der Sprint-Planung werden anschließend einzelne Anforderungen für den nächsten Sprint vorgehen und in das Sprint Backlog übernommen. Die Umsetzung wird in den täglichen Daily Scrums besprochen bzw. überwacht und im Sprint Burndown dokumentiert. Sofern der Sprint abgeschlossen ist, also ein neues Produktinkrement fertiggestellt ist, wird der Sprint-Endebericht erstellt.

Laut (Gloger, 2010) erleben viele Organisationen durch Scrum erhöhte Produktivität ihrer Softwareentwicklungsteams: "Der Paradigmenwechsel hat in diesen Firmen begonnen, und sie erleben eine gesteigerte Produktivität bei höherer Zufriedenheit ihrer Mitarbeiter. Damit ist Scrum aus der modernen Softwareentwicklung nicht mehr wegzudenken“.

(ID:42704398)