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.

Ein agiles Projekt geht weiter

Eine Web Applikation, die in einem agilen Projekt im vergangen Jahr konzipiert und fertiggestellt wurde, wird nun weiterentwickelt. Das Backlog ist gefüllt, alle User Stories sind geschätzt und der erste Sprint geplant. Ein neues Team steht vor der anspruchsvollen Aufgabe die Weiterentwicklung zu bewerkstelligen.

Bis zum letzten Release in 2007 (interne Bezeichnung: SOMMAR) wurden 80 Story Points in 5 Sprints abgearbeitet. Mit der Weiterentwicklung standen zum 29. Februar'08 20 Story Points verteilt auf 9 User Stories und 3 Bugs an. Das Team wurde auf 2 Entwickler reduziert, wobei ein Entwickler das Projekt nicht kannte. Aufgrund des kleineren Teams und dem notwenigen Wiederaufbau der gesamten Entwicklungsumgebung ist man zunächst im Sprint 7.1 von einer Velocity von 5 SP ausgegangen, ab Sprint 7.2 dann von 10 SP. Nach 2 Sprint sah das Ergebnis so aus:

Sprint 7.1: 5 SP geplant, 6 SP gleistet


Sprint 7.2: 10 SP geplant, 12 SP geleistet

Wir waren in der glücklichen Lage, dem Kunden zweimal hinterander zu informieren, dass wir vorzeitig fertig sind und er je noch eine User Story "gratis" haben kann.

Die Zufriedenheit und das Vertrauen des Kunden, auch ein Jahr nach erfolgreichem Abschluss des Projekts, konnte nachhaltig bestätigt werden. Das macht sich positiv bzw. negativ in den Zahlen bemerkbar - je nachdem wie man es betrachtet.

Wir, die Auftragnehmer, haben vom ursprünglich offerierten Aufwand nur 2/3 der Kosten verrechnen können, weil wir zu pessimistisch geschätzt haben. 1/3 vom Umsatz laut forecast wurde nicht erwirtschaftet! Kurzfristig betrachtet - nicht gut, aber mittel und langfristig ein dicker Nagel im Brett!

Der Kunde, sichtlich beeindruckt und zum wiederholten Mal mehr als zufrieden, beauftragte das Team selbst ein paar neue, coole und fancy Ideen zu entwickeln, die man als Feature in das Produkt einfliessen lassen könnte. Gesagt - getan!

Wie es weitergeht, werde ich in einem der nächsten Posts berichten.

Wie plant man einen Release?

Beim agilen Vorgehen geht man davon aus, dass nach jedem Sprint funktionierende und brauchbare Features bereit stehen, die in Betrieb genommen werden können. Wann macht man einen Release?

Die Arbeit für ein Scrum Projekt wird im Product Backlog manifestiert. Hier steht, was am Ende geliefert werden soll, zum Zeitpunkt "heute".

Product Backlog
Das Product Backlog definiert das Fernziel, das Ende der Reise. Es hat teilweise einen visionären Charakter. Alle Aufgaben auf dem Weg werden in Form von User Stories festgehalten. Ordnet man jeder User Story im Product Backlog einen Business Value zu, erhält man eine Kennzahl, die den betriebswirschaftlichen Nutzen wiederspiegelt. Ebenso wichtig sind die Wünsche und Erwartungen der eigentlichen Endbenutzer. Er /sie wird entscheiden, ob die Software brauchbar ist und man damit arbeiten kann oder nicht. Nur wenn sich für Product Owner und Endbenutzer einen Win-Win Situation einstellt, kann man von einem Erfolg sprechen. Um die Wünsche und Erwartungen der Endbenutzer herauszufinden, gibt es mehrere Möglichkeiten, die hier nicht näher beschrieben werden sollen.

Priorisierung
Mit Hilfe des Business Value und der Gewichtung der Endbenutzer kann man die User Stories im Product Backlog priorisieren - die Basis für viele Sprint Backlogs. Das Product Backlog gibt dem Product Owner die Möglichkeit, die Priorisierung der User Stories zu ändern, hinzuzufügen, zu löschen, den Business Value neu zu bewerten, User Stories zusammenzufassen oder zu spitten - Changes are welcome.

Sprint Backlog
Der Product Owner präsentiert vor jedem Sprint im Planning Meeting seine Wünsche und beantwortet damit die Frage, welche User Stories aus dem Product Backlog im kommenden Sprint bearbeitet werden sollen. Das Team ordnet jeder User Story einen Aufwand (Effort) zu und nimmt die Arbeit an, die machbar ist. Man definiert gemeinsam das Sprint Backlog für den kommenden Sprint. Aufgrund von Erfahrungswerten kann man in etwa abschätzen, wie viele User Stories in einem Sprint vom Team abgearbeitet werden können. Das Sprint Backlog ist für die Dauer des Sprints eingefroren.

