5
WELCHE AGILE METHODE FÜR WEN? VON ZIELEN UND VORAUS- SETZUNGEN ZUR OPTIMALEN METHODE schiedliche Projekt-Settings unterschiedli- che Herangehensweisen erfordern. Scrum Scrum (vgl. [Sch02]) setzt den Schwerpunkt auf Managementtechniken (Schätzen, Planen, Tracking); wie das Entwicklungs- team seine tägliche Arbeit verrichtet, wird hingegen nicht adressiert. Scrum geht davon aus, dass alle auftre- tenden Anforderungen in einer priorisier- ten Liste, dem so genannten Product Backlog gesammelt werden. Der Product Backlog wird von einer Person, dem Product Owner geführt. Dieser vertritt die Kundenseite in einem Scrum-Projekt. Eine Iteration wird in Scrum Sprint genannt. Die vorgeschlagene Länge eines Sprints beträgt 30 Tage (mittlerweile hat sich eine Sprint- Länge von einer bis sechs Wochen etabliet). Zu Beginn des Sprints wird in einem Meeting der Umfang festgelegt, der wäh- rend der Iteration entwickelt werden soll. Dazu werden die am höchsten priorisierten Anforderungen des Product Backlogs in eine neue Liste, den so genannten Sprint Backlog, überführt. Der Inhalt des Sprint Backlogs wird während des Sprints nicht mehr geändert. Schematisch ist dieser Ablauf in Abbildung 1 dargestellt. Agile Methoden sind heute Stand der Kunst bei Softwareentwicklungsprozessen, denn ihre Vorteile, wie Transparenz, Flexibilität und schneller ROI, sind unbestrit- ten. Aber es gibt viele Teams, denen die Einführung agiler Methoden noch bevor- steht. Für sie ist es nicht einfach zu entscheiden, an welcher agilen Methode und welchen agilen Praktiken sie sich bei der Einführung orientieren sollen. Dieser Artikel soll hier Hilfestellung geben. Er regt aber auch agil Erfahrene an, darüber nachzudenken, ob vielleicht für ihre Bedürfnisse und ihr Projekt-Setting neue Impulse aus bisher weniger bekannten Methoden manchmal besser geeignet wären. mehr zum thema: www.it-agile.de www.agilesoftwareentwicklung.de 40 41 Anschließend geben wir – in Ab- hängigkeit von den Zielen der Einführung (Qualität, Flexibilität etc.) und den organisatorischen Voraus- setzungen (Teamorganisation, Projekt- größe etc.) – Empfehlungen. Schwerpunkte der Methoden Jede agile Methode setzt einen eigenen Schwerpunkt, der bereits einen ersten Hinweis darauf liefert, ob die Methode zu einem Unternehmen, Team oder Projekt passt. Die Auswahl der im Folgenden betrachteten vier agilen Methoden haben wir wie folgt getroffen: Scrum und XP sind die mit Abstand populärsten und bekann- testen agilen Methoden im deutschsprachi- gen Raum. FDD ist weniger bekannt, unter- scheidet sich aber in Schwerpunktsetzung und Projektorganisation stark, sodass es für viele Unternehmen eine Alternative darstel- len kann. Crystal ist als Methodenfamilie hilfreich für das Verständnis, dass unter- Aus unserer Beratungspraxis wissen wir, dass kein Unternehmen und kein Team dem ande- ren gleicht – und erst recht kein Projekt dem anderen. Das führt auch bei der Einführung oder Durchführung agiler Softwareent- wicklung dazu, dass es nicht eine gültige Antwort auf alles gibt. Wir gehen daher von individuellen Anpassungen des Entwick- lungsprozesses je Projekt aus, aber erst agil erfahrene Teams können diese alleine durch- führen. Diese vermeintliche Beliebigkeit birgt die Gefahr, dass agile Praktiken völlig unpas- send miteinander kombiniert werden. Daher ist es sinnvoll, bei der Einführung agiler Methoden mit der Einführung einer vorhan- denen Methode zu beginnen, an der man sich gut orientieren kann. Die Methoden enthal- ten nämlich eine passende und erprobte Zusammenstellung agiler Praktiken. Auch und gerade für das Erlernen einer neuen Methode ist Orientierung wichtig – und sogar wichtiger als die sofortige individuelle Anpassung bzw. Optimierung. Wir suchen also nach der passenden agi- len Startmethode und nähern uns dieser in diesem Artikel mit folgenden Schritten: Zuerst stellen wir kurz und knapp die Schwerpunkte der vier agilen Metho- den Scrum, XP, FDD und Crystal vor 1 ). fachartikel Henning Wolf (E-Mail: [email protected]) ist Geschäftsführer der akquinet it-agile GmbH. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten als Entwickler, Projektleiter und Berater und hilft Unter- nehmen, agile Methoden erfolgreich einzuführen. Christoph Kemp (E-Mail: [email protected]) ist Senior Softwareentwickler bei der akquinet it-agile GmbH und arbeitet seit Jahren in agilen Projekten nach Scrum, Crystal und XP. die autoren 1 ) Es gibt noch weitere agile Ansätze wie z. B. „Lean Development“, „Adaptive Software Development“ (ASD) und „Dynamic Systems Development Method“ (DSDM), auf die hier nicht näher eingegan- gen wird. Diese Ansätze sind im deutschsprachigen Raum bisher wenig verbreitet und wir selber haben mit ASD und DSDM bisher keine konkreten Projekterfahrungen.

