Agile Prozesse: Von XP über Scrum bis MAP (eXamen.press)

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 [email protected]

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 SoftwareEngineering-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-EngineeringVorlesung 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 Ein Prozessmodell – was ist das? . . . . . . . . . . . . . . . . . 1.1.1 Einteilung in Projekttypen . . . . . . . . . . . . . . . . 1.1.2 Schwergewichtige und leichtgewichtige Prozessmodelle . 1.1.3 Prozessmodell vs. Vorgehensmodell . . . . . . . . . . . 1.2 Das Phasenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Das Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Moderne iterativ-inkrementelle Prozessmodelle . . . . . . . . . 1.4.1 V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Unified Software Development Process (UP) . . . . . . . 1.4.3 Agile Prozessmodelle . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

1 1 2 2 3 3 4 6 6 6 7 7

2 Das Agile Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 11

3 Extreme Programming (XP) . . . 3.1 Die fünf Werte . . . . . . . . . 3.1.1 Kommunikation . . . . 3.1.2 Einfachheit . . . . . . 3.1.3 Feedback . . . . . . . 3.1.4 Mut . . . . . . . . . . 3.1.5 Respekt . . . . . . . . 3.2 Die 14 Prinzipien . . . . . . . 3.2.1 Menschlichkeit . . . . 3.2.2 Wirtschaftlichkeit . . . 3.2.3 Wechselseitiger Vorteil 3.2.4 Selbstähnlichkeit . . . 3.2.5 Verbesserung . . . . . 3.2.6 Vielfältigkeit . . . . . 3.2.7 Reflexion . . . . . . . 3.2.8 Fluss . . . . . . . . . . 3.2.9 Gelegenheit . . . . . . 3.2.10 Redundanz . . . . . . . 3.2.11 Fehlschlag . . . . . . .

13 14 14 14 15 16 16 17 17 17 18 18 18 18 19 19 19 19 20

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

xiii

xiv

Inhaltsverzeichnis

3.2.12 Qualität . . . . . . . . . . . . . . . . . . . . . . 3.2.13 Kleine Schritte . . . . . . . . . . . . . . . . . . 3.2.14 Akzeptierte Verantwortung . . . . . . . . . . . . 3.3 Prozessschritte und traditionelle XP-Praktiken . . . . . . 3.3.1 Planung . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Design der Software . . . . . . . . . . . . . . . . 3.3.3 Kodieren . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Testen der Software . . . . . . . . . . . . . . . . 3.4 Erweiterte XP-Praktiken . . . . . . . . . . . . . . . . . 3.4.1 Primärpraktiken . . . . . . . . . . . . . . . . . . 3.4.2 Folgepraktiken . . . . . . . . . . . . . . . . . . 3.4.3 Unterschiede zwischen erweiterten und traditionellen XP-Praktiken . . . . . . . . . . . . 3.5 Berühmte XP-Praktiken . . . . . . . . . . . . . . . . . . 3.5.1 Erstellen von User Stories . . . . . . . . . . . . . 3.5.2 Paarweises Programmieren . . . . . . . . . . . . 3.5.3 Collective Code Ownership, Shared Code . . . . 3.5.4 Kontinuierliche Code-Integration, eine Codebasis 3.5.5 Kunde im Team, Einbeziehung des Kunden . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

20 20 20 20 21 27 30 36 37 38 40

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

42 43 44 44 44 45 45 45

4 Crystal und Crystal Clear . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Teamgröße und Risiko – die Crystal-Familie . . . . . . . . . . . . 4.2 Die sieben Crystal-Eigenschaften . . . . . . . . . . . . . . . . . . 4.2.1 Regelmäßige Lieferung . . . . . . . . . . . . . . . . . . . 4.2.2 Reflektierte Verbesserung . . . . . . . . . . . . . . . . . . 4.2.3 Verdichtete oder osmotische Kommunikation . . . . . . . 4.2.4 Persönliche Sicherheit . . . . . . . . . . . . . . . . . . . . 4.2.5 Schwerpunkte bilden . . . . . . . . . . . . . . . . . . . . 4.2.6 Einfache Kontaktaufnahme mit Endanwendern . . . . . . 4.2.7 Technische Umgebung mit automatisierten Tests, Konfigurationsmanagement und regelmäßige Integrationen 4.3 Crystal Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Eigenschaften und Praktiken . . . . . . . . . . . . . . . . 4.3.2 Rollen im Projektteam . . . . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47 47 49 49 49 50 51 51 52 52 53 53 56 59

5 Scrum . . . . . . . . . . . . . . . . . . . . . 5.1 Scrum – die Projektrollen . . . . . . . . 5.1.1 Product Owner . . . . . . . . . 5.1.2 Team . . . . . . . . . . . . . . . 5.1.3 ScrumMaster . . . . . . . . . . 5.1.4 Weitere Scrum-Rollen . . . . . . 5.1.5 Gefahr durch Rollenmissbrauch 5.2 Scrum – der Prozess . . . . . . . . . . . 5.2.1 Scrum-Flow – Überblick . . . . 5.2.2 Sprint – Details . . . . . . . . .

61 61 62 63 65 67 67 68 68 69

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Inhaltsverzeichnis

5.3

Scrum-Artefakte . . . . . . . . . . . . . . 5.3.1 Product Backlog . . . . . . . . . . 5.3.2 Sprint Backlog . . . . . . . . . . 5.3.3 Releaseplan und Burndown Chart Literatur . . . . . . . . . . . . . . . . . . . . .

xv

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

73 73 75 75 77

6 Experimentelles Software-Engineering im studentischen Labor . 6.1 Die Projekte im studentischen Labor . . . . . . . . . . . . . . 6.2 Randbedingungen der studentischen Sessions . . . . . . . . . 6.3 Veränderung der klassischen Projektrollen in agilen Projekten . 6.3.1 Der Projektmanager im agilen Projekt . . . . . . . . . 6.3.2 Der Qualitätsmanager im agilen Projekt . . . . . . . . 6.4 Neue Teamrolle – der Integrationsingenieur . . . . . . . . . . 6.5 Veränderung agiler Praktiken und Prozesse in der Praxis . . . 6.5.1 Design von User Stories . . . . . . . . . . . . . . . . . 6.5.2 Collective Code Ownership . . . . . . . . . . . . . . . 6.5.3 Mini-Team-Größe: Sind XP-Paare erfolgreich? . . . . 6.5.4 Der Weg zur erfolgreichen Software-Integration . . . . 6.5.5 Crystal und die reflektierte Verbesserung . . . . . . . . 6.5.6 Scrum im studentischen Labor . . . . . . . . . . . . . 6.5.7 Hierarchische Prozesse unter dem agilen Deckmantel . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

79 80 82 84 84 88 92 93 93 94 94 100 103 107 115 117

. . . .

119

. . . . . . . . . . . . . . . . . . . . .

119 122 123 124 125 125 127 128 129 130 131 133 133 136 139 141 142 143 143 146 147

7 MAP – Meta Agile Process Model . . . . . . . . . . . . . . . 7.1 Team-Psychologie – Landkarte der Verhaltensweisen im Team . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Das Super-Team . . . . . . . . . . . . . . . . . . . . . . . 7.3 Was ist MAP? . . . . . . . . . . . . . . . . . . . . . . . . 7.4 MAP – die Projektrollen im Team . . . . . . . . . . . . . 7.4.1 Kunde . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Kommunikationsmanager . . . . . . . . . . . . . . 7.4.3 Integrationsingenieur . . . . . . . . . . . . . . . . 7.4.4 Team . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.5 Prozessverantwortlicher – der MAP-Beobachter . . 7.4.6 Projektrollen in der Landkarte der Verhaltensweisen 7.5 MAP Cycle – der Referenzprozess . . . . . . . . . . . . . 7.6 MAP und Scrum . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Vergleich der Rollen . . . . . . . . . . . . . . . . 7.6.2 Bestimmung des Product Owners . . . . . . . . . . 7.6.3 Prozess . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 Artefakte . . . . . . . . . . . . . . . . . . . . . . 7.6.5 MAP und Scrum – geht das? . . . . . . . . . . . . 7.6.6 Vorteile für Scrum-Anwender . . . . . . . . . . . . 7.7 MAP im regulierten Umfeld . . . . . . . . . . . . . . . . 7.8 MAP-Projekt in der Industrie . . . . . . . . . . . . . . . . Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

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 Artefakte1 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, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_1, 

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“ Modelle5 : • 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. 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). 3 Die

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 SoftwareProjekte 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 SoftwareEntwicklungsprozesses 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).

4

1 Software-Prozessmodelle

Abb. 1.1 Das Phasenmodell nach Royce

definiert wurden und sich bis zum Schluss nicht mehr änderten.8 Royce entwickelte deshalb 1979 das Phasenmodell (Royce 1970).9 In einer vereinfachten Form (Fairley 1985) zeigt es die fünf, zeitlich hintereinander folgenden Phasen des Software-Entwicklungsprozesses10 (Abb. 1.1). Aus Abb. 1.1 wird deutlich, warum das Phasenmodell auch „Wasserfallmodell“ genannt wird. Die Phasen sind in Form von Kaskaden eines mehrstufigen Wasserfalls angeordnet. Die Rückpfeile sind Verifizierungspfeile. Nach der Kodierung eines Moduls wird beispielsweise verifiziert, ob das Modul mit den Vorgaben der DesignPhase, den Architekturdetails, übereinstimmt. So wird immer gegen die (zeitlich) vorhergehende Phase verifiziert. Erst bei den abschließenden Akzeptanztests wird nochmals gegen die Spezifikationen verifiziert.

1.3 Das Spiralmodell In den 1980er Jahren wurde es immer dringlicher, Prozessmodelle zu entwickeln, welche es zulassen, eine Software in aufeinander aufbauenden Versionen zu

8 War

dies doch einmal der Fall, wurde das Projekt neu aufgelegt. hierzu auch (Boehm 1981) oder (Fairley 1985). 10 Boehm kennt acht Phasen. Im Grunde detailliert er Abb. 1.1 nur weiter (Boehm 1981). 9 Siehe

1.3

Das Spiralmodell

5

Abb. 1.2 Die Vision des Endprodukts als„Moving Target“

entwickeln. Das Phasenmodell war immer dann unzureichend, wenn Software in „Stücken“, sog. Iterationen, entwickelt werden musste. Dies war insbesondere dann der Fall, wenn die Anforderungen an ein Software-Produkt anfangs nicht bis ins Detail geklärt waren oder sich im Laufe des Projekts änderten („Moving Targets“, siehe Abb. 1.2).11 Barry Boehm schlug für solche Fälle Mitte der 1980er Jahre das sog. Spiralmodell vor.12 Es beschreibt den sog. iterativ-inkrementellen Entwicklungsprozess von Software. Der Entwicklungsprozess wird in zeitliche Abschnitte eingeteilt, in denen eine neue Funktionalität der Software implementiert wird, die sog. Iterationen. Für jede dieser Iterationen findet das Phasenmodell mit seinen Phasen Analyse bis Systemtest Anwendung. Das Phasenmodell wird also pro Iteration einmal durchlaufen. Am Ende jeder Phase steht das Inkrement (falls in der Iteration nicht lediglich Fehler oder Missverständnisse korrigiert wurden), die neue Funktionalität der Software. Ein oder mehrere Inkremente ergeben eine neue Release oder Version. Das Spiralmodell ist genau genommen kein Prozessmodell, sondern ein „Meta Modell“. Auf dem Ansatz der iterativ-inkrementellen Software-Entwicklung setzen alle modernen Prozessmodelle auf.

11 Bei der Entwicklung von Software für Maschinensteuerungen kam man auch weiterhin mit dem

Phasenmodell aus. dazu (Boehm 1986) oder (Boehm 1988).

12 Siehe

6

1 Software-Prozessmodelle

1.4 Moderne iterativ-inkrementelle Prozessmodelle Zur Einteilung einiger aktueller Prozessmodelle soll die Klassifizierung in schwergewichtige und leichtgewichtige Prozessmodelle dienen. Als erstes seien zwei Vertreter der schwergewichtigen Prozessmodelle erwähnt:

1.4.1 V-Modell Das V-Modell ist besonders in Deutschland und Österreich verbreitet und ist in der aktuellen Version V-Modell XT das Vorgehensmodell des Bundes (Höhn u. Höppner 2008). Es ist sehr stark im „regulierten“ Umfeld verbreitet, besonders auch in der pharmazeutischen Industrie, dort aber meist in der historisch ältesten Version, dem V-Modell nach Boehm (Boehm 1979). Kritiker bemängeln die starke „Dokumentenlastigkeit“ des Modells, die die Projektkosten erhöht. Insbesondere in der pharmazeutischen Industrie werden deshalb Wege gesucht, kostengünstigere Vorgehensmodelle anzuwenden (siehe auch Kap. 7.7).

1.4.2 Unified Software Development Process (UP) UP ist das Resultat der Entwicklung eines iterativ-inkrementellen Prozessmodells bei der Firma Rational in den USA13 (Jacobson et al. 1999). Der UP besteht aus vier Phasen: Inception (Einstieg), Elaboration (Ausarbeitung), Construction (Konstruktion) und Transition Phase (Übergang) (Abb. 1.3). Während in der Inception-Phase der Einstieg in das Projekt erfolgt, dient die Elaboration Phase zum Erstellen der Risikoanalyse, der Spezifikationen in Form von Use Cases und der Basisarchitektur des Systems. Außerdem wird die Construction Phase geplant, in der die eigentliche Systemerstellung stattfindet. In der Construction Phase werden die Iterationen zur Systemerstellung durchgeführt. Pro Iteration finden die vom Phasenmodell her bekannten Phasen Detailanforderungsanalyse, Detaildesign, Kodierung, (Modul-) Test und Integration statt. Die Iteration endet mit einer Kundendemonstration.

Abb. 1.3 Der Unified Process (UP)

13 Rational

wurde 2002 von IBM akquiriert.

Literatur

7

Auch der UP gilt mit seinen vielen vorgeschriebenen Management- und Ingenieursartefakten als sehr dokumentenlastig (und damit als teuer).

1.4.3 Agile Prozessmodelle Im Gegensatz zu den beiden bisher beschriebenen Prozessmodellen gelten die agile Modelle als leichtgewichtig. Nicht die Dokumentation steht im Vordergrund, sondern funktionierender Code. Trotzdem sind agile Projekte nicht anarchisch. Weder ist die Vorgehensweise im Projekt chaotisch, noch ist es verboten, zu dokumentieren. Lediglich die Gewichtung ist eine andere. Grundsätzlich dürfen nur Prozesse als agil bezeichnet werden, die dem agilen Manifest entsprechen. Dieses soll im nächsten Kapitel näher beleuchtet werden.

Literatur Boehm B (1979) Guidelines for verifying and validating software requirements and design specifications. EURO IFIP 79, pp. 711–719, North Holland 1979 Boehm B (1981) Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall Boehm B (1986) A spiral model of software development and enhancement. ACM SIGSOFT Software Engineering Notes, August 1986 Boehm B (1988) A spiral model of software development and enhancement. IEEE Computer, Vol. 21, Ausg. 5, Mai 1988, pp. 61–72 Dröschel W, Wiemers M (2000) Das V-Modell 97. München: Oldenbourg Fairley R (1985) Software Engineering Concepts. New York, NY: McGraw-Hill Fowler M, Scott K (2000) UML konzentriert. Bonn: Addison-Wesley Höhn R, Höppner S (2008) Das V-Modell XT. New York, NY: Springer Jacobson I, Booch G, Rumbaugh J (1999) The Unified Software Development Process. Reading, MA: Addison-Wesley Royce W (1970) Managing the development of large software systems. Proceedings of IEEE WESCON, Vol. 26, pp. 1–9.

Kapitel 2

Das Agile Manifest

Branchen wie etwa die militärische oder pharmazeutische Software-Entwicklung, die Verantwortung für Leib und Leben tragen, können nicht auf ausführliche Dokumentation verzichten. Das verlangen zu Recht die zuständigen Behörden. Es handelt sich jedoch um eng abgegrenzte Felder. In der Mehrzahl der Software-Projekte jedoch sollte die Entwicklung funktionierender Software im Mittelpunkt stehen, was Kritiker wie Ward Cunningham, Martin Fowler, Alistair Cockburn oder Kent Beck betonen. Dies führte 2001 zur Verkündung des „Manifesto for Agile Software Development“, des Agilen Manifests.

Das Agile Manifest ist eine Reaktion der Entwickler auf die sog. „schwergewichtigen“ Prozess- bzw. Vorgehensmodelle, wie den Unified Process (UP) (Jacobson et al. 1999) von Rational (jetzt IBM) oder das V-Modell,14 das Vorgehensmodell der deutschen Bundesbehörden. Obwohl beide Ansätze sehr unterschiedlich sind – UP beleuchtet den iterativ-inkrementellen Software-Entwicklungsprozess, während das V-Modell die Sicht des Kunden auf das Software-Projekt in den Vordergrund stellt – gelten beide als sehr „dokumentenlastig“, was zumindest bei „Anfängern“ erheblichen zusätzlichen Aufwand bedeutet. Nun muss man wissen, dass Software-Entwickler ihren Beruf wählen, um Software-Lösungen zu designen und zu implementieren. Allzu viel Dokumentation ist ihnen eher lästig. Es braucht üblicherweise große Überzeugungsarbeit hinsichtlich der Notwendigkeit einer aufwändigen Dokumentation, wie der Autor aus eigener Erfahrung weiß. Das mittlerweile weltweit unterstützte Agile Manifest (Beck et al. 2001) zeigt einen Ausweg aus dieser Problematik. Es definiert vier Leitsätze für eine erfolgreiche und effiziente Software-Entwicklung: • Die individuellen Beteiligten und ihre Interaktion sind wichtiger als Prozesse und Werkzeuge. • Die Ablieferung lauffähiger Software ist wichtiger als umfassende Dokumentation. • Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

14 Zum

aktuellen V-Modell XT siehe (Höhn u. Höppner 2008) oder (Friedrich et al. 2009), zum „alten“ V-Modell 97 siehe (Dröschel u. Wiemers 2000).

E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, eXamen.press, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_2, 

9

10

2 Das Agile Manifest

• Auf Änderungen der Anforderungen einzugehen ist wichtiger als die sture Verfolgung eines Plans. Die agilen Leitsätze liest man sinnvollerweise „von rechts nach links“: • Prozesse und Werkzeuge sind wichtig, aber wichtiger sind im Zweifelsfall die am Projekt Beteiligten und ihre Interaktionen. • Dokumentation (auch eine umfassende) ist wichtig, aber im Zweifelsfall hat die Ablieferung einer lauffähigen Software Priorität. • Verträge sind wichtig, aber im Zweifelsfall ist die Zusammenarbeit mit dem Kunden wichtiger. • Pläne sind wichtig, aber wenn es erforderlich ist, müssen die Anforderungen eben im Sinne des Kunden geändert (also angepasst) werden. Besonders interessant ist die Interpretation des zweiten Leitsatzes: Dokumentation (auch eine umfassende) ist wichtig, aber im Zweifelsfall hat die Ablieferung einer lauffähigen Software Priorität. Dies heißt eben nicht, dass in agilen Projekten nicht dokumentiert werden muss. Es wird lediglich etwas über die Priorität der Dokumentation gesagt. Agile Projekte brauchen also eine besondere, flexible Art der Dokumentation. Statische Dokumente werden der Situation nicht gerecht. Die Lösung sind oft Wikis oder kommerzielle Dokumenten-Management-Produkte, die eine Versionierung und damit eine leichte Änderbarkeit der Dokumente ermöglichen. Mittels einer elektronischen Unterschrift lässt sich auch das Freigabeverfahren der Dokumente vereinfachen. Somit ergibt sich die Möglichkeit, agile Modelle auch im sog. „regulierten Umfeld“15 einzusetzen. Zu Verträgen und Plänen sei gesagt, dass bei Änderungen und Anpassungen, insbesondere in späten Phasen, natürlich das Wohlwollen beider Parteien, des Kunden und der Entwickler, gefragt ist: Die Entwickler müssen wissen und sich dessen auch sicher sein, dass der Kunde sie mit seinem Änderungswunsch nicht einfach nur „ärgern“ will, sondern in der Regel ein vitales Interesse hat. Der Kunde muss sich seinerseits im Klaren darüber sein, dass sowohl Spezifikations- wie auch und Planänderungen einen erheblichen Mehraufwand bedingen, der auch bezahlt sein will. Insbesondere bei Festpreisangeboten muss hier ggf. nachverhandelt bzw. der Funktionsumfang im Rahmen der Iterationsplanung neu definiert werden. Wichtig ist bei alledem, dass niemals die Qualität des Software-Produkts unter solchen Änderungen leidet. Dies muss durch vorher definierte Testverfahren (insbesondere auch durch automatisiertes Testen) ausgeschlossen werden. Das Agile Manifest stellt mit seinen vier Leitsätzen eine Art Randbedingungen der leichtgewichtigen Software-Entwicklung dar. Doch als Durchführungshilfen in einem konkreten Prozess sind sie weniger geeignet. Die diversen Prozessmodelle, wie die in der Folge diskutierten, haben die Aufgabe, die agilen Leitsätze umzusetzen. 15 Von einem regulierten Umfeld spricht man bei von Behörden kontrollierten Projektumgebungen.

Literatur

11

Literatur Beck K et al. (2001) www.agilemanifesto.org. Zugriff Oktober 2009 Dröschel W, Wiemers M (2000) Das V-Modell 97. München: Oldenburg Friedrich J, Hammerschall U, Kuhrmann M, Sihling M (2009) Das V-Modell XT, New York, NY: Springer Höhn R, Höppner S (2008) Das V-Modell XT, Berlin: Springer Jacobson I, Booch G, Rumbaugh R (1999) Unified Software Development Process. Reading, MA: Addison-Wesley

Kapitel 3

Extreme Programming (XP)

Als Kent Beck 1996 sein Prozessmodell Extreme Programming im Rahmen des ChryslerProjekts C3 entwickelte, war das Projekt bereits so gut wie gescheitert. Man war also bereit, auf neue Ansätze zu hören und gab somit Beck die Möglichkeit, seine zuerst informelle agile Praxis als neues Prozessmodell zu formulieren. Nach Becks eigener Aussage war das C3-Projekt ideal für seinen neuen Ansatz, weil sich die Spezifikationen schnell änderten und weil der Kunde keine endgültige Vorstellung vom Funktionsumfang hatte. In der ersten Phase war C3 sehr erfolgreich und wurde 1997 produktiv. Somit wurde C3 zum „Flaggschiff“ für XP.

Kent Beck entwickelte sein Prozessmodell Extreme Programming (XP) (Beck 2000) im Rahmen des Chrysler-Projekts Chrysler Comprehensive Compensation (C3), das die Entwicklung einer Lohn- und Gehaltslisten-Software zum Ziel hatte (Beck u. Andres 2004). Das Projekt war zum Zeitpunkt des Eintretens von Beck bereits so gut wie gescheitert. Leider ist dies sehr oft erst die Voraussetzung, neuen Ansätzen eine Chance zu geben. Man gab also Beck die Möglichkeit, seine zuerst informellen agilen Projektpraktiken als neues Prozessmodell zu formulieren und das SmalltalkProjekt neu zu starten. Nach Becks eigener Aussage war das Projekt ideal für seinen neuen Ansatz, • • • • •

weil sich die Spezifikationen schnell änderten, weil der Kunde keine endgültige Vorstellung vom Funktionsumfang hatte, weil eine hohe Produktivität der Programmierer gefordert war, weil das Projekt ein (auch zeitlich) hohes Risiko in sich trug, weil die Projektgruppe inkl. Managern, Programmierern und Kunden eine Stärke von weniger als zwölf Mitarbeitern hatte • und weil die zu erstellende Software automatisiertes Testen erlaubte. Im Gegensatz zu anderen Verfechtern des Agilen Manifests, wie z.B. Alistair Cockburn, dem Begründer des Crystal-Prozessmodells (Kap. 4), schreibt Kent Beck die Vorgehensweisen im Projekt strikt vor. XP definiert „Rules and Practices“ zu Planung, Design, Kodierung und Testen, auf deren Einhaltung bestanden wird. Über allen Regeln stehen die fünf Werte: Kommunikation, Einfachheit, Feedback, Mut und Respekt. E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, eXamen.press, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_3, 

13

14

3 Extreme Programming (XP)

3.1 Die fünf Werte 3.1.1 Kommunikation Entscheidend für den Erfolg eines agilen Projekts ist die Kommunikation. Wir unterscheiden mindestens zwei Arten: die Kommunikation mit dem Kunden und die interne Kommunikation im Entwicklerteam. Die interne Kommunikation ist die Grundlage für ein gemeinsames Vorgehen im Projekt. Nur wenn die Teammitglieder miteinander kommunizieren, ist die Grundlage gegeben, dass jedem Teammitglied die gemeinsamen Ziele des Teams bekannt sind. Außerdem kann sehr effizient auf abweichende Projektziele16 reagiert werden. Interne Teamkommunikation gibt es nicht zum Nulltarif. Wie später noch gezeigt wird, ist ein vernünftiger psychologischer Prozess unabdingbar. Dies kann nur durch eine entsprechende Auswahl der Teammitglieder erreicht werden. Die Kommunikation mit dem Kunden ist deutlich schwieriger als die interne Teamkommunikation. Oft sträubt sich das Team, den Kunden ins Team „aufzunehmen“, d.h. ihn als Teammitglied vor Ort zu akzeptieren, so wie es von Beck gefordert wird (Beck 2000). Immer wieder fällt auf, dass das Team Angst davor hat, dem Kunden zu sehr Einblicke in die projektinternen Abläufe zu gewähren. Oft hört man das Argument, der Kunde traute dem Team keine professionelle SoftwareEntwicklung zu, wenn er wüsste, wie intern „gebastelt“ würde. In der Praxis ist meist das Gegenteil der Fall. Der Kunde freut sich über die interne Sichtweise auf das Projekt, die ihm gewährt wird. Er fühlt sich ernst genommen und hat bereits in frühen Projektphasen Anteil an Erfolg und Misserfolg. Seine Achtung vor den Fähigkeiten des Teams wächst, und er entwickelt Verständnis für Probleme im Projektablauf.

3.1.2 Einfachheit XP sucht immer nach der einfachsten Lösung, zumindest zum aktuellen Zeitpunkt. Dies betrifft nicht nur das Design einer Software, sondern auch den Ablauf, die Planung des Projekts. Bewusst beschäftigt man sich nicht mit Dingen, die man erst in späteren Releases implementieren muss. Man wählt immer die einfachste Lösung eines Problems, z.B. bei der Implementierung eines Algorithmus. Der Autor hat selbst miterlebt, wie in einem Messtechnik-Projekt ein genialer generischer Algorithmus zur dynamischen Erzeugung von Objekten zur Hardwarekapselung nach ein paar Jahren nicht mehr erweiterbar war. Der „Vater“ des Algorithmus hatte das Projektteam verlassen und kein anderes Teammitglied hatte dessen Code hinreichend gut verstanden. Berücksichtigt man, dass insgesamt nur etwa fünf HardwareObjekte mit diesem Algorithmus dynamisch erzeugt wurden, war die Komplexität des generischen Algorithmus im Nachhinein sicherlich nicht zu rechtfertigen. 16 sog.

Moving Targets.

3.1

Die fünf Werte

15

3.1.3 Feedback Feedback (Rückkopplung) hat mehrere Facetten. Einerseits ist das Feedback des Systems gemeint. Wenn man Testfälle (Test Cases) schreibt und diese mit Erfolg durchlaufen werden, erhält man vom Software-System das Feedback, dass die spezifizierte Funktionalität korrekt implementiert wurde. Die Summe aller Testfälle ersetzt damit mehr und mehr die klassische funktionale Spezifikation. Änderungen der Spezifikation müssen nicht mehr zwingend schriftlich niedergelegt werden. Das Feedback des Systems, dass ein angepasster Testfall erfolgreich durchlaufen wurde, ist der Beweis, dass die Änderung der Anforderung erfolgreich implementiert wurde. Feedback ist aber auch wichtig in der Kunden-Lieferanten-Beziehung. Im klassischen Ansatz entwickelt der Kunde eine Benutzeranforderung, die User Requirements Specification (URS), manchmal auch Lastenheft genannt. Dies erfordert aber vom Kunden eine ingenieursmäßige oder vergleichbare Ausbildung. Wenn der Kunde diese Qualifikation nicht hat, muss er einen entsprechenden Consultant engagieren. Da die funktionale Anforderung, die Functional Specification (FS) oder auch Pflichtenheft, vom Lieferanten geschrieben wird, entsteht oft die Situation, dass zwei aus Kundensicht fachfremde Parteien sowohl Lasten- als auch Pflichtenheft schreiben. Dem Kunden obliegt bestenfalls die Aufgabe, die entstandenen Dokumente zu unterzeichnen. Zeigen sich im Verlauf der Implementierung der Software im Funktionsumfang Abweichungen von ursprünglichen (aber nicht dokumentierten) Vorstellungen des Kunden, kommt es zu Differenzen. Da diese meist in späteren Projektphasen auftreten, wird es immer schwieriger die Wünsche des Kunden in die Software „einzubauen“. Agile Ansätze, insbesondere XP, versuchen, dieses Problem durch Feedback zu vermeiden. Der Lieferant, also das Software-Entwicklungsteam, verpflichtet sich, dem Kunden möglichst schnell den aktuellen Stand der Software vorzustellen. Idealerweise kann der Kunde immer einen Stand sehen, der nicht älter als ein Iterations-Schritt, also in der Regel nicht älter als wenige Wochen ist. Auf der anderen Seite muss der Kunde ein qualifiziertes Feedback geben. Dazu gehört, dass es sich um den richtigen Kunden handelt. (Diese Forderung ist eigentlich trivial!) Er muss später einer der Anwender der Software sein und muss über die Kompetenz verfügen, Entscheidungen über den Funktionsumfang sowohl fachlich, als auch verantwortlich zu fällen. Das Entwicklerteam darf also vom Kunden die fachliche Kompetenz der Zielgruppe der Software erwarten – aber keine Kompetenz im Bereich des Software-Engineerings! Die Kommunikation muss in der Sprache des Kunden erfolgen. Dies erfolgt am besten an Hand der aktuellen Implementierung (Release). Nur wenn der Kunde Anwender ist und mit der Software arbeiten kann, kann er auch letztendlich beurteilen, ob sie seinen Bedürfnissen entspricht. Dabei ist es aus der Erfahrung des Autors nicht so entscheidend, ob die Software fehlerfrei läuft. Man kann dem Kunden fehlerhafte Features der Software erklären und ihn auf die nächste Release verweisen. Meistens kann der Kunde trotz einiger Detailfehler durchaus beurteilen, ob die Software seine Bedürfnisse abdeckt. Es ist also wichtiger, schnell das Feedback des Kunden auf neue Funktionen der Software zu erhalten, als ihm eine fehlerfreie Software vorzustellen. Dasselbe gilt auch für die

16

3 Extreme Programming (XP)

Projektplanung. Dem Kunden eine ehrliche Terminplanung vorzustellen, ermöglicht diesem ein ehrliches Feedback. Dem Kunden so tiefe Einsichten in das Projekt zu geben, fällt dem Entwicklerteam in der Regel schwer, wie schon im Abschnitt über Kommunikation dargestellt wurde. Es gehört eine gehörige Portion Vertrauen und Mut dazu!

3.1.4 Mut Schnell sich ändernde Projekte resultieren zwangsläufig in zweitklassigen Designs. In Laboren mit studentischen Arbeitsgruppen zeigt sich dieser Effekt genauso wie in Projekten in der Unternehmenspraxis. Oft wird Code solange angepasst, bis es einfacher wäre, alles wegzuwerfen und neu anzufangen. Dasselbe gilt für das Design. Wenn das Team am Anfang des Projekts das endgültige Ziel noch nicht vor Augen hat, kann es dieses im Design auch nicht berücksichtigen. Trotzdem ist die Bereitschaft Designs anzupassen und Code ggf. neu zu schreiben sehr gering verbreitet. Oftmals wird bei fehlschlagenden Testfällen ein Design oder ein Stück Code solange angepasst, bis pro neuer Änderung mehr Testfälle schiefgehen als erfolgreiche Testfälle dazukommen. Und trotzdem scheut sich das Team vor der Konsequenz. Das Problem ist die Rechtfertigung u.a. vor Vorgesetzten – vielleicht auch vor dem Kunden. Es wird augenscheinlich, dass man mehr Zeit für die nächste Iteration braucht. Trotzdem ist Refactoring, also die Umstrukturierung des Designs oder des Codes unabdingbar, um auf Dauer die Fehlerrate bei den Testfällen zu reduzieren. Martin Fowler fordert sogar, 10% des Codes pro Iteration neu zu strukturieren (Fowler u. Scott 2000). Dem Autor erscheint dieser Wert allerdings etwas hoch gegriffen. Mut fordert XP aber auch an anderer Stelle. So fordert Kommunikation und Feedback in der Kunden-Lieferantenbeziehung Mut von beiden Seiten, wie oben beschrieben. Aber auch die Anpassung des Prozessmodells als Ganzes kann großen Mut erfordern. Wenn gewisse Rules and Practices von XP nicht funktionieren, so stehen auch sie zur Disposition: Fix XP when it breaks, wie Kent Beck selbst schreibt (Beck 2000). Doch dazu später mehr. Wichtig ist, dass die drei Werte Kommunikation, Einfachheit und Feedback den Mut bereits implizit voraussetzen. Nur ein mutiges Team und ein mutiger Kunde werden die Anforderungen eines agilen Projekts bewältigen können.17

3.1.5 Respekt Im Gegensatz zu den o.g. vier Werten (Beck 2000) fügte Beck diesen Wert erst später hinzu (Beck u. Andres 2004). Respekt ist ein wichtiger Wert für den Umgang miteinander. Sowohl innerhalb des Entwicklerteams als auch in der Beziehung zum 17 Und

diese Aussage gilt auch unabhängig von XP.

3.2

Die 14 Prinzipien

17

Kunden ist Respekt die Basis für einen vertrauensvollen gegenseitigen Umgang. Aus der Sicht des Autors ist Respekt die Grundlage für ein erfolgreiches Projekt.

3.2 Die 14 Prinzipien XP definiert 14 Prinzipien, die aus den fünf Werten abgeleitet werden. Alle konkreten XP-Praktiken müssen auf die Einhaltung dieser Prinzipien geprüft werden: • • • • • • • • • • • • • •

Menschlichkeit Wirtschaftlichkeit Wechselseitiger Vorteil Selbstähnlichkeit Verbesserung Vielfältigkeit Reflexion Fluss Gelegenheit Redundanz Fehlschlag Qualität Kleine Schritte Akzeptierte Verantwortung Im Folgenden sollen die 14 Prinzipien kurz erläutert werden:

3.2.1 Menschlichkeit Es sind Menschen, die Software entwickeln. Also müssen auch die Arbeitsbedingungen menschenwürdig sein. Persönliche Weiterentwicklungsmöglichkeiten der Software-Entwickler, ihre Integration und ihre Akzeptanz im Team müssen gewährleistet sein. Die Entwickler müssen sich in ihrer Projektumgebung wohlfühlen.

3.2.2 Wirtschaftlichkeit Software-Entwicklung muss wirtschaftlich sein. Die reine „Schönheit“ der technischen Lösung nützt niemandem (obwohl Techniker manchmal dazu tendieren). Auch Software-Entwickler müssen akzeptieren, dass das Unternehmen letztlich mit ihrer Lösung Geld verdienen will und muss.18 18 Nicht

umsonst beschäftigen sich in der heutigen Zeit Technik-Studenten an deutschen Hochschulen vermehrt mit betriebswirtschaftlichen Themen.

18

3 Extreme Programming (XP)

3.2.3 Wechselseitiger Vorteil Alles, was im Team getan wird, sollte allen beteiligten Gruppen Vorteile bringen. Man sollte also immer versuchen, „Win-Win“-Situationen zu erreichen. Dokumentiert man z.B. aufwändig im Code, hat man als Nachteil einen aktuellen zeitlichen Mehraufwand. Demgegenüber steht der Vorteil der leichteren Lesbarkeit (zu einem späteren Zeitpunkt!). Der eigene Nachteil steht also in Relation zu einem später möglichen Vorteil einer bislang unbekannten Person. Dies muss gegeneinander abgewogen und in Balance gebracht werden.19

3.2.4 Selbstähnlichkeit Selbstähnlichkeit in der Natur ist gegeben, wenn eine Struktur auf unterschiedlichen Größenskalen gleich ist. Dies kennt man z.B. von ferromagnetischen Strukturen. Es gilt aber auch für die Struktur einer erfolgreichen Lösung eines Problems. Man darf sich nicht scheuen (sondern muss es zum Prinzip erheben), solche erfolgreichen Lösungen auch in andere Kontexte zu kopieren. Hat man ein erfolgreiches Prinzip entdeckt, kann es auf unterschiedlichen (zeitlichen) Skalen funktionieren.

3.2.5 Verbesserung Ständige Verbesserung ist ein Grundprinzip der Software-Entwicklung. Iteratives Vorgehen birgt die Möglichkeit der ständigen Verbesserung der Lösung. Agile Prozesse unterliegen der Verbesserung: Praktiken, die sich nicht bewähren, werden vom agilen Team abgeschafft und durch bessere Praktiken ersetzt.

3.2.6 Vielfältigkeit Teams müssen aus einer Vielfalt von Mitgliedern mit unterschiedlichen Eigenschaften und Fähigkeiten bestehen. Das birgt Konfliktpotenzial, aber auch die Möglichkeit völlig neue Lösungen zu entwickeln. Verschiedene Menschen entwickeln beispielsweise verschiedene Designs, aus denen dann das beste ausgesucht werden kann. Die Zusammensetzung des Teams ist entscheidend für den Erfolg des Teams (Kap. 6 und 7).

19 Ein

Ausweg, den Kent Beck erwähnt, wäre die Einführung gut dokumentierter automatisierter Tests (Beck u. Andres 2004) anstatt (aufwändiger) Code-Dokumentation. Die Tests haben den Vorteil, dass sie dem jetzigen wie dem zukünftigen Entwickler nützen. Außerdem hält ein regelmäßiges Refactoring das Design einfach. Wir haben also eine „Win-Win“-Situation zwischen aktuellem und zukünftigem Entwickler. Der Autor empfiehlt allerdings, nicht völlig auf die Code-Dokumentation zu verzichten.

3.2

Die 14 Prinzipien

19

3.2.7 Reflexion Ein gutes Team denkt darüber nach, wie es arbeitet und wie es seine Arbeit verbessern könnte. Es ist sinnvoll, dass das Team diese Reflexion formalisiert, d.h. bewusst Sitzungen durchführt mit dem Ziel, den Prozess zu verbessern. Aber auch informelle Gespräche zwischen Teammitgliedern dienen diesem Zweck. Agile Prozesse sind immer in Bewegung und auf dem Pfad der ständigen Verbesserung.

