examen.press ist eine Reihe, die Theorie und Praxis aus allen Bereichen der Informatik für die Hochschulausbildung vermittelt.

examen.press ist eine Reihe, die Theorie und Praxis aus allen Bereichen der Informatik für die Hochschulausbildung vermittelt.

Eckhart Hanser Agile Prozesse: Von XP über Scrum bis MAP 123

Prof. Dr. Eckhart Hanser Duale Hochschule Baden-Württemberg (DHBW) Lörrach Studiengang Angewandte Informatik, Vertiefung Biosystem-Informatik (Life Science) Hangstraße 46-50 79539 Lörrach Deutschland map@dr-hanser.de ISSN 1614-5216 ISBN 978-3-642-12312-2 e-isbn 978-3-642-12313-9 DOI 10.1007/978-3-642-12313-9 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer-Verlag Berlin Heidelberg 2010 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Grußwort Agile Vorgehensweisen stellen, nun schon mehr als ein Jahrzehnt, eine sehr beliebte Alternative zu den so genannten schwergewichtigen Vorgehensmodellen dar. Die Beschwerlichkeit, die man den älteren Methodiken SADT, SSADM, SA/SD, dem V-Modell 97 und auch wieder den jungen Modellen RUP mit UML und V-Modell XT nachsagt, begründen Entwickler und Anwender mit dem hohen Lernaufwand, der sich mit mehreren 100 Seiten Modelldokumentation präsentiert. Zudem wird die starke Bindung an einen Phasendurchlauf oder, wie im Falle des V-Modell XT, an eine Folge von Entscheidungspunkten, als zu starr geregelte Zeitstrukturierung beklagt. Auch wenn der Durchlauf angepasst werden kann, auch wenn Rücksprünge und Inkrementaufteilung erlaubt sind, so ist doch zumindest eine solide begründete Konfiguration zu bewältigen. Hinzu kommen umfangreich definierte Projektprodukte, Projektaktivitäten, Phasenzustände, die zu weitgehend feststehenden Zeitpunkten im Projektlebenslauf erreicht sein müssen, was ebenfalls als Einschränkung der Bewegungsfreiheit empfunden wird. An dieser Auffassung hat auch die Konfigurierbarkeit des V-Modell XT auf eine Projektdurchführungsstrategie Agile Projekte nicht gerüttelt. Konfiguration, Dokumentation, Phasenregelung, Produktmuster, Methodenvorschriften stellen die Lernbereitschaft auf eine harte Probe, werfen berechtigte Fragen der Implementierbarkeit auf und sehen sich daher auf allen Organisationsebenen mit Akzeptanzproblemen konfrontiert. Das betrifft auch gleich die gesamte Breite der beteiligten Rollen, wie z.b. die Systemanalytiker, die Entwickler, das Linienmanagement, das Projektmanagement und besonders auch die Anwender. Da kommt vielen die unmittelbare Einsatzbereitschaft der agilen Methoden wie gerufen. Sichtbar wurde die agile Trendwende mit der immer noch heftig umstrittenen, extrem gekürzten Vorgehensvariante von Kent Beck, dem Extreme Programming, das, wie Eckhart Hanser wiedergibt, auf einen einfachen Satz von Prinzipien und Praktiken baut. Die Kürzung des Vorgehens besteht sowohl in der Befreiung vom vorgeschriebenen Durchlauf, im Verzicht auf methodengestützte Spezifizierung, als auch in der Minimierung der Ausstattung mit Methoden, Vorlagen, Mustern. Extreme bezieht sich deshalb auch auf eine extrem dünne Dokumentation des Extreme Programming. Je agiler die Methodik ist, desto mehr Fragen nach Beispielen, Mustern, Anleitungen tauchten auf, und so wurde die Leichtgewichtigkeit in weiteren agilen Modellen wieder etwas methodisch angereichert. Die Gruppe der agilen v