WELCHE AGILE METHODE FÜR WEN? SETZUNGEN ZUR ......„Crystal Clear“ (vgl. [Coc04]), das auf Teams von sechs bis acht Teammitgliedern optimiert ist. Knappere Beschreibungen existieren

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: WELCHE AGILE METHODE FÜR WEN? SETZUNGEN ZUR ......„Crystal Clear“ (vgl. [Coc04]), das auf Teams von sechs bis acht Teammitgliedern optimiert ist. Knappere Beschreibungen existieren

WELCHE AGILEMETHODE FÜR WEN?VON ZIELEN UND VORAUS-SETZUNGEN ZUR OPTIMALENMETHODE

schiedliche Projekt-Settings unterschiedli-che Herangehensweisen erfordern.

ScrumScrum (vgl. [Sch02]) setzt den Schwerpunktauf Managementtechniken (Schätzen,Planen, Tracking); wie das Entwicklungs-team seine tägliche Arbeit verrichtet, wirdhingegen nicht adressiert.

Scrum geht davon aus, dass alle auftre-tenden Anforderungen in einer priorisier-ten Liste, dem so genannten ProductBacklog gesammelt werden. Der ProductBacklog wird von einer Person, demProduct Owner geführt. Dieser vertritt dieKundenseite in einem Scrum-Projekt. EineIteration wird in Scrum Sprint genannt. Dievorgeschlagene Länge eines Sprints beträgt30 Tage (mittlerweile hat sich eine Sprint-Länge von einer bis sechs Wochen etabliet).Zu Beginn des Sprints wird in einemMeeting der Umfang festgelegt, der wäh-rend der Iteration entwickelt werden soll.Dazu werden die am höchsten priorisiertenAnforderungen des Product Backlogs ineine neue Liste, den so genannten SprintBacklog, überführt. Der Inhalt des SprintBacklogs wird während des Sprints nichtmehr geändert. Schematisch ist dieserAblauf in Abbildung 1 dargestellt.

Agile Methoden sind heute Stand der Kunst bei Softwareentwicklungsprozessen,denn ihre Vorteile, wie Transparenz, Flexibilität und schneller ROI, sind unbestrit-ten. Aber es gibt viele Teams, denen die Einführung agiler Methoden noch bevor-steht. Für sie ist es nicht einfach zu entscheiden, an welcher agilen Methode undwelchen agilen Praktiken sie sich bei der Einführung orientieren sollen. DieserArtikel soll hier Hilfestellung geben. Er regt aber auch agil Erfahrene an, darübernachzudenken, ob vielleicht für ihre Bedürfnisse und ihr Projekt-Setting neueImpulse aus bisher weniger bekannten Methoden manchmal besser geeignetwären.

m e h r z u m t h e m a :www.it-agile.dewww.agilesoftwareentwicklung.de

40 41

■ Anschließend geben wir – in Ab-hängigkeit von den Zielen derEinführung (Qualität, Flexibilität etc.)und den organisatorischen Voraus-setzungen (Teamorganisation, Projekt-größe etc.) – Empfehlungen.

