Advanced Software Engineering WS0910 Kapitel1. Dr. Dominik Haneberg

Transkript

1 Advanced Software Engineering WS0910 Kapitel1 Dr. Dominik Haneberg

2 AGILE METHODEN Advanced Software Engineering 11

3 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 Advanced Software Engineering 12

4 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] Advanced Software Engineering 13

5 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 Advanced Software Engineering 14

6 Advanced Software Engineering 15

7 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 Advanced Software Engineering 16

8 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 Advanced Software Engineering 17

9 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 Advanced Software Engineering 18

10 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 Advanced Software Engineering 19

11 Werte, Prinzipien, Praktiken, Methodiken Advanced Software Engineering 20

12 Änderungskosten Kosten pro Änderung Prädiktive Vorgehensweise Adaptive Vorgehensweise Zeit Advanced Software Engineering 21

13 Die agilen Werte Advanced Software Engineering 22

14 Die agilen Werte Advanced Software Engineering 23

15 Die agilen Werte Advanced Software Engineering 24

16 Die agilen Werte Advanced Software Engineering 25

17 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 Advanced Software Engineering 26

18 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 Advanced Software Engineering 27

19 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 Advanced Software Engineering 28

20 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 Advanced Software Engineering 29

21 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 Advanced Software Engineering 30

22 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 Advanced Software Engineering 31

23 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 Advanced Software Engineering 32

24 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 Advanced Software Engineering 33

25 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 Advanced Software Engineering 34

26 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 Advanced Software Engineering 35

27 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 Advanced Software Engineering 36

28 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 Advanced Software Engineering 37

29 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 Advanced Software Engineering 38

30 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) Advanced Software Engineering 39

31 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 Advanced Software Engineering 40

32 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, Advanced Software Engineering 41

33 METHODIKDESIGN Advanced Software Engineering 42

34 Warum eine Methodik? Koordination der Projektbeteiligten Vermeidet es Fehler zu wiederholen (Eine Methodik sollte aus ausreichend Erfahrung abgeleitet sein) Vertrauensgewinn beim potentiellen Auftraggeber Advanced Software Engineering 43

35 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 Advanced Software Engineering 44

36 Methodikelemente A. Cockburn: Agile Software Development The Cooperative Game, Addison Wesley, Advanced Software Engineering 45

37 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 Advanced Software Engineering 46

38 Metriken Größe der Methodik Advanced Software Engineering 47

39 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 Advanced Software Engineering 48

40 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, Advanced Software Engineering 49

41 Metriken Sichtbarkeit: Wie transparent sind die Vorgänge in einem Projekt Stabilität: Wie hoch ist die Wahrscheinlichkeit einer Veränderung Advanced Software Engineering 50

42 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) Advanced Software Engineering 51

43 Häufige Fehler Eierlegende Wollmilchsau Bisher nicht in Erscheinung getreten Unnötiges Beiwerk mangels Vertrauen Viel hilft viel Advanced Software Engineering 52

44 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 Advanced Software Engineering 53

45 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 Advanced Software Engineering 54

46 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 Advanced Software Engineering 55

47 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, Advanced Software Engineering 56

48 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 Advanced Software Engineering 57

49 PRAKTIKEN Advanced Software Engineering 58

50 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 Advanced Software Engineering 59

51 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 Advanced Software Engineering 60

52 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 Advanced Software Engineering 61

53 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 * * radius; return perimeter; } public double getarea() { double area = * Math.pow(radius,2); return area; } Advanced Software Engineering 62

