Agile Softwareentwicklung
in der Praxis
DI Dr. Andreas Wintersteiger
Objectbay Software & Consulting GmbH
andreas.wintersteiger@objectbay.com
1
V5.306/2008
© 2007 Objectbay Software & Consulting GmbH. www.objectbay.com
Wurzeln – Verschwendung (Lean)
 Frage nach dem Beitrag zur Wertschöpfung
 The Poppendieck Seven Wastes
 Unfertige Arbeit
 Zusätzliche Prozesse
 Extra Features
 Task Switching
 Waiting
 Motion
 Defects
4
Quelle: Poppendieck, 2007
© 2007 Objectbay Software & Consulting GmbH. www.objectbay.com
Wurzeln: Werte in XP (Kent Beck, 1999)
 Kommunikation („Communication“)
 Problems with projects are [...] somebody not talking to
somebody else about something important.
 Einfachheit („Simplicity“)
 The simplest thing that could possibly work
 Feedback
 Auf mehreren Ebenen
 Mut („Courage“)
 Mut zu Feedback
 Mut zur Lücke
 Mut zur Richtigstellung
5
 Amazon.de
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Agile Werte
 Kleine Releases
 kleine Stücke
 Kurze Zeiträume
 Iterativ-inkrementelle Entwicklung
 Gesamter Entwicklungszyklus
 Iterationen fixer Länger mit fixiertem Umfang
 „Time-Boxes“
 Collocation
 Face-to-Face Communication
 Team-Raum
 Visualisierung
 Feature Backlog
 Benutzer-/Wert-Orientiert
 Priorisiert
 Laufende, adaptive Planung
 Unterscheide Grob- und Feinplan
 „Planning Game“
 Komplexität
 Verantwortung
 Feedback
 Maximierung Feedback
 Kontinuierliches Lernen und Verbessern
 Qualität/Stabilität
 Effiziente Interaktion
 Effiziente Teamaktivitäten
 Gleicher Status (Synchronisation)
 Reflektiert Kundenwert
 Explorative Annäherung an bewegliche Ziele
 Balance Verantwortung und Mitsprache
 Erwartungen über Ziele abschätzbar
 Abschätzung durch Beteiligte
6
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Agile Werte (2)
7
 Selbst organisierende Teams
 Autonomes Handeln
 Prozess-Intelligenz
 Qualitätsgetriebene Prozesse
 „Jidoka“ (aus Lean Production)
 Testgetriebene Entwicklung
 Feedback
 Definition von „Fertig“
 Inspektion und Adaption
 Retrospektiven
 Einfachheit, Adaptierbarkeit
 Inhaltlich und prozessual einfach halten
 Lean (wenig Verschwendung)
 Adaptierbar
 Kein Mikro-Management
 Lösungskompetenz
 Produktivität
 Solides Fundament (Früherkennung)
 Kein „technical debt“
 Hohe Änderbarkeit
 Vermeidung von „Halbfabrikaten“
 Lernen und Verbessern
 Reflexion
 Maximierung des Business-Value
 Maximierung des Kundenwerts
 Veränderungen „entgegenkommen“
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Das agile Manifest
8
 Individuals and interactions
 over processes and tools
 Working results
 over comprehensive documentation
 Customer collaboration
 over contract negotiation
 Responding to change
 over execution of a plan
Original Signees:
Kent Beck
Mike Beedle
Arie v. Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Feb. 11-13, 2001,
Snowbird ski resort
Wasatch mountains,
Utah, USA
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Prozessmodelle der Software-Entwicklung
9
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Scrum!
10
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Charakteristika
11
 “Agiler Prozess” mit Fokus auf „Projektmanagement“
 Selbstorganisierende, funktionsübergreifende Teams
 Entwicklungsfortschritt in einmonatigen „Sprints“
 Anforderungen in einer Liste (“Product Backlog”)
 Keine spezifischen Engineering Practices
 Kombination mit XP (xp@scrum)
 Generative Regeln
 Schaffen „Agile Umgebung“ um Entwicklungsprojekte