Schwerpunkte der MethodenJede agile Methode setzt einen eigenenSchwerpunkt, der bereits einen erstenHinweis darauf liefert, ob die Methode zueinem Unternehmen, Team oder Projektpasst. Die Auswahl der im Folgendenbetrachteten vier agilen Methoden habenwir wie folgt getroffen: Scrum und XP sinddie mit Abstand populärsten und bekann-testen agilen Methoden im deutschsprachi-gen Raum. FDD ist weniger bekannt, unter-scheidet sich aber in Schwerpunktsetzungund Projektorganisation stark, sodass es fürviele Unternehmen eine Alternative darstel-len kann. Crystal ist als Methodenfamiliehilfreich für das Verständnis, dass unter-

Aus unserer Beratungspraxis wissen wir, dasskein Unternehmen und kein Team dem ande-ren gleicht – und erst recht kein Projekt demanderen. Das führt auch bei der Einführungoder Durchführung agiler Softwareent-wicklung dazu, dass es nicht eine gültigeAntwort auf alles gibt. Wir gehen daher vonindividuellen Anpassungen des Entwick-lungsprozesses je Projekt aus, aber erst agilerfahrene Teams können diese alleine durch-führen. Diese vermeintliche Beliebigkeit birgtdie Gefahr, dass agile Praktiken völlig unpas-send miteinander kombiniert werden. Daherist es sinnvoll, bei der Einführung agilerMethoden mit der Einführung einer vorhan-denen Methode zu beginnen, an der man sichgut orientieren kann. Die Methoden enthal-ten nämlich eine passende und erprobteZusammenstellung agiler Praktiken. Auchund gerade für das Erlernen einer neuenMethode ist Orientierung wichtig – undsogar wichtiger als die sofortige individuelleAnpassung bzw. Optimierung.

Wir suchen also nach der passenden agi-len Startmethode und nähern uns dieser indiesem Artikel mit folgenden Schritten:

■ Zuerst stellen wir kurz und knapp dieSchwerpunkte der vier agilen Metho-den Scrum, XP, FDD und Crystal vor1).

f achar t i ke l

Henning Wolf

(E-Mail: [email protected])

ist Geschäftsführer der akquinet it-agile

GmbH. Er verfügt über langjährige Erfahrung

aus agilen Softwareprojekten als Entwickler,

Projektleiter und Berater und hilft Unter-

nehmen, agile Methoden erfolgreich

einzuführen.

Christoph Kemp

(E-Mail: [email protected])

ist Senior Softwareentwickler bei der akquinet

it-agile GmbH und arbeitet seit Jahren in

agilen Projekten nach Scrum, Crystal und XP.

d i e au toren

1) Es gibt noch weitere agile Ansätze wie z. B. „LeanDevelopment“, „Adaptive Software Development“(ASD) und „Dynamic Systems DevelopmentMethod“ (DSDM), auf die hier nicht näher eingegan-gen wird. Diese Ansätze sind im deutschsprachigenRaum bisher wenig verbreitet und wir selber habenmit ASD und DSDM bisher keine konkretenProjekterfahrungen.

Page 2: WELCHE AGILE METHODE FÜR WEN? SETZUNGEN ZUR ......„Crystal Clear“ (vgl. [Coc04]), das auf Teams von sechs bis acht Teammitgliedern optimiert ist. Knappere Beschreibungen existieren

5 / 2 0 0 8

Scrum legt auch während des Sprints gro-ßen Wert auf Transparenz. So ist jedesTeammitglied dafür verantwortlich, denaktuellen Stand seiner Arbeit durch regel-mäßiges Tracking – d. h. verbrauchte Zeitfür einen Task und geschätzte verbleibendeZeit bis zur Fertigstellung – sichtbar zumachen. Auch finden täglich sehr kurzeInformationsmeetings statt, die so genann-ten Daily Scrums. Jedes Teammitglied gibtdabei kurz Auskunft darüber, was es seitdem letzten Meeting getan hat, was gege-benfalls behindernd auf seine Arbeitgewirkt hat und was es sich bis zum näch-sten Daily Scrum vorgenommen hat.

Am Ende des Sprints muss immer aus-führbare und potenziell auslieferbareSoftware stehen. Diese wird in einemMeeting, dem Sprint Review Meeting, alleninteressierten Personen präsentiert. Aufdieser Basis kann dann von den Ver-antwortlichen entschieden werden, wie esmit dem Projekt weitergeht.