vi Grußwort Methoden hat sich differenziert, ist gewachsen und hat dadurch an Bequemlichkeit und auch etwas an Übersichtlichkeit verloren. Der Literaturmarkt führt derzeit in erster Linie nur zu einzelnen agilen Modellen Monografien, und diese Werke sind leider im Brustton der Überzeugung erfolgreicher Projekte geschrieben worden, helfen deshalb wenig die Unübersichtlichkeit zu beheben. Das Buch von Eckhart Hanser leistet hier einen wichtigen sachlichen Beitrag zur Orientierung. Die Vertreter der agilen Vorgehensweisen heben lobenswerter Weise stark auf den Mensch, seine Bestrebungen zur Zusammenarbeit, sein Kommunikationsverhalten und die sein Handeln leitenden, ethischen Werte ab. Das kommt in einigen der Prinzipien und im Agilen Manifest zum Ausdruck. Man darf dennoch hinterfragen, ob denn Prämissen, wie z.b. tägliche Morgenmeetings, Pair-Programming, gleich große Aufgabenpakete, tatsächlich den menschlichen Neigungen entsprechen und humanere Zusammenarbeit fördern oder doch eher ein Ideal bleiben. Es fällt auf, dass die agilen Autoren immer von ihrer persönlichen positiven Projekterfahrung schwärmen, aber nicht von einer wissenschaftlich belegten Erkenntnis. Es wurde Zeit, dass diese sozialen, agilen Empfehlungen wenigstens mit derjenigen Genauigkeit untersucht werden, die sogar die agilen Entwickler ihren Programmen zugestehen, nämlich durch Testen. Für den viel komplexeren Akt des Zusammenarbeitens erwartet man einen sozialen Prototypen, eine Organisationsform unter kontrollierten Umgebungsbedingungen, an dem man sozial-wissenschaftlich nachweist, dass die besagten sozialen Prämissen x, die Zusammenarbeitsform y, am Besten geeignet sind für die Aufgabenstellung z. Eckhart Hanser hat seine Arbeit dieser Lücke gewidmet und die soziologischen Aspekte des Software-Entwickelns in seinem Software Engineering Labor beobachtet. Ihm gebührt damit das Verdienst als einer der wenigen IT-Forscher mit seinem Meta Agile Process Model (MAP) eine soziologische Sicht in die Softwareentwicklung einbezogen zu haben und zwar mit sozialwissenschaftlichen Methoden, wie dem Feldversuch, der begleitenden Beobachtung und dem gruppendynamischen Experiment. Die im Organisationslabor ich lasse mich hier begrifflich von Arbeiten des Tavistock Institute anregen gewonnenen Erkenntnisse fließen in Verbesserungsvorschläge zum agilen Vorgehen ein. Damit kann der Projektmanager fundierte Kriterien an die Stelle der agilen Schwärmerei setzen. Und das hilft zu beurteilen, ob eine Aufgabenstellung in einer agilen Form oder schwergewichtig angegangen werden soll. Die Wahrheit wird wohl, wie immer, in der Mitte liegen: Für einige Projekttypen eignen sich agile Modelle besser, für andere Projekttypen ist auf umfangreiche Vorgehensmodelle nicht zu verzichten. Eckhart Hanser öffnet mit seinem Buch den Blick für eine sachliche Einschätzung der Eignung agiler Modelle zu einem Projekttyp. Ich freue mich, dass es wieder einem aktiven Mitglied der Fachgruppe Vorgehensmodelle des Fachbereichs Wirtschaftsinformatik der Gesellschaft für Informatik gelungen ist, ein interessantes Buch herauszubringen und wünsche dem Buch eine gute Resonanz. Dass sich das Buch auch noch mit einem vor vier Jahren mit Professor Gerhard Chroust gestarteten Themenfokus Soziale, kulturelle und lokationsspezifische Aspekte der Fachgruppe zusammenfällt, freut uns alle besonders. An dieser Stelle sei auch Herrn Heine vom Springer Verlag gedankt, dass er