54 Beispiel zu Refactoring Version 1 Version 2 public class Circle { private double radius; public class Circle { public static final double PI = ; } public void setradius(double radius) { this.radius = radius; } public double getperimeter() { double perimeter = 2 * * radius; return perimeter; } public double getarea() { double area = * 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; } Advanced Software Engineering 63

55 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 Advanced Software Engineering 64

56 Product Backlog Es muß nicht immer alles elektronisch sein Advanced Software Engineering 65

57 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 Advanced Software Engineering 66

58 Praktikenbasar Machbarkeitsanalyse (Proof of concept) Anforderungspatterns Glossar Kunde vor Ort MoSCoW-Regel C. Dogs, T. Klimmer: Agile Software Entwicklung kompakt, mitp-verlag, Advanced Software Engineering 67

59 Praktikenbasar Planning Game Prototypen Requirements Management CRC-Karten Designmentor Advanced Software Engineering 68

60 Praktikenbasar Design Patterns Öffentliche Modellpräsentation (Wall of Wonders) Coding Standards Collective Ownership Individual Code Ownership Advanced Software Engineering 69

61 Praktikenbasar Kurze Releases Pair Programming Refactoring Monkey-Tests Regressionstests Advanced Software Engineering 70

62 Praktikenbasar 40-Stunden-Woche Weiterbildung Knowledge-Base/Wiki Selbstorganisierende Teams Tägliches Stand-Up-Meeting Advanced Software Engineering 71

63 Praktikenbasar Timeboxing Anti-Patterns Einfachheit Risikogetriebene Priorisierung Advanced Software Engineering 72

64 METHODIKEN Advanced Software Engineering 73

65 Methodiken gibt s viele XP Adaptive Software Development (ASD) Crystal dx Scrum PP Feature-Driven Development (FDD) Dynamic Systems Development Method (DSDM) Advanced Software Engineering 74

66 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) Advanced Software Engineering 75

67 EXTREME PROGRAMMING Advanced Software Engineering 76

68 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 Advanced Software Engineering 77

69 Aspekte Prozess Rollen Praktiken Werte XP Anwendung Advanced Software Engineering 78

70 Werte im XP Kommunikation Nicht mit den Werten des agilen Manifests verwechseln! XP war früher! Mut XP Einfachheit Feedback Advanced Software Engineering 79

71 Prinzipien im XP Unmittelbares Feedback Qualitätsarbeit Einfachheit anstreben Veränderung wollen Inkrementelle Veränderung Advanced Software Engineering 80

72 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 Advanced Software Engineering 81

73 Rollen Big Boss Kunde Management Geschäftsdomäne Coach Tracker Design/ Programmierung Programmierer Tester Consultant Projektunterstützung Sonstige Rollen Advanced Software Engineering 82

74 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 Advanced Software Engineering 83

75 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 Advanced Software Engineering 84

76 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 Advanced Software Engineering 85

77 Rollen Consultant Externer technischer Sachverstand Advanced Software Engineering 86

78 Ablauf der Entwicklung Der eigentliche Prozess Technische Experimente Einweisung des Kunden Exploration Planung Entwicklung Freigabe Wartung Ende Advanced Software Engineering 87

79 Ablauf der Entwicklung Der eigentliche Prozess Exploration Planning Game Planung der Iteration durch Kunde und Entwickler Planung Entwicklung Freigabe Wartung Ende Advanced Software Engineering 88

80 Ablauf der Entwicklung Der eigentliche Prozess Exploration Festlegung der Architektur Schreiben von Unit und Akzeptanztests Paarweises Programmieren der Software Planung Entwicklung Freigabe Wartung Ende Advanced Software Engineering 89

81 Ablauf der Entwicklung Der eigentliche Prozess Exploration Planung Entwicklung Freigabe Wartung Ende Letzte Tests Performanceoptimierungen Advanced Software Engineering 90

82 Ablauf der Entwicklung Der eigentliche Prozess Exploration Planung Entwicklung Freigabe Wartung Ende Überarbeitung der Software im Produktivbetrieb Advanced Software Engineering 91

83 Ablauf der Entwicklung Der eigentliche Prozess Exploration Planung Entwicklung Freigabe Wartung Schreiben der Abschlussdokumentation Projektabschluss Ende Advanced Software Engineering 92

84 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] Advanced Software Engineering 93

85 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 Advanced Software Engineering 94

86 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) Advanced Software Engineering 95

87 Story Card Advanced Software Engineering 96

88 Story Cards Advanced Software Engineering 97

89 Aufwandsschätzungen Gestern Heute Advanced Software Engineering 98

90 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, Advanced Software Engineering 99