abzuwickeln
 ISO und CMMI „Kompatibilität“
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Scrum - Wurzeln
 Produktivität
 Borland QuattroPro Team
 8 Developer, 31 Monate, 1 MLOC
 1 KLOC / Developer / Week (37x Industry Standard) [Coplien, 94]
 PatientKeeper
 45 production releases per Year
 860 hospitals, bi-weekly [Sutherland, 2007]
 Selbstorganisation
 Pull-Prinzip
 Iterativ-Inkrementell
12
Quelle: Jeff Sutherland
© 2007 Objectbay Software & Consulting GmbH. www.objectbay.com
Iterativ-inkrementelle Entwicklung
Start
Ziel
(aus heutiger Sicht)
13
© 2007 Objectbay Software & Consulting GmbH. www.objectbay.com
Entwicklungszyklus
1 2 3 4 5 6 7 8 9 10 11 12
Fehlerrate
Stress
14
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Sequentielle vs. überlappende Entwicklung
15
 Anstatt pro Phase alle Aufgaben zu erledigen
 machen agile Teams ständig einen Teil aller Aufgaben
Analysis
Design
Develop
Test
Integrate
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Sprints
16
 Scrum Projekte schreiten in einer Serie von “Sprints” fort
 Vgl. Iterationen in XP
 Fixe Dauer von einem Monat
 Abweichend auch 1 bis 4 Wochen
 Wichtig ist die Entstehung eines Rhythmus
 Während des Sprints
 Alle Aktivitäten aus den klassischen Phasen
 Produktdesign, Code, Test, Dokumentation …
 Ergebnis – „Done“
 „Potenziell auslieferbares
Produktinkrement“
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Sprints liefern ein „Produktinkrement“ ab
17
Produkt-Release
User Interface Layer
Business Layer
Database Layer
Infrastructure Layer
Inkrement1
Inkrement2
Inkrement3
Quelle: R. Pichler
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Der Scrum Prozess
18
2 – 4
Wochen
24
Std.
Sprint Backlog
Produkt Backlog
Daily Scrum
Sprint
Produkt
Inkrement

UP
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Keine Änderungen während des Sprints
19
 Das Team erklärt verbindlich, eine bestimmte Menge an
Features/Anforderungen in einem Sprint abzuliefern
 Änderungen dieser Anforderungen sind nicht erlaubt
 Keine Störung oder Unterbrechungen von außen
 Sprintdauer sollte so gewählt werden, wie lange es
möglich ist, Veränderung außen vor zu halten.
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Rollen in Scrum
20
Product Owner
Scrum Master
Team
Bildquellen: Apple, Inc., Scrum Alliance Inc., EuropuppyUSA.com
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Scrum in Action
21
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Another Silver Bullet?
 Prozess-Schwächen werden sichtbar
 Verschwendung: Nicht-wertschöpfende Aktivitäten
(Wert aus der Sicht des Kunden)
 Engpässe und Blockaden
 Überlastung
22
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Scrum – Nachweisliche Ergebnisse
 Funktionsfähige Software am Ende eines jeden Sprints
 „Fertig“
 Qualität
 Kontinuierliche Steigerung der Produktivität
 Reduktion des Stress-Niveaus
 Steigerung der Zufriedenheit von Kunden und Mitarbeitern
 Fokus auf die richtigen Features
 Transparenz auf den Projektfortschritt
 Einfachere und realistischere Möglichkeit zur Planung
 Nachhaltige Steigerung der Softwarequalität
23
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Product Backlog
 Liste
 Anforderungen
 Arbeitspakete
 Was ist zu tun
 Einträge: User Stories -
„Wert“ für Kunde/Benutzer
 Priorisiert
 Geschätzt
 „Sizing“