Grußwort vii immer ein Ohr für die Fachgruppe hat. Es bleibt zu wünschen, dass der von Eckhart Hanser gestartete Weg des sozialen Experiments noch viel weiter gegangen wird, dass noch mehr sozietale Maßnahmen, Sozialkriterien und ihre Indikatoren beobachtet werden, dass weitere Informatiker die Soziologie einbeziehen. Vielleicht werden eines Tages die Aktivitäten, Methoden, Meilensteine im Projekt nicht mehr auf die technische Güte der Produkte reduziert, sondern von sozietalen Aktivitäten, soziologischen Methoden und sozialen Meilensteinen flankiert. Dann müssen sich auch die Softwareentwickler nicht schon wieder den Vorwurf gefallen lassen, am Anwender vorbei zu programmieren. Oder ist irgendjemand der Auffassung, dass z.b. das weitverbreitetste Vorgehensmodell der Welt, der Unified Process mit UML, fachanwenderfreundlich ist? Reinhard Höhn Sprecher der Fachgruppe Vorgehensmodelle der Gesellschaft für Informatik 2007-2009, Mitglied des Leitungsgremiums der Fachgruppe 2010 Darmstadt im Februar 2010

Vorwort Mit diesem Buch verfolge ich zwei Ziele: Zum einen soll ein Überblick über die aktuelle Welt der agilen Prozessmodelle gegeben werden. Die leichtgewichtigen Software-Entwicklungsmethodiken Extreme Programming, Crystal und Scrum werden ausführlich beschrieben und mit Hilfe meines studentischen Software- Engineering-Labors der Dualen Hochschule Baden-Württemberg Lörrach auf ihre Alltagstauglichkeit überprüft. Zum anderen fasse ich die Erfahrungen aus sechs Jahren experimentellen Software-Engineerings im studentischen Labor in dem neuen agilen Meta-Modell MAP zusammen, welches sich mit den Zutaten beschäftigt, die ein erfolgreiches technisches Projekt benötigt. Die Grundidee ist einfach: Wenn man ein hochqualifiziertes Projektteam zusammenstellt, macht es keinen Sinn, einen Prozess in Form eines Flussdiagrammes vorzugeben, sondern es ist besser, die richtigen Charaktere oder Typen zusammenzubringen und mit ihnen die im studentischen Labor identifizierten notwendigen Projektrollen korrekt zu besetzen. Ein in diesem Sinn gut ausbalanciertes Projektteam hat eine höhere Aussicht auf Erfolg! Diese Erkenntnis ist das direkte Resultat meines studentischen Labors. Bei den aufgeführten Projektrollen wird in diesem Buch die männliche Form benutzt. Dies dient lediglich der Erhöhung der Lesbarkeit des Texts. Meine Erfahrung zeigt, dass Frauen im Projektgeschäft hervorragende Leistungen erbringen. Insbesondere Projektleiterinnen verstehen es oft, ihre Teams zu außergewöhnlichen Leistungen anzuspornen (Kap. 7). Zielgruppe dieses Buchs Dieses Buch wendet sich sowohl an Praktiker, die sich einen Überblick über den Markt der agilen Ansätze verschaffen wollen, als auch an Studierende, die sich auf ihre Klausuren und Prüfungen im Bereich der agilen Prozessmodelle vorbereiten. Insbesondere Praktiker wird interessieren, welche agilen Praktiken sich im studentischen Labor und damit unter reproduzierbaren Laborbedingungen bewährt haben und welche nicht (Kap. 6). Viele Vermutungen aus Praxisprojekten konnten wissenschaftlich fundiert nachgewiesen werden. ix