91 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 Advanced Software Engineering 100

92 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 Advanced Software Engineering 101

93 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 Advanced Software Engineering 102

94 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 Advanced Software Engineering 103

95 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 Advanced Software Engineering 104

96 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) Advanced Software Engineering 105

97 TDD Ablauf Unit Test für neuen Code schreiben Refactoring erfolgreich Test ausführen Test nicht bestanden Code schreiben bzw. ändern Test bestanden Refactoring Advanced Software Engineering 106

98 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 Advanced Software Engineering 107

99 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 Advanced Software Engineering 108

100 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 Advanced Software Engineering 109

101 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 Advanced Software Engineering 110

102 Freigabephase Aktueller Stand (Release-Candidate) wird dem Echtbetrieb übergeben Kunde prüft nochmals genau auf Mängel Entwickler machen Performanceoptimierungen Übergabe an die Anwender Advanced Software Engineering 111

103 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 Advanced Software Engineering 112

104 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 Advanced Software Engineering 113

105 Detailansicht des Prozesses Advanced Software Engineering 114

106 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 Advanced Software Engineering 115

107 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 Advanced Software Engineering 116

108 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 Advanced Software Engineering 117

109 Weitere Praktiken/Empfehlungen Offene Arbeitsumgebung Advanced Software Engineering 118

110 Weitere Praktiken/Empfehlungen Informativer Arbeitsplatz Advanced Software Engineering 119

111 Weitere Praktiken/Empfehlungen CRC-Karten Advanced Software Engineering 120

112 Weitere Praktiken/Empfehlungen Just Rules Lokale Anpassungen Parties Advanced Software Engineering 121

113 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: Advanced Software Engineering 122

114 XP V2 Prinzipien Advanced Software Engineering 123

115 XP V2 Praktiken Advanced Software Engineering 124

116 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 Advanced Software Engineering 125

117 Neue und alte Praktiken Advanced Software Engineering 126

118 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 Advanced Software Engineering 127

119 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!) Advanced Software Engineering 128

120 XP Simulation Advanced Software Engineering 129

121 SCRUM Advanced Software Engineering 130

122 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, Advanced Software Engineering 131

123 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 Advanced Software Engineering 132

124 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 Advanced Software Engineering 133

125 Vergleich von Entwicklungszyklen Teufelskreislauf Ziele in Gefahr Mehr Kontrollen Mehr Mitarbeiter, längere Arbeitszeiten Schlechte Softwarequalität, schlechte Mitarbeitermoral Advanced Software Engineering 134

126 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 Advanced Software Engineering 135

127 Verbesserungen durch Scrum Mitarbeiterzufriedenheit Kundenzufriedenheit Time to market Qualität Produktivität Advanced Software Engineering 136

128 Scrum Alliance Scrum ist stärker institutionalisiert Es gibt Schulungen zum Certified Scrum Master und Certified Scrum Product Owner Advanced Software Engineering 137

129 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 Advanced Software Engineering 138

130 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 Advanced Software Engineering 139

131 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 Advanced Software Engineering 140

132 Rollen in Scrum Team Product Owner Scrum Master Scrum Advanced Software Engineering 141

133 Product Owner Anforderungsbeschreibung und management Releasemanagement und Return on Investment Enge Zusammenarbeit mit dem Team Stakeholder-Management Ist nicht der Kunde Advanced Software Engineering 142

134 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 Advanced Software Engineering 143

135 Scrum Master: Fähigkeiten Moderation Coaching Erfahrung in der (Software-)Entwicklung Advanced Software Engineering 144

136 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 Advanced Software Engineering 145

137 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) Advanced Software Engineering 146

138 Wie sollte das Team sein? Bevollmächtigt (empowered) Autonom Interdisziplinär besetzt Selbstorganisiert Klein Advanced Software Engineering 147

139 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 Advanced Software Engineering 148

140 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 Advanced Software Engineering 149

141 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, Advanced Software Engineering 150

142 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 Advanced Software Engineering 151

