Präsentation einer agilen Methode Adaptive Software Development Rainer Ulrich Überblick 1. Entstehung 2. Einordnung 3. Manifesto for Agile Software Development 4. Ansatz 5. Adaptive Conceptual Model 5.1. Projekt Mission 5.1.1. Worum geht es bei dem Projekt? 5.1.2. Warum sollen wir das Projekt durchführen? 5.1.3. Wie sollen wir das Projekt durchführen? 5.2. Adaptive Development Cycles 5.2.1 Charakteristika 5.2.2. Speculate 5.2.3. Collabortion 5.2.4. Learn 6. Adaptive Development Model 6.1. Zyklen 7. Adaptive (Leadership-Collaboration) Management Model 8. Chancen und Gefahren 9. Conclusio 1
1. Entstehung Entwicklung durch James Highsmith III im Jahr 2000 Entstanden in der Blütezeit der new economy Standardwerk: Highsmith III, James A.: Adaptive Software Development - A Collaborative Approach to Managing Complex Systems, Dorset House Publishing, 2000 2. Einordnung von Adaptive Software Development Agile Methode im Gegensatz zu monumentalen Methoden (V-Modell, Wasserfallmodell) Für große, komplexe Projekte entwickelt Reaktion auf Überbürokratisierung von Modellen wie V-Modell oder Wasserfallmodell 2
3. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 4. Der Ansatz von Adaptive Software Development Annahmen: Zu starre Abläufe verhindern Anpassung an ständig sich ändernde Anforderungen Zeit = Geld = Marktposition Schlussfolgerung: Entwicklungsprozess so weit planen, wie gerade notwendig Am Rande des Chaos zum Ziel Gerade gut genug, um Funktion zu erfüllen Komponenten-fokussiertes Vorgehen Vorbild Microsoft 3
Adaptive Software Development - was ist das konkret? Adaptive Development Framework: 1. Adaptive Conceptual Model 2. Adaptive Development Model 3. Adaptive (Leadership- Collaboration)Management Model 5.1. Projekt Mission Es wird eines der Kriterien Umfang, Zeit, Budget und Qualität als das wichtigste definiert. Von Bedeutung, um nachher Trade-offs machen zu können. Fragen stellen: 5.1.1. Worum geht es bei dem Projekt? 5.1.2. Warum sollen wir das Projekt durchführen? 5.1.3. Wie sollen wir das Projekt durchführen? 4
5.1.3 Wie sollen wir das Projekt durchführen? Mehrere Dokumente empfohlen: Project Vision Hauptvorteil des Projekts, spätere Anwender, Projekthintergrund, Projektumfang in Functionpoints, Zeitrahmen, Budget, Personalbedarf, Risiko und größere Projektvision Project Data Sheet Das Allerwichtigste des Projekts auf einer Seite zusammenfassen Product Specification Outline Projektrahmen abstecken. Festlegen, was das Projekt nicht beinhaltet 5.2. Adaptive Development Cycles (1) Charakteristika: Mission Driven: Die Aktivitäten in jedem Entwicklungszyklus müssen durch die Projektmission gerechtfertigt werden Component Based: Die Software soll Stück für Stück zusammengebaut werden. Am Ende jedes Zyklus steht eine funktionierende Software Iterative: Nicht nach Wasserfall Prinzip, sondern in Iterationen 5
5.2. Adaptive Development Cycles (2) Charakteristika Time-Boxed: Jeder Zyklus bekommt eine strikte Deadline. Damit sollen schon früh Entscheidungen für Trade-offs getroffen werden Change tolerant: Fähig, sich an neue Anforderungen zu adaptieren Risk driven: Risikobehaftete Teile zuerst erarbeiten 5.2. Adaptive Development Cycles (3) Phasen des iterativen Zyklus: 1.2.1 Speculate 1.2.2. Learn 1.2.3. Collaborate 6
5.2.1. Speculate In anderen Modellen heißt diese Phase Planung. Terminus Speculate gewählt, um Abänderbarkeit der Planung auszudrücken. 5.2.2. Collaboration Unterstreichung der Bedeutung von Teamwork 7
5.2.3. Learn Soll das Reagieren auf Veränderungen hervorstreichen 6. Adaptive Development Model Beschreibt wie die Projektzyklen zu organisieren sind Jeder Zyklus soll ein Stück vorführbare Software hervorbringen Time boxing: Verbindlicher Zeitrahmen pro Zyklus, der im Notfall auch durchgeboxt wird Trade-off. Nur mit Einwilligung aller (einschließlich des Kunden) ist Verschiebung möglich 8
6.1. Zyklen Zyklus 1: Menüs und Navigationsleisten, Anfragemasken, Datenbankanbindungen etc. Zyklus 2: Einarbeiten der Änderungswünsche des Kunden, Testen etc. Zyklus 3: Verfeinerung der Komponenten, Erreichung eines akzeptablen Fehlerlevels Zyklus 4: Anwenderdokumentation, Installation, Trainingsprogramme 7. Adaptive (Leadership-Collaboration) Management Model Beziehungen statt Meetings Aufbau von Zweierbeziehungen zwischen Abteilungen -. dadurch Gewährleistung von Informationsfluss Kein hierarchischer Führungsstil Einsetzung von Kommunikationsprofis zur Moderation von Meetings 9
8. Chancen und Gefahren des Modells + Keine Verbürokratisierung Pragmatischer Ansatz zu Softwarequalität Im Mittelpunkt der Mensch - unpräzise Birgt Gefahr, wichtige Aufgaben aus Bequemlichkeit auszulassen Bringt nicht viel Neues 9. Conclusio Wer eine weltbewegende Neuschöpfung wie einen spiralförmig, aufwärts fließenden Wasserfall erwartet hat, wurde enttäuscht Wie bei vielen Modellen, besteht auch hier die Leistung nicht darin, neue Erkenntnisse aufzubringen, sondern alte kompakt zusammenzufassen 10
Danke für Eure Aufmerksamkeit 11