x Vorwort Aufbau dieses Buchs Agiles Manifest und agile Prozessmodelle Nach einer kurzen Einführung in die Historie der Software-Prozessmodelle (Kap. 1) wird in Kap. 2 das Agile Manifest erläutert. Diese von Entwicklern initiierte Gegenbewegung zu den schwergewichtigen Prozessmodellen wie Unified Process oder V-Modell begründet die bekannten agilen Prozessmodelle Extreme Programming (XP), Crystal mit Crystal Clear und die agile Projektmanagementmethode Scrum. Die aufgezählten agilen Methodiken werden in den Kap. 3 bis 5 systematisch vorgestellt. Dabei stehen der Prozess und die vorgeschlagenen Praktiken sowie die Projektrollen und die erzeugten Artefakte im Vordergrund. Bei Extreme Programming (Kap. 3) werden insbesondere die traditionellen XP-Praktiken den erweiterten Praktiken gegenübergestellt. Das studentische Software-Engineering-Labor In Kap. 6 wird das studentische Software-Engineering-Labor der Dualen Hochschule Baden-Württemberg Lörrach vorgestellt. Seit mittlerweile sechs Jahren werden in diesem experimentellen Software-Engineering-Labor agile Prozessmodelle und Methoden untersucht und auf ihre Praxistauglichkeit überprüft. Alle im Buch erwähnten Prozessmodelle wurden in diversen studentischen Projekten ausprobiert. Nach einer theoretischen Einweisung im Rahmen der Software-Engineering- Vorlesung mussten studentische Gruppen reale Projekte bearbeiten und dabei als Projektteam dem jeweils betrachteten Prozessmodell folgen. Die Ergebnisse, insbesondere bezüglich der Alltagstauglichkeit der gewählten agilen Methoden, sowie Erfahrungsberichte aus den unterschiedlichen Projekten finden sich in Kap. 6. Danksagung Dieses Buch wäre nicht ohne die Hilfe und Unterstützung lieber Menschen zustande gekommen. Ich danke meiner Familie, meiner Frau Susanne und meiner Tochter Stephanie, dass sie während der Erstellung dieses Buchs oft auf mich verzichtet haben. Meinem Sohn Felix danke ich für die aktive Teilnahme auf Kundenseite beim aktuellen studentischen Projekt. Meinen Eltern danke ich, dass ich das studieren durfte, was ich immer wollte. Den Studierenden der Dualen Hochschule Baden-Württemberg Lörrach, die an den studentischen Projekten teilgenommen haben, danke ich für ihr Engagement und ihre lebhafte Teilnahme. Sie mussten sich oft wie Versuchskaninchen vorkommen, insbesondere wenn sie die hundertste Evaluation ausfüllen sollten. Und doch war ihr Feedback stets positiv und ermunterte mich zum Weitermachen. Dem Organisationspsychologen Herrn Baldegger danke ich für die fruchtbaren Diskussionen und nützlichen Kommentare zu MAP, meiner neu entwickelten Landkarte der Verhaltensweisen im Team.

Vorwort xi Kein Projekt kommt ohne reale Kunden aus. Ich danke in diesem Zusammenhang der Geschäftsführung des Berufsförderungswerks Bad Wildbad (BFW), insbesondere Herrn Geschäftsführer Dings und Herrn Birk, sehr herzlich, dass sie das aktuelle studentische Projekt vor Ort beim Kunden und die Veröffentlichung der Ergebnisse ermöglicht haben. Herrn Birk und seinen Mitarbeitern in der IT danke ich für die aktive Teilnahme am Projekt, die uns allen neue interessante Erkenntnisse gebracht hat. Natürlich müssen Ergebnisse aus dem studentischen Labor in der betrieblichen Praxis überprüft werden. Das ist nicht so einfach, da oftmals Geheimhaltungsgründe gegen eine Veröffentlichung sprechen. Ich danke deshalb der Werksleitung der Evonik Degussa GmbH, Werk Rheinfelden, insbesondere Herrn Werksleiter Dr. Vierbaum und Herrn Meijlink, dass ich die Ergebnisse der Diplomarbeit von Frau Dipl.-Ing. (BA) Olga Wolf zum Einsatz agiler Methoden in der Werks-IT verwenden durfte (Kap. 7). Mein besonderer Dank gilt Frau Wolf für ihre gelungene Arbeit, die ich mit Herrn Sehringer und Frau Reisch betreuen durfte. Der Fachgruppe Vorgehensmodelle der Gesellschaft für Informatik danke ich für die interessanten Diskussionen zum Thema schwergewichtige und leichtgewichtige Prozessmodelle. Herrn Heine und Frau Herrmann vom Springer-Verlag danke ich für ihre Unterstützung beim Entstehen und bei der Veröffentlichung dieses Buchs. Herrn Heine danke ich insbesondere für seine ermunternde Aufforderung auch mal ein kleineres Buch zu schreiben. Ohne diese Motivation wäre das Buch nicht entstanden. Rheinfelden Februar 2010 Eckhart Hanser

