Informatik für Ingenieure (InfIng)

Transkript

1 Informatik für Ingenieure (InfIng) SW-Engineering 2 Doz. Dipl.-Ing. H. Hiller WS 2012/13

2 Entwicklung von Software Vorgehensweise Manche lieben es klassisch, machen lieben es agil Klassisches Vorgehen Agiles Vorgehen John Casey - Fotolia.com Alison Bowden - Fotolia.com FH D Seite 2 FB 5

3 Themen dieser Vorlesung Wir wollen folgenden Fragen nachgehen: 1. "Klassische Software-Entwicklung?" Wasserfall-Modell 2. "Agile Softwareentwicklung?" Scrum FH D Seite 3 FB 5

4 Ausgangslage Probleme bei Softwareprojekten Auftraggeber (Kunde)... formuliert Anforderungen oft vage oder unklar kennt nicht alle Anforderungen hat widersprüchliche Anforderungen Auftragnehmer (Firma) versteht nicht genau, was der Kunde will unterschätzt/überschätzt die Aufwände Änderungen in den Prioritäten in den Geschäftsprozessen Technische Risiken Antworten Infrastruktur hält nicht was sie verspricht Klassisches Modell Beispiel: Wasserfall-Modell Agiles Modell Beispiel: Scrum FH D Seite 4 FB 5

5 Übersicht Wasserfall-Modell Scrum FH D Seite 5 FB 5

6 Wasserfall-Modell Wasserfall-Modell In Phasen organisierter Software-Entwicklungsprozess Einfach, verständlich und benötigt nur wenig Managementaufwand Planung Analyse Am Ende jeder Phase wird durch ein Review entschieden, ob die Ziele der Phase erreicht wurden. Entwurf Jede Phase ist in sich abgeschlossen. Übergang zur nächsten Phase erst, wenn vorherige Phase beendet ist. Coding Test FH D Seite 6 FB 5

7 Wasserfall-Modell Vorgehensweise Sequenzielle Organisation in Projektphasen Vollständige Abstimmung der Anforderungen bei Projektbeginn Erstellung detaillierter Spezifikationen (Lastenheft/Pflichtenheft) Änderungen nur über ein definiertes Change Request Verfahren Phasen Start- und Endpunkte mit eindeutig definierten Ergebnissen Jede Aktivität muss beendet sein, bevor die nächste anfängt Meilensteine Dokumente Wichtigste Dokumente sind Lastenheft bzw. Pflichtenheft Ende jeder Aktivität verbunden mit einem fertig gestellten Dokument Durchführung Aktivitäten entsprechend der richtigen Reihenfolge und in vollem Umfang Iterationen nur zwischen zwei aufeinanderfolgenden Stufen erlaubt FH D Seite 7 FB 5

8 Wasserfall-Modell Ziele Genaues Verständnis der Anforderungen, Verfolgbarkeit Priorisierung Höchste Priorität: Termintreue und Einhaltung des Budgets Untergeordnete Prio: Qualität und vollständige Funktionalität Fokus auf Meilensteine Kunde Integration am Anfang und am Ende des Projekts, kaum während des Projekts Einbeziehung über Anforderungsdefinition, Dokumenten-Reviews und Tests Kommunikation zum Teil reglementiert (nur über Projektleiter oder Dokumente) Projekte nach dem Wasserfall-Modell sind immer noch die am häufigsten anzutreffende Projektform! FH D Seite 8 FB 5

9 Wasserfallmodell Vorteile Aufgaben aller Phasen klar umrissen Geringer Prozess-Overhead bzw. Management-Aufwand Nachteile Zurückkehren in frühere Phasen ist aufwendig Modell "scheitert" bei verspäteten Änderungsanforderungen Später Beginn der Implementierung Verzögertes Erkennen von technischen Problemen Benutzerbeteiligung nur bei Anforderungen und Abnahme Verzögerter Abgleich von Anforderung/Realisierung Software-Bürokratie Umfangreiches Berichtswesen, zu viele Dokumente Zu teuer, zu schwergewichtig, zu träge FH D Seite 9 FB 5

10 Übersicht Wasserfall-Modell Scrum FH D Seite 10 FB 5

11 SCRUM Begriffsbestimmung Rugby Begriff aus dem Rugby Deutsch: "Gedränge", hier: angeordnetes Gedränge Warum? Ahndung kleinerer Regelverstöße Beispielsweise bei unerlaubtem Vorwärtsspielen des Balles, aber auch bei Ball-Aus Was? Neustart des Spiels Ball liegt in der Mitte des Gedränges Ball muss in die Hälfte des eigenen Gedränges Ohne Einsatz der Hände! "A scrum is a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field" Software-Entwicklung Begriff für eine moderne Form der agilen Software-Entwicklung Steve Cukrov - Fotolia.com Flexibel und schlank, ganz im Gegensatz zu klassischen Modellen Wesen von Scrum ist die starke Fokussierung auf das Entwicklungsteam FH D Seite 11 FB 5

