Advanced Software Engineering WS0910 Kapitel1 Dr. Dominik Haneberg
AGILE METHODEN 15.12.2009 Advanced Software Engineering 11
Inhalte dieses Kapitels Warum agil? Agile Methoden vs. schwergewichtige Prozesse Das Agile Manifesto Agile Werte, Prinzipien, Praktiken und Methodiken XP, Scrum und Crystal Kritische Betrachtung Indikation und Kontraindikation 15.12.2009 Advanced Software Engineering 12
Agil? Warum denn auch das noch? Unified Process [1996] 2009: 30 % der Softwareprojekte voll erfolgreich V-Modell [1986] Wasserfallmodell [1970] Softwarekrise [1968, NATO- Konferenz in Garmisch] 15.12.2009 Advanced Software Engineering 13
Erfolgsgeschichte Software Engineering? Nach 40 Jahren Softwaretechnik hat sich der relative Anteil der erfolgreichen, problematischen und total abgestürzten Projekte nicht signifikant verschoben Andererseits: Softwareprojekte sind heute um Größenordnungen komplexer als vor 40 Jahren Methodischen Fortschritte durch Komplexitätszuwachs verbraucht Andere Sichtweise: Die eingesetzten Prozesse fokussieren nicht auf das, was eigentlich wichtig ist 15.12.2009 Advanced Software Engineering 14
15.12.2009 Advanced Software Engineering 15
Agile vs. schwergewichtige Prozesse Schwergewichtige Prozesse Dokumentenzentriert Up-Front Design Reglementiert Abarbeitung eines Plans Lange Releasezyklen Agile Prozesse Codezentriert Minimale Analyse zu Beginn Adaptiv, Prozess wird angepasst Ständige Anpassung der Ziele Häufiges Deployment 15.12.2009 Advanced Software Engineering 16
Das Agile Manifest 2001 von vielen Vertretern leichtgewichtiger Vorgehensweisen auf einer Tagung aus der Taufe gehoben Bewusst politisierender Gegenentwurf zu den etablierten Vorgehensweisen Argumentativ stark aus Praxis/Projekterfahrung geprägt Hat viele Unterstützer gefunden 15.12.2009 Advanced Software Engineering 17
Das Agile Manifest Wir entdecken Wege, Software besser zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Arbeit haben wir Folgendes zu schätzen gelernt: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Funktionierende Software ist wichtiger als umfassende Dokumentation. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Sich auf unbekannte Änderungen einzustellen, ist wichtiger als einem Plan zu folgen. Wir schätzen aufgrund unserer Erfahrung die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite höher. www.agilemanifesto.org 15.12.2009 Advanced Software Engineering 18
Werte, Prinzipien, Praktiken, Methodiken Werte Grundsätze, wie Projekte das Problem der Änderungen angehen sollen Prinzipien Konkretisieren Werte und sollen helfen diese umzusetzen Praktiken Konkrete Handlungsempfehlungen für die Softwareentwicklung Methodiken Kombination von Praktiken, die einer bestimmten Philosophie folgt 15.12.2009 Advanced Software Engineering 19
Werte, Prinzipien, Praktiken, Methodiken 15.12.2009 Advanced Software Engineering 20
Änderungskosten Kosten pro Änderung Prädiktive Vorgehensweise Adaptive Vorgehensweise Zeit 15.12.2009 Advanced Software Engineering 21
Die agilen Werte 15.12.2009 Advanced Software Engineering 22
Die agilen Werte 15.12.2009 Advanced Software Engineering 23
Die agilen Werte 15.12.2009 Advanced Software Engineering 24
Die agilen Werte 15.12.2009 Advanced Software Engineering 25
Die 12 agilen Prinzipien Unsere höchste Priorität liegt darin, den Kunden durch frühzeitige und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Das Wichtigste sind die Bedürfnisse des Kunden Aktivitäten darauf ausgerichtet, dass Kunde die Software baldmöglichst einsetzen kann 15.12.2009 Advanced Software Engineering 26
Die 12 agilen Prinzipien Begrüße sich verändernde Anforderungen, selbst wenn sie erst spät bei der Entwicklung auftreten. Agile Prozesse nutzen Änderungen zugunsten des Wettbewerbsvorteils des Kunden. Von Anfang an auf unvorhersehbare Änderungen einstellen Änderungen nicht als Problem verstehen 15.12.2009 Advanced Software Engineering 27
Die 12 agilen Prinzipien Liefere häufig funktionierende Software aus, innerhalb weniger Wochen oder Monate, wobei der kürzeren Zeitspanne eindeutig der Vorzug zu geben ist. Kunde soll neue Funktionalität schnell gewinnbringend einsetzen können Frühes Feedback erlaubt bessere Steuerung 15.12.2009 Advanced Software Engineering 28
Die 12 agilen Prinzipien Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten. Probleme werden durch enge Zusammenarbeit von Domänenfachleuten und Entwicklern früher erkannt 15.12.2009 Advanced Software Engineering 29
Die 12 agilen Prinzipien Baue deine Projekte mit motivierten Mitarbeitern auf. Gib ihnen die Umgebung und die Unterstützung, die sie benötigen und vertraue ihnen, dass sie ihre Arbeit erfolgreich beenden Motivierte Mitarbeiter auswählen Mitarbeiter unterstützen Fachliche Entscheidungen den Mitarbeitern überlassen 15.12.2009 Advanced Software Engineering 30
Die 12 agilen Prinzipien Die effektivste und effizienteste Methode, Informationen einem Entwicklungsteam zukommen zu lassen bzw. innerhalb eines Entwicklungsteams auszutauschen, ist die direkte Kommunikation von Angesicht zu Angesicht. Direkte Kommunikation wirkungsvoller, nonverbale Komponente geht nicht verloren Verständnisschwierigkeiten können oft direkt aufgelöst werden 15.12.2009 Advanced Software Engineering 31
Die 12 agilen Prinzipien Funktionierende Software ist der primäre Maßstab für Fortschritt. Funktionierende Software ist besser als Pläne, wie Software funktionieren könnte Nur durch funktionierende Software kann beurteilte werden, ob das Projekt weiter fortgeschritten ist 15.12.2009 Advanced Software Engineering 32
Die 12 agilen Prinzipien Agile Methodiken fördern die kontinuierliche Entwicklung. Geldgeber, Entwickler und Anwender sollten in der Lage sein, ein beständiges Tempo unbegrenzt beizubehalten. Wenn nachts und in Überstunden entwickelt wird erreicht man nur, dass die dabei produzierten Fehler am Folgetag wieder ausgebaut werden müssen 15.12.2009 Advanced Software Engineering 33
Die 12 agilen Prinzipien Ständige Aufmerksamkeit gegenüber technisch hervorragender Qualität und gegenüber gutem Design erhöht die Agilität. Entwickler sollten technisch up-to-date sein Wissen über technische Fortschritte erlaubt qualitativ bessere Software 15.12.2009 Advanced Software Engineering 34
Die 12 agilen Prinzipien Einfachheit die Kunst, unnötige Arbeit zu minimieren ist essentiell. Leichte Änderbarkeit reduziert Aufwand Einfachheit sorgt für leichte Änderbarkeit Daher alle Artefakte so einfach wie möglich 15.12.2009 Advanced Software Engineering 35
Die 12 agilen Prinzipien Die besten Architekturen, Anforderungen und Designs ergeben sich aus sichselbst-organisierenden Teams. Entscheidungen dem Team überlassen, anstatt sie vorzugeben In der Regel finden weitegehend selbstorganisierende Teams besser Lösungen 15.12.2009 Advanced Software Engineering 36
Die 12 agilen Prinzipien In regelmäßigen Abständen macht sich das Team Gedanken darüber, wie effektiver gearbeitet werden kann und passt sein Verhalten entsprechend an. Es ist wichtig regelmäßig über die eigene Arbeit nachzudenken und Verbesserungsmöglichkeiten auszuloten Es ist praktisch unmöglich, am Anfang die beste Methodik für ein Projekt zu bestimmen 15.12.2009 Advanced Software Engineering 37
Praktiken Meistens konkrete Handhabungsformen, die beschreiben, wie Software entwickelt werden sollte Sind nicht Teil des agilen Manifests Auswahl der Praktiken wird den Methodiken überlassen Großen Anzahl, oftmals mehrere Synonyme für dieselbe Idee 15.12.2009 Advanced Software Engineering 38
Praktiken Nicht alle Praktiken sind bahnbrechend neue Ideen. Viele existieren schon länger (z. B. Refactoring) Einige Praktiken entfalten ihren Nutzen nur im Zusammenspiel mit bestimmten anderen Praktiken, z. B. Refactoring und Regressionstests Eine Methodik ist eine Festlegung einer Menge von Praktiken (die idealerweise einer bestimmten Philosophie folgen) 15.12.2009 Advanced Software Engineering 39
Methodiken Eine Methodik legt für ein Projekt einen bestimmten Satz an Praktiken verbindlich fest P6 P5 P1 P4 P2 P3 Methodik 1 Eine Methodik heißt agil, wenn sie sich an den Werten und Prinzipien des agilen Manifest orientiert Es sind also viele agile Methodiken möglich 15.12.2009 Advanced Software Engineering 40
Methodiken In [Abrahamsson et al.] finden sich vier Eigenschaften, die eine agile Methodik aufweisen muss Inkrementell Kooperativ Unkompliziert Adaptiv P. Abrahamsson et al.: Agile Software Development Methods Review and Analysis, VTT publications, 2002 15.12.2009 Advanced Software Engineering 41
METHODIKDESIGN 101 15.12.2009 Advanced Software Engineering 42
Warum eine Methodik? Koordination der Projektbeteiligten Vermeidet es Fehler zu wiederholen (Eine Methodik sollte aus ausreichend Erfahrung abgeleitet sein) Vertrauensgewinn beim potentiellen Auftraggeber 15.12.2009 Advanced Software Engineering 43
Methodikdesign Ähnlich zu einem Brunch: Große Auswahl und nicht alles passt zusammen Methodiken sind soziale Konstrukte (Die Konventionen, die die Gruppe akzeptiert) Wie bewertet man Methodiken, um eine gute zu erstellen Elemente Metriken 15.12.2009 Advanced Software Engineering 44
Methodikelemente A. Cockburn: Agile Software Development The Cooperative Game, Addison Wesley, 2007 15.12.2009 Advanced Software Engineering 45
Metriken Erlauben den Vergleich anhand einer Skala Beispiele: Größe der Methodik Zeremonie Gewicht der Methodik (Indikator für Inflexibilität) Problemgröße Kritikalität Sichtbarkeit Stabilität 15.12.2009 Advanced Software Engineering 46
Metriken Größe der Methodik 15.12.2009 Advanced Software Engineering 47
Metriken Zeremonie: Detaillierungsgrad der Artefakte und Toleranz gegenüber Abweichungen Gewicht der Methodik: Produkt aus Größe und Zeremonie Problemgröße: Wie komplex ist das zu lösende Problem 15.12.2009 Advanced Software Engineering 48
Metriken Kritikalität Größe des Schadens, wenn die Software nicht funktioniert Cockburn unterscheidet u. a. in der Crystal- Methodenfamilie folgende Grade: Klasse C (Comfort) D (Discretionary Money) E (Essential Money) L (Life) Beschreibung Komfort des Benutzer beeinträchtigt Überschaubarer finanzieller Schaden Erheblicher finanzieller Schaden (jenseits der Portokasse) Gefahr für Menschenleben A. Cockburn: Agile Software Development The Cooperative Game, Addison Wesley, 2007 15.12.2009 Advanced Software Engineering 49
Metriken Sichtbarkeit: Wie transparent sind die Vorgänge in einem Projekt Stabilität: Wie hoch ist die Wahrscheinlichkeit einer Veränderung 15.12.2009 Advanced Software Engineering 50
Ansätze für das Design einer Methodik Tailoring: Bestehende Methodik anpassen Kombination: Das Beste aus mehreren Methodiken kombinieren Die Methodik muss ausgewogen und der jeweiligen Situation angemessen sein (keine Überbetonung einzelner Aspekte) 15.12.2009 Advanced Software Engineering 51
Häufige Fehler Eierlegende Wollmilchsau Bisher nicht in Erscheinung getreten Unnötiges Beiwerk mangels Vertrauen Viel hilft viel 15.12.2009 Advanced Software Engineering 52
Häufige Fehler Ideenkill ( Das funktioniert bestimmt nicht. ) Das Prinzip Hoffnung ( Das müsste eigentlich funktionieren. ) Missachtung des Zusammenspiels einzelner Praktiken Vernachlässigung des Faktors Mensch 15.12.2009 Advanced Software Engineering 53
Cockburns 10 Prinzipien 1. Unterschiedliche Projekte erfordern unterschiedliche Methodiken. 2. Übermäßiges Gewicht in der Methodik ist kostspielig. 3. Größere Teams erfordern mehr Kommunikationspraktiken. 4. Projekte mit höherem potentiellen Schaden erfordern mehr Praktiken zur Überprüfung. 15.12.2009 Advanced Software Engineering 54
Cockburns 10 Prinzipien 5. Disziplin, Können und Verständnis können nicht durch Verfahren, Formalitäten und Dokumentation ersetzt werden. 6. Interaktive, direkte Kommunikation ist der günstigste und schnellste Kanal zum Austausch von Informationen. 7. Die Zunahme an Kommunikation und Feedbacks reduziert das Bedürfnis nach Dokumentation. 15.12.2009 Advanced Software Engineering 55
Cockburns 10 Prinzipien 8. Nebenläufige Entwicklung erhöht die Geschwindigkeit und Flexibilität; serielle Entwicklung verringert die Kosten. 9. In Aktivitäten ohne Flaschenhals ist Effizienz entbehrlich. 10. Bestimmte Praktiken ( Sweet Spots ) beschleunigen die Entwicklung. A. Cockburn: Agile Software Development The Cooperative Game, Addison Wesley, 2007 15.12.2009 Advanced Software Engineering 56
Cockburns Sweet Spots Projekte sollten versuchen, sich soweit wie möglich folgenden Praktiken zu nähern: Für jeden Entwickler nur eine einzige Aufgabe Einsatz von erfahrenen Entwicklern Kleine Teams, deren Mitglieder am gleichen Ort platziert sind Automatische Regressionstests Leichter Zugang zu den Benutzern Kleine Inkremente und häufige Auslieferung an echte Benutzer 15.12.2009 Advanced Software Engineering 57
PRAKTIKEN 15.12.2009 Advanced Software Engineering 58
Praktiken Praktiken sind konkrete Anleitungen, wie Software entwickelt werden soll Praktiken in den meisten Fällen aus Erfahrungswerten aus Projekten abgeleitet Es gibt sehr viele verschiedene Praktiken, keine Methodik nutzt alle Im Folgenden werden einige Praktiken beispielhaft vorgestellt 15.12.2009 Advanced Software Engineering 59
Pair Programming Immer zwei Entwickler an einem Computer Einer hat Tastatur und Maus und entwickelt Code Der Andere überwacht, denkt voraus an die nächsten Schritte Die Partner wechseln wiederholt die Rollen Besetzung der Paare wird regelmäßig gewechselt 15.12.2009 Advanced Software Engineering 60
Refactoring Code ist wie Käse, mit der Zeit beginnt er zu stinken ( code smells ) Refactoring verbessert bestehenden Code, ohne die Funktionalität zu verändern Umbenennen von Klassen Entfernen von redundantem Code Extrahieren von Interfaces Toolsupport wichtig Mehr zu Refactoring später 15.12.2009 Advanced Software Engineering 61
Beispiel zu Refactoring Version 1 Version 2 public class Circle { private double radius; } public void setradius(double radius) { this.radius = radius; } public double getperimeter() { double perimeter = 2 * 3.141592 * radius; return perimeter; } public double getarea() { double area = 3.141592 * Math.pow(radius,2); return area; } 15.12.2009 Advanced Software Engineering 62
Beispiel zu Refactoring Version 1 Version 2 public class Circle { private double radius; public class Circle { public static final double PI = 3.141592; } public void setradius(double radius) { this.radius = radius; } public double getperimeter() { double perimeter = 2 * 3.141592 * radius; return perimeter; } public double getarea() { double area = 3.141592 * Math.pow(radius,2); return area; } } private double radius; public void setradius(double radius) { this.radius = radius; } public double getperimeter() { double perimeter = 2 * PI * radius; return perimeter; } public double getarea() { double area = PI * Math.pow(radius,2); return area; } 15.12.2009 Advanced Software Engineering 63
Product Backlog Öffentliche Liste aller Aufgaben, die für das Endprodukt noch getan werden müssen Nicht nur Funktionalität, auch Bugfixes und Dokumentationsbedarf, Alle Einträge werden mit Priorität und Aufwandsschätzung versehen 15.12.2009 Advanced Software Engineering 64
Product Backlog Es muß nicht immer alles elektronisch sein 15.12.2009 Advanced Software Engineering 65
Collective Code Ownership Das Team als Gemeinschaft ist der Besitzer des Codes Jeder kann jeden Teil des Codes jederzeit ändern Wer der ursprüngliche Autor war, ist irrelevant Für alle gelten dieselben Programmierstandards und -richtlinien Hilft den Truckfaktor niedrig zu halten 15.12.2009 Advanced Software Engineering 66
Praktikenbasar Machbarkeitsanalyse (Proof of concept) Anforderungspatterns Glossar Kunde vor Ort MoSCoW-Regel C. Dogs, T. Klimmer: Agile Software Entwicklung kompakt, mitp-verlag, 2005 http://www.noop.nl/2009/04/the-big-list-of-agile-practices.html 15.12.2009 Advanced Software Engineering 67
Praktikenbasar Planning Game Prototypen Requirements Management CRC-Karten Designmentor 15.12.2009 Advanced Software Engineering 68
Praktikenbasar Design Patterns Öffentliche Modellpräsentation (Wall of Wonders) Coding Standards Collective Ownership Individual Code Ownership 15.12.2009 Advanced Software Engineering 69
Praktikenbasar Kurze Releases Pair Programming Refactoring Monkey-Tests Regressionstests 15.12.2009 Advanced Software Engineering 70
Praktikenbasar 40-Stunden-Woche Weiterbildung Knowledge-Base/Wiki Selbstorganisierende Teams Tägliches Stand-Up-Meeting 15.12.2009 Advanced Software Engineering 71
Praktikenbasar Timeboxing Anti-Patterns Einfachheit Risikogetriebene Priorisierung 15.12.2009 Advanced Software Engineering 72
METHODIKEN 15.12.2009 Advanced Software Engineering 73
Methodiken gibt s viele XP Adaptive Software Development (ASD) Crystal dx Scrum PP Feature-Driven Development (FDD) Dynamic Systems Development Method (DSDM) 15.12.2009 Advanced Software Engineering 74
Taxonomie von Methodiken Prozessorientiert Mitarbeiterzentriert Werkzeugzentriert Unvollständig XP ASD dx (RUP agil) Agile Modeling (AM) Scrum Crystal Agile Database Techniques (ADT) DSDM Lean Software Development (LSD) FDD Pragmatic Programming (PP) 15.12.2009 Advanced Software Engineering 75
EXTREME PROGRAMMING 15.12.2009 Advanced Software Engineering 76
Extreme Programming Bekannteste Agile Methodik Von Kent Beck, Ward Cunningham und Ron Jeffries 1996 entwickelt Entstand aus Erfahrungen im C3 Projekt (Chrysler Comprehensive Compensation System) von Chrysler XP stellt Entwickler und Kunden in den Vordergrund Praktiken zielen auf Programmierung und Einbindung des Kunden 15.12.2009 Advanced Software Engineering 77
Aspekte Prozess Rollen Praktiken Werte XP Anwendung 15.12.2009 Advanced Software Engineering 78
Werte im XP Kommunikation Nicht mit den Werten des agilen Manifests verwechseln! XP war früher! Mut XP Einfachheit Feedback 15.12.2009 Advanced Software Engineering 79
Prinzipien im XP Unmittelbares Feedback Qualitätsarbeit Einfachheit anstreben Veränderung wollen Inkrementelle Veränderung 15.12.2009 Advanced Software Engineering 80
Prinzipien im XP Lernen lehren Ehrliches Messen Geringe Anfangsinvestition Unmittelbares Feedback Mit leichtem Gepäck reisen Auf Sieg spielen Qualitätsarbeit Einfachheit anstreben An örtliche Gegebenheiten anpassen Veränderung wollen Inkrementelle Veränderung Gezielte Experimente Verantwortung übernehmen Offene, aufrichtige Kommunikation Die Instinkte des Teams nutzen, nicht dagegen arbeiten 15.12.2009 Advanced Software Engineering 81
Rollen Big Boss Kunde Management Geschäftsdomäne Coach Tracker Design/ Programmierung Programmierer Tester Consultant Projektunterstützung Sonstige Rollen 15.12.2009 Advanced Software Engineering 82
Rollen Programmierer Entwickeln Architektur Schreiben Quellcode und Unit Tests Big Boss Verantwortlich für Projekterfolg Grundlegende Entscheidungen Unterstützung für das Team, wenn nötig Nicht an der täglichen Arbeit beteiligt 15.12.2009 Advanced Software Engineering 83
Rollen Coach Vergleichbar mit Teamleiter Führt die Programmierer Zeigt wie XP angewandt wird Verantwortlich für Einhaltung der Ziele Ansprechpartner für Teammitglieder Tracker Historiker Sammelt Daten zur Leistung des Teams Achtet auf mögliche Gefährdung der vorgegebenen Zeitrahmen 15.12.2009 Advanced Software Engineering 84
Rollen Kunde Verwendet später die Software Schreibt Story Cards als Anforderungen Schreibt Akzeptanztests Arbeitet mit den Entwicklern zusammen Tester Unterstützt Kunde beim Formulieren von Tests Verantwortlich für regelmäßige Durchführung der Tests und Veröffentlichung der Ergebnisse 15.12.2009 Advanced Software Engineering 85
Rollen Consultant Externer technischer Sachverstand 15.12.2009 Advanced Software Engineering 86
Ablauf der Entwicklung Der eigentliche Prozess Technische Experimente Einweisung des Kunden Exploration Planung Entwicklung Freigabe Wartung Ende 15.12.2009 Advanced Software Engineering 87
Ablauf der Entwicklung Der eigentliche Prozess Exploration Planning Game Planung der Iteration durch Kunde und Entwickler Planung Entwicklung Freigabe Wartung Ende 15.12.2009 Advanced Software Engineering 88
Ablauf der Entwicklung Der eigentliche Prozess Exploration Festlegung der Architektur Schreiben von Unit und Akzeptanztests Paarweises Programmieren der Software Planung Entwicklung Freigabe Wartung Ende 15.12.2009 Advanced Software Engineering 89
Ablauf der Entwicklung Der eigentliche Prozess Exploration Planung Entwicklung Freigabe Wartung Ende Letzte Tests Performanceoptimierungen 15.12.2009 Advanced Software Engineering 90
Ablauf der Entwicklung Der eigentliche Prozess Exploration Planung Entwicklung Freigabe Wartung Ende Überarbeitung der Software im Produktivbetrieb 15.12.2009 Advanced Software Engineering 91
Ablauf der Entwicklung Der eigentliche Prozess Exploration Planung Entwicklung Freigabe Wartung Schreiben der Abschlussdokumentation Projektabschluss Ende 15.12.2009 Advanced Software Engineering 92
Explorationsphase Werkzeuge kennenlernen Technische Ansätze ausprobieren Kunde bekommt Methodik und seine spätere Rolle erklärt Wenige Wochen bis sehr wenige Monate. Falls mehr Zeit benötigt wird, Projektumfang verkleinern und Projekt so überschaubarer machen [Beck, 2000, Extreme Programming Explained] 15.12.2009 Advanced Software Engineering 93
Planungsphase Kunden und Entwickler entscheiden gemeinsam im Planning Game, welche Funktionalität im nächsten Release enthalten sein soll und wann diese implementiert werden soll Planning Game maximal 1 bis 2 Tage [Beck, 2000, Extreme Programming Explained] Hauptziel der ersten Iteration sollte hauptsächlich eine grobe Architektur des Systems sein 15.12.2009 Advanced Software Engineering 94
Ablauf Planungsphase 1. Kunde formuliert seine Anforderungen auf Story Cards 2. Entwickler schätzen den Aufwand jeder einzelnen Karte und stellen Anhängigkeiten fest (A nicht vor B) 3. Kunde priorisiert die einzelnen Karten (entsprechend seinem Nutzen) 4. Auf Basis von Prioritäten und Aufwänden werden gemeinsam die Karten ausgewählt, die implementiert werden. Ergebnis: Iterationsplan (welche Funktionalität in welcher Iteration) 15.12.2009 Advanced Software Engineering 95
Story Card 15.12.2009 Advanced Software Engineering 96
Story Cards 15.12.2009 Advanced Software Engineering 97
Aufwandsschätzungen Gestern Heute 15.12.2009 Advanced Software Engineering 98
Aufwandsschätzungen Wie schätzt man Aufwände? Alle Teammitglieder sind in den Schätzprozess eingebunden Technische und organisatorische Rahmenbedingungen müssen klar sein Anforderungen dürfen eine gewisse Maximalgröße nicht überschreiten Es werden abstrakte Schätzgrößen verwendet W.-G. Bleek, H. Wolf: Agile Softwareentwicklung, dpunkt.verlag,2008 15.12.2009 Advanced Software Engineering 99
Schätzpokern Geschätzter Aufwand 1. Jedes Teammitglied erhält eine Farbe 2. Anforderung wird vorgelesen 3. Alle wählen ihre Schätzungskarte aus 4. Schätzung wird verdeckt hingelegt 5. Umdrehen, wenn alle geschätzt haben Diskussionsbedarf 15.12.2009 Advanced Software Engineering 100
Sching-Schang-Schong-Schätzen Funktioniert wie Kinderspiel Schere-Stein-Papier Wertungsskala 1 bis 5 Alle rufen Sching-Schang-Schong und signalisieren dann mit der Hand ihre Schätzung Abweichung mehr als 2: Diskussionsbedarf 15.12.2009 Advanced Software Engineering 101
Hierarchisches Schätzverfahren Wenn die Zahl der User-Stories zu groß wird oder nicht alle User-Stories erfasst werden können, werden beim Schätzen zusätzliche Hierarchieebenen eingezogen Kunde Lösche Kunde Bearbeite Kunde Drucke Kundenliste nach PLZ Zeige Kundenliste an Öffne Kunden aus Liste Prüfe Plausibilität vor Speichern Speichere Kunden User - Stories Subsystem Features 15.12.2009 Advanced Software Engineering 102
Hierarchisches Schätzverfahren Man benötigt mindestens 1 Subsystem, für das alle Features erfasst sind und darunter mindestens 1 Feature, für das alle Stories erfasst sind Zuerst wird Top-Down geschätzt Alle Subsysteme in syep (System effort point) Alle Features in feep Alle Stories in step Dann ermittelt man wie viele Personentage ein step sind (z. B. durch Programmieren einiger Stories) Dann werden Botton-Up die konkreten Aufwände berechnet 15.12.2009 Advanced Software Engineering 103
Beispiel zu hierarchischem Schätzen Kunde Zeige Kundenliste 2 step Bearbeite Kunde 3 feep Öffne Kunden aus Liste 1 step Drucke Kundenliste nach PLZ 2 feep Lösche Kunde 1 feep 2 syep Prüfe Plausibilität vor Speichern 3 step Speichere Kunden 1 step Auftrag Rechnung Lohn 5 syep 2 syep 3 syep Außerdem bekannt: 1 step 2 PT 15.12.2009 Advanced Software Engineering 104
Entwicklungsphase Am Anfang: Entwickler sprechen sich ab, wie in der Iteration vorzugehen ist und wie das grobe Design für die Funktionalitäten auf den Story Cards aussehen soll Implementieren der Funktionalitäten einzelner Story Cards im paarweisen Programmieren und nach dem Test Driven Development (TDD)-Ansatz Tracker beobachtet Fortschritt der Implementierung (um im nächsten Planning Game beim Schätzen der Aufwände zu helfen) 15.12.2009 Advanced Software Engineering 105
TDD Ablauf Unit Test für neuen Code schreiben Refactoring erfolgreich Test ausführen Test nicht bestanden Code schreiben bzw. ändern Test bestanden Refactoring 15.12.2009 Advanced Software Engineering 106
Entwicklungsphase Kommt es in der Iteration zu Unklarheiten, werden diese mit den anderen Entwicklern oder dem Kunde (on-site customer) geklärt Abschloss einer Iteration nach der zuvor festgelegten Dauer (1 bis 4 Wochen). Ergebnis ist funktionierende Software Unit Tests sollte für geringe Fehlerquote sorgen Akzeptanztests werden ausgeführt 15.12.2009 Advanced Software Engineering 107
Entwicklungsphase Akzeptanztests wurden während der Iteration von Kunde und Tester zusammen entwickelt Ist das Ergebnis nicht zufriedenstellend 2 Möglichkeiten Entwickler nehmen kurzfristig Änderungen vor Kunde muss neue Story Card für nächstes Planning Game formulieren Weitere Iteration oder Übergang zu Freigabephase (neues Release), je nach Iterationsplanung Faustregel: 8-10 Iterationen pro Release 15.12.2009 Advanced Software Engineering 108
Akronyme im agilen Umfeld YAGNI: You Ain t Gonna Need It. Keine Technik/Funktionalität/Generalisierung/Abstraktion auf Vorrat KISS: Keep it simple, stupid; DTSTTCPW: Do the simplest thing that could possibly work. Lösungen sollen einfach sein, eine gute Architektur ist zuallererst immer einfach 15.12.2009 Advanced Software Engineering 109
Akronyme im agilen Umfeld DRY: Don t Repeat Yourself; OAOO: Once And Only Once: Eine Entwurfsentscheidung soll sich an genau einer Stelle im Code wiederfinden. SCP: Speaking Code Principle: Code soll seinen Zweck kommunizieren, auch ohne Kommentar und Dokumentation SoC: Separation of Concerns: Jede Klasse soll für ihre Aufgaben zuständig sein, aber eben nur für ihre eine Aufgabe TDA: Tell, Don t Ask: Klassen sollten Funktionalität bereitstellen, nicht nur Daten/Fakten 15.12.2009 Advanced Software Engineering 110
Freigabephase Aktueller Stand (Release-Candidate) wird dem Echtbetrieb übergeben Kunde prüft nochmals genau auf Mängel Entwickler machen Performanceoptimierungen Übergabe an die Anwender 15.12.2009 Advanced Software Engineering 111
Wartungsphase Anpassung der Software an veränderte Bedingungen Beheben von Fehlern Neue Anforderungen werden umgesetzt Software, die bereits im Einsatz ist, erfordert höhere Vorsicht bei Änderungen 15.12.2009 Advanced Software Engineering 112
Endphase Projekt endet, wenn keine weiteren Wünsche seitens des Kunden vorliegen 10- bis 15-seitige Dokumentation zu Software und Quellcode Das ist nicht die Benutzerdokumentation 15.12.2009 Advanced Software Engineering 113
Detailansicht des Prozesses 15.12.2009 Advanced Software Engineering 114
Praktiken des XP (V1) Managementtechniken Kunde vor Ort Programmierstandards Retrospektive Planungsspiel Gemeinsame Verantwortlichkeit Testen Refactoring Einfaches Design Programmieren in Paaren Nachhaltiges Tempo Standup- Meeting Fortlaufende Integration Metapher Kurze Releasezyklen 15.12.2009 Advanced Software Engineering 115
Praktiken des XP (V1) Kunde vor Ort Teamtechniken Programmierstandards Retrospektive Planungsspiel Gemeinsame Verantwortlichkeit Testen Refactoring Einfaches Design Programmieren in Paaren Nachhaltiges Tempo Standup- Meeting Fortlaufende Integration Metapher Kurze Releasezyklen 15.12.2009 Advanced Software Engineering 116
Praktiken des XP (V1) Kunde vor Ort Programmierstandards Programmiertechniken Retrospektive Planungsspiel Gemeinsame Verantwortlichkeit Testen Refactoring Einfaches Design Programmieren in Paaren Nachhaltiges Tempo Standup- Meeting Fortlaufende Integration Metapher Kurze Releasezyklen 15.12.2009 Advanced Software Engineering 117
Weitere Praktiken/Empfehlungen Offene Arbeitsumgebung 15.12.2009 Advanced Software Engineering 118
Weitere Praktiken/Empfehlungen Informativer Arbeitsplatz 15.12.2009 Advanced Software Engineering 119
Weitere Praktiken/Empfehlungen CRC-Karten 15.12.2009 Advanced Software Engineering 120
Weitere Praktiken/Empfehlungen Just Rules Lokale Anpassungen Parties 15.12.2009 Advanced Software Engineering 121
XP V2 Ende 2004 überarbeitete Version von Kent Becks extreme Programming explained Heißt auch XP2 Zusätzlicher Wert: Respekt Jetzt auch Ergänzung um projektspezifische Werte möglich Wikipedia beschreibt XP2: http://de.wikipedia.org/wiki/extreme_programming 15.12.2009 Advanced Software Engineering 122
XP V2 Prinzipien 15.12.2009 Advanced Software Engineering 123
XP V2 Praktiken 15.12.2009 Advanced Software Engineering 124
XP V2 Ergänzende Praktiken Echte Kundenbeteiligung Inkrementelles Deployment Team-Kontinuität Schrumpfende Teams Ursprungsursachen- Analyse Gemeinsamer Code Code und Tests Eine Codebasis Tägliches Deployment Vertrag mit verhandelbarem Umfang Bezahlung pro Benutzung 15.12.2009 Advanced Software Engineering 125
Neue und alte Praktiken 15.12.2009 Advanced Software Engineering 126
Bewertung/Anwendbarkeit XP ist nur für kleine Teams ausgelegt ( 10 Entwickler). XP erfordert hochqualifizierte Mitarbeiter. Die XP-Praktiken sind untereinander stark verkettet. Das erzwingt ein Alles oder Nichts -Vorgehen. Wenn kein Kunde vor Ort möglich, da keiner existent (Software für den Massenmarkt), sollten ausgewählte Teammitglieder diese Rolle Vollzeit übernehmen. 15.12.2009 Advanced Software Engineering 127
Bewertung/Anwendbarkeit Gibt es mehrere Kunden, kann es Probleme geben, wenn die Machtverhältnisse nicht geklärt sind Die am häufigsten verwendete agile Methodik, aber fast immer an das Projekt angepasst (und so soll es auch sein!) 15.12.2009 Advanced Software Engineering 128
XP Simulation 15.12.2009 Advanced Software Engineering 129
SCRUM 15.12.2009 Advanced Software Engineering 130
Scrum Facts Scrum ist ein agiles Managementframework Scrum ist nicht auf Softwareprojekte limitiert...und enthält auch keine Praktiken, die vorschreiben, wie die Software entwickelt werden soll Scrum ist von den Ideen des lean management/lean production inspiriert Erstes Scrum-Projekt war 1993 Einer der Väter ist Jeff Sutherland J. Sutherland: Agile Development: Lessons Learned from the First Scrum, in: Cutter Consortium Agile Project Management Advisory Service. Executive Update, Vol. 5, No. 20, 2004 15.12.2009 Advanced Software Engineering 131
Was ist ein Scrum? Scrum (deut. Gedränge ) ist ein Spielzug aus dem Rugby Der Spielzug ist kompliziert, er muss sorgsam einstudiert und orchestriert werden Verlangt disziplinierte Teamarbeit 15.12.2009 Advanced Software Engineering 132
Scrum ist ein empirischer Prozess: inspect and adapt no silver bullet harte Arbeit für alle Beteiligten inspiriert von den Ideen der lean production (japanische Unternehmen, insb. Toyota) ein Versuch Überlastung systematisch zu vermeiden, durch Selbstverpflichtung eines autonomen Teams 15.12.2009 Advanced Software Engineering 133
Vergleich von Entwicklungszyklen Teufelskreislauf Ziele in Gefahr Mehr Kontrollen Mehr Mitarbeiter, längere Arbeitszeiten Schlechte Softwarequalität, schlechte Mitarbeitermoral 15.12.2009 Advanced Software Engineering 134
Vergleich von Entwicklungszyklen Scrum-Kreislauf Umsetzung von Anforderungen in Software regelmäßig überprüfen Die richtigen Maßnahmen ergreifen Probleme und Hindernisse frühzeitig erkennen Ursachen finden, Lösungsoptionen entwickeln 15.12.2009 Advanced Software Engineering 135
Verbesserungen durch Scrum Mitarbeiterzufriedenheit Kundenzufriedenheit Time to market Qualität Produktivität 15.12.2009 Advanced Software Engineering 136
Scrum Alliance Scrum ist stärker institutionalisiert Es gibt Schulungen zum Certified Scrum Master und Certified Scrum Product Owner www.scrumalliance.org 15.12.2009 Advanced Software Engineering 137
Scrum im Überblick Product Backlog Sprint Backlog Daily Scrum Auslieferbares Produktinkrement Max. 30 Tage User Story 1 Der User soll irgendwas irgendwas können, und ywar möglichst was interesaaantes Sprint 15.12.2009 Advanced Software Engineering 138
Inkrementelle Innovation Anforderungen an neue Version möglichst minimal Dafür so schnell und häufig wie möglich Funktionalität ausliefern Kein Big-Bang -Release mit umfangreichen neuen Funktionen auf einen Schlag Scrum passt hierfür sehr gut, da jeder Sprint ein Produktinkrement erzeugt Vorgehen: Identifiziere die kleinste Menge an vermarktbaren Merkmalen, die einen echten Mehrwert darstellt 15.12.2009 Advanced Software Engineering 139
Vorteile Inkrementeller Innovation Projektdauer und Time-to-market niedriger Früherer break-even und verbesserter cash-flow Risikominimierung durch Reduktion der notwendigen Investitionen pro Version Höhere Profitabilität (besserer ROI) möglich Bessere Vorhersage der Kundenbedürfnisse und schnellere Rückmeldung Kurze Zyklen helfen, termingerecht zu liefern 15.12.2009 Advanced Software Engineering 140
Rollen in Scrum Team Product Owner Scrum Master Scrum 15.12.2009 Advanced Software Engineering 141
Product Owner Anforderungsbeschreibung und management Releasemanagement und Return on Investment Enge Zusammenarbeit mit dem Team Stakeholder-Management Ist nicht der Kunde 15.12.2009 Advanced Software Engineering 142
Scrum Master: Aufgaben Scrum etablieren Das Team unterstützen Direkte Zusammenarbeit zwischen Product Owner und Team sicherstellen Hindernisse beseitigen Entwicklungspraktiken verbessern helfen Führen durch Dienen 15.12.2009 Advanced Software Engineering 143
Scrum Master: Fähigkeiten Moderation Coaching Erfahrung in der (Software-)Entwicklung 15.12.2009 Advanced Software Engineering 144
Scrum Master sollte idealerweise vom Team bestimmt werden sollte keine Personalverantwortung für die Teammitglieder haben hat eine sich über die Projektdauer ändernde Rolle: Vom Vollzeit-Scrum Master als Change Agent zu Beginn bis zum Teilzeit-Scrum Master, der auch an der Erreichung des Sprint-Ziels mitwirkt, am Ende 15.12.2009 Advanced Software Engineering 145
Team Das Team führt alle Arbeiten aus, die zur Umsetzung der Anforderungen in auslieferbare Produktinkremente nötig sind Entscheidend: Die richtigen Mitarbeiter im Team (Mitarbeiter müssen über das relevante Wissen und die notwendigen Fähigkeiten verfügen) Empfehlung: Die Mitarbeiter bestimmen lassen, in welchem Projekt sie mitarbeiten (bei Google sollen sich die Entwickler für Projekte selbst nominieren) 15.12.2009 Advanced Software Engineering 146
Wie sollte das Team sein? Bevollmächtigt (empowered) Autonom Interdisziplinär besetzt Selbstorganisiert Klein 15.12.2009 Advanced Software Engineering 147
Arbeitsorganisation des Teams Vollzeitmitarbeiter Collocation: Alle Arbeitsplätze in unmittelbarer Nähe, am besten in einem Teamraum Team muss Normen und Standards für die Arbeit formulieren Visueller Arbeitsplatz 15.12.2009 Advanced Software Engineering 148
Das Scrum-Team Echtes Team, keine Ansammlung von Individuen Verfolgt gemeinsam ein Ziel Zeichnet sich durch gegenseitigen Respekt und Verständnis seiner Mitglieder aus, folgt gemeinsamen Normen Mitglieder arbeiten eng zusammen und unterstützen sich gegenseitig Teambildungsprozess erforderlich, ein Team entsteht nicht über Nacht 15.12.2009 Advanced Software Engineering 149
Phasen der Teamentwicklung nach Tuckman Änderung der Teamzusammensetzung Forming Norming Storming Performing Änderung der Teamzusammensetzung Bruce W. Tuckman: Developmental Sequence in Small Groups, in: Psychological Bulletin, Vol. 63, 1965 15.12.2009 Advanced Software Engineering 150
und wer macht die Projektleiterjobs? Aufgabenbereich Scope-Management Zeitmanagement Kostenmanagement Kommunikationsmanagement Risikomanagement Qualitätsmanagement Lieferantenmanagement Personalmanagement Scrum-Rollen Product Owner für Produktversion Team für Sprints Product Owner für den Releaseplan Team für das Sprint Backlog Product Owner Product Owner für das Release-Reporting Team für Berichterstattung im Sprint Product Owner mit Input vom Team Product Owner für die Produktleistungsmerkmale Team für qualitätssichernde Maßnahmen Scrum Master für die richtige Anwendung des Prozesses Product Owner und Team Management für die Bereitstellung der Mitarbeiter Team für Produktivität und kontinuierliche Prozessverbesserung 15.12.2009 Advanced Software Engineering 151
Anforderungsgewinnung Anforderungsbeschreibung Umsetzung Traditionelles Vorgehen Anforderungsbeschreibung Umsetzung Sprint 1 Vorgehen in Scrum Sprint n 15.12.2009 Advanced Software Engineering 152
Anforderungsgewinnung Kunde Endanwender Interessenvertreter Product Owner Product Backlog Team 15.12.2009 Advanced Software Engineering 153
Das Product Backlog Nicht fix, sondern ein lebendiges Dokument Entwickelt sich iterativ und inkrementell Scrum kennt keine Change-Requests, dennoch ist es oft nützlich, Änderungen am Product Backlog zu dokumentieren Alle Einträge priorisiert und bzgl. Aufwand geschätzt 15.12.2009 Advanced Software Engineering 154
Das Product Backlog 15.12.2009 Advanced Software Engineering 155
Wie kommt man zum Product Backlog? Produktkonzept Produktidee Product Backlog 15.12.2009 Advanced Software Engineering 156
Das Product Backlog füllen Product Backlog möglichst minimalistisch, dennoch alle wichtigen Anforderungen von Beginn an festhalten Initial mindestens Anforderungen für die erste 2-3 Sprints Zentrale Funktionalität ins Product Backlog, aber auch nichtfunktionale Anforderungen 15.12.2009 Advanced Software Engineering 157
Das Product Backlog füllen Die Einträge im Product Backlog werden unterschiedlich detailliert ausgearbeitet Hoch priorisierte Einträge werden detaillierter erfasst Je höher das Risiko und je niedriger das Domänenwissen des Teams, desto genauer muss eine Anforderung formuliert sein Beschreibungen der Einträge werden über die Zeit verfeinert 15.12.2009 Advanced Software Engineering 158
Themen als Strukturierungswerkzeug Themen gruppieren mehrere inhaltlich zusammenhängende Einträge im Product Backlog Vorteile von Themen Überblick behalten High-level Sicht kann das Priorisieren erleichtern Themen können bei der Freigabeplanung helfen, da für die Endnutzer üblicherweise Merkmalsbündel interessant sind, nicht einzelne Anforderungen. Mit Themen kann der Product Owner leichter überwachen, welchen Fertigstellungsgrad einzelne Merkmalsbündel haben. 15.12.2009 Advanced Software Engineering 159
Zum Product Backlog in 5 Schritten 1. Eigenschaften, die aus dem Produktkonzept folgen, sowie Anforderungen, die durch Fokusgruppen, Kundeninterviews, Anforderungsworkshops, ermittelt wurden, kommen in das Product Backlog 2. Product Owner gruppiert Anforderungen zu Themen 3. Product Owner priorisiert die Themen und ggf. einzelne Anforderungen (in Zusammenarbeit mit dem Team) R. Pichler: Scrum, dpunkt.verlag, 2008 15.12.2009 Advanced Software Engineering 160
Zum Product Backlog in 5 Schritten 4. Product Owner verfeinert die hochprioren Anforderungen (vorzugsweise in Anforderungsworkshops) unter Einbeziehung des Teams 5. Aktualisierung, Verfeinerung oder Löschung existierenden Anforderungen anhand der Ergebnisse nachfolgender Anforderungsworkshops. Neue Themen und Anforderungen werden aufgenommen. 15.12.2009 Advanced Software Engineering 161
Anforderungsworkshop Hilfreiches Werkzeug zur Anforderungsgewinnung, ergänzt Fokusgruppen, Interviews, Beobachtung der Anwender Alle Interessenvertreter an einem Tisch Etabliert gemeinsames Verständnis, sorgt für gemeinsame Sprache und adäquate Beschreibung Mehrere vor dem ersten Sprint, regelmäßig während der Sprints um neue Anforderungen zu bestimmen 15.12.2009 Advanced Software Engineering 162
Priorisieren des Product Backlog Warum? Das Wichtigste zuerst! Zielgerichtete Verfeinerung der wichtigsten Anforderungen Team weiß, was für den Erfolg des Projekts entscheidend ist und fokussiert darauf Priorisieren ist schwierig! Product Owner muss Kundenbedürfnisse genau kennen und beurteilen, welche Funktionen für erfolgreichen Einsatz entscheidend sind 15.12.2009 Advanced Software Engineering 163
Kriterien für Priorisierung Ziel eines Projekts ist die Generierung von Mehrwert Risiko Wert Kosten Primäre Frage: Wie viel Wert schafft eine Anforderung Priorität 15.12.2009 Advanced Software Engineering 164
Risiken Risiko Unsicher Verursacht Schaden In der Zukunft Beispiele sind Verständnis der Anforderung Architektur und Technologieauswahl Infrastruktur und Prozess Je innovativer ein Projekt, desto mehr Unsicherheit Product Owner und Team identifizieren gemeinsam die Risiken (bei jeder Aktualisierung das Releaseplans) 15.12.2009 Advanced Software Engineering 165
Risiken Identifizierte Risiken werden analysiert, Gegenmaßnahmen werden zu neuen Einträgen im Product Backlog Keine Analyse möglich Anforderung hoch priorisieren und im nächsten Sprint umsetzen Ein solches Vorgehen hilft vermeiden, dass Risiken erst spät wirksam werden. Ein early-fail ist dabei nicht ausgeschlossen Scrum ist ein risikoorientierter Ansatz 15.12.2009 Advanced Software Engineering 166
Wert-Risiko-Matrix Risiko Hoch Vermeiden Als erstes Niedrig Zuletzt Als zweites Niedrig Hoch Wert 15.12.2009 Advanced Software Engineering 167
MuSCoW Einteilung Must have Should have Could have Won t have 15.12.2009 Advanced Software Engineering 168
Mehr zu Anforderungen Eine Anforderung sollte die INVEST-Eigenschaften haben Independent Negotiable Valuable Estimable Small Testable 15.12.2009 Advanced Software Engineering 169
Anforderungen erfassen User Stories Beschreiben Anforderungen aus Sicht des Endanwenders Bestandteile Name Kurze Beschreibung der Anforderung Akzeptanzkriterien Text beinhaltet Benutzerrolle, Ziel der User Story und optional den Nutzen des Merkmals 3 C-Bedingung einhalten: Card, Conversation, Confirmation 15.12.2009 Advanced Software Engineering 170
Vorteile von User Stories User Story beschreibt Anforderung zusammen mit Nutzen für Anwender User Stories unterstützen systematische Verfeinerung von Anforderungen Gute User Stories erfüllen die INVEST-Kriterien Einsatz leicht zu erlernen Akzeptanzkriterien bilden gute Grundlage für Akzeptanztests 15.12.2009 Advanced Software Engineering 171
Releaseplanung Ziel: Vorausschauende Steuerung und Optimierung der Kundenzufriedenheit und Wertschöpfung über die Grenzen einzelner Sprints hinweg Aspekte der Releaseplanung: Schätzen Planen Berichten 15.12.2009 Advanced Software Engineering 172
Unterschiede zur traditionellen Releaseplanung Kein detaillierter Plan mit allen Aktivitäten zu Anfang des Projekts Verzicht auf den aussichtslosen Versuch, alle Eventualitäten vorhersehen und planen zu können 15.12.2009 Advanced Software Engineering 173
Releaseplan in Scrum In Scrum ist der Releaseplan eine Vorhersage Basis sind die derzeitigen Informationen zu den geschätzten Aufwänden im Product Backlog der derzeitigen Entwicklungsgeschwindigkeit des Teams 15.12.2009 Advanced Software Engineering 174
Ebenen der Planung Product Backlog Aktueller Fortschritt und aktuelle Probleme Releaseplanung Sprintplanung Tagesplanung Releaseplan Sprint Backlog 15.12.2009 Advanced Software Engineering 175
Typen von Sprints Explorationssprints Standardsprints Releasesprints 15.12.2009 Advanced Software Engineering 176
Beispiel für Releaseplan 15.12.2009 Advanced Software Engineering 177
Verfolgen des Projektfortschritts Häufiger Abgleich zwischen Plan und Wirklichkeit hilft Projektfortschritt zu verstehen und ggf. gegensteuern zu können In Scrum ist Berichterstattung in hohem Maße transparent Verzögerungen/Probleme früh erkennen Traditionell eher Verdrängung von Problemen üblich Releaseberichterstattung basiert auf Aufwänden im Product Backog und dem tatsächlichen Fortschritt 15.12.2009 Advanced Software Engineering 178
Burndown-Chart Release-Burndown Aufwände im Product Backlog 1 2 3 4 5 6 7 Sprints 15.12.2009 Advanced Software Engineering 179
Entwicklungsgeschwindigkeitsbericht Erledigte Aufwandspunkte Ø aller Sprints Ø der 3 schlechtesten Sprints 15 17 18 20 12 20 18 1 2 3 4 5 6 7 Sprints 15.12.2009 Advanced Software Engineering 180
Themenpark Stammt als Berichterstattungsform ursprünglich aus dem FDD Stellt Fertigstellungsgrad und Freigabefähigkeit von Funktionalitätsclustern dar Thema A 4 Geschichten 12 Punkte Thema B 3 Geschichten 4 Punkte Thema C 3 Geschichten 18 Punkte 15.12.2009 Advanced Software Engineering 181
Sprints Sprints im Überblick Verbesserungsmaßnahmen Product Backlog Sprintplanung Umsetzungsaktivitäten und Daily Scrum Sprint-Review und Sprint-Retrospektive 15.12.2009 Advanced Software Engineering 182
Sprints Wandelt Anforderungen in lauffähige, getestete und dokumentierte Software um Vorgehen ist iterativ und inkrementell Agile Entwicklungspraktiken (z.b. TDD) einsetzbar aber nicht festgelegt Während des Sprints keine Änderung an dessen Dauer, den Anforderungen in Sprint Backlog und der Teamzusammensetzung Overhead für Scrum-spezifische Aktivitäten 10% 15.12.2009 Advanced Software Engineering 183
Sprint-Planungssitzung Zur Vorbereitung der Sprint-Planungssitzung definiert der Product Owner das Sprint-Ziel Erklärt allen Beteiligten, was in der Summe das erwartete Ergebnis des Sprints ist Realistisch, kurz und gut verständlich Team in die Formulierung einbeziehen, Release Plan liefert ebenfalls Input Sorgt für einheitliche Ausrichtung aller Beteiliten Erleichtert Kommunikation des Sprint-Inhalts an die Interessenvertreter und die Erfolgskontrolle beginnt der Product Owner einige Tage vorher mit der Verfeinerung und Aufbereitung der Anforderungen (z.b. Anforderungsworkshop) 15.12.2009 Advanced Software Engineering 184
Sprint-Planungssitzung Zur Vorbereitung der Sprint-Planungssitzung werden Aufwände für die ausgewählten Anforderungen geschätzt werden die Anforderungen priorisiert wird die Teamkapazität bestimmt Die Vorbereitung einer Sprint- Planungssitzung ist viel Arbeit. Frühzeitig beginnen! 15.12.2009 Advanced Software Engineering 185
Sprint-Planungssitzung Auswahl eines realistischen Sprint Backlog Scrum Master moderiert Product Owner Sprint-Ziel und Anforderungen Team Aktivitäten bestimmen und schätzen Aufnahme der Anforderung, wenn umsetzbar Teamkapazität im Auge behalten: Planungsglas 15.12.2009 Advanced Software Engineering 186
Sprint-Planungssitzung Ergebnis Vereinbartes realistisches Sprint-Ziel Realistisches Sprint Backlog, zu dem sich das Team verpflichtet hat Typische Fehler Scrum Master plant Ein Teammitglied dominiert Viel Designdiskussion Product Owner identifiziert Aktivitäten Product Owner nimmt nicht teil Aktivitäten zu vage oder zu groß Sitzung schlecht vorbereitet 15.12.2009 Advanced Software Engineering 187
Sprint Backlog Beinhaltet alle Aktivitäten, die zur Umsetzung der Anforderungen notwendig sind Wird täglich aktualisiert Aktivität beginnen: Karte mit Namen kennzeichnen Neue Aktivität identifiziert: Schätzen und in Sprint Backlog einfügen Am Ende des Tages aktualisieren alle Teammitglieder die Aktivitäten, an denen sie gearbeitet haben und schätzen den Restaufwand 15.12.2009 Advanced Software Engineering 188
Sprint Backlog 15.12.2009 Advanced Software Engineering 189
Daily Scrum Max. 15 Minuten Immer zur gleichen Zeit am selben Ort Ziel: Selbstorganisation des Teams unterstützen, Hindernisse identifizieren Wer: Komplettes Team, Scrum Master. Product Owner sollte dabei sein, weitere Interessenvertreter als Zuhörer möglich 15.12.2009 Advanced Software Engineering 190
Daily Scrum Drei Fragen für jeden: Was getan seit letztem Daily Scrum? Was mache ich bis zum nächsten Daily Scrum? Was behindert meine Arbeit? Hindernisse mit Datum versehen notieren Vorbereitung für effizientes Daily Scrum: Sprint Backlog ist aktuell Sprint Burndown-Chart liegt vor 15.12.2009 Advanced Software Engineering 191
Daily Scrum Techniken für das Daily Scrum Stand-Up Meeting Speech Token Variation Metadiskussion 15.12.2009 Advanced Software Engineering 192
Sprint Burndown Chart Aufwände im Sprint Backlog 1 2 3 4 5 10 15 20 Tage 15.12.2009 Advanced Software Engineering 193
Sprint-Review Ziel: Begutachtung der Arbeitsergebnisse Product Owner prüft, ob alle akzeptierten Anforderungen vollständig und fehlerfrei umgesetzt wurden Dauer ca. 1 bis 2 Stunden Wer: Komplettes Team, Product Owner, Scrum Master, optional weitere Interessenvertreter (Kunde!, Endanwender!) 15.12.2009 Advanced Software Engineering 194
Sprint-Review Ablauf 1. Kurze Reflektion über das Sprint-Ziel 2. Team macht Live-Demo der Umsetzung der Anforderungen 3. Product Owner und Interessenvertreter stellen Fragen und geben Feedback 4. Product Owner entscheidet für die einzelnen Anforderungen ob akzeptiert oder nicht 15.12.2009 Advanced Software Engineering 195
Sprint-Review Techniken für die Sprint-Review Hart, aber herzlich Aktiver Product Owner Vertrauen ist gut, Transparenz ist besser Offenes Protokollieren 15.12.2009 Advanced Software Engineering 196
Sprint-Review Typische Fehler Passiver Product Owner Herausstellen Einzelner Falsches Schulterklopfen Hokuspokus Privater Build 15.12.2009 Advanced Software Engineering 197
Sprint-Retrospektive Ziel: Zusammenarbeit im Team und Anwendung des Prozesses verbessern Wann: Direkt nach dem Sprint-Review Dauer: 1,5 bis 2,5 Stunden Wer: Komplettes Team, Scrum Master, Product Owner. Nach Bedarf werden weitere Interessenvertreter (z.b. Führungskräfte) eingeladen Muss gut vorbereitet werden 15.12.2009 Advanced Software Engineering 198