Scrum kennt mit dem Scrum-Master einespezielle Rolle, die für die Einhaltung derScrum-Regeln und das Beseitigen auftre-tender Hindernisse für das Team zuständigist.

XPExtreme Programming (XP) ist eine„Komplettmethode“, die Praktiken für dengesamten Entwicklungsprozess vorschlägt(vgl. [Bec04], [Wol05]). Diese Praktikenbeschreiben direkt, was von wem auf wel-che Art und Weise im Projekt zu tun ist.Dazu liefert XP ein Wertesystem und eine

Reihe von Prinzipien, die im Projekt alsEntscheidungshilfen dienen können, wennFragen entstehen, auf die XP nicht soforteine Antwortet bietet.

Der Schwerpunkt von XP liegt auf derErstellung qualitativ hochwertiger lauffähi-ger Software. Dafür bietet XP viele sinn-volle Praktiken an: vom Programmieren inPaaren, über testgetriebene Entwicklungund inkrementellem Design, bis hin zu kon-tinuierlicher Integration und Zehn-Minu-ten-Builds. XP geht von Teams mit qualifi-zierten Entwicklern aus, die in der Lagesind, bei der Entwicklung ständig einSystem zu hinterlassen, das – im Sinne vonErweiterbarkeit und Anpassbarkeit – hoch-gradig wartbar bleibt. So können die heutenoch nicht bekannten Anforderungen vonmorgen schnell und sicher umgesetzt wer-den. Ein Teil des Zusammenspiels der XP-Praktiken zeigt Abbildung 2.

Der Managementprozess von XP ähneltdem von Scrum. Statt Backlog-Items gibt esbei XP die Anforderungen in Form vonUser-Storys, die Iterationen erfolgen imWochentakt (statt der Scrum-Sprints vonein bis sechs Wochen); zusätzlich gibt eseinen expliziten Release-Zyklus mit einemVorschlag, sich am Quartal zu orientieren.

XP ist recht komplex, liefert aber kon-krete Hilfestellung zur Erstellung vonQualitätssoftware und kann durchausschrittweise eingeführt werden. Dies kannnicht immer auf der Ebene einzelnerPraktiken erfolgen, stattdessen müssenmanchmal einige wenige Praktiken sinnvol-lerweise zusammen eingeführt werden.

Feature Driven DevelopmentBeim Feature Driven Development (FDD)(vgl. [DeL08]) liegt der Schwerpunkt expli-zit auf Festpreisprojekten. Dabei verlangtFDD kein Lastenheft, sondern besteht imGegenteil sogar darauf, dass es eine ge-meinsame Modellierungsphase von Fach-experten (mit Entscheidungskompetenz),Modellierern und Entwicklern gibt, in derdas fachliche Gesamtmodell entsteht.Außerdem entsteht dabei das Verständnis,welche Features später am System benötigtwerden, sodass diese Features auch aufge-schrieben werden können. Dabei gilt eineHöchstgrenze für Features: Sie müssen inmaximal 14 Tagen umsetzbar sein. DieFeature-Liste ist Vertragsgegenstand fürden Festpreis. Auf Basis der Feature-Listekann mit dem Verständnis aus demModellierungsworkshop eine verbindlicheSchätzung abgegeben werden.

Für die Entwicklung wird dann ein Planerstellt, der sich auf der einen Seite daranorientiert, dass einzelne Entwickler für einzel-ne Klassen – und damit Konzepte des Fach-modells – zuständig sind und Klassenbesitzerwerden. Andererseits orientiert sich diePlanung an Features. Über eine Zuordnungder Features zu beteiligten Klassen ergibt sichpro Feature dynamisch ein Feature-Team,d. h. die Klassenbesitzer aller zur Erledigungdes Features benötigter Klassen.

Der Entwurf und die Implementierung desFeatures erfolgt dann im Feature-Team, dassich zusammensetzt und und gemeinsam denEntwurf für dieses Feature ausarbeitet.Schließlich konstruiert jeder Klassenbesitzerentsprechende Änderungen und Erwei-terungen an seinen Klassen und die Qualitätwird mittels Design- und Code-Reviews wie-

f achar t i ke l

Abb. 1: Scrum im Überblick.

Abb. 2: Feedback zu jeder Zeit mit XP.

Page 3: WELCHE AGILE METHODE FÜR WEN? SETZUNGEN ZUR ......„Crystal Clear“ (vgl. [Coc04]), das auf Teams von sechs bis acht Teammitgliedern optimiert ist. Knappere Beschreibungen existieren