Releaseplanung
Während alle User Stories im Product Backlog quasi das Fernziel beschreiben, werden in den Sprints einzelne Etappen geplant und umgesetzt. Nach wievielen Sprints ist man nun so weit, das man einen ersten Release machen kann? Die Antwort gibt wiederum der Endbenutzer! Prof. Noriaki Kano hat in den 80-iger Jahren ein Model entwickelt, mit dem man Kundenbedürfnisse kategorisiert und gewichtet - bis heute ein wichtiges Instrument in der Produktentwicklung - Kano Model. Kennt man die Basic, Performance und Exciter kann man ein Paket schnüren, um mit Release One in Produktion zu gehen.

Automatisierter Build und Deployment III

Um automatisch den letzten Stand auf dem Trunk und Release zu bauen und zu deployen verwende ich ein Shell Script, dass auf einer Linux Maschine mit Hilfe von crontab automatisiert wird. Ich richte auf der Linux Maschine jeweils ein User pro Projekt ein, somit ist es einfacher die Projekte sauber voneinander zu trennen.

Beispiel crontab:
[myproject@linux ~]$ crontab -l
45 5,12 * * * /home/myproject/build.sh all

Wenn man es noch ganz schön machen möchte, dann man mit maven eine Site generieren lassen, die man dann auf dem www-Root ablegt. Diese Site liefert dann Informationen zum Projekt, dem Team und der Source-Code Anbindung.

Automatisierter Build und Deployment II

Um auf einem Apache und einem Tomcat den trunk, release und tag parallel laufen lassen zu können, empfielt es sicht, mit viruellen Host zu arbeiten. Dafür sollte man den Apache per DNS auf die Staging Maschine zeigen lassen, z.B.

nslookup staging.myproject.company.com

Server:  dns.company.home

Address:  192.168.1.12

Non-authoritative answer:

Name:    linux.company.com

Address:  192.168.1.2

Aliases:  staging.myproject.company.com

Im Apache werden dann 3 virtuelle Hosts definiert: trunk, release und tag, z.B.:

VirtualHost  trunk.myproject.company.com:80 trunk.myproject.company.com:443>

 ServerAlias trunk.myproject.company.com

 ServerName trunk.myproject.company.com

 ServerAdmin sysadmin@company.com

 DocumentRoot /var/www/myproject/trunk

 ...

>

Analog wird das gleiche noch für release und tag definiert.

Der Tomcat bekommt pro Entwicklungsstand einen eigenen CATALINA_HOME. Dort wird die jeweilige Version deployed, z.B. das WAR file für Release 3.

Per Apache Rewrite Regeln kann man Requests auf ein einen Applikationskontext vom Apache an den Tomcat weiterleiten. 

Fertig! Jetzt kann man auf der gleichen Maschine drei unterschiedliche Entwicklungsstände zeigen. 

Im kommenden Post beschreibe ich, wie man das automatisiseren kann.

Release 3 ausgeliefert

Nach nur einem Sprint von 2 Wochen haben wir am Freitag den Release 3.0 ausgeliefert.
Das Team hat insgesamt 23 Story Points, verteilt auf 8 User Stories, angenommen und zu 100% fertiggestellt. Zusätzlich wurde ein Bug bearbeitet.

Die Velocity in diesem Sprint betrug 23- damit ergibt sich ein Durchschnitt bisher von 19 Story Points pro Release.

Seit Projektbeginn Anfang April 07 hat das Team 59 Story Points abgearbeitet.
Das Projekt wird am 15. Juni mit einen weiteren Release abgeschlossen. Es sind noch 13 Story Points geplant.

Release 2.0 erfolgreich ausgeliefert

Gestern, 22.05.07 haben wir den Release 2.0 (Anneboda) erfolgreich ausgeliefert. Wir haben daran zwei Sprints a eine Woche gearbeitet. Geplant war pro Sprint eine Velocity von 10 SP's. Es hat sich jedoch gezeigt, dass einwöchige Sprints nicht wirklich gut sind, denn es ist das Ziel am Sprint Ende alle User Stories auf DONE zu bringen. Wir konnten das nicht einhalten. Im ersten Sprint wurde lediglich eine User Story mit 1 SP abgeschlossen, im zweiten Sprint dann 5 weitere mit insgesamt 25 SP's. Damit wurden total 26 SP's für diesen Release realisiert. Wir werden zukünftig wieder Sprints a zwei Wochen planen - Velocity 20.

Ein alt bekanntes Problem gab es auch während dieses Releases - Resourcenlage. Es gab erneut wieder, sagen wir mal "flüchtige Resourcen". Teammitglieder wurden mal stunden-, mal tagweise abgezogen und es ist viel Arbeit liegengeblieben. Der Rest des Teams hat diese dann übernommen und fertiggestellt - immerhin fördert das den Teamzusammenhalt, auch wenn man beim Einen oder Anderen Säbelrasseln hört...

Was haben wir daraus gelernt? Nun ja, die Scrum Rituale sind wichtig! Bisher haben wir Estimation, Planning Meeting und Daily Scrum nicht nach Scrum durchgeführt. Hier war es eher so, dass ein kleiner Teil des Teams diese Meetings durchlaufen hat, nicht aber alle. Damit haben die Daily Scrum Meetings eher den Stil von "Du machst heute das!" (Weil ich es Dir sage!). Was passiert? Niemand übernimmt Verantwortung und klemmt sich hinter die Arbeit. Man bekommt auch keine Hindernisse oder Verzug gemeldet. Am Ende wird es eng und die Gemüter sind erhitzt!