3.2.8 Fluss Die iterative Entwicklung von Software soll einen möglichst kontinuierlichen Fluss der ausgelieferten Releases zur Folge haben. Nur so kann dem Kunden ständig ein aktuelles (Zwischen-) Resultat der Entwicklung gezeigt werden. Dies steht im Widerspruch zur Entwicklung in einem „großen Rutsch“, der Big Bang Entwicklung der 1970er und 1980er-Jahre.20

3.2.9 Gelegenheit Jedes Problem birgt die Gelegenheit für eine Verbesserung. Wenn ein Team Probleme hat, muss es sie aktiv angehen. Es reicht nicht aus, nur zu „überleben“, das Team muss besser werden. Aus diesem Prinzip ergibt sich die XP-Praxis des Pair Programming (Kap. 3.3.3): Macht ein Programmierer zu viele Fehler, kann man dieses Problem durch Paar-Programmierung abstellen.21

3.2.10 Redundanz Wenn man kritische Probleme mehrfach angeht, kann man aus den entstehenden Lösungen die beste auswählen. So können unterschiedliche Design-Ansätze bis zum Prototypen entwickelt werden, um dann den effektivsten Ansatz auszuwählen. Auch beim Testen kann Redundanz sinnvoll sein, beispielsweise durch Anhängen einer Testphase nach Ablieferung der fertigen Release.22 Auch das Arbeiten in Programmiererpaaren ist eine redundante XP-Praxis.

20 Phasen-

oder Wasserfall-Modell (Kap. 1). von Kent Beck in (Beck u. Andres 2004). Denkbar wäre natürlich auch die Verbesserung des Schulungswesens. 22 Im regulierten Umfeld z.B. der Pharmaindustrie auch Operational Qualification genannt. 21 Aussage

20

3 Extreme Programming (XP)

3.2.11 Fehlschlag Manchmal muss man Fehlschläge hinnehmen, um den besten Weg zu finden. Wen man bei mehreren Designvorschlägen nicht in der Lage ist, durch Diskussion den besten zu bestimmen, muss man die Designvorschläge ausprobieren und den Fehlschlag eines oder mehrerer Vorschläge hinnehmen. Wichtig ist, dass man dabei Erkenntnis gewinnt.23

3.2.12 Qualität Qualität ist nicht verhandelbar. Ein Team wird nicht schneller, bloß weil es eine mindere Qualität akzeptiert. Meist wird die Produktivität durch Zunahme der Qualität höher. Qualität der Arbeit stärkt auch das Selbstvertrauen des Teams. Man ist stolz auf das Geleistete.

3.2.13 Kleine Schritte Iterationen sollten in kleinen Schritten erfolgen. Insbesondere in agilen Projekten, ist es wichtig, Arbeitsfortschritte (auch kleine Fortschritte) schnell zeigen zu können, um Feedback zu erhalten. Kleine, regelmäßige Schritte bei der Integration der Software verringern den Overhead, der durch die Integration entsteht. Nur wenn Integration selbstverständlich ist, wird sie regelmäßig durchgeführt.

3.2.14 Akzeptierte Verantwortung Verantwortung kann nicht zugewiesen werden, sie muss akzeptiert werden. Das Team muss Verantwortung übernehmen für das Produkt, das im agilen Projekt entsteht. Wenn keiner Verantwortung übernimmt, wird das Projekt scheitern.

3.3 Prozessschritte und traditionelle XP-Praktiken Der von Kent Beck vorgeschlagene Satz von XP-Praktiken hat sich seit den ersten Publikationen verändert bzw. erweitert. Die in (Beck 2000) genannten „traditionellen“ XP-Praktiken, die auch auf der Website von Don Wells beschrieben sind (Wells 2009), unterscheiden sich zum Teil von den Praktiken, die im neueren Buch (Beck u. Andres 2004) erläutert werden.24 Dies wird mit der Weiterentwicklung von XP

23 Dieses 24 Sie

Prinzip korreliert natürlich mit dem Prinzip der Redundanz. werden in diesem Buch als „erweiterte“ Praktiken bezeichnet.

3.3

Prozessschritte und traditionelle XP-Praktiken

21

und der wachsenden Erfahrung mit diesem agilen Prozessmodell begründet. Allerdings ist es meist ein Unterschied „auf den ersten Blick“, der größer erscheint, als er tatsächlich ist. In diesem Kapitel sollen die traditionellen XP-Praktiken erläutert werden. Die vier Phasen des Wasserfallmodells tauchen dabei leicht abgewandelt als Kategorien der Rules and Practices auf: • • • •

Planung Design Kodieren Testen

Alle von Kent Beck vorgeschlagenen XP-Regeln und Praktiken werden diesen Kategorien zugeordnet (Wells 2009). Allerdings lässt XP die Reihenfolge der Regeln und Praktiken offen. Natürlich ist klar, dass das Projektteam mit Planung und Design beginnt, bevor implementiert werden kann. Ist jedoch das Projekt im Gang, ist keine klare Reihenfolge erkennbar. Agilität bedeutet eben auch Freiheit bei der Reihenfolge der Prozessschritte. Allerdings gibt es, wie schon vom Spiralmodell (Kap. 1.3) bekannt, Iterationen und Inkremente, die geplant bzw. designt werden müssen. Die Software wird dann Stück für Stück als Inkremente in kleinen Prozessschritten, den Iterationen, implementiert. Jedes Inkrement kann vom Kunden begutachtet und freigegeben werden. Es soll nicht verschwiegen werden, dass Kent Beck die traditionellen Regeln und Praktiken einige Jahre später anpasste. Trotzdem finden sie sich nach wie vor auf der offiziellen XP-Webseite wieder (Wells 2009) und haben somit ihre Gültigkeit. Da sie zentral sind und viel über das Entstehen von XP verraten, sollen die „traditionellen“ Regeln und Praktiken im Folgenden näher beleuchtet werden.

3.3.1 Planung In der Planungsphase kennt XP folgende traditionellen Regeln und Praktiken: 3.3.1.1 User Stories User Stories sind wie auch die aus dem Unified Process (UP) bekannten Use Cases oder Anwendungsfälle (Fowler u. Scott 2000) eine moderne Spezifikationstechnik. Im Gegensatz zur klassischen statischen Spezifikation des Funktionsumfangs wird in beiden Fällen beschrieben, was im Rahmen des Software-Projekts getan werden soll. Neu an dieser Betrachtungsweise ist der dynamische Aspekt. Während aber der Use Case eine spezielle Art der Minispezifikation darstellt und die Summe der Use Cases das System spezifizieren, handelt es sich bei der User Story mehr um ein Arbeitspaket, welches insbesondere zur Risikoanalyse, Aufwandschätzung und Iterationsplanung benutzt wird (Abb. 3.1 und 3.2). Es geht also nicht darum, möglichst

22

3 Extreme Programming (XP)

Abb. 3.1 User Story Card Board aus dem studentischen Labor

Abb. 3.2 Details einer User Story Card

genau einen Anwendungsfall zu beschreiben, sondern lediglich das Thema in zwei bis drei Halbsätzen anzureißen. Details werden dann später während der Implementierung in Zusammenarbeit mit dem Kunden ausgearbeitet. Der Kunde ist also in diesem Sinne die „wandelnde Spezifikation“. Das Ausarbeiten der User Stories erfordert insbesondere die beiden XP-Werte Kommunikation und Feedback (Kap. 3.1).

3.3

Prozessschritte und traditionelle XP-Praktiken

23

3.3.1.2 Release-Planung – das Planungsspiel Bei der Planung einer auszuliefernden Software-Release unterscheidet XP zwischen zwei teilnehmenden Parteien: der Geschäftsseite und der Entwicklung. Die Geschäftsseite benötigt die Software, die Entwicklung, also das Team, entwickelt die Software. Bei der Planung können Interessenskonflikte der beteiligten Parteien offen zu Tage treten. Aus der Erfahrung des Autors tendieren Entwickler dazu, in alle ihre Aufwandschätzungen „Sicherheit“ einzubauen, während die Geschäftsseite gerne den besten anzunehmenden Projektverlauf als Standard erklärt. Etwas unklar ist die Rolle des Kunden, der eigentlich zur Geschäftsseite gehört, aber aufgrund seiner ständigen Nähe zum Team, als Teammitglied, mit der Zeit auch immer mehr die Sorgen und Nöte der Entwickler verstehen wird. Trotzdem wird er im Zweifelsfall versuchen, die Interessen seines Unternehmens zu vertreten, in der Regel also auf eine schnelle Auslieferung drängen. Das XP-Planungsspiel kennt vier Variablen: Umfang, Ressourcen, Zeit und Qualität. Dabei spielt die Qualität aus der Sicht des Autors eine Sonderrolle. Sie ist keine echte Variable. Ziel muss immer sein, Software maximaler Qualität zu erzeugen, da die Auswirkungen schlechter Qualität, wie unzufriedene Kunden, notwendig werdende Nachbesserungen etc., immer Einfluss auf die anderen Variablen haben. Es bleiben also drei Variablen, von denen die Geschäftsseite maximal zwei beeinflussen darf. Die dritte Variable „gehört“ der Entwicklung. Im Rahmen des Planungsspiels entwirft die Geschäftsseite User Story Cards (Abb. 3.2), allerdings in der Regel unter Mithilfe einiger Mitglieder des Entwicklungsteams, wie in Kap. 6 noch näher erläutert werden wird. Als Regel gibt Kent Beck vor, dass User Stories so definiert werden sollten, dass ihre Bearbeitung etwa ein bis drei Wochen dauern sollte. Ein Release-Plan sollte aus ungefähr 80 ± 20 User Stories bestehen (Wells 2009). Im eigentlichen Planungsspiel werden die User Stories unter Abwägung der Marktanforderungen, des Risikos und anderer Einflüsse zeitlich so angeordnet, dass alle Parteien mit dem sich ergebenden Projektablaufplan einverstanden sind (Abb. 3.3 und 3.4). Neben den XP-Werten Kommunikation und Feedback ist insbesondere der Mut gefordert, den sich ergebenden Konflikten nicht aus dem Weg zu gehen. Insbesondere die Entwickler seien gewarnt, ihre Termine auf Aufforderung der Geschäftsseite nach „unten“ zu korrigieren, ohne gleichzeitig den Funktionsumfang der Software zu reduzieren. Zu optimistische Termine rächen sich, insbesondere weil dann die Geschäftsseite in der Regel nicht mehr weiß, dass sie es war, die diese gefordert hatte.

3.3.1.3 Kleine Releases Kleine Releases garantieren schnelles Feedback. Wenn man Releases plant, die einen sichtbaren Kundennutzen repräsentieren, wie z.B. ein neues Eingabeformular, dann kann der Kunde auch sofort seine Meinung äußern. Da der Kunde Teammitglied ist, spricht natürlich auch nichts dagegen, wenn er eine fertiggestellte User

24

Abb. 3.3 Planungsspiel im studentischen Labor

Abb. 3.4 User Story Card Board im Planungsspiel

3 Extreme Programming (XP)

3.3

Prozessschritte und traditionelle XP-Praktiken

25

Story sofort am Entwicklerarbeitsplatz begutachtet. Allerdings weiß der Autor aus der Erfahrung im studentischen Labor, dass es wichtig ist, dass der Kunde auf einem Integrationsrechner den aktuellen Stand der Release mit allen aktuellen User Stories sehen kann. Doch dazu mehr in Kap. 6 und 7. 3.3.1.4 Messung der Projektgeschwindigkeit Addiert man die geschätzten Aufwände für die User Stories pro Iteration und vergleicht man sie mit den tatsächlichen Aufwänden für die von den User Stories abgeleiteten Aufgaben (Tasks), so erhält man ein Maß für den Fortschritt des Projekts. Im Grunde macht man einen einfachen Soll-Ist-Vergleich, wie er aus der Projektplanung bekannt ist. Selbstverständlich kann man etwas professioneller auch nach Function Point (Hürten 1999) oder COCOMO II (Boehm et al. 2000) schätzen. Der Autor bedient sich gerne solcher komplexeren Methoden. Einfachheit des Prozesses impliziert nicht unbedingt Einfachheit der Schätzmethode. Lohnenswert ist auch immer ein Blick auf die Methoden im GPM-Infocenter.25 3.3.1.5 Iterationen und Iterationsplanung Beck schlägt Iterationslängen von ein bis drei Wochen vor. Die Iteration wird gemeinsam mit dem Kunden im Rahmen eines Iteration Planning Meetings geplant. Üblicherweise wählt sich der Kunde eine oder mehrere User Stories, die für ihn wichtig sind, aus um sie vom Team realisieren zu lassen. Die Aufgabe des Meetings ist eine einvernehmliche Einigung auf Programmieraufgaben (Tasks), die sich aus der oder den ausgewählten User Stories ergeben. Im Rahmen der Iterationsplanung wählen sich die Programmierer einzelne Tasks zur Realisierung aus. Der Autor hat gute Erfahrungen damit gemacht, dass die Programmierer ganze User Stories wählen, weil damit die Verantwortung für einen für den Kunden wichtigen Teilaspekt der Software übernommen wird. So wird letztlich die Kommunikation mit dem Kunden gefördert. Die Programmierer machen für die ausgewählten Tasks eine Detailplanung, deren geschätzte Aufwände wiederum in die Messung der Projektgeschwindigkeit eingehen. Ebenfalls machen sich die Entwickler gleich zu Anfang Gedanken über geeignete Testfälle zur Messung der Erreichung des Ziels der Iteration. Die Test Cases ergeben sich in der Regel direkt aus der bearbeiteten User Story (Abb. 3.5). 3.3.1.6 Move People Around Agile Vorgehensweisen weisen eine große Schwäche auf. Aufgrund der eher dürftigen Dokumentation ist viel Wissen in den Köpfen der Entwickler oder des Kunden vorhanden. Die Frage stellt sich, wie viele Teammitglieder ausscheiden dürfen, oder 25 Siehe

dazu (GPM 2009) oder (Drews u. Hillebrand 2007).

26

3 Extreme Programming (XP)

Abb. 3.5 Beziehung zwischen User Stories, Test Cases und Code

wie John Coplien etwas zugespitzt sagt, „wie viele von einem LKW überfahren werden dürfen“ (Williams u. Kessler 2002), bevor das Projekt nicht mehr vernünftig weitergeführt werden kann. Beck schlägt deswegen den sog. Truck-Faktor vor, der von 0 bis 100% die Wahrscheinlichkeit des Scheiterns des Projekts angibt, wenn ein bestimmtes Teammitglied aus dem Projekt ausscheidet. Wenn alle Teammitglieder in jedem Bereich der Software mindestens einmal mitarbeiten, dann kann dieser Truck-Faktor reduziert werden. Damit braucht ein agiles Projekt aber Generalisten als Teammitglieder. Der Vorteil von Spezialisten, die komplexe Detailaufgaben erledigen können, kann so nicht ausgenutzt werden. Die Erfahrung im studentischen Labor des Autors zeigt, dass es Programmierer gibt, die keinerlei Interesse daran haben, die ganze Software zu kennen. Hier muss bei XP Überzeugungsarbeit geleistet werden. Generell hat der Autor aber keine guten Erfahrungen damit gemacht, Entwickler zu Ihrem „Glück“ zu zwingen.26 Es braucht hier sicher Mut, um die für das Team beste Lösung zu finden. 3.3.1.7 Stand-Up Meeting Auch für diese XP-Praxis gibt es keine überzeugende deutsche Übersetzung. Wie oft haben sich Entwickler und Ingenieure schon beschwert über endlose Sitzungen ohne nennenswertes Ergebnis. Ein guter Freund des Autors berichtete von einer Sitzung bei einem deutschen Automobilbauer, die mit einer stundenlangen Anfahrt begann und in stundenlanger Langweile endete. Fazit war ein vergeudeter Tag! Eine bewährte agile Technik dagegen (und beileibe keine Erfindung von XP) ist das „Meeting im Stehen“ (und eben nicht die „Sitzung“). Oft werden diese täglichen Meetings vor einem Kaffeeautomaten abgehalten. Ziel ist, möglichst schnell und präzise den Projektstand zu reflektieren, gefundene Probleme aufzuzeigen oder Lösungen von allgemeinem Interesse zu kommunizieren. Oft bilden sich solche Meetings auch spontan, nach der Erfahrung des Autors ist es jedoch besser, eine fixe Uhrzeit abzumachen (nicht zu früh!). Denkbar ist auch die Variante, dass pro Sitzung ein Entwickler ein „Freilos“ bekommt, das es ihm ermöglicht, wegen anderer wichtiger Aufgaben an dieser Sitzung

26 Siehe

auch Collective Code Ownership in Kap. 3.3.3.

3.3

Prozessschritte und traditionelle XP-Praktiken

27

nicht teilzunehmen. Wichtig ist aber, dass dieser Entwickler erst sein zweites Freilos erhält, wenn vorher alle anderen ebenfalls in den Genuss gekommen sind. So ist sichergestellt, dass kein Entwickler leichtfertig mit diesem Freilos umgeht. 3.3.1.8 Fix XP When It Breaks Im Sinne einer vernünftigen Prozessverbesserung muss es möglich sein, von Regeln und Praktiken Abstand zu nehmen, die sich in der Praxis nicht bewähren. So lässt auch XP diese Möglichkeit der Korrektur zu. Wichtig ist jedoch, dass eine Prozessverbesserung kein schleichender Vorgang ist. Es muss zu jedem Zeitpunkt klar sein, welche Regeln und Praktiken gelten und welche nicht mehr. Im studentischen Labor neigte das Team dazu, von einer „impliziten Prozessverbesserung“ zu sprechen. Das ist natürlich Unfug und zeigt eher die Faulheit des Teams, Änderungen am Prozess öffentlich zu machen und somit auch dem Kunden mitzuteilen. Es gehört Mut dazu, Änderungen des Prozesses durchzuführen und zu veröffentlichen. Die Frage, die man sich stellen muss, ist, ab der wievielten Änderung der „gefahrene“ Prozess nicht mehr XP ist. Der Autor wird im weiteren Verlauf zeigen, dass hier eine übergeordnete Sichtweise auf den Prozess Erfolg verspricht (Kap. 7).

3.3.2 Design der Software Zur Modellierung der Software bietet XP die nachfolgenden traditionellen Regeln und Praktiken an. Auch hier sieht man, dass die vorgeschlagenen Praktiken nicht neu sind. Es ist eher die Zusammensetzung der Regeln und Praktiken, die XP ausmacht. 3.3.2.1 Einfachheit des Designs – Implementiere Funktionalität nicht früher als nötig Insbesondere im agilen Design ist Einfachheit gefragt. Da bei agilen Projekten aus prinzipiellen Gründen zu Beginn nicht klar sein kann, wie das endgültige Design aussehen wird, macht es auch keinen Sinn, Klassen oder Schnittstellen zu designen, die nicht auch in der gleichen Iteration implementiert werden. Damit entsteht das Problem, dass die Gesamtarchitektur des Systems auch erst kurz vor Schluss des Projekts sichtbar wird. Was aber noch nicht bekannt ist, kann auch nicht designt werden. Ein XP-Design stellt immer den aktuellen Wissensstand des Teams dar. Soll z.B. für ein PC-gestütztes Messsystem neben einem TCP/IP-Bus in einer späteren Iteration auch ein aktueller Labor-Bus realisiert werden, so darf dieser im ersten Design noch nicht auftauchen. Es besteht durchaus die Wahrscheinlichkeit, dass der Labor-Bus im weiteren Verlauf des Projekts als überflüssig erachtet wird.27 Also: Funktionalität nicht früher als nötig einbauen.

27 Dies

ist jedenfalls die Erfahrung des Autors.

28

3 Extreme Programming (XP)

3.3.2.2 Systemmetapher Laut Kent Beck ist eine Systemmetapher eine „Geschichte, mit der jeder – Kunde, Programmierer, Manager – die Funktionsweise des Systems veranschaulichen kann“ (Beck 2000). Im originalen Chrysler-Projekt C3, das die Entwicklung einer Lohn- und Gehaltslisten-Software zum Ziel hatte und das erste dokumentierte XPProjekt war, war die Systemmetapher ein Bild aus der Automobilproduktion. Die Software wurde mit einer Automobilproduktionslinie verglichen, weil man davon ausging, dass alle Chrysler-Mitarbeiter mit dieser Begriffswelt vertraut waren. Die Suche nach einer Metapher gestaltet sich im Allgemeinen schwierig, so dass der Autor im studentischen Labor auf diese Praxis verzichtet. Im Rahmen des Labors wurde bisher immer der „klassische“ Ansatz der Systemarchitektur verfolgt, also die Idee, die wichtigen Zusammenhänge im Software-System darzustellen und die Details der Software zu vernachlässigen, was mit dem Begriff des Modells korrespondiert, wie er z.B. bei Balzert Verwendung findet (Balzert 2001 u. 1998). Natürlich wird auch bei diesem Ansatz eine Metapher verwendet, indem die Modellierung der Software mit der Modellierung eines Hauses verglichen wird – dies steckt bereits in der Verwendung des Begriffs Architektur! 3.3.2.3 CRC-Karten Class, Responsibilities and Collaboration (CRC) Cards sind ein äußerst praktisches Design-Werkzeug. Ganz schlicht in der Form wird pro Klasse in maximal vier Halbsätzen dargestellt, was die Klasse leisten soll bzw. mit welcher anderen Klasse sie dazu in Wechselwirkung stehen muss.28 So kann pro Iteration ein Satz von korrespondierenden Klassen gebildet und in Form von Karteikarten verwaltet werden. Wenn man diese Karteikarten auf einer Pinwand anordnet und durch Assoziationen verbindet, entsteht ein erstes UML-Diagramm.29 Zu erwähnen ist noch, dass die UML-Klassen in der nicht-objektorientierten Welt durchaus auch Datenbanktabellen oder, ganz allgemein, Software-Module sein können (Abb. 3.6).

3.3.2.4 Risikominimierung durch „Spike Solutions“ Eine Spike Solution lässt sich am besten als prototypenhafte Implementierung der Lösung eines aufgetauchten (technischen) Problems bezeichnen. Mit diesem „Durchstich“ wird die Lösbarkeit bewiesen. Meist taugt jedoch dieser Prototyp nicht als Komponente der endgültigen Software. Es ist meist besser, den „quick and dirty“ entwickelten Code wieder wegzuwerfen. Es gehört allerdings Mut dazu, funktionierenden Code allein aufgrund eines mangelhaften Designs aufzugeben. Die Erfahrung zeigt jedoch, dass es sich rächt, schlecht designten Code weiter zu nutzen. 28 z.B.

durch Aufruf einer entsprechenden Methode. Modeling Language, ein sehr gutes Buch dazu ist (Fowler u. Scott 2000).

29 Unified

3.3

Prozessschritte und traditionelle XP-Praktiken

29

Abb. 3.6 CRC-Karte aus einer eMail-Versand-Software

3.3.2.5 Refactoring Refactoring lässt sich am besten mit Umstrukturierung des Designs oder des Codes übersetzen (Fowler u. Scott 2000). Dahinter steckt das Problem der SoftwareEntropie: Entwickelt man nur lange genug, wird aus jedem noch so guten Design ein schlechtes Design. Bleiben wir beim Beispiel des Messsystems: Nachdem eine TCP/IP-Schnittstelle implementiert wurde, wird unabhängig davon (zu einem späteren Zeitpunkt) ein Labor-Bus hinzugefügt.30 Angenommen, diese verschiedenen Schnittstellen werden jeweils durch eine Klasse repräsentiert, wird spätestens jetzt klar, dass ein optimales Design ein Interface, also eine „Schnittstelle“ beinhalten sollte, von dem die o.g. Klassen abgeleitet werden. Das (wild) gewachsene System der zwei unabhängigen Schnittstellen-Klassen wird durch das saubere Design Interface vererbt an Klassen ersetzt. Dieser Ansatz hat aber auch einen weiteren Vorteil. Sollte sich in einer späteren User Story die Implementierung einer weiteren Bus-Schnittstelle, z.B. Profibus, als notwendig erweisen, kann der Entwickler die entsprechende Klasse vom Interface „Schnittstelle“ ableiten. Refactoring macht das Design besser und reduziert damit auf Dauer die Fehlerrate bei den Testfällen. Martin Fowler fordert sogar, 10% des Codes pro Iteration neu zu strukturieren (Fowler u. Scott 2000). Vergleicht man mit der Praxis des studentischen Labors, scheint dem Autor dieser Wert allerdings zu hoch gegriffen. Über die Jahre hinweg kann es aber in einem studentischen Projekt durchaus passieren, dass mehr als die Hälfte des Codes nochmals angepasst wird. Leider funktioniert Refactoring ohne die entsprechende WerkzeugUnterstützung nicht vernünftig. Mit Hilfe eines guten Model Driven Development-Tools (MDD) reduziert sich eine Design-Änderung nach der Erfahrung des Autors auf wenige Maus-Klicks. Deshalb fordert Refactoring in 30 z.B.

IEEE-488 / IEC-625.

30

3 Extreme Programming (XP)

einem agilen Projekt fast zwangsweise den Einsatz von Computer Aided Software Engineering (CASE). Ansonsten wird nur die systemweite Namensänderung einer Variablen zu einem fast ausweglosen Unterfangen.31 Zum Refactoring gehört Mut! Mut, lauffähige Software aus „ästhetischen Gründen“ umzuschreiben. Dies beginnt mit Variablen-Namen und endet mit den o.g. Design-Anpassungen. Allerdings verbessert ein klares Design auf die Dauer die Resultate der Software-Tests (Fowler u. Scott 2000).

3.3.3 Kodieren Die traditionellen Regeln und Praktiken, die XP in der Kodierungsphase zu Verfügung stellt, sind zum Teil neu und wenigstens teilweise nicht unumstritten. 3.3.3.1 Der Kunde ist immer verfügbar XP fordert die permanente Mitgliedschaft des Kunden im Team. Dies soll eine schnelle Reaktion auf sich ändernde Kundenwünsche ermöglichen, selbst in späten Projektphasen. Spezifikationsdetails können „face to face“ mit dem Kunden besprochen werden. Die geforderte dauernde Anwesenheit des Kunden im Projekt ist in der Praxis naturgemäß ein Problem, da erfahrene Kunden kaum vollständig einem Software-Projekt zur Verfügung stehen. Die Praxis zeigt jedoch einen Mittelweg auf: Der Autor hat gute Erfahrungen mit einem „roten Telefon“ gemacht, welches den Kunden mit dem Team verbindet. Dies kann z.B. ein Prepaid-Handy o.Ä. sein, dessen Nummer idealerweise nur dem Entwicklerteam bekannt ist. Wenn dieses Handy klingelt, setzt ein zweistufiger Mechanismus ein: Der Kunde meldet sich möglichst direkt, spätestens innerhalb von einer Stunde, um den Anruf entgegenzunehmen. Innerhalb eines Arbeitstags gibt er die endgültige Antwort. Diese Zeitspannen reichen üblicherweise sowohl den Entwicklern als auch dem Kunden aus. Die Entwickler können normalerweise einen Tag Antwortzeit überbrücken, der Kunde kann innerhalb eines Tags in der Regel eine qualifizierte Antwort geben. Ein anderer Einwand gegen die ständige Präsenz des Kunden ist, dass er auf diese Weise zu viele Interna des Projekts (auch gemachte Fehler) mitbekommen könnte. Würde dadurch nicht sein Vertrauen in die Qualität der Entwickler-Mannschaft sinken? Und wird dadurch die Projekt-Kommunikation insbesondere mit dem Kunden wirklich besser? Die Praxis zeigt, dass der Kunde es dem Team in aller Regel dankt, wenn er integriert wird und auch an den Entscheidungsprozessen beteiligt wird. Sein Vertrauen in das Team wächst! Allerdings ist die Kommunikation zwischen Team und Kunde kein Selbstläufer. Der Autor, der im studentischen Labor

31 Man

stelle sich auch noch vor, die Variable heiße i.

3.3

Prozessschritte und traditionelle XP-Praktiken

31

Abb. 3.7 Kunde bemüht sich um Kommunikation im studentischen Labor

immer die Rolle des Kunden inne hat, musste sich in der Vergangenheit immer wieder Gehör verschaffen bzw. das Team aktiv auffordern, mit ihm zu kommunizieren (Abb. 3.7). 3.3.3.2 Kodierungsstandards Coding guidelines sind aus der modernen Software-Entwicklung nicht mehr wegzudenken. Es gibt keinen Grund, auf sie zu verzichten. Sie vereinheitlichen den Code und ermöglichen dem Teammitglied, den Code der anderen leicht zu verstehen. Im studentischen Labor „überleben“ solche Guidelines an der Wand über Jahre (Abb. 3.8). Von drei Nachfolgeteams hatte keines das Bedürfnis, die Richtlinien des studentischen Teams aus dem Jahr 2005 zu verändern oder anzupassen. Kodierungsstandards sind die Grundlage für ein erfolgreiches Refactoring. 3.3.3.3 Unit Test zuerst programmieren “Test first!“ ist ein wichtiger Grundsatz des XP (Beck u. Andres 2004). Wenn man Modultests (Unit tests) am Anfang einer Iteration schreibt, kann man damit die betrachtete User Story präzisieren. Zur Erinnerung: User Stories bestehen in der Regel aus maximal drei Halbsätzen und haben nicht ansatzweise den Informationsgehalt einer klassischen Spezifikation. Zusammen mit dem Kunden wird bei der Implementierung der User Story eine Minispezifikation geschaffen,

32

3 Extreme Programming (XP)

Abb. 3.8 Coding Guidelines aus dem Jahr 2005

welche allerdings nirgends detailliert niedergeschrieben wird. Im studentischen Labor findet man im Wiki32 lediglich Ausschnitte der Detailspezifikation und des Feindesigns. Es fällt deutlich leichter, die Entwickler zu motivieren parallel zur (nicht schriftlich niedergelegten) Minispezifikation Testfälle zu generieren, die das Erreichen des spezifizierten Ziels dokumentieren sollen. Diese können auch problemlos mit dem Kunden abgestimmt werden und ersetzen so die schriftliche Detailspezifikation (Abb. 3.9). Naturgemäß befinden sich diese Testfälle auf dem Niveau des Software-Moduls (also auf der Ebene der Software-Units). Übergeordnete Systemtests, in denen auch das Umfeld der Software getestet werden kann,33 sind dabei ausgeklammert, bzw. auf der Zeitachse nach hinten verschoben (Kap. 3.3.4). 3.3.3.4 Pair Programming Die Idee der Programmierung in Paaren besagt, dass der ganze Code des SoftwareProjekts von Gruppen – der Autor nennt diese Gruppen auch Mini-Teams – bestehend aus zwei Entwicklern, programmiert werden soll. Dabei teilen sich die 32 Ein Wiki (Wiki Web) ist eine im World Wide Web verfügbare Seitensammlung, die von den Be-

nutzern nicht nur gelesen, sondern auch online geändert werden kann. Wikis ähneln damit einfach zu bedienenden Content Management Systemen, siehe http://de.wikipedia.org/wiki/Wiki 33 Performance-Tests, Stresstests usw.

3.3

Prozessschritte und traditionelle XP-Praktiken

33

Abb. 3.9 Detail-Spezifikationen des V-Modells werden durch Unit-Tests ersetzt

beiden Entwickler einen Computer (Abb. 3.10). Periodisch wechselnd schieben sie die Tastatur hin und her. Der eine denkt taktisch, er implementiert z.B. die Methode einer Klasse, während der andere daneben sitzt und strategisch denkt: Braucht man diese Klasse überhaupt, oder sollte sie abgeändert werden? Beck behauptet, dass das Programmieren in Paaren die Qualität des erzeugten Codes erhöht, was dem Projekt sicherlich nützt. Interessant ist aber, dass er ebenfalls (ohne einen dem Autor bekannten Beweis) behauptet, dass das Paar genauso schnell entwickelt wie zwei unabhängige Entwickler an zwei verschiedenen Rechnern. Dies deckt sich nicht mit den Erfahrungen des Autors im studentischen Labor. In Low-Level-Implementierungen auf Detailniveau ist es eher so, dass der Spezialist programmiert und der Partner zuschaut. Solange es aber um Design-Entscheidungen geht, macht das Arbeiten in Mini-Teams Sinn. In Kap. 3.3 wird der Frage nachgegangen, ob diese Mini-Teams sinnvollerweise aus zwei Mitgliedern bestehen müssen.

34

3 Extreme Programming (XP)

Abb. 3.10 Ein XP-Paar im studentischen Labor

3.3.3.5 Code-Integration durch Paare – Integriere oft! XP fordert, dass die Paare ihren Code selbst integrieren. Allerdings darf dies nur durch jeweils ein Paar geschehen. Dieses Paar hält ein Token, was es nur ihm ermöglicht zu integrieren. Dieses Token kann z.B. ein freier Integrationsrechner sein. Die Idee dahinter ist, dass ein Paar seinen neu entwickelten Code am besten kennt und deshalb auftauchende Integrationsprobleme am besten lösen kann. Problematisch wird es, wenn das Paar für die Integration des eigenen Codes Änderungen am Code anderer Paare durchführen muss. Aufgrund der nachfolgenden Regel Collective Code Ownership geht XP davon aus, dass zumindest ein Grundverständnis des Codes anderer Paare vorhanden ist. Und durch die vorhandenen Testfälle ist es leicht, herauszufinden, ob die Änderung am „fremden“ Code Fehler produziert oder nicht. Durch diese Praxis der sequentiellen Integration durch die Paare wird verhindert, dass abwesende oder verhinderte Teammitglieder zum Engpass für den Projektfortschritt werden. Den Einsatz von Integratoren oder Integrationsteams lehnt Kent Beck explizit ab. Dies würde ebenfalls die Projektgeschwindigkeit reduzieren (Wells 2009). Dies entspricht in keinster Weise der Erfahrung des Autors im studentischen Labor oder in der Praxis! Die Wahrheit ist, dass sich alle MiniTeams, auch Paare, vor der Integration zu „drücken“ versuchen. Kein Mini-Team von Entwicklern ist erpicht darauf, in „fremdem“ Code Änderungen durchzuführen. Der Autor machte als Kunde des studentischen Labor-Teams die Erfahrung, dass

3.3

Prozessschritte und traditionelle XP-Praktiken

35

jedes Mini-Team voller Stolz seine realisierte User-Story vorführte, aber immer nur auf dem eigenen Rechner.34 Beck fordert eine kontinuierliche Code-Integration (Continuous Code Integration). „Integriere oft!“ ist sein Leitspruch. Dabei strebt er Integrationszyklen unter einem Tag an. Dieses ehrgeizige Ziel ist ohne automatisierte Tests niemals zu erreichen. 3.3.3.6 Collective Code Ownership Dem Team als Ganzem gehört der Code! Damit ist in XP das Team auch gleichzeitig der Chefarchitekt. Alle Teammitglieder können so ihren Beitrag zu einer guten Software-Architektur leisten. Sicherlich weiß das Team als Ganzes mehr als ein einzelner Architekt. Gute Ideen gehen nicht mehr unter. Keiner wird mehr zum Engpass für eine schnelle und effiziente Software-Entwicklung. Funktionieren kann diese Regel nur, wenn vor der Architektur die Ausarbeitung der Unit Tests steht. Nachdem die Paare sich pro Release „ihre“ User Stories gewählt haben, müssen sie Unit Tests schreiben, die die korrekte Funktionalität der User Story beweisen. Damit kann jedes Paar Änderungen am Code anderer Paare durchführen, ohne Gefahr zu laufen, unbewusst Fehler in den Code einzubauen. Wenn der originale Unit Test des anderen Paars immer noch fehlerfrei läuft, gilt die Änderung als erfolgreich. Die Anwendung dieser Regel erfordert Mut! Die Praxis im studentischen Labor zeigt, wie schon früher erwähnt, dass Entwickler üblicherweise wenig Interesse zeigen, „fremden Code“ zu verändern. Man stößt oft auf regelrechtes Desinteresse daran. Von einem Team von ca. 20 Personen war nie mehr als ein Drittel am Gesamtcode interessiert. Auch diese Regel wird in Kap. 6 hinterfragt werden. 3.3.3.7 Optimiere erst zum Schluss Dies ist keine spezielle XP-Regel. Auch im Unified Process findet Optimierung erst in der Transition-Phase statt (Jacobsen et al. 1999). Beim Optimieren wird der Debug-Code eliminiert, der während der Entwicklung wertvolle Hinweise auf Programmierfehler gibt. Außerdem kann erst ganz zum Schluss klar sein, wo Performance-Engpässe im System entstehen. Diese sollten dann gezielt angegangen werden. Nur der Verdacht auf einen möglichen Engpass reicht nicht aus. 3.3.3.8 Keine Überstunden Wie der Autor aus eigener Erfahrung weiß, zerstören anhaltende Überstunden die Motivation des Teams. Wenn man täglich zehn Stunden arbeitet und mehrere Wochen die Wochenenden opfert, ist nach maximal einem Monat „die Luft raus“. Das Team will nicht mehr, die Arbeitsleistung nimmt ab. Wie man schon in der 34 In

Kap. 6 soll diese Problematik näher beleuchtet werden.

36

3 Extreme Programming (XP)

Projektmanagement-Vorlesung lernt, kann man am Tag kaum mehr als 6,5 Stunden produktiv am Projekt arbeiten. Die restliche Zeit wird für andere Dinge gebraucht.35

3.3.4 Testen der Software Wie schon in Kap. 3.3.3 klar wird, durchzieht das Testen der Software den ganzen Entwicklungsprozess. Durch das Prinzip Test first! wird das Schreiben von Unit Tests sogar an den Anfang der Implementierung einer User Story gestellt. Trotzdem gibt es Tests, die naturgemäß am Ende der Implementierung einer Release stehen, die Akzeptanztests. 3.3.4.1 Unit Tests für den gesamten Code! Wenn ein Fehler gefunden wird, muss ein Test generiert werden! Alle Unit Tests müssen vor der Release erfolgreich sein! In diesen Regeln wird nochmals explizit die Wichtigkeit von Unit Tests herausgestellt. Wie schon in Kap. 3.3.3 dargestellt, können am Anfang einer Iteration geschriebene Unit Tests die betrachteten User Stories präzisieren. Testfälle können problemlos mit dem Kunden abgestimmt werden und damit „klassische“ schriftliche Detailspezifikation ersetzen (Abb. 3.9). Unit Tests befinden sich auf dem Niveau des Software-Moduls (Software-Unit). Wenn aber während der Tests oder im laufenden Betrieb Fehler gefunden werden, muss zum Fehler ein Test generiert werden. Man darf davon ausgehen, dass dieser Test noch nicht bestand, weil sonst der Fehler entdeckt worden wäre.36 Alle Unit Tests müssen vor einer Release erfolgreich durchgeführt sein. 3.3.4.2 Akzeptanztests Bei allen Überlegungen zu Software-Tests wurde bisher ausgeklammert, dass gewisse Fehler, z.B. bezüglich Performance, Internet-Anbindung oder allgemeiner Belastung des Systems, nicht in Unit Tests gefunden werden können. Das ausgelieferte System besteht am Ende aus Software und Hardware. Und dieses Komplettsystem muss auch getestet werden. Auch die Akzeptanztests resultieren aus den User Stories. Der Unterschied zu den Unit Tests ist, dass die Akzeptanztests nicht mehr eindeutig einem Software-Modul zugeordnet werden können (und sollen). Mit Hilfe der Akzeptanztests kann der Kunde „seine“ User Stories testen, sie ersetzen die (in der Regel nicht sauber niedergeschriebenen) High-LevelSpezifikationen des Systems (Abb. 3.11). Akzeptanztests sind Black Box Tests. Zu ihrer Durchführung muss der Code nicht vorliegen. Hier setzt auch die Qualitätssicherung an, die zwar ansonsten bei XP nicht explizit in Erscheinung tritt, die aber nach Erfahrung des Autors in einem agilen Projekt unabdingbar ist. 35 Abfragen

