4 projekt M A N A G E M E NT 1/ 20 07 aktuell Einführung: Auslöser agiler Entwicklungen Projektmanagement ist seit seinem Entstehen in den 60er- Jahren von ingenieur- und systemtechnischen Vorgehensweisen geprägt, die ursprünglich in der Luft- und Raumfahrt entstanden waren. Projekte beginnen danach mit der Ausarbeitung eines möglichst vollständigen Satzes von Anforderungen an das zu erarbeitende Ergebnis, die bei Entwicklungsprojekten in umfangreichen Lastenheften dokumentiert werden. Daran schließen sich ein zunächst grober und dann immer weiter verfeinerter systemtechnischer Entwurf, die Entwicklungs-, Konstruktions- und Programmierarbeiten sowie schließlich die Erprobung und die Systemeinführung an. Diese, auch als Wasserfallmodell bekannte, Vorgehensweise klingt im Prinzip gut, hatte in der Praxis jedoch schon immer ihre Schwächen: Die zu Projektbeginn mit großem Aufwand ermittelten Anforderungen erwiesen sich im weiteren Projektverlauf häufig als lückenhaft und instabil. Zudem erforderten der globale Wettbewerb, die wachsende Marktdynamik und komplexere Technologien seit den 90er-Jahren immer kürzere Projektlaufzeiten und häufigere technische Änderungen während des Projekts. Viele Kunden waren auch überfordert, ihre Anforderungen an ein neues System bereits zu Projektbeginn genau zu formulieren. Das Wasserfallmodell war auf derartige Randbedingungen nicht ausgerichtet und wurde in Verbindung mit verbreiteten Qualitätsmanagementsystemen (ISO 9001, CMM, V-Modell u. Ä.) auch immer dokumentationsintensiver und schwerfälliger. Bei vielen Entwicklern stieß es daher auf zunehmende Ablehnung. Verschiedene Experten für Softwareentwicklungsmethoden begannen, nach alternativen Vorgehensweisen zu suchen, mit denen Projekte schneller und änderungsfreundlicher durchgeführt werden konnten. Die meisten der von ihnen gefundenen Methoden waren nicht vollkommen neu, sondern beruhten auf den bereits in den 70er-Jahren von Basili und Turner [2] vorgestellten iterativen und inkrementellen Vorgehensmodellen, bei denen ein Softwaresystem in Teilsysteme zerlegt und stückweise Funktionalität hinzugefügt und verbessert wird. Weitere Vorläufer waren das Mitte der 80er- Jahre von Barry Boehm entwickelte Spiralmodell [3] sowie das zur gleichen Zeit entstandene Evolutionäre Projektmanagementmodell von Tom Gilb [4]. Der Begriff „Agile Softwareentwicklung“ wurde erstmals von dem Japaner Mikio Aoyama gebraucht, der damit seit 1993 Erfahrungen bei großen Telekommunikationssoftwareprojekten für Fujitsu gesammelt hatte, die geografisch über mehrere Länder verteilt waren [5]. Einer größeren Fachöffentlichkeit wurde der Begriff „Agil“ jedoch erst durch die spektakulären Forderungen der Ende 1999 veröffentlichten Extreme-Programming-Methode und die in deren Folge 2001 gegründete „Agile Alliance“ [6] bekannt. Agiles Projektmanagement am Beispiel von Scrum Der Ablauf agiler Projekte sei an dieser Stelle zunächst am Beispiel der Scrum-Methode verdeutlicht [7]. Scrum ist gegenüber anderen agilen Ansätzen stärker auf das Management von Projekten als auf softwaretechnische Fra- Das aktuelle Stichwort: Agiles Projektmanagement Siegfried Seibert Zu Beginn des neuen Jahrtausends wurde bei Softwareprojekten mit dem Buch „Extreme Programming Explained“ von Kent Beck [1] ein Paradigmenwechsel weg von den traditionellen plangetriebenen Vorgehensweisen propagiert. Der kurze Zeit später von Beck und ähnlich gesinnten Mitstreitern gewählte Begriff der „agilen Entwicklung“ strebt eine höhere Effektivität der Projektarbeit durch flexible, „leichtgewichtige“ Prozesse an. Er blieb zunächst auf die Softwarewelt beschränkt und wurde vom etablierten Projektmanagement nur am Rande wahrgenommen. Agile Arbeitsweisen in der Entwicklung benötigen aber auch ein darauf abgestimmtes „agiles“ Management. Die Protagonisten der agilen Softwareentwicklung haben sich daher seit jeher auch um das Projektmanagement in agilen Projekten gekümmert. Und diese agilen Managementansätze sind immer dann, wenn man es mit nicht vorhersehbaren, nicht planbaren Vorhaben zu tun hat, generell für alle Arten von Projekten interessant, auch außerhalb des Softwarebereichs. Aus agiler Softwareentwicklung ist mittlerweile agiles Projektmanagement geworden, das seit zwei bis drei Jahren durch Fachkongresse und Fachpublikationen geistert. In Google liefert das Stichwort „Agile Project Management“ mittlerweile 350.000 Treffer. Im vorliegenden „Aktuellen Stichwort“ sollen die Hauptansätze und Instrumente dieses agilen Projektmanagements vorgestellt und mit den traditionellen plangetriebenen Ansätzen verglichen werden. 42 WISSEN aktuell projekt M A N A G E M E NT 1/ 20 07 gen ausgerichtet. Die Scrum-Methode ist daher auch ein repräsentatives Beispiel für agiles Projektmanagement. Scrum geht davon aus, dass Entwicklungsprozesse so komplex und dynamisch sind, dass sie sich im Voraus weder im Ganzen noch in Teilabschnitten sicher planen lassen. Herkömmliche Arbeitspaket- und Terminplanungstechniken sind für solche unsicheren Planungssituationen nicht geeignet. Stattdessen arbeitet Scrum mit einer erfahrungsgeleiteten, empirischen Projektsteuerungsmethode, die auf verbindliche Planvorgaben verzichtet. Scrum-Projekte werden dazu in einzelne Iterationen (Sprints) aufgeteilt, die in der Regel immer 30 Tage dauern. Der Begriff „Scrum“ (= Gedränge) kommt aus dem Rugby-Sport. Dort findet ein Scrum statt, wenn die Spieler eines Teams eng in einem Knäuel zusammenstehen, um abzusprechen, wie sie nach dem Einwurf möglichst schnell den Ball gewinnen wollen. Diese Teamabstimmungsmethode wird auf das Projektgeschehen übertragen. Abb. 1 zeigt den Ablauf. Zentrale Elemente sind das Produkt-Backlog, das Sprint-Backlog, das Scrum-Meeting und das Sprint-Review. Produkt-Backlog: Aufbauend auf einer groben Produktvision werden die Anforderungen an ein neues System in einer offenen, jederzeit änder- und erweiterbaren Merkmalsliste, dem sogenannten Produkt-Backlog (= „Auftragsbestand“), festgehalten. Die in der Liste enthaltenen Funktions- und Leistungsmerkmale werden vom Kunden (in Form eines Kundenvertreters oder Produktmanagers) festgelegt und priorisiert. Sprint-Backlog: Die Merkmale und Funktionen, die im nächsten Sprint realisiert werden sollen, werden zu Beginn des Sprints in einer gemeinsamen Sitzung von Projektteam und Kundenvertreter aus dem Produkt-Backlog ausgewählt. Zusätzlich wird in einem prägnanten Satz ein übergeordnetes Sprintziel festgelegt, das Richtschnur für die Sprint-Abnahme vier Wochen später ist. Die ausgewählten Merkmale werden vom Team aus dem Produkt-Backlog in ein Sprint-Backlog übertragen und detailliert. Während des Sprints kann diese Liste vom Kundenvertreter nicht mehr geändert werden. Die Teammitglieder (nicht der „Scrum-Master“) stimmen unter sich ab, von wem und in welcher Reihenfolge die Anforderungen aus dem Sprint-Backlog bearbeitet werden. Um beurteilen zu können, wie viele Merkmale realisiert werden können, schätzen sie dazu auch den benötigten Zeitaufwand ab. Scrum-Meeting: Während des Sprints findet zur laufenden Koordination jeden Morgen ein kurzes Treffen statt, in dem der Arbeitsfortschritt abgeglichen wird und aufgetretene Probleme besprochen werden. Die bis Sprintende zu realisierenden Restaufgaben werden in einem Feature-Burndown-Chart (Abb. 2) festgehalten, das in jedem Scrum-Meeting aktualisiert wird. Zeigt sich, dass innerhalb des Sprints nicht alle Features realisiert werden können, kann der Scrum-Master geringer priorisierte Merkmale aus dem Sprint-Backlog streichen. Steht mehr Zeit zur Verfügung als gedacht, fügt der Scrum-Master zusätzliche Merkmale aus dem Produkt-Backlog hinzu. Sprint-Review: Nach Abschluss des Sprints wird die neu entwickelte Funktionalität dem Kunden vorgeführt und die Ergebnisse werden einem informellen Review durch Team und Kundenvertreter unterzogen. Aus dem Produkt-Backlog werden die Features für das nächste Sprint ausgewählt und das Feature-Burndown-Chart für das Gesamtprojekt aktualisiert. Agile Methoden im Überblick Neben Scrum sind die heute bekanntesten agilen Entwicklungsmethoden in Abb. 3 charakterisiert: o das Extreme Programming (XP) von Kent Beck und Ward Cunningham [1], o das Adaptive Software Development (ASD) von Jim Highsmith [8], 30-Tage- Sprint Produkt-Backlog Ständig aktualisierbare, priorisierte Anforderungsliste Für Sprint gewähltes Backlog-Paket Sprint-Backlog Vom Team detaillierte Backlog-Merkmale Tägliches 15-Minuten-Treffen. Teammitglieder geben Statusinfos: 1) Was habe ich gestern getan? 2) Was behindert meine Arbeit? 3) Was will ich heute tun? Neue Funktionalität wird am Ende des Sprints demonstriert Scrum Sprint-Review Produkt-Vision RoI, Releases, Meilensteine Abb. 1: Ablauf von Scrum-Projekten; Quelle: eigene Darstellung in Anlehnung an [7], S. 9 43 projekt M A N A G E M E NT 1/ 20 07 aktuell o die Crystal-Clear-Methoden von Alistair Cockburn [9], o die Scrum-Methode von Ken Schwaber und Jeff Sutherland [10], o das Feature Driven Development (FDD) von Jeff DeLuca und Peter Coad [11] sowie o das Lean Software Development von Mary und Tom Poppendieck [12]. Weitere hier nicht näher betrachtete Methoden sind das Lean Development [13], das Agile Modeling [14] und die Dynamic System Development Methodology [15]. In Deutschland wurde von Hruschka und Rupp eine agile Methode für technische Systeme (ARTE Agile Real Time Embedded Systems) [16] und von Oestereich eine agile Variante des Rational Unified Process (OEP Object Engineering Process) [17] vorgelegt. Obwohl diese Ansätze alle unterschiedliche Schwerpunkte und Arbeitstechniken aufweisen (Abb. 4), gehen sie von gemeinsamen Überzeugungen und Grundprinzipien aus, mit denen sie sich von den am Wasserfallmodell angelehnten, plan- und spezifikationsgetriebenen Vorgehensweisen abgren- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 250 200 150 100 50 0 Restaufwand Heute Gemessen Prognose Tag Personentage Abb. 2: Feature-Burndown-Chart; Quelle: Wolf, Roock, Lippert (Extreme Programming, dpunkt 2005, S. 135) Abb. 3: Die bekanntesten agilen Methoden Methode Autoren Beschreibung eXtreme Programming (XP) Kent Beck, Ward Cunningham, Ron Jeffries o Bekannteste und radikalste agile Methode mit sehr kurzen Iterationen (2 Wochen). o Vorgabe von zwölf genau definierten Arbeitspraktiken, die alle vollständig anzuwenden sind, u. a. Planungsspiele, Programmierung in Paaren, einfaches Design, testgetriebene Programmierung, kontinuierliches Refactoring, tägliche Systemintegration, offener Teamarbeitsraum. o Permanente Anwesenheit eines Kundenvertreters im Team. o Info: www.extremeprogramming.org Adaptive Software Development (ASD) Jim Highsmith o Geht davon aus, dass Änderungen in Projekten der Normalfall sind und die schnelle Anpassung an Änderungen erfolgsentscheidend ist. o Im Mittelpunkt steht ein änderungsfreundlicher, adaptiver Lebenszyklus, der zielorientiert, anforderungsbasiert, iterativ und risikogetrieben ist. o Iterationen sind zeitbegrenzt (Timeboxing) und folgen einer Lernspirale mit den Schritten: Spekulieren (statt Planen) -> Zusammenarbeiten (statt Leiten) -> Lernen (statt Kontrolle). o Der Führungsstil ist kollaborationsorientiert mit Feedbacks durch Kunden-Fokusgruppen. o Info: www.adaptivesd.com Crystal Alistair Cockburn o Methodenfamilie, die in Abhängigkeit von Teamgröße und Kritikalität des zu entwickelnden Systems sowohl agile als auch planungsgetriebene Prinzipien enthält. o Menschliche Aspekte, d. h. das Team, Teamwerte, Fähigkeiten der Teammitglieder, Kommunikation, Umgang miteinander und gegenseitiges Vertrauen werden gegenüber Prozessen, Methoden und Tools in den Mittelpunkt gestellt. o Info: alistair.cockburn.us/ crystal/ crystal.html Scrum Ken Schwaber, Jeff Sutherland, Mike Beedle o Zusammen mit XP die am weitesten verbreitete agile Methode. o Geht davon aus, dass der Entwicklungsprozess nicht planbar ist. o Scrum-Projekte werden in 30-tägige Iterationen (Sprints) aufgeteilt, in denen eine bestimmte Zahl von Anforderungen aus einer priorisierten Anforderungsliste („Backlog“) zu implementieren ist. o Koordination erfolgt durch tägliche 15-minütige „Scrum-Meetings“. o Info: www.controlchaos.com Feature Driven Development (FDD) Jeff DeLuca, Peter Coad o Leichtgewichtiger, architekturbasierter Prozess, in dem zunächst eine Gesamtsystemarchitektur entworfen, daraus eine Featureliste abgeleitet und deren Realisierung (grob) geplant wird. o Einzelne Features werden dann in sehr kurzen Iterationen (1 bis 2 Wochen) detaillierter entworfen, codiert, getestet und integriert. o Betont die Wichtigkeit von Schlüsselpersonen im Team, insbesondere von Chefarchitekt und Chefprogrammierer; Prozesse treten demgegenüber in den Hintergrund. o Auch für größere Projekte mit mehreren Teilteams geeignet. o Info: www.featuredrivendevelopment.com Lean Software Development Mary und Tom Poppendieck o Übertragung von Prinzipen der schlanken Entwicklung aus der Automobilindustrie auf Softwareprojekte. o Basiert auf sieben Prinzipien (Verschwendung vermeiden, Lernen unterstützen, so spät wie möglich entscheiden, so früh wie möglich ausliefern, Verantwortung an das Team geben, Integrität einbauen, das Ganze sehen), aus denen 22 agile Werkzeuge abgeleitet werden. o Info: www.poppendieck.com 44 WISSEN aktuell projekt M A N A G E M E NT 1/ 20 07 zen. Den meisten agilen Ansätzen liegt zugrunde, dass sie versuchen, die reine Entwurfsphase auf ein Mindestmaß zu reduzieren und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen, die dann in regelmäßigen, kurzen Abständen (Iterationen) dem Kunden zur gemeinsamen Abstimmung vorgelegt werden kann. Auf diese Weise soll es jederzeit möglich sein, flexibel auf Kundenwünsche einzugehen und so die Kundenzufriedenheit insgesamt zu erhöhen. Ihre gemeinsamen Überzeugungen haben die Vertreter agiler Entwicklungskonzepte 2001 in einem Manifest formuliert [18]. In diesem Manifest werden Kundenzufriedenheit, motivierte Teams und kontinuierliches Risikomanagement in den Mittelpunkt gestellt. In vier Leitsätzen wird formuliert, dass im Zweifelsfalle o Menschen und deren Zusammenarbeit wichtiger seien als Prozesse und Werkzeuge, o funktionierende Software wichtiger sei als eine umfangreiche Dokumentation, o Kooperation zwischen den Stakeholdern wichtiger sei als Verträge und o flexibles Eingehen auf Änderungswünsche wichtiger sei als das Festhalten an einem starren Plan. Um kein Missverständnis entstehen zu lassen, weist das Agile Manifest ausdrücklich darauf hin, dass definierte Prozesse, Dokumentation, Verträge und Planungen nicht grundsätzlich abgelehnt werden, sondern dass sie gegenüber den jeweils erstgenannten Punkten nur eine geringere Priorität hätten. Aus den vier Leitsätzen werden im Agilen Manifest eine Reihe weiterer Merkmale agiler Methoden abgeleitet. Agile Methoden sind leichtgewichtige Prozesse, die die Benutzer aktiv in das Projekt einbinden, um die Anforderungen an das Projektergebnis zu ermitteln, zu priorisieren und zu verifizieren. Sie stützen sich mehr auf das implizite Wissen des Projektteams als auf eine umfangreiche Dokumentation. Kernmerkmale agiler Methoden sind: o Iterativ-inkrementelle Vorgehensweise: Agile Methoden liefern dem Kunden möglichst schnell ein funktionsfähiges System, das in kurzen Iterationsschleifen verbessert und mit zusätzlichen Funktionen erweitert wird. o Timeboxing: Die einzelnen Iterationen werden in festen Zeitabschnitten durchlaufen, das heißt alle Beteiligten können sich auf die festgelegten Termine verlassen. Im Falle von Problemen erfolgt keine Terminverschiebung, sondern eine Anpassung an den Umfang der zu erstellenden Version. o Selbstorganisierende Teams: Die Mitglieder im Team sind grundsätzlich gleichberechtigt. Das Team hat die Autonomie, sich selbst so zu organisieren, dass es die Arbeitsanforderungen bestmöglich erfüllen kann. o Änderungsfreundliche Projektkultur: Im Gegensatz zum klassischen Wasserfallmodell werden Anforderungen und Technologien nicht im „Design Freeze“ unter Änderungskontrolle gestellt, sondern lassen sich im Verlauf des Produktentwicklungszyklus einfach ändern. Änderungen werden als Freund, nicht als Gegner des Projekts gesehen. Agile Methoden versuchen dazu, die sogenannte „Zehnerregel der Fehlerkosten“ (Kosten einer Änderung steigen von Phase zu Phase um den Faktor 10) außer Kraft zu setzen und die Kostenkurve für Änderungen möglichst flach zu halten. Damit werden im Projekt eine höhere Kreativität und ein schnellerer Nutzen für den Kunden ermöglicht. Agile Entwicklungsmethoden stehen mit diesen Merkmalen in offensichtlichem Widerspruch zu einer starren und unreflektierten Anwendung „schwergewichtiger“ Qualitäts- und Vorgehensmodelle, wie der ISO 9001 und dem CMMI-Modell. Auch das V-Modell und der Rational Unified Process sind mit den agilen Prinzipien SW-CMM CMMI RUP FDD Crystal ASD Scrum XP Plangetrieben Agil Kundenschnittstelle Prozessmessungen Chancen/ Risiken Technische Praktiken Managementprozess Wartung Entwicklung Entwurf Anforderungsanalyse Vorstudie Einzelne Person Einzelteamprojekt Multiteamprojekt Geschäftssystem Gesamtunternehmen Aufgabenbezug Lebenszyklusphasen Organisat. Abdeckung Vorgehensmodelle = voll abgedeckt, = teilweise abgedeckt = dazwischen Abb. 4: Vergleich verschiedener Vorgehensmodelle; Quelle: [19], S. 194 45 projekt M A N A G E M E NT 1/ 20 07 aktuell und Methoden nicht kompatibel. Sie enthalten in ihren neuesten Versionen zwar Komponenten für eine agile Systementwicklung, sind aber in ihren Grundstrukturen viel zu schwergewichtig, als dass ihre agile Anwendung durch ein extremes Tailoring besonderen Sinn machen würde (Abb. 5). Agiles Projektmanagement Die Methoden der agilen Entwicklung werden unterschiedlich eingeteilt. Boehm und Turner [19] unterscheiden zwischen: o Technischen Arbeitspraktiken, zum Beispiel einfaches Design, Refactoring (wiederholte Codebereinigung während der Programmierung) und testgetriebene Entwicklung. o Kommunikationsmethoden, zum Beispiel Metaphern als Projektvision, Programmierung in Paaren. o Managementmethoden, zum Beispiel kontinuierliche Versionsauslieferung in kurzen Zyklen, Planungsspiele. Unter „agilem Projektmanagement“ kann man dabei im weiteren Sinne die Managementmethoden und die Kommunikationsmethoden der agilen Entwicklung verstehen. Etwas differenzierter und weiter gehend unterteilen Hruschka et al. [20] agile Methoden in die Bereiche agile Systemanalyse, agile Architektur, agile Programmierung, agile Dokumentation, agiles Projektmanagement und agile Organisation. Unter agilem Projektmanagement verstehen sie dabei ein pragmatisch und situationsangemessen auf das Wesentliche konzentriertes Management von Projekten, bei dem Kundenzufriedenheit, motivierte Teams und effektives Risikomanagement im Mittelpunkt stehen. Diese Definition bildet die heute vorherrschende Vorstellung zu agilem Projektmanagement sehr gut ab. Auch die agile Organisation kann im weiteren Sinne zum Projektmanagement gezählt werden. Die Autoren verstehen darunter Modelle, wie ein projektorientiertes Unternehmen strukturiert sein sollte, um in dynamischen Wettbewerbsumfeldern zu bestehen und eine agile Zusammenarbeit zwischen Auftraggebern und Auftragnehmern zu fördern. Als agile Prinzipien werden dabei das Marktprinzip (auch für die interne Zusammenarbeit) sowie die unternehmensübergreifende Netzwerkorganisation vorgeschlagen. Ein eigenständiger methodischer Rahmen für agiles Projektmanagement auch außerhalb von Softwareprojekten wurde 2004 von Highsmith veröffentlicht [21]. Er unterscheidet zwischen drei kunden- und produktorientierten und drei führungsstilorientierten agilen Managementprinzipien: o Kundennutzen durch innovative Produkte: - Liefere Kundennutzen. - Arbeite mit iterativen, anforderungsbasierten Vorgehensmodellen. - Favorisiere technische Exzellenz. o Kollaborativer Führungsstil: - Sei experimentierfreudig. - Bilde anpassungsfähige (selbst organisierende, disziplinierte) Teams. - Vereinfache, wann immer möglich. Viele dieser Prinzipien sind aus den Methoden der schlanken Produktion und der schlanken Entwicklung in der Automobilindustrie abgeleitet. Eines der wichtigsten Prinzipien dort ist die systematische Reduzierung von Verschwendungen, die dem Kunden keinen Nutzen liefern. Auch das Projektmanagement muss seine Projekte von Verschwendung befreien und sich auf die Lieferung der vom Kunden erwarteten Ergebnisse konzentrieren. Highsmith benennt dazu die aus seiner Sicht zu starren und plangetriebenen Prozessgruppen des PMBOK der Funktionsorientierte, lange Phasen Objektorientierte, kurze Iterationen Sehr flexibel Sehr starr Wasserfall Evolutionäres Prototyping Spiralmodell Vorgehensflexibilität Phasen-/ Iterationsprinzip Inkrementelle Implementierung Evolutionärer Entwurf Inkrementelle Entwicklung „Gleich-drauflos- Arbeiten“ („Code and Fix“) V-Modell Rational Unified Process Microsoft Solution Framework XP SCRUM „Schwergewichtige“, plangetriebene Prozesse ASD Crystal FDD „Leichtgewichtige“, agile Prozesse CMMI Abb. 5: Einordnung agiler Vorgehensmodelle 46 WISSEN aktuell projekt M A N A G E M E NT 1/ 20 07 PMI [22] in agile Prozessgruppen um, für die er einen Werkzeugkasten mit agilen Managementinstrumenten zusammenstellt (Abb. 6): 1. Inspiration (statt Initiierung) - Bestimmen der Produktvision und des Lieferumfangs, Identifikation der Stakeholder und Teambildung: Instrumente für die Produktvision sind die visionäre Produktverpackung, das Fahrstuhltest-Statement und ein grober Produktstrukturplan. Zur Definition des Projektumfangs dient ein einseitiger Projektsteckbrief. Weitere Praktiken dieser Phase sind die Personalzusammenstellung, die Stakeholderanalyse, die Definition der Kunden-Lieferanten-Team-Schnittstelle und die Definition von Spielregeln zur Teamarbeit. 2. Nachdenken (statt Planung) - Entwicklung eines anforderungsorientierten Release-, Meilenstein- und Iterationsplans: Der Produktstrukturplan wird, ähnlich der Stückliste in der Fertigung, auf einen Featurestrukturplan heruntergebrochen. Leistungsanforderungen und funktionale Merkmale des Feature-Strukturplans werden in Karteikarten (User Stories, Featurekarten; häufig handschriftlich, siehe Abb. 7) an Pinnwänden festgehalten, auf denen sie leicht hin und her gesteckt werden können. Bei größeren, verteilten Teams werden die Karten mit darauf ausgerichteten Softwareprogrammen elektronisch geführt. Ein Iterationsplan kann entwickelt werden, indem man die Featurekarten einfach an Pinnwänden in den entsprechenden Iterationen anordnet. In den Ablauf der Planungssitzungen sind Schätzklausuren und Risikoanalysen integriert. 3. Ausprobieren (statt Ausführung) - Ausliefern getesteter Merkmale in kurzen Iterationszyklen und kontinuierliches Risikomanagement: Hauptmanagementaufgaben dieser Phase sind die Bereitstellung einer kollaborativen Arbeitsumgebung und das Teammanagement. Instrumente sind Coaching, tägliche Teammeetings, kooperative Entscheidungsfindung und tägliche Kundenkontakte. Für das Ressourcenauslastungsmanagement und die möglichst kostengünstige Realisierung technischer Änderungen sind die Teammitglieder selbst verantwortlich. 4. Anpassen (statt Steuerung) - Review der ausgelieferten Produkte, der Projektsituation und der Teamleistung; Anpassungsmaßnahmen, wenn notwendig: Instrumente dieser Phase sind Kunden-Fokusgruppen, technische Reviews, Selbstbewertung der Teamleistung und metrikbasierte Projektstatusberichte (zum Beispiel die schon erwähnten Feature-Burndown- Charts oder die Verfolgung der Anzahl und des Werts der ausgelieferten Features und des erwarteten Projektendtermins). 5. Abschluss - Projekt abschließen, Erfahrung weiter geben und feiern: Instrumente sind die gleichen wie in der vierten Phase sowie spezielle Projektabschluss- Checklisten und die Projektretrospektive. Dem Leser kommt dies vielleicht bekannt vor, denn Highsmith macht viele Anleihen bei etablierten Projektmanagementmethoden. Produktstrukturpläne, Meilensteinpläne, Stakeholderanalysen, Reviews und Weiteres mehr kennt schließlich jeder Projektmanager. Aber diese Instrumente sind im agilen Projektmanagement anders implementiert als in klassischen Projekten. Im agilen Projektmanagement findet am Anfang eben keine detaillierte Projektstrukturplanung statt, sondern lediglich eine grobe, dem Kenntnisstand angepasste Produktstrukturierung. Der Projektaufwand wird in Planungsspielen ebenfalls nur relativ grob geschätzt. Netzpläne werden nicht erstellt, dafür aber Featurelisten und aus dem Kanban-System abgeleitete Karteikarten mit Featurebeschreibungen an Pinnwänden. Verteilte Teams koordinieren ihre Arbeiten über Sharepoint und Wikis statt über aufwendige Microsoft-Project-Server-Installationen. Es gibt kein Änderungskontrollverfahren mit Änderungsanträgen und Änderungskontrollausschüssen. Änderungen werden vielmehr über die vom Kunden priorisierten Featurelisten am Beginn einer Iteration eingebracht. Risiken werden nicht über Checklisten identifiziert und in Risikolisten festgehalten und quantifiziert. Das Risikomanagement erfolgt vielmehr organisch als inhärenter Bestandteil der täglichen Teamsitzungen durch die Fragestellung nach den zugrunde liegenden Planungsannahmen und nach den Bedenken der Teammitglieder. Im magischen Dreieck sind die Produktmerkmale nicht mehr die feste, sondern die anpassbare Größe. Die Arbeitsverteilung erfolgt nicht mehr nach dem Push-Prinzip eines genau einzuhaltenden Plans, sondern nach dem durch Kundenanforderungen ausgelösten Pull-Prinzip (Abb. 8). Die Teammitglieder entscheiden in diesem Rahmen eigenständig über ihre Vorgehensweise. Kritik an agilen Methoden Agile Methoden sind in Wissenschaft und Praxis nicht unumstritten. Die Hauptkritikpunkte, soweit sie sich auf das hier im Vordergrund stehende agile Projektmanagement beziehen, seien im Folgenden kurz diskutiert. Auf die spezielle Kritik an einigen Techniken des Extreme Programming (Programmierung in Paaren, 40-Stunden- Woche, ständig präsenter Kundenmitarbeiter) wird nicht eingegangen, da diese Techniken für agiles Projektmanagement nicht essenziell sind. Kritikpunkt: Agile Methoden funktionieren nur für kleine Projekte. Agile Methoden sind vor allem auf kleinere Projekte mit unter zehn Mitarbeitern ausgerichtet, die einen schnellen Geschäftserfolg für den Kunden erreichen wollen. Es sind zwar auch Ansätze für agile Projekte mit vernetzten Teamstrukturen entwickelt und in Projekten Abb. 6: Ablauf des agilen Projektmanagements; Quelle: [21], S. 81 Nachdenken Ausprobieren Anpassen Abschluss Inspiration Anforderungsliste Getestete Merkmale Releaseplan Fertiges Produkt Vision 47 projekt M A N A G E M E NT 1/ 20 07 aktuell erfolgreich eingesetzt worden. So soll ein Scrum-Projekt schon mit einem 800-Personen-Team durchgeführt worden sein [ 10 ]. Mit zunehmender Projektgröße steigt jedoch auch der Kommunikations- und Dokumentationsbedarf. Damit geht ein großer Teil der Agilität verloren. Plangetriebene Vorgehensweisen sind auf dokumentationsintensive Projekte besser ausgerichtet und sollten dafür dann auch bevorzugt werden. Kritikpunkt: Agile Projekte bringen mehr Risiken mit sich. Gernert [23] macht darauf aufmerksam, dass die Anwendung agiler Methoden zusätzliche Risiken mit sich bringt. So können Systeme durch die Forderung nach Einfachheit eine zu einfache, später nur noch mit erheblichem Aufwand erweiterbare Architektur erhalten. Für die agile Zusammenarbeit mit Unterlieferanten wird nur wenig methodische Unterstützung geliefert. Bei Mitarbeiterfluktuation geht undokumentiertes Wissen verloren. Und anderes mehr. Derartige Punkte sind zwar beherrschbar, müssen aber im Risikomanagement agiler Projekte beachtet werden. Kritikpunkt: Agile Methoden lassen keine Festpreisverträge zu. Während der Systementwurf und das Pflichtenheft bei plangetriebenen Vorgehensweisen eine geeignete Grundlage für Festpreisverträge liefern, werden derartige Dokumente bei agilen Projekten nicht erarbeitet. Agile Vertragsvereinbarungen stoßen in Einkaufsabteilungen daher oft auf formale Widerstände. Coldewey und Poppendieck [24] zeigen anhand von Beispielen aus der Automobilentwicklung jedoch auf, dass es eine Vielzahl von Vertragsmodellen gibt, mit denen in agilen Projekten gearbeitet werden kann. Oestereich [25] hat verschiedene agile Festpreismodelle entwickelt, die sogar bei Ausschreibungen öffentlicher Auftraggeber mit Erfolg eingesetzt wurden. Kritikpunkt: Agile Methoden sind nur bei Softwareprojekten einsetzbar. Agile Methoden wurden für Softwareprojekte entwickelt, die oft in integrierten Teams durchgeführt werden und in denen es praktisch keine Produktionsphase gibt. Für fertigungsnahe Phasen bei der Entwicklung größerer physischer Produkte sind agile, ingenieurtechnische Methoden in der Tat nur schwer vorstellbar. Saynisch [26] zeigt jedoch, dass im Bereich von Systemarchitekturen in der Automobilentwicklung agile Ansätze durchaus vorstellbar sind und dort auch konzipiert werden. Das agile Projektmanagement selbst ist sogar noch weniger auf Softwareprojekte beschränkt, als dies bei rein technischen Aufgaben der Fall ist. Viele Ansätze des agilen Projektmanagements wurden ursprünglich in der Automobilentwicklung erfunden oder werden dort seit Langem eingesetzt. Dazu zählen beispielsweise das Simultaneous bzw. Concurrent Engineering, der Target-Costingbzw. Design-to-Cost-Ansatz oder das dem Spiralmodell verwandte Stage-Gate-Modell von Cooper [27] sowie weitere Methoden der schlanken Automobilentwicklung, wie sie in Japan bei Toyota und in Deutschland bei Porsche entwickelt wurden. Kritikpunkt: Die Einführung agiler Praktiken in herkömmlichen Unternehmensstrukturen ist mit einem erheblichen Aufwand verbunden. In der Tat ist agiles Projektmanagement, wenn es über isolierte Insellösungen hinausgeht, für mechanistisch geprägte Großorganisationen mit großen Umstellungen verbunden, die einen hohen Aufwand erfordern. Vorbehalte und Widerstände müssen überwunden und die Organisation muss auf bereichsübergreifende Teamarbeit umgestellt werden. Neue Standards müssen auf ihre Anwendbarkeit geprüft und angepasst werden. Unterlieferanten müssen in die neuen Vorgehensweisen eingebunden werden. Dies alles kommt einem kulturellen Wandel gleich, der als eigenständiges Organisationsänderungsprojekt betrachtet und mit einem darauf ausgerichteten Change Management unterstützt werden sollte. Der reine Schulungs- und Trainingsaufwand ist bei agilen Methoden im Allgemeinen jedoch geringer als bei plangetriebenen Methoden. Auch wenn die Kultur des Unternehmens bereits organisch und flexibel geprägt ist, fällt die Umstellung leichter. Verbreitung und Wirksamkeit agiler Methoden Agile Methoden haben inzwischen − zumindest in den USA − eine hohe Verbreitung gefunden. 2002 gaben dort bei einer Befragung von 194 Softwareexperten noch 35 Prozent der Befragten das Wasserfallmodell als bevorzugtes Vorgehensmodell an [28]. Bei einer Befragung von 722 Softwareexperten 2006 nutzen jetzt aber bereits 84 Prozent der Befragten agile Methoden. Hierbei haben Scrum mit 40 Prozent und XP mit 23 Prozent die Abb. 7: Beispiel einer User Story Card; Quelle: www.extremeperl.org (30. 10. 2006) Randbedingungen Kosten Termine Anforderungen Schätzungen Kosten Termine Merkmale Agil Aus der Vision entstehen Merkmalsschätzungen Nach Plan Aus den Anforderungen entstehen Kosten- und Terminschätzungen Plangetrieben Visionsgetrieben Abb. 8: Paradigmenwechsel von plangetriebenem zu agilem Projektmanagement; Quelle: nach VersionOne (2006) [29] 48 WISSEN aktuell projekt M A N A G E M E NT 1/ 20 07 höchste Verbreitung. Mehr als die Hälfte der Befragten gab an, mit agilen Methoden Produktivitätssteigerungen von 25 Prozent und mehr erzielt zu haben [29]. Ein ähnliches Ergebnis zeigt auch eine Zusammenstellung empirischer Befunde bei Boehm und Turner [30]. Allerdings werden dort auch für das plangetriebene CMM-Modell ähnlich hohe Produktivitätsverbesserungen ausgewiesen. Je nach Randbedingungen scheinen also sowohl plangetriebene als auch agile Methoden erfolgreich einsetzbar zu sein. Diese Umfrageergebnisse sind auch ein Indiz für die von Boehm und Turner angegebenen Auswahlregeln. Agile Methoden sollten danach immer dann zum Einsatz kommen, wenn folgende Bedingungen vorliegen [31]: o Kleine Projekte mit bis zu zehn Personen. o Systeme mit geringer oder mittlerer Kritikalität. o Hoch dynamische Umfelder mit Anforderungsänderungsraten von mehr als 30 Prozent im Monat. o Mindestens 30 Prozent hoch qualifizierte Kräfte im Team, geringer Anteil niedrig qualifizierter Kräfte. o Organische Unternehmenskultur mit vielen Freiräumen für die Teammitglieder. Plangetriebene Methoden sollten immer dann zum Einsatz kommen, wenn folgende Bedingungen vorliegen: o Großprojekte mit mehr als 100 beteiligten Personen. o Systeme mit hoher oder sehr hoher Kritikalität. o Stabile Rahmenbedingungen mit Anforderungsänderungsraten von weniger als fünf Prozent pro Monat. o Mehr als 30 Prozent niedrig qualifizierte, weniger als 20 Prozent hoch qualifizierte Kräfte. o Mechanistische Unternehmenskultur mit klaren Regeln und Richtlinien. Liegen keine eindeutigen Randbedingungen vor, stellen die nicht modellkonformen Faktoren immer Projektrisiken dar, die mit Methoden des Risikomanagements bekämpft werden sollten. Unter Umständen sind auch maßgeschneiderte, hybride Vorgehensweisen möglich. Agile Methoden sind bei hoher Anforderungsunsicherheit empfehlenswert. Bei hoher Kritikalität dominieren nach wie vor plangetriebene Methoden. Die Empfehlungen von Boehm werden auch durch zwei jüngere, von der GPM unterstützte deutsche Umfragen belegt. In einer Befragung des Fraunhofer Instituts speziell bei Entwicklern kritischer Softwaresysteme gaben 41 Prozent der Befragten an, mit dem Wasserfallmodell zu arbeiten und 24 Prozent mit dem V-Modell. Evolutionäres Prototyping gaben 17 Prozent an, XP nur vier Prozent. Hier dominieren also plangetriebene Methoden [32]. Die Universität Köln ermittelte, dass agile Vorgehensweisen bei hoher Anforderungsunsicherheit mit einem größeren Projekterfolg verbunden sind, bei geringer Anforderungsunsicherheit besteht dieser Zusammenhang jedoch nicht [33]. Fazit In seinem bereits erwähnten Beitrag auf der interPM 2006 wurde von Saynisch [26] darauf hingewiesen, dass agile Methoden den evolutionär-systemischen Prinzipien des von ihm entwickelten Projektmanagements 2. Ordnung entsprechen. Aufgrund der zunehmenden Verbreitung sowohl agiler Ansätze in Softwareprojekten als auch schlanker Produktentwicklungsprinzipien in der Automobilindustrie ist damit der Paradigmenwechsel zum Projektmanagement 2. Ordnung bereits in vollem Gange. Allerdings zeigt der bisherige Stand der Veröffentlichungen und der empirischen Forschung (insbesondere die Arbeit von Boehm und Turner) auch, dass das traditionelle, plangetriebene Projektmanagement nach wie vor benötigt wird und je nach Situation einmal agiles und das andere Mal plangetriebenes Projektmanagement sinnvoll ist. Eine Erkenntnis, die im Grunde genommen nicht besonders neu ist. Schon in den 60er-Jahren wurde im Kontingenzansatz der Organisationsforschung herausgefunden, dass es ein universelles Management nicht gibt, sondern je nach Situation entweder organische oder mechanistische Managementsysteme besser geeignet sind. Diese Erkenntnis gilt nach wie vor und trifft auch auf das Projektmanagement zu. n Literatur [1] Beck, K.: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999 [2] Basili, V. R./ Turner, A. J.: Iterative Enhancement: A Practical Technique for Software Development. IEEE Transactions on Software Engineering 1, 1975, 4, 390-396 [3] Boehm, B.: A Spiral Model of Software Development and Enhancement. In: IEEE Computer 21, 1988, 5, S. 61-72 [4] Gilb, T.: Principles of Software Engineering Management. Addison-Wesley, 1988 [5] Aoyama, M.: Web-Based Agile Software Development. In: IEEE Software, Nov./ Dec. 1998, S. 56-65. Sowie Aoyama, M.: Agile Software Process and its Experience. In: IEEE Computer, Apr. 1998, S. 3-12 [6] Website: www.agilealliance.org [7] Schwaber, K.: Agile Project Management with Scrum. Microsoft Press, Redmont 2004 [8] Highsmith, J.: Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House, 2000 [9] Cockburn, A.: Crystal Clear: A Human Powered Methodology for Small Teams. Addison-Wesley, 2005 [10] Schwaber, K./ Beedle, M.: Agile Software Development with Scrum. Prentice Hall, 2002 [11] Coad, P./ DeLuca, J./ Lefebvre, E.: Java Modeling in Color with UML. Prentice Hall, 1999 [12] Poppendieck, M. und T.: Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003 [13] Website: www.itabhi.com/ ld.htm [14] Ambler, S.: Agile Modeling. Wiley, 2002 [15] DSDM Consortium: Business Focused Development. Addison-Wesley, 2002 [16] Hruschka, P./ Rupp, C.: Agile Software-Entwicklung für Embedded Real-Time Systems mit der UML. Carl-Hanser, 2002 [17] Oestereich, B.: OEP - oose Engineering Process. Vorgehensweisen für agile Softwareprozesse. dpunkt, 2006 [18] Website: www.agilemanifesto.org [19] Boehm, B./ Turner, R.: Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, 2004 [20] Hruschka, P./ Rupp, C./ Starke, G.: Agility kompakt: Tipps für erfolgreiche Systementwicklung. Spektrum, 2004 49 projekt M A N A G E M E NT 1/ 20 07 aktuell [21] Highsmith, J.: Agile Project Management: Creating Innovative Products. Addison-Wesley, 2004 [22] Project Management Institute (PMI): A Guide to the Project Management Body of Knowledge. PMBOK Guide, 3rd Ed., PMI, 2004 [23] Gernert, C.: Agiles Projektmanagement und Risikobeherrschung. In: OBJEKTspektrum, Heft 1/ 2006, 33-40. Sowie Gernert, C.: Agiles Projektmanagement. Hanser, 2003 [24] Coldewey, J./ Poppendieck, M.: Wir sind das Team: „Lean Development“ (Teil 2). In OBJEKTspektrum, Heft 4/ 2003, S. 81-86 [25] Oestereich, B.: Der Agile Festpreis und andere Preis- und Vertragsmodelle. In: OBJEKTspektrum 1/ 2006, S. 29-32 [26] Saynisch, M.: Agile Projektmanagementprinzipien: Ein evolutionärer Management-Ansatz? Projektmanagement 2. Ordnung als Referenzmodell. In: Oestereich, B. (Hrsg.): Agiles Projektmanagement. dpunkt, 2006 [27] Cooper, R. G.: Top oder Flop in der Produktentwicklung: Von der Idee zum Launch. Wiley-VCH, 2002 [28] Collin, J./ Laplante, P.: Requirements Engineering: The State of the Practice. IEEE Software, Nov./ Dec. 2003 [29] VersionOne: Agile Development: A Manager’s Roadmap for Success. Online im Internet: www.versionone.net (30. 10. 2006) [30] Boehm, B./ Turner, R.: a. a. O., S. 229 [31] Boehm, B./ Turner, R.: a. a. O., S. 51 ff. [32] Kalthoff, C./ Kunz, S.: Projektmanagement bei der Entwicklung kritischer Softwaresysteme: Fraunhofer IITB gibt Umfrageergebnisse bekannt. In: projektMANAGEMENT aktuell, Heft 2/ 2004, Seite 33-36 [33] Trittmann, R., et al.: Sieg der Moderne über die Tradition? Ergebnisse einer empirischen Untersuchung zur Projektgestaltung in der Softwareentwicklung. In: projekt- MANAGEMENT aktuell, Heft 4/ 2005, S. 12-17 Schlagwörter Agiles Projektmanagement, Extreme Programming, Prozessmodelle, Scrum, Vorgehensmodelle Autor Diplom-Wirtschaftsingenieur Dr. Siegfried Seibert ist Professor für Projektmanagement und Unternehmensführung an der Hochschule Darmstadt. Während der letzten Jahre war Siegfried Seibert Mitglied des Vorstands der GPM Deutsche Gesellschaft für Projektmanagement, Nürnberg. Hier leitete er das Ressort Publikationen und arbeitete als Chefredakteur der Zeitschrift projektMA- NAGEMENTaktuell. Daneben führt Siegfried Seibert regelmäßig Schulungen zum IT-Projektmanagement und zur Software-Kostenschätzung durch und verfügt über eine langjährige, leitende Industriepraxis in der Zulieferindustrie. Anschrift Hochschule Darmstadt Fachbereich Wirtschaft (Campus Dieburg) Max-Planck-Str. 2 D-64807 Dieburg Tel./ Fax: 0 60 78/ 7 27 33 Mail: s.seibert@h-da.de www.siegfried-seibert.de Projektmanagement Software ... ... einfach organisiert Bild: Photocase � � Fon : 07 21/ 95 25 0 w w w. A S TA d e v. d e Anzeige making IT better in-Step ® Risikomanagement Änderungsmanagement Qualitätsmanagement Anforderungsmanagement Projektmanagement Prozessmanagement Konfigurationsmanagement microTOOL GmbH Voltastraße 5 13355 Berlin Tel.: +49 30 / 467 08 6-0 Fax: +49 30 / 464 47 14 E-Mail: info@microTOOL.de www.microTOOL.de Mit in-Step ® erreichen Sie: Die einfache Einführung von Standards - wie V-Modell ® XT, PRINCE2 ™ & Co. Den durchgängigen Rollout Ihrer individuellen Prozesse - CMMI ® - und SPICE-konform. Die effektive Zusammenarbeit in Ihren Teams - im LAN und Internet. Die schnelle Nachverfolgbarkeit über das gesamte Projekt - Traceability leicht gemacht. Anzeige