143 Anforderungsgewinnung Anforderungsbeschreibung Umsetzung Traditionelles Vorgehen Anforderungsbeschreibung Umsetzung Sprint 1 Vorgehen in Scrum Sprint n Advanced Software Engineering 152

144 Anforderungsgewinnung Kunde Endanwender Interessenvertreter Product Owner Product Backlog Team Advanced Software Engineering 153

145 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 Advanced Software Engineering 154

146 Das Product Backlog Advanced Software Engineering 155

147 Wie kommt man zum Product Backlog? Produktkonzept Produktidee Product Backlog Advanced Software Engineering 156

148 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 Advanced Software Engineering 157

149 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 Advanced Software Engineering 158

150 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 Advanced Software Engineering 159

151 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, Advanced Software Engineering 160

152 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 Advanced Software Engineering 161

153 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 Advanced Software Engineering 162

154 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 Advanced Software Engineering 163

155 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 Advanced Software Engineering 164

156 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) Advanced Software Engineering 165

157 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 Advanced Software Engineering 166

158 Wert-Risiko-Matrix Risiko Hoch Vermeiden Als erstes Niedrig Zuletzt Als zweites Niedrig Hoch Wert Advanced Software Engineering 167

159 MuSCoW Einteilung Must have Should have Could have Won t have Advanced Software Engineering 168

160 Mehr zu Anforderungen Eine Anforderung sollte die INVEST-Eigenschaften haben Independent Negotiable Valuable Estimable Small Testable Advanced Software Engineering 169

161 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 Advanced Software Engineering 170

162 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 Advanced Software Engineering 171

163 Releaseplanung Ziel: Vorausschauende Steuerung und Optimierung der Kundenzufriedenheit und Wertschöpfung über die Grenzen einzelner Sprints hinweg Aspekte der Releaseplanung: Schätzen Planen Berichten Advanced Software Engineering 172

164 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 Advanced Software Engineering 173

165 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 Advanced Software Engineering 174

166 Ebenen der Planung Product Backlog Aktueller Fortschritt und aktuelle Probleme Releaseplanung Sprintplanung Tagesplanung Releaseplan Sprint Backlog Advanced Software Engineering 175

167 Typen von Sprints Explorationssprints Standardsprints Releasesprints Advanced Software Engineering 176

168 Beispiel für Releaseplan Advanced Software Engineering 177

169 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 Advanced Software Engineering 178

170 Burndown-Chart Release-Burndown Aufwände im Product Backlog Sprints Advanced Software Engineering 179

171 Entwicklungsgeschwindigkeitsbericht Erledigte Aufwandspunkte Ø aller Sprints Ø der 3 schlechtesten Sprints Sprints Advanced Software Engineering 180

172 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 Advanced Software Engineering 181

173 Sprints Sprints im Überblick Verbesserungsmaßnahmen Product Backlog Sprintplanung Umsetzungsaktivitäten und Daily Scrum Sprint-Review und Sprint-Retrospektive Advanced Software Engineering 182

174 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% Advanced Software Engineering 183

175 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) Advanced Software Engineering 184

176 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! Advanced Software Engineering 185

177 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 Advanced Software Engineering 186

178 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 Advanced Software Engineering 187

179 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 Advanced Software Engineering 188

180 Sprint Backlog Advanced Software Engineering 189

181 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 Advanced Software Engineering 190

182 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 Advanced Software Engineering 191

183 Daily Scrum Techniken für das Daily Scrum Stand-Up Meeting Speech Token Variation Metadiskussion Advanced Software Engineering 192

184 Sprint Burndown Chart Aufwände im Sprint Backlog Tage Advanced Software Engineering 193

185 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!) Advanced Software Engineering 194

186 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 Advanced Software Engineering 195

187 Sprint-Review Techniken für die Sprint-Review Hart, aber herzlich Aktiver Product Owner Vertrauen ist gut, Transparenz ist besser Offenes Protokollieren Advanced Software Engineering 196

188 Sprint-Review Typische Fehler Passiver Product Owner Herausstellen Einzelner Falsches Schulterklopfen Hokuspokus Privater Build Advanced Software Engineering 197

189 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 Advanced Software Engineering 198