von E-Mails, Verwaltungsaufgaben usw. bei Unit Tests ist das richtig.

36 Zumindest

3.4

Erweiterte XP-Praktiken

37

Abb. 3.11 High-Level-Spezifikationen des V-Modells werden durch Akzeptanz-Tests ersetzt

Auch Akzeptanztests sollten in XP möglichst automatisiert werden (Wells 2009). Dies ist aber aller Erfahrung nach weitaus schwerer als die Automatisierung der Unit Tests. Im studentischen Labor ist das den Teams in fünf Jahren bisher noch nicht gelungen. Es ist sinnvoll ein Score für diese Tests einzuführen, so dass das Entwicklerteam (und jeder andere) jederzeit den Stand der Tests sieht. Sinnvoll erachtet der Autor auch ein System aus Ampeln, die visuell (rot und grün) den Erfolg der wichtigsten Tests z.B. auf einer Intranet-Seite anzeigen.

3.4 Erweiterte XP-Praktiken Die bisher beschriebenen „traditionellen“ XP-Praktiken wurden bereits 2000 von Kent Beck vorgeschlagen (Beck 2000) und haben noch immer ihre Berechtigung.

38

3 Extreme Programming (XP)

Sie werden auch heute noch gepflegt und in Projekten angewandt (Wells 2009). Trotzdem hat Kent Beck die traditionellen XP-Praktiken in seinem neueren Buch (Beck u. Andres 2004) durch einen neuen Satz von 13 Primärpraktiken und 11 Folgepraktiken ersetzt. Dies wird mit der Weiterentwicklung von XP und der wachsenden Erfahrung mit diesem agilen Prozessmodell begründet. Der Unterschied zwischen den traditionellen und den in diesem Kapitel beschriebenen „erweiterten“ XP-Praktiken ist allerdings nicht so groß, wie er auf den ersten Blick erscheint. XP bleibt sich treu!

3.4.1 Primärpraktiken Die von Kent Beck 2004 neu definierten 13 Primärpraktiken (Beck u. Andres 2004) sind: • • • • • • • • • • • • •

Team sitzt räumlich zusammen Komplettes Team Informative Arbeitsumgebung Energized Work Pair Programming Stories Wöchentlicher Zyklus Vierteljährlicher Zyklus Freiraum Ten-Minute Build Continuous Code Integration Test First Entwicklung Inkrementelles Design

Einige der Primärpraktiken sind bereits als traditionelle Praktiken bekannt und brauchen nicht noch einmal beschrieben werden. Dies sind User Stories (Kap. 3.3.1) und Inkrementelles Design (Kap. 3.3.2) sowie Pair Programming, Continuous Code Integration und Test First Entwicklung (Kap. 3.3.3). Interessant sind die „neuen“ XP-Praktiken: 3.4.1.1 Team sitzt räumlich zusammen Diese Primärpraxis ist nicht wirklich neu. Schon die geforderte paarweise Arbeit (mit wechselnder Besetzung) verlangt eine räumliche Nähe des Teams. Neu ist, dass XP diese agile Selbstverständlichkeit explizit fordert. 3.4.1.2 Komplettes Team Das Team muss alle Fähigkeiten vereinen, die zur Erfüllung der gestellten Aufgabe notwendig sind. Dieser wichtige Aspekt soll in Kap. 7 ausführlich behandelt werden.

3.4

Erweiterte XP-Praktiken

39

3.4.1.3 Informative Arbeitsumgebung, Energized Work, Freiraum Die Arbeitsumgebung soll den Bedürfnissen des Teams angepasst sein, aber auch den aktuellen Stand des Projekts widerspiegeln. Es ist z.B. sinnvoll, die User Story Cards so auf Pinwänden anzuordnen, dass sofort klar wird, wie viele davon erledigt und wie viele noch offen sind (Abb. 3.12). Innerhalb weniger Sekunden kann sich jeder Besucher vom Stand des Projekts überzeugen. Eine gute und angepasste Arbeitsumgebung „beflügelt“ das Team und befähigt es zu „Energized Work“, also zu einer engagierten Arbeit voller Energie. Nur so kann das Team Außergewöhnliches leisten. Ebenso wichtig ist auch der Freiraum der einzelnen Teammitglieder. Sie sollten auch eigene Aktivitäten entwickeln können, sich also in einem (begrenzten) Teil ihrer Zeit mit Dingen beschäftigen, die sie interessieren (und die in aller Regel mit ihrem Thema im Projekt zu tun haben). Das Team profitiert von den neu gewonnenen Ideen. 3.4.1.4 Ten-Minute Build Neu ist eine klare Aussage Kent Becks zu den Zeitskalen im Projekt. Er weist daraufhin, dass ein Build des Software-Systems inklusive aller automatisierten Tests nicht länger als zehn Minuten dauern sollte. Dies ist eine vernünftige Größe, weil ein längeres Warten dazu führt, dass die Zahl der Builds reduziert wird. Der Autor

Abb. 3.12 Die Anordnung der User Story Cards zeigt den aktuellen Stand des Projekt (2009)

40

3 Extreme Programming (XP)

arbeitete in den 1980er Jahren in einem Projekt, bei dem ein Build über eine Stunde lief. Das Resultat waren Builds in Abständen von jeweils einigen Tagen mit der Gefahr von Schnittstellenproblemen zwischen den separat implementierten User Stories. Ausgelöst durch den Preisverfall leistungsfähiger Hardware, lässt sich diese Problematik heutzutage leicht in den Griff bekommen. 3.4.1.5 Wöchentlicher Zyklus Die zweite Zeitskala, die XP vorgibt, bezieht sich auf die Länge der Iterationen. Kent Beck schlägt im Gegensatz zu den traditionellen Praktiken (Kap. 3.2) eine kürzere Zeitskala vor. Spricht er anfangs von zwei bis drei Wochen, bevorzugt er nunmehr eine Woche, weil sich damit alles auf Freitag fokusiert. Freitag ist das Ende eines Arbeitsabschnitts. Es liegt somit nahe, Iterationen auf eine Woche hin zu planen.37 Man beginnt die Woche planend, schreibt darauf die automatisierten Tests und verbringt den Rest der Woche damit, den Code so zu implementieren, dass die zuvor geschriebenen Tests erfüllt werden. 3.4.1.6 Vierteljährlicher Zyklus Die nächstgrößere, vorgegebene Zeiteinheit ist das Vierteljahr. In Analogie zur (natürlichen) Länge einer Jahreszeit können größere Einheiten der Software implementiert werden. Es bietet sich an, vierteljährliche Releases durchzuplanen und durchzuführen.38 Auch Reflexionssitzungen finden in XP einmal im Vierteljahr statt. Wichtig ist, nicht nur Probleme zu benennen, sondern auch Lösungen anzustoßen, also das „Big Picture“ des Projekts nicht aus den Augen zu verlieren. Um es noch einmal ganz deutlich zu machen: Die Aussage zu den Zeitskalen ist neu und in den ersten Ansätzen zu XP noch nicht in dieser Deutlichkeit zu finden.39

3.4.2 Folgepraktiken XP kennt 11 Folgepraktiken, die allerdings erst zum Einsatz kommen sollen, wenn das Team die Primärpraktiken beherrscht: • • • • •

Einbeziehung des Kunden Inkrementelle Lieferung Teamkontinuität Teams können schrumpfen Ursachenanalyse

37 Obwohl

Beck das im entsprechenden Kapitel nicht explizit verlangt (Beck u. Andres 2004). Beck auch das nicht explizit verlangt (Beck u. Andres 2004). 39 Vergleiche dazu (Beck 2000) und (Beck u. Andres 2004). 38 Obwohl

3.4

• • • • •

Erweiterte XP-Praktiken

41

Shared Code Eine Codebasis Tägliche Lieferung Vertrag mit verhandelbarem Umfang Pay-Per-Use

Auch einige der Primärpraktiken sind bereits als traditionelle Praktiken bekannt. Die Einbeziehung des Kunden ins Team40 war von Anfang an eine Forderung von Kent Beck. Ebenso wichtig war immer eine inkrementelle Lieferung kleiner Releases.41 Shared Code korrespondiert mit der traditionellen Praxis Collective Code Ownership (Kap. 3.3.3). Neu ist die explizite Erwähnung der nachfolgenden Folgepraktiken: 3.4.2.1 Teamkontinuität Effektive Teams sollten, soweit es geht, zusammengehalten werden, denn ein Team ist mehr als die Summe der einzelnen Teammitglieder. Ein gutes „Klima“ in einem Team führt dazu, dass sich die einzelnen Teammitglieder wohlfühlen und damit ihre optimale Leistung abrufen können. Das Problem, dass Teams auseinandergerissen werden, besteht hauptsächlich in großen Entwicklungsorganisationen. 3.4.2.2 Teams können schrumpfen Mit der Zeit wachsen die Fähigkeiten eines Projektteams und damit die Bearbeitungsgeschwindigkeit der definierten User Stories. In einem solchen Fall ist es sinnvoller, den „Workload“ konstant zu halten und die Teamgröße zu verkleinern.42 3.4.2.3 Ursachenanalyse Wenn ein Bug die Entwicklung unentdeckt überstanden hat, muss nach den Ursachen geforscht werden. Zuerst sollte auf System-Ebene ein (idealerweise automatisierter) Test entwickelt werden, der den Fehler zeigt. Danach sollte auf Modul-Ebene der korrespondierende Test-Case implementiert werden.43 Ist der Fehler dann behoben, sollte nach den Ursachen geforscht werden, warum der Fehler nicht entdeckt wurde. War die Person, die den Fehler hätte finden können, nicht Mitglied des Teams? Diese und ähnliche Ursachen müssen anschließend geklärt werden.

40 „Der

Kunde ist immer verfügbar“ (Kap. 3.3.3). Releases“ (Kap. 3.3.1) und „Integriere oft!“(Kap. 3.3.3) 42 Im Rahmen der studentischen Projekte hat der Autor diese Möglichkeit allerdings nicht. Die Teamgröße ist definiert durch die Kursgröße. 43 Dies wird allerdings nur bei funktionalen Fehlern möglich sein. Performance-Probleme sind in der Regel auf Modulebene nur schwer zu identifizieren. 41 „Kleine

42

3 Extreme Programming (XP)

3.4.2.4 Eine Codebasis, tägliche Lieferung Das Team und das Projekt haben immer eine aktuelle Codebasis. Natürlich wird jedes XP-Paar eine User Story zuerst lokal implementieren. Spätestens aber nach ein paar Stunden sollte der Code mit den anderen wieder synchronisiert werden. Ansonsten wird der Aufwand der Code-Integration zu groß.44 Aus demselben Grund ist vorzusehen, dass jede Nacht ein neuer Build der Software generiert wird. Nur eine ständige Synchronisation der Arbeit eines Programmierers mit dem „Produktionscode“, verhindert Integrationsrisiken. 3.4.2.5 Vertrag mit verhandelbarem Umfang In Software-Entwicklungsverträgen sollten Zeitaufwand, Kosten und Qualität definiert sein. Der genaue Funktionsumfang sollte aber kontinuierlich angepasst werden können. Soviel Freiraum sollte der Vertrag vorsehen. Es entspricht dem agilen Gedanken, dass Spezifikationen in Form von User Stories mit der Zeit entwickelt werden. Diese Praxis ist also eine direkte Folge des agilen Ansatzes. Nichtsdestotrotz haben Auftraggeber große Mühe mit der Realisierung eines solchen Freiraums in Verträgen. 3.4.2.6 Pay-Per-Use Pay-Per-Use bedeutet, dass der Kunde nur bezahlt, wenn er die Software nutzt. Bei jeder Nutzung der Software entstehen somit angemessene Gebühren. Über die Nutzungsrate der Software entsteht letztlich eine Aussage über die Kundenzufriedenheit. Diese kann vom Entwicklungsteam bei der Weiterentwicklung berücksichtigt werden. Je näher das Produkt an den Bedürfnissen des Kunden ist, umso höher ist die Nutzung und sind somit die Gebühren, die der Kunde bereit ist zu zahlen.45 Problematisch ist dieser Ansatz allerdings bei speziellen Kundenentwicklungen. Hier erwartet der Kunde mit Recht Kostensicherheit, während das Entwicklungsteam seine Kosten gedeckt sehen will. (Vielleicht sollte man Pay-Per-Use auch nur im übertragenen Sinn verstehen!)

3.4.3 Unterschiede zwischen erweiterten und traditionellen XP-Praktiken Seit seinem ersten Buch (Beck 2000) hat Kent Beck einige der traditionellen Rules and Practices aus der Liste der XP-Praktiken herausgenommen. Es sind dies hauptsächlich nicht XP-spezifische Praktiken wie

44 Siehe

dazu auch Kap. 6.4. Ansatz ist auch als Application Service Providing (ASP) bekannt.

45 Dieser

3.5

• • • • • • •

Berühmte XP-Praktiken

43

das Messen der Projektgeschwindigkeit Stand Up Meetings der Einsatz von CRC-Karten das Implementieren von Prototypen (Spike Solutions) Refactoring einer Software Optimieren am Schluss keine Überstunden

Diese Praktiken gehören heutzutage zum „Good Engineering“ und werden von der Mehrzahl der Entwickler nicht mehr als XP-spezifisch angesehen. Andere traditionelle Praktiken haben sich (meist nur leicht) gewandelt oder werden nicht mehr explizit erwähnt: • Das Planungsspiel (Kap. 3.3.1) weicht dem Vertrag mit verhandelbarem Umfang. • Die Iterationsplanung mit kleinen Releases (Kap. 3.3.1) wird präzisiert zum wöchentlichen Zyklus. Beck reduziert die ursprünglich zwei- bis dreiwöchigen Iterationen auf eine Woche, um das Team auf Freitag als Abgabetag zu fokusieren. • Move People around (Kap. 3.3.1) muss nicht mehr separat erwähnt werden. Diese Praxis dient der Verbreitung des Wissens um den Code im Team. Pair Programming und Teamkontinuität bewirken letztlich dasselbe. • Die Regel Fix XP when it breaks findet man in den erweiterten XP-Praktiken nicht mehr. Das Heikle an dieser Regel ist festzustellen, ab wann der Prozess kein XP mehr ist.46 • Interessant ist das Verschwinden der Forderung nach einer Systemmetapher (Kap. 3.3.2). Aus dem studentischen Labor ist bekannt, dass sich die Suche nach einer Metapher im Allgemeinen als schwierig erweist. Aus diesem Grund wird dort auf diese Praxis verzichtet. Es ist davon auszugehen, dass diese generelle Schwierigkeit Kent Beck bewogen hat, auf diese Praxis zu verzichten.

3.5 Berühmte XP-Praktiken Wie schon erwähnt, sind viele der XP-Regeln und -Praktiken nicht neu. Es ist eher ihre Kombination und ihre strikte Einhaltung, was XP ausmacht. Man kann die XP-Praktiken durchaus in zwei Kategorien einteilen: Regeln, die jeder moderne Projektmanager sofort akzeptiert und meist auch schon einsetzt, und Regeln, die Widerspruch hervorrufen:

46 Hier

sei auf Kap. 6 und 7 verwiesen.

44

3 Extreme Programming (XP)

Kein erfahrener und zeitgemäßer Projektleiter bezweifelt die Wichtigkeit einer vernünftigen Versions- und Release-Planung, kleiner Releases, einer iterativinkrementellen Vorgehensweise und eines einfachen Designs mit Namenskonventionen. Ebenso gehört heutzutage ein ausführliches und automatisiertes Testen „ab dem ersten Tag“ bereits auf Modul-Ebene zu den modernen SoftwareProjekttechniken. Die andere Gruppe der XP-Regeln und -Praktiken gibt mehr Anlass zu Diskussionen, wie der Autor aus eigener Erfahrung weiß und im studentischen Labor verifizieren konnte. Diese Regeln und Praktiken, die XP berühmt gemacht haben, werden im studentischen Labor (Kap. 6) auf ihre Praxistauglichkeit überprüft:

3.5.1 Erstellen von User Stories Die Anforderungen sollen nicht in Form von Dokumenten, sondern in Form von kurzen, dreisätzigen Mini-Spezifikationen vom Kunden in seiner „Sprache“ abgefasst werden. Der Aufwand für die Implementierung des zugehörigen Software-Moduls soll drei Wochen nicht überschreiten. Kann der Kunde das? Wie kann er drei Wochen Aufwand abschätzen? Macht eine solche zeitlich feine Gliederung überhaupt Sinn? Braucht er Unterstützung? (Und wenn ja, von wem?)

3.5.2 Paarweises Programmieren Zwei Programmierer arbeiten zusammen an einem Computer. Beck verspricht eine Erhöhung der Software-Qualität bei gleicher Effizienz wie bei einem Team von zwei Programmierern an zwei Computern. Im Paar soll ein Programmierer taktisch denken, sich also mit dem Funktionsumfang einer aktuellen Klassenmethode beschäftigen, während der andere strategisch denkt, sich also mit der Frage beschäftigt, ob obige Klassenmethode überhaupt in diese Klasse passt. Die Programmierer wechseln regelmäßig, ggf. alle paar Stunden, ihre Rollen. Diese Forderung wird wohl in den wenigsten Projekten erfüllt. Die Frage nach dem Sinn dieser XP-Regel soll im Weiteren untersucht werden.

3.5.3 Collective Code Ownership, Shared Code Jedes Team-Mitglied soll Verantwortung für den gesamten Code tragen und diesen auch entsprechend verstehen. Jeder, der eine Änderung am Code eines anderen Paares braucht, kann diese selbstständig durchführen, da das automatisierte Testen mit einer entsprechenden Versionskontrolle es ermöglicht, den „Urzustand“ der Software vor der Änderung wieder herbeizuführen. Dieser Punkt ist heikel! Jeder der schon einmal mit entsprechenden Tools gearbeitet hat, weiß, dass man hierzu ein tiefes Verständnis der zu ändernden Software haben oder die Bereitschaft zum

Literatur

45

Erlangen dieses Verständnisses mitbringen muss. Auch diese Regel soll untersucht werden.

3.5.4 Kontinuierliche Code-Integration, eine Codebasis Integration in kurzen Abständen, idealerweise kontinuierlich, dient dem Zweck, immer eine aktuelle Codebasis zu haben. Die Integration des Codes wird von den XP-Paaren geleistet, die eigenverantwortlich nacheinander an einem Integrationsrechner die Projektmodule zu einem lauffähigen Release verknüpfen. Hier muss die Frage geklärt werden, ob alle Paare genügend Willen und Know-how mitbringen, um eine in der Regel komplexe Integration erfolgreich durchzuführen.

3.5.5 Kunde im Team, Einbeziehung des Kunden Beck fordert die permanente Mitgliedschaft des Kunden im Team (zumindest in den traditionellen Praktiken und in den erweiterten Praktiken/Folgepraktiken). Dies soll eine schnelle Reaktion auf sich ändernde Kundenwünsche ermöglichen, selbst in späten Projektphasen. Spezifikationsdetails können „face to face“ mit dem Kunden besprochen werden. Die geforderte dauernde Anwesenheit des Kunden im Projekt ist in der Praxis naturgemäß ein Problem, da erfahrene Kunden kaum vollständig einem Software-Projekt zur Verfügung stehen. Ein anderer Einwand ist, dass der Kunde auf diese Weise zu viele Interna des Projekts mitbekommen könnte. Und wird dadurch die Projekt-Kommunikation insbesondere mit dem Kunden wirklich besser? Ein Indiz der Problematik dieser Praxis ist, dass Kent Beck sie in seinen erweiterten Praktiken in die Folgepraktiken für erfahrene Teams einordnet. Die hier diskutierten XP-Praktiken wurden intensiv im studentischen Labor untersucht und werden im Kap. 6 intensiv diskutiert.

Literatur Balzert H (2001 u. 1998) Lehrbuch der Software-Technik. Band 1 und 2. Amsterdam: ElsevierVerlag Beck K (2000) Extreme Programming. Reading, MA: Addison Wesley Beck K, Andres C (2004) Extreme Programming Explained – Embrace Change, 2nd Ed. Boston, MA: Addison-Wesley Boehm B, Abts C, Brown W, Chulani S, Clark B (2000) Software Cost Estimation with Cocomo II. Upper Saddle River, NJ: Prentice Hall Drews G, Hillebrand N (2007) Lexikon der Projektmanagement-Methoden. Haufe, München Fowler M, Scott K (2000) UML konzentriert, 2. Auflage. Bonn: Addison-Wesley GPM (2009) http://www.gpm-infocenter.de. Zugriff Oktober 2009 Jacobsen I, Booch G, Rumaugh J (1999) The Unified Software Development Process. Reading, MA: Addison-Wesley Hürten R (1999) Function-Point Analysis – Theorie und Praxis. Renningen-Malmsheim: expertVerlag Wells D. (2009) www.extremeprogramming.org. Zugriff Oktober 2009 Williams L, Kessler R (2002) Pair Programming Illuminated. New York, NY: Addison-Wesley

Kapitel 4

Crystal und Crystal Clear

Crystal ist eine Familie von agilen Prozessmodellen, die von Alistair Cockburn entwickelt wurde. Ausgehend von der Analogie zum Kristall unterteilt Cockburn die Prozessmodelle seiner Familie nach Farbe und Härtegrad. Die Farbe entspricht der Teamgröße. Der Härtegrad entspricht der Kritikalität, also der Schwere des Schadens, den die Software anrichten kann. Im Besonderen soll hier Crystal Clear betrachtet werden, welches für eher unkritische Projekte in kleinen Teams entwickelt wurde.

Die Crystal-Familie agiler Prozessmodelle wurde in den 1990er Jahren von Alistair Cockburn47 entwickelt. Cockburn unterteilt die Prozessmodelle der Crystal-Familie nach Farbe und Härtegrad. Die Farbe entspricht der Teamgröße, je dunkler desto größer das Team. Der Härtegrad entspricht der Kritikalität, also der Schwere des Schadens, den eine fehlerhafte Software anrichten kann.48 Diese Einteilung ist sinnvoll, da einerseits mit größeren Projekten ein erhöhter Kommunikationsaufwand entsteht, andererseits erhöhte Kritikalität mehr Aufwand in der Qualitätssicherung bedeutet.49 Trotzdem steht im Mittelpunkt des Ansatzes nicht eine spezifische, definierte Vorgehensweise im Projekt. Stattdessen werden generelle Prinzipien postuliert und zu erreichende Projekteigenschaften festgelegt.

4.1 Teamgröße und Risiko – die Crystal-Familie Crystal unterteilt Software-Entwicklungsprojekte bezüglich der Anzahl der Teammitglieder wie folgt: • Crystal Clear: • Crystal Yellow: • Crystal Orange:

1 bis 6 Teammitglieder bis 20 Teammitglieder bis 40 Teammitglieder

47 Interessant

und informativ ist die persönliche Website des Begründers der Methodenfamilie (Cockburn 2008), der sich übrigens Co-burn ausspricht. 48 Crystal konnte 2007 im Rahmen einer Studienarbeit an der Berufsakademie Lörrach (Duale Hochschule BW) näher beleuchtet werden (Hättich 2007, siehe auch Kap. 6.5.5). 49 insbesondere zum Testen der Korrektheit des Codes.

E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, eXamen.press, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_4, 

47

48

• • • •

4 Crystal und Crystal Clear

Crystal Red: Crystal Maroon50 Crystal Blue Crystal Violet

bis 100 Teammitglieder bis 200 Teammitglieder bis 500 Teammitglieder bis 1000 Teammitglieder

Das entsprechend der Teammitglieder gewählte Prozessmodell wird anschließend entsprechend der Kritikalität des Projekts gehärtet. Hierzu sind vier Härtegrade vorgesehen: • C:

Loss of comfort

• D:

Loss of discretionary money

• E:

Loss of essential money

• L:

Loss of life

Komfortverlust, z.B. Einschränkungen beim Bedienkomfort Verlust von verfügbaren (in der Regel unkritischen) Geldern Verlust von wesentlichen Geldern (in der Regel Verlust des Unternehmens) Verlust von Menschenleben

Ein Projekt mit 15 Teammitgliedern und der Gefahr des Verlusts von Menschenleben im Falle eines Softwarefehlers gehört somit zur Klasse L20 im Prozessmodell Crystal Yellow (Abb. 4.1).

Abb. 4.1 Die Crystal-Familie agiler Prozessmodelle

50 kastanienbraun

4.2

Die sieben Crystal-Eigenschaften

49

4.2 Die sieben Crystal-Eigenschaften Im Rahmen von Umfragen unter Teammitgliedern (Cockburn 2005) werden folgende Projekteigenschaften als wichtig identifiziert und somit für Crystal-Projekte vorgeschrieben: • • • • • • •

regelmäßige Lieferung reflektierte Verbesserung verdichtete oder osmotische Kommunikation persönliche Sicherheit Bildung von Schwerpunkten einfache Kontaktaufnahme mit Endanwendern technische Umgebung mit automatisierten Tests, Konfigurationsmanagement und regelmäßige Integrationen

Dabei werden regelmäßige Lieferung, reflektierte Verbesserung und osmotische Kommunikation als die wichtigsten Eigenschaften angesehen. Im Folgenden sollen die aufgezählten Projekteigenschaften näher beleuchtet werden.

4.2.1 Regelmäßige Lieferung Der getestete Code soll regelmäßig an den Kunden ausgeliefert werden. Somit kann der Kunde auch in gleichmäßigen zeitlichen Abständen sein Feedback zum aktuellen Stand des Software-Projekts abgeben. Abweichungen von den Anforderungen können somit schnell erkannt werden. Für den Kunden ist es einfacher, die Umsetzung seiner Anforderungen am „laufenden System“ zu überprüfen, als die Korrektheit umfassender Spezifikationsdokumente zu erkennen. Außerdem motiviert die Zustimmung des Kunden das Entwicklungsteam.

4.2.2 Reflektierte Verbesserung In Reflexionsbesprechungen listet das Team auf, was im Projekt gut funktioniert und was nicht. Das Team diskutiert über Verbesserungsmöglichkeiten und stellt Praktiken ab, die sich nicht bewährt haben. Die Ergebnisse der Teambesprechungen werden in die nächste Entwicklungsphase aufgenommen. Eine solche Teambesprechung sollte mindestens alle drei Monate oder nach Bedarf stattfinden. Sie kann von einer halben Stunde bis zu einem halben Tag dauern.51

51 Die

Erfahrung des Autors zeigt, dass sich das Team auch dagegen wehrt, wenn diese Sitzungen seiner Meinung nach zu oft stattfinden.

50

4 Crystal und Crystal Clear

4.2.3 Verdichtete oder osmotische Kommunikation Ein Team verfügt über eine verdichtete Kommunikation, wenn kurze und ergiebige Kommunikationswege zur Verfügung stehen. Die kostengünstigste Art der Kommunikation entsteht in kleinen Teams, die in einem Raum arbeiten. Man spricht dann auch von osmotischer Kommunikation. Allein durch die räumliche Nähe der Teammitglieder fließen Informationen. Wenn sich ein Mini-Team von Entwicklern über ein Thema unterhält, bekommen das die anderen Teammitglieder mit (Abb. 4.2). Vorausgesetzt das Gespräch wird nicht zu laut geführt, können sie das Gespräch wegfiltern, es sei denn, sie sind auch von dem angesprochenen Thema betroffen. Dann können sie sich einmischen und aktiv am Gespräch des Mini-Teams teilnehmen.52 Die osmotische Kommunikation hält die Kosten für Kommunikation niedrig, kann aber nur stattfinden, wenn alle Beteiligten in einem Raum sind (wie dies im studentischen Labor der Fall ist).53 Somit ist sie besonders für Crystal ClearProjekte mit ein bis sechs Teammitgliedern geeignet. In größeren Projekten, wo das Team aufgrund der Zahl der Beteiligten nicht mehr komplett in einen Raum passt, kann osmotische Kommunikation nur in entsprechend kleinen Teilteams

Abb. 4.2 Osmotische Kommunikation im Crystal-Team

52 Der

Autor konnte schon oft selbst von den Vorteilen dieser Art der informellen Kommunikation profitieren. 53 Siehe hierzu auch Kap. 6.5.5.

4.2

Die sieben Crystal-Eigenschaften

51

stattfinden. Die Kommunikation zwischen den Teilteams sollte aber wenigstens verdichtet stattfinden. Dies ergibt sich nicht von alleine, sondern nur durch entsprechende kommunikationsfördernde Maßnahmen (z.B. durch regelmäßige und ausführliche Video- oder Telefonkonferenzen). Trotzdem findet bereits eine Informationsreduktion zwischen den Teilteams statt, die aufmerksam verfolgt werden muss.54

4.2.4 Persönliche Sicherheit Ein Teammitglied muss zu jeder Zeit die Wahrheit sagen können, ohne Repressalien fürchten zu müssen. Dies gilt insbesondere, wenn man die Terminplanung des Projektleiters nicht für realistisch hält. Aber auch persönliche Misserfolge oder Unzulänglichkeiten (die in jedem Projekt vorkommen und im studentischen Projekt auch immer zu sehen sind) muss man im Team zugeben können, ohne das Gesicht zu verlieren. So kann man Unterstützung annehmen, um das anstehende Problem erfolgreich lösen zu können. Nur so kommt das Projekt erfolgreich voran! Persönliche Sicherheit entsteht durch Vertrauen: Vertrauen zum Projektleiter, aber auch zum Vorgesetzten, dass persönliche Schwächen nicht zu negativen Konsequenzen führen, sondern zu Hilfe und Unterstützung. Aber auch das erfolgreiche Team braucht Vertrauen, insbesondere das des Kunden.

4.2.5 Schwerpunkte bilden Schwerpunkte zu bilden heißt für das Management, Prioritäten für das Projekt, aber auch für das Unternehmen festzulegen und an alle Teammitglieder zu kommunizieren. Jedes Teammitglied soll die Verantwortung für zwei Schwerpunkte übernehmen und diese zu seinen persönlichen Hauptschwerpunkten machen. Idealerweise sollen damit persönliche Stärken herausgearbeitet oder gebildet werden. Zur Erledigung dieser Aufgaben sollen dem Teammitglied mindestens zwei aufeinanderfolgende Tage mit jeweils zwei Stunden täglich ohne Unterbrechung zur Verfügung stehen. Hintergrund dieser Forderung ist die verbreitete Unart, Entwickler in zu vielen verschiedenen Projekten einzusetzen. Da sich dem Entwickler oftmals alle diese Projekte als gleich wichtig darstellen, fällt ihm eine Fokusierung schwer. Sind dagegen seine Hauptschwerpunkte definiert, kann er die an ihn gestellten Anforderungen priorisieren und seinen Hauptschwerpunkten den Vorrang geben.

54 Das

studentische Labor zeigt, dass Kommunikation, insbesondere über räumliche Distanz hinweg, grundsätzlich gepflegt werden muss (z.B. durch web-basierte Konferenz-Tools).

52

4 Crystal und Crystal Clear

4.2.6 Einfache Kontaktaufnahme mit Endanwendern Wie schon in XP gefordert (Kap. 3), soll der einfache Kontakt mit dem Endanwender (also dem Kunden, der das Software-System nutzt) sicherstellen, dass dieser an Funktionalität bekommt, was er will und braucht (z.B. durch ein „rotes Telefon“, Kap. 3.3.3). Ein schnelles Feedback des Endanwenders durch regelmäßige Lieferungen vermeidet Missverständnisse und ermöglicht dem Entwicklerteam auf sich ändernde Kundenwünsche zu reagieren (Abb. 4.3). Interessant ist es, wenn der Repräsentant des Kunden und der oder die Endanwender voneinander abweichen. Gerade in diesem Fall ist es wichtig, dass Missverständnisse zwischen diesen Gruppen auf der Basis der Funktionalität der frisch ausgelieferten Release ausgeräumt werden können.

4.2.7 Technische Umgebung mit automatisierten Tests, Konfigurationsmanagement und regelmäßige Integrationen Diese Forderung sollte eigentlich eine Selbstverständlichkeit und eine „Good Engineering Practice“ sein. Automatisierte Tests haben den Vorteil ihrer ständigen Wiederholbarkeit. Ein gutes, werkzeuggestütztes Konfigurationsmanagement ist der Schlüssel zu einer zuverlässigen Integration neuer Funktionalität oder ihrer Rücknahme. Mit der Unterstützung solcher Tools sollten mindestens zwei wöchentliche

Abb. 4.3 Direktes Feedback des Kunden im agilen Team

4.3

Crystal Clear

53

Systemintegrationen möglich sein, was die Zahl der regelmäßigen Lieferungen an den Kunden entsprechend erhöht.

4.3 Crystal Clear Im Folgenden soll Crystal Clear, das Prozessmodell für kleinere Projektteams, näher beleuchtet werden. Crystal Clear ist ein iterativ-inkrementelles Prozessmodell.55 Es ist für Projekte mit ein bis sechs56 Teammitgliedern geeignet und wird hauptsächlich in den Härtegraden C und D angewendet (Kap. 4.1). Crystal Clear ist nicht geeignet für die Entwicklung von störungssicheren oder lebenskritischen Systemen.57

4.3.1 Eigenschaften und Praktiken Laut Alistair Cockburn soll Crystal Clear ein „einfacher und toleranter Regelsatz sein, der das Projekt in sicheres Fahrwasser bringt.“ (Cockburn 2005). Der Fokus liegt dabei auf der guten Kommunikation und der hohen Toleranz gegenüber variierenden Arbeitsstilen. Dieser „hohe Toleranzspielraum“ des Prozessmodells lässt Platz für die individuellen Anforderungen unterschiedlicher Projekte, weil Crystal Clear lediglich die ersten drei Crystal-Projekteigenschaften (Kap. 4.2) fordert: • regelmäßige Lieferung • reflektierte Verbesserung • osmotische Kommunikation Die geforderten Projekteigenschaften sind das Ergebnis von Befragungen erfolgreicher Teams. Zu beachten ist, dass die Kommunikation in Crystal Clear als osmotische Kommunikation abläuft. Das kleine Projektteam und die räumliche Nähe der Mitarbeiter lassen dies zu. Der Prozessablauf ist üblicherweise „individuell“. Die in der Regel erfahrenen Teams58 benutzen ebenso bekannte wie auch individuell entwickelte, projektspezifische Methoden. Crystal Clear lässt diesen Toleranzspielraum bewusst, es werden keine spezifischen Tools oder Projektmethoden vorgeschrieben. Der Schwerpunkt liegt eher auf Kommunikation

55 Siehe

hierzu auch Kap. 1.3.

56 eventuell auch bis zu zehn Teammitglieder! Hierfür sprechen Erfahrungen aus dem studentischen

Labor (Kap. 6.5.5) und andere Literatur, wie (Wolf u. Roock, 2008). dort notwendigen Validierungsmaßnahmen, wie z.B. behördliche Überprüfungen des Designs oder Tests gegen im Vorfeld ausformulierte und von den Behörden abgenommene Spezifikationen sind in Crystal Clear nicht vorgesehen. 58 Wenigstens der Teamleiter sollte „über den Dingen stehen“, also viel Erfahrung mit Crystal Clear mitbringen (Cockburn 2005). 57 Die

54

4 Crystal und Crystal Clear

und reflektierter Verbesserung des Prozesses. Das Team nimmt sich also regelmäßig Zeit, die Abläufe im Prozess zu hinterfragen und ggf. zu verbessern. Der Software-Entwicklungsprozess wird als eine sich entwickelnde Unterhaltung oder als kooperatives „Spiel“ betrachtet. Trotz der besonders für Neulinge verwirrend wenigen Eigenschaften, die für ein Crystal Clear-Projekt gefordert werden,59 beschreibt Alistair Cockburn sehr genau, wie ein Crystal Clear-Projekt aussehen muss (Cockburn 2005). Folgende Anforderungen müssen zwingend erfüllt sein: • Die Kommunikationswege müssen kurz und ergiebig sein. Das Team sitzt idealerweise in einem Raum (osmotische Kommunikation). • Die Inkrementzyklen dauern typischerweise ein bis zwei Monate, nicht aber länger als ein Vierteljahr. Ansonsten kann man nicht mehr von einer regelmäßigen Lieferung sprechen. • Am Projekt ist ein Endanwender beteiligt. Dies kann ggf. auch nur zweitweise sein. Wichtig ist, dass das User Interface zusammen mit diesem Endanwender entwickelt wird. Außerdem ist sein Feedback wichtig. Auch dieser enge Umgang mit dem Endanwender trägt zur osmotischen Kommunikation bei. • Der Projektauftrag ist definiert. Dies kann high-level in Form von Business Requirements, low-level in Form von User-Stories sein. Ebenso müssen high-level Aussagen zum System-Design bestehen.60 • Die Verantwortlichkeiten für Arbeitsergebnisse des Teams müssen klar definiert sein. Für jede Klasse, jedes Modul, jede Prozedur ist definiert, wer Änderungen vornehmen darf. Dies können Einzelpersonen, aber auch ganze Sub-Teams sein, niemals aber das ganze Team.61 Ein Team, welches die nachfolgenden Praktiken einsetzt, befindet sich immer noch im Einklang mit Crystal Clear: • Das Team ist klein, sitzt aber in benachbarten Räumen und besucht sich häufig gegenseitig. Wichtig ist dabei das persönliche Gespräch (nicht über das Telefon)!62 • Entlehnen von Methoden anderer Prozessmodelle ist erlaubt. So passt z.B. die Scrum-Backlog-Technik (Kap. 5.3.1) für das Priorisieren von Projektanforderungen gut zu Crystal Clear und kann auch hier angewendet werden.