Inhaltsverzeichnis 1 Software-Prozessmodelle... 1 1.1 Ein Prozessmodell was ist das?... 1 1.1.1 Einteilung in Projekttypen... 2 1.1.2 Schwergewichtige und leichtgewichtige Prozessmodelle.. 2 1.1.3 Prozessmodell vs. Vorgehensmodell... 3 1.2 Das Phasenmodell...... 3 1.3 Das Spiralmodell...... 4 1.4 Moderne iterativ-inkrementelle Prozessmodelle..... 6 1.4.1 V-Modell...... 6 1.4.2 Unified Software Development Process (UP)... 6 1.4.3 AgileProzessmodelle... 7 Literatur... 7 2 Das Agile Manifest... 9 Literatur... 11 3 Extreme Programming (XP)... 13 3.1 DiefünfWerte... 14 3.1.1 Kommunikation... 14 3.1.2 Einfachheit..... 14 3.1.3 Feedback...... 15 3.1.4 Mut... 16 3.1.5 Respekt... 16 3.2 Die14Prinzipien... 17 3.2.1 Menschlichkeit... 17 3.2.2 Wirtschaftlichkeit... 17 3.2.3 Wechselseitiger Vorteil.... 18 3.2.4 Selbstähnlichkeit... 18 3.2.5 Verbesserung... 18 3.2.6 Vielfältigkeit.... 18 3.2.7 Reflexion... 19 3.2.8 Fluss... 19 3.2.9 Gelegenheit..... 19 3.2.10 Redundanz...... 19 3.2.11 Fehlschlag...... 20 xiii

xiv Inhaltsverzeichnis 3.2.12 Qualität... 20 3.2.13 Kleine Schritte... 20 3.2.14 Akzeptierte Verantwortung... 20 3.3 Prozessschritte und traditionelle XP-Praktiken...... 20 3.3.1 Planung... 21 3.3.2 DesignderSoftware... 27 3.3.3 Kodieren... 30 3.3.4 TestenderSoftware... 36 3.4 ErweiterteXP-Praktiken... 37 3.4.1 Primärpraktiken... 38 3.4.2 Folgepraktiken... 40 3.4.3 Unterschiede zwischen erweiterten und traditionellenxp-praktiken... 42 3.5 BerühmteXP-Praktiken... 43 3.5.1 ErstellenvonUserStories... 44 3.5.2 PaarweisesProgrammieren... 44 3.5.3 Collective Code Ownership, Shared Code.... 44 3.5.4 Kontinuierliche Code-Integration, eine Codebasis.... 45 3.5.5 Kunde im Team, Einbeziehung des Kunden... 45 Literatur... 45 4 Crystal und Crystal Clear... 47 4.1 Teamgröße und Risiko die Crystal-Familie... 47 4.2 Die sieben Crystal-Eigenschaften... 49 4.2.1 RegelmäßigeLieferung... 49 4.2.2 Reflektierte Verbesserung... 49 4.2.3 Verdichtete oder osmotische Kommunikation...... 50 4.2.4 Persönliche Sicherheit..... 51 4.2.5 Schwerpunkte bilden..... 51 4.2.6 Einfache Kontaktaufnahme mit Endanwendern..... 52 4.2.7 Technische Umgebung mit automatisierten Tests, Konfigurationsmanagement und regelmäßige Integrationen 52 4.3 CrystalClear... 53 4.3.1 Eigenschaften und Praktiken...... 53 4.3.2 RollenimProjektteam... 56 Literatur... 59 5 Scrum... 61 5.1 Scrum dieprojektrollen... 61 5.1.1 Product Owner... 62 5.1.2 Team... 63 5.1.3 ScrumMaster... 65 5.1.4 WeitereScrum-Rollen... 67 5.1.5 Gefahr durch Rollenmissbrauch.... 67 5.2 Scrum der Prozess..... 68 5.2.1 Scrum-Flow Überblick... 68 5.2.2 Sprint Details... 69

