Mittwoch, 30. April 2008

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

Montag, 28. April 2008

Who the f** is Agnes?

Was versteht man unter Continuous Integration, einer der wesentlichen Bestandteile der agilen Softwareentwicklung.

Software wird meist von mehreren Entwicklern parallel geschrieben. Dazu kommt oft, dass man über mehr Standorte hinweg implementiert. Damit jeder Entwickler immer den neuesten Stand der Software hat, gibt es Source Control Werkzeuge (SVN, CVS, SourceSafe, etc.).

Der Sinn eines zentralen Repositories ist neben zentraller Codeverwaltung das Sicherstellen von Qualität: kontinuierlicher Build, Tests und Integration.

Was bedeutet das?
Man installiert neben dem Code Repository eine Software auf einer Maschine, die regelmässig folgende Tasks abläuft, z.B. nightly build:

* Code aus dem Repository auschecken
* Kompilieren
* Alle Test laufen lassen
* Report zusammenstellen
* Warten auf nächsten Build

Eine solche Software ist z.B Bamboo, CruiseControl oder continuum und Luntbuild.

Warum das ganze?
Man möchte an zentraller Stelle die Qualität der Software kontrollieren. Die Idee dahinter ist, dass man bei regelmässig erfolgreichen Build, Test und Integrations-Vorgängen auf relativ stabile Software schliessen kann. Durch den agilen Ansatz sind changes welcome, dass bedeutet in aller Regel, dass die Codebasis einem ständigen Refactoring unterliegt. Wenn man hier kein continuous integration betreibt ist man hoffnungslos verlohren.

Wie sieht das der Entwickler?
Implement ->Test -> Implement ->Test -> Implement ->Test und wer errät es - genau! Es geht immer so weiter. Am Ende einer Implementierung kommt dann der Checkin in das zentrale Code Repository. Vor dem Checkin muss der Entwickler einen Update machen, um den neuesten Code bei sich zu haben, zu kompilieren und zu testen, dass seine Änderungen die bisherige Version im Repo nicht kompromtieren. Wenn das nicht der Fall ist - Commit!

Von nun an kompiliert und testet die Continuous Integration Maschine meinen Code.

Und Agnes will keiner sehen! Wenn Sie kommt, dann man ne Runde Bier zahlen ....

Agnes and friends.

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.

Montag, 21. April 2008

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.

Mittwoch, 16. April 2008

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.

Dienstag, 15. April 2008

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.

Montag, 14. April 2008

Deadline - you are finally dead!

"Ich hab' eine Deadline und ein fixes Budget, hör' mir auf mit agil. Das ist doch Quatsch!" Aber Moment mal bitte!

Agiles Vorgehen steht in keinem Widerspruch zu einem fixierten Endtermin oder fixem Budget. Im Gegenteil! Ich würde sagen, dass man mit agil auf dem richtigen Weg ist, denn hier beginnt man gleich vom ersten Tag etwas nützliches zu produzieren. Gemäss agilem Takt, z.B. alle 3 Wochen, wird etwas präsentiert. Dannach wird die Arbeit für die kommenden 3 Wochen geplant und los geht es --- im 3 Wochentakt dem Ziel entgegen.

Budgetkontrolle? Kein Problem! Man kann die Kosten für 3 Wochen sehr gut vorausberechnen. Der ROI ist direkt messbar. Man kann früh etwaige Konzeptionsfehler erkennen und reagieren und - am aller wichtigsten - man kann bereits Ergebnisse vorweisen.

Donnerstag, 10. April 2008

Scrum Breakfast in Zürich, Lean Software Development, oder der optimale Weg vom Konzept zum Cash

Am 7. Mai 2008 findet wieder ein Scrum Breakfast in Zürich statt. Peter Stevens, Principal und zertifizierter Scrum Master, referiert über Lean Software Development.

Thema:
Dieser Vortrag schliesst den Kreis zwischen Agilität und Wettbewerbsfähigkeit auf der unternehmerischen Ebene mit Scrum und agile Software Entwicklung auf der operativen Ebene. Sie lernen, wie die Leitgedanken von Toyota mittels Scrum Ihre Agiliät und Wettbewerbsfähigkeit verbessern können.


Wann & Wo: 07.05.2008, 08:00 -- 10:00
namics ag, konradstrasse 12/14, 8005 Zurich (Map)

Anmeldung: xing.com

Wir sehen uns ...

Dienstag, 8. April 2008

Certified Scrum Master Training in Bern

SPRINT-IT Trainings veranstaltet am 02./03. Juni 2008 ein Certified ScrumMaster (CSM) Training in Bern, Schweiz, durchgeführt von Bob Schatz, Inhaber und Senior Consultant von Agile Infusion LLC, Philadelphia, PA USA. Der Kurs ist in englisch.

Sie verlassen das ScrumMaster Training mit einer neuen Einstellung und neuen Arbeitsansätzen. Das Training bietet Ihnen einen idealen Einstieg in die Scrum Welt. Es können Teammitglieder, Projektleiter, Teamleiter und Führungskräfte teilnehmen.

Zu den Kursdetails und Anmeldung

Freitag, 4. April 2008

Sprint Estimation

Ein bereits abgeschlossenes Projekt wird weiterentwickelt, allerdings mit neuem Team. Man kann auf die Informationen von 6 vergangenen Sprints zurückgreifen. Wie macht man nun ein Aufwandschätzung?

Im vorherigen Post habe ich darüber geschrieben, dass der Kunde uns den Auftrag gab, ein paar neue Ideen zu entwickeln, die als Features in die Web Applikation einfliessen könnten. Das Team hat daraufhin 21 neue User Stories formuliert. Der Kunde hat die User Stories reviewed, umformuliert, auf 11 User Stories zusammengefasst und priorisiert.

Um dem Team die Estimation zu erleichtern, haben wir folgende Eichung vorgenommen (Beträge sind exemplarisch):

Zunächst wurden die Gesamtkosten vom Sprint 7.1 plus Sprint 7.2 ermittelt: 35.000 GE.
Dem Betrag stehen 18 realisierte User Stories gegenüber, d.h. ca. 1.950 GE kostet eine User Story. Bei einem angenommenen Tagessatz von 700 GE und umgestellt auf 1 MT ergibt dass ca 0.3 User Stories pro Entwickler pro Tag. Mit dieser Eichgrösse geht das Team in die Estimation.

Das Backlog weisst anschliessend total 25 Story Points auf. Der geschätzte Gesamtaufwand, basierend auf dem vorliegenden Sprints lautet:

35.000 GE = 18 SP, 25 SP = x
x = 48.600 GE

Ich werde in einem der kommenden Posts berichten, wie es weitergeht.

Dienstag, 1. April 2008

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.