59 Man

vergleiche mit Extreme Programming (XP, Kap. 3). als rudimentäre UML-Diagramme. 61 Diese Forderung kann damit u.U. in einem gewissen Gegensatz zum Collective Code Ownership bei XP stehen (Kap. 3.5). Dort ist gefordert, dass das ganze Team Änderungen am Code vornehmen kann. 62 Die Erfahrungen im studentischen Labor zeigen aber, dass bereits bei benachbarten TeamRäumen die Kommunikation leidet, wenn nicht aktiv, z.B. durch regelmäßige Teamsitzungen in kurzen Abständen (mindestens täglich), entgegengewirkt wird. 60 ggf.

4.3

Crystal Clear

55

• Pro Code-Lieferung gibt es nur eine Iteration. Es werden allerdings viele Demonstrationen für den Endanwender durchgeführt. Somit können seine Kommentare auf diese Art und Weise in den Entwicklungsprozess einfließen.63 • Nicht alle fertiggestellten Inkremente und Teilfunktionalitäten werden sofort an den Endanwender ausgeliefert, der damit überfordert wäre, sondern sie werden z.B. von einem Integrator auf einem separaten Notebook oder Server „gesammelt“ und in geeigneten zeitlichen Abständen dem Endanwender zur Verfügung gestellt.64 • Bei Design-Dokumenten werden eigene Formate und keine Standards verwendet. Wichtig dabei ist allerdings, dass die Darstellungen in ihrer Bedeutung klar sind und von allen Beteiligten verstanden werden.65 Zur Abgrenzung sollen noch Praktiken erwähnt werden, deren Einsatz nicht Crystal Clear entspricht, obwohl sie durchaus funktionieren können: • Das Team arbeitet in unterschiedlichen Gebäuden oder an verschiedenen Orten. Kommunikation findet über Telefon, E-Mail oder durch gelegentliche Besuche statt. • Die Iterationen dauern mehr als vier Monate. • Vor der Lieferung findet keine Überprüfung durch den Anwender statt. Somit ist die Gefahr groß, dass er nicht das bekommt, was er eigentlich will (und braucht). • Das Team kann nicht mit einem Endanwender kommunizieren, sondern erhält die notwendigen Informationen z.B. vom Marketing.66 Interessant ist abschließend noch die Prüfung der siebten Crystal-Eigenschaft, der Einrichtung einer technischen Umgebung mit automatisierten Tests und Konfigurationsmanagement. Ein Crystal Clear-Projekt muss sie zwar nicht zwingend besitzen, es nützt aber ungemein und sollte zwischenzeitlich zum „Good Engineering“ gehören. Am Konfigurationsmanagement sollte heutzutage kein Weg vorbeigehen, aber automatisierte Regressionstests sind letztlich für den Projekterfolg nicht zwingend erforderlich.67 Somit bleiben sie eine wichtige Option für ein erfolgreiches Projekt (die der Autor dringend empfiehlt!).

63 Der

Autor dieses Buchs rät allerdings davon ab, Code-Lieferungen nur in jeweils einer Iteration zu entwickeln. Die Integration des Codes wird umso schwieriger, je länger damit gewartet wird. Es treten in der Regel ungeahnte Probleme am Ende der Iteration auf. Auch der Endanwender ist besser dran, wenn er die Software nicht nur sieht, sondern ab und zu mit einer (Zwischen-) Release arbeiten kann. 64 Auch der Autor übergibt die Aufgabe der Integration an eine spezielle Projektrolle, den Integrationsingenieur (Kap. 6.4 und 7.4.3). 65 Der Autor rät davon ab! UML ist zwischenzeitlich so verbreitet, dass es als Standard für DesignDokumente genutzt werden sollte. 66 Die Erfahrungen des Autors zeigen, dass das in der Regel nicht gutgeht! Die Problematik stellt sich auch beim Scrum-Product Owner und wird auch dort behandelt (Kap. 5.1.1 und 6.5.6). 67 wenn sie auch die Geschwindigkeit und Sicherheit des Redesigns massiv erhöhen.

56

4 Crystal und Crystal Clear

4.3.2 Rollen im Projektteam Crystal Clear kennt acht benannte Rollen, von denen vier Rollen von unterschiedlichen Personen wahrgenommen werden müssen (Cockburn 2005). Die wichtigsten vier Projektrollen sind: • • • •

Auftraggeber erfahrener Anwender Chefdesigner Designer/Programmierer Diese Rollen sollen im Folgenden kurz vorgestellt werden:

4.3.2.1 Auftraggeber Der Auftraggeber wird oft auch als Kunde bezeichnet, weil er das Projekt finanziert und damit die vertragliche Beziehung zum Entwicklungsteam unterhält. Er vertritt das Projekt nach außen und muss ökonomische Entscheidungen fällen, insbesondere wenn sich während der Projektlaufzeit der betriebswirtschaftliche Nutzen des Projekts verändert.68 Er entscheidet auch über einen möglichen Abbruch des Projekts. 4.3.2.2 Erfahrener Anwender Die Wichtigkeit dieser Projektrolle wurde in diesem Kapitel schon oft beleuchtet. Der erfahrene Anwender ist mit den Arbeiten vertraut, die mit dem zu erstellenden Software-System durchgeführt werden sollen. Er weiß i.d.R. wie das Vorgängersystem funktioniert und kennt die Nachteile dieses Systems, die meist zum Projektauftrag für den Nachfolger geführt haben. Er ist Ansprechpartner, wenn es um die Gestaltung der Bedienoberfläche des Software-Systems geht. Der erfahrene Anwender muss dem Team genügend oft zur Verfügung stehen.69 4.3.2.3 Chefdesigner Der Chefdesigner ist der technische Leiter des Projekts. Er verfügt über Erfahrungen im Bereich der Software-Entwicklung und des Software-Designs und ist für das System-Design verantwortlich. Er hat den höchsten Crystal-Kompetenzgrad der Stufe 3. Dabei definiert Crystal Stufe 1 als das Nachahmen von Crystal-Praktiken, Stufe 2 als das Loslösen von diesen Praktiken und Stufe 3 als die Fähigkeit, Praktiken zu vermischen oder neue Praktiken zu erfinden. 68 Dies ist notwendig, wenn auch sehr unangenehm für das Projektteam, wie der Autor aus eigener

Praxis weiß. wurde bereits in Kap. 4.3.1 diskutiert.

69 Dies

4.3

Crystal Clear

57

Da es in Crystal Clear keinen expliziten Projektleiter gibt, ist der Chefdesigner auch für die Steuerung des Projekts verantwortlich. Dies erfordert sowohl fachliche als auch methodische Fähigkeiten, insbesondere da der Chefdesigner auch selbst kodiert. Mit dem Chefdesigner hat ein Crystal Clear-Team also mindestens ein Teammitglied der Crystal-Erfahrungsstufe 3. Generell gilt die Regel, das kleine Teams ohne standardisierte Prozessabläufe überwiegend aus erfahrenen Mitgliedern der Stufen 3 und 2 bestehen sollten.70 4.3.2.4 Designer/Programmierer Diese zusammengesetzte Rollenbezeichnung demonstriert die Zusammengehörigkeit beider Tätigkeiten. Ein Crystal Clear-Programmierer muss sowohl designen als auch programmieren. Trennt man die zwei Tätigkeiten zwischen verschiedenen Teammitgliedern auf, entstehen Missverständnisse, die in einem Crystal Clear-Projekt nicht tragbar sind. Neben den vier beschriebenen Projektrollen gibt es noch vier weitere „Nebenrollen“ im Projekt, die entweder einer der vier Hauptrollen zugeordnet werden können oder temporär von einem der Teammitglieder mit übernommen werden: 4.3.2.5 Koordinator Der Koordinator koordiniert das Projekt. Er protokolliert Projektplanung und Projektstatus und informiert alle Teammitglieder über seine Ergebnisse. Er vermittelt dem Auftraggeber Struktur und Status des Projekts inklusive Releaseplan. Meist wird diese Aufgabe vom Chefdesigner oder von einem anderen befähigten Teammitglied übernommen.71 4.3.2.6 Fachexperte Der Fachexperte kennt die Geschäftsabläufe und damit den fachlichen Kontext des Projekts. Er bietet den Entwicklern den fachlichen Hintergrund und kann auch einschätzen, welche Elemente der Geschäftsabläufe (und damit der fachlichen Grundlagen des Software-Produkts) sich in Zukunft ändern könnten. Ideal ist es, wenn diese zusätzliche Rolle vom erfahrenen Anwender übernommen werden kann, wenn dieser also auch über die fachlichen Hintergründe des Projekts verfügt. Wie schon erwähnt, ist es projektentscheidend, dass sowohl der erfahrene Anwender als auch der Fachexperte dem Team genügend oft zur Verfügung stehen und Fragen des Teams umfassend und kompetent beantworten.

70 In

(Boehm 1981) wird sehr umfassend auf die Abhängigkeit zwischen der Erfahrung der Teammitglieder und dem Erfolg des Projekts eingegangen. 71 Cockburn schlägt ggf. auch einen Wechsel dieser Rolle zwischen verschiedenen Teammitgliedern vor (Cockburn 2005). Der Autor rät davon ab, weil das Projekt gerade in der Außenwirkung gegenüber dem Auftraggeber immer dasselbe „Gesicht“ haben sollte.

58

4 Crystal und Crystal Clear

4.3.2.7 Tester Grundsätzlich gilt die Regel, dass man das, was man entwickelt hat, nicht selbst testen kann. (Wer findet schon gern seine eigenen Fehler?) Es empfiehlt sich also in einem kleinen Team, dass Entwickler die Module der jeweils anderen Teammitglieder testen. Noch besser ist es, wenn das Team für einen gewissen Zeitraum externe Tester engagieren kann.72 4.3.2.8 Autor Die Autoren sind für das Erstellen der Dokumentation, insbesondere der Anwenderdokumente wie Benutzerhandbuch oder Abnahmetests, verantwortlich. Oft übernehmen diese Aufgabe die Teammitglieder mit, manchmal findet aber auch eine Spezialisierung eines Teammitglieds oder externer Mitarbeiter statt (Abb. 4.4). Im Kap. 6.5.5 wird das „Funktionieren“ von Crystal Clear im studentischen Labor überprüft. Dabei wird das Zusammenspiel eines Crystal Clear-Teams näher beleuchtet und die dabei auftretenden Probleme, insbesondere im Bereich der reflektierten Verbesserung, analysiert.

Abb. 4.4 Der Autor des neuen CMS73 informiert das studentische Team über die Fortschritte

72 Automatisierte 73 Content

Tests und ausformulierte Testpläne helfen auch hier weiter. Management System zur Verwaltung der Projektdokumente.

Literatur

59

Literatur Boehm B (1981) Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall Cockburn A. (2001) http://alistair.cockburn.us/ Crystal+light+methods. Artikel im Cutter IT Journal, 2001. Zugriff Dezember 2009 Cockburn A (2005) Crystal Clear: A human powered Methodology for small Teams. New York, NY: Pearson. Dt. Übersetzung: Crystal Clear: Agile Software-Entwicklung für kleine Teams. Bonn: MITP-Verlag Cockburn A (2008) http://alistair.cockburn.us. Zugriff Dezember 2009 Hättich N (2007) Das agile Prozessmodell Crystal, Studienarbeit, DHBW/BA Lörrach, Studiengang Informationstechnik Wolf H, Roock A (2008) Agile Softwareentwicklung – ein Überblick. Heidelberg: dpunkt Verlag

Kapitel 5

Scrum

Im Gegensatz zu den bisher diskutierten agilen Prozessmodellen ist Scrum eine agile Projektmanagementmethode. Nicht die Zusammenarbeit des Teams, sondern der Ablauf des Projekts steht im Vordergrund. Auffallend sind die in Scrum festgelegten Projektrollen Product Owner, Team und Scrum Master, insbesondere das Fehlen einer „klassischen“ Rolle, der des Projektmanagers. Neben den Aufgaben der Projektrollen regelt Scrum den Projektablauf in Form von Sprints, also Entwicklungszyklen von wenigen Wochen.

Scrum unterscheidet sich von den bisher diskutierten agilen Prozessmodellen, denn es ist eine agile Projektmanagementmethode. Fragen der Zusammenarbeit und der Teamstruktur stehen nicht im Vordergrund, sondern der Ablauf des Projekts. Trotzdem ist es eine sehr interessante agile Methode mit zunehmender Verbreitung. Scrum folgt der Idee des Lean Managements, des „schlanken“ Managements, wie es insbesondere bei Toyota verfolgt wird74 (Gloger 2009). Scrum wurde in den frühen 1990er Jahren von Ken Schwaber und Jeff Sutherland entwickelt, die Grundgedanken sind in (Schwaber 2004) niedergelegt. Auffallend sind die in Scrum festgelegten Projektrollen • Product Owner • Team • ScrumMaster und damit insbesondere das Fehlen einer „klassischen“ Rolle, der des Projektmanagers. Neben den Aufgaben der Projektrollen regelt Scrum den Projektablauf in Form von Sprints – Entwicklungszyklen von wenigen Wochen.

5.1 Scrum – die Projektrollen Im Folgenden sollen die in Scrum zwingend geforderten Projektrollen näher beleuchtet werden. 74 auch wenn Ken Schwaber immer wieder betont, dass Scrum seinen Ursprung nicht in der Lean Production hat

E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, eXamen.press, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_5, 

61

62

5

Scrum

5.1.1 Product Owner Der Produktverantwortliche übernimmt die Sichtweise des Endkunden. Er steuert die Software-Entwicklung und arbeitet eng mit dem Entwicklungsteam zusammen. Ähnlich wie der Kunde in XP (Kap. 3) ist er für das Entwicklungsteam ständig verfügbar. Im Gegensatz zum XP-Kunden bestimmt er im Projekt alleine „wohin die Reise geht“75 (Pichler 2008). Die Rolle des Product Owners ist bivalent. Er darf nicht die „Unschuld“ des Kunden annehmen und sich neue Features wünschen, sondern wird auch sofort auf die Realisierungsmöglichkeit achten. Es besteht somit die Gefahr, dass tolle Ideen nicht realisiert werden, weil der Product Owner nicht an ihre Realisierungsmöglichkeit glaubt. Im Einzelnen hat der Product Owner folgende Aufgaben: 5.1.1.1 Anforderungsmanagement Der Product Owner erfasst die Anforderungen des Kunden an die Software und beschreibt sie in Form eines Produktkonzepts76 und des Product Backlogs.77 Ein traditionelles Scrum Product Backlog enthält alle Arten von Anforderungen oder Tätigkeiten, die im Zusammenhang mit dem Projekt erledigt werden müssen.78 Ziel ist immer, einen Mehrwert für den Kunden zu erzeugen. Der Product Owner priorisiert und schätzt die Anforderungen als Basis der Arbeit des Teams. Das Product Backlog „lebt“. Im Verlauf des agilen Prozesses wird es ständig aktualisiert und erweitert. 5.1.1.2 Release Management Der Product Owner ist verantwortlich für den Erfolg des Projekts. Er alleine entscheidet über Funktionalität, Kosten und Termine. Somit ist er auch verantwortlich für die Auslieferung der diversen Releases.79 Er erstellt also einen Release Plan und passt ihn ggf. an. Der Product Owner ist gut beraten, dies in Absprache mit dem Team zu machen. Die Aufwandschätzungen aus dem Team sind die Basis für seine Planung.

75 und

wird damit zum „single wringable neck“, wie diese Rolle bei Yahoo! bezeichnet wird (Pichler 2008) 76 Beantwortung von Fragen wie: Was wollen wir als Firma mit dem Produkt erreichen? Was ist der Zweck des Produkts? 77 engl. Auftragsbestand 78 Für den Product Owner ist es am einfachsten, sich zuerst auf Anforderungen zu konzentrieren, die einen Mehrwert für den Kunden erzeugen. Diese Anforderungen sind aus (Kap. 3.3.1) als User Stories (XP) bekannt, siehe dazu auch (Wirdemann 2009). 79 Versionen

5.1

Scrum – die Projektrollen

63

5.1.1.3 Kommunikation Der Product Owner muss beständig mit dem Team und mit allen beteiligten Interessengruppen (Stakeholdern), insbesondere beim Endkunden, kommunizieren. Da der Product Owner eng mit dem Team zusammenarbeiten muss, kann man aus der Sicht des Teams von Innen- und Außenwirkung sprechen. In der Innenwirkung steht der Product Owner dem Team idealerweise pro Tag eine entsprechende Zeitdauer zur Verfügung (mindestens eine Stunde) während er den Rest des Tages zumindest gut erreichbar ist.80 In der Außenwirkung kommuniziert der Product Owner insbesondere mit den Endkundengruppen, um ein möglichst frühes Feedback über neue Funktionalität der Software zu bekommen. Es ist wichtig, den Product Owner mit genügend Vollmachten und Zeit auszustatten, um die o.g. Aufgaben zu erfüllen. Product Owner ist ein Vollzeit-Job81 ! Nur so kann ein Erfolg des Projekts ermöglicht werden.

5.1.2 Team Das Team entwickelt („liefert“) das Produkt, also die Software. Seine Zusammensetzung ist entscheidend für das Gelingen des Projekts. Dabei geht es nicht nur um die fachliche Qualifikation, sondern auch um die Teampsychologie, also das „Zusammenpassen“ der Teammitglieder. Dies soll in Kap. 6 und 7 näher beleuchtet werden. Wichtig ist, potenziellen Teammitgliedern die Möglichkeit zu geben, sich für interessante Projekte zu bewerben. Damit ist zumindest sichergestellt, dass Interesse vorhanden ist.82 Scrum geht nicht weiter auf die Rollenverteilung im Team ein. Scrum ist, wie schon erwähnt, eine Managementmethode. Es ist jedoch klar, dass alle Rollen oder besser gesagt Fähigkeiten, die für eine erfolgreiche Projektentwicklung notwendig sind, vorhanden sein müssen. Auch hier sei auf Kap. 6 und 7 verwiesen. Ein Team muss folgende Eigenschaften haben: 5.1.2.1 Selbstorganisiert und klein Innerhalb eines Sprints (also einer Iteration) organisiert sich das Team selbst. Ausschließlich die Teammitglieder entscheiden, welche Aufgaben gelöst werden müssen, um ein Sprint-Ziel zu erreichen, und wer für die Aufgabe verantwortlich zeichnet.83 Das Team hat keinen Teamleiter, also auch keinen klassischen

80 Aus

der Erfahrung des Autors empfiehlt sich die Verfügbarkeit über ein „rotes Telefon“, ein Mobiltelefon ggf. mit Geheimnummer, welche nur dem Team bekannt ist. 81 Sollte das nicht möglich sein, muss er wenigstens 50% seiner Zeit für das Projekt freigestellt werden (Pichler 2008). 82 Google ermutigt Entwickler, sich für Projekte zu bewerben! 83 Das Team ist empowered (bevollmächtigt).

64

5

Scrum

Projektleiter. Dies hat zum einen mit der Größe des Teams zu tun: Ein ideales Scrum-Team hat sieben ± zwei Mitglieder (Schwaber 2004). Zum anderen kann gemäß Scrum auf den Teamleiter verzichtet werden, weil das Team seine tägliche Arbeit im Rahmen eines „Korsetts“ von Berichten und Besprechungen durchführt und somit „Leitplanken“ für die Projektdurchführung hat.84 Bedingung für diese Arbeitsweise ist die Vollzeitmitgliedschaft der Mitglieder im Team. Agile Techniken erfordern ein Team, das sich als Einheit versteht. Dieses Teamverständnis kann sich nicht aufbauen, wenn einige Teammitglieder von Projekt zu Projekt „hüpfen“. Auch der Arbeitsplatz des Teams muss den Anforderungen genügen: Ein agiles Team muss osmotisch kommunizieren (Cockburn 2005). Dazu gehört räumliche Nähe. Das Team muss ein gemeinsames Büro haben85 (Abb. 5.1). Osmotische Kommunikation läuft in einer solchen räumlichen Situation typischerweise wie folgt ab: • Ein Teammitglied holt sich einen Kaffee, verlässt seinen Arbeitsplatz und schlendert an anderen vorbei. Automatisch und ohne eigenes Zutun („osmotisch“)

Abb. 5.1 Team im gemeinsamen Büro

84 Es

sind dies: Sprint-Backlog, Sprint-Burndown-Bericht und die Daily Scrum-Besprechung, siehe auch Kap. 5.2. 85 Nach der Erfahrung des Autors ist diese Forderung nicht verhandelbar und kann auch nicht durch Videokonferenzen ersetzt werden. Der Verlust an osmotischer Kommunikation wäre einfach zu hoch.

5.1

Scrum – die Projektrollen

65

schnappt es Gesprächsfetzen der anderen auf. Entweder sind diese uninteressant oder sie betreffen die Arbeit des Teammitglieds. Das Teammitglied schaltet sich in die Diskussion ein. • Durch die räumliche Nähe hört man ohne Absicht Gesprächsfetzen der nebenan sitzenden Entwickler mit. Betrifft einem das Thema, schaltet man sich in die Diskussion ein.

Osmotische Kommunikation geschieht immer „im Vorbeigehen“. Man glaubt nicht, wie viele wichtige Dinge man auf diese Weise erfährt! Eine Anmerkung zu Großraumbüros: Der Teambereich sollte durch Stellwände abgegrenzt werden. Es empfiehlt sich, nicht mit dem Platz zu sparen. Nach den Stellwänden sollte nicht sofort der erste Schreibtisch folgen, sondern es sollte ausreichend „Luft“ um den Teambereich herum sein. Ansonsten wird das Team ständig durch Passanten gestört, die über die Wände hinweg sprechen.

5.1.2.2 Multidisziplinär und autonom Die Teammitglieder müssen alle Fähigkeiten abdecken, die zum Erreichen der Projektziele erforderlich sind. Software-Architekten müssen genauso vorhanden sein wie Datenbankspezialisten, Programmierer, Qualitätssicherer, Tester, Dokumentierer usw. Wichtig ist, dass diese Spezialisten nicht auf ihrer traditionellen Projektrolle beharren. Grundsätzlich muss jedes Teammitglied jede Aufgabe im Projekt übernehmen (können) und damit auch sein Wissen an die anderen weitergeben. Das Scrum-Team muss unabhängig sein. Ist ein Sprint-Ziel erst einmal definiert, muss das Team in der Lage sein, das Ziel ohne externe Abhängigkeiten oder Hilfe von außen zu erreichen. Ist dies nicht gewährleistet, dann muss die Zusammensetzung des Teams verbessert werden, indem externer Sachverstand ins Team geholt wird.

5.1.3 ScrumMaster Der ScrumMaster (Change Agent) ist der Prozessverantwortliche. Er ist der Freund des Teams. Er coacht das Team, wenn es um die Einhaltung des Prozesses geht. Insbesondere bei mit Scrum unerfahrenen Teams hilft er, den Prozess zu etablieren. Macht er seine Arbeit gut, macht er sich idealerweise überflüssig! Die Erfahrung zeigt jedoch, dass es nicht soweit kommt, da Teams dazu neigen, den gewählten Prozess (manchmal bis zur Unkenntlichkeit) abzuändern (was der Autor grundsätzlich nicht für beängstigend hält, siehe Kap. 6 und 7). Deswegen muss der ScrumMaster immer wieder eingreifen und die Korrektheit des Prozesses überprüfen. Bei erfahrenen Teams kann er allerdings die Zeit, die er mit dem Team verbringt,

66

5

Scrum

langfristig reduzieren. Der Beziehung zwischen ScrumMaster und Team ist eine Eins-zu-Eins-Beziehung. Der ScrumMaster arbeitet beim Team. Die Aufgaben des ScrumMasters sind: 5.1.3.1 Scrum einführen und Product Owner und Team unterstützen Der ScrumMaster etabliert den Prozess im Team. Er identifiziert Hindernisse wie verkrustete Denkweisen oder „veraltete“ Arbeitsweisen. Er hilft dem Team, Scrum kennen zu lernen und damit Erfahrungen zu sammeln. Er erklärt dem Team die Abläufe im Prozess und unterstützt es dabei. Er beantwortet auftauchende Fragen zum Prozess. Wichtig ist es auch, das Team gegen Einflüsse von außen zu schützen. Keinesfalls dürfen Mitglieder von den Vorgesetzten für andere Aufgaben abgezogen werden (auch nicht temporär). Ziel ist, das Team in Ruhe arbeiten zu lassen. Der ScrumMaster unterstützt auch den Product Owner. In der Regel ist auch dieser anfangs ungeübt und braucht Hilfe. Wichtig ist zu verhindern, dass der Product Owner in die Rolle des Projektleiters verfällt. (Diese Gefahr besteht allerdings auch für den ScrumMaster!) Der Product Owner muss zwar eng mit dem Team zusammenarbeiten, setzt das Team jedoch zu einem Scrum Sprint an, darf er es nicht mehr stören. Das muss der ScrumMaster verhindern. 5.1.3.2 Hindernisse beseitigen Der ScrumMaster muss Abweichungen vom Prozess-Soll, die Impediments angehen (Gloger 2009). Impediments hindern das Team daran, effizient zu sein. Diese Blockaden müssen gelöst werden. Der ScrumMaster notiert sich alle Abweichungen in einer eigenen Liste, dem Scrum Impediment Backlog. Diese muss er nach und nach abarbeiten. In der Regel können komplexere Blockaden nicht in kurzer Zeit gelöst werden. Impediments können Probleme in der Teampsychologie sein (wenn also z.B. Teammitglieder nicht miteinander auskommen), können sich aber auch aus falsch verstandenen Scrum-Rollen ergeben, z.B. dem Product Owner, der versucht als Projektleiter zu fungieren. Auch ein fehlender oder ungeeigneter Product Owner wird ganz schnell zu einem essenziellen Problem. Hier ist das Fingerspitzengefühl des ScrumMasters gefragt, die Situation zu entschärfen und einen geeigneten Product Owner zu finden. 5.1.3.3 Dem Team dienen Der ScrumMaster führt das Team. Jeder Coach weiß, dass er alleine aufgrund seines Wissensvorsprungs eine Führungsfunktion hat. Diese darf jedoch nicht ausgenutzt werden. Der ScrumMaster sollte einen kollegialen Führungsstil pflegen. Seine Aufgabe ist es, dem Team Hindernisse aus dem Weg zu räumen, nicht Aufgaben anzuweisen bzw. im Team zu verteilen. Dies obliegt alleine dem Team selbst.

5.1

Scrum – die Projektrollen

67

5.1.4 Weitere Scrum-Rollen In der Literatur findet man manchmal weitere Scrum-Projektrollen,86 die zum Verständnis des Prozesses nützlich sind, aber auch in „klassischen“ Prozessmodellen vorkommen: 5.1.4.1 Der Kunde Der Kunde beauftragt die Produktentwicklung. Er ist budgetverantwortlich, sowohl bei interner als auch bei externer Projektvergabe. Er entspricht der Rolle des Kunden, wie wir sie aus anderen agilen Methoden kennen, übernimmt aber keine Projektverantwortung. 5.1.4.2 Der Anwender Der Anwender ist der spätere Benutzer der Software. Üblicherweise hat er bereits Erfahrungen mit der Vorgänger-Software (falls eine solche vorhanden ist) und kann dem Team wertvolle Tipps bezüglich der Usability (Nutzbarkeit) geben. Team und Product Owner tun gut daran, solche Tipps zu beherzigen und in die Sprint-Planung einzubeziehen, weil die Akzeptanz der Software damit ungemein steigt.87 Nach dem Sprint wird der Anwender die Realisierung seiner Tipps prüfen. Das Trennen der Rollen Kunde und Anwender ist nicht unproblematisch. In klassischen, nicht agilen Projekten entspricht es der Realität, andere agile Methoden88 versuchen hingegen, einen Kunden zu finden, der auch die Rolle des Anwenders hinreichend gut ausfüllen kann. Somit kann er auch die Machbarkeit eines Wunsches sofort abschätzen und wird damit für das Team verlässlicher. 5.1.4.3 Das Management Das Management sorgt für die Rahmenbedingungen, innerhalb derer ein Projekt durchgeführt wird. Meist löst es die vom ScrumMaster im Projektumfeld identifizierten Probleme.

5.1.5 Gefahr durch Rollenmissbrauch Da in Scrum die klassische Rolle des Projektleiters fehlt, besteht insbesondere in unerfahrenen Scrum-Teams die Gefahr, dass Product Owner oder ScrumMaster die 86 siehe

z.B.(Gloger 2009). Die Rollen werden allerdings bei (Schwaber 2004) nicht erwähnt. des Autors zeigt allerdings, dass in der Regel nicht alle Wünsche des Anwenders berücksichtigt werden können. Manchmal widersprechen sich Wünsche, oft sind sie auch im Rahmen des Budgets nicht realisierbar. Dieser Konflikt entsteht durch das Trennen der Rollen Kunde und Anwender. 88 z.B. XP (Kap. 3) und MAP (Kap. 7) 87 Die Erfahrung

68

5

Scrum

Rolle übernehmen und der „gelebte“ Prozess somit von Scrum abweicht. Problematisch ist, dass mit Einführung von Scrum meist ehemalige Projektleiter die Rolle des ScrumMasters übernehmen. Damit ist die Gefahr eines „Rückfalls“ in alte Denkmuster naturgemäß groß. Bei unerfahrenen Product Ownern besteht die Gefahr, dass sie die Autonomie des Teams verletzen. Bei Einführung von Scrum muss also darauf geachtet werden, dass Product Owner oder ScrumMaster ihre Rollen nicht missbrauchen. Es empfiehlt sich, Product Owner, ScrumMaster und Team im Verlauf des Projekts immer wieder durch externe Scrum-Experten zu coachen.

5.2 Scrum – der Prozess Im Weiteren soll das Zusammenspiel der Scrum-Rollen beleuchtet werden: Wie sieht der Ablauf eines Scrum-Projekts aus?

5.2.1 Scrum-Flow – Überblick Der Ablauf des Scrum-Prozesses ist einfach gehalten (Abb. 5.2). Am Anfang steht die Vision des Product Owners mit einer kurzen Beschreibung des Produkts, einer Abschätzung des Aufwands und möglicher Meilensteine.89 Letztlich muss die Frage geklärt sein, ob es sinnvoll ist, das Projekt anzugehen, bevor man in den eigentlichen Scrum-Prozess eintritt. Wenn diese Business-Entscheidung gefällt ist, wird das Product Backlog vom Product Owner gefüllt.90 Hier werden alle Anforderungen an die Software festgehalten und priorisiert. Erstellt wird die Software vom Team in Iterationszyklen, den sog. Sprints. Alle Sprints dauern gleich lang, üblicherweise wählt man maximal 30 Tage für einen Sprint. Für jeden Sprint wird zwischen Product Owner und Team ein Endtermin vereinbart, der eingehalten werden muss. Zu Beginn des Sprints findet eine Sprint-Planungssitzung statt, in der das Team das Sprint Backlog erstellt. In diesem Planungsdokument wird festlegt, welche Anforderungen für das nächste Inkrement der Software abgearbeitet werden sollen und welche Aktivitäten dazu notwendig sind. Die Planung des Sprints geschieht entsprechend den Vorgaben im Product Backlog. Danach beginnt der Sprint, also die eigentliche Implementierung des nächsten Inkrements der Software. Hier entwickelt das Team ohne Störung von außen das neue Software-Inkrement mit den im Sprint Backlog festgelegten Features. Jeden Tag am selben Ort zur selben Zeit findet eine Teambesprechung statt, die Daily Scrum genannt wird. Wichtig ist, dass diese Sitzung kurz gehalten wird. Neben dem Team muss der ScrumMaster anwesend sein. Der Product Owner hingegen 89 Hier handelt es sich naturgemäß nicht um seriöse Schätzungen, sondern um Ziele, die man gerne erreichen würde. Sie müssen später vom Team durch Aufwandschätzungen untermauert werden (oder eben auch nicht). 90 Hier kann er bereits vom Team unterstützt werden. Die Verantwortung bleibt aber beim Product Owner.

5.2

Scrum – der Prozess

69

Abb. 5.2 Scrum Flow

sollte anwesend sein. Betroffene Gäste sind erlaubt, haben aber kein Rederecht. Das Team hat Gelegenheit, die Arbeit zu koordinieren und Probleme anzusprechen und entweder gleich zu lösen oder wenigstens an den ScrumMaster oder den Product Owner weiterzugeben. Am Ende des Sprints steht das Sprint Review. Hier wird das entstandene Software-Inkrement vom Product Owner geprüft und abgenommen. Dabei werden nur vollständige und fehlerfreie Arbeitsergebnisse akzeptiert. Der Sprint schließt mit der Sprint-Retrospektive, die dem Team Gelegenheit gibt, über den Ablauf des Sprints nachzudenken, insbesondere über die Zusammenarbeit im Team und über Verbesserungsmaßnahmen. Diese bilden die Grundlage für den nächsten Sprint.

5.2.2 Sprint – Details 5.2.2.1 Sprintlänge Üblicherweise werden in iterativen Prozessmodellen die Features der Software definiert, die im nächsten Inkrement enthalten sein sollen. Der Aufwand für ihre Implementierung wird spätestens jetzt vom Team geschätzt, und ggf. werden Features zurückgestellt, um die Iteration nicht zu lange andauern zu lassen. In größeren Projekten sind Iterationslängen von zwei bis drei Monaten keine Seltenheit. Von Iteration zu Iteration schwankt die zeitliche Länge, weil man die Realisierung

70

5

Scrum

der konkreten Features der Software in den Vordergrund stellt und letztlich (aus Entwicklersicht) keinen Vorteil in einer gleichbleibenden Iterationslänge sieht. Anders ist dies in Scrum: Scrum-Sprints haben feste Iterationslängen. Ken Schwaber beschreibt das Einführen von festen Sprintlängen als Reduktion der Komplexität des Projekts für das Team: Das Team muss nur eine feste Zeitdauer überblicken, um zum nächsten Ziel zu kommen. Schritt für Schritt wird es mit der zunehmenden Komplexität im Projekt fertig (Schwaber 2004). Dabei hat sich eine fixe Sprintlänge, die 30 Tage nicht überschreiten sollte, bewährt (Timeboxing). Das Team vereinbart gemäß der Sprintlänge einen Endtermin mit dem Product Owner. Dieser Endtermin muss eingehalten werden. Allerdings darf das Team auf dem Weg zum Endtermin auch nicht gestört werden. 5.2.2.2 Anfang des Sprints – die Sprint-Planungssitzung Zu Beginn des Sprints findet die Sprint-Planungssitzung statt. Der Product Owner muss ein Sprint-Ziel definieren. Es muss ein Schritt in Richtung Projektziel sein und einen Nutzen für das Projekt bringen. Der Product Owner muss das Sprint-Ziel so definieren, dass es für das Team klar erkenntlich ist. Das Team verpflichtet sich zur Umsetzung des Ziels und der damit verbunden Features der Software. Nach der Sitzung kann der Product Owner für den laufenden Sprint keine Änderungen des Ziels mehr vornehmen. Es gilt also, das Ziel mit Bedacht zu wählen. Der Product Owner definiert entsprechend dem Product Backlog und dem zuvor erstellten Releaseplan91 die Anforderungen an das Produkt, die im aktuellen Sprint realisiert werden sollen. Dabei spielt die Priorisierung einer Anforderung im Product Backlog naturgemäß eine große Rolle. Wichtig ist auch, dass im Vorfeld geklärt wurde, ob diese Anforderungen problemlos zu erfüllen sind.92 Dies kann durch den Product Owner und ausgewählte Teammitglieder erfolgen. Dazu gehört auch eine vernünftige Abschätzung des Aufwands für die Realisierung einer Anforderung. In der Sprint-Planungssitzung erstellt das Team gemäß Sprint-Ziel und vom Product Owner ausgewählten Anforderungen das Sprint-Planungsdokument, das Sprint Backlog. Hier werden alle Features des nächsten Inkrements der Software identifiziert, die im Sprint realisiert werden sollen. Ebenso werden alle Aktivitäten identifiziert, die notwendig sind, um das Inkrement zu realisieren. Es empfiehlt sich auch hier ein iteratives Vorgehen – eine schrittweise Verfeinerung der durchzuführenden Aktivitäten und der Schätzung des benötigten Aufwands bei gleichzeitiger Präzisierung der vom Product Owner „bestellten“ neuen Features der Software.93

91 Der Releaseplan dient der Information, wann welches Feature der Software zu erwarten ist (Kap.

5.3.3). 92 Sollten

die Zweifel technischer Natur sein, muss ggf. vorab ein technischer Prototyp erstellt werden. (Vorsicht, das Erstellen eines Prototyps muss als zusätzliche Anforderung in das Product Backlog eingetragen werden). 93 Aus der Erfahrung des Autors empfiehlt sich hier der Einsatz von User Story Cards (bekannt von XP). Siehe hierzu auch Kap. 5.3.2 und Kap. 3.

5.2

Scrum – der Prozess

71

Sowohl Product Owner, als auch Team und ScrumMaster müssen in der Planungssitzung die ganze Zeit anwesend sein: Der Product Owner, um dem Team Rede und Antwort stehen zu können, der ScrumMaster, um die Selbstorganisation des Teams zu überwachen. Die Planungssitzung endet, wenn die dafür angesetzte Zeit (oft nicht mehr als ein Tag) abgelaufen ist. Als Ergebnis der Sprint-Planungssitzung muss ein realistisches Sprint Backlog vorliegen. Die Anforderungen, zu deren Realisierung sich das Team verpflichtet hat, müssen mitsamt den zugehörigen Aktivitäten definiert und abgeschätzt sein (Kap. 5.3.2). 5.2.2.3 Daily Scrum Jeden Tag am selben Ort zur selben Zeit findet eine Teambesprechung statt, die Daily Scrum genannt wird. Sie darf nur 15 Minuten dauern (Schwaber 2004),94 das Team und sein ScrumMaster müssen anwesend sein. Die Anwesenheit des Product Owners ist nicht zwingend erforderlich. Wenn es seine Zeit erlaubt, sollte er allerdings anwesend sein. So kann er aus erster Hand erfahren, was das Team umtreibt. Allerdings sind diese Sitzungen nicht dazu gedacht, dass der Product Owner versucht, den Ablauf des Sprints zu beeinflussen. Gäste sind im Daily Scrum erlaubt, insbesondere alle vom Projekt Betroffenen, sie haben aber kein Rederecht. Das Ziel des Daily Scrums ist es, die Arbeit des Teams zu koordinieren (Selbstorganisation!) und auftauchende Probleme anzusprechen. Dazu muss das Sprint Backlog aktualisiert sein. Das Team muss im Daily Scrum über den Status quo des Projekts informiert sein! In Anbetracht der Kürze des Daily Scrums sollte jedes Teammitglied nur Antwort auf folgende drei Fragen geben (Schwaber 2004): • Was habe ich seit dem letzten Daily Scrum für das Projekt getan? • Was will ich bis zum nächsten Daily Scrum für das Projekt tun? • Was hindert mich daran, so effektiv wie möglich zu arbeiten? Der ScrumMaster ist verantwortlich, dass diese Fragen von jedem Teammitglied beantwortet werden, ohne dass das Team in (endlose) Diskussionen verfällt. Etwas psychologisches Geschick ist angebracht um zu erkennen, wo es um persönliche Befindlichkeiten Einzelner und wo es um wirkliche Probleme geht, die dann in der Regel auch andere Teammitglieder behindern. Kleinere Probleme kann das Team ggf. nach dem Daily Scrum gleich lösen. Komplexere Probleme müssen aufgezeigt und an ScrumMaster oder Product Owner weitergegeben werden. Es ist wichtig, dass diese die gemeldeten Probleme ernst nehmen und wissen, dass ungelöste Probleme die Leistung des Teams in der Regel mindern.