24
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
User Stories: User + Story
25
 Anforderungen/Features aus Benutzersicht
 Jede Story muss einen Wert für den Benutzer darstellen
 Ist einfach zu verstehen
 Kurzer Beschreibungstext
 Klarheit darüber, was der User damit
an Funktionalität bekommt
Quelle: Mike Cohn, Mountain Goat Software
As a vacation planner, I
want to see photos of
the hotels.
As a user, I want to
cancel a reservation.
As a frequent flyer, I
want to rebook a past
trip, so that I can save
time booking trips I
take.
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Der Product Backlog Eisberg
26
Priorität
Sprint
Release
Nächstes Release
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Wo halten wir den Backlog?
27
Bildquellen: Scrumworks, VersionOne, T-Online, Mountain Goat Software
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Tools (2)
28
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Sizing – Planungspoker
29
 In vielen Fällen konvergiert das Ergebnis bereits nach der
zweiten Runde.
 Der Moderator sollte versuchen, Konvergenz in der Diskussion
herbeizuführen.
 Es geht dabei nicht um Genauigkeit, sondern Angemessenheit.
Schätzer 1. Runde 2. Runde
Fred 3 5
Wilma 8 5
Barny 2 5
Betty 5 8
Quelle: Mike Cohn
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Vor dem Sprint / Planning - Themen
 Vorbereitung
 Backlog
 Team
 Bugs
 Tasks
 Granularität, „Herunterbrechen“
 Diskussion, Schätzen
 Das gesamte Team (Qualität des Plans)
 Was kommt in den Sprint?
 „Neben-Aufgaben“, Infrastruktur, „Administrative Aufgaben“…?
30
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Das „Task Board“ ist ein Sprint-Monitor
31
Story Tasks to do
Design and Code the
User Interface
8
Code the Middle tier
interfaces
8
Code the business
logic
12
Design the
Integration rules
4
Design and Code the
User Interface
4
Code the Middle tier
interfaces
8
Code the business
logic
2
Design the
Integration rules
2
In progress To be verified Done
Design and Code the
User Interface
4
Code the Middle tier
interfaces
8
Code the business
logic
6
Design the
Integration rules
4
Hours
18
10
14
Summe der
verbleibenden
Stunden am
Ende des Tages
/ 6
/ 2
/ 2
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Definition von „DONE“
 Teams zu 3 - max. 6 Personen
 Ein aktuelles (oder fiktives) Produkt/Projekt
 Was bedeutet „Done“ („Fertig“) …?
 für mich persönlich
 für mein Team
 für meinen Vorgesetzten
 für meinen Kunden
 …
32
© 2007 Objectbay Software & Consulting GmbH. www.objectbay.com
Continuous Integration
 Build Automatisierung
 Automatisierte Tests
 Unit-Tests
 Integrationstests
 UAT
 Last- u. Performance-Tests
 Coverage
 Deployment
 Code-Analyse
 Metriken
 Report
33
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
FAQ: Architektur
 Evolving Architecture
 Architektur entwickelt sich über die Zeit
 Wieviel Architektur ist notwendig? Wie wenig möglich?
 Architektur-Sprints
 Zumindest ein Stück Funktionalität im Sprint
 Spikes, Prototypen
 Joint Application Design Sessions
 Das gesamte Team arbeitet an der Architektur
 Entweder unmittelbar vor oder nach dem Sprint Planning
34
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Beispiel Sprint-Board
35
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Beispiele: Sprint Burndowns
36
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Non-Excel Burndown Reports
37
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Der Visuelle Arbeitsplatz
38
 Agile Methoden bevorzugen einfache Visualisierung und
offene Kommunikation
 Arbeitsplatz mit allen wichtigen Informationen verfügbar
 Release Plan
 Sprintziel
 Sprint Backlog
 Hindernisse, …
 Build-Ergebnisse, Metriken,
 Erlaubt Selbstorganisation und Inspect & Adapt
 Erlaubt dem P.O. den Fortschritt des Teams zu erkennen