das Ziel, laufende Software zu liefern,erreichen kann. So werden in Crystal auchnur Praktiken vorgeschlagen, aber abgese-hen von der Retrospektive ist keine dieserPraktiken Pflicht. Getreu dem Grundsatz,dass der Prozess dem Team gehört, ent-scheidet in Crystal das Team, durch welchePraktiken seine Arbeit am besten unter-stützt wird. Das stellt einen deutlichenUnterschied beispielsweise zu XP dar.

Übrigens ist XP – ergänzt um ein Min-destmaß an Dokumentation – eine gültigeAusprägung einer Crystal-Methode fürkleine Teams. Auch dies macht denCharakter von Crystal als Meta-Methodedeutlich. Die Crystal-Methodenfamilie istmomentan nicht für alle Teamgrößen ingleicher Ausführlichkeit beschrieben. Dieausführlichste Beschreibung existiert für„Crystal Clear“ (vgl. [Coc04]), das aufTeams von sechs bis acht Teammitgliedernoptimiert ist. Knappere Beschreibungenexistieren für „Crystal Yellow“ (optimiertauf etwa 20 Personen, vgl. [Coc06]) und„Crystal Orange“ (optimiert auf etwa 40Personen, vgl. [Coc97]).

Entscheidungen anhandder ZielsetzungDie Schwerpunkte der hier vorgestellten vieragilen Methoden geben sicherlich schon einegewisse Richtung vor, für wen welche Me-thode geeignet sein könnte. Vielleicht habenauch Sie bereits einen Favoriten. In diesemAbschnitt wollen wir anhand von Zielen, diemit der Einführung agiler Methoden verbun-den werden, eine Empfehlung aussprechen,welche Methoden für welche Ziele geeignetoder weniger geeignet sind.

Die wirklich gute Nachricht zuerst: Alleagilen Methoden zeichnen sich dadurchaus, dass der Projektfortschritt sehr trans-parent und realistisch anhand von lauffähi-ger Software beurteilt werden kann.

Ähnliches gilt für den schnellen System-einsatz, mit dem auch ein schneller ROI(Return on Investment) verbunden ist. Diesmag bei FDD vielleicht am wenigsten aus-geprägt sein, aber auch dort sind früheReleases möglich; bei einer Gesamtlaufzeitvon maximal sechs Monaten kann vonlangsam sowieso noch nicht gesprochenwerden. Wichtig ist es hier aber, immer zubedenken, dass der schnelle Systemeinsatzauch davon abhängt, dass die fachlichenAnforderungen in kleinere Releases ge-schnitten werden. Das wäre dann eigentlichauch mit klassischen Ansätzen umsetzbar,die allerdings mit der darauf folgenden

42 43

(Management) eines Projekts, sondernauch Fragen der täglichen Entwicklungs-arbeit adressiert werden.

Bei Crystal wird besonderer Wert daraufgelegt, dass verschiedene Projekt-Settingsauch verschiedene Methoden benötigen.Besondere Beachtung finden dabei unter-schiedliche Teamgrößen, für die dann indi-viduelle Maßnahmen vorgeschlagen wer-den (siehe Abb. 4). In diesem Sinne istCrystal eigentlich nicht eine Methode, son-dern eine Methodenfamilie, deren Fami-lienmitglieder individuell auf die Be-dürfnisse der jeweiligen Projekte undTeams abgestimmt sind.

Um dies zu ermöglichen, räumt Crystalbeim Erstellen und Anpassen der Methodemaximale Freiheitsgrade ein und stellt nurdie nötigsten Regeln auf, sodass ein Projekt

der im Feature-Team gesichert. Gege-benenfalls ist beim Design oder bei denReviews auch der Chefentwickler anwesend.Schematisch ist die Abfolge der FDD-Teilprozesse in Abbildung 3 dargestellt.

FDD folgt eher einem klassischen undrecht hierarchischen Ansatz – trotzdemkann je nach Konstellation die Freiheit derFeature-Teams recht groß sein. FDD-Projekte dauern maximal sechs Monate.Jeff De Luca, der „Erfinder“ von FDD, hatdiese Festlegung getroffen, weil er der Über-zeugung ist, dass Anforderungen nicht län-ger als sechs Monate stabil bleiben können.