94 Der Autor hat gute Erfahrungen mit Standup Meetings gemacht, also Sitzungen, die im Stehen (oft an der Kaffeemaschine) abgehalten werden. Solche Sitzungen bleiben in der Regel kurz!

72

5

Scrum

5.2.2.4 Ablauf des Sprints Scrum ist eine reine Managementmethode und macht folglich dem Team keine Vorgaben bezüglich der angewandten Entwicklungspraktiken. Es ist allerdings sinnvoll, Praktiken, die man von anderen agilen Methoden kennt, wie z.B. von XP (Kap. 3), anzuwenden. Wichtig ist, dass das Team im Sprint ohne Störung von außen entwickeln kann. In der Zeit des Sprints sind die Anforderungen eingefroren. Sie dürfen nicht geändert werden. Nur so hat das Team eine Chance, den anvisierten Endtermin zu halten. Am Endtermin ist der Sprint fertig, die Ergebnisse müssen dem Product Owner präsentiert werden. 5.2.2.5 Ende des Sprints – Sprint Review Am Ende des Sprints steht das Sprint Review. Der Product Owner bekommt die Möglichkeit, das entstandene Software-Inkrement zu prüfen und abzunehmen. Die Sprint Review-Sitzung ist auf maximal vier Stunden beschränkt (Timeboxing, Schwaber 2004). Wichtig ist, dass der Product Owner nur vollständige und fehlerfreie Arbeitsergebnisse akzeptiert. Auch fast fertige oder fehlerhafte Ergebnisse werden nicht akzeptiert, unvollständige Resultate gelten als nicht erledigt. Solche Ergebnisse werden z.B. im Product Backlog festgehalten und Gegenstand des nächsten Sprints. Ziel ist, sie möglichst schnell (im nächsten Sprint) in Ordnung zu bringen, um das aktuelle Inkrement der Software zu vervollständigen. Das vom Team entwickelte Inkrement der Software muss auf einem zentralen Integrationsrechner in Form einer Live-Demo präsentiert werden. Der Product Owner sollte selbst Tests an der Software durchführen können und sich von der (aus seiner Sicht) korrekten Funktionsweise der Software überzeugen. Nur der Product Owner entscheidet, ob das Ergebnis akzeptiert wird oder nicht! Auf keinen Fall darf der Product Owner einzelne Ergebnisse auf lokalen Rechnern akzeptieren. Der Autor hat die Erfahrung gemacht, dass die Integration solcher Ergebnisse auf einem Rechner keine Trivialität ist (Kap. 6.4) und in der Regel nur mit entsprechendem Aufwand zu realisieren ist. Somit gehört die Integration klar mit zum Sprint und muss am Ende erfolgreich abgeschlossen sein. Neben Product Owner und Team muss auch der ScrumMaster am Sprint Review teilnehmen. Seine Aufgabe ist es, die Sitzung zu moderieren. Interessant ist es außerdem, Endanwender der Software dabeizuhaben. Von ihnen können wertvolle Tipps und Ideen für die Weiterentwicklung der Software kommen. Es erhöht die Akzeptanz der Software ungemein, wenn der Endanwender regelmäßig das Wachsen der Software mitverfolgen kann. 5.2.2.6 Sprint Retrospektive Die Sprint Retrospektive schließt direkt an das Sprint Review an. Auch diese Besprechung ist in ihrer Dauer beschränkt. Ken Schwaber fordert eine maximale Länge von drei Stunden (Schwaber 2004). Die Sprint Retrospektive gibt dem Team

5.3

Scrum-Artefakte

73

Gelegenheit, über den Ablauf des Sprints nachzudenken, insbesondere über die Zusammenarbeit im Team und über notwendige Verbesserungsmaßnahmen. Diese bilden die Grundlage für den nächsten Sprint.95 Oftmals geht um die Einführung, Abschaffung oder Veränderung agiler Praktiken, die das Team für sinnvoll oder eben nicht mehr für sinnvoll hält (Kap. 6). Teilnehmer der Sprint Retrospektive sind zwingend das Team und der ScrumMaster. Die Teilnahme des Product Owners ist optional. Die Erfahrung zeigt aber, dass sein Verständnis für das Team mit der Teilnahme an der Sprint Retrospektive wächst. Die Aufgabe des ScrumMasters ist es, die vom Team vorgeschlagenen Veränderungen zu sammeln und zu notieren. Es ist nicht seine Aufgabe, dem Team Lösungen aufzuzeigen. Er hat also die Rolle eines Moderators inne! Das Team priorisiert die vorgeschlagenen Veränderungen und bespricht sie in dieser Reihenfolge. Veränderungen, die gemeinsam beschlossen werden, werden im nächsten Sprint umgesetzt. Das Ziel der Sprint Retrospektive ist die Optimierung des Prozesses. Angesprochene Probleme, die zu keinen Veränderungen führen, sind frustrierend und unterhöhlen die Akzeptanz der Sprint Retrospektive. Warum soll man auch Zeit für eine Verbesserungssitzung opfern, wenn keine Verbesserung dabei heraus kommt!

5.3 Scrum-Artefakte Die wichtigsten Scrum-Artefakte (Dokumente) sind das Product Backlog, das Sprint Backlog und der Releaseplan mit Burndown Chart. Die Backlogs sind Planungsinstrumente, während der Releaseplan der Information dient, wann welches Feature der Software zu erwarten ist. Die Burndown Chart dient der Überwachung des Projektfortschritts.

5.3.1 Product Backlog Das Product Backlog ist das zentrale Dokument zum Erfassen und Verwalten von Anforderungen. Das Product Backlog verwaltet Items – die zu liefernden Funktionalitäten. Ein typisches Product Backlog zeigt Abb. 5.3. Nachdem die Funktionalitäten im Product Backlog gesammelt wurden,96 werden sie priorisiert, und der Realisierungsaufwand wird geschätzt. Dies geschieht durch den Product Owner (idealerweise mit Hilfe des Teams). In der Praxis hat sich auch die elektronische Darstellung des Product Backlogs bewährt. Dies kann mit Hilfe eines gängigen Bugtracking-Tools geschehen (Abb. 5.4). Wichtig dabei ist, dass das Product Backlog für alle Teammitglieder, den Product Owner und den ScrumMaster deutlich sichtbar, z.B. auf einen großen 95 Dies

ist natürlich keine Erfindung von Scrum, bei Crystal heißt dieses Meeting ReflexionsWorkshop (Kap. 4). 96 Eine Funktionalität ist üblicherweise eine Zeile im Product Backlog!

74

5

Scrum

Abb. 5.3 Typisches Product Backlog für ein Newsletter-Versandsystem

Abb. 5.4 Product Backlog in elektronischer Form

LCD-Schirm im Team-Büro dargestellt wird. Ist dies nicht der Fall, ist es nicht möglich, „schnell im Vorbeigehen“ einen Blick auf den Gesamtstand des Projekts zu werfen.97 In elektronischer Form abgespeichert können die Items auf einfache Art und Weise beim Sprint in das Sprint Backlog übernommen werden. 97 Das

hat sich im studentischen Labor des Autors als klarer Nachteil herausgestellt. Das Team neigt dann dazu, die Projektsituation zu positiv zu beurteilen, wenn nicht alle Beteiligten ständig den aktuellen Gesamtstand vor Augen haben.

5.3

Scrum-Artefakte

75

5.3.2 Sprint Backlog Das Sprint Backlog ist eine Liste der Aktivitäten, die das Team innerhalb eines Scrum-Sprints abarbeiten muss. Es dient dem Team zur Organisation des Sprints. Das Sprint Backlog ist das Resultat der Sprint-Planungssitzung (Kap. 5.2.2). In der Planungssitzung teilt der Product Owner dem Team sein Sprint-Ziel mit. Er identifiziert die Anforderungen im Product Backlog, die das Team erfüllen muss. Das Team verpflichtet sich zum Erreichen des Sprint-Ziels und, damit verbunden, zur Umsetzung der vom Product Owner identifizierten Anforderungen aus dem Product Backlog. Nachdem die dem Sprint-Ziel zugeordneten Anforderungen identifiziert wurden, werden sie in das Sprint Backlog aufgenommen.98 Ihr Aufwand ist spätestens zu diesem Zeitpunkt üblicherweise in Personenstunden abgeschätzt. Er sollte vier bis 16 Stunden nicht überschreiten (Schwaber 2004). Sind aus dem Product Backlog Anforderungen übernommen worden, deren Aufwand größer ist, müssen sie in mehrere, kleinere (Teil-) Anforderungen zerlegt werden. Damit geht eine Präzisierung der Anforderungen einher. Kleine „Arbeitspakete“ können besser überwacht werden. Das Team weiß zu jedem Zeitpunkt über den Status jedes Sprint Backlog Items (also jedes Arbeitspakets) Bescheid. Es ist sinnvoll, die Sprint Backlog Items als User Stories darzustellen.99 Wie bei XP (Kap. 3) können diese dann als Einzelpapiere (z.B. Din A5 quer) an eine Pinwand gehängt werden. Das Sprint Backlog in Listenform enthält dann nur noch eine Kurzzusammenfassung der Items, um den Überblick zu wahren (Abb. 5.5). Das Sprint Backlog ist ein „lebendes“ Dokument. Es wird täglich, idealerweise vor dem Daily Scrum, angepasst und spiegelt damit jederzeit den aktuellen Status des Sprints wider. Wird das Sprint Backlog als User Stories an einer Stellwand realisiert, kann das tägliche Update besonders einfach durchgeführt werden. Unerledigte User Stories sollten links und erledigte rechts an der Stellwand aufgehängt werden. Noch besser wäre es, zwei farblich unterschiedliche Stellwände zu benutzen.

5.3.3 Releaseplan und Burndown Chart Für größere Projekte empfiehlt sich das Schreiben eines Releaseplans. Dies ist Aufgabe des Product Owners. Im Releaseplan wird die Abfolge der Sprints, also der Iterationen des Projekts, geplant. Inkrement für Inkrement nähert sich das SoftwareProdukt der endgültigen Lösung. Dem Releaseplan kann entnommen werden, wie viele Sprints benötigt werden, oder in welchem zeitlichen Rahmen das Projekt voraussichtlich stattfinden wird.

98 Im Product Backlog ist der Aufwand für die einzelnen Anforderungen bereits geschätzt worden. 99 Siehe

auch (Wirdemann 2009).

76

Abb. 5.5 Sprint Backlog als User Stories an einer Stellwand

Abb. 5.6 Release Burndown Chart

5

Scrum

Literatur

77

Interessant ist die Überwachung der Releaseplanung mit Hilfe der Release Burndown Chart.100 Hier wird pro Sprint der insgesamt verbleibende Aufwand im Projekt dargestellt (Abb. 5.6). Eine Releaseplanung ist in agilen Projekten nicht unumstritten. Wie passt diese Gesamtplanung zu einem agilen Ansatz, der ja gerade den Anspruch hat, wechselnden Anforderungen, sog. „Moving Targets“ (Kap. 3), folgen zu können. Die Antwort liegt in Scrum selbst: Während ein Sprint nicht unterbrochen werden darf, d.h. auch die Anforderungen des Sprints nicht verändert werden können (Kap. 5.2), kann das zwischen den Sprints durchaus passieren. Aus geänderten Anforderungen folgt zwangsläufig eine Anpassung des Releaseplans. Dies findet aber erst beim nächsten Sprint Beachtung (und eben nicht im aktuellen Sprint!).

Literatur Cockburn A (2005) Crystal Clear – Agile Software-Entwicklung für kleine Teams. Bonn: MITPVerlag Gloger B (2009) Scrum – Produkte zuverlässig und schnell entwickeln. München: Hanser Pichler R (2008) Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg: dpunkt Verlag Schwaber K (2004) Agile Project Management with Scrum. Washington, DC: Microsoft Press Wirdemann R (2009) Scrum mit User Stories. München: Hanser

100 engl.

burn down = abbrennen

Kapitel 6

Experimentelles Software-Engineering im studentischen Labor

Im studentischen Software-Engineering-Labor der Dualen Hochschule Baden-Württemberg Lörrach führt der jeweilige studentische Jahrgang (Kurs genannt) gemeinsam als Team ein Software-Projekt durch. Dabei werden insbesondere Fragen zu agilen Projektpraktiken und deren Erfolg in der Praxis beantwortet. Somit können aus der Literatur bekannte agile Prozessmodelle auf den Prüfstand gestellt werden. In diesem Zusammenhang stellt sich dem Autor die Frage, ob der Ansatz der Prozessmodelle überhaupt der richtige ist. Wird das Team dadurch nicht zu sehr eingeschränkt?

Das studentische Software-Engineering-Labor der Dualen Hochschule BadenWürttemberg Lörrach findet im Rahmen des technischen Informatik-Studiums statt. Der jeweilige studentische Jahrgang (Kurs genannt) führt gemeinsam als Team ein Software-Projekt durch. Damit ergibt sich die Zahl der Team-Mitglieder naturgemäß aus der Zahl der Studierenden plus Dozent. In ca. 60 Kursstunden arbeiten bis zu 20 Team-Mitglieder am Projekt mit. Pro Kurs ergeben sich so effektiv bis zu 800 Projektstunden. Das IT-Labor besteht in dieser Form seit 2004. Der Autor übernimmt dabei als Dozent die Rolle des Kunden (und ab und zu des Beraters), die Rollen Projektleiter und Qualitätsmanager werden entweder von ihm bestimmt oder vom Team gewählt (Hanser 2006). Neben dem vordergründigen Ziel, eine den Spezifikationen entsprechende stabile Software zu entwickeln, werden jedoch auch tiefer gehende Fragen zur Projektorganisation beleuchtet: (1) Gibt es agile Projektpraktiken, die nicht ohne Intervention eines (Projekt-) Managements funktionieren? Welche agilen Praktiken sind kein Resultat der Selbstorganisation des Teams? Hier wird insbesondere die in Kap. 3.5 beschriebene Gruppe von XP-Praktiken untersucht, die – wie bereits erwähnt – Anlass zu Diskussionen gibt. (2) Die praktische Erfahrung zeigt, dass Teams mit mehr als etwa fünf Mitgliedern sich in „Mini-Teams“ unterteilen: • In XP wird ein solches Mini-Team „Paar“ genannt. Es besteht aus zwei Mitgliedern. Sind diese Paare in der Realität erfolgreich? • Gibt es eine ideale Größe (größer als zwei) für erfolgreiche Mini-Teams? E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, eXamen.press, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_6, 

79

80

6 Experimentelles Software-Engineering im studentischen Labor

• Wie sieht die Mitgliederstruktur einen solchen (erfolgreichen) Mini-Teams aus? Anlass zu dieser Fragenstellung geben neben den persönlichen Erfahrungen des Autors auch diverse Beiträge in der Literatur. Es ist bekannt, dass das „Initialprojekt“ von XP, das in Kap. 3 erwähnte Chrysler C3 Projekt, nicht erfolgreich endete. Nur in der ersten Phase bis 1997 war es ein Erfolg. Im weiteren Projektverlauf geriet es immer mehr in Schwierigkeiten und wurde 1999 eingestellt. Kent Beck gibt selbst zu, dass auch XP kein Garant für einen erfolgreichen Projektverlauf ist (Fowler 2005, Beck 2009). Auch Alistair Cockburn, der Begründer der Methodenfamilie Crystal (Kap. 4), äußert sich kritisch. Bekannt ist in diesem Zusammenhang die XP-Karikatur auf seiner Web-Site, die zwei Programmierer vor einem Bildschirm zeigt und an Edvard Munchs Gemälde „Der Schrei“ erinnert (Cockburn, 2008). Der Autor fragt sich in diesem Zusammenhang immer mehr, ob der Ansatz der Prozessmodelle überhaupt der richtige ist. Wird das Team dadurch nicht zu sehr eingeschränkt? Dazu mehr in Kap. 7.

6.1 Die Projekte im studentischen Labor Von 2004 bis 2008 wurde im studentischen Labor des Autors eine E-Mail-Marketing Software entwickelt. Aus einer unterliegenden Datenbank werden NewsletterInhalte ausgelesen und personalisiert an Abonnenten verschickt, die sich zuvor für den entsprechenden Newsletter angemeldet haben. Die Software verfügt über eine webbasierte grafische Benutzeroberfläche und ein Administrationsinterface. In den Abb. 6.1 bis 6.2 sieht man einige Eingabemasken des Newsletter-Systems. Das System ist mittlerweile nach über 3.000 Projektstunden funktionsfähig und mit Hilfe des Mono-Projekts auf Linux-Server portiert. Das Projekt wurde 2008 abgeschlossen. 2009 wurde im Rahmen einer Exkursion für einen realen Kunden aus dem Bereich der Berufsqualifizierung eine Raumplanungs-Software für Gruppen mit körperlich Behinderten realisiert (Abb. 6.3). Das Projekt ging über acht volle Arbeitstage mit einem Team aus Product Owner, ScrumMaster101 und einem zehnköpfigen Team.102 Davon wurden drei Tage im Rahmen einer Exkursion beim Kunden geleistet. Dieses studentische Projekt fand im Rahmen des Studiengangs Life Science Informatik (Angewandte Informatik) statt.

101 Diese 102 Dies

Rolle wird vom Autor übernommen. entspricht in etwa 600 Projektstunden.

6.1

Die Projekte im studentischen Labor

Abb. 6.1 Newsletter-System, Login-Maske

Abb. 6.2 Newsletter-Editor

81

82

6 Experimentelles Software-Engineering im studentischen Labor

Abb. 6.3 Raumplanungs-Software „TeRaPlan“

6.2 Randbedingungen der studentischen Sessions Jede Session des IT-Labors wird vom Dozenten unter gewisse Randbedingungen gestellt. Somit können gezielt Fragestellungen beleuchtet werden, die sich aus dem Umgang mit Agilen Prozessmodellen ergeben. Diese Randbedingungen resultieren auch aus den Erfahrungen der vorigen Jahre. Insbesondere werden in den bisher sechs Sessions verschiedene agile Prozessmodelle „ausprobiert“: • 2004 steht kein spezielles agiles Prozessmodell im Vordergrund. Das Team soll, ausgehend vom Agilen Manifest, seinen eigenen agilen Prozess entwickeln. • 2005 soll das Team XP praktizieren. Der tatsächliche agile Prozess weicht schließlich davon ab. • 2006: Ausgehend von einem agilen Ansatz entwickelt sich ein hierarchischer Prozess. Interessant ist, dass der Projektleiter, der diesen Prozess etabliert, zuvor vom Team gewählt wurde. • 2007 soll das Team Crystal praktizieren. Wie schon 2005 weicht auch hier der tatsächliche agile Prozess ab. • 2008: Startprozess ist wiederum XP. Auch hier wird der agile Prozess abgewandelt und angepasst. • 2009: Startprozess ist erstmalig Scrum. Auch diese agile Managementmethode wird angepasst bzw. erweitert. Erstmalig wird für einen „realen“ Kunden außerhalb der Hochschule entwickelt. Das Projekt ist sehr erfolgreich.

6.2

Randbedingungen der studentischen Sessions

83

Interessant ist insbesondere die Veränderung der Randbedingungen zwischen den ersten beiden Sessions des studentischen Labors. In der folgenden Tabelle 6.1 sind die Randbedingungen der Jahre 2004 und 2005 einander gegenübergestellt: Wie sind die unterschiedlichen Erfolge der beiden Sessions erklärbar? Was sind die notwendigen „Zutaten“ für ein erfolgreiches Projekt? Natürlich spielt die Stärke der Teammitglieder eine große Rolle, aber in beiden Jahrgängen waren starke Programmierer. Der Schlüssel zum Erfolg muss also auch maßgeblich in der Organisation des Teams liegen. Um dies zu untermauern sollen zunächst die Rollen des Projektmanagers und des Qualitätsmanagers beleuchtet werden. Machen diese

Tabelle 6.1 Jahr 2004 vs. 2005

IT-Labor der DHBW Lörrach

Session 2004

Session 2005

Vorbedingungen

Der Dozent besetzt die Positionen Projektmanager und Qualitätsmanager mit geeigneten Studierenden.

Der Dozent besetzt die Positionen Projektmanager und Qualitätsmanager mit geeigneten Studierenden.

Das restliche Team (Kurs) wird anfangs in Dreiergruppen (Mini-Teams) eingeteilt.

Team (Kurs) ist anfangs unstrukturiert, erhält aber den Auftrag, Mini-Teams in Form von XP-Paaren zu bilden.

Die Teammitglieder haben Hintergrundwissen zum Thema Prozessmodelle, speziell zum Thema Agile Programmierung.

Die Teammitglieder haben Hintergrundwissen zum Thema Prozessmodelle, speziell zu Extreme Programming (XP).

Der Kunde (der Dozent) ist Teammitglied.

Der Kunde (der Dozent) ist Teammitglied.

Entwicklungsplattform

Microsoft Visual Studio.NET 2003

Microsoft Visual Studio.NET 2003

Projektziel

Erfolgreiches Produkt, erfolgreiches Projekt.

Erfolgreiches Produkt, erfolgreiches Projekt.

Business Logik und grafische Benutzeroberfläche sollen von konkurrierenden Mini-Teams jeweils in C# und Visual Basic entwickelt.

Gemeinsame Implementierung eines voll einsatzfähigen E-Mail-Marketing-Systems in C#.

Das Team soll sich einen geeigneten Agilen Prozess wählen.

XP wird vom Dozenten gefordert.

Nur die Minimalanforderungen an Produkt und Prozess werden erfüllt.

Am Ende ein erfolgreiches Produkt und ein erfolgreicher Prozess.

Erfolg der Session

84

6 Experimentelles Software-Engineering im studentischen Labor

klassischen Projektrollen in einer agilen Umgebung noch Sinn bzw. wie verändern sie sich?

6.3 Veränderung der klassischen Projektrollen in agilen Projekten Die klassischen Projektrollen sind Projektmanager und Qualitätsmanger. Insbesondere diese Rollen machen in agilen Projekten eine Veränderung durch.

6.3.1 Der Projektmanager im agilen Projekt Der „klassische“ Projektmanager führt sein Team und überwacht den Projektfortschritt. Er/sie erstellt das Projekthandbuch, welches das Projekt beschreibt, und den Projektplan für Aufwand, Zeit und Ressourcen. Der Projektmanager stellt die Weichen für ein erfolgreiches Projekt. In einem agilen Projekt ist diese klassische Projektrolle jedoch nicht eindeutig definiert. Also wurde im studentischen Labor 2005 beschlossen, dass ein Student diese Rolle übernehmen sollte, um seine Rolle im agilen Team neu zu definieren. Der damalige Projektmanager beschreibt seine Rolle wie folgt (Hanser et al. 2006):

„In einem agilen Projekt ist die Rolle des klassischen Projektmanagers eigentlich nicht definiert. Das Team sollte sich selbst führen. Jedes Mitglied ist für alle Bereiche mitverantwortlich. Dieser Umstand wird auch durch die fünf Werte von XP gefestigt. Allerdings war dieses Projekt aus Sicht von XP etwas Besonderes: Die Anzahl der Projektmitglieder lag deutlich über zwölf. Der Kunde hatte konkrete Vorstellungen bezüglich des Funktionsumfangs, während sich die Teammitglieder erst in die Materie einarbeiten mussten. Somit kamen vom Kunden keine bis wenige Änderungswünsche, während das Verständnis der Teammitglieder erst mit der Zeit wuchs. Schon zu Projektbeginn wurde deshalb der XP-Ansatz ein erstes Mal angepasst. Aus diesen Anpassungen erfolgte eine erste Definition der Rolle des Projektmanager: 1. Erstellen kurzer User Stories. 2. Koordination des Teams bis alles in geordneten Bahnen verläuft (jeder auf XP eingeschworen ist). 3. Überwachung des Gesamtprojekts.

6.3

Veränderung der klassischen Projektrollen in agilen Projekten

Ziele in der ersten Projektphase: 1. Durchführung einer Teamschulung zur Verbesserung der Programmierkenntnisse. 2. Aufteilung des Gesamtprojektes in ca. drei Wochen dauernde Iterationsschritte. 3. Erarbeiten der Grundlagen für das Projekt, unter anderem Designvorlagen für den Webauftritt und Festlegung der Datenbankstruktur. 4. Keine festen Regeln und Vorgehensweise vorgeben. In Zusammenarbeit mit dem Kunden wurden User Stories erarbeitet und morgens an einer Pinwand aufgehängt. Das Team sollte selbstständig Gruppen bestimmen und eine entsprechende User Story bearbeiten. Bei Unvollständigkeit einer Story sollte die Gruppe eigenständig mit dem Kunden oder dem Projektmanager eine neue User Story entwickeln bzw. verbessern und an die Pinwand hängen. Das Team sollte das Projekt somit selbstständig leiten. Probleme in der ersten Projektphase: 1. Der unterschiedliche Programmierlevel der Teammitglieder führte aus der Sicht des Qualitätsmanagements entweder zu sehr guten oder sehr schlechten Realisierungen einzelner User Stories. Um ein qualitativ gutes Endprodukt zu erhalten, mussten einzelne Gruppen somit vergrößert werden. 2. Mangelnde Kommunikationsbereitschaft stellte eine nur sehr schwer überwindbare Hürde dar. Von den Gruppen festgestellte Einschränkungen für die Entwicklung von Formularen wurden nicht oder nur teilweise weiter kommuniziert und somit auch nicht von allen Gruppen eingehalten. Anfragen beim Kunden fanden nur seitens des Qualitätsmanagers bzw. des Projektmanagers statt. 3. Festgelegte Regeln wurden nicht beachtet und von „Collective Code“ konnte nicht die Rede sein. Nach ein paar Wochen erfolgte die Ernüchterung im Team, als festgestellt wurde, dass sehr viel „Müll“ entwickelt wurde. Daraufhin wurde eine Neudefinition der Rolle des Projektmanagers (PM) festgelegt: 1. Der PM wurde zum Kommunikationsmanager zwischen den einzelnen Gruppen und stellte sicher, dass wichtige Informationen zwischen den einzelnen Gruppen weitergegeben wurden. 2. Der PM unterstützte die Herstellung des Kontaktes zwischen den Teammitgliedern und dem Kunden.

85

86

6 Experimentelles Software-Engineering im studentischen Labor

3. Dadurch ergab sich der Übergang zu einem klassischen Projektleiter, d.h. mehr Vorgaben (User Stories dürfen dem Entwickler nicht mehr so viele Freiheiten überlassen). Ziele der zweiten Phase: 1. Scheitern des Projektes verhindern. 2. Erste Iteration „endlich“ zum „Laufen“ zu bekommen. 3. Teammitglieder wieder motivieren. Ergebnis der zweiten Phase: Wichtige Module nahmen konkrete Form bzw. Funktionalität an. Die Stimmung im Team entwickelte sich positiv. Teammitglieder passten Regeln an, so wurde z.B. ab jetzt ein Stand-up Meeting zur Verbesserung der Kommunikation eingeführt. In diesem berichtete jedes Team über Erfolge und Probleme bei der Bearbeitung einer User Story. Weiterhin wurden Änderungswünsche des Kunden an User Stories von den einzelnen Teammitgliedern selbst geplant und durchgeführt. Zu diesem Zeitpunkt führte das Team „seine“ Form von XP sehr erfolgreich durch. Es zeigte sich aber auch, dass die Produktivität nicht in allen Gruppen gleich hoch war, so wurden die schwierigen Module sehr gut, einfache Module weiterhin eher mangelhaft umgesetzt, was durch die inhomogene Teamstruktur zu erklären war. (Gute Leute reizen eben die schwierigen Themen.) In der letzten Phase des Projektes ging es auf die Diplomklausuren zu und somit sank die Anzahl der Teammitglieder. Die Produktivität litt unter diesem Umstand aber nicht, da nun eine überschaubarere Anzahl von Teams vorhanden war. In dieser Phase wurde zur Dokumentation ein Projekt-Wiki eingeführt, welches von den einzelnen Teammitgliedern sehr gut angenommen wurde. In diesem wurde jeglicher Quellcode kurz erläutert und auf eventuelle Besonderheiten aufmerksam gemacht. Diese Dokumentation war überall online verfügbar und erleichterte die Zusammenarbeit. Nur der Einführungstermin erfolgte zu spät. Eine frühere Einführung hätte schon früher manche Unstimmigkeit beseitigen können. Das Integrieren der einzelnen Teilprojekte auf der Zielplattform stellte unerwartete Schwierigkeiten dar. Deshalb musste für diesen Job ein sehr guter Programmierer abgestellt werden. Die mangelhafte Einhaltung von Qualitätsmanagementregeln führte dazu, dass es nicht möglich war, Quellcode einer Gruppe ohne größeren Aufwand auf einem anderen PC zu kompilieren bzw. zu integrieren. Aufgrund der so verlorenen Zeit war es nicht möglich, alle Module zur vollsten Zufriedenheit zu implementieren. Als Ersatz musste hierfür auf Beta-Versionen zurückgegriffen werden.

6.3

Veränderung der klassischen Projektrollen in agilen Projekten

87

Am Ende wurden dem Kunden die grundlegenden Funktionen präsentiert„und das Projekt konnte als Erfolg gewertet werden.“

Es fällt auf, dass der Projektmanager 2005 (Abb. 6.4) das Projekt aus der Sicht von XP als besonderes Projekt einschätzt: Schon die Zahl der Teammitglieder größer als zwölf (es waren bis zu 20 Studierende) stellt erhöhte Ansprüche an die Kommunikation innerhalb des Teams. Die mangelnde Kommunikationsbereitschaft wird auch explizit als ein Problem der ersten Projektphase erwähnt. Mangelnde Disziplin und unterschiedliche Programmierkenntnisse der Teammitglieder erschweren die Etablierung des agilen Prozesses. Collective Code Ownership wird nicht beobachtet (zumindest nicht auf freiwilliger Basis). Erst durch eine Neudefinition der Rolle des Projektmanagers durch das Team werden die schlimmsten Probleme ausgeräumt. Der „neudefinierte“ Projektmanager • arbeitet als Kommunikationsmanager zwischen den einzelnen Programmierergruppen (Mini-Teams), • pflegt Kontakte zwischen den Teammitgliedern und dem Kunden, ist in diesem Zusammenhang auch ein maßgeblicher Co-Designer von User Stories, • motiviert die Mini-Teams bei Misserfolgen.

Abb. 6.4 Agiler Projektmanager (Mitte)

88

6 Experimentelles Software-Engineering im studentischen Labor

Der agile Projektleiter selbst empfindet das als Rückschritt gegenüber dem klassischen Projektleiter, der dem Team mehr und mehr Vorgaben macht und ihre Einhaltung überwacht. Die Erfolge der zweiten Projektphase zeigen jedoch die Effizienz dieses Wegs. Interessant sind noch folgende Beobachtungen des Projektleiters 2005: • Weniger Teammitglieder bedeutet nicht unbedingt weniger Produktivität des Teams. Es kommt auf die Performance des Teams an! • Dokumentation, z.B. mit Hilfe eines Projekt-Wikis, ist enorm hilfreich. Eine frühere Einführung hätte schon eher manche Unstimmigkeit beseitigen können. • Das Integrieren der einzelnen Teilprojekte auf der Zielplattform stellt unerwartete Schwierigkeiten dar und muss an einen sehr guten Programmierer delegiert werden. Dies führt zu Einführung einer entsprechenden Projektrolle, dem Integrationsingenieur (Kap. 6.4). Abschließend sei noch angemerkt, dass der Projektleiter 2005 aufgrund seiner überdurchschnittlichen Programmierkenntnisse auch als .NET-Experte auftritt und auch bei technischem Trouble-Shooting gefragt ist. Zusammenfassend lässt sich die Rolle des Projektmanagers wie folgt beschreiben: • • • • •

Koordinator des Projekts Problemlöser Kommunikator .NET-Experte Co-Designer von User Stories

6.3.2 Der Qualitätsmanager im agilen Projekt Die Rolle des Qualitätsmanagers, der im „klassischen“ Projekt die Projektqualität misst und verantwortlich ist für das Erstellen des Qualitätssicherungsplans, der Risikoanalyse und der Testpläne, ist im agilen Projekt nicht definiert. Wie im Fall des Projektmanagers wurde im studentischen Labor 2005 auch hier entschieden, dass ein Student die Rolle des Qualitätsmanagers übernehmen sollte, um seine neue agile Rolle individuell zu definieren. Der damalige Qualitätsmanger beschreibt seine Rolle wie folgt (Hanser et al. 2006): „Den klassischen Qualitätsmanger gibt es in einem agilen Projekt nicht. Was sind also seine Aufgaben in einem XP-Projekt? Zum Start des Projektes mussten alle Projektmitglieder auf XP ,eingeschworen‘ werden, denn keiner im Team wusste so richtig, was auf ihn zukommt, außer vielleicht, dass ,zu zweit‘ entwickelt wird. Es gab anfangs

6.3

Veränderung der klassischen Projektrollen in agilen Projekten

also viel Klärungsbedarf, wie genau das Projekt abzulaufen hat. Um es den Mitgliedern zu erleichtern, wurden feste Regeln definiert, wie im Projekt genau gearbeitet werden sollte. Neu war für alle, dass nach jeder User Story die Teams gewechselt werden mussten oder dass die Reviews zwischen zwei Teams gleichzeitig durchgeführt werden sollten, indem je ein Mitglied der einen Gruppe ein Review mit einem Mitglied der anderen Gruppe durchführt. Alle diese Regeln wurden auf großen Plakaten festgehalten, die an den Wänden des IT-Labor aufgehängt wurden. Die Probleme, die sich aus Sicht der Qualitätssicherung ergaben, waren, dass manche User Stories nicht zufriedenstellend implementiert wurden. Dies hatte vor allem zwei Gründe, zum einen wurde es den Teammitgliedern selbst überlassen, die Teams zusammenzustellen. Dadurch ergaben sich oft Teams mit zu unter-schiedlichem Know-how, sowohl, was die Programmierkenntnisse betraf, als auch die Kenntnisse des .NET-Frameworks. Zum anderen wurden von vielen Teams das Testen und die gegenseitigen Reviews als lästig empfunden, so dass diese wichtigen Tätigkeiten vernachlässigt wurden. Im Verlauf der Projektes nahm der XP-Qualitätsmanager neben den traditionellen Rollen eines Qualitätsmanagers, verantwortlich für das Testen, Reviews oder Code-Konventionen zu sein, aber auch andere Rollen ein, die sich sehr stark mit denen des Projektmanagers überschneiden. Durch den ständigen direkten Kontakt mit dem Kunden wirkt der Qualitätsmanager auch bei der Spezifikation der User Stories mit. Da die User Stories aber keine ausführliche Dokumentation, sondern nur eine MiniSpezifikationen in der Sprache des Kunden darstellen, ist er genauso wie der Projektmanager ein ständiger Anlaufpunkt für die Entwickler, um Fragen zum Hintergrund und zu den Details der Implementierung zu beantworten. Der Qualitätsmanager hat ähnlich wie der Projektmanager einen guten Überblick über den Stand und die Probleme innerhalb des Projektes. Oft übernimmt er auch die Funktion eines Problemlösers. Beispielsweise bei Problemen zur Implementierung oder Integration versucht er selbst mitzuhelfen oder koordiniert den weiteren Ablauf. An besonders wichtigen Aufgaben wie z. B. dem Datenbankdesign arbeitet er aufgrund seiner Erfahrung auch selbst mit oder überprüft das erarbeitete Konzept. An Stellen, wo XP nicht klappt, erarbeitet er zusammen mit dem Projektmanager neue Vorgehensweisen, ganz nach den Worten von Kent Beck ,Fix XP when it breaks‘. Insgesamt lässt sich feststellen, dass der Qualitätsmanager neben seinen traditionellen Tätigkeiten in einem XP-Projekt aber auch weitere Rollen annimmt, die sich teils sehr stark mit denen des Projektmanager überschneiden. Als Resümee für das gesamte Projekt lässt sich sagen, dass das Projekt nur pünktlich fertig wurde, weil XP so angepasst wurde, wie es speziell für das Team am besten war.“

89

90

6 Experimentelles Software-Engineering im studentischen Labor

Interessant ist, dass der Qualitätsmanager 2005 (Abb. 6.5) neben seinen „klassischen“ qualitätssichernden Aufgaben auch Aufgaben außerhalb der üblichen Rollenbeschreibung zu bewältigen hat. Im Grunde übernimmt er auch die Rolle eines Prozessverantwortlichen, der die anderen Teammitglieder in XP schult.103 In der Startphase des Projekts überwiegen allerdings die Aufgaben der Qualitätssicherung, wie z.B. • Schreiben des Qualitätssicherungsplans und der Risikoanalyse, • Entwickeln von Templates für Testpläne, • Definition und Verbreitung von Projektregeln und Code-Konventionen (Abb. 6.6), • Schulung im Ablauf eines Reviews und anfängliche Überwachung desselben. Im Verlauf des Projekts überschneiden sich die aus dem Projektverlauf entstehenden Aufgaben immer mehr mit denen des Projektmanagers:

Abb. 6.5 Agiler Qualitätsmanager (stehend)

103 Und dies, obwohl die anderen Studierenden XP auch bereits im Rahmen einer Vorlesung kennen

gelernt haben. Es gibt eben doch einen Unterschied zwischen Theorie und Praxis, nicht wahr?

6.3

Veränderung der klassischen Projektrollen in agilen Projekten

91

Abb. 6.6 Projektregeln als Plakate an der Wand (1)

• Durch den ständigen Kontakt mit dem Kunden gehört der Qualitätsmanager mit zum „Kernteam“, welches die User Stories entwickelt. Aus dieser Sicht wird deutlich, dass eben nicht alle Teammitglieder Interesse am Erstellen von User Stories haben! • Genauso wie der Projektmanager sieht sich auch der Qualitätsmanger als ständigen Anlaufpunkt für die Entwickler, um Fragen zu den User Stories zu beantworten. Da auch der Qualitätsmanager 2005 sehr gute Programmierkenntnisse hat, wird auch sein Know-how als .NET-Experte und seine Fähigkeiten als technischer Trouble-Shooter von den Mini-Teams gerne genutzt. Zusammenfassend lässt sich die Rolle des Qualitätsmanagers wie folgt beschreiben: • • • • • • • •