12 SCRUM Entstehungsgeschichte : Jeff Sutherland definiert die Rolle des Projektmanagers neu Stärkerer Fokus auf das Team sowie Moderierung der Teamarbeit 1995: Zusammenarbeit von Jeff Sutherland und Kent Beck Erfahrungen fließen in die extreme Programmierung ein (XP) 1996: Kent Schwaber veröffentlicht ersten Konferenzbeitrag zur OOPSLA'96 über Scrum Gundthese: "Scrum akzeptiert, dass der Entwicklungsprozess unvorhersehbar ist." 2001: Sutherland, Schwaber und Beedle u.a. schreiben am Agile Manifesto Veröffentlichung des Buchs "Agile Software Development mit Scrum" 2003: Ken Schwaber beginnt mir dem Training zum Scrum Master. Veröffentlichung des Buchs "Agile Project Management with Scrum" 2007: Ken Schwaber veröffentlicht sein 3. Buch: "The Enterprise and Scrum" FH D Seite 12 FB 5

13 SCRUM Agile Software-Entwicklung Manifest Festgeschrieben im Jahr 2001 im Agilen Manifest von Sutherland und anderen Manifest stellt Menschen und deren Interaktionen vor Prozesse und Werkzeug. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Funktionierende Software ist wichtiger als Umfassende Dokumentation Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen Reagieren auf Veränderungen ist wichtiger als Befolgen eines Plans Quelle: FH D Seite 13 FB 5

14 SCRUM Überblick Scrum-Flow Scrum ist ein iterativer Prozess Sprint-Planning Meeting Teil 1 Teil 2 Scrum Meeting 24h Sprint 1-4 Wochen Scrum Master Scrum Team Sprint-Review Meeting Sprint Backlog Backlog Tasken Product Backlog Product Owner Potenziell auslieferbares Produkt-Increment FH D Seite 14 FB 5

15 SCRUM Sprint Sprint Softwareentwicklung verläuft iterativ in Zyklen ("Sprint" genannt) Sprints sind überschaubare Entwicklungseinheiten mit fester Länge Anzahl und Dauer abhängig von Größe und Komplexität des Projekts Timeboxed Zeitlich klar abgegrenzte Dauer eines Sprints, zwischen 1 und 4 Wochen Konstante Dauer führt zu besserem Rhythmus Inhalt Produkt wird während des Sprints entworfen, kodiert und getestet Änderungen Keine Änderungen während des Sprints von außen erlaubt Ergebnis Jede Iteration endet mit einem potenziell auslieferbarem Produkt-Inkrement FH D Seite 15 FB 5

16 SCRUM Rollen, Meetings und Artefakte Rollen Scrum kennt nicht die übliche Rollenverteilung (Projektmanager, Projektleiter) Stattdessen gibt es die Rollen Product Owner, Scrum Master und Team Meetings Prozess u. Arbeitsweise werden in Reviews und Retrospektiven stetig begutachtet Ergebnis ist eine andauernde Verbesserungen der Prozesse und Arbeitsweisen Artefakte Artefakte sind die Ergebnisse von Aktivitäten im Softwareentwicklungsprozess Zentrales Artefakt bei einem Softwareprodukt ist der auslieferbare Code Weitere begleitende Artefakte: Product Backlog, Sprint Backlog, Burndown Chart FH D Seite 16 FB 5

17 Übersicht Rollen Product Owner Scrum Master Team Meetings Sprint Planning Daily Scrum Sprint Review Sprint Retrospektive Artefakte Product Backlog Sprint Backlog Burndown Chart FH D Seite 17 FB 5

18 Product Owner Auftraggeber, Visionär Vorgabe der Richtung, WAS im Projekt umgesetzt werden soll Verantwortlich für den wirtschaftlichen Erfolg des Projekts Inhaltliche Steuerung Aufnahme der fachlichen Anforderungen vom Kunden Erstellung von User Stories aus den Anforderungen Priorisierung der einzelnen Anforderungen nach Geschäftswert Akzeptanz oder Ablehnung der Arbeitsergebnisse Budgetverantwortlicher Bestreben, das Budget bestmöglich auszuschöpfen Bestimmung der Kundenverfügbarkeit FH D Seite 18 FB 5