Inhaltsverzeichnis xv 5.3 Scrum-Artefakte... 73 5.3.1 Product Backlog... 73 5.3.2 Sprint Backlog... 75 5.3.3 ReleaseplanundBurndownChart... 75 Literatur... 77 6 Experimentelles Software-Engineering im studentischen Labor... 79 6.1 Die Projekte im studentischen Labor...... 80 6.2 Randbedingungen der studentischen Sessions...... 82 6.3 Veränderung der klassischen Projektrollen in agilen Projekten... 84 6.3.1 Der Projektmanager im agilen Projekt...... 84 6.3.2 Der Qualitätsmanager im agilen Projekt..... 88 6.4 Neue Teamrolle der Integrationsingenieur... 92 6.5 Veränderung agiler Praktiken und Prozesse in der Praxis.... 93 6.5.1 DesignvonUserStories... 93 6.5.2 CollectiveCodeOwnership... 94 6.5.3 Mini-Team-Größe: Sind XP-Paare erfolgreich?..... 94 6.5.4 Der Weg zur erfolgreichen Software-Integration..... 100 6.5.5 Crystal und die reflektierte Verbesserung..... 103 6.5.6 Scrum im studentischen Labor..... 107 6.5.7 Hierarchische Prozesse unter dem agilen Deckmantel... 115 Literatur... 117 7 MAP Meta Agile Process Model... 119 7.1 Team-Psychologie Landkarte der Verhaltensweisen imteam... 119 7.2 Das Super-Team... 122 7.3 WasistMAP?... 123 7.4 MAP dieprojektrollenimteam... 124 7.4.1 Kunde... 125 7.4.2 Kommunikationsmanager... 125 7.4.3 Integrationsingenieur..... 127 7.4.4 Team... 128 7.4.5 Prozessverantwortlicher der MAP-Beobachter..... 129 7.4.6 Projektrollen in der Landkarte der Verhaltensweisen... 130 7.5 MAP Cycle der Referenzprozess... 131 7.6 MAPundScrum... 133 7.6.1 VergleichderRollen... 133 7.6.2 Bestimmung des Product Owners.... 136 7.6.3 Prozess... 139 7.6.4 Artefakte... 141 7.6.5 MAP und Scrum geht das?...... 142 7.6.6 Vorteile für Scrum-Anwender...... 143 7.7 MAPimreguliertenUmfeld... 143 7.8 MAP-Projekt in der Industrie..... 146 Literatur... 147

