XP oder doch besser Scrum?

"Wir möchten agil arbeiten. Sollen wir XP oder Scrum verwenden?" Diese Frage bekommt man immer wieder gestellt. Die Antwort ist recht einfach - es ist nicht die Frage ob XP oder Scrum, denn man kann XP und Scrum nicht vergleichen!

" Scrum is an agile management methodology. Whereas XP is an agile engineering methodology. As such they are entirely complementary." Kelly Waters

Ich würd' sagen, das trifft es ziemlich genau.

"XP is Agile, but Agile is not XP..." Kelly Waters

The the beat - the XP beat

Bei eXtreme Programming arbeitet das Team selbstorganisierend und –regulierend. Jede Arbeit die anfällt, um eine Aufgabe zu lösen, wird vom Team geleistet. Während der gesamten Entwicklung folgt das Team einem gelegeltem Arbeitstakt: Plan->Do->Reflect->Improve.

Jede Iteration beginnt mit einem Planning Meeting. Anwesend ist das Team und der Product Owner. Das Team entscheidet, welche User Storys aus dem Product Backlog in der nächsten Iteration realisierbar sind. Aus der angenommenen Arbeit entsteht das Iteration Backlog. Das Team nimmt nur soviel Arbeit an, wie es leisten kann.

Nach mehreren Planning Meetings bekommt man ein Gefühl dafür, wieviel das Team an Arbeit pro Iteration leisten kann. Damit kann man einen Rückschluss auf die zuvor gemachte Releaseplanung ziehen und gegebenenfalls frühzeitig reagieren.

Nach dem Planning Meeting beginnt das Team mit der Umsetzung. In dieser Zeit ist das Team auf sich gestellt. Äussere Einflüsse werden vom Product Owner vom Team ferngehalten. Das Team fokussiert sich auf die angenommene Arbeit. Ziel ist es, aus jeder User Story ein fertiges und brauchbares Feature zu entwickeln.

Im Anschluss an die Iteration werden alle User Storys vom Team vorgeführt. Hier ist das Team, der Product Owner und alle sonstigen Projektinteressierten anwesend. Der Product Owner kann die entwickelten Features selbst verwenden oder sie vom Team vorführen lassen.

Nachdem alle User Story vorgeführt wurden, zieht sich das Team zurück und tauscht positive und negative Erfahrungen aus. Ziel ist es, positive Punkte in der kommenden Iteration zu wiederholen, negative zu vermeiden.

Nach der Team Reflection beginnt der Zyklus Plan->Do->Reflect->Improve erneut.

XP Series III - Let's go Kano

Das Team ist zusammengestellt, alle User Stories im Product Backlog aufgenommen, geschätzt und priorisiert. Womit soll begonnen werden? Eine Entscheidung, die mit einer vorausgegangen Zielgruppen- und Benutzerstudie einfach zu beanworten ist. Der Product Manager ist hier federführend.

Beim der Umsetzung wird mit den User-Storys begonnen werden, welche das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach werden diejenige User-Storys zu verwirklichen, die geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die User-Storys an, die geringes Risiko und geringen Nutzen auf sich vereinen. Die Fertigstellung von User-Storys mit geringem Nutzen aber hohem Risiko ist zu vermeiden. Zur Analyse wird das Kano-Modell verwendet.

Anschliessend beginnt das gesamte Team den Aufwand der User Stories zu schätzen. Hierfür werden Story Points verwendet, eine releative Kenngrösse, den Aufwand im Vergleich zu anderen User Stories wiederspiegelt. Es kann sein, dass erste Abschätzungen im Verlaufe des Projektes geändert werden.

Alle User Stories, mit Business Value und Risiko gewichtet und vom Team geschätzt, werden im Product Backlog festgehalten. Eine erste Releaseplanung aufgrund der Kano Analyse und der Aufwandschätzung und Zeitplanung wird vorgenommen.

Ausgehend vom Product Backlog in Verbindung mit der Release Planung beginnt das Team die User Storys in Iterationen umzusetzen.

XP Series II - Release It!

Extreme Programming, ein informelle, unverbindliche, agile Methode, die das Lösen einer Programmieraufgabe in den Vordergrund stellt. In einem vorherigen Post habe über XP im allgemeinen geschrieben, hier geht es nun um Release- und Iteration Planung.