verantwortlich für Produkt- und Projektqualität Definieren von Projektregeln (Abb. 3.8, 6.6 und 6.7) Durchführen von Reviews Tester Problemlöser Kommunikator .NET-Experte Co-Designer von User Stories

Es ist bemerkenswert, dass beide Studenten ihre neue Rolle sehr ähnlich definieren. Sie unterscheiden sich nur im ersten Punkt, also im „klassischen Teil“ ihrer neuen agilen Projektrolle. Die meiste Zeit üben beide Studenten ähnliche Tätigkeiten aus: Sie bringen dem Team (agile) Projektregeln und unterstützten es bei der Durchführung, insbesondere bei der Kommunikation. Sie richten ein Wiki ein als

92

6 Experimentelles Software-Engineering im studentischen Labor

Abb. 6.7 Projektregeln als Plakate an der Wand (2)

zentrales, einfaches Archiv für Projektdokumentation. Sie überwachen die TeamStruktur und ändern ggf. die Struktur der XP-Paare. Im Rahmen des agilen Ansatzes „fixt“ das Team mit diesen beiden Kommunikationsmanagern an der Spitze XP zum ersten Mal und passt eine der XP-Praktiken an, indem die Selbstorganisation der Paare in Zukunft durch die beiden Kommunikationsmanger beeinflusst werden kann.

6.4 Neue Teamrolle – der Integrationsingenieur Der Weg zur erfolgreichen Software-Integration öffnet sich nicht von alleine. Negative Erfahrungen aus der ersten Session des studentischen Labors (2004), in der das Team seine Integrationsschritte selbst wählen konnte und dann erst am letzten(!) Tag integrierte, veranlassen den Kunden, in der Session 2005 Integrationszyklen von drei Wochen zu fordern. Die ist zwar deutlich mehr als in XP-Projekten üblicherweise festgelegt (Kap. 3.3.3), aber für ein junges Team immer noch anspruchsvoll. Selbst diese Integrationszyklen werden vom Team nicht selbstständig eingehalten. Kontinuierliche oder wenigstens konstante Integrationen scheinen für das Team keine Bedeutung zu haben. Jedes Mini-Team arbeitet an seiner eigenen Fragestellung. Massive Intervention des Kunden und ein mehr „klassisches“ Rollenverständnis des Projektmanagers (Kap. 6.3.1) verbessern die Situation. Die Rolle des „Integrationsingenieurs“ wird geschaffen und mit einem sehr guten, (aber) gerne alleine arbeitenden Software-Entwickler besetzt. Dieser „lone wolf“, der mit seinem Integrationsrechner immer etwas Abstand zum restlichen Team hat, integriert sehr erfolgreich. Durch die Besetzung dieser Position wird nach ca. fünf Wochen eine kontinuierliche Integration möglich (Abb. 6.8). Alle Sessions des IT-Labors haben dasselbe Ergebnis: Integration ist nicht das Resultat einer Selbstorganisation des Teams, sondern das Ergebnis einer zentralen Planung des Projektmanagers. Es darf nur einen Integrationsingenieur mit einem

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

93

Abb. 6.8 Integrationsingenieur als „lone wolf“

Integrationsrechner geben! Integration durch gleichberechtigte Paare, wie in XP vehement gefordert (Kap. 3.3.3), hat im studentischen Labor bisher nicht zum Erfolg geführt!

6.5 Veränderung agiler Praktiken und Prozesse in der Praxis Wie sich schon bei der Beschreibung der Veränderung der klassischen Projektrollen andeutet (Kap. 6.3), sind einige (insbesondere „berühmte“) agile Praktiken in der Praxis nicht haltbar bzw. müssen angepasst werden. Im Folgenden sollen die Resultate aus dem studentischen Labor dargestellt werden.

6.5.1 Design von User Stories In allen Sessions des studentischen Labors 2004 bis 2008 findet das Erstellen der User Stories kein breites Interesse bei den Team-Mitgliedern. Der Kunde wird als Team-Mitglied wenig zur Kenntnis genommen. Lediglich Projekt- und Qualitätsmanager (in ihrem neuen Rollenverständnis) und einige wenige Teammitglieder suchen

94

6 Experimentelles Software-Engineering im studentischen Labor

den Kontakt zum Kunden, um maximale Qualität und Verständnis der User Stories zu erreichen. Oftmals werden fertige User Stories „interpretiert“ ohne nachzufragen. Erst wenn Entwickler-Mini-Teams Verantwortung für eine User Story übernehmen, werden sie aktiv und machen ein detailliertes Low-Level-Design.

6.5.2 Collective Code Ownership Kollektive Verantwortung für den gesamten Code ist in allen Sessions im Team nicht sehr beliebt (siehe auch Erfahrungsbericht des Projektmanagers in Kap. 6.3.1). Außer Projekt- und Qualitätsmanager sind nur noch die wenigen Teammitglieder, die schon bei den User-Stories mitgewirkt haben, in der Lage, den gesamten Code zu verstehen – und nicht nur das vergleichsweise kleine Stück, das sie selbst entwickelt haben. Eine Bereitschaft für Collective Code Ownership ist bei keiner Session von 2004 bis 2008 erkennbar. Nur die Angst ernsthafte Fehler zu machen, die sich negativ auf das Produkt auswirken, veranlasst wenigstens die oben erwähnten Teammitglieder, kollektive Verantwortung für den Code „auszuprobieren“.

6.5.3 Mini-Team-Größe: Sind XP-Paare erfolgreich? Ein interessanter Parameter für ein Prozessmodell ist die Größe der „Untergruppen“ des Teams (Mini-Teams), in denen die einzelnen User Stories bearbeitet werden. In XP werden „Paare“ gefordert: Zwei Entwickler sitzen am selben Rechner, ein Entwickler denkt strategisch, der andere operativ (Kap. 3.4). Um die „Stabilität“ solcher Paare zu analysieren, werden in der Session 2004 zu Beginn Dreierteams gebildet, während in den Sessions 2005 und 2008 reine XP-Paare an den Start gehen. Interessant ist die Frage nach der Veränderung der Mini-Teamgrößen über die Zeit, wie sie in Tabelle 6.2 dokumentiert ist. Die Sequenz von Bildern (Abb. 6.9 bis 6.15) aus dem studentischen Labor 2005 zeigt den „Zerfall“ von XP-Paaren zugunsten von größeren Mini-Teams, aufgenommen vom Projektstart an, im Abstand von jeweils zwei Wochen. Somit scheint es, dass XP-Paare „instabil“ sind. Die Größe der Mini-Teams ändert sich ständig, je nach Aufgabenstellung. Es gibt nach den Erfahrungen des Autors keinen Grund für die Teamgröße 2, also für Paare. Bei übergreifenden Aufgaben, z.B. bei der Vorbereitung der Integration, ist auch eine Sechsergruppe keine Seltenheit. Und auch wenn sich Paare bilden, heißt das noch lange nicht, dass es sich um XP-Paare handelt. Oftmals bestehen „Paare“ aus einem stärkeren und einem schwächeren Partner, wo der erste die Struktur der Lösung erarbeitet, während der andere die Details erledigt. Um die interne Struktur von XP-Paaren in der Praxis besser zu verstehen, kann ein „glücklicher Umstand“ ausgenutzt werden: 2008 ist nach vier Jahren das erste studentische Labor mit drei stabilen XP-Paaren, die sich auch bewusst als solche

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

95

Tabelle 6.2 Vergleich Paarentwicklung über die Jahre 2004, 2005 und 2008

Session 2004

Session 2005

Session 2008

6 Mini-Teams mit 3 Mitgliedern zum Start.

9 XP-Paare als initiale MiniTeams.

6 XP-Paare als initiale Mini-Teams.

Im Verlauf des Projekts bilden sich keine XP-Paare spontan.

Die Zahl der XP-Paare nimmt ab.

3 XP-Paare „überleben“.

Die kleinste Teamgröße bleibt 3.

Die meisten Mini-Teams wachsen. Die Zahl der Mitglieder wächst auf 3, 4 und mehr.

50% der Teams sind XPPaare

Das erfolgreichste Mini-Team hat 4 Mitglieder („Super-Team“ 1).

In speziellen Phasen, z.B. in der Integration, gibt es Teamgrößen mit bis zu 6 Mitgliedern („Super-Team“ 2).

Integration: mehrere Paare bilden ein Integrationsteam.

Abb. 6.9 Session 2005, Projektstart: Man sieht drei XP-Paare. . .

verstehen. Diese XP-Paare werden angehalten, am Ende jedes Projekttags ein Formular auszufüllen, in dem festgehalten wird, mit welchen anderen Teammitgliedern oder Paaren sie zusammengearbeitet haben (Abb. 6.16). Man sieht sowohl im ausgefüllten Formular als auch auf den Fotos (Abb. 6.17 und 6.18), dass auch hier die Zusammensetzung meist mehr einem Dreier- oder Viererteam gleicht, als „klassischen“ XP-Paaren. Dies ist nicht verwunderlich: Auch

96

6 Experimentelles Software-Engineering im studentischen Labor

Abb. 6.10 . . .plus ein weiteres, also vier XP-Paare

Abb. 6.11 Session 2005, Projektstart: Man sieht bereits ein Damen-Triplett

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

97

Abb. 6.12 2 Wochen später: Man sieht drei XP-Paare. . .

Abb. 6.13 . . .aber auch bereits ein „Super-Team“, welches dem Integrationsingenieur zuarbeitet

98

6 Experimentelles Software-Engineering im studentischen Labor

Abb. 6.14 Vier Wochen später: nur noch ein „klassisches“ XP-Paar. . .

Abb. 6.15 . . .aber das Super-Team bleibt „stabil“

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

99

Abb. 6.16 Formular „Wechselwirkung zwischen zwei Paaren“ (2008) (Namen unkenntlich gemacht)

Abb. 6.17 Wechselwirkung zwischen zwei Paaren (hinten und vorne)

wenn sich stabile Paare bilden, arbeiten sie intensiv mit anderen Paaren zusammen, wobei sich manchmal Paare aufspalten, weil ein Partner für eine gewisse Zeit ein „Triplett“ mit einem anderen Paar bildet. Es kann sein, dass für diese Zeit ein Partner isoliert arbeitet. Dies ist aus der Auswertung des „Wechselwirkungsformulars“ eines typischen XP-Paars ersichtlich (Abb. 6.19). Fazit: XP-Paare sind in der Regel nicht stabil, sondern verändern ihre Struktur in Richtung größerer Mini-Teams, die sich für spezifische Aufgaben, z.B. Integration, bilden. Natürlich ist nicht ausgeschlossen, dass sich die Paare wieder „finden“ nachdem diese spezifische Aufgabe erledigt ist, wahrscheinlicher ist aber, dass sie „zerfallen“ (Abb. 6.9 bis 6.15). Fakt ist, dass nur in einer von fünf Sessions des studentischen Labors mehrere XP-Paare stabil waren und sich selbst auch als XP-Paare angesehen haben (Session 2008). „Klassische“ XP-Paare fordern eher ähnliche Typen, da beide Paar-Mitglieder sich abwechseln sollen im strategischen

100

6 Experimentelles Software-Engineering im studentischen Labor

Abb. 6.18 Kurzfristige Bildung eines Triplets

und taktischen Handeln. Besonders unter Männern fördert diese Konstellation Rivalitäten, die wiederum den Erfolg des Paars gefährden. Im Rahmen des studentischen Labors wurden gut funktionierende, gleichberechtigte XP-Paare außer in Session 2008 nach Beobachtung des Autors nur unter Studentinnen gefunden! Abbildung 6.19 kann durchaus auch als das „Innenleben“ eines erfolgreichen Vierer-Mini-Teams interpretiert werden. Nach Meinung des Autors ist die „zwanghafte“ Unterteilung erfolgreicher Miniteams in XP-Paare für den Erfolg eines Projekts nicht sinnvoll! Im folgenden Kapitel soll anhand der Phase der Software-Integration das Innenleben eines besonderen Mini-Teams näher beleuchtet werden.

6.5.4 Der Weg zur erfolgreichen Software-Integration XP fordert, dass jedes Paar seinen Code selbst integriert (Kap. 3.3.3). Allerdings kann dies nur durch ein Paar gleichzeitig geschehen. Wollen nun Paare zeitlich hintereinander ihren Code integrieren und bemerken sie gegenseitige Abhängigkeiten ihres Codes, beginnen sie miteinander zu kommunizieren: Welche Anpassungen müssen im jeweiligen, vom Paar programmierten Code durchgeführt werden, damit alles „zusammenpasst“, d.h. weder syntaktische noch semantische Probleme bei der Integration auftauchen. Die Paare rücken zusammen! Das Beispiel aus Session 2008 (Abb. 6.17, 6.18, and 6.19) zeigt, dass sich die Paare noch als solche verstehen, aber eng zusammenarbeiten. Das „Super-Team“ aus Session 2005 zeigt

Veränderung agiler Praktiken und Prozesse in der Praxis

101

Abb. 6.19 Wechselwirkung zwischen zwei Paaren (2008)

6.5

102

6 Experimentelles Software-Engineering im studentischen Labor

einen noch höheren „Verschmelzungsgrad“. Nach nur zwei Wochen Projekt bildet es sich aus (Abb. 6.13) und bleibt danach stabil (Abb. 6.15), was man unter anderem daran bemerkt, dass es gemeinsam neue User Stories bearbeitet. Spätestens nach Abschluss der Integration hätte es doch wieder in XP-Paare „zerfallen“ müssen! Die Zusammenarbeit in dieser Gruppe scheint den Mitgliedern jedoch gut zu gefallen. Offensichtlich ist genügend fachliche und soziale Kompetenz im Mini-Team vorhanden, um anspruchsvolle User Stories zu bearbeiten. Immer beim Auftauchen solcher Super-Teams ist zu beobachten, dass sie sich anspruchsvollen Aufgaben widmen. Das Super-Team ist also mehr als die Summe der ursprünglichen kleineren Einheiten (XP-Paare).104 Wichtig ist, dass sich insbesondere bei der Phase der Integration einer oder mehrerer User Stories größere Mini-Teams bilden (oder bereits erfolgreich zusammenarbeiten). Hier ist ein großer Kommunikationsbedarf festzustellen, was größere Entwicklereinheiten erfordert. Leider reichen solche Super-Teams noch nicht aus, eine regelmäßige und effiziente Integration zu garantieren. Der Grund ist einfach: Auch Super-Teams sehen nur „ihre“ User Stories und deren Integration. Wenn sie keinen Grund für eine Integration sehen, findet keine statt. Abhilfe schafft hier die in Kap. 6.4 beschriebene neue Rolle des Integrationsingenieurs (Abb. 6.8). Dieser setzt eine Integrationsplanung des Projektmanagers um, die dieser mit dem Kunden abgesprochen hat. Der Integrationsingenieur ist üblicherweise im Team geachtet – seine fachliche Kompetenz ist unumstritten. Er hat das nötige „Standing“ im Team, um fälligen Code für anfallende Integrationen einzufordern. Aus der Erfahrung des Autors neigen Entwickler dazu, nur perfekten Code für die Integration freizugeben. Man versucht also, den Integrationsingenieur lange zu vertrösten, bis er den „fertigen“ Code erhält. Dieser Code mag in der Tat modulintern fehlerfrei sein, aber inter-modulare Fehler (also Fehler der Schnittstellen zwischen den Klassen bzw. Modulen) sind oft noch nicht entdeckt. Fehler z.B., die sich aus der Wechselwirkung zwischen User Stories ergeben, bleiben lange unentdeckt. Die Aufgabe des Integrationsingenieurs ist es also auch, Code früh einzufordern, d.h. den Entwicklern immer wieder klar zu machen, dass es besser ist, selbst Code mit kleinen Fehlern auf Methodenebene einzureichen (natürlich mit Hinweis auf den Fehler!) um die Integration zu beschleunigen. Während der Integration durch den Integrationsingenieur kann das betroffene Mini-Team parallel den lokalen „Bug“ eliminieren und die betroffene Methode in den nächsten Integrationsschritt einfließen lassen. Die Erfahrung im studentischen Labor zeigt, dass die Integration auf diese Art und Weise massiv beschleunigt wird. Das studentische Labor der letzten Jahre zeigt, dass sich Super-Teams zur Lösung insbesondere von Integrationsproblemen von alleine bilden, dass aber die Integration selbst und ihre Frequenz vom Projektmanager gesteuert werden muss. Die Durchführung der Integration obliegt der eigens dafür geschaffenen Rolle des Integrationsingenieurs. 104 Warum

(Kap. 7).

solche Teamstrukturen so stabil sind, kann die Organisationspsychologie zeigen

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

103

Im folgenden Kapitel (Abb. 6.21) wird gezeigt, dass Super-Teams auch aus anderen Gründen gebildet werden, z.B. um komplexe Portierungsaufgaben zu erfüllen.

6.5.5 Crystal und die reflektierte Verbesserung 2007 ist eine besondere Session: Hier kann ein Student gewonnen werden, den Prozess des Teams im Rahmen seiner Studienarbeit während des ganzen Semesters zu begleiten. Für ihn wird die Rolle des Prozessverantwortlichen geschaffen (Hättich 2007). Aufgabe des Projektteams 2007 ist es, die bestehende E-Mail-Marketing Software mit Hilfe des Mono-Projekts105 auf Linux zu portieren. Als Prozessmodell wird vom Autor Crystal Clear vorgegeben, das agile Prozessmodell für kleinere Teams von Alistair Cockburn (Cockburn 2005). Parallel bildet sich bereits beim zweiten Termin eine kleine Untergruppe, die sich ausschließlich mit agiler Dokumentation beschäftigt (Content-Management-System Joomla106 plus Einsatz eines Wikis der Vorgänger-Teams), also ein eigenes kleines Projekt begründet.

Abb. 6.20 Session 2007 – Zuordnung der Aufgaben (Projektbeginn) 105 www.mono-project.com 106 www.joomla.de

104

6 Experimentelles Software-Engineering im studentischen Labor

Auf den Abbildungen 6.20 und 6.21 sieht man das zu Projektbeginn gleichmäßig im Raum verteilte Projektteam, das bei der ersten größeren Aufgabe (Portierung des bestehenden Systems auf Linux) schon drei Tage später das erste größere MiniTeam bildet, ein Super-Team mit vier Entwicklern. Damit zeigt die Session 2007 das bereits in den vorhergegangenen Sessions beobachtete Mini-Team-Verhalten: größere Mini-Teams, die sich insbesondere mit „mission-critical“-Aufgaben beschäftigen (in diesem Fall eine Portierung). Durch die Schaffung der neuen Rolle des Prozessverantwortlichen kann das Team 2007 weitaus intensiver und vor allem dokumentierbar bezüglich des gelebten Prozesses befragt werden. Wie bereits in Kap. 4.3 beschrieben, fordert Crystal Clear im Gegensatz zu XP nur wenige Eigenschaften zwingend:

1. regelmäßige Lieferung des aktuellen, getesteten Codes, 2. reflektierte Verbesserung des Prozesses, erzielt durch regelmäßig abgehaltene Meetings, 3. osmotische Kommunikation, d.h. Informationsaustausch im Team, der ganz „nebenbei“, ohne zusätzlichen Aufwand (meist durch räumliche Nähe) stattfindet.

Abb. 6.21 Nur drei Tage später bildet sich das erste größere Mini-Team (Super-Team für Portierung nach Linux)

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

105

Abb. 6.22 Session 2007 – Befragung Projektteam (Hättich 2007)

Werden diese Anforderungen an das Team erfüllt? In einer Umfrage sollen die Team-Mitglieder Schulnoten abgegeben, inwieweit sie die o.g. drei Ziele erreicht haben. Die Antworten (Abb. 6.22) werden mit den Analysen des Prozessverantwortlichen und des Autors verglichen: Insbesondere die unregelmäßigen Code-Lieferungen und die nicht festgestellte Prozess-Reflektion werden vom Prozessverantwortlichen bemängelt. Das Team hingegen gibt sich selbst hinsichtlich der Erfüllung der Crystal Clear-Anforderungen im Schnitt gute bis befriedigende Schulnoten (Tab. 6.3). Diese Umfrage nach ca. drei Viertel der Projektzeit wird am Ende des Projekts für die Punkte 1 und 2 nochmals durchgeführt und ergibt noch bessere Werte (Tab. 6.4). Tabelle 6.3 Erfüllung der Crystal Clear-Anforderung aus Sicht des Teams (1. Umfrage)

1 2 3

Crystal-Clear-Eigenschaft

Schulnote

Regelmäßige Code-Lieferung Reflektierte Prozess-Verbesserung Osmotische Kommunikation

3,0 2,9 1,7

Prozessverantwortlicher und Autor können lediglich die gute Note für die osmotische Kommunikation erklären. Die anderen Noten sind aus Sicht von Crystal Clear nicht nachvollziehbar. Deswegen werden die Teammitglieder nochmals gezielt befragt, wie ihre Benotung zustande kommt:

106

6 Experimentelles Software-Engineering im studentischen Labor Tabelle 6.4 Erfüllung der Crystal Clear-Anforderung aus Sicht des Teams (2. Umfrage)

1 2

Crystal-Clear-Eigenschaft

Schulnote

Regelmäßige Code-Lieferung Reflektierte Prozess-Verbesserung

2,5 2,3

Zum Punkt (1) Regelmäßige Lieferungen ergibt sich Folgendes (Hättich 2007):

„Da es sich bei dem Projekt um eine Portierungsaufgabe handelte, konnte anfangs kaum oder nur sehr schwer fertiger Code geliefert werden. Gegen Ende wurden die Lieferungen dann mehr und auch öfters durchgeführt. Aufgrund der Aufgabe waren regelmäßige Lieferungen nicht möglich“.

Dies ist allerdings nur begrenzt korrekt. Richtig ist wohl, dass das Team keine Notwendigkeit der regelmäßigen Lieferung gesehen hatte und deshalb das Prozessmodell ungesagt angepasst hat. Zum Punkt (2) Reflektierte Verbesserung ergibt sich (Hättich 2007):

„Hier wurde vom Team nicht die reflektierte Verbesserung durch ein Meeting verstanden, sondern die vielen Verbesserungen, die durch Gespräche in kleinen Gruppen mit Projektmanager, Qualitätsmanager und auch mit dem Kunden erzielt wurden.“

Während man bei der Regelmäßigen Lieferung eventuell noch von einer „Interpretation“ der Crystal-Eigenschaft reden könnte, hat das Team bei der Reflektierten Verbesserung eindeutig einen eigenen Weg beschritten. Der gelebte Prozess ist nicht mehr Crystal Clear! Die Session 2007 weist die Gefahr der unausgesprochenen Prozessanpassung auf. Das studentische Labor zeigt hier eindeutig, dass dem Team die Prozessanpassung gar nicht bewusst ist (oder aber völlig egal, was noch viel schlimmer ist). Auf diese Weise schleichen sich Verschlechterungen der Qualität des Prozesses ein, was aus der Erfahrung des Autors sehr oft eine Verschlechterung des Produkts mit sich bringt. Die konsequent gelebte Rolle des Prozessverantwortlichen kann dies verhindern. Sie kann, insbesondere in kleineren Projekten, auch zusätzlich vom Projektmanager oder vom Qualitätssicherer übernommen werden, falls diese noch über genügend Kapazitäten verfügen.

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

107

6.5.6 Scrum im studentischen Labor In der Session 2009 wird im studentischen Labor mit Scrum „experimentiert“. Nach einer ausführlichen Schulung in der agilen Projektmanagementmethode wird die Rolle des Product Owners mit einem Studierenden besetzt.107 Im Rahmen einer Exkursion wird für einen realen Kunden aus dem Bereich der Berufsqualifizierung eine Raumplanungs-Software für Gruppen mit körperlich Behinderten realisiert. Das Projekt geht über acht volle Arbeitstage mit einem Team aus Product Owner, ScrumMaster108 und einem zehnköpfigen Team. Die ersten drei Tage finden im Rahmen einer Exkursion beim Kunden Berufsförderungswerk Bad Wildbad (BFW) statt (Abb. 6.23 bis 6.26).

Abb. 6.23 Session 2009 – Der Kunde im Gespräch mit Product Owner und Team

107 Das Besetzungsverfahren mit Selbst- und Fremdeinschätzung wird in Kap. 7.3.4 näher beleuch-

tet. 108 Diese

Rolle wird vom Autor übernommen.

108

6 Experimentelles Software-Engineering im studentischen Labor

Abb. 6.24 Product Owner mit Sprint Backlog als User Stories

Abb. 6.25 Kunden warten auf das Sprint Review

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

109

Abb. 6.26 Scrum Product Backlog an der Wand

Der Projektablauf wird im „Tagebuch“ des ScrumMasters geschildert (Auszug): 1. Tag (BFW) Nachmittags: Nach Bekanntgabe der Aufgabe (vormittags) organisiert sich das Team. Erste Konflikte entstehen bezüglich der Coding Conventions. Ein „Sprech-Token“ wird eingeführt, um die Diskussion zu kanalisieren. Es bildet sich schnell ein „User Story Kern-Team“ aus Kunde, Product Owner (PO) und fünf Teammitgliedern. Damit wird Scrum bereits das erste Mal „erweitert“.109 Das User Story-Team „übertreibt“. Es versucht, die „optimale“ Lösung zu finden, d.h. die endgültige Lösung zu spezifizieren. Dies gelingt nicht, der Anspruch ist zu groß. Der ScrumMaster (SM) weist auf das Prinzip Simplicity hin. Der Product Owner benennt zum Start drei User Stories, die von drei Mini-Teams geschätzt werden. Die Sprint-Länge wird auf zwei Tage festgelegt.110 Ein Mini-Team aus ein bis vier Entwicklern kümmert sich um die Coding Guidelines.

109 Der

ScrumMaster l¨asst das Team gew¨ahren und beobachtet das Vorgehen.

110

6 Experimentelles Software-Engineering im studentischen Labor

2. Tag (BFW) Vormittags: Intensives Coaching des Product Owners. Es ist nicht so einfach, sich in diese komplexe und anfangs ungewohnte Rolle einzudenken. 10:00 bis 10:15: Daily Scrum : Mini-Teams berichten über ihre Fortschritte. Bemängelt wird Sitzordnung. Sitzordnung wird geändert. Einige Teammitglieder haben Probleme sich an die Konventionen zu halten (Reihenfolge der Wortmeldungen). 11:30: Der Kunde spricht Details der Anforderungen mit dem PO ab. Nachmittags: Die Einteilung in drei große User Stories für den ersten Sprint erweist sich als zu „grob“. Erste Entwickler langweilen sich, weil sie keine weiteren User Stories zur Bearbeitung vorfinden. 13:30: Noch zweieinhalb Stunden bis zum Ende des ersten Sprints. Die Sprint Review-Sitzung ist auf 16:00 Uhr terminiert. Der Integrationsrechner wird vom Kunden zur Verfügung gestellt und steht bereit. 15:55: Der Integrationsingenieur (IE) hat zu lange gezögert, die erste Release der Software auf dem Integrationsrechner zu installieren. Kurz vor Beginn der Sprint Review-Sitzung läuft die Applikation noch nicht auf dem Integrationsrechner. 16:10 – 16:45111 : Sprint-Review Nr. 1 beginnt mit zehnminütiger Verspätung. Die Demo muss auf dem Notebook des IE ablaufen. Damit ist die Bedingung, dass die Demo auf dem Integrationsrechner laufen muss, nicht erfüllt. Das Team demonstriert die Funktionen der ersten Release. Der PO verkündet, dass das Team 66% der User Stories erfolgreich realisiert hat. Ein Grund für die Abzüge ist, dass die Demo nicht auf dem Integrationsrechner lief. Dieses Problem soll zum Ende des nächsten Sprints gelöst sein. Der Kunde lobt das Team, seine Erwartungen sind erfüllt! In der Diskussion entwickelt sich IE zum „Sprecher“ der Gruppe. 3. Tag (BFW) 8:30 – 9:45: Sprint Retrospektive. Einhellige Meinung des Teams ist, dass der erste Sprint „ziemlich gut“ verlief (angenehmes Klima). Das Team ist zufrieden. IE wünscht sich eine bessere zeitliche Organisation der Integration, geht auch auf technische Aspekte ein

110 Das ist sehr kurz, aber in Anbetracht der kurzen Projektlaufzeit von acht Tagen im studentischen Labor gerechtfertigt. 111 Da im studentischen Labor die Sprints recht kurz sind, sind auch die Sitzungen schneller beendet.

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

(wie wird gemeinsame Codebasis verwaltet? Neue Story Card Versionierung/gemeinsamer Projektserver). Team kritisiert: Code könnte früher abgegeben werden. Collective Code Ownership soll in Zukunft besser „gelebt“ werden. Bessere Kommunikation zwischen den MiniTeams, die die einzelnen Story Cards bearbeiten, wird von einzelnen Teammitgliedern gewünscht. Andere sehen das als bereits gegeben. Uneinigkeit herrscht bei der Code-Dokumentationssprache. Obwohl man vorher Englisch gewählt hatte (Coding Conventions), wählt man jetzt Deutsch, lässt aber englische Anteile bestehen (neue Story Card Kommentierungen im Code des Sprint 1 ggf. verbessern). Team diskutiert, wie Verdopplungen im Design verhindert werden können. Daraus folgt Story Card Refactoring Gruppen/Räume für nächsten Sprint. In folgenden Sprints sollten Leerläufe der Team-Mitglieder verhindert werden. Es folgt daraus eine Prozessänderung/-erweiterung und damit eine Anpassung von Scrum: Ab sofort ist es möglich, dass Teammitglieder mit freien Ressourcen oder mit neuen Ideen, potenzielle Story Card formulieren und ins System „einspeisen“ können. Dazu gibt es eine neue Rolle im Team: die Story Koordinatorin (SK). Das Teammitglied bespricht die neue Idee/Story Card mit der SK. Diese trifft eine Vorauswahl und gibt die von ihr ausgewählten Story Cards an den PO weiter. Die neuen Story Cards werden im nächsten Sprint berücksichtigt. Es besteht aber auch neu die Möglichkeit, eine neue Story Card aktuell in den laufenden Sprint aufzunehmen, dies soll aber die Ausnahme sein. Das Ende des Sprints verändert sich dadurch nicht! Weitere neue Rollen werden vereinbart: Qualitätssicherer/Tester (QA) für die Funktionstests der Sprint-Inkremente auf dem Integrationsrechner. 10:15 – 10:30: Etwas verspätet beginnt der Daily Scrum. Er fällt kurz aus, weil eigentlich Vieles bereits in der Retrospektiv-Sitzung angesprochen wurde. 10:30 – 13:50 (exklusive einer Stunde Mittagspause): SprintPlanungssitzung. Diesmal mach sich der PO eindeutig zu viel Arbeit: 37(!) User Stories für den nächsten Sprint. Ein diesbezüglicher Einwand des SM löst Diskussion im Team aus. Man ist geteilter Meinung. Story Cards werden zu Themengebieten gebündelt. PO definiert die drei wichtigen User Stories für den nächsten Sprint. Diskussion entbrennt kontrovers, ob aufwändige Stories durch größere Mini-Teams bearbeitet werden sollen. Sprintlänge wird wieder auf zwei Tage festgelegt.

111

112

6 Experimentelles Software-Engineering im studentischen Labor

Der vierte bis achte Projekttag findet im studentischen Labor statt. Es treten folgende Probleme auf: 5. Tag 9:15: Mitten im zweiten Sprint beginnt eine grundsätzliche Diskussion zwischen PO und zwei Teammitgliedern über das Ziel des Projekts. Diese Diskussion ist wichtig, hat aber nichts im Sprint verloren. SM blockt die Diskussion ab und verschiebt sie auf nächste SprintPlanungssitzung. 9:45: SM coacht PO, realistische finale Ziele für die Software zu definieren (Konzept der räumlichen Nähe von Schulungsräumen). 16:00 – 17:00: Sprint Review Nr. 2. Obwohl PO die User Stories im Sprint Backlog zu 85% als erfüllt akzeptiert, entsteht in der Diskussion mit dem Kunden112 der Eindruck, dass die Implementierung an den Kundenwünschen vorbeizielt. Der Kunde erklärt nochmals detailliert seine Wünsche (manuelle Raumvariationen und Planspiele mit zusätzlichen Gruppen, Berechnung der resultierenden Raumauslastung). PO und das Team „justieren“ ihre Ziele neu. Interessanterweise wird in der anschließenden Restrospektiv-Sitzung nicht die Aufteilung des Teams in zwei Zimmer bemängelt. Die dadurch entstehende Ruhe steht im Vordergrund. Mangelnde osmotische Kommunikation wird vom Team nicht festgestellt. 113 Interessant ist auch, dass das Team die ständige Rückkopplung des Product Owners benötigt. Er ist oft in Gespräche mit Teammitgliedern eingebunden. Es ist offensichtlich sehr schwer, in der Sprint-Planungssitzung die Anforderungen abschließend ins Team zu bringen. Ein einmaliges Verlegen des Daily Scrum am 6. Tag auf 13:00 Uhr zeigt, wie schnell sich das Team an 10:00 Uhr gewöhnt hat. Es ist wichtig, tägliche Meetings immer zur selben Uhrzeit durchzuführen. Interessant ist wieder das „Tagebuch“ des ScrumMasters vom 7.Tag und vom letzten Tag (Auszug): 7. Tag 15:45: Sprint Review beginnt in einer halben Stunde. Team wird geschäftig und unruhig. 16:15 – 17:00: Sprint Review läuft sehr professionell ab. IE führt die aktuelle Release der Software professionell vor. Beim Vorführen findet er ab und

112 Der

Kunde ist über ein web-basiertes Konferenztool zugeschaltet. ist der ScrumMaster, d.h. der Autor, anderer Meinung. 114 Link zum Projekt-Wiki 113 Hier

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

113

zu kleine Probleme. Hier bräuchte es vielleicht doch ausführliche Testpläne. Ad-hoc-Testen findet nicht alle Fehler. Fazit: Erfolgreicher Sprint, aber da nicht alle Story Cards implementiert wurden, nur zu 50% erfüllt (PO). Kunde ist beeindruckt von der Lösung. Kleinere Probleme gilt es im letzten Sprint zu beheben. 8. Tag 8:45: SM muss einschreiten, weil der PO zu viel Projektzeit „verschwendet“, um in der Schlussphase den Überblick über alle noch offenen User Stories zu behalten. Damit blockiert er das Team, weil es die offenen User Stories noch nicht bearbeiten kann. Dieser Stillstand kostet alle sechs Minuten eine Entwicklerstunde! Und der endgültige Abgabetermin ist auf 14:00 Uhr angesetzt. PO gibt schließlich alle User Stories der Priorität1 frei, auch ohne Schätzung des jeweiligen Mini-Teams. Die Schätzungen müssen vom jeweiligen Mini-Team nachgeholt werden. 14:00 – 14:45: Das letzte Review Meeting beginnt pünktlich. Das ganze Team arbeitete erstaunlich ruhig und konzentriert an den letzten Feinheiten. Der Stand der Software ist beeindruckend, die Software läuft stabil. Ein paar Kleinigkeiten funktionieren noch nicht, sollen aber im Anschluss an die Review-Sitzung noch korrigiert werden. Der Kunde sieht seine Erwartungen erfüllt, zum großen Teil sogar übertroffen und ist sehr zufrieden. 14:45 – 16:15: Das Team eliminiert die letzten Bugs, organisiert Tests mit Testplänen und führt sie gemeinsam durch. 16:15: Die Software wird per E-Mail inklusive Dokumentation114 abgegeben. Dabei wurde kein Schwerpunkt auf die Dokumentation gelegt, aber alle Arbeitsdokumente, Backlogs, Code Conventions etc. wurden gesammelt und zentral archiviert. 16:20: —PROJEKTENDE— Das Projekt hatte ca. 580 Projektstunden, also 4,8 Programmierer-Monate. Tolle Leistung!

Die Gründe für den Erfolg des Projekts sind • die konsequente Zuordnung der Projektrollen,115 • der Einsatz von Scrum für regelmäßige Sprints mit definiertem Abgabetermin, • ein kleines und motiviertes Team!

115 Zum

Besetzungsverfahren mit Selbst- und Fremdeinschätzung siehe Kap. 7.3.4.

114

6 Experimentelles Software-Engineering im studentischen Labor

Allerdings musste Scrum im Verlauf des studentischen Projekts um die Rolle der Story Koordinatorin erweitert werden, die es Teammitgliedern mit freien Ressourcen oder neuen Ideen erlaubt, diese als potenzielle Story Card zu formulieren und ins System „einzuspeisen“, d.h. nach Vorauswahl durch die Story Koordinatorin dem Product Owner vorzulegen (s. „Tagebuch – 3. Tag“). Zum Schluss sollen noch einige Kommentare der Studierenden im Rahmen einer Umfrage am Ende des Projekts zusammengefasst werden: • Mit großer Mehrheit wird die Nützlichkeit der Daily Scrum-Sitzung bestätigt. So konnte das ganze Team in einer Viertelstunde einen Überblick über den aktuellen Stand des Projekts bekommen. Aber auch die Einteilung des Projekts in fixe Sprints wurde als zielführend empfunden. • Ein XP-Paar war im Team. Die restlichen Team-Mitglieder arbeiteten UserStory-bezogen in Mini-Teams wechselnder Größen. • Die Nützlichkeit der formalen Abfolge der diversen Scrum-Sitzungen wird in Frage gestellt (mit Ausnahme des Daily Scrums). Auch muss angemerkt werden, dass die Gefahr der Überbeanspruchung des Product Owners besteht. Er muss als „Nadelöhr“ angesehen werden, da hauptsächlich er den Kontakt zum Kunden hält, was ihn zeitlich stark belastet. Es besteht die Gefahr, dass das Team auf seine User Stories warten muss, was im studentischen Labor auch tatsächlich passierte. In einem realen Projekt außerhalb des Labors muss er die Chance bekommen, das Projekt einige Tage im Voraus zu planen und vorzubereiten. Dies wird in der Regel der Fall sein. Der Product Owner äußert sich zur Frage der Nützlichkeit der Vorgaben des Prozesses wie folgt: Positiv/zielführend: •

•

Die im Projekt eingesetzte Rollenverteilung empfand ich als sinnvoll. Die Integration der einzelnen Softwaremodule, Kommunikation mit dem Kunden und Zielformulierung sowie Überwachung des Prozesses können nicht vom gesamten Team in demokratischer Weise geregelt werden. Hierfür gab es die Rollen des Integrationsingenieurs, des Product Owners und des Prozessbeobachters. Die tägliche Reflexion über die eigene Arbeit jedes Teammitglieds während des Daily Scrum war eine gute Möglichkeit, Strategien zu überdenken und mögliche Konflikte mit anderen Teams frühzeitig zu erkennen.