Kapitel 1 Software-Prozessmodelle Ein Software-Prozessmodell ist ein Modell für die Entwicklung eines Software-Systems. Da Modellbildung immer auch Abstraktion beinhaltet, geht es nicht um die Darstellung des Ablaufs eines bestimmten Software-Entwicklungsprojekts, sondern einer ganzen Klasse von Projekten. Daraus ergibt sich, dass nicht jedes Prozessmodell für jede Klasse von Projekten geeignet ist. Es gibt grundsätzlich schwergewichtige und leichtgewichtige Prozessmodelle, wobei die agilen Modelle zu den leichtgewichtigen gehören. 1.1 Ein Prozessmodell was ist das? Ein Software-Prozessmodell ist ein Modell für den Ablauf der Entwicklung eines Software-Systems. Dabei geht es nicht um die Darstellung des Ablaufs eines bestimmten Software-Entwicklungsprojekts, sondern einer ganzen Klasse von Projekten. Dazu wird der Entwicklungsprozess üblicherweise in Phasen eingeteilt. Man unterscheidet typischerweise zwischen Planung des Prozesses, Spezifikation der Anforderungen an das Produkt, Design des Software-Produkts, Implementierung (Kodierung) und diversen Tests des Software-Produkts. Im Rahmen eines Prozessmodells werden neben den Aktivitäten innerhalb dieser Phasen auch die Rollen und Qualifikationen der Mitarbeiter definiert, die gewisse Aktivitäten durchführen oder für sie verantwortlich sind. Außerdem werden die Dokumente und Unterlagen, zusammenfassend Artefakte 1 genannt, festgelegt, die im Rahmen des Entwicklungsprozesses erstellt werden müssen. Oftmals sind hierbei auch Vorgaben von Behörden zu beachten. Es gibt nicht das Prozessmodell für alle Typen von Software-Entwicklungsmodellen. Ausschlaggebend für die Wahl eines Prozessmodells ist der Projekttyp. 1 Zum Begriff des Artefakts (engl. artifact) siehe (Jacobson et al. 1999). E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, examen.press, DOI 10.1007/978-3-642-12313-9_1, C Springer-Verlag Berlin Heidelberg 2010 1

2 1 Software-Prozessmodelle 1.1.1 Einteilung in Projekttypen Eine frühe Einteilung in Projekttypen nimmt Barry Boehm bereits in den 1980er Jahren vor (Boehm 1981). Er unterscheidet zwischen organic, semidetached und embedded Projekten: Organic Mode-Projekte haben relativ kleine Entwicklungsteams, die Software in enger räumlicher Nähe entwickeln. Die Teammitglieder sind meist sehr erfahren, sowohl fachlich als auch methodisch. Meist wissen sie über das spätere Einsatzgebiet der Software recht gut Bescheid. Oft ist die Code-Größe der Software recht gering. 2 Embedded Mode-Projekte sind das Gegenteil zum oben besprochenen Projekttyp. Sie unterliegen starken Zwangsbedingungen, sind meist reguliert, d.h. von behördlichen Auflagen geprägt, oder sie unterliegen anderen Zwängen, z.b. den Unwägbarkeiten hardware-naher Projekte. 3 Die entwickelte Software muss hohen Anforderungen an die Zuverlässigkeit des Systems genügen, und meist sind nachträgliche Software-Anpassungen nahezu unmöglich. Das Entwicklungsteam ist meist groß. Dies hat auch damit zu tun, dass die Anforderungen an die Software detailliert beschrieben sind, was oftmals Platz für Parallelisierung der Entwicklungsarbeit schafft. Das Entwicklerteam besteht aus erfahrenen und unerfahrenen Mitgliedern. 4 Oft ist die Code-Größe der Software sehr hoch. Semidetached Mode-Projekte stehen zwischen den oben beschriebenen Projekttypen und bilden eine Mischung aus Organic und Embedded Mode. Die Software-Entwicklungsteams sind meist mittelgroß und bestehen aus erfahrenen und unerfahrenen Programmierern. Oft sind nicht alle Aspekte des Produkts bekannt. Die Code-Größe ist meist hoch. 1.1.2 Schwergewichtige und leichtgewichtige Prozessmodelle Die vorgestellte Einteilung in Projekttypen ermöglicht auch eine entsprechende Einteilung der Software-Prozesse und ihrer Prozessmodelle in schwergewichtige und leichtgewichtige Modelle 5 : Schwergewichtige Prozessmodelle zeichnen sich durch eine sehr formale, dokumentengestützte Vorgehensweise aus. Jede Phase der Entwicklung wird ausführlich dokumentiert, der Prozess selbst ist in seinem Ablauf klar beschrieben und hält auch behördlicher Begutachtung stand. Der Einsatz schwergewichtiger Prozessmodelle ist sinnvoll, wenn eine Fehlfunktion des Software-Produkts eine 2 Dies ist aber keine Bedingung für den Organic Mode. 3 Die Entwicklung der Software in einem militärischen Projekt gehört sicherlich zu dieser Klasse. 4 Dies ergibt sich alleine schon aufgrund der Größe des Teams. 5 Der Begriff leichtgewichtiger Prozess begegnete dem Autor zum ersten Mal in (Fowler u. Scott 2000).

