SOFTWARETECHNIK & ENTWICKLUNGSWERKZEUGE

Transkript

1 Collin Rogowski SOFTWARETECHNIK & ENTWICKLUNGSWERKZEUGE Veranstaltung im WS 2009/10, Duale Hochschule Baden-Württemberg, Karlsruhe - Skript - 1

2 Software Engineering 6 Software Entwicklung als eigenständige Disziplin 6 Das Wasserfallmodell 7 Big Design Up Front 8 Das Wasserfallmodell in der Praxis 9 Agile Software Entwicklung 12 Die Wurzeln der agilen Software Entwicklung 12 Agile Manifesto 13 Individuals and interactions over processes and tools 13 Working software over comprehensive documentation 15 Customer collaboration over contract negotiation 15 Responding to change over following a plan 16 (Unbequeme) Wahrheiten 16 Schlanke Prinzipien 17 Eliminiere Verschwendung 17 Unfertige Arbeit 17 Unnötige Prozesse 18 Multi-Tasking 18 Aufspüren von Verschwendung 18 Entscheide so spät wie möglich 19 Schaffe Integrität 22 Wahrgenommene Integrität 22 Konzeptuelle Integrität 22 Betrachte das Ganze 23 Scrum 23 2

3 Herkunft 23 Aufbau 24 Sprint 24 Rollen 24 Product Owner 24 Scrum Master 25 Team 25 Artefakte 26 Product Backlog 26 Releaseplan 27 Sprint Backlog 27 Burndown Chart 28 Meetings 29 Daily Scrum 29 Sprint Planung 30 Sprint Review 30 Sprint Retrospektive 30 Scrum auf einen Blick 31 Extreme Programming 31 Entstehung 32 Aufbau 32 Werte 32 Prinzipien 33 Praktiken 33 User Stories 34 3

4 Rhythmus 35 Planen 35 Planungsdreieck 36 Planen (Fortsetzung) 37 Pair Programming 38 Continuous Integration 38 Test-First 39 Root-Cause Analysis 40 Gemeinsamer Code 40 Abhängigkeiten von Praktiken 41 CI & TDD 41 Rhythmus & gemeinsamer Code 41 gemeinsamer Code & Pair Programming 41 gemeinsamer Code & TDD 41 Pull versus Push 41 Push 42 Pull 42 Test Driven Development 43 Test schreiben 43 Red 43 Bug fixen 43 Grün 44 Refactor 44 Beispiel: Dreieckserkennung 45 Aufgabe 45 4

5 Red 45 Green 45 Refactor 45 Red 45 Green 46 Refactor 46 Red 46 Green 46 Refactor 47 Rot Grün 47 Fake it! 48 Naheliegende Implementation 48 Triangulation 49 Test Design 49 Testen von GUIs 49 Testen von komplexen Komponenten 52 Testen von Grenzfällen 54 Bibliographie 56 5