Negativ/problematisch: •

Die selbstständige Auswahl der Aufgaben durch die Mini-Teams in Kombination mit einem sehr heterogenen Entwicklerteam konnte dazu führen, dass sich unerfahrene Programmierer mit hochkomplexen

6.5

Veränderung agiler Praktiken und Prozesse in der Praxis

•

115

Aufgaben überforderten, während erfahrene Mini-Teams sich mit eher einfachen Aufgaben beschäftigten. Hier fehlt möglicherweise ein System zur koordinierten Aufgabenverteilung z.B. während der Sprintplanungssitzung. Dies ginge allerdings auf Kosten des Faktors Zeit. Das Product Backlog116 erwies sich als zu zeitaufwändig und mit wachsendem Umfang schlicht nicht flexibel genug, um regelmäßig aktualisiert zu werden, insbesondere was die Priorisierung anging. Stattdessen verkümmerte es mehr und mehr zu einem Ideenvorrat, welcher bei der Releaseplanung und beim Erstellen der User Stories für den nächsten Sprint lediglich überflogen wurde. Hilfreich war es erst, als die einzelnen Punkte nach Kategorien geordnet wurden, um einen besseren Überblick zu haben. Ob dies jedoch in Tabellenform geschehen muss? Ein Stift und einige wenige Notizblätter erfüllen den gleichen Zweck, zumindest in einem so kurzen Projekt mit entsprechend kurzen Sprints und knapper Vorbereitungszeit.

Man erkennt aus diesen Aussagen die zwingende Notwendigkeit der Erfahrung des Teams mit agilen Ansätzen. Trotzdem war auch dieses studentische Team nach einiger Einarbeitung in der Lage Scrum anzuwenden. Was die Zusammensetzung des Teams und die Verteilung der Projektrollen betrifft, sei auf Kap. 7.6 verwiesen. Mögliche Erweiterungen und Anpassungen von Scrum sollen dort diskutiert werden.

6.5.7 Hierarchische Prozesse unter dem agilen Deckmantel In der Session 2006 geschieht durch eine Änderung der Rahmenbedingungen etwas Seltsames: Eigentlich möchte der Autor ausprobieren, welchen Typ Projektleiter sich ein Team auswählt, wenn es die Möglichkeit dazu hat. In der Praxis wird dies wohl so gut wie nie vorkommen,117 im studentischen Labor bietet sich diese Konstellation förmlich an. Wird das Team eher einen Moderator oder einen „Alleinherrscher“ wählen? Das Team wählt sich in der Tat einen starken, hierarchisch orientierten Projektleiter,118 der mit Eifer und viel Fleiß seine Aufgabe wahrnimmt. Er organisiert die Erstellung der User Stories mit dem Kunden, wählt die teilnehmenden Teammitglieder aus und formuliert die User Stories. Im Rahmen einer täglichen Sitzung

116 Siehe

auch Abbildung 6.26. ist dem Autor keine solche Konstellation bekannt. 118 der auch nach Einschätzung des Autors aus einem entsprechend hierarchisch orientierten Unternehmen stammt 117 Jedenfalls

116

6 Experimentelles Software-Engineering im studentischen Labor

(die auch tatsächlich im Sitzen stattfindet) teilt er die User Stories einzelnen MiniTeams zu. Auf die Zusammensetzung der Mini-Teams nimmt er allerdings nur Einfluss, wenn er die Notwendigkeit sieht. Es entsteht ein „klassischer“ iterativinkrementeller Prozess, der bezogen auf die Erreichung der Projektziele erfolgreich ist! Der Erfolg wird jedoch durch einen übermäßigen und aus der Sicht des Autors ungesunden Arbeitsaufwand für den Projektleiter erkauft. Am Ende sind sich Projektleiter und Autor einig, dass es besser gewesen wäre, die Arbeit auf mehrere Schultern zu verteilen (also „agiler“ vorzugehen).119 Im Nachhinein ist sich der Autor sicher, dass das Projektteam, das den späteren Projekteiter aus mehreren Kursjahren gut kannte und einschätzen konnte, bewusst diese Entscheidung gefällt hat, um sich Arbeit zu ersparen. Man war sich offensichtlich sicher, dass der Projektleiter mit seinem hohen Einsatz dem Team Aufwand ersparte. Der Ansatz, den Projektleiter wählen zu lassen, wird vom Autor im studentischen Labor nicht mehr weiter verfolgt. Die Ausbildung der Mini-Teams ist allerdings von der hierarchischen Projektstruktur unbeeinflusst. Es bilden sich Paare und Tripel, die auch wieder zerfallen oder ihre Zusammensetzung ändern. Interessant ist, dass sich kein Super-Team bildet (Abb. 6.27 und 6.28).

Abb. 6.27 Session 2006 – Paare und Tripel im hierarchischen Prozess

119 Trotzdem: großer Respekt vor der Leistung des Projektleiters, die im Rahmen des studentischen

Labors nicht einmal benotet werden konnte.

Literatur

117

Abb. 6.28 Im hierarchischen Prozess bildet sich kein Super-Team

Durch all die beschriebenen Erfahrungen im studentischen Labor stellt sich dem Autor die zentrale Frage, ob der Ansatz der Prozessmodelle überhaupt der richtige ist. Wird das Team dadurch nicht zu sehr eingeschränkt? Ist es nicht besser, lediglich die Rahmenbedingungen für den Prozess zu definieren und das Team den geeigneten agilen Teamprozess finden zu lassen?

Literatur Beck K (2009) http://c2.com/cgi/wiki?CthreeProjectTerminated, last edited June 19, 2009. Zugriff 27.08.2009 Cockburn A (2005) Crystal Clear: A human powered Methodology for small Teams. New York, NY: Pearson. Dt. Übersetzung: Crystal Clear: Agile Software-Entwicklung für kleine Teams. Bonn: MITP-Verlag Cockburn A (2008) http://alistair.cockburn.us. Zugriff 27.08.2009 Fowler M (2005) http://www.martinfowler.com/articles/newMethodology.html#id2251638. Zugriff 27.08.2009 Hättich N (2007) Das agile Prozessmodell Crystal, Studienarbeit, DHBW/BA Lörrach, Studiengang Informationstechnik Hanser E (2006) Extreme Programming in Real World at the „IT Laboratory“ of BA Loerrach, ISTC Conference Proceedings. Vaal University of Technology, South Africa Hanser E, Brecht U, Michelbach A (2006) Agile Software-Entwicklung: Extreme Programming im IT-Labor der BA Lörrach. BA Dialog Nr. 6

Kapitel 7

MAP – Meta Agile Process Model

Die im studentischen Labor beschriebenen Erfahrungen provozieren die zentrale Frage, ob der Ansatz, immer wieder neue Prozessmodelle zu entwickeln, überhaupt der richtige ist. MAP verfolgt deswegen einen anderen Weg: Es werden die Rahmenbedingungen für den Prozess festgelegt, aber dem Team wird genügend Raum gegeben, den geeigneten agilen Teamprozess selbst zu finden. Dabei findet insbesondere eine organisationspsychologische Betrachtung des Teams statt.

Ist der Ansatz, immer wieder neue Prozessmodelle zu entwickeln, der richtige? Diese zentrale Frage resultiert aus den geschilderten Erfahrungen im studentischen Labor. Wird das Team durch das strikte Befolgen eines vorgegebenen Prozessmodells nicht zu sehr eingeschränkt? Auch im studentischen Labor wurde immer wieder festgestellt, dass Mitglieder des Teams das geforderte Prozessmodell nicht kannten (und das trotz der zuvor gehörten Vorlesung zum Thema). Ist es nicht generell besser, lediglich die Rahmenbedingungen für den Prozess zu definieren und das Team den geeigneten agilen Teamprozess selbst finden zu lassen?120

7.1 Team-Psychologie – Landkarte der Verhaltensweisen im Team Die Organisationspsychologie kennt sechs Verhaltensweisen von Teammitgliedern, die gemäß der Erfahrung des Autors alle zu einem erfolgreichen Team gehören müssen: Kommunikatoren, Ideengeber, Fachexperten und Teamworker, die für das Mini-Team wichtig sind, sowie Problemlöser und Qualitätsprüfer, die (zusätzlich) für das gesamte Projektteam von Bedeutung sind (Abb. 7.1).121 Die Mischung aus diesen verschiedenen Verhaltensweisen ist Grundlage für den Erfolg des Teams.

120 Um

es aber ganz deutlich zu sagen: Das Wissen um Prozessmodelle ist unabdingbar, weil es den Teammitgliedern erlaubt, die dort beschriebenen Regeln und Praktiken als „Werkzeugkasten“ für den täglichen Gebrauch zu nutzen. 121 Sehr zu empfehlen ist zu diesem Thema auch (Baldegger 2004) oder (Baldegger u. Gotsman 2001). Die obige Abbildung ist in der Diskussion mit Herrn Baldegger entstanden.

E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP, eXamen.press, C Springer-Verlag Berlin Heidelberg 2010 DOI 10.1007/978-3-642-12313-9_7, 

119

120

7

MAP – Meta Agile Process Model

Abb. 7.1 „Landkarte“ der Verhaltensweisen im Team

Die Landkarte der Verhaltensweisen im Team (Abb. 7.1), kurz MAP122 genannt, ist wie folgt zu „lesen“: In der oberen Zeile von links nach rechts stehen allgemeine menschliche Eigenschaften. Bezogen auf die Projektarbeit sind die folgenden hier besonders wichtig: • bereit zur Kommunikation • erfahren • belastbar In der Spalte vorne stehen menschliche Eigenschaften, die insbesondere in Projekten eine wichtige Rolle spielen: • • • • • • • •

visionär kreativ kostenbewusst kritisch/hinterfragend strukturiert analytisch planend umsetzungsorientiert

122 neben dem Akronym für Meta Agile Process Model ein anderer Grund für die Namenswahl des

agilen Metamodells, siehe dazu auch (Hanser 2009)

7.1

Team-Psychologie – Landkarte der Verhaltensweisen im Team

121

Die Typen der Teammitglieder, oder besser ihre Verhaltungsweisen123 im Team, ergeben sich aus der Kombination dieser menschlichen Eigenschaften.124 In der Karte überlappen sich die resultierenden Verhaltensweisen zum Teil125 : • Der Kommunikator muss mit offenen Augen am Projekt teilnehmen und Probleme der Kommunikation erkennen und beheben. Er muss ein Problem strukturiert analysieren und dem Team kommunizieren. Er muss z.B. weder visionär noch implementierend sein, und die Arbeit unter Druck muss auch nicht zu seinen Stärken gehören. • Der Ideengeber ist erfahren und bereit zur Kommunikation, außerdem visionär und kreativ. Üblicherweise mangelt es ihm an kritischem Hinterfragen. Kosten spielen in der Regel kaum eine Rolle in seinen Überlegungen. Belastbar muss er nicht sein. • Der Experte/Fachspezialist hat seine Stärken im strukturierten, analytischen, planenden Vorgehen. Er ist erfahren, durchaus auch offen für andere Meinungen, hat aber auch eine klare Vorliebe für das „Machen“, das Implementieren der Lösung. • Der Technische Problemlöser/Troubleshooter fährt zu voller Leistung auf, wenn er unter Druck steht. Seine Erfahrung, sein kritisch-strukturiertes und analytisches Denken helfen ihm in verfahrenen Situationen, „die Karre aus dem Dreck zu ziehen“. „Normale“ Projektarbeiten, wie Planung der Iterationen oder Kostenschätzung, interessieren ihn meist weniger. • Der Teamworker ist der „Implementierer“126 im Team. Er übernimmt mit seinem Mini-Team eine User Story und implementiert sie selbstständig mit seinen Kollegen. Er ist oft erfahren und meist auch durchaus in der Lage, seine Ziele unter Druck zu erreichen. Diese Eigenschaften stehen jedoch nicht im Vordergrund. Die Erfahrungen im studentischen Labor zeigen eher, dass der Teamworker wenig Interesse hat, an übergreifenden Teamarbeiten, wie z.B. der Erstellung von User Stories, teilzunehmen. • Der Qualitätsprüfer hat nur ein Ziel: Er will die maximale Qualität von Produkt und Prozess sicherstellen. Er ist erfahren und kritisch, denkt strukturiert,

123 Der Einfachheit halber werden hier die männlichen Formen benutzt, wohl wissend, dass Frauen

im Team maßgeblich zum Erfolg beitragen und auch das Klima verbessern. sei aber angemerkt, dass Menschen auch mehrere solche Verhaltensweisen in sich vereinen können. Außerdem verändern sich Verhaltensweisen im Laufe der Jahre. Die Welt ist eben nicht nur schwarz-weiß! 125 Jede Verhaltensweise stellt also ein farbiges Rechteck in der „MAP“ dar. Die Verhaltensweisen Qualitätsprüfer, Kommunikator und Experte/Fachspezialist überlappen aufgrund der teilweise übereinstimmenden unterliegenden menschlichen Eigenschaften. 126 Vorsicht! In Diskussionen mit Psychologen sorgt der Begriff Team Worker immer wieder für Verwirrung. Psychologen sehen den Team Worker oft als „Arbeiter am Teamprozess“ (Baldegger u. Gotsman 2001). Hier wird der Team Worker als „Arbeiter“ am Produkt verstanden (Implementierung einer User Story). 124 Es

122

7

MAP – Meta Agile Process Model

und er behält die Kosten im Auge. Oftmals ist er „orthogonal“ zum Team, ist also geschaffen für die Rolle des Qualitätssicherers. Im Gegensatz zur klassischen Projektrolle braucht er aber im agilen Team mehr Kommunikationsfähigkeiten. Wenn die Mischung aus den skizzierten Verhaltensweisen Grundlage für den Erfolg eines Teams ist, dann muss man in einem erfolgreichen Team die o.g. Verhaltensweisen in einer „vernünftigen“ Mischung finden. Es ist also sinnvoll, das Super-Team aus dem studentischen Labor 2005 (Kap. 6.5.3) auf die vorhandenen Verhaltensweisen der Teammitglieder zu untersuchen.

7.2 Das Super-Team Das Super-Team aus Session 2005 bildet sich ursprünglich anlässlich einer Integrationsaufgabe und arbeitet anfangs dem Integrationsingenieur zu (Abb. 6.13). Das Super-Team ist für den Erfolg des Projekts von großer Bedeutung! Insbesondere dessen erfolgreiches Zusammenführen der Teilaktivitäten im Vorfeld der ersten Integration macht den Erfolg der Session 2005 erst möglich. Besonders ist, dass das Super-Team auch nach Abschluss der Integrationsaufgabe stabil bleibt. Die Mitglieder merken, dass ihnen diese Organisationsform Vorteile bringt. Im Gegensatz zum Gesamtteam braucht dieses Teilteam keinen internen Qualitätsprüfer, weil diese Aufgabe vom Qualitätsmanager des Projektteams übernommen wird. Ebenso braucht das Super-Team keinen eigenen Troubleshooter. Diese Aufgabe wird in der Session 2005 von Projekt- und Qualitätsmanager übernommen (Kap. 6.3.1 und 6.3.2). Gemäß MAP (Abb. 7.1) braucht das Super-Team als Projektteilteam die vier Verhaltensweisen Kommunikatoren, Ideengeber, Fachexperten und Teamworker. Abbildung 7.2 zeigt die tatsächliche Zusammensetzung des Super-Teams aus Session 2005: Wie man sieht, sind alle in MAP geforderten Verhaltensweisen im Super-Team vorhanden. Es sei noch einmal ausdrücklich darauf hingewiesen, dass dieses Teilteam sich spontan gebildet hat. Auslöser war eine wichtige Integrationsaufgabe, nachdem der Kunde (der Autor) das Einhalten des Integrationtermins vehement gefordert hat. Das erfolgreiche Super-Team hat sich also unter äußerem Druck und ohne Eingriff des Managements gebildet – einfach aus der Notwendigkeit heraus – und ist nach der erfolgreichen Bearbeitung der Aufgabe zusammengeblieben! Das Super-Team hat sich die Mitglieder mit den Verhaltensweisen, die zum Erfolg notwendig sind, „gesucht“127 ! Dies ist eine gelungene Bestätigung der Landkarte der Verhaltensweisen (Abb. 7.1). Um den Erfolg eines Projekts möglich zu machen, reicht es also aus, dem 127 Anzumerken

ist noch, dass der Autor MAP (die Landkarte der Verhaltensweisen) zeitlich parallel zur Bildung und Existenz des Super-Teams entwickelt hat. MAP war also zuerst da, und die Überraschung und Freude war groß, als alle Verhaltensweisen, die für den Erfolg des Teams als notwendig identifiziert wurden, auch im Super-Team isoliert werden konnten. Abbildung 7.2 wurde übrigens im Nachhinein vom damaligen Projektmanager bestätigt.

7.3

Was ist MAP?

123

Abb. 7.2 Verhaltensweisen im Super-Team der Session 2005

Projektteam genügend (aber nicht zu viele) Mitglieder mit den zum Erfolg notwendigen Verhaltensweisen zur Verfügung zu stellen. Die zur Lösung einer kniffeligen Aufgabe notwendigen erfolgreichen Mini-Teams bilden sich dann von selbst.128

7.3 Was ist MAP? Im Laufe der (Projekt-) Jahre kommt der Autor mehr und mehr zu der Überzeugung, dass der Ansatz der Entwicklung ständig neuer Prozessmodelle falsch ist. Es ist zwar wichtig, den Studierenden und Auszubildenden fundamentale Prozessmodelle als Projekt-„Baukasten“ zur Verfügung zu stellen. Für die Projektpraxis wichtiger aber ist es, die minimalen „Zutaten“ zu benennen, die ein erfolgreiches Team und damit ein erfolgreicher Prozess benötigt. Der Autor bezeichnet diesen Ansatz als „Meta Agile Process Model“. MAP ist also ein Meta-Modell. Es geht nicht um die Definition eines agilen Prozesses, sondern um die Definition der Rahmenbedingungen für den agilen Prozess:

Ein erfolgreiches Projekt in einem nicht zu großen Team (bis vielleicht 20 Mitgliedern) braucht nach den Erfahrungen aus dem studentischen Labor des Autors folgende Zutaten: • Ein Kunde, der seine Aufgabe ernst nimmt, und dem Team nicht unbedingt immer, aber genügend oft zur Verfügung steht.

128 Trotzdem

ist die Existenz eines Integrationsingenieurs, des „lone wolf“ unabdingbar, da diese Aufgabe nur zentral bewältigt werden kann (Kap. 6.4).

124

7

MAP – Meta Agile Process Model

• Ein bis zwei gute und flexible Kommunikationsmanager, die sich Projektund Qualitätsmanagementaufgaben aufteilen, aber vor allem die Kommunikation im Team und mit dem Kunden sicherstellen. • Ein Integrationsingenieur, der allein verantwortlich, aber vom Projektmanagement überwacht, eine kontinuierliche Projekt-Integration einfordert und garantiert. • Ein gut ausgewogenes Team mit einem guten psychologischen Prozess, in dem alle aus der Organisationspsychologie bekannten Typen in ausreichendem Maße vorkommen. • Ein Prozessverantwortlicher (MAP-Beobachter129 ), der den tatsächlich gelebten Prozess und seine Veränderung dokumentiert und die Einhaltung verabredeter Regeln und Praktiken überwacht. (Dies kann auch vom Qualitätsmanager übernommen werden!) Wenn diese Bedingungen erfüllt sind, spielt nach den Erkenntnissen aus dem studentischen Labor das gewählte Software-Entwicklungs-Prozessmodell eine untergeordnete Rolle. Das Team wird im Rahmen der ProjektRandbedingungen den geeigneten Prozess finden.

Der Ansatz, Rahmenbedingungen für ein Projekt und keine Prozessschritte zu beschreiben, ist für den Leser sicherlich ungewöhnlich. Er ergibt sich aber aus der Problematik, dass ein Prozess, der sich sowieso ständig verändert, keine Invariante im Leben des Teams bilden kann130 : Wie soll sich ein Teammitglied einen Prozess merken, der sich ständig verändert! Besser ist, wenn sich das Team aus seinem Wissensschatz über Prozessmodelle Regeln und Praktiken sucht, die für das aktuelle Projekt oder in der aktuellen Projektsituation passen, und keine Energie darauf verschwendet, einem gewissen Prozess zu folgen, der sich zumindest im studentischen Labor im Lauf der Zeit immer als suboptimal herausgestellt hat. Richtig ist allerdings auch, dass alle studentischen Gruppen über die Jahre hinweg einer Art von Minimalprozess gefolgt sind. Dieser soll im Kap. 7.5 vorgestellt werden.

7.4 MAP – die Projektrollen im Team Da MAP ein Meta-Modell ist, sollte den Projektrollen eine besondere Bedeutung zugemessen werden. Die Teammitglieder, die diese Rollen übernehmen, müssen sorgfältig ausgesucht werden. Wie das studentische Labor 2006 zeigte, kann sich 129 engl.

MAP Observer. der Autor Physik studiert hat, ist sein Leben vom Suchen nach Erhaltungssätzen und Invarianten geprägt ;-)

130 Da

7.4

MAP – die Projektrollen im Team

125

ansonsten unter dem Deckmantel der Agilität durchaus ein hierarchischer Prozess bilden (Kap. 6.5.7).

7.4.1 Kunde Der Kunde muss das zu erstellende Endprodukt genau im Auge haben. Er allein ist verantwortlich dafür, dass das fertige Produkt für den Auftraggeber von Wert ist. Er validiert das Produkt somit.131 Seine fachliche Qualifikation muss besonders ausgeprägt sein, aber auch seine Durchsetzungskraft in der Kundenorganisation, also auf der Seite des Auftraggebers. Nichts Schlimmeres als eine Änderung des Produkts, die vom Kunden im Team initiiert wurde, aber von anderen Nutzern des Software-Produkts abgelehnt wird! Von zentraler Bedeutung ist die Verfügbarkeit des Kunden. Er muss seine Aufgabe so ernst nehmen, dass er bereit ist, dem Team eine Reaktionszeit bei auftauchenden Fragen zu garantieren. Es ist klar (das zeigen MAP-Projekte in der Praxis), dass es schwierig ist, einen solchen Kunden zu finden und auch noch sicherzustellen, dass er dem Team genügend oft zur Verfügung steht. Dass sich der Kunde die ganze Zeit im Team aufhält, bleibt somit meist nur ein Wunschtraum. Bewährt hat sich daher die folgende Vereinbarung zwischen dem Kunden und dem Team, die im Rahmen der Projekt-Regeln und -Praktiken am Anfang des Projekts geschlossen werden muss: 1. Der Kunde ist pro Woche mindestens zwei bis drei halbe Tage im Team. Hier erwartet ihn nicht das übliche „Kunden-Besuchsprogramm“ mit Präsentationen usw., sondern der Einblick in die Arbeit des Teams. Er ist einfach nur da! 2. In Abwesenheit des Kunden gibt es ein „rotes Telefon“, also z.B. ein Handy, idealerweise mit geheimer Nummer, welches er immer bei sich trägt und über welches er nur vom Team angerufen werden kann. Läutet dieses Telefon, nimmt er gleich ab und nimmt die Frage des Teams entgegen.132 3. Innerhalb von maximal sechs bis zwölf Stunden bekommt das Team eine ausführliche Antwort auf die gestellte Frage.

7.4.2 Kommunikationsmanager Die Erfahrung aus dem studentischen Labor lehrt ganz klar, dass in den meisten Projekten ein Mangel an Kommunikation herrscht (Kap. 6.3.1). Kommunikation verläuft dabei grundsätzlich in zwei Richtungen:

131 Allerdings

in der Regel ohne das aufwändige Verfahren der Validierung, wie wir es z.B. vom V-Modell kennen. 132 Natürlich muss diese Verhaltensweise des Kunden mit seinen Vorgesetzten abgestimmt sein.

126

7

MAP – Meta Agile Process Model

1. Kommunikation innerhalb des Teams 2. Kommunikation zwischen Team und Kunde Die Kommunikation innerhalb des Teams verläuft grundsätzlich osmotisch (Cockburn 2005). Durch die Anwesenheit aller Entwickler im gleichen Büro ist sichergestellt, dass alle mitbekommen, wenn ein Thema mehrere Entwickler beschäftigt (und damit für das ganze Team interessant sein könnte). Im studentischen Labor schlendert der Autor eigentlich nur durch die Tischreihen und weiß in der Regel danach bestens über die aktuellen Probleme des Teams Bescheid. Dies muss für jeden Entwickler ebenso gelten. Trotzdem ist die Kommunikation der Mini-Teams untereinander manchmal eingeschränkt. Da sie üblicherweise unterschiedliche User Stories bearbeiten, besteht aus Sicht der Mini-Teams oftmals wenig Notwendigkeit, über alle Sorgen und Nöte des Projektteams informiert zu sein.133 Hier setzen die Kommunikationsmanager an. Durch Abhalten von Stand-Up Meetings oder vergleichbaren Treffen wird der Informationsfluss gefördert. Bei heiklen Projektsituationen werden sofort alle Teammitglieder informiert. Bei Integrationen wird ein gemeinsamer Wissensstand bezüglich des Funktionsumfangs der angestrebten Version hergestellt. Dies kann auch durch Initiieren einer kurzen Präsentation durch einen Fachspezialisten geschehen (Abb. 7.3).

Abb. 7.3 Präsentation im studentischen Labor (Session 2007)

133 Natürlich

hat das auch mit der Größe des Teams zu tun: Teams unter fünf Personen berichten dem Autor keine Kommunikationsprobleme.

7.4

MAP – die Projektrollen im Team

127

Kritischer ist nach den Erfahrungen aus dem studentischen Labor die Kommunikation zwischen Team und Kunde. Man glaubt nicht, wie oft der Kunde „interpretiert“ anstatt einfach nur gefragt wird. In den letzten fünf Jahren gab es kein Team, welches nicht bisweilen dieser Versuchung erlag. Interessanterweise findet man den Versuch, den Kunden zu interpretieren, sogar, wenn dieser sich im gesamten Projekt mit dem Team in denselben Projekträumen aufhält. Hier muss der Kommunikationsmanger eingreifen. Er hält die Verbindung mit dem Kunden aufrecht und versucht zu erkennen, wenn ein Mini-Team die Auskunft des Kunden benötigt. Wichtig ist auch, dass dem Team geänderte Randbedingungen des Projekts rechtzeitig mitgeteilt werden. Damit übernimmt ein Kommunikationsmanger in der „Außenwirkung“ des Teams gegenüber dem Kunden durchaus Aufgaben, die klassisch im Projektmanagement zu finden sind. Deswegen verwundert es nicht, dass sich die in MAP-Teams mit über fünf Personen meist mehreren Kommunikations-Manger Projekt- und Qualitätsmanagementaufgaben teilen. Bewährt hat sich im studentischen Labor, dass zwei Kommunikationsmanager jeweils Projektmanagement und Qualitätsmanagement übernehmen. Wichtig ist, dass diese klassischen Projektrollen getrennt besetzt werden, da ihre Ziele manchmal im Gegensatz zueinander stehen: Während der Projektmanager Termine und Kosten im Auge behalten muss, kann sich der Qualitätsmanager ganz auf die Forderung nach optimaler Qualität konzentrieren.

7.4.3 Integrationsingenieur Die Rolle des Integrationsingenieurs wird bereits in Kap. 6.4 behandelt. Negative Erfahrungen im ersten studentischen Labor waren die Auslöser für die Einführung dieser Rolle. Es reicht eben nicht aus, wie z.B. in XP gefordert (Beck 2000), einen Integrationsrechner zur Verfügung zu stellen, man braucht auch den entsprechenden Verantwortlichen, den Integrationsingenieur. Es ist zwar richtig, dass dadurch ein Engpass im Projektablauf entstehen kann, aber die Erfahrungen im studentischen Labor zeigen, dass der Vorteil, an zentraler Stelle einen Experten und Troubleshooter zu haben, überwiegt. Es ist klar geregelt, wer die Verantwortung für die Integration trägt. Um es noch einmal klar zu sagen: Jedes Mini-Team hat die Aufgabe, den zu integrierenden Code zusammenzustellen und dem Integrationsingenieur abzugeben. Aber die eigentliche Integration auf dem Integrationsrechner wird nur von ihm alleine durchgeführt. Dabei muss er auftretende Probleme unter Mitwirkung der betroffenen Mini-Teams lösen. Dieser Ansatz ist anders als bei anderen agilen Ansätzen! Es hat sich bewährt, die Integrationsaktivitäten vom Projektmanager überwachen zu lassen. Dieser kann im Zusammenspiel mit dem Kunden eine kontinuierliche Integration einfordern und die diesbezüglichen Meilensteine überwachen. Diese wichtige Aufgabe ist auch ein Beleg für die Wichtigkeit der Existenz eines Projektmanagers.134 134 Im

Gegensatz zu diesen Ausführungen möchte Scrum auf den Projektleiter verzichten, was nach Ansicht des Autors unsinnig ist (siehe dazu auch Pichler 2008).

128

7

MAP – Meta Agile Process Model

7.4.4 Team Das Team steht bei MAP im Zentrum. Dies ist an und für sich nichts Außergewöhnliches in agilen Projekten. Neu ist, dass MAP gemäß der „Landkarte“ der Verhaltensweisen im Team (Abb. 7.1) klare Bedingungen an die Verhaltensweisen135 stellt, die im Team vorhanden sein müssen.136 Wie in Kap. 7.1 dargelegt, braucht das erfolgreiche MAP-Team • • • • • •

Kommunikatoren Ideengeber Experten/Fachspezialisten Technische Problemlöser/Troubleshooter Teamworker Qualitätsprüfer

Das „Super-Team“ in Abbildung 7.2 zeigt, dass ein kleines erfolgreiches Team von jedem Typen oder besser gesagt von jeder Verhaltensweise ihrer Teammitglieder eine aufweist. Größere Teams brauchen naturgemäß mehrere Typen von derselben Sorte in einem ausgewogenen Verhältnis. Interessant ist die Frage, wie diese Zusammensetzung des Teams erreicht werden kann: Am Anfang steht die Einschätzung137 potenzieller Mitarbeiter bezogen auf die Verhaltensweise im Team – den „MAP-Typ“. Bewährt hat sich im studentischen Labor eine Kombination aus Selbsteinschätzung und zwei Fremdeinschätzungen. Dafür wurde vom Autor ein Formular entwickelt, welches sich für beide Arten der Einschätzung eignet (Abb. 7.4 und 7.5). Abbildung 7.4 zeigt ein ausgefülltes Selbsteinschätzungsformular. Sollte diese Einschätzung durch mindestens eine Fremdeinschätzung bestätigt werden, bildet sie die Basis für eine Zuordnung eines oder mehrerer MAP-Typen. In Abbildung 7.5 wird über das Selbsteinschätzungsformular eine Folie mit den MAP-Typen (also den Verhaltensweisen im Team) gelegt. Wie man leicht sieht, passt in diesem Beispiel die Selbsteinschätzung auf Technischer Problemlöser oder Teamworker mit hundertprozentiger Übereinstimmung. Die Übereinstimmung mit Qualitätsprüfer und Experte beträgt etwa 50%. Eine Übereinstimmung mit Kommunikator oder Ideengeber ist nicht erkennbar. Somit ist das Teammitglied in diesem Beispiel sehr gut als Technischer Problemlöser oder Teamworker einsetzbar. Mit dieser Methode kann das Team ausgewogen zusammengestellt werden, indem alle MAP-Typen in ausreichendem Maße berücksichtigt werden.

135 Man könnte zu den „Typen“ der Teammitglieder auch „Charaktere“ sagen. Da diese Eigenschaf-

ten sich aber zeitlich verändern, spricht man besser von Verhaltensweisen. Eine Verhaltensweise ist also streng genommen ein Teammitglied mit einer Verhaltensweise wie in Kap. 7.1 definiert. 136 Damit stellt MAP also Anforderungen an die Teampsychologie! 137 Im Unternehmen sollte bei solchen Einschätzungen der Betriebsrat mit hinzugezogen werden. Wichtig ist, dass solche Informationen keinesfalls zur Mitarbeiterbeurteilung verwendet werden.

7.4

MAP – die Projektrollen im Team

129

Abb. 7.4 Selbsteinschätzungsformular (ausgefüllt)

Abb. 7.5 Selbsteinschätzungsformular (Auswertung)

7.4.5 Prozessverantwortlicher – der MAP-Beobachter Ein Prozessverantwortlicher ist derjenige, der den tatsächlich gelebten Prozess und seine Veränderung dokumentiert und die Einhaltung verabredeter Regeln und Praktiken überwacht. (Dies kann auch vom Qualitätsmanager übernommen werden!) Er muss profunde Kenntnisse in grundsätzlichen „Prototypen“ von Prozessmodellen haben und sich nicht scheuen, das angewandte Prozessmodell abzuändern und anzupassen. (Das ist immer nötig!) Im Zweifelsfall hat aber das Projekt und damit die Erfüllung des Auftrags Vorrang! Trotzdem hat es sich im studentischen Labor als vorteilhaft herausgestellt, ein Teammitglied zu haben, welches auf die Einhaltung der abgesprochenen Regeln und Praktiken, z.B. das regelmäßige Abhalten von Teamsitzungen und reflektierten Verbesserungen, drängt. Der Projektmanager ist für diese Aufgabe eher ungeeignet. Hier besteht ein Interessenkonflikt mit dem Erreichen des Projektziels.

130

7

MAP – Meta Agile Process Model

7.4.6 Projektrollen in der Landkarte der Verhaltensweisen In den Abbildungen 7.4 und 7.5 wird gezeigt, wie aus Selbsteinschätzung und Fremdeinschätzung eine Zuordnung zu einem oder mehrerer MAP-Typen im Team durchgeführt werden kann. Was noch fehlt, ist die Abbildung auf die anderen definierten MAP-Projektrollen. Hierzu wurde vom Autor eine zweite Folie entwickelt, die über das Selbsteinschätzungsformular gelegt werden kann. Hier findet neben den Verhaltensweisen eine Zuordnung zu den MAP-Projektrollen statt (Abb. 7.6). Im Beispiel sieht man die potenzielle Eignung zum Integrationsingenieur. Wichtig ist anzumerken, dass es sich um eine potenzielle Eignung handelt. Die fachliche Qualifikation und die Durchsetzungskraft muss diese Eignung bestätigen. Abbildung 7.7 zeigt MAP-Typen und Projektrollen übereinandergelegt.

Abb. 7.6 Zuordnung zu den Projektrollen (Auswertung)

Abb. 7.7 Verhaltensweisen und korrespondierende Projektrollen

7.5

MAP Cycle – der Referenzprozess

131

7.5 MAP Cycle – der Referenzprozess Ausgehend von den Erfahrungen des studentischen Labors kann ein „MAPMinimalprozess“ definiert werden (Abb. 7.8). Es ist wichtig, zu verstehen, dass es sich bei diesem Referenzprozess selbst auch nur um eine Best Practice handelt. Die letzten fünf Jahre im studentischen Labor haben einfach gezeigt, dass alle studentischen Teams mehr oder weniger diesem Prozess gefolgt sind. Dies hat sicher auch mit ihren Kenntnissen um iterativ-inkrementelle Prozesse zu tun. Am Anfang des Projects steht die Besetzung der zwingend notwendigen Projektrollen. Die Erfahrung der letzten fünf Jahre im studentischen Labor zeigt, dass es von Vorteil ist, zumindest Projektleiter und Qualitätssicherer ganz „klassisch“ vom Management zu besetzen.138 Neu ist, dass das Management sich auf die Selbsteinschätzungsbögen der Bewerber (Abb. 7.4) stützen kann bzw. sollte. Der MAP-Beobachter (Kap. 7.4.5) wird in der Praxis in der Regel von außen in das Projekt kommen, z.B. als externer Berater und Coach. Im studentischen Labor wird diese Rolle meist vom Autor übernommen. Der Integrationsingenieur sollte

Abb. 7.8 MAP-Referenzprozess (Minimalprozess, Best Practice)

138 Diese

Rolle übernimmt im studentischen Labor der Autor.

132

7

MAP – Meta Agile Process Model

aufgrund seiner „Bewerbungsunterlagen“ (Selbst- und Fremdeinschätzungsbogen) von Projektleiter und Qualitätssicherer ausgewählt werden.139 Im nächsten Schritt des MAP-Cycle wird das Team140 auf den Prozess bzw. den Meta-Prozess „eingeschworen“.141 Danach werden die User Stories geschrieben. Wie bereits erwähnt, wird diese Arbeit von einem „Kernteam“ geleistet (Kap. 6.3.2) – im studentischen Labor haben die Teammitglieder die Wahl, ob sie daran teilnehmen wollen oder nicht. (In der Praxis stoßen Teammitglieder, die nicht teilnehmen wollen, später zum Team.) Mit der Verteilung der User Stories beginnt der eigentliche Entwicklungszyklus: Zuerst wird der Aufwand für die einzelnen User Stories von den Mini-Teams geschätzt. Danach werden die User Stories implementiert und mit Hilfe des Integrationsingenieurs auf einem Rechner integriert. Das Ergebnis – die Release – wird dem Kunden vorgeführt. Abweichungen von den Kundenwünschen werden sofort erkannt und in Form neuer User Stories dokumentiert. Die Integrationszyklen bewegen sich, wie in agilen Projekten üblich, im Bereich von einigen Tagen bis zu ein bis zwei Wochen. Nach der Integration folgt zwingend eine Reflektionsphase. Diese liegt in der Verantwortung des MAP-Beobachters. Sie darf sehr kurz sein und kann z.B. in Form eines Stand-Up Meetings stattfinden, sie sollte aber nicht ausfallen. Wichtig ist, dass die Teammitglieder kurz den aktuellen Prozess, also ihr tägliches „Miteinander“ im Projekt besprechen, Stärken betonen und Schwächen benennen. Wichtig ist auch, sofort Gegenmaßnahmen zu benennen.142 Der MAP-Beobachter dokumentiert die Ergebnisse und stellt sie allen zur Verfügung.143 Die Session 2007 des studentischen Labors (Kap. 6.5.5) zeigt deutlich, dass viele Gespräche in kleinen Gruppen nicht zu einer Prozessverbesserung führen. Dies liegt daran, dass nicht alle Teammitglieder über die angedachten Verbesserungen informiert sind! Das Team braucht eine gemeinsame Reflektionssitzung. Nur so werden alle informiert und können die besprochene Prozessverbesserung auch „leben“. Nach der Reflektionssitzung bearbeitet das Team die nächsten User Stories. Diese können entweder aus vorherigen Iterationen noch übrig sein oder neu aus der Kundendemonstration der aktuellen Software-Release entstanden sein. Damit beginnt der nächste Zyklus.