und ob das Ziel erreicht werden kann
Quelle: Ken Schwaber
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Sprint Review
 Demo funktionsfähiger Software
 Qualitätsgesichert
 Ziel: Präsentation von Software
als Life-Demo
 Vorbereitung
 Tests
 Kurzer Intro (Sprint-Ziel, Context,…)
 Hoch-Produktive Teams zeigen nur Life-Demos
 Keine Dokumente, Diagramme, Folien etc.
 Einzige Ausnahme für „technische Stories“ zB. Testergebnisse,
Reports
39
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Retrospektiven
 Wichtig für alle Teams, um stetig produktiver zu werden
 Team (typischerweise ohne P.O.)
 Praktiken aus der Moderationstechnik
 Good/Bad
 Timeline
 5 Whys
 …
 „Lessions learned“ verteilen
 „Knowledge Bridge“
 Skalierte Retrospektive
 SM weekly, SOS
40
© 2008 Objectbay Software & Consulting GmbH. www.objectbay.com
Literaturempfehlungen
41
Ken Schwaber:
Agile Project Management
with Scrum
Microsoft Press, 2004
ISBN 0-7356-1993-X
 Amazon.de
Mike Cohn:
User Stories Applied
Addison Wesley, 2004
ISBN 0-321-20568-5
 Amazon.de
Boris Gloger:
Scrum
Carl Hanser Verlag Wien München,
2008
ISBN 978-3-446-41495-2
 Amazon.de
Mike Cohn:
Agile Estimating and Planning
Prentice Hall Intl., 2005
ISBN 0-13-147941-5
 Amazon.de
Vielen Dank
www.objectbay.com
42