1.2 Das Phasenmodell 3 Gefahr für Leib und Leben provozieren kann. Schwergewichtige Prozessmodelle gelten aber auch als unflexibel, insbesondere in Projekten mit wechselnden Anforderungen. Sie sind besonders geeignet für den Einsatz in Embedded Modeund meist auch in Semidetached Mode-Projekten. Leichtgewichtige Prozessmodelle sind dagegen eher geeignet für Software- Projekte in kleinen Teams, wo die Anforderungen an das Produkt anfangs nur unvollständig bekannt sind. Ausführliche Spezifikationen machen damit wenig Sinn, da die Gefahr der Änderung zu groß ist. Gleichzeitig ist die Kommunikation im Team und mit dem Kunden aufgrund der kleinen Teamgröße sehr gut. Viele Informationen fließen informell, müssen also nicht explizit schriftlich fixiert werden. Die funktionierende Software steht im Vordergrund und nicht ihre Dokumentation. Leichtgewichtige Prozessmodelle sind besonders geeignet für den Einsatz in Organic Mode-, manchmal auch in Semidetached-Mode-Projekten. Die in diesem Buch behandelten agilen Prozessmodelle gehören zur Gruppe der leichtgewichtigen Prozessmodelle. 1.1.3 Prozessmodell vs. Vorgehensmodell Im deutschen Sprachraum wird anstelle des Begriffs Prozessmodell gerne das Wort Vorgehensmodell benutzt. 6 Grundsätzlich kann man diese Begriffe synonym verwenden. Es fällt allerdings auf, dass das in Deutschland dominierende Vorgehensmodell, das V-Modell, zumindest in der frühen Version V-Modell 97 keine Aussagen über die Interna des eigentlichen Software-Entwicklungsprozesses machte. 7 Lediglich die Dokumentenschnittstelle zwischen Auftraggeber und Entwickler wurde umfangreich definiert. Auch die gebräuchliche Rückübersetzung von Vorgehensmodell als Life Cycle Model lässt den Schluss zu, dass es eine Differenzierung zum Begriff des Prozessmodells gibt. Der Autor wird deshalb in diesem Buch zwischen Prozessmodell und Vorgehensmodell unterscheiden. Immer wenn es um die Interna des Software- Entwicklungsprozesses geht, wird vom Prozessmodell die Rede sein. Geht es mehr um den Life Cycle und den Blick von außen auf die Entwicklung, wird der Begriff Vorgehensmodell verwendet. 1.2 Das Phasenmodell In den 1970er Jahren konnte man in der Software-Entwicklung noch davon ausgehen, dass die Anforderungen an das Software-Produkt am Anfang des Projekts 6 Prozessmodell entspricht eher direkten Übersetzung des engl. process model. 7 Dies wurde erst mit dem V-Modell XT nachgeholt. Zu empfehlen ist hierzu die Lektüre von (Höhn u. Höppner 2008). Zum V-Modell 97 siehe auch (Dröschel u. Wiemers 2000).