CrystalGenau wie XP und FDD – und anders alsScrum – ist Crystal in dem Sinne vollstän-dig, dass nicht nur ein Teilaspekt

f achar t i ke l

Abb. 3: Parallelität der Teilprozesse für Entwurf und Konstruktion bei FDD.

Abb. 4: Kategorisierung der Crystal-Methoden nach Projekteigenschaften.

Page 4: WELCHE AGILE METHODE FÜR WEN? SETZUNGEN ZUR ......„Crystal Clear“ (vgl. [Coc04]), das auf Teams von sechs bis acht Teammitgliedern optimiert ist. Knappere Beschreibungen existieren

5 / 2 0 0 8

Weiterentwicklung erfahrungsgemäß denBereich des Planbaren verlassen.

In Sachen Planbarkeit überraschen agileMethoden vermutlich viele Zweifler mitdurchaus vorhandenen Plänen, die zwarmeist weniger detailliert ausfallen als klassi-sche Pläne, dafür aber realistischer sind unddie Flexibilität bieten, im Iterationsrhythmusangepasst werden zu können, wenn dies imProjektverlauf nötig wird. Agile Pläne kön-nen durchaus auch eine Roadmap für dieReleases der nächsten zwei Jahre darstellen,aber sie können nie exakt die Funktionalitätversprechen, die in zwei Jahren existierenwird. Aber auch klassische Pläne gaukeln diesja zumeist nur vor.

Wenn die Flexibilität im Umgang mit denAnforderungen im Vordergrund steht, sindScrum, XP und Crystal die geeignetenKandidaten. FDD geht hier von einemanderen Takt und weniger Flexibilität zurProjektlaufzeit aus. Die Gefahren zu hoherFlexibilität („Entwicklung auf Zuruf“)adressieren agile Methoden meist durchTime-Boxing, also Zeiträume von zumin-dest einer bis vier Wochen, in denen sichdie Anforderungen nicht ändern dürfen.

Ist Qualitätsverbesserung ein wichtigesZiel, dann sind sowohl XP als auch Crystalund FDD gut geeignet, um Software vonhoher Qualität zu erstellen. Scrum könntezwar immerhin einen Rahmen bieten, umdie Probleme früh aufzuzeigen, bietet aberkonkret keine Mechanismen zur Qualitäts-verbesserung. Diese Mechanismen sinddurchaus unterschiedlich, so setzt z. B. XPauf das Programmieren in Paaren (auch alsDauer-Review) und testgetriebene Ent-wicklung (test-first), während FDD ge-meinsame Vorabentwürfe je Feature,Entwurfsinspektionen, nachgelagerte Testsund konsequente Code-Reviews in denVordergrund stellt.

Wer besonderes Augenmerk auf einehohe Akzeptanz des Prozesses durch dasTeam legt, der sollte sich Crystal genaueranschauen. Hier hat das Team bei derAusgestaltung eines passenden Prozessessehr große Freiheiten. Die Möglichkeit, diepassenden Praktiken anhand der eigenenBedürfnissen aktiv auswählen zu können,führt erfahrungsgemäß zu einer hohenAkzeptanz des Prozesses. Gleichzeitig stelltdies aber auch eine besondere Herausfor-derung an das Team dar, da die geeigneteAuswahl zueinander passender Praktikenviel Erfahrung und Verständnis der agilenZusammenhänge erfordert.

Entscheidungen anhandder VoraussetzungenNeben den Zielen, die durch die Ein-führung der Methode erreicht werden sol-len, spielen natürlich auch die vorgefunde-nen Voraussetzungen bei der Auswahl einerpassenden Methode eine Rolle.

So ist bei FDD die Einstiegshürde fürstark traditionell organisierte Teams miteiner klassischen Rollenverteilung – wieChefarchitekt und Entwickler – häufiggeringer als bei den anderen vorgestelltenMethoden, da FDD eine entsprechendeAufgabenverteilung aufgreift. Demgegen-über setzen Scrum und XP eher auf eigen-verantwortlich arbeitende Teams mitgleichberechtigten Teammitgliedern.