Agile intro-90min (2007)

  • 1.
    Agile Softwareentwicklung in derPraxis DI Dr. Andreas Wintersteiger Objectbay Software & Consulting GmbH andreas.wintersteiger@objectbay.com 1 V5.306/2008
  • 2.
    © 2007 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Wurzeln – Verschwendung (Lean)  Frage nach dem Beitrag zur Wertschöpfung  The Poppendieck Seven Wastes  Unfertige Arbeit  Zusätzliche Prozesse  Extra Features  Task Switching  Waiting  Motion  Defects 4 Quelle: Poppendieck, 2007
  • 3.
    © 2007 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Wurzeln: Werte in XP (Kent Beck, 1999)  Kommunikation („Communication“)  Problems with projects are [...] somebody not talking to somebody else about something important.  Einfachheit („Simplicity“)  The simplest thing that could possibly work  Feedback  Auf mehreren Ebenen  Mut („Courage“)  Mut zu Feedback  Mut zur Lücke  Mut zur Richtigstellung 5  Amazon.de
  • 4.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Agile Werte  Kleine Releases  kleine Stücke  Kurze Zeiträume  Iterativ-inkrementelle Entwicklung  Gesamter Entwicklungszyklus  Iterationen fixer Länger mit fixiertem Umfang  „Time-Boxes“  Collocation  Face-to-Face Communication  Team-Raum  Visualisierung  Feature Backlog  Benutzer-/Wert-Orientiert  Priorisiert  Laufende, adaptive Planung  Unterscheide Grob- und Feinplan  „Planning Game“  Komplexität  Verantwortung  Feedback  Maximierung Feedback  Kontinuierliches Lernen und Verbessern  Qualität/Stabilität  Effiziente Interaktion  Effiziente Teamaktivitäten  Gleicher Status (Synchronisation)  Reflektiert Kundenwert  Explorative Annäherung an bewegliche Ziele  Balance Verantwortung und Mitsprache  Erwartungen über Ziele abschätzbar  Abschätzung durch Beteiligte 6
  • 5.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Agile Werte (2) 7  Selbst organisierende Teams  Autonomes Handeln  Prozess-Intelligenz  Qualitätsgetriebene Prozesse  „Jidoka“ (aus Lean Production)  Testgetriebene Entwicklung  Feedback  Definition von „Fertig“  Inspektion und Adaption  Retrospektiven  Einfachheit, Adaptierbarkeit  Inhaltlich und prozessual einfach halten  Lean (wenig Verschwendung)  Adaptierbar  Kein Mikro-Management  Lösungskompetenz  Produktivität  Solides Fundament (Früherkennung)  Kein „technical debt“  Hohe Änderbarkeit  Vermeidung von „Halbfabrikaten“  Lernen und Verbessern  Reflexion  Maximierung des Business-Value  Maximierung des Kundenwerts  Veränderungen „entgegenkommen“
  • 6.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Das agile Manifest 8  Individuals and interactions  over processes and tools  Working results  over comprehensive documentation  Customer collaboration  over contract negotiation  Responding to change  over execution of a plan Original Signees: Kent Beck Mike Beedle Arie v. Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Feb. 11-13, 2001, Snowbird ski resort Wasatch mountains, Utah, USA
  • 7.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Prozessmodelle der Software-Entwicklung 9
  • 8.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Scrum! 10
  • 9.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Charakteristika 11  “Agiler Prozess” mit Fokus auf „Projektmanagement“  Selbstorganisierende, funktionsübergreifende Teams  Entwicklungsfortschritt in einmonatigen „Sprints“  Anforderungen in einer Liste (“Product Backlog”)  Keine spezifischen Engineering Practices  Kombination mit XP (xp@scrum)  Generative Regeln  Schaffen „Agile Umgebung“ um Entwicklungsprojekte abzuwickeln  ISO und CMMI „Kompatibilität“
  • 10.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Scrum - Wurzeln  Produktivität  Borland QuattroPro Team  8 Developer, 31 Monate, 1 MLOC  1 KLOC / Developer / Week (37x Industry Standard) [Coplien, 94]  PatientKeeper  45 production releases per Year  860 hospitals, bi-weekly [Sutherland, 2007]  Selbstorganisation  Pull-Prinzip  Iterativ-Inkrementell 12 Quelle: Jeff Sutherland
  • 11.
    © 2007 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Iterativ-inkrementelle Entwicklung Start Ziel (aus heutiger Sicht) 13
  • 12.
    © 2007 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Entwicklungszyklus 1 2 3 4 5 6 7 8 9 10 11 12 Fehlerrate Stress 14
  • 13.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Sequentielle vs. überlappende Entwicklung 15  Anstatt pro Phase alle Aufgaben zu erledigen  machen agile Teams ständig einen Teil aller Aufgaben Analysis Design Develop Test Integrate
  • 14.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Sprints 16  Scrum Projekte schreiten in einer Serie von “Sprints” fort  Vgl. Iterationen in XP  Fixe Dauer von einem Monat  Abweichend auch 1 bis 4 Wochen  Wichtig ist die Entstehung eines Rhythmus  Während des Sprints  Alle Aktivitäten aus den klassischen Phasen  Produktdesign, Code, Test, Dokumentation …  Ergebnis – „Done“  „Potenziell auslieferbares Produktinkrement“
  • 15.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Sprints liefern ein „Produktinkrement“ ab 17 Produkt-Release User Interface Layer Business Layer Database Layer Infrastructure Layer Inkrement1 Inkrement2 Inkrement3 Quelle: R. Pichler
  • 16.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Der Scrum Prozess 18 2 – 4 Wochen 24 Std. Sprint Backlog Produkt Backlog Daily Scrum Sprint Produkt Inkrement  UP
  • 17.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Keine Änderungen während des Sprints 19  Das Team erklärt verbindlich, eine bestimmte Menge an Features/Anforderungen in einem Sprint abzuliefern  Änderungen dieser Anforderungen sind nicht erlaubt  Keine Störung oder Unterbrechungen von außen  Sprintdauer sollte so gewählt werden, wie lange es möglich ist, Veränderung außen vor zu halten.
  • 18.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Rollen in Scrum 20 Product Owner Scrum Master Team Bildquellen: Apple, Inc., Scrum Alliance Inc., EuropuppyUSA.com
  • 19.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Scrum in Action 21
  • 20.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Another Silver Bullet?  Prozess-Schwächen werden sichtbar  Verschwendung: Nicht-wertschöpfende Aktivitäten (Wert aus der Sicht des Kunden)  Engpässe und Blockaden  Überlastung 22
  • 21.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Scrum – Nachweisliche Ergebnisse  Funktionsfähige Software am Ende eines jeden Sprints  „Fertig“  Qualität  Kontinuierliche Steigerung der Produktivität  Reduktion des Stress-Niveaus  Steigerung der Zufriedenheit von Kunden und Mitarbeitern  Fokus auf die richtigen Features  Transparenz auf den Projektfortschritt  Einfachere und realistischere Möglichkeit zur Planung  Nachhaltige Steigerung der Softwarequalität 23
  • 22.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Product Backlog  Liste  Anforderungen  Arbeitspakete  Was ist zu tun  Einträge: User Stories - „Wert“ für Kunde/Benutzer  Priorisiert  Geschätzt  „Sizing“ 24
  • 23.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com User Stories: User + Story 25  Anforderungen/Features aus Benutzersicht  Jede Story muss einen Wert für den Benutzer darstellen  Ist einfach zu verstehen  Kurzer Beschreibungstext  Klarheit darüber, was der User damit an Funktionalität bekommt Quelle: Mike Cohn, Mountain Goat Software As a vacation planner, I want to see photos of the hotels. As a user, I want to cancel a reservation. As a frequent flyer, I want to rebook a past trip, so that I can save time booking trips I take.
  • 24.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Der Product Backlog Eisberg 26 Priorität Sprint Release Nächstes Release
  • 25.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Wo halten wir den Backlog? 27 Bildquellen: Scrumworks, VersionOne, T-Online, Mountain Goat Software
  • 26.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Tools (2) 28
  • 27.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Sizing – Planungspoker 29  In vielen Fällen konvergiert das Ergebnis bereits nach der zweiten Runde.  Der Moderator sollte versuchen, Konvergenz in der Diskussion herbeizuführen.  Es geht dabei nicht um Genauigkeit, sondern Angemessenheit. Schätzer 1. Runde 2. Runde Fred 3 5 Wilma 8 5 Barny 2 5 Betty 5 8 Quelle: Mike Cohn
  • 28.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Vor dem Sprint / Planning - Themen  Vorbereitung  Backlog  Team  Bugs  Tasks  Granularität, „Herunterbrechen“  Diskussion, Schätzen  Das gesamte Team (Qualität des Plans)  Was kommt in den Sprint?  „Neben-Aufgaben“, Infrastruktur, „Administrative Aufgaben“…? 30
  • 29.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Das „Task Board“ ist ein Sprint-Monitor 31 Story Tasks to do Design and Code the User Interface 8 Code the Middle tier interfaces 8 Code the business logic 12 Design the Integration rules 4 Design and Code the User Interface 4 Code the Middle tier interfaces 8 Code the business logic 2 Design the Integration rules 2 In progress To be verified Done Design and Code the User Interface 4 Code the Middle tier interfaces 8 Code the business logic 6 Design the Integration rules 4 Hours 18 10 14 Summe der verbleibenden Stunden am Ende des Tages / 6 / 2 / 2
  • 30.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Definition von „DONE“  Teams zu 3 - max. 6 Personen  Ein aktuelles (oder fiktives) Produkt/Projekt  Was bedeutet „Done“ („Fertig“) …?  für mich persönlich  für mein Team  für meinen Vorgesetzten  für meinen Kunden  … 32
  • 31.
    © 2007 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Continuous Integration  Build Automatisierung  Automatisierte Tests  Unit-Tests  Integrationstests  UAT  Last- u. Performance-Tests  Coverage  Deployment  Code-Analyse  Metriken  Report 33
  • 32.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com FAQ: Architektur  Evolving Architecture  Architektur entwickelt sich über die Zeit  Wieviel Architektur ist notwendig? Wie wenig möglich?  Architektur-Sprints  Zumindest ein Stück Funktionalität im Sprint  Spikes, Prototypen  Joint Application Design Sessions  Das gesamte Team arbeitet an der Architektur  Entweder unmittelbar vor oder nach dem Sprint Planning 34
  • 33.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Beispiel Sprint-Board 35
  • 34.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Beispiele: Sprint Burndowns 36
  • 35.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Non-Excel Burndown Reports 37
  • 36.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Der Visuelle Arbeitsplatz 38  Agile Methoden bevorzugen einfache Visualisierung und offene Kommunikation  Arbeitsplatz mit allen wichtigen Informationen verfügbar  Release Plan  Sprintziel  Sprint Backlog  Hindernisse, …  Build-Ergebnisse, Metriken,  Erlaubt Selbstorganisation und Inspect & Adapt  Erlaubt dem P.O. den Fortschritt des Teams zu erkennen und ob das Ziel erreicht werden kann Quelle: Ken Schwaber
  • 37.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Sprint Review  Demo funktionsfähiger Software  Qualitätsgesichert  Ziel: Präsentation von Software als Life-Demo  Vorbereitung  Tests  Kurzer Intro (Sprint-Ziel, Context,…)  Hoch-Produktive Teams zeigen nur Life-Demos  Keine Dokumente, Diagramme, Folien etc.  Einzige Ausnahme für „technische Stories“ zB. Testergebnisse, Reports 39
  • 38.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Retrospektiven  Wichtig für alle Teams, um stetig produktiver zu werden  Team (typischerweise ohne P.O.)  Praktiken aus der Moderationstechnik  Good/Bad  Timeline  5 Whys  …  „Lessions learned“ verteilen  „Knowledge Bridge“  Skalierte Retrospektive  SM weekly, SOS 40
  • 39.
    © 2008 ObjectbaySoftware & Consulting GmbH. www.objectbay.com Literaturempfehlungen 41 Ken Schwaber: Agile Project Management with Scrum Microsoft Press, 2004 ISBN 0-7356-1993-X  Amazon.de Mike Cohn: User Stories Applied Addison Wesley, 2004 ISBN 0-321-20568-5  Amazon.de Boris Gloger: Scrum Carl Hanser Verlag Wien München, 2008 ISBN 978-3-446-41495-2  Amazon.de Mike Cohn: Agile Estimating and Planning Prentice Hall Intl., 2005 ISBN 0-13-147941-5  Amazon.de
  • 40.