19 Scrum Master Prozess-Verantwortlicher Verantwortung für den Scrum-Prozess und dessen korrekte Implementation "Dem Team über die Schulter schauen" Team bei Bedarf an seine Commitments erinnern Kümmerer Bereitstellung der bestmöglichen Arbeitsbedingungen Hindernisse aus dem Weg räumen Pizza holen, wenn es spät wird ;-) Team von äußeren Störungen fernhalten Produktivität und Zufriedenheit sicherstellen FH D Seite 19 FB 5

20 Scrum Team Organisation Scrum Teams organisieren sich selbst! Schätzung des Aufwands für die Arbeitsschritte Verpflichtung zu den geplanten Aufgaben Implementierung der machbaren Elemente Verantwortlichkeiten Planung des Sprints sowie dessen Umsetzung Fertigstellung der selbst gewählten Aufgabenpakete Verantwortlich für die Arbeitsergebnisse Team-Member Typischerweise fünf bis neun Leute Mitgliedschaft kann sich nur zwischen Sprints verändern FH D Seite 20 FB 5

21 Pigs and Chickens Pigs (Schweine) Bezeichnung der direkt am Prozess beteiligten Personen Chickens (Hühner) Bezeichnung für "Außenstehende" Quelle: FH D Seite 21 FB 5

22 Pigs and Chickens Pigs Am Projekt beteiligte Personen, die die Last und das Risiko des Projekts tragen Product Owner Scrum Master Team Arbeiten entsprechend den für Scrum definierten Regeln zusammen. Treffen sich regelmäßig zu kurzen, aber effizienten Meetings. Halten ihre jeweiligen Scrum-Artefakte (Dokumente) auf dem neuesten Stand, damit alle - auch die Chickens - sich selbständig über den Fortschritt des Projekts informieren können. Chickens Am Projekt interessierte Personen ohne Projektrisiko (Stakeholder) User Manager Interesse, weil das Projekt ihre Arbeit beeinflussen kann/wird. Overhead im Prozess, was deutlich erkennbar ist in Meetings. Haben einmal pro Sprint Gelegenheit sich über das Projekt zu informieren und Feedback zu geben, werden ansonsten gleich zu Beginn aus dem Prozess eliminiert. FH D Seite 22 FB 5

24 Sprint Planning Teil 1 Auswahl der zu bearbeitenden Items aus dem Product Backlog Scrum Master Scrum Team Product Owner Team Kapazität Product Backlog Aktuelles Produkt Technologie Sprint Planning Teil 1 Product Backlog analysieren Für jedes Backlog Item gilt Anforderung verstehen Ergebnis festlegen User acceptance tests finden Acceptance criteria definieren Grobe Schätzung Backlog Items realsierbar? Sprintziel Sprint Backlog FH D Seite 24 FB 5

25 Sprint Planning Teil 1 Vorstellung der Backlog Items Product Owner erläutert die Items des Product Backlogs Items des Product Backlogs sind priorisiert Team und Product Owner diskutieren den nächsten Sprints Welche Items können im nächsten Sprint realisiert werden? Auswahl der Items nach Prioritätenliste ( "n" Items + "x") Möglicher Sprint Backlog wird abgestimmt und erstellt Definition des Sprint-Ziels (Fokus der Arbeiten während des Sprints) Auswahl der Items für den nächsten Sprint Team entscheidet wie viele Backlog Items tatsächlich entwickelt werden Diskussion ohne den Produkt Owner; Product Owner wird nur informiert Vermeidung, Team über seine Kapazität hinaus zu belasten Tatsächlicher Sprint Backlog mit den zu realisierenden Items wird erstellt Commitment Team-Verpflichtung, festgelegten Sprint Backlog zu realisieren FH D Seite 25 FB 5

26 Sprint Planning Teil 2 Auswahl der zu bearbeitenden Items aus dem Sprint Backlog Scrum Master Scrum Team Product Owner Team Kapazität Sprint Backlog Aktuelles Produkt Technologie Sprint Planning Teil 2 Sprint Backlog analysieren Für jedes Backlog Item gilt Aufteilung in Tasken Zeitaufwand schätzen Grobe Schätzung Backlog Items realisierbar? Sprint-Ziel Tasken FH D Seite 26 FB 5

27 Sprint Planning Teil 2 Wie sollen die Backlog Items umgesetzt werden Diskussion über Umsetzung des Selected Product Backlogs Entwurf von Design und Architektur Aufteilung der Backlog Items (Stories) in einzelne Tasken Zeitaufwand Abschätzung des Zeitaufwands (1-16 Stunden, Poker) Gemeinschaftliche Entscheidung, nicht nur Scrum Master Ergebnis Taskboard mit den zu bearbeitenden Aufgaben (Tasken) Aufgabenverteilung Team kann jederzeit neue Tasken hinzufügen überflüssige Tasken löschen Mitglieder wählen Tasken aus Arbeit wird nie zugewiesen Alison Bowden - Fotolia.com FH D Seite 27 FB 5