139 Das

stärkt die Rolle des Qualitätssicherers im Verhältnis zu „klassischen“, nicht-agilen Projekten. 140 Ein Satz zum Team: Im studentischen Labor ist der Kurs der Studierenden das Team, in der Praxis sollten Entwickler die Möglichkeit haben, sich um eine Stelle im Team zu bewerben – natürlich mit ausgefülltem Selbst- und Fremdeinschätzungsbogen. 141 Auch für die Studierenden im Labor ist eine kurze Wiederholung von Vorteil – trotz vorheriger Vorlesung! 142 Schwächen, für die keine Gegenmaßnahmen benannt werden können (z.B. „politische“ Bedingungen im Firmenumfeld) lähmen das Team und sollten nicht in den Mittelpunkt gestellt werden. Allerdings schadet es nicht, sie zu dokumentieren. 143 Bewährt hat sich das Anlegen einer speziellen Rubrik im Projekt-Wiki.

7.6

MAP und Scrum

133

Ausdrücklich sei hier nochmals darauf verwiesen, dass es sich bei MAP Cycle um einen Referenzprozess (Minimalprozess) handelt. Im Vordergrund steht die Erfüllung der Bedingungen des Meta-Modells MAP. Es hat sich allerdings in den vergangenen fünf Jahren des studentischen Labors herausgestellt, dass die teilnehmenden studentischen Teams ohne größeres Zutun des Autors dem Prozess MAP Cycle gefolgt sind. Trotzdem gilt in Anlehnung an Kent Beck (Wells 2009): „Fix the actual MAP process if it breaks“. Ein gewählter Prozess ist also nur solange von Wert, wie er das Projekt voranbringt – und es nicht behindert! MAP ist ein Meta-Modell. Grundsätzlich kommen also auch andere Prozesse „unter“ MAP in Frage. Im folgenden Kapitel soll die Frage behandelt werden, ob das MAP-Team auch Scrum als Entwicklungsprozess folgen kann.

7.6 MAP und Scrum Um die Frage zu beantworten, ob Scrum mit MAP harmoniert, müssen zuerst die Unterschiede beleuchtet werden: MAP ist ein agiles Meta-Modell. Grundsätzlich geht MAP davon aus, dass es entscheidend ist, im Team die richtigen Leute zusammenzubringen, um Erfolg zu haben. Dies ist wichtiger als jedes gewählte Prozessmodell (Kap. 7.1). Scrum dagegen ist eine agile Prozessmanagementmethode. Hier geht es um die Frage, welche Projektrollen wie miteinander interagieren, um das Projekt – und damit das Produkt – voranzutreiben. Nicht beleuchtet werden in Scrum die Entwicklerpraktiken, die „Rules and Practices“ des Teams. Dies lässt Freiräume für die Integration z.B. der neuen MAP-Rolle Integrationsingenieur (Kap. 7.4.3). Die Frage ist also, ob Scrum der agile Managementprozess unterhalb MAP sein kann bzw. welche Anpassungen ggf. durchzuführen sind.

7.6.1 Vergleich der Rollen MAP als agiles Meta-Modell fordert folgende Rollen im Team: • • • • •

Kunde Kommunikationsmanager Integrationsingenieur Team Prozessverantwortlicher – der MAP-Beobachter Scrum als agile Managementmethode fordert folgende Rollen:

• Product Owner • Team • ScrumMaster

134

7

MAP – Meta Agile Process Model

Als zusätzliche Rollen werden erwähnt (Kap. 5.1.4) • Kunde • Anwender Übereinstimmende Rollen sind: • Team • Kunde/Anwender Im Folgenden sollen die Rollen miteinander verglichen bzw. auf „Kompatibilität“ überprüft werden. 7.6.1.1 Team und Integrationsingenieur In beiden Ansätzen spielt das Team die zentrale Rolle. MAP als Meta-Modell beschäftigt sich allerdings sehr stark mit der Zusammensetzung des Teams aus organisationspsychologischer Sicht (Kap. 7.3.4). Als Meta-Modell steht die Bildung des Teams im Vordergrund. Die Rolle des Integrationsingenieurs ist nur in MAP bekannt. Scrum als agiler Managementprozess beschäftigt sich nicht mit Praktiken und Rollen der SoftwareEntwicklung. Deshalb spricht nichts dagegen, diese Rolle im agilen Prozess beizubehalten. Aus dem studentischen Labor weiß man sogar, dass diese Rolle für den Erfolg des Projekts unabdingbar ist (Kap. 6.4) 7.6.1.2 MAP-Beobachter und ScrumMaster MAP-Beobachter und ScrumMaster sind augenscheinlich korrespondierende Rollen. Beide sind der „Freund des Teams“, unterstützen und coachen es, räumen Hindernisse im Prozess aus dem Weg. Die Unterschiede liegen im Detail. Während der ScrumMaster über den Prozess „wacht“ und seine Korrektheit überprüft, „beobachtet“ der MAP-Beobachter den Prozess. Natürlich sind beide für den Prozess verantwortlich. Da MAP aber einen sich verändernden Prozess zulässt, muss der MAP-Beobachter nicht zwingend eingreifen. Seine Aufgabe ist mehr die Moderation und Dokumentation des Veränderungsprozesses.144 Im studentischen Labor hat es sich allerdings als sehr nützlich erwiesen, dass der MAP-Beobachter immer wieder durch kleine Umfragen und provozierende Bemerkungen das Team veranlasst hat, seinen Prozess zu überdenken und unbewusste Praktiken ins Bewusstsein zu rufen (Kap. 6.5.6). Wenn MAP und Scrum kombiniert werden sollen, muss der Blick des ScrumMasters auf den Prozess erweitert werden. Er muss beginnen, das „reine“ Scrum als 144 Vergleicht man das mit CMMI, so haben wir sinngemäß einen wesentlich höheren „Reifegrad“

erreicht. Wir beschäftigen uns nicht nur mit dem Prozess (Reifegrad 2 bis 4), sondern mit dem Prozessänderungsmanagement (Reifegrad 5). (Siehe dazu auch Kneuper 2005).

7.6

MAP und Scrum

135

Startprozess zu verstehen, der im Laufe des Projekts Veränderungen durchmacht. Kein Prozess hat im studentischen Labor der letzten fünf Jahre in seiner reinen Form „überlebt“. Alle Prozesse wurden vom Team angepasst. Wichtig ist allerdings, dass diese Anpassung bewusst geschieht.145 So wurde z.B. im studentischen Labor 2009 Scrum zweimal erweitert (Kap. 6.5.6): • Schon am ersten Tag bildete sich ein „User Story Kernteam“ aus Kunde, Product Owner und fünf interessierten Teammitgliedern, welche den Product Owner beim Verständnis der Kundenanforderungen unterstützte. Dies ist im reinen Scrum nicht vorgesehen. • Am dritten Tag schuf das Team die Möglichkeit, dass Teammitglieder mit freien Ressourcen oder mit neuen Ideen, potenzielle Story Cards formulieren und ins System „einspeisen“ konnten. Die neue Team-Rolle der Story Koordinatorin wurde geschaffen, welche die Aufgabe hatte, eine Vorauswahl dieser Ideen zu treffen und an den Product Owner weiterzureichen. Interessant war die Variante, dass solcherart „nachgeschobene“ Story Cards in den laufenden Sprint hineingenommen werden konnten, ohne das Ende des Sprints zu beeinflussen. Der ScrumMaster muss in der Lage sein, solche Prozessänderungen zu begleiten und ihren geregelten und bewussten Ablauf zu gewährleisten. Er erweitert somit seine Rolle zum MAP-Beobachter. 7.6.1.3 Kunde, Kommunikationsmanager und Product Owner In der Abbildung dieser Rollen besteht der größte Klärungsbedarf. Der Product Owner (Kap. 5.1.1) ist produktverantwortlich und übernimmt die Sicht des Endkunden. Damit entspricht er durchaus dem Kunden im MAP. Der Unterschied ist, dass er nicht der Kunde ist. In MAP tritt ein realer Kunde auf, wie auch in XP gefordert (Kap. 3.5.5). Der MAP-Kunde hat keine Projektverantwortlichkeit, abgesehen von der Verantwortlichkeit für die User Stories. Er steuert die Software-Entwicklung nicht. Diese Aufgabe übernimmt in der Regel einer der MAP-Kommunikationsmanager, der in die Rolle des Projektleiters schlüpft. Diese Rolle ist in Scrum nicht vorgesehen. Ihre Aufgaben sind zwischen Product Owner, Team und ScrumMaster aufgeteilt (Pichler 2008). Allerdings verlangt MAP die Rolle des Projektleiters nicht zwingend. Diskussionen des Autors insbesondere mit kleinen Entwicklungsteams aus Unternehmen zeigen, dass durchaus auch ohne Projektleiter gute Projektresultate erzielt werden können. Auch ein MAP-Projektteam kann also die Aufgaben des Projektleiters auf die Teammitglieder und MAP-Rollen verteilen. Ein Kommunikationsmanger kann die Rolle des Product Owners einnehmen, insbesondere, da Kommunikation explizit als eine Aufgabe des Product Owners genannt ist (Kap. 5.1.1). Auch Anforderungs-

145 Siehe

hierzu als eher negatives Beispiel Kap. 6.5.5.

136

7

MAP – Meta Agile Process Model

und Release-Management können als klassische Projektmanager-Aufgaben vom Kommunikationsmanger übernommen werden. Die Frage ist allerdings, woher das Wissen um die Anforderungen kommt. Dazu muss der Product Owner Kundenwissen haben. Dies muss er sich von Kunde und Anwender besorgen.146 Hier besteht ein großer Unterschied zwischen dem MAP-Referenzprozess und Scrum. Im MAP-Referenzprozess kann sich grundsätzlich jedes Teammitglied, zusammen mit dem Kunden, am Erstellen der User Stories beteiligen. In der Regel übernimmt ein Mini-Team („User Story Kernteam“, Kap. 6.3.2) diese Arbeit des Scrum-Product Owners. Die Reduktion dieser wichtigen Aufgabe auf eine Person, den Product Owner, empfindet der Autor als Nachteil, da die Gefahr besteht, dass der Product Owner zum „Flaschenhals“ für das Projekt wird. Selbst im studentischen Labor 2009, in dem Scrum als Prozess genutzt wurde, bildete sich dieses „User Story Kernteam“ spontan am ersten Tag (Kap. 6.5.6). Der „soziale Druck“ ein solches, den Product Owner unterstützendes User Story Kernteam zu bilden, reduziert sich auf natürliche Weise, wenn der Product Owner genügend produktspezifisches Wissen hat und Fragen des Teams zu den Anforderungen kompetent beantworten kann. In diesem Spezialfall ist die Reduktion des ursprünglichen (und meist spontanen) „Spezifikations-Kernteams“ auf eine einzige Rolle, den Product Owner, möglich und vertretbar. Eine Kombination von MAP als Meta-Modell und Scrum als „unterliegender“ agiler Managementprozess ist unter diesen Randbedingungen möglich.

7.6.2 Bestimmung des Product Owners Wie bereits aufgezeigt, ist die Wahl eines geeigneten Product Owners essenziell für den Erfolg eines agilen Projekts.147 Üblicherweise ist der Product Owner „gesetzt“, entweder aufgrund seiner hervorragenden Produktkenntnisse oder weil er gewisse Managementerfahrungen mitbringt. In diesem Kapitel soll exemplarisch aufgezeigt werden, wie man mit Hilfe von MAP die Suche nach einem guten Product Owner systematisieren kann.148

146 Der

Autor fragt sich bei Scrum generell, wie es der Product Owner schafft, so detailreiches Wissen um die Produktanforderungen zu erwerben, wie es der Kunde hat: Die Erfahrung des Autors aus Praxisprojekten lehrt, dass die Person, die das Wissen um das künftige Produkt hat (der Kunde) und die Person, die das Wissen um die Führung des Projekts hat (üblicherweise der Projektmanager) selten ein und dieselbe Person sind. Also muss ein Wissenstransfer stattfinden ohne Verlust an Information. Der Autor hält es für besser, wenn das Team sich diese Informationen direkt beim Kunden abholen und nicht (gefiltert) beim Product Owner. Diese Ansicht wird auch durch die Erfahrungen mit der spontanen Bildung des „User Story Kernteams“ im studentischen Labor 2009 bestätigt (Kap. 6.5.6). 147 Dies gilt natürlich nicht nur für agile Projekte! 148 Im studentischen Labor steht der Autor ständig vor der Entscheidung, aus den Studierenden des Kurses den geeigneten Product Owner herauszufinden.

7.6

MAP und Scrum

137

Im studentischen Labor 2009, in dem Scrum als Prozess vorgegeben war, wurde mit Hilfe von MAP eine Vorauswahl für die Besetzung wichtiger Rollen, insbesondere des Product Owners, getroffen.149 Dazu konnten sich die Studierenden, wie in Kap. 7.4.4 beschrieben, mit Hilfe eines vom Autor entwickelten Formulars (Abb. 7.4) selbst einschätzen. Ebenfalls baten sie zwei ihrer Kommilitonen um eine Fremdeinschätzung ihrer Person.150 Diese drei ausgefüllten Formulare wurden zusammengefasst: Alle Eigenschaften, die in allen drei Formularen angekreuzt waren, wurden dunkelgrau markiert, alle, die zweimal angekreuzt waren, wurden hellgrau markiert. Einmalige Nennungen wurden nicht berücksichtigt. Abbildung 7.9 zeigt die solchermaßen gewichteten Eigenschaften151 des späteren Product Owners. Im nächsten Schritt wurde die „Landkarte“ der Verhaltensweisen im Team über das so erstellte Einschätzungsformular gelegt (Abb. 7.10). Durch einfaches Auszählen der überdeckten „Kästchen“ im Einschätzungsformular und Gewichten der hellgrauen Flächen mit 2/3 ergibt sich in diesem Fall eine • 100%ige Eignung zum Kommunikator • 90%ige Eignung zum Qualitätsprüfer • 75%ige Eignung zum Experten Gewichtet man für einen guten Product Owner die Fähigkeit zum Kommunikator mit 50%, die Eignung zum Qualitätsprüfer mit 30% und ein gutes Troubleshooting

Abb. 7.9 Formular für Selbst-/Fremdeinschätzung im studentischen Labor (gewichtet)

149 Dazu

kam noch die wichtige MAP-Teamrolle des Integrationsingenieurs. war die Teilnahme an der Selbst-/Fremdeinschätzung freiwillig. 151 Im Verlauf des Verfahrens kam es zu Diskussionen um die Bedeutung der Haupteigenschaft „erfahren“. Da sie in der Rubrik der allgemeinen menschlichen Eigenschaften steht, einigte man sich auf eine allgemeine menschliche Lebenserfahrenheit bzw. Lebensweisheit. 150 Natürlich

138

7

MAP – Meta Agile Process Model

Abb. 7.10 Landkarte der Verhaltensweisen des späteren Product Owners im studentischen Labor

mit 20%, ergibt sich in diesem Fall eine Eignung zum Product Owner mit 77%.152 Führt man diese Analyse mit allen Beteiligten durch, ergibt sich ein Ranking der geeignetsten Product Owner. Nicht berücksichtigt sind in dieser Analyse allerdings die Produktkenntnisse. Es wird davon ausgegangen, dass potenzielle Bewerber über ausreichende Produktkenntnisse verfügen. Im studentischen Labor sind die Projekte so gewählt, dass üblicherweise kein Studierender über ausgewiesene Produktkenntnisse verfügt. Um keine Missverständnisse aufkommen zu lassen: Der Autor ist erklärter Gegner einer „Pseudo-Genauigkeit“. Diese einfache Analyse darf niemals mehr als ein Indiz für die Besetzung einer Projektrolle sein. Das Ranking der Beteiligten bezüglich der Eignung für eine Projektrolle nach MAP kann aber zur Objektivierung der Entscheidung beitragen. Im studentischen Labor wurde das Ranking allen Beteiligten vorgestellt und diskutiert. Durch Befragung der Betroffenen wurde der erste Eindruck verfeinert und per Akklamation durch das Team bestätigt.153 Der Erfolg des 2009er Projekts (und der geringere Erfolg eines Nachfolgeprojektes 2010 mit veränderter Rollenbesetzung) bestätigte im Nachhinein die Auswahl.

152 Die Eigenschaft „belastbar“ wurde nur einmal in einer Fremdeinschätzung angekreuzt. Anfangs

war dem Autor nicht klar, ob das eine Einschränkung für die Besetzung der Rolle Product Owner sein könnte. Die Bedenken konnten aber während des äußerst erfolgreichen Projekts ausgeräumt werden: Wichtig ist vor allem die Belastbarkeit der Teammitglieder während eines Sprints. Der Product Owner ist von dieser Art des „Stresses“ weniger betroffen. 153 Es ist dem Autor bewusst, dass so viel „Demokratie“ in den meisten Unternehmen nicht üblich ist. Ein intensives Gespräch mit den Kandidaten kann aber den ersten Eindruck durch MAP festigen oder aber auch nicht bestätigen.

7.6

MAP und Scrum

139

7.6.3 Prozess Betrachtet man den Scrum-Flow (Abb. 5.2), sieht man, dass nach Erstellung des Product Backlogs der eigentliche iterative Prozess beginnt – der Sprint. Wie passen die Besonderheiten des Sprints zu MAP? 7.6.3.1 Sprintlänge Das Besondere ist, dass der Sprint eine fixe Dauer hat, z.B. 30 Tage. Dies ist ein Unterschied zum MAP-Referenzprozess, wie im Übrigen auch zu anderen agilen Ansätzen. Die fixe Sprint-Dauer widerspricht aber MAP nicht. MAP als MetaModell äußert sich nicht zu dieser Frage, sondern überlässt die Festlegung der Iterationsdauer ausschließlich dem Team. Während Scrum die fixe Sprintdauer fordert, tut MAP das nicht. Wenn das Team sich aber darauf festlegt, ist das im Rahmen des MAP Meta-Modells kein Problem154 ! 7.6.3.2 Sprint-Planungssitzung In jedem iterativ-inkrementellen Prozess muss eine Planung der nächsten Iteration stattfinden. Im studentischen Labor geschieht das im Zusammenspiel von Kunden, Kommunikationsmanger und Team. Wie aus dem Vergleich der MAPund der Scrum-Rollen bekannt ist (Kap. 7.6.1), ist das kein Widerspruch. SprintPlanungssitzungen sind im Rahmen des MAP Meta-Modells eine sinnvolle Praxis. 7.6.3.3 Daily Scrum Der Daily Scrum ist eine tägliche, zeitlich fixierte Teamsitzung (Abb. 7.11). Solche Sitzungen gibt es auch in anderen agilen Praktiken. XP bevorzugt ein Standup Meeting (Wells 2009). Auch die MAP-Teams im studentischen Labor haben – unabhängig vom gewählten Prozess – solche Meetings regelmäßig (in der Regel am Vormittag) abgehalten. Die tägliche Abstimmung des Teams wurde dabei als sehr zielführend betrachtet. Die Integration dieser Praxis in ein MAP-Projekt stellt somit überhaupt kein Problem dar. 7.6.3.4 Sprint Review Diese Praxis muss für jedes agile Projekt zentral sein. Der Kunde muss in kurzen Abständen – nach jeder Iteration – mittels einer Demonstration über den aktuellen Stand des Software-Produkts informiert werden. Geschieht dies nicht, kann

154 Im studentischen Labor wird die fixe Sprint-Länge gut angenommen. Sie gibt den Studierenden

eine zeitliche Orientierungshilfe – einen Zeitpunkt, auf den sie hinarbeiten können.

140

7

MAP – Meta Agile Process Model

Abb. 7.11 Daily Scrum im studentischen Labor 2009

die Feedback-Schleife zum Kunden nicht funktionieren.155 Eine Integration dieser Praxis in einen agilen Prozess unter MAP ist unerlässlich. Neu ist lediglich die zeitliche Ausdehnung. Scrum verlangt ein Timeboxing von maximal vier Stunden. MAP legt hier natürlich keine Zeiten fest. Dies wäre bei einem Meta-Modell auch seltsam. Das MAP-Team weiß aufgrund seiner Kompetenz, wie lange die Review-Sitzung zu dauern hat. Da allerdings auch bekannt ist, dass Sitzungen über vier Stunden kaum noch produktiv sind, ist diese Scrum-Forderung kein grundsätzliches „Killer-Argument“ gegen eine Verknüpfung von MAP und Scrum. 7.6.3.5 Sprint Retrospektive Die Idee, regelmäßig über den Prozess zu reflektieren, ist nicht neu und auch vom agilen Prozessmodell Crystal bekannt. Sie ist sogar zwingend notwendig und wird im studentischen Labor regelmäßig angewandt (Kap. 6.5.5). Die Prozessreflektion dient der Optimierung des Prozesses und widerspricht MAP nicht. Neu ist auch hier die zeitliche Beschränkung auf drei Stunden. Aus den oben diskutierten Gründen ist das aber keine Einschränkung, die Sprint Retrospektive als Praxis in einen agilen Prozess unter MAP mit einzubeziehen. Im studentischen Labor wurde lediglich das regelmäßige Auftreten der Sprint Retrospektive nach jedem Sprint bemängelt. Das Team erweiterte den Prozess dahingehend, dass man sich das Recht herausnahm, die Sitzung ggf. sehr kurz ausfallen zu lassen. Der ScrumMaster (d.h. der Autor) bestand aber auf der Retrospektiv-Sitzung nach jedem Sprint.

155 Man

muss immer daran denken, dass die Spezifikation des Produkts in agilen Projekten eher dürftig ist!

7.6

MAP und Scrum

141

7.6.4 Artefakte Als letztes werden die geforderten Scrum-Dokumente (Kap. 5.3) auf „MAPKompatibilität“ geprüft. 7.6.4.1 Product Backlog Im studentischen Labor entsteht ein Product Backlog als Sammlung von User Stories (die bereits aus XP bekannt sind). Grundsätzlich müssen diese Stories in jedem agilen Prozess priorisiert und geschätzt werden. Das Product Backlog ist somit ein spezielles agiles Anforderungsdokument und kann in jeden agilen Prozess unter MAP integriert werden. In der Praxis des studentischen Labors 2009 gab es jedoch kritische Einwände des Product Owners gegen die geforderte Aktualität der Product Backlogs. In einem Statement zum Abschluss des sehr erfolgreichen Projekts schrieb er: Das Product Backlog erwies sich als zu zeitaufwändig und mit wachsendem Umfang schlicht nicht flexibel genug, um regelmäßig aktualisiert zu werden, insbesondere was die Priorisierung anging. Stattdessen verkümmerte es mehr und mehr zu einem Ideenvorrat, welcher bei der Releaseplanung und beim Erstellen der User Stories für den nächsten Sprint lediglich überflogen wurde. Hilfreich war es erst, als die einzelnen Punkte nach Kategorien geordnet wurden, um einen besseren Überblick zu haben. Ob dies jedoch in Tabellenform geschehen muss? Ein Stift und einige wenige Notizblätter erfüllen den gleichen Zweck, zumindest in einem so kurzen Projekt mit entsprechend kurzen Sprints und knapper Vorbereitungszeit. Tatsächlich war für ihn das Sprint Backlog das Steuerungsinstrument seiner Wahl, was im Projektablauf nicht als störend empfunden wurde. 7.6.4.2 Sprint Backlog Im Rahmen der Iterationsplanung kristallisieren sich die Anforderungen heraus, die in der Iteration umgesetzt werden sollen. Das Team definiert die Aktivitäten, die notwendig sind, um diese Anforderungen zu implementieren, und hält die Aktivitätenliste, das Sprint Backlog, aktuell. Es spricht nichts dagegen, diese Praxis und das zugehörige Dokument in einen agilen Prozess unter MAP zu integrieren. Im studentischen Labor 2009 wurde hier ausschließlich und mit großem Erfolg die Variante Sprint Backlog als User Stories gewählt (Wirdemann 2009). 7.6.4.3 Releaseplan und Burndown-Chart Auch agile Projekte müssen Releases planen, soweit das eben möglich ist. Um den Projektablauf zu verfolgen, ist es sinnvoll, dies mit dem Erstellen einer Release

142

7

MAP – Meta Agile Process Model

Burndown Chart (Abb. 5.5) zu tun. Auch hier gibt es keine Probleme, diese Praxis und die dazu gehörigen Dokumente in einen agilen Prozess unter MAP zu integrieren.156

7.6.5 MAP und Scrum – geht das? Die vorhergehenden Analysen der Projektrollen und der Vergleich zwischen Scrum und dem MAP-Referenzprozess zeigen auf, dass es möglich ist, Scrum als agilen Prozess „unter“ dem Meta-Modell MAP zu implementieren. Erste, sehr positive Erfahrungen zu diesem Ansatz gibt es bereits im studentischen Labor 2009. Es ist allerdings darauf zu achten, dass folgende Bedingungen erfüllt werden: Die Sichtweise des ScrumMasters auf den agilen Prozess muss erweitert werden: Der MAP-Beobachter, der jetzt als ScrumMaster agiert, muss das „reine“ Scrum als Startprozess verstehen, der ggf. Veränderungen durchmacht, die von Scrum wegführen. In der Sprint Retrospektive hat das Team Gelegenheit, neue Praktiken einzuführen, die nicht Scrum sind. Dies ist in agilen Prozessen unter MAP erlaubt. Das Team hat durch seine Zusammensetzung und sein Wissen die Kompetenz, dies zu tun. Der MAP-Beobachter erweitert die klassische ScrumMaster-Rolle derart, dass er diesen Veränderungsprozess nicht unterbindet, sondern moderiert. Allerdings wird er dem Team helfen, die Sinnhaftigkeit der Veränderung zu prüfen, und er wird die Veränderung dokumentieren. Nähe zwischen Kunde und Team muss erhalten bleiben: Durch Einführen von Scrum wird das aus MAP bekannte Spezifikations-Kernteam auf eine einzige Scrum-Rolle, den Product Owner, reduziert. Dadurch schiebt sich der Product Owner zwischen Team und Kunde. Deshalb ist es im Sinne von MAP wichtig, dass der Kontakt zwischen Kunde und Team trotzdem hinreichend eng ist, so dass Fragen des Teams zu den Anforderungen kompetent und aus erster Hand beantwortet werden.157 Somit können Unklarheiten bezüglich der Spezifikationen schnell und auf direktem Weg geklärt werden. Es ist zwar akzeptabel, dass nur der Product Owner das Product Backlog erstellt und priorisiert, nicht aber, dass er zwischen Kunde und Team steht, wenn es darum geht, Anforderungen an das Software-Produkt zu hinterfragen. Länge von Sprint Review und Retrospektive sind nicht unumstößlich: Die von Scrum vorgegebenen Längen der Sprint-Sitzungen, insbesondere des Sprint Reviews und der Sprint Retrospektive, dürfen nicht zum Dogma werden. Das MAPTeam ist aufgrund seiner Zusammensetzung selbst in der Lage, zu entscheiden, ob die vorgegebene Länge der Sitzung im Einzelfall ausreicht. Klar ist aber auch, dass zu lange Sitzungen unproduktiv sind. Der ScrumMaster (dargestellt vom

156 Diese

Artefakte wurden im studentischen Labor 2009 vom Product Owner als hilfreich bezeichnet und gut angenommen. 157 Es ist nicht sinnvoll, dass das Team den Product Owner und dieser den Kunden fragt (Phänomen der „Stillen Post“).

7.7

MAP im regulierten Umfeld

143

MAP-Beobachter) erweitert seine Rolle dahingehend, dass er das Team in der Entscheidung unterstützt, eine Scrum-Sitzung weiterzuführen oder zu unterbrechen bzw. abzubrechen. Sind die diskutierten Bedingungen erfüllt, steht einer Kombination aus dem agilen Meta-Modell MAP und Scrum als unterliegendem agilen Prozess nichts mehr im Weg.

7.6.6 Vorteile für Scrum-Anwender Eingefleischte Scrum-Anwender mögen sich fragen, was der Vorteil für sie ist, MAP als Prozess-„Oberbau“ zu installieren. Bietet Scrum nicht schon alles, was das agile Projekt braucht? Nein sagt der MAP-Befürworter. Scrum ist eine agile Projektmanagment methode. Scrum sagt nichts über den eigentlichen Entwicklungsprozess aus, und es gibt auch keine klare Praxis bezüglich des Aufbaus des Teams. MAP steuert neben der Teampsychologie auch die unglaublich wichtige Rolle des Integrationsingenieurs bei. Wie aus dem studentischen Labor seit 2004 bekannt ist, ist die gute Besetzung dieser wichtigen Projektrolle mitentscheidend für den positiven Verlauf eines Projekts: Die Projektphase der Integration ist der Schwachpunkt agiler Projekte! Hier wird durch die Besetzung der neuen agilen Rolle des Integrationsingenieurs gegengesteuert! MAP stellt ausdrücklich die Beziehung des Teams zum Kunden in den Vordergrund (insbesondere in Bezug auf Fähigkeiten und Erreichbarkeit des Kunden). Außerdem wird die Kommunikation im Team durch die Besetzung eines oder mehrerer Kommunikationsmanger aktiv gestärkt. Natürlich ist auch der Product Owner in diesem Sinne ein Kommunikationsmanager, aber das Projektteam hat in der Regel mehrere davon.158 Man sieht also, dass MAP und Scrum die Schwerpunkte anders legen. Geht es in Scrum um den agilen Managementprozess mit klarer Rollenverteilung, klaren Prozessabläufen und Dokumenten,159 liegt der Fokus bei MAP in der Zusammensetzung des Teams, immer getreu dem Motto: Ein korrekt zusammengesetztes Team weiß, was es tun muss! Dies beinhaltet ausdrücklich auch die Möglichkeit, den verfolgten Prozess anzupassen und zu optimieren.160

7.7 MAP im regulierten Umfeld Auch im von Behörden regulierten Umfeld, z.B. in Pharma-IT-Projekten, insbesondere in der Forschung, existiert großer Bedarf an agilen Techniken. Auch dort 158 Auch

dies ist eine Erfahrung aus dem studentischen Labor der letzten fünf Jahre. Sicht klassischer Projektmanager sind die neuen Rollen sicherlich auch etwas eigenwillig gewählt. 160 siehe hierzu die Fallbeispiele in Kap. 6.5. 159 Aus

144

7

MAP – Meta Agile Process Model

gibt es oft einen Kunden oder Nutzer des Software-Systems, dessen Anforderungen sich im Laufe des Projekts ändern oder grundsätzlich noch nicht ausformuliert sind. Problematisch sind jedoch die von den Behörden geforderten Dokumente: Es ist üblich, dass am Anfang des Projekts ausführliche Benutzerspezifikationen, sog. User Requirement Specifications (URS), geschrieben werden, gegen die dann getestet werden kann. Meist wird auch behördenseitig das V-Modell als Vorgehensmodell gefordert (Kap. 1.4). Grundsätzlich muss also zuerst mit Hilfe einer Risikoanalyse geprüft werden, ob ein Projekt überhaupt für den Einsatz einer agilen Technik wie MAP geeignet ist. Projekte, die z.B. in Crystal (Kap. 4.1) das Risikoattribut „L“ (Loss of Life) erhalten würden, scheiden sicher aus.161 Es gibt aber viele Projekte mit geringerem Risiko, z.B. im Bereich der klinischen Forschung oder auch der Bioinformatik, die für agile Techniken geeignet erscheinen und in denen auch heute schon agile Techniken angewandt werden.162 Im Folgenden wird eine grundsätzlich neue Idee vorgeschlagen, wie agile Projekte im regulierten Umfeld angegangen werden sollen, so dass einerseits der agile Prozess „gefahren“ werden, aber auch andererseits eine für die Behörden ausreichende Dokumentation erstellt werden kann. Dazu muss MAP Cycle, der MAP-Referenzprozess, erweitert werden (Abb. 7.12). Im regulieren Umfeld muss das Erstellen • von Testszenarien163 • einer Risikoanalyse zur Gewichtung der Tests • eines Qualitätssicherungsplans (Qualifizierungsplans) mit Qualitätssicherungsstrategie • detaillierter Test Cases explizit gefordert werden. Allerdings werden im regulierten Umfeld üblicherweise detaillierte Spezifikationen gefordert. Agile Prozesse sehen dies gerade nicht vor. Ein Ausweg aus dieser Problematik ist die Strukturierung der User Stories: Die Anforderungen werden wie gewohnt strukturiert, aber nicht ausformuliert. Hier reicht die Darstellung als User Stories.164 Statt auf ausformulierte Spezifikationen legt der hier vorgestellte Ansatz den Schwerpunkt auf ausformulierte und detaillierte Test Cases, also

161 Dies betrifft z.B. Software in Anlagen zur Wirkstoff- und Medikamentenproduktion. Hier kann

z.B. das V-Modell XT angewandt werden, das in der aktuellen Version mit iterativen Projekten umgehen kann. In der Praxis sollte die Zahl der Iterationen allerdings nicht zu hoch sein. 162 Der Autor steht diesbezüglich in ständiger Diskussion mit Pharma-IT-Spezialisten insbesondere in der Forschung, die den Einsatz agiler Techniken bestätigen. 163 Testszenarien sind grobe Darstellungen möglicher Testabläufe. 164 Das heißt, dass pro Anforderung nur ca. drei Halbsätze formuliert werden. Die Details sind dann im Gespräch mit dem Kunden zu identifizieren.

7.7

MAP im regulierten Umfeld

145

Abb. 7.12 MAP-Referenzprozess im regulierten Umfeld

ein System von Software-Testfällen, die jederzeit die korrekte Funktionalität der Software nachweisen. Idealerweise kann bzw. sollte hier mit automatisierten Tests gearbeitet werden. Da beim Erstellen der User Stories (anstelle der Spezifikationen!) üblicherweise noch zu wenig Details für Test Cases bekannt sind, werden dort zuerst Testszenarien erstellt. Hier wird der grobe Ablauf der zu erstellenden Tests definiert. Mithilfe der darauf folgenden Risikoanalyse und der Qualitätssicherungsstrategie165 werden die Tests gewichtet166 und ihr grundsätzlicher Ablauf definiert. Die detaillierten Test Cases ersetzen also die üblichen ausführlichen Spezifikationsdokumente (Abb. 7.13). Ändern sich die Anforderungen an das SoftwareSystem, so ändern sich naturgemäß auch die entsprechenden Test Cases. Es reicht also völlig aus, die Tests anzupassen. Der überflüssige Schritt einer etwaigen Anpassung von Spezifikationsdokumenten entfällt! Dies geschieht im Einklang mit dem agilen Gedanken, keine Dokumente zu pflegen, die man nicht für den Fortschritt des Produkts benötigt.

165 Die 166 Wie

Qualitätssicherungsstrategie steht im Qualitätssicherungsplan (Qualifizierungsplan). viele Tests sind durchzuführen?

146

7

MAP – Meta Agile Process Model

Abb. 7.13 Strukturierte Test Cases „ersetzen“ ausführliche Spezifikationsdokumente

7.8 MAP-Projekt in der Industrie Im Rahmen einer Diplomarbeit bei der Evonik Degussa GmbH konnte das Funktionieren des agilen Meta-Modells MAP in der Praxis nachgewiesen werden (Wolf 2008). Ziel der Arbeit war die Entwicklung einer Web-basierten SchulungsverwaltungsSoftware für das Werk Rheinfelden in einem agilen Software-Entwicklungsteam von sieben Mitarbeitern. Die Aussage von MAP, dass sich der Prozess in einem geeigneten Team selbstständig entwickelt, wurde bestätigt. XP bildete lediglich den „Methodenbaukasten“ mit dessen Hilfe sich ein eigener SoftwareEntwicklungsprozess bildete. Die Abweichungen vom „reinen“ XP wurden in der Arbeit dokumentiert167 . Die Autorin beschreibt die Bildung des SoftwareEntwicklungsprozesses wie folgt: Es ist schwer, einen neuen perfekten Prozess zu definieren, und dies ist auch häufig ein falscher Ansatz. Viel eher sollte sich ein erfolgreicher Prozess selbstständig im Projekt entwickeln. Dazu reichen oft nur wenige Ausgangsregeln, wie der Autor in [30]168 mit seinem definierten Ansatz des „Meta Agile Process Model“ beschreibt. Dem entsprechend verlief auch die Entwicklung des neuen Softwareentwicklungsprozesses in der IT-Abteilung. XP diente hier als ein „Baukasten“, aus dem geeignete Methoden ausgewählt und im Projekt angewendet wurden.

Im neu entwickelten Prozess wurden folgende Rollen definiert und besetzt: • Kunde • Projektleiter 167 Zum

Beispiel verzichtete das Team recht schnell auf das Pair Programming (siehe dazu auch Kap. 6.5.3). 168 Zitiert wird hier der Artikel des Autors in (Hanser 2008).

Literatur

• • • •

147

Qualitätsmanager Entwickler Tester Integrierer

Insbesondere die Existenz des MAP-Integrationsingenieurs wurde somit als unabdingbar für den Erfolg des Projekts angesehen. Da die Kundenakzeptanz der vorigen Schulungsverwaltungs-Software nicht sehr groß war, wurde außerdem großer Wert auf die umfassende Einbeziehung des Kunden in das Projekt gelegt. MAP konnte also in diesem Industrieprojekt bestätigt werden.

Literatur Baldegger R (2004) Erfolgreich im Team. Riviera: Baldegger Verlag Baldegger R, Gotsmann L (2001) Ganzheitliches Projektmanagement. Riviera: Baldegger Verlag Beck K (2000) Extreme Programming. Boston, MA: Addison Wesley Cockburn A (2005) Crystal Clear: A human powered Methodology for small Teams. Upper Saddle River, NJ: Pearson. Dt. Übersetzung: Crystal Clear: Agile Software-Entwicklung für kleine Teams. Bonn: MITP-Verlag Hanser E (2008) Agile Software-Entwicklung: Das „Projektmanagement-Labor“ der BA Lörrach. In Dorn K.-H. et al. (Ed.) Innovationen durch Projektmanagement – oder?! Beiträge zur Konferenz „interPM“. Heidelberg: dpunkt Verlag Hanser E (2009) www.gpm-infocenter.de/PMMethoden/MAP. Zugriff Dezember 2009 Kneuper R. (2005) CMMI – Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. Heidelberg: dpunkt Verlag Pichler R (2008) Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg: dpunkt Verlag Wells D. (2009) www.extremeprogramming.org. Zugriff Oktober 2009 Wirdemann R (2009) Scrum mit User Stories. München:Hanser Wolf O (2008) Entwicklung eines Schulungsverwaltungssystems unter Anwendung der Methoden des Extreme Programmings. Diplomarbeit, Berufsakademie Lörrach