Hinweis der Redaktion

  • #5 Task Switching: DeMarco/Lister: Peopleware, Project-Multitasking: Goldratt in Critical Chain
  • #9 Individuals and interaction without the right people who have the right technical and behavioral skills, all the process and tools in the world won‘t produce results. People often tied down with procedures and forms BPR proponents thought that structured processes would somehow make up for mediocre individual capabilities No process can overcome the lack of good engineers, product managers, customers, suppliers and executives Good process should support the team rather than dictate it actions APM supports creators, not stewards Working results a characteristic of serial development is delivering documentation artifacts large, front-end loaded projects spend months, and even years gathering and documenting requirements, proposing architectures and designing products are prone to errors Documents do not work. Products do. stress the delivery of versions of the product (or effective simulations and models) this delivery verifies that something tangible to the customer is being built working features provide dependable feedback into the development process, in a way, a document cannot. Documentation is not unimportant, it is just less important than a working version Documentation is not a substitute for interaction and collaboration In traditional forms, a document often has become a substitute (customer & product owner send a requirements document to development), and thus barricade to progress (no knowledge is transferred) Customer collaboration customer team and development team form a partnership with specific roles, responsibilities and accountabilities the customer is the individual or group who uses the created product to generate business value Customers define value Other stakeholders define constraints (we must not confuse these roles) Customers define requirements (features) that provide value and the business objective (schedule, cost) that assist in quantifying that value today value arises from implemented features that meet the requirements tomorrow‘s benefits (once a product is delivered) is a function of how quickly and cost effectively the product can be adapted.  Deliver today, adapt tomorrow Responding to change every project has to balance planning and change exploration style projects are characterized by a process that emphasizes envisioning and then exploring into that vision rather than detailed planning and relatively strict execution of tasks Cost of exploration, experimenting = cost of an iteration. Low cost iterations enable adaptive style of development „conforming to plan“ falls very short in a turbulent economy. The old mantra „plan the work“ and then „work the plan“ Highsmith 2004, pp. 8ff Mike Cohn 2006, pp. 21f J. Coldewey: Collaboration over formalisms short increments over year long mediation flexibility over planning orgies Customer involvement over safeguarding
  • #14  Klassisches Vorgehen also Plan/Execute = Ziel anvisieren, Abschießen einer „unguided Missile“ Nur: eigentlich immer ein bewegliches Ziel (Anforderungen, Technologie, …) Agile Methoden verwenden ein iterativ inkrementelles Vorgehen Iterativ heißt „in Iterationen“ Fixe Länge, zB 2 Wo klarem Fokus auf das Ziel Feedback: früh & häufig Ähnlich Navigationssystem im Auto In jeder Iteration Entscheidungsräume
  • #15 100% Fertig = Getestet Wesentliche Unterscheidung zur klassischen Entwicklung Typ. Release zB. Ein Jahr, mehrere MS, a, b, Release, HotFix klassisch: spät testen, spät integrieren, spät dokumentieren iterativ: von Beginn weg testen, integrieren, dokumentieren Workload und Stress ausnivellieren Qualität konstant hoch halten Geschwindigkeit nicht ohne Qualität möglich Regelmäßige Shipments möglich, da Inkremente auslieferbar sind
  • #22 Beispiel bei Fabasoft Planung / Sprint Kommitment - Einfache, sehr effiziente Visualisierung - Daily Scrum: ca. 10 min täglich
  • #24 Produktivität auch Team-Entwicklung, Reibungen, Extrem klarer Fokus Stress: Auch Entlastung von Einzelkämpfern, Belohnungseffekt, positiv
  • #30  A round should not take longer than three minutes If the requirements are not clear, define the story new (not in the poker game)
  • #37 The team was not able to finish the committed work. It looks like it had an issue in progress on day 3-4 and the second week. It seems, that they spent more than once much more time on finishing tasks in significant more time than planned. The team was faster than expected and finished more work than planned. The velocity was higher than planned. The PO put in another story and the team seemed to delivered it.
  • #44 The material in this document is protected by copyright law. Some contents in this presentation have been included from their original authors with permission, these are: Ken Schwaber’s Version 5 Certified ScrumMaster Course and CSM course materials Mike Cohn’s Redistributable Intro to Scrum Ken Schwaber’s and Mike Cohn’s CSPO course materials Roman Pichler’s CSM course materials No part of this publication may be reproduced or transmitted in any form or for any purpose without prior express permission of Objectbay. The information contained herein may be changed without prior notice. Some software products marketed by Objectbay and its distributors contain proprietary software components of other software vendors. Objectbay is a trademark or registered trademark of Objectbay Software & Consulting GmbH in Austria and/or the European Union and in several other countries all over the world. All other products and names mentioned are trademarks or registered trademarks of their respective companies.