28 Daily Scrum Teilnehmer Pigs and Chickens, aber nur Pigs dürfen reden Parameter Täglich zur gleichen Zeit am gleichen Ort Timeboxed - 15 Minuten Stand-up (!) - Zwang, um Dauer zu begrenzen Nicht zur Problemlösung Problemdiskussion anschließend in kleiner Gruppe Fehlen ist nicht erlaubt Inhalt Jeder Mitarbeiter berichtet über den aktuellen Fortschritt Was ist geschafft? - Was ist zu tun? - Probleme? Team erhält täglich einen globalen Projekt-Überblick Druck von Peers/Kollegen das zu tun, was man sagt Kein Statusbericht für den Scrum Master! Daily Scrum bis picturia - Fotolia.com FH D Seite 28 FB 5

29 Daily Scrum 3 Fragen! Im Daily Scrum beantwortet jedes Teammitglied folgende 3 Fragen: 1. Was hast Du gestern getan? 2. Was wirst Du heute tun? 3. Welche Hindernisse sind in Deinem Weg? FH D Seite 29 FB 5

30 Sprint Review Teilnehmer Team, Scrum Master, Product Owner und allen interessierten Stakeholder Zeitpunkt: Form Inhalt Nach Ende des Sprints Informell (Keine Folien) "Zwei-Stunden-Vorbereitungs"-Regel Team präsentiert, was es während eines Sprints erreicht hat Typischerweise in Form einer Demo (live am System) Potenziell auslieferbares Produkt (Increment of Potentially Shippable Functionality) Feedback seitens Product Owner, Stakeholders u.a. Anwesenden erwünscht Abgleich mit dem Product Backlog, ggf. Änderungen (Inhalt, Prioritäten) FH D Seite 30 FB 5

31 Sprint Retrospective Teilnehmer Team, Scrum Master und Product Owner Zeitpunkt Inhalt Im Anschluss an das Sprint Review Wertefreier Rückblick auf die Ereignisse des Sprints Wurde geliefert, was geplant und angenommen wurde? Reflektion über die Durchführung des Sprints Was war gut, was war nicht so gut? Jedes Teammitglied ist zur Diskussion aufgefordert Entscheiden, was im nächsten Sprint verändert wird Unterstützung des kontinuierlichen Lernprozesses FH D Seite 31 FB 5

33 Product-Backlog Liste aller erforderlichen/gewünschten Projektarbeiten Erstellt und priorisiert vom Product Owner Re-priorisiert zu Beginn eines jeden Sprints Organisation des Product Backlogs Losgelöst vom Sprint Änderungen durch Product Owner jederzeit möglich FH D Seite 33 FB 5

34 Remaining Effort Estimation Burndown Chart Werkzeug zur Messung des Fortschrittes, täglicher Abgleich (Minimum) Chart gibt Auskunft über die noch zu leistende Arbeit ab dem aktuellen Tag Noch zu leistender Aufwand in h Task Task 1 Member Anke Remaining Effort (h) Task 2 Task 3 Task 6 Frank Sven Jens Datum FH D Seite 34 FB 5

35 SCRUM Abschlussbetrachtung Unterschied zu klassischen Modellen Gesamtsystem "lebt" und ist ständigen Änderungen unterworfen Keine auf Jahre hinaus festgelegte Projektplanung Eigenverantwortung des Teams ist zentral Keine "Weisungsbefugnis" im klassischen Sinn Komplexität wird auf "handliche" Objekte heruntergebrochen Neue Erkenntnisse werden umgehend in den Product Backlog aufgenommen Flexibilität Sofortige Reaktion auf Veränderungen (z.b. in der Produktanforderung) Erfolgsfaktoren Voraussetzung ist eine entsprechend "reife" Unternehmenskultur Zur Vorgehensweise passende Entwicklungsumgebung Geeignete Teamplayer, fähige Scrum Master, kooperative Product Owner Gelebte Praxis Kombination aus klassischen Methoden und Scrum FH D Seite 35 FB 5

36 Cost of Change Flexibilität reduziert die Kosten von Änderungen Cost-of-Change Kurve wird durch Scrum abgeflacht Änderungskosten klassisches Vorgehen Änderungskosten agiles Vorgehen Änderungskosten klassisches Vorgehen (Quelle: Änderungskosten agiles Vorgehen (Quelle: FH D Seite 36 FB 5

37 It's Scrum-Time Daily Scrum, please! FH D Seite 37 FB 5