Das Team plant die Arbeit in Releases und Interationen. Ein Release definiert ein Featureset und einen Termin. Die Features werden in Iterationen erarbeitet. Der Zeitpunkt der Fertigstellung wird als Zeitintervall verstanden und kann aufgrund der gewonnenen Erkenntnisse und des durchgeführten Fortschritts vom Team abgestimmt werden.

Innerhalb einer Iteration arbeit das Team an einzelnen Neuerungen, die durch User Storys, eine schlanke Form von Anwendungsfällen, beschrieben werden. User-Storys beschreiben die Funktionsanforderungen an ein System aus Sicht eines Users. Jeder User Story werden Prioritätswerte zugeordnet. Die Priorisierung wird vom Team gemeinsam mit dem Product Owner definiert und soll beschreiben, welche User-Storys dem Produkt den höchsten, respektive den niedrigsten Mehrwert bieten. Man spricht hier vom Business Value. Neben Business Value ordnet das Team jeder User Story eine Risikoabschätzung zu.

XP Series - All you need to operate

Agile, Scrum, XP und andere Begrifflichkeiten werden immer wieder im Zusammenhang mit Lean Software Development genannt. In den kommenden Posts werde ich mich dem Thema XP widmen.

Extreme Programming (XP) ist ein informelle und damit unverbindliche, agile Methode, die das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung stellt und die Formalisierung des Vorgehens vermindert.

Neben dem Entwickler gibt es bei Extreme Programming Prozess nur eine Person, den Product Owner. Der Product Owner kann ein Kunde, ein Nutzer des Systems oder ein Produktmanager bzw. Projektmanager sein. Innerhalb des Teams gibt es keine Rollenteilung. Der Product Owner steuert und leitet das Team.

Im Team sind alle Spezialisten vertreten, die notwendig sind, um eine Programmieraufgabe zu lösen: Analysten, Business Developer, Tester, Entwickler, DBA's, GUI Entwickler, WAI + Usability Guys – All you need to operate.

User Acceptance Testing

Nach Extreme Progromming (XP) ein wichtiger Ansatz, dass man erst einen Test schreibt, bevor man die Implementierung beginnt, auch bekannt als Test Driven Development (TDD).

Für die Durchführung von Tests gibt es diverse Frameworks, z.B. JUnit (Erich Gamma and Kent Beck, http://junit.org). Sie dienen in erster Linie für Integrationstest. Diese werden meistens nächtlich (nightly build) automatisiert durchlaufen und charakterisieren "Modul-" bzw. "Integrationstest". Sie sind technischer Natur und prüfen technische Belange, z.B. DB Connection, korrekte Berechnungen, CRUD Operationen auf Objekten, etc.

Zusätzlich gibt es (User) Acceptance Tests (UAT): Die Idee ist, dass man die entwickelten Features einer Applikation, die iterativ entwickelt wird, stetig einem Akzpeptanztest unterzieht. Geprüft wird, ob das entwickelte Feature das tut, was erwartet wird, was es tun soll. Dies kann der Product Owner oder ein (fremder) Benutzer des Systems verfizieren. Man spricht bei UAT von einem System-under-test (SUT).

Ward Cunningham hat dafür ein einfaches Framework entwickelt: FIT, Framework for Integrated Test: "Fit is a tool for enhancing communication and collaboration. Fit creates a feedback loop between customers and programmers. Fit allows customers and testers to use tools like Microsoft Office to give examples of how a program should behave--without being programmers themselves. Fit automatically checks those examples against the actual program, thus building a simple and powerful bridge between the business and software engineering worlds."[Quelle: http://fit.c2.com/wiki.cgi?IntroductionToFit]

Es ist sehr einfach die Acceptance Test zu definieren, gemeinsam mit dem Kunden/Product Owner, z.B. mit Excel.

FIT selbst basieren auf HTML, was sich leicht aus dem Excel Sheet generieren lässt. Fit Tools parsen einen speziellen HTML Syntax und verarbeiten diesen als Tests. Dafür muss pro Excel Tabelle ein "fixture" codiert werden.
Das ist sehr mühsam und bedeutet, dass man Development-Skills benötigt, um einen Test zu schreiben.

Selenium ist ein Tool, dass auf dem FIT HTML Syntax basiert, aber zunächst keine codierung von "fixture" benötigt. Es wurde ThoughtWorks entwickelt. Man kann mit der Selenium IDE als Browser plug-in Test einfach aufzeichnen.

Mit Selenium Remote Control besteht auch die Möglichkeit Test in einer beliebigen Sprache zu implementieren.