6 Software Engineering Software Engineering - zu deutsch Softwaretechnik - ist derjenige Teil der Informatik, welcher sich mit Modellen zur Erstellung von Software befasst. Die IEEE definiert Software Engineering als [IEEE, 2004] (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (I). Eine umfassende Beschreibung dieses Feldes findet sich im Software Engineering Body of Knowledge (SWEBOK) [Abran, 2004]. Dieser identifiziert 10 Bereiche, mit denen sich Software Engineering im wesentlichen befasst: 1. Software requirements 2. Software design 3. Software construction 4. Software testing 5. Software maintenance 6. Software configuration management 7. Software engineering management 8. Software engineering process 9. Software tools and methods 10. Software quality Diese Veranstaltung thematisiert hauptsächlich Themen aus den Bereichen 4, 7 und 8, also den Vorgehensmodellen zur Software Entwicklung und der Organisation dieser in Projekten. Für den Einfluss agiler Entwicklung auf das Programmieren an sich, also Codeerstellung, Software Design, etc., sei auf [Martin, 2009], [McConnell, 2004], [Fowler, 1999] und [Gamma, 1996] verwiesen. Software Entwicklung als eigenständige Disziplin Warum kann man nicht einfach Modelle anderer Bereiche, wie etwa des Ingenieurwesens oder der Architektur, auf die Software Entwicklung übertragen? Schließlich gibt es auch dort Entwicklung und es existieren bereits vielfältige Vorgehensmodelle, best practices und (teilweise) Jahrhunderte an Erfahrungen. Über genaue Antworten auf diese Frage wird viel gestritten, es gibt aber ein paar deutliche Anhaltspunkte, dass Software Entwicklung sich zum Teil deutlich von anderen Disziplinen unterscheidet. Software hat in der Regel einen sehr hohen Komplexitätsgrad, was sich durch eine hohe Anzahl interagierender Teilsysteme und/oder durch einen hohen Verknüpfungsgrad dieser bemerkbar macht. Je größer die Komplexität eines Systems, desto schwieriger ist seine Handhabung. Software befindet sich oft an der Grenze des Handhabbaren. Software wird auch immer wieder neu entwickelt. Keine Software ist identisch mit einer anderen Software (sonst könnte man sie ja einfach binär kopieren). Wir reden also zu Recht von Software 6

7 Entwicklung und nicht etwa von Software Fertigung. Zusammen mit dem vorherigen Punkt (Komplexität) bedeutet diese Erkenntnis, dass zwei verschiedene Software Programme, auch wenn sie sich nur in einem Detail unterscheiden, sehr unterschiedlich aufgebaut sein können. Denn wenn dieses eine Detail mit viele anderen Komponenten in Wechselwirkung steht, hat seine Änderung mitunter große Auswirkungen. Ein Beispiel: Microsoft Office für den Mac ist mittlerweile eine komplett eigene Codebasis und wird von einem eigenen Team entwickelt. Dabei gab es ursprünglich nur die Anforderung, das Produkt Office auf einem anderen Betriebssystem verfügbar zu machen. Software Entwicklung findet oft in einem extrem instabilen Umfeld statt. Die technologischen Fortschritte sind so rasant, dass regelmäßig Paradigmenwechsel stattfinden, wie z.b. die Etablierung von virtuellen Maschinen oder die Wiederkehr von Service Oriented Architectures (SOAs). Dies erfordert auf der einen Seite eine konstante Beschäftigung mit der Technik selbst, aber auch eine aktive Beobachtung des Marktes, da sich die rasanten Fortschritte auch dort widerspiegeln. Ein Beispiel hier: der rasante Aufstieg der Smartphones allgemein durch den unerwarteten Markteintritt von Apple (iphone). Last but not least ist die Entwicklung von Software im Spannungsfeld zwischen Kreativität auf der einen Seite und der Verwendung von best practises und analytischem und strukturiertem Vorgehen auf der anderen Seite angesiedelt. Details hierzu finden sich u.a. in [Rosenberg, 2007] und [Graham, 2004]. Begreift man Software Entwicklung als eigenständige Disziplin, so ist es notwendig, sich dedizierte Vorgehensmodelle für die Entwicklung von Software zu überlegen. Eines der ersten war das so genannte Wasserfallmodell. Das Wasserfallmodell Das Wasserfallmodell ist eines der bekanntesten und verbreitetsten Vorgehensmodelle zur systematischen Entwicklung von Software. Mittlerweile wird es i.d.r. nicht mehr direkt angewandt, sondern in Form weiter ausformulierter Prozesse; oft auf die Bedürfnisse des jeweiligen Unternehmens zugeschnitten. Das Wasserfallmodell ist in diesen Fällen aber oft noch sichtbarer Ursprung. Insbesondere die Hauptcharakteristika finden sich in der Regel 1:1 wieder. 7

8 Das Wasserfallmodell [Winston, 1987] (erschienen 1970) Das Wasserfallmodell ist streng sequentielles, dokumentengetriebenes Vorgehensmodell zur Software Entwicklung [Winston, 1987]. Das Modell sieht sieben Stufen vor, welche für die erfolgreiche Entwicklung von Software durchlaufen werden müssen. Dabei dient der Output von Stufe n als Input für Stufe n+1. Die Entwicklung beginnt mit der Analyse der Anforderung, dem einzigen Schritt, wo der Kunde der zu entwickelnden Software direkt beteiligt ist. Das Ergebnis dieser Analyse-Phase ist ein Dokument, welches die Wünsche des Kunden an die Software fixiert. Dieses Dokument dient dann als Grundlage für die Design-Phase, in welcher der technische Aufbau der Software (System- Architektur, Klassendiagramme, etc.) festgelegt wird. Diese Dokumente werden dann in der Implementierungsphase verwendet, um die eigentliche Software zu erstellen. Die Integration dieser Software in ihre Umgebung (Interaktion mit andere Software Komponenten, Integration in den Betrieb, etc.) wird in der Integrationsphase vorgenommen. In der darauf folgenden Phase wird die Software getestet und sichergestellt, dass die Qualitätsanforderungen eingehalten werden. Ist dies erfolgt, kann die Software ausgerollt (installiert) werden, um dann in die Lebenszyklus Wartung überzugehen. Big Design Up Front Das Wasserfallmodell liegt das Paradigma Big Design Up Front (BDUF) zu Grunde, eine Philosophie die besagt, dass, je später ein Fehler in der Erstellung eines System gefunden wird, es umso teurer ist, ihn zu beseitigen. Hier sieht man klar die Wurzeln des Wasserfallmodells: die Fertigungsindustrie der 1970er Jahre. Bei der Produktfertigung ist BDUF sicherlich gegeben, denn ein Fehler im Design einer Maschine, der sich erst durch eine fehlerhafte Charge des mit der Maschine zu 8

9 erstellenden Produktes bemerkbar macht, ist in der Regel nur mit viel Aufwand (Geld und Zeit) zu beheben. Auch in der Software Entwicklung ist BDUF als Paradigma weit verbreitet, denn es gibt viele Beispiele, wo ein kleiner Fehler zu Beginn eines Projektes sehr große Auswirkungen gegen Ende des Projektes hat. Ein Beispiel: Es soll eine Desktop-Applikation für Windows entwickelt werden. Die Entwickler entscheiden sich als technische Grundlage für das Microsoft.NET-Framework. Die Software wird implementiert und kommt in den Test. Dort wird festgestellt, dass bei der Anforderungsanalyse die Anforderung muss ohne Administrationsrechte installierbar sein vergessen wurde. Das.NET- Framework kann aber nur mit Administrationsrechten installiert werden; die Wahl der gesamten technischen Grundlage war im Nachhinein falsch und das Projekt muss aufgegeben werden. Das Wasserfallmodell in der Praxis Die in der Literatur vielzitierten Berichte der Standish-Group [Standish Group, 2004] zeigen, dass nur ein kleiner Teil aller IT-Projekte wie geplant durchgeführt werden kann. Failed 18% Succeeded 29% Challenged 53% Ergebnisse des Standish CHAOS Report 2004 [Standish Group, 2004] Die Grafik listet die Ergebnisse von durchgeführten IT-Projekten auf. Succeeded bedeutet eine Fertigstellung innerhalb der veranschlagten Zeit und mit den veranschlagten Ressourcen. Challenged bedeutet, dass prinzipiell zwar das Projektziel erreicht, dafür aber mehr Zeit oder mehr Ressourcen als geplant benötigt wurden. Failed bedeutet, dass das Projektziel verfehlt wurde. Interessant ist auch die Entwicklung der Zeit- und Ressourcenüberschreitungen über die letzten Jahre: 9

10 200% 150% 100% 50% 0% Mehrkosten Verzögerung Überschreitung der durchschnittlichen, geplanten Projektparameter in %. [Standish Group, 2004] Man erkennt deutlich eine Verbesserung über die Jahre hinweg, muss aber dennoch bemerken, dass die durchschnittliche Projektlaufzeit um ca. 100% überschritten wird. Dies deckt sich durchaus mit der eigenen Alltagserfahrung: man denke nur an Projekte wie Windows Vista (erstes angekündigtes Releasedatum im Juli 2001 war Ende 2003; Vista erschien im Januar 2007 nach sieben Jahren Entwicklung) oder Duke Nukem Forever. Was könnten Gründe für solche Performancedaten sein? Ein mögliche Ursache wurde schon kurz angeschnitten: Software Entwicklung ist Entwicklung und nicht Fertigung. Sie entspricht der Entwicklung neuer Produkte und nicht der Fertigung bereits existierender. Software Entwicklung benötigt weiterhin ein gehöriges Maß an Kreativität. Die Grundlage, um in einem Team der Kreativität freien Raum zu lassen, ist eine funktionierende Kommunikation. Team bezieht sich hierbei nicht nur auf die Software Entwickler, sondern auf alle an der Entstehung des Produktes beteiligten Personen (Business Analysten, Produktmanager, Software Entwickler, Tester, etc.). Hinzu kommt, dass das Design von (Software) Produkten schwer ist, dass Priorisierung von Features schwer ist und dass Kommunikation schwer ist [Cockburn, 2002]. Schwer bedeutet in diesem Zusammenhang, dass es kein Erfolgsrezept gibt, an welchem man sich entlang hangeln kann. Ein Beispiel: 10

11 Login-Dialog für das Browser-Betriebssystem eyeos. Nehmen wir an, es soll ein Nutzerkonzept für den Login-Dialog erstellt werden, so dass die Entwicklung mit der Umsetzung dieses Konzeptes beginnen kann (bzw. das Design-Team mit dem Software-Design). Auf den ersten Blick sollte die Grafik eigentlich fast schon genügen. Es gibt drei Elemente, von denen nur eines eine Aktion ausführt und die Art der Aktion ist selbsterklärend (wir gehen der Einfachheit halber davon aus, dass alle Beteiligten wissen, wie ein Login ins System funktionieren soll). Das genaue visuelle Design ist durch die Grafik auch schon festgelegt. Leider ist dies aber nur auf den ersten Blick so. Was soll passieren wenn der Nutzer sein Login und Passwort eingegeben hat und dann nicht auf den Button klickt, sondern die Return-Taste verwendet? Es soll sicherlich der Login Vorgang ausgelöst werden, dies ist aber nirgendwo spezifiziert. Was ist mit der Enter-Taste (unten rechts am Ziffernblock)? 1 Dieses Beispiel ist nicht sehr weit hergeholt, denn wenn ein GUI gefordert ist, welches (graphisch) von den Standards abweicht, so kommt man oft in die Verlegenheit, die benötigten GUI-Widgets selbst programmieren zu müssen. Dies führt dann dazu, dass man solche Kleinigkeiten (wie Return & Enter) mit berücksichtigen muss. Auch funktional ist es nicht so einfach, wie es auf den ersten Blick aussieht. Was soll z.b. passieren wenn der Benutzer bereits eingeloggt ist(auf einem anderen Rechner, oder auf demselben Rechner mit einem anderen Account)? Möchte man alle diese Punkte (plus diejenigen, die ich noch vergessen habe) in die Nutzerspezifikation aufnehmen, wird schon ein sehr umfangreiches Dokument entstehen. In der Regel beschränkt sich die zu entwickelnde Software aber nicht auf so einfache Dialoge wie den diskutierten. Oft enthält kommerzielle Software Dutzende von Dialogen des folgenden Komplexitätsgrades: 1 Zumindest bei Verwendung der Win32-API haben Return und Enter unterschiedliche Keycodes, müssen also getrennt behandelt werden. 11

12 Einstellungs-Dialog vom Firefox 3 Für solche Applikationen ein vollumfängliches Nutzerkonzept mit der oben dargelegten Granularität zu schreiben, ist nahezu unmöglich. Wie kann ich aber Software entwickeln, ohne vorher genau zu spezifizieren, was ich eigentlich entwickeln will? Agile Software Entwicklung Die Wurzeln der agilen Software Entwicklung Der Ursprung der Methoden agiler Software Entwicklung ist auf die japanische Automobilindustrie der 1980er Jahre zurückzuführen. Insbesondere das Unternehmen Toyota beschäftigte sich zu dieser Zeit mit neuen Methoden zur Produktentwicklung. Das sogenannte Lean Management basiert auf der Vermeidung der drei mu : muda = Verschwendung, muri = Überlastung und mura = Unausgeglichenheit. Verschwendung ist hier definiert als jede menschliche Aktivität, die Ressourcen verbraucht, aber keinen Wert erzeugt 2 2 [Hopp, 2000], Seite

13 Das Gegenteil zur Verschwendung ist demnach die Wertschöpfung oder werterzeugende Aktivität. Die agile Software Entwicklung hat sich zum Ziel gesetzt, diese Philosophie zu übernehmen und auf Software Entwicklungsprozesse zu adaptieren. Agile Manifesto Das Agile Manifesto - agilemanifesto.org - versucht die Quintessenz agiler Software Entwicklung zu erfassen und in 4 Werten und 12 Prinzipien festzuhalten. Die vier Werte sind Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Wichtig ist die im Agile Manifesto den Werten folgende Klarstellung, dass das over nicht im Sinne von anstatt, sondern als Ausdruck einer Priorisierung verstanden werden muss. So sind z.b. Prozesse und Werkzeuge auch wichtig, aber eben nicht so wichtig wie Individuen und Interaktionen. Diese Werte beschreiben den Raum agiler Software Entwicklung in welchem sich dann konkrete Vorgehensmodelle - wie etwa Scrum, extreme Programming oder Crystal - wiederfinden. Individuals and interactions over processes and tools Software wird von Menschen gebaut. Menschen sind einzigartig. Auf den ersten Blick wirken diese beiden Aussagen banal. Sie sind es aber nicht, wenn man sich die Versuche zur Standardisierung von Software Entwicklung anschaut. Denn, wenn man versucht, einen Software Entwicklungsprozess zu definieren, versucht man (i.d.r.) vom Individuum so zu abstrahieren, dass der Prozess von beliebigen Personen durchgeführt werden kann. Die agile Software Entwicklung spricht dem Individuum hier mehr Raum zu, in dem konstatiert wird, dass Individualität wichtiger ist als Prozesskonformität. Dass das gerade im Bereich der Software Entwicklung wichtig ist, folgt u.a. aus der Erkenntnis, dass Software Entwicklung eine Tätigkeit zur Erfindung neuer Produkte ist und diese Tätigkeit unter anderem eine Menge an Kreativität erfordert (s.o.). Um den starken Einfluss der Individualität deutlich zu machen, soll hier ein Aspekt von Individualität - nämlich individuelle Leistungsfähigkeit - diskutiert werden. 13

14 2,5 1 Entwickler Best Median Worst Performance Leistungsfähigkeit von Software Entwicklern. Quelle: [DeMarco, 1999] Die Grafik stellt auf der X-Achse die individuelle Leistungsfähigkeit von Software Entwicklern auf einer Skala von 1 bis 10 dar. Auf der Y-Achse ist die Anzahl der Software Entwickler abgetragen, die diese Leistungsfähigkeit besitzt [DeMarco, 1999]. Aus dieser Statistik kann man (mindestens) drei interessante Aussagen ableiten: I. Die besten Software Entwickler sind um den Faktor 10 produktiver als die schlechtesten Software Entwickler. II. Die besten Software Entwickler sind um den Faktor 2,5 produktiver als durchschnittliche Software Entwickler. III. Die Gruppe der Software Entwickler über dem Median ist im Durchschnitt um den Faktor 2 produktiver als die Gruppe der Software Entwickler unter dem Median. Ein Beispiel, wo dieser Aspekt in klassischen (a.k.a. nicht agilen) Software Entwicklungsmodellen oft nicht berücksichtigt wird, sind Arbeitspaketschätzungen. Bei einem großen Wasserfallprojekt steht in der Planungsphase häufig noch nicht fest, welche Personen später das Entwicklungsteam bilden werden. Trotzdem werden die Arbeitspakte im Vorfeld geschätzt, z.b. durch Architekten oder Lead Engineers. Das führt genau dann zu Problemen, wenn diese bei den Schätzungen von ihrer eigenen Leistungsfähigkeit ausgehen, diese dann aber beim umsetzenden Team nicht vorhanden ist. Mit Interaktionen über Werkzeugen ist gemeint, dass Werkzeuge zwischenmenschliche Beziehungen, bzw. Kommunikation nur ergänzen, aber nicht ersetzen können. Ein Beispiel aus der Praxis: Bugzilla ist ein sehr mächtiges Werkzeug um Defekte in der zu entwickelnden Software zu 14

15 tracken und zu organisieren. Ersetzt er aber die zwischenmenschliche Kommunikation, führt er eher zu sinkender Produktivität und Unmut im Team. 3 Working software over comprehensive documentation Warum ist lauffähige Software wichtiger als Dokumentation? Die abstrakte Antwort ist ganz einfach: Weil Software wertschöpfend ist und Dokumentation nicht. 4 Wichtig ist, dass sich hier Dokumentation nicht auf die Dokumentation der Software - für den User oder für andere Entwickler - bezieht, sondern auf die Dokumentation, die in klassischen Software Entwicklungsmodellen vor der eigentlichen Entwicklung entsteht., also etwa das Nutzerkonzept und die technische Spezifikation. Beide haben auch in der agilen Software Entwicklung durchaus ihren Nutzen, sind aber eben nicht so wichtig wie lauffähige Software. Ein konkretes Beispiel: Es soll eine Software zur Verwaltung von Kundendaten (Anlegen, Ändern, Suchen, Löschen) entwickelt werden. Man kann nun entweder im ersten Monat das (vollständige) Nutzerkonzept erstellen, oder - nach einer kurzen, gemeinsamen Ausarbeitung der zentralen Anforderungen - mit der Implementierung beginnen und am Ende das Monats das Modul zum Anlegen von Kundendaten als lauffähige Software deployt haben. Die agile Software Entwicklung bevorzugt eindeutig die zweite Option, denn nur diese hat einen Wert am Ende des ersten Monats erzeugt: es kann mit der Eingabe von Kundendaten begonnen werden. Das Ergebnis der ersten Option ist aber ausserhalb des Projekts nicht von Relevanz. Lauffähige Software ist einer der wichtigsten, aber auch der kniffeligsten Aspekte von agiler Software Entwicklung. Denn wann genau ist denn eine Software lauffähig, beziehungsweise fertig ( done )? Dies muss von Projekt zu Projekt neu festgelegt werden und erfordert auf der einen Seite viel Wissen aus der Fachdomäne und auf der anderen Seite viel Wissen über technische Aspekte wie Wartbarkeit, Skalierbarkeit und Performanz von Software. Zwei Beispiele sollen dies illustrieren: Ein Computerspiel ist fertig, wenn die Funktionalität umgesetzt wurde, es bugfrei ist, es auf der geforderten Minimal-Hardware performant genug funktioniert, die Server n Kunden auf einmal aushalten (und schnell erweitert werden können), etc. Die Wartbarkeit ist hier u.u. nicht so wichtig (vielleicht ist weder eine Erweiterung noch ein Nachfolger geplant). Eine Software zur Steuerung einer Maschine, welche Medikamente herstellt, ist fertig, wenn die Funktionalität umgesetzt wurde, sie bugfrei ist, die Dokumente für die FDA 5 vorliegen, der Source- Code auf 30 Jahre hin archiviert wurde, die Software so dokumentiert ist, dass ein völlig neues Team in 10 Jahren in der Lage ist einen Bug zu fixen, usw. Skalierung ist hier hingegen kein Thema. Customer collaboration over contract negotiation Die Basis für die meisten Software Produkte ist eine Zusammenarbeit zwischen dem Auftraggeber - ob externer Kunde oder Produktmanager - und dem Entwicklungsteam. Der Auftraggeber kennt die Anforderungen an die Software, die Business Domäne und das Umfeld (oder den Markt), in dem die Software eingesetzt werden. Das Entwicklungsteam bringt das notwendige 3 Ein konkretes Beispiel ist eine Assignment-Eskalation, bei der ein Bug ständig zwischen zwei Teams hin- und hergeschoben wird, da sich niemand wirklich zuständig fühlt. Ein einfaches Telefonat zweier Entwickler löst dieses Problem i.d.r. innerhalb von Minuten. 4 Ansonsten sollte man nicht primär Software Entwickler beschäftigen, sondern Autoren. 5 Food & Drug Association in den USA 15

16 technische Know-How mit, um die Vorstellungen des Auftraggebers in die Tat umzusetzen. Beide sind nur gemeinsam in der Lage, wertschöpfend tätig zu sein. Diese Zusammenarbeit funktioniert nur dann optimal, wenn beide versuchen, dasselbe Ziel zu erreichen. Dieses Ziel kann nur dann in optimaler Art und Weise erreicht werden, wenn auf dem Weg auftretende Hindernisse schnell und unkompliziert aus dem Weg geräumt werden können. Besteht eine harmonierende, wohlwollende Kommunikationsbeziehung zwischen Auftraggeber und Entwicklungsteam, ist dies in der Regel leicht möglich. Ist dies aber nicht der Fall, arten einfache Differenzen schnell aus: das Vergessen der Enter- Taste beim Login-Dialog führt dann leicht zu einer zeitraubenden, hässlichen Grundlagendiskussion über den notwendigen Detailgrad bei Nutzerkonzepten. Fühlt sich dann noch die eine Seite übervorteilt, wird oft sogar der gesunde Menschenverstand ausgeschaltet: Das steht da nicht, also mache ich das auch nicht. Verträge können eine gute Grundlage für eine (Kommunikations-)Beziehung sein, insbesondere dann, wenn die beiden Parteien das erste Mal zusammenarbeiten. Sie sind aber auch i.d.r. nur mit extremem Aufwand anzupassen und bieten damit nicht die genügende Flexibilität, um als primäres Kommunikationsmittel eingesetzt zu werden. Responding to change over following a plan Das größte Risiko für die meisten Projekte ist, das falsche Produkt zu entwickeln. [Pichler, 2008] In der IT Industrie gibt es nahezu täglich große Änderungen 6. Google bringt ohne vorherige Ankündigung einen neuen Browser auf den Markt. Apple betritt mit dem iphone völlig überraschend den Mobilfunksektor. Python 3.0 ist nicht mehr abwärtskompatibel zu vorherigen Versionen. Solche Änderungen können großen Einfluss auf laufende Software Entwicklungsprojekte haben. Eine Web-Applikation, die nicht mit Google Chrome funktioniert, kann nicht wie geplant gelauncht werden. Java ME als technologische Basis für die eigene Mobile Applikation steht plötzlich in Frage. Für eine Portierung der gesamten Codebasis auf Python 3.0 muss Geld und Zeit gefunden werden. Auch Veränderung innerhalb der eigenen Firma oder sogar innerhalb des eigenen Projektes sind oft nicht vorhersehbar. Die Übernahme eines Konkurrenten führt z.b. in der Regel dazu, dass laufende Projekte gründlich ob der Validität ihrer Ziele überprüft werden müssen. Auch Mitarbeiterwechsel - z.b. durch Kündigung - können sehr großen Einfluss auf die Laufzeit von Projekten haben (insbesondere wenn man die individuelle Leistungsfähigkeit verschiedener Software Entwickler berücksichtigt; s.o.). Während in klassischen Software Entwicklungsmodellen diese Punkte unter dem Stichwort Risiko Management laufen und man versuchen würde sie im Vorfeld (vor dem Start der Entwicklungsphase) zu identifizieren und zu bewerten, geht die agile Software Entwicklung hier einen anderen Weg. Agile Entwicklungsmodelle müssen in der Lage sein, mit beliebigen Änderungen umzugehen, also insbesondere mit solchen, die man im Vorfeld nicht antizipiert hat. Auch hier gilt natürlich, dass es schon von Wert ist, einen Plan zu haben. Dieser sollte aber nicht so starr sein, dass die einzige mögliche Reaktion auf eine Änderung eine vollständige Neuplanung ist. (Unbequeme) Wahrheiten 6 Optimisten nennen das Fortschritt. 16

17 Die vier Werte des Agile Manifesto enthalten zum Teil Aussagen, die für klassische Modelle schwer zu akzeptieren sind: I. Software Entwickler sind Individuen und damit nicht beliebig austauschbar. II. Man kommt nur gemeinsam zum Ziel. Es ist nicht zielführend, 7 sich damit zu beschäftigen, im Falle eines Scheiterns nicht Schuld gewesen zu sein. III. Unvorhergesehenes wird passieren und auf das Projekt Einfluss nehmen. Während die klassische Software Entwicklung eher versucht, diese Punkte zu eliminieren oder zu beherrschen, geht die agile Entwicklung einen anderen Weg. Sie fordert diese Punkte als gegeben zu akzeptieren und das eigene Vorgehen darauf anzupassen. Schlanke Prinzipien 8 Wie schon im im Vorfeld diskutiert wurde, liegen die Wurzeln der agilen Software Entwicklung in der Lean Thinking Bewegung der 80er und 90er Jahre. Lean Thinking wiederum basiert auf Prinzipien der Lean Production Philosophie aus den 50er Jahren. Eine erfolgreiche Übertragung der Erfahrungen von Lean Production auf Lean Thinking gelang damals nur, weil nicht die Praktiken, also die Prozesse und Werkzeuge übertragen wurden, sondern die Prinzipien, aus welchen dann neue, auf die jeweiligen Umstände angepasste, Praktiken entwickelt werden konnten. Mary & Tom Poppendieck wählen einen analogen Ansatz, um die Erfahrungen des Lean Thinkings für die Software Entwicklung nutzbar zu machen. In [Poppendieck, 2003] identifizieren sie sieben Prinzipien des Lean Thinking, übertragen diese auf die Software Entwicklung und entwickeln für die Software Entwicklung passende Werkzeuge. Vier dieser Prinzipien sollen hier vorgestellt werden. Eliminiere Verschwendung Verschwendung zu eliminieren ( eliminate waste ) ist das Hauptprinzip des Toyota Production Systems (s.o.). Verschwendung meint hier alles, was keinen Kundenwert hat, also z.b. Dinge, die gerade nicht in Verwendung sind (u.a. der gesamte Inhalt eines Lagers) oder Prozessschritte, die keinen Einfluss auf das entstehende Produkt haben. Um dieses Prinzip auf die Software Entwicklung zu übertragen, kann ein Zitat von Royce, dem Erfinder des Wasserfallmodells, als Startpunkt dienen [Royce, 1987]: [While] many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs. Um mögliche Arten von Verschwendung innerhalb eines Software Entwicklungsprozesses zu identifizieren, sollte man alles, was nicht direkt der Anforderungsanalyse oder der Entwicklung zugesprochen werden kann, auf seinen Kundenwert hin untersuchen. Drei typische Quellen von Verschwendung werden nun kurz diskutiert. Unfertige Arbeit 7 im wahrsten Sinne des Wortes 8 [Poppendieck, 2003] 17

18 Code, der nicht deployt oder an den Kunden übergeben wurde, ist unfertige Arbeit. Er erzeugt keinen Wert und stellt damit eine nicht realisierbare Investition dar. Je länger der Code unfertig bleibt, desto größer wird die getätigte Investition und desto höher wird auch das Risiko, die Investition nicht, oder nicht vollständig, abschreiben zu können. Die Lösung für diese Art von Verschwendung ist die Phase, in der Code unfertig ist, möglichst zu eliminieren. Die agile Software Entwicklung erreicht dies durch die Einführung von Iterationen, an deren Ende ja immer lauffähige, fertige Software steht. Unnötige Prozesse Unnötige Prozesse in der Software Entwicklung sind alle Tätigkeiten, die keine Artefakte erzeugen, welche Kundenwert besitzen. Ein Beispiel hierfür ist ein regelmäßiger Management-Report über den Projektfortschritt in einem bestimmten Format oder die Erstellung von Dokumentationen über verwendete Techniken oder eingehaltene (technische) Vorgaben. Solche Prozesse sind nicht per se überflüssig, sollten aber auf ihren Nutzen hin überprüft werden. Als Daumenregel kann dienen, dass nur solche Dokumente wichtig sind, auf deren Erstellung jemand wartet. Dokumente die irgendwo abgelegt werden, ohne dass zum Zeitpunkt der Erstellung klar ist ob, wann oder von wem sie gelesen werden, sind i.d.r. nicht notwendig. Multi-Tasking Das Wechseln müssen zwischen Aufgaben, sei es eines Entwicklers oder auch eines ganzen Teams, ist immer mit (mindestens mentalem) Aufwand verbunden. Dieser dient keiner der Aufgaben, zwischen denen gewechselt wird und erzeugt damit auch keinen Wert für den Kunden. Hier kann eine Lösung sein, Aufgaben nur noch seriell zu entwickeln, so dass jeder Entwickler bzw. jedes Team zu jedem Zeitpunkt nur einem Projekt zugeordnet ist. Aufspüren von Verschwendung Ein Werkzeug, um Verschwendung zu entdecken, ist das Value Stream Mapping. Hierbei wird ein Graph erstellt, der einen Feature Request eines Kunden von der initialen Anfrage bis zum fertigen Produkt durch die eigene Organisation verfolgt. Dabei werden die Zeiten, in denen am Feature gearbeitet wird, aber auch die Zeiten, während derer das Feature auf die nächste Bearbeitungsstufe wartet, erfasst. 18

19 Beispiel für eine Value Stream Mapping. In dem Beispiel fängt der Feature Request mit einer kurzen Bearbeitungszeit an, die zum Schreiben des Projektantrags notwendig ist. Danach folgt eine lange Wartezeit, bis der Projektauftrag freigegeben wird. Der Akt der Freigabe an sich erfordert wiederum nur wenig Aufwand, usw.. Hat man einen solchen Graphen erstellt, lassen sich leicht diejenigen Schritte im Prozess identifizieren, welche die lohnendsten Ziele für eine weitergehende Untersuchung darstellen: eben diejenigen, welchen eine lange Wartezeit vorausgeht. Entscheide so spät wie möglich Auch dem Prinzip entscheide so spät wie möglich liegt eine Erfahrung aus der Automobilindustrie zu Grunde. Karosserieteile werden dort mit Hilfe von Stahl-Stempeln gepresst. Dabei macht die Herstellung dieser Stempel einen großen Teil der Entwicklungskosten eines neuen Fahrzeuges aus. Es scheint also naheliegend, viel Wert darauf zu legen, dass ein Stempel gelingt, also dass er im Verlaufe der Entwicklung nicht mehr geändert oder sogar komplett neu erstellt werden muss. Dies wiederum bedeutet, dass das Karosserie-Design vor der Produktion der Stempel feststehen sollte ( Big Design Up Front, s.o.). Die amerikanische Autoindustrie verfuhr in den 80er Jahren nach genau diesem Prinzip. In Japan hingegen wurde anders vorgegangen: Hier wurden der Entwickler eines Karosserieteils und der Produzent des dazugehörigen Stempels sehr früh im Design-Prozess zusammengebracht. Das führte dazu, dass der Stempel-Produzent sich eine gute Vorstellung davon machen konnte, welche Aspekte beim Design des Karosserieteils eher noch im Fluss und welche bereits final bestimmt waren. Er konnte dann bereits sehr früh mit der Produktion des Stempels beginnen, während parallel noch am Design der Karosserie gearbeitet wurde. Das Resultat war, dass während in Amerika Änderungen am Design zwischen 30% und 50% der gesamten Stempel-Kosten ausmachten, diese nur zwischen 10% und 20% in Japan betrugen. Zusätzlich waren die japanischen Stempel von höherer Qualität: sie brauchten im Schnitt fünf statt der amerikanischen sieben Pressungen für die Erstellung eines Karosserieteiles. Dieses Prinzip der parallelen Entwicklung lässt nun auch auf die Software Entwicklung übertragen, indem man die Spezifikations- und Entwicklungsphasen parallelisiert, wie z.b. in den iterativen Vorgehen von Scrum oder XP (s.u.). Durch die parallele Entwicklung wird der Raum der möglichen 19

20 Lösungen mittels Breiten- und nicht mittels Tiefensuche durchsucht. D.h. bevor der zweite Schritt eines möglichen Lösungsweges betrachtet wird, werden zunächst die ersten Schritte aller möglichen Lösungswege betrachtet. Traversierung eines Graphen mit Breitensuche (links) und Tiefensuche (rechts) Hierdurch wird das Prinzip der späten Entscheidung umgesetzt, denn alle Optionen (Lösungswege) werden maximal lange offen gehalten. Dieser Ansatz steht nun klar entgegen der Big Design Up Front -Philosophie (s.o.), so dass man dem Vorwurf begegnen muss, dass späte Änderungen, also hier späte Wechsel des Lösungsweges, doch teuer sind. Generell ist es richtig, dass es Änderungen gibt, die, je später sie auftreten, umso mehr kosten. Beim Beispiel der Stempel für die Karosserie wäre etwa der Umschwenk von einem Sportwagen auf einen SUV etwas, welches sich nicht durch eine Anpassung halb fertiger Stempel realisieren ließe. Analog ist im Bereich der Software Entwicklung eine Änderung der Programmiersprache i.d.r. nicht ohne einen vollständigen Neuanfang möglich. Dies gilt jedoch nicht für alle Änderungen. Eine leicht andere Form des Kotflügels lässt sich sehr wohl durch eine Änderung am bereits bestehenden Stempel und die Umstellung einer Datenbank oft durch geringe Änderungen an der Software realisieren. Mary und Tom Poppendieck schlagen deshalb folgende Sichtweise auf Änderungen und ihre Kosten über den Zeitpunkt der Änderung vor: 20

21 kritische Änderungen normale Änderungen Änderungskosten Zeit Änderungskosten in Relation zum gewählten Zeitpunkt der Änderung D.h., während sich die späte Umsetzung kritischer Änderungen stark negativ auf die Kosten auswirkt, ist dies für normale Änderungen nicht der Fall. Wie kann man nun Stellen antizipieren, an denen in Zukunft Änderungen eintreten können, um hier bspw. in der Software Architektur Änderungsmöglichkeiten vorzusehen? Ein einfaches Verfahren ist, zu beobachten, an welchen Stellen in der Vergangenheit Änderungen vorgenommen werden mussten. Denn in der Regel werden Software-Änderungen durch den Markt getrieben. Stellen, an denen sich die Software öfters ändert (bzw. ändern muss), deuten darauf hin, dass der Markt an dieser Stelle volatil ist. Aus dieser Volatilität folgt, dass hier auch mit hoher Wahrscheinlichkeit in Zukunft wieder Änderungen notwendig werden. Dies kann dann mittels einer generischeren Architektur vereinfacht werden. Als Gegenpol gilt hier aber, dass eine generische Architektur i.d.r. teurer ist als eine weniger generische und damit Aufwand verschwendet (s.o.) wird, wenn die potentiellen Änderungsmöglichkeiten zu einem zukünftigen Zeitpunkt nicht verwendet (realisiert) werden. Mary und Tom Poppendieck definieren in diesem Zusammenhang den last responsible moment als denjenigen Moment, an dem das Nicht-Fällen einer Entscheidung zum Wegfall einer Option führt. Diesen Moment gilt es zu identifizieren und das Fällen der Entscheidung bis hierhin hinauszuzögern. Dies kann z.b. von Techniken für sauberes objektorientiertes Design [Martin, 2002] unterstützt werden. So sorgt z.b. das single responsibility Prinzip dafür, dass sich singuläre, fachliche Änderungen auf leicht lokalisierbare singuläre Stellen im Source-Code abbilden lassen. Auch schnelle Reaktions-, bzw. Turnaroundzeiten sind wichtig für möglichst späte Entscheidungen. Hat man etwa einen Releasezyklus von vier Wochen, so muss man sich bereits vier Wochen vor dem 21

22 Livegang dafür entscheiden ein Feature zu entwickeln, auch wenn die eigentliche Entwicklung des Features vielleicht nur eine Woche dauert. Bei einem kürzeren Releasezyklus ist man in der Lage, den Moment der Entscheidungsfindung weiter nach hinten zu verschieben. Schaffe Integrität Es gibt zwei Arten von Integrität, die für diese Diskussion von Bedeutung sind: die wahrgenommene Integrität und die konzeptuelle Integrität. Wahrgenommene Integrität Hiermit ist gemeint, wie der Kunde ein Produkt wahrnimmt, also ob ihm die Software vorkommt wie aus einem Guss. Dies wird oft dadurch erreicht, dass Bedienkonzepte über große Bereiche hinweg vereinheitlicht werden, oder dass vom Designer/Entwickler der Software die Probleme des Users antizipiert wurden und dem User nicht einfach nur eine Ansammlung von lose gekoppelten Features angeboten wird. Als Beispiel kann hier die Apple Software idvd dienen. Diese bietet die Möglichkeit, eine Photo-Slideshow auf DVD zu brennen und diese mit Musik zu hinterlegen. Das Beispiel für wahrgenommene Integrität ist hier die Checkbox Slideshow Länge mit Länge der gewählten Musik synchronisieren, der dazu führt, dass die Übergänge zwischen den Bildern genau so lang gewählt werden, dass die Slideshow endet, wenn das gewählte Musikstück beendet ist. Dieses Problem ist für den Entwickler der Software sehr leicht zu lösen 9, würde aber einen technisch nicht so versierten Benutzer vor größere Herausforderungen stellen. Eine Voraussetzung für die Schaffung von wahrgenommener Integrität ist eine gemeinsame Sprache der Fachseite und der Technik. So kann sichergestellt werden, dass Konzepte, die fachlich zusammenhängen, auch technisch zusammenhängend umgesetzt werden (analog mit fachlich Unabhängigem). Eine Möglichkeit, dies zu erreichen, ist die Verwendung von Model-Driven Design, also die Erstellung eines fachlichen Modells, auf welchem die technische Entwicklung aufsetzt. So ein Modell kann vielerlei Formen annehmen. Es kann beispielsweise eine einfache Matrix nebst Glossar sein, die alle möglichen Verbindungen zwischen fachlichen Komponenten auflistet und die Komponenten beschreibt. Es kann aber auch eine eigene (formale) Sprache, eine sogenannte Domain Specific Language (DSL), erstellt werden, mit deren Hilfe domänenspezifische Algorithmen und Datenstrukturen abgebildet werden können. Aus diesen Abbildungen kann häufig sogar Code in einer Standard-Programmiersprache generiert werden, welcher dann als technische Basis für die Entwicklung der Software dienen kann. Weitere Informationen zu modellgetriebener Softwareentwicklung finden sich in [Stahl, 2007]. Konzeptuelle Integrität Konzeptuelle Integrität meint die Verwendung von durchgängigen Design-Prinzipien innerhalb des Produktes, also im Falle von Software Entwicklung beispielsweise die Wiederverwendung von Komponenten oder die Verwendung von Design Patterns 10. Auch auf Ebene der Software Architektur kann konzeptuelle Integrität durch durchgängig verwendete Prinzipien wie etwa SOA ( Service Oriented Architecture ) erzeugt werden. Konzeptuelle Integrität ist eine notwendige, aber keine hinreichende Bedingung für wahrgenommen Integrität. Es gibt (leider) viele Software-Produkte, welche hohen architekturellen und 9 transitiontime = musicpiece.length() / picturelist.length() 10 [Gamma, 1996] 22

23 Software-Design Ansprüchen genügen, denen es aber nicht gelingt, die Probleme des Nutzers zu antizipieren und einfache Lösungen für diesen anzubieten. Ein Beispiel hierfür ist die Software Chandler, deren Entwicklung im Detail in [Rosenberg, 2007] beschrieben ist. Betrachte das Ganze Betrachtet man etwas nicht als Ganzes, sondern zerlegt es in einzelne Teile, besteht die Gefahr von lokalen Optimierungen. Das sind Optimierungen, welche zwar ein lokales Maximum erzeugen, wo die Summe dieser Maxima aber nicht dem globalen Maximum entspricht. Um dieses Prinzip zu verdeutlichen sei auf die Tour de France verwiesen: versucht man jedes einzelnen Rennen zu gewinnen (Optimierung der jeweiligen Bestandteile), wird man mit großer Sicherheit nicht die Tour gewinnen, da schon nach wenigen Etappen der eigene Energievorrat erschöpft ist. Um die Tour zu gewinnen, muss man sie als Ganzes betrachten und sich sehr gut überlegen, in welchen Rennen man maximales geben will, um diese zu gewinnen und in welchen Rennen man nur eine gute Zeit fahren möchte. Ein Punkt, wo sich dieses Prinzip auf die Software Entwicklung übertragen lässt, sind messbare Optimierungen. Messbares ist in der Software Entwicklung (wie auch in vielen anderen Disziplinen) sehr begehrt, denn es kann leicht verwendet werden, um den eigenen Fortschritt zu dokumentieren ( Wir sind 20% besser geworden! ) oder Fortschritt von anderen einzufordern, z.b. durch die Kopplung von Gehaltsboni an messbare Erfolgsfaktoren. Was hier nun leicht passiert, ist, dass durch die Fokussierung auf Messbares nicht-messbares vernachlässigt wird, obwohl es für den Gesamterfolg u.u. ebenso wichtig ist. Hat man etwa ein Problem, welches aus fünf Teilproblemen besteht, von welchen wiederum nur drei messbar sind, so ist die Wahrscheinlichkeit hoch, dass die zwei nicht messbaren Probleme nicht jeweils 20% der Aufmerksamkeit (bzw. der investierten Arbeit) bekommen. Hierdurch wird aber die optimale Lösung des Gesamtproblems u.u. verfehlt. Ein konkretes Beispiel wäre hier etwa die Konzentration auf das Fixen von Bugs (messbar: wie viele Bugs gibt es vorher und nachher noch im System) und die Vernachlässigung von Usability Problemen (nicht bzw. nur sehr aufwendig messbar). Das Resultat hier ist ein fehlerfreies System, welches aber nicht sehr bedienbar ist. Dies hat aber einen geringeren Kundenwert als ein System, welches noch ein paar kleine Bugs enthält, aber gute Bedienkonzepte aufweist. Scrum Scrum 11 ist ein konkretes Vorgehensmodell zur agilen Software Entwicklung. Im Gegensatz zu extreme Programming (XP), welches im nächsten Abschnitt im Detail vorgestellt wird, legt es den Fokus dabei nicht so sehr auf eine Sammlung von Praktiken, sondern auf Hilfsmittel zur Organisation der Zusammenarbeit im Team. So enthält Scrum z.b. keine Praktiken für das eigentliche Code schreiben, wie etwa Test Driven Development bei XP. Herkunft Der Begriff Scrum entstammt dem Paper The New New Product Development Game von Takeuchi und Nonaka [Takeuchi, 1986]. Dort wurden Methoden verschiedener japanischer Firmen zur Entwicklung neuer Produkte auf ihre Gemeinsamkeiten hin untersucht. Takeuchi und Nonaka wählten 11 Wenn nicht anders angegeben, stammen die Informationen aus [Pichler, 2004]. 23

24 den Begriff Scrum als Bild für eine teamorientierte Herangehensweise. Scrum kommt ursprünglich aus dem Rugby und bezeichnet dort einen Spielzug, welcher koordiniertes Teamplay voraussetzt, um erfolgreich durchgeführt werden zu können 12. Aufbau Der Aufbau von Scrum ist sehr praxisorientiert. Scrum beschäftigt sich im wesentlichen mit der Definition von Begriffen und Vorgehensweisen in den drei Bereichen Rollen, Artefakte und Meetings. Etwas ausserhalb dieser Kategorien steht das für Scrum zentrale Konzept des Sprint, welches als erstes eingeführt werden soll. Sprint Ein Sprint ist in Scrum ein Arbeitszyklus, welcher zu einem so genannten Softwareinkrement führt. Ein Softwareinkrement ist eine Version der zu entwickelnden Software, welche prinzipiell releast werden kann. Prinzipiell bedeutet hier, dass es insbesondere keine technische Gründe geben darf, von einem Release abzusehen. Die Entscheidung, ein Softwareinkrement nicht zu releasen, sollte nur auf Grund eines zu geringen Featureumfangs erfolgen. Hier spiegelt sich deutlich die Forderung nach Working Software aus dem Wertesystem der agilen Software Entwicklung wider. Sprints dauern zwischen 2 und 4 Wochen und werden zu Beginn des jeweiligen Sprints geplant. Diese Planung ist für die Dauer des Sprints konstant: bei gravierenden Umständen kann ein laufender Sprint höchstens abgebrochen, aber nie geändert werden. Die Konstanz bezieht sich hierbei auf die Dauer und auch auf den Umfang bzw. den Inhalt des Sprints. Rollen Scrum definiert nur drei Rollen, welche notwendig für die Software Entwicklung sind: den Product Owner, den Scrum Master und das Team. Product Owner Der Product Owner (PO) ist in Scrum diejenige Person, die verantwortlich für das Projekt, bzw. für das zu entwickelnde Produkt ist. Dies umschliesst insbesondere auch den wirtschaftlichen Erfolg des Projektergebnisses, bzw. des Produkts. Bei Yahoo! wird aus diesem Grund der PO treffenderweise als single wringable neck bezeichnet [Pichler, 2004]. Da der PO den Erfolgt des Produktes verantwortet, ist er auch für die fachliche Definition des Produkts verantwortlich, d.h. er spezifiziert die Anforderungen an das Produkt, welche dann im Verlauf des Projektes umgesetzt werden. In der Regel ist der PO deshalb auch Domänenexperte oder hat direkten Zugriff auf Domänenexperten. Der PO sollte für das Entwicklungsteam sichtbar in Erscheinung treten und jederzeit für Fragen greifbar sein. D.h. er sollte am selben Ort wie das Team sein und im Idealfall täglich beim Team vorbeischauen, um sich über den Fortschritt zu informieren und etwaige, während des aktuellen Sprints aufgetretene, fachliche Fragen direkt beantworten zu können. Wichtig ist hierbei, dass der PO auch die Kompetenz hat, die Fragen zu beantworten. Es ist kontraproduktiv, wenn der PO Antworten über einen längeren Zeitraum schuldig bleiben muss, da er sich beispielsweise bei seinem Vorgesetzten (oder Geldgeber) zuerst rückversichern will. 12 Für Details siehe z.b. 24

25 Der PO sollte nicht disziplinarisch verantwortlich für das Entwicklungsteam sein, da sonst leicht ein Ungleichgewicht zwischen Entwicklung und PO bei Verhandlungen, beispielsweise während den Sprintplanungen (s.u.), entstehen kann. Auch die Autonomie des Teams würde so in Frage gestellt (s.u.). Scrum Master Der Scrum Master (SM) ist verantwortlich für die Ablauforganisation und für die Sicherstellung einer optimalen Arbeitsumgebung für das Entwicklungsteam. Die konkreten Aufgaben des SM sind dabei sehr vielfältig, lassen sich aber im Endeffekt als das Beseitigen von Hindernissen zusammenfassen. Hindernisse können organisatorischer Art sein (Testsysteme bereitstellen) oder sich um fachliche Themen drehen ( wir bräuchten mal jemanden, der sich richtig gut mit Hibernate auskennt ). Auch Probleme im Teambuilding oder der Teamkommunikation sind Hindernisse für eine reibungslose Zusammenarbeit, die vom SM adressiert werden sollten. Bei teaminternen oder fachlichen Themen sollte der SM dabei eher als Moderator oder Coach auftreten denn als Problemlöser. Für das Teambuilding ist es wichtig, die Norming -Phase [Tuckman, 1965] zu durchlaufen, also zu gemeinsamen Werten und Normen zu gelangen. Es hilft da nichts, diese von aussen, also z.b. vom SM, vorgegeben zu bekommen. Von seiner Ausbildung her sollte der SM idealerweise einen Software Entwicklungshintergrund besitzen. Dieser ermöglicht es. die fachliche Probleme, die im Team diskutiert werden, nachzuvollziehen und ist notwendig für den Coaching-Aspekt der Rolle. Oft ist es der SM, der Anregungen für die Einführung neuer Praktiken, wie etwa TDD oder CI (siehe Diskussion im Abschnitt zu XP Praktiken ) ins Team einbringt (die Entscheidung für oder gegen einen Einsatz muss aber zu 100% beim Team selbst liegen). Wie der PO, sollte auch der SM keine Personalverantwortung für die Teammitglieder haben, da dass in Spannung mit seiner Rolle als Dienstleister des Teams der Hindernisse für das Team beseitigt stehen würde. Eine mögliche Betriebsorganisation, die der Forderung gerecht wird, dass weder SM noch PO disziplinarische Verantwortung für das Team besitzen, ist etwa ein Abteilungsleiter, an den 5-6 Scrum Teams direkt berichten. Team Durch die Definition von Team als dritter Rolle weicht Scrum stark von klassischen Modellen ab, wo viele verschiedene Rollen definiert werden, aus welchen sich das Entwicklungsteam zusammensetzt (etwa Entwickler, Tester, Architekt, usw.). Scrum verzichtet hier auf eine Definition einer Teamaufstellung, da diese zum einen stark von dem jeweiligen Team und der jeweiligen Aufgabe abhängt und zum anderen, da eine solche Aufstellung nicht von außen vorgegeben, sondern vom Team selbst festgelegt werden sollte. In Scrum ist das Team verantwortlich für die Lieferung des Softwareinkrements am Ende des jeweiligen Sprints. Um diese Verantwortung übernehmen zu können, benötigt es alle dafür notwendigen Kompetenzen. Da natürlich das genaue Setup des Teams und der Modus der Zusammenarbeit z.b. ob das gesamte Fachwissen über das Team verteilt ist, oder ob es einzelne Teammitglieder Spezialisten für einzelne Themen sind stark die Performance und damit auch Lieferfähigkeit des Teams beeinflusst, muss die Entscheidungskompetenz im Team selbst liegen 13. Scrum fordert Autonomie des Entwicklungsteams. 13 Keine Verantwortung ohne Kompetenzen! 25

26 Neben dieser sehr starken Forderung gibt Scrum noch einige konkrete Hinweise auf Eigenschaften, welche ein gut funktionierendes Team besitzen sollte: Das Team sollte interdisziplinär aufgestellt sein. Jeder Aspekt, der zur Entwicklung der Software notwendig ist, sollte geleistet werden können. Das Team sollte an einem Ort (in einem Büro!) ansässig sein, um eine direkte, reibungslose Kommunikation zu gewährleisten. Das Team sollte klein sein, es sollte 7 Entwickler nicht überschreiten. Alle Teammitglieder sollte zu 100% Mitglieder dieses einen Teams sein und nicht noch nebenher in anderen Projekten arbeiten. Artefakte Scrum definiert 4 Artefakte, d.h. 4 Objekte, die entweder als Ein- oder als Ausgabe in einer der Scrum-eigenen Vorgehensweisen benötigt werden oder dort entstehen. Die 4 Artefakte sind das Product Backlog, der Releaseplan, das Sprint Backlog und der Burndown Chart. Product Backlog Das Product Backlog enthält die Anforderungen an das zu entwickelnde Produkt. Die enthaltenen Anforderungen sind dabei stets priorisiert und (aufwands-)geschätzt. Die Anforderungen werden initial vom Product Owner vor dem Beginn des ersten Sprints erfasst und dann vom Team bepreist. Die Schätzung erfolgt dabei grobgranular (eher in Personentagen als in Personenstunden). Das Product Backlog ist eine lebendiges Dokument: es kann jederzeit vom Product Owner erweitert, gekürzt, verändert und repriorisiert werden. Es ist jedoch darauf zu achten, dass, wenn neue Anforderungen hinzukommen oder bestehende geändert werden, das Entwicklungsteam diese zeitnah abschätzt. Ein Format für das Product Backlog ist bei Scrum nicht vorgegeben. Eine minimale Version enthält neben den Anforderungen und dem jeweiligen Aufwand auch noch ein Themengebiet, welches verwendet wird, um Anforderungen zu gruppieren (dies wird z.b. in der Sprint Planung verwendet, s.u.). Auch die Art und Weise, wie Anforderungen definiert werden, ist bei Scrum bewusst offen gelassen. Thema Anforderung Aufwand Formatvorlagen Zeichenvorlagen sollen angewendet werden können 2 PT 26