Wir machen jetzt Planning Meeting mit allen Teammitgliedern und jeder wählt selbst, welche Arbeit er übernehmen möchte. "Scheissarbeiten" werden demokratisch verteilt, so kommt jeder mal in den Genuss. Jedem ist klar, dass er allein für die Fertigstellung der Aufgabe verantwortlich ist. Wenn Hindernisse auftauchen müssen diese in erster Linie selbst gelöst werden.

Wir arbeiten jetzt konzentrierter und fokussierter an den Aufgabe - ein guter Schritt nach vorn, wie ich finde.

Release 1.0 erfolgreich ausgeliefert

Am Montag 07.Mai 07 haben wir den ersten Release (Ecktorp) im neuen Scrum Projekt planmässig ausgeliefert. Alle Features, die geplant waren, wurden firstgerecht fertigestellt und in Produktion genommen. Der Kunde ist sehr zufrieden und hat mit dem Team die weiteren Schritte definiert.

Trotzdem der Release erfolgreich war, hatten wir einige Problem, die ich hier kurz erläutern möchte.

1. Sprint-Planung
   Von Begin an war klar, dass wir einen ersten Release nach ca. 3 Wochen in Betrieb nehmen werden. Das Produktbacklog bot genug Arbeit für ca. 3 Releases. Der Kunde hat ein Priorisierung der Features vorgegeben und das Team hat die Arbeit zunächst auf einen Sprint mit 3 Wochen mit 25 Story Points geplant. Ein weiterer Release steht in 2 Wochen an, was uns zur Frage bringt, wie man dass in eine Sprint Planung einbezieht. Wir haben für den 2. Release (Anneboda) zwei Sprints a eine Woche geplant. Die Problematik besteht nun darin, eine realistische Planung aufzustellen, denn man hat keinen Vergleich für die Sprint Geschwindigkeit (Velocity). Unsere Annahme ist, dass wir pro Woche 12 Story Points realisieren können. Wir werden sehen ...
   
2. Resourcenplanung
   Sprint 1 wurde mit einem Team von 4 Entwicklern geplant. Wir haben die User Stories aufgeteilt und parallel an Features gearbeitet. Nach ca. 1 1/2 Wochen hat sich die Resourcenlage leider verschlechtert - es wurden 2 Teammitglieder abgezogen. Nun, was ist passiert? Ein Scrum Teammitglied arbeitet weitestgehend eigenverantwortlich. Wenn jemand das Team während des Sprints verlässt, hinterlässt man begonnen Arbeit in einem mehr oder weniger unklarem Zustand. Wir haben also in der Hälfte des Sprints die Strategie zur Abarbeitung der User Stories verändert und auf Stabilität statt Menge gesetzt - sprich den Umfang reduziert. Der Rest vom Team hat die liegengebliebene Arbeit (grossteils durch Überstunden) auf DONE bringen können. So haben wir es trotz nicht geplanter Lage geschafft, alle gewünschten Features fertigzustellen. Das hat nur funktioniert, weil das Team bereits mit dem Scrum Vorgehensmodell vertraut ist und technologisch sattelfest ist. Wenn das Know-How nicht homogen verteilt ist, ist eine solche Lage durchaus als riskant einzustufen.
   
3. Prototype
   In der Offerte wurden bereits Screen/Design Vorschläge offeriert. Unmittelbar zum Projektbeginn hat der Kunde das Design abgenommen. Daraufhin wurde ausserhalb des Scrum Teams ein HTML Prototype realisiert. Als das Scrum Team die Arbeit aufgenommen hatte, ergaben sich die ersten Probleme. Das Design war für eine Website, nicht aber für eine Webapplikation ausgelegt. Klassiker, wie Links, die einen Form Submit auslösen, Breadcrumb Trail in einer Applikation, Dialoge, die keine Dialoge sind, etc. wurde falsch gemacht. Somit konnte das Team nur verzögert mit der Arbeit beginnen. Dazu kam, dass der Kunde das Design abgenommen hatte und nunmehr bereits nach wenigen Tagen schon ein Re-Design besprochen werden musste, bevor überhaupt Features realisiert werden konnten. Der Kunde war sichtlich irritiert - verständlich! Daher die Empfehlung einen Applikationsdesigner von Beginn an einzusetzen. Es ist sicher auch hilfreich ein Developer über das Design schauen zu lassen - das hat sich in der Vergangenheit immer bewährt.

Was vielleicht noch erwähnenswert ist: wir haben die Scrum Rituale auf eine Minimum beschränkt. Wir machen täglich ein 15-minütiges Stand-up Meeting, Sprint und Release Planung und eine Retrospective bei einem Bier am Abend. Wir setzten Target Process ein, beschränken uns aber nur auf die Funktionen für Release und Sprint Planung, sowie User Stories und Bugs. Sonst kommen keine weiteren Tools zum Einsatz.