Auch die Projektgröße und die damitzusammenhängende Teamgröße könnennatürlich Einfluss auf die Wahl derMethode haben. XP war ursprünglich eherfür kleine Teams konzipiert, die aber durchdie enorme Effizienz der Methode häufigrecht große Aufgaben stemmen können.Generell kann die Kommunikation in gro-ßen Teams nicht so eng sein wie in kleinerenTeams. Es bietet sich daher an, großeProjekte nicht mit einem großen Teamanzugehen, sondern mit mehreren parallelarbeitenden kleineren Teams. Scrum greiftdiese Idee mit den Scrum of Scrums auf.Dabei wird die Arbeit der Einzelteams überspezielle Meetings synchronisiert. Crystalkann ebenfalls in größeren Teams eingesetztwerden. In [Coc97] wird beispielsweiseCrystal Orange beschrieben, das aufTeamgrößen von über 20 und unter 80Personen ausgelegt ist. FDD geht zwar vonzeitlich sehr kurzen Projektlaufzeiten aus(maximal sechs Monate), dafür kann mandas Problem aber durchaus mit sehr großenTeams angehen, weil das Planungsinstru-mentarium von FDD sehr gut skaliert.

Auch die Vertragskonstellation kann eineentscheidende Rolle bei der Methodenwahlspielen. Scrum und XP sind für Kon-stellationen mit festem Preis, Umfang undTermin nicht optimiert, obwohl man siemit gewissen Modifikationen auch ineinem solchen Umfeld einsetzen kann. Hiersind Aufwandskonstellationen oder Kon-stellationen mit festem Preis und Terminbei variablem Umfang das bevorzugteVertragsmodell. Crystal und FDD kommenaus dem Bereich des klassischen Vertragsmit festem Preis, Umfang und Termin. Hierwird mehr Wert auf die Ermittlung des tat-sächlichen Projektumfangs gelegt, was eineabsolute Voraussetzung für solche Verträge

f achar t i ke l

sein muss. Beispielsweise kennt Crystal mitdem Exploratory 360° eine vorgelagerteProjektphase, die zur Klärung des Projekt-umfangs dienen kann (vgl. [Coc04]). InFDD dient die gemeinsame Modellierungmit dem Fachexperten zu einem besserenVerständnis des Projektumfangs, auf dessenBasis dann realistische Schätzungen auchfür einen Festpreisvertrag abgegeben wer-den können.

Für Neueinsteiger in die agilen Methodenkann die Frage entscheidend sein, ob es mög-lich ist, einen erfahrenen Coach in das Projektzu holen. Generell ist es nicht einfach, agileMethoden in bisher klassisch arbeitendeTeams und Organisationen einzuführen. Beider Einführung jeder Methode ist es dringendangeraten, sich unterstützen zu lassen. Ist dasaber nicht möglich, sollte man als Startpunkteher eine der drei Methoden wählen, die mitbereits vorgegebenen Sätzen an erprobtenPraktiken daherkommen. Crystal erfordertdurch seine große Flexibilität und das Fehlenfest vorgegebener Praktiken in besonderemMaß Verständnis für die agilen Zusam-menhänge. Für Anfänger ist das eigenständi-ge Zusammenstellen einer geeigneten Me-thode ohne die Hilfe eines erfahrenenCoaches aber eine zu große Herausforderung.

Anpassen an daseigene agile VorgehenAllen agilen Prozessen ist gemeinsam, dassman den Prozess im Projektverlauf anpas-sen sollte, wenn man merkt, dass er für dieaktuelle Situation nicht (mehr) optimal ist.

Das führt dazu, dass ein Team am Endeeines Projekts normalerweise nicht mehrgenau den gleichen Prozess umsetzt, den esnoch zu Projektbeginn praktiziert hat. Mankönnte sogar so weit gehen zu behaupten,dass ein Projekt nicht agil ist, wenn es nacheinigen Monaten noch haargenau demProzess folgt wie zu Projektbeginn.

Wie aber kommt man zu sinnvollenAnpassungen des Prozesses? Der Schlüsselhierfür ist die Retrospektive. Retro-spektiven sind in Form von „Post-Mortem“-Retrospektiven auch in vieleneher traditionell arbeitenden Firmenbekannt: Man schaut bei Projektendezurück und versucht, aus den gemachtenErfahrungen für das nächste Projekt zu ler-nen. Das Problem bei diesem Vorgehen ist,dass die Erkenntnisse für das gerade been-dete Projekt zu spät kommen, das nächsteProjekt aber vielleicht auf ganz andereProbleme als das letzte treffen wird.

Agile Methoden haben dies erkannt und

Page 5: WELCHE AGILE METHODE FÜR WEN? SETZUNGEN ZUR ......„Crystal Clear“ (vgl. [Coc04]), das auf Teams von sechs bis acht Teammitgliedern optimiert ist. Knappere Beschreibungen existieren

44 45

Projektbeginn erstellen und diesen im weite-ren Projektverlauf immer weiter optimieren.Letztlich geht es nicht darum, ob man XP,Scrum, Crystal oder FDD einsetzt, sonderndarum, laufende Qualitätssoftware auszulie-fern, die dem Kunden Nutzen bringt.

FazitDas Ende ist klar: Ihre eigene agile Vor-gehensweise, die auf Ihre Organisation, IhrProjekt und Ihr Team abgestimmt ist undIhnen dabei hilft, Software erfolgreich,effektiv und effizient zu entwickeln. DieHerausforderung liegt am Anfang bzw.beim Einstieg in diese neuen Vor-gehensweise. Wir haben in diesem Artikelargumentiert, dass es ohne Erfahrung keinegute Idee wäre, gleich eine eigene Methodezu erfinden. Orientieren Sie sich an vor-handenen Methoden und an dem, wasIhrem Bedürfnis, Ihren Zielen, und IhrenVoraussetzungen am nächsten kommt.

Wenn Sie die Möglichkeit haben, empfeh-len wir Ihnen außerdem, sich von erfahre-nen Agilisten unterstützen zu lassen: Geradebeim Anpassen der Methode besteht sonstdie Gefahr, dass der Prozess eine eher un-günstige Richtung einschlägt, weil man bei-spielsweise Praktiken aus einem Prozess aus-mustert, ohne ihren Zweck durch geeigneteandere Maßnahmen zu ersetzen. ■

führen daher auch während des Pro-jektverlaufs Retrospektiven durch, um denProzess anzupassen. Der Projektverlaufwird in regelmäßigen Abständen reflek-tiert. Auf der Basis der dabei gemachtenErkenntnisse werden dann unmittelbarMaßnahmen ergriffen, die somit dem lau-fenden Projekt zugute kommen können.

Die Retrospektive ist die Schlüsselpraktikzur Prozessverbesserung. Dabei besteht abernatürlich auch die Gefahr, dass man in derRetrospektive Maßnahmen ergreift, die zwarauf den ersten Blick nach einer Verbesserungaussehen, in der Praxis aber eher einenRückschritt darstellen. Die nächsteRetrospektive bietet dann die Möglichkeit,diese Fehlentwicklung zu korrigieren.

Die logische Folgerung aus den häufigenAnpassungen ist, dass ein agiler Prozessnicht bis ins letzte ausformuliert zumFirmenstandard werden kann. Dies würdeder zentralen agilen Idee des adaptivenProzesses entgegenstehen.

Tatsächlich tritt bei erfahrenen „Agi-listen“ die Frage, welchem konkreten Pro-zess man denn nun folgt, immer mehr in denHintergrund. Wer erst einmal durchErfahrung ein echtes Verständnis der agilenPraktiken und Werte erlangt hat, wird sei-nen individuell auf das Projekt, das Teamund die Situation abgestimmten Prozess zu

f achar t i ke l

Literatur & Links

[Bec04] K. Beck, eXtreme Programming explai-

ned – embrace change, Addison-Wesley, 2004

[Ble08] W.-G. Bleek, H. Wolf, Agile Soft-

wareentwicklung, dpunkt.verlag, 2008

[Coc97] A. Cockburn, Surviving Object-

Oriented Projects, Addison-Wesley, 1997

[Coc04] A. Cockburn, Crystal Clear: A

Human-Powered Methodology for Small

Teams, Addison-Wesley, 2004

[Coc06] A. Cockburn, Agile Software Devel-

opment, Addison-Wesley, 2006

[DeL08] J. DeLuca, Web-Seite zu Feature

Driven Development, siehe: www.featuredriven

development.com

[Sch02] K. Schwaber, M. Beedle, Agile Software

Development with Scrum, Prentice Hall, 2002

[Wol05] H. Wolf, S. Roock, M. Lippert,

eXtreme Programming, dpunkt.verlag, 2005

[Wol08] H. Wolf, A. Roock, Agilität wird

Mainstream: Ergebnisse der Online-Umfrage

2008, in: OBJEKTspektrum 3/2008