Erfahrungen bei der Einführung agiler Methoden im JBF-Team

Präsentation zum Thema: "Erfahrungen bei der Einführung agiler Methoden im JBF-Team"—  Präsentation transkript:

1 Erfahrungen bei der Einführung agiler Methoden im JBF-Team
Erfahrungen bei der Einführung agiler Methoden im JBF-Team D.Brotzer, SYRACOM AG; O. Fischer, Technische Architektur | JBFOne 2009

2 Agenda Szenen aus dem Projektalltag
Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

3 Szenen aus dem Projektalltag

4 Agenda Szenen aus dem Projektalltag
Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

5 Was haben wir gesehen? Unklare Anforderungen
Projektstatus und –fortschritt ist nicht transparent Lange Reaktionszeiten auf neue Anforderungen Relativ hoher Anteil ungeplanter Tätigkeiten Wissensinseln

6 Agenda Szenen aus dem Projektalltag
Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

7 Das agile Manifest wichtiger als wichtiger als wichtiger als wichtiger

8 Agilität schafft Sicherheit und Transparenz
Klare Priorisierung der Anforderungen oberstes Ziel: Maximierung des Geschäftswerts/Kundennutzens Setzen von Sicherungspunkten kurze, gleich lange Iterationen Regelmäßige Produktinkremente und Einholung von Feedback Kunde muss jedes Inkrement abnehmen Mehr Flexibilität auf Kundenseite Kunde kann Anforderungen im laufenden Projekt ändern, streichen, ergänzen oder ersetzen Mehr Transparenz über Projektstatus und -fortschritt Schätzgrößen werden frühzeitig mit empirischen Daten hinterlegt

9 Firmen, die auf Agilität setzen

10 Agenda Szenen aus dem Projektalltag
Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

11 Sprint Planning Meeting
Die SCRUM-3 x 3-Matrix Product Backlog Sprint Backlog Impediment List 3 Artefakte Scrum Master Product Owner Team 3 Rollen Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting 15' (Retrospective) 3 Meetings

12 Der SCRUM-Prozess

13

14 SCRUM MACHT PROBLEME SICHTBAR

15 SCRUM = RISK-MANAGEMENT

16 Agenda Szenen aus dem Projektalltag
Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

17 Szenen aus dem agilen Projektalltag

18 Agenda Szenen aus dem Projektalltag
Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

19 Ziele von agile@JBF … Verbesserung des Know-How-Transfers
kürzere Reaktionszeiten auf Anforderungen weniger Aufwände für Bewertungen einfachere Priorisierung von Anforderungen mehr Transparenz für alle mehr Kommunikation, mehr Austausch von Informationen im Team

20 Der Projektherzschlag von agile@JBF
Sprint 1 28 Tage Sprint 2 28 Tage Sprint 3 28 Tage Sprint 4 28 Tage Sprint 5 28 Tage Sprint 6 28 Tage Milestones M1 M2 M3 M4 M5 Final Release Mittwoch Donnerstag Freitag vor Sprintende Der JBF- Entwicklungsprozess basiert auf SCRUM Die Dauer eines Sprints beträgt 4 Wochen  6 Sprints pro Release Ein Sprint dauert jeweils von Donnerstag bis Mittwoch Sprint-Endgame 3 Tage vor Sprintende (Freitag, 12 Uhr) Code Freeze Entwicklertests zur Stabilisierung und Aushärtung des Systems Zeitliche Freiräume können zur Spezifikation kommender Features genutzt werden Retrospektive nicht vergessen! Sprint Review Meeting mit dem Product Owner zur Abnahme der Features Release-Endgame Letzter Sprint vor dem finalen Release zur Aushärtung des Systems Keine neuen Features mehr Daily scrums der Teilteams sind zeitlich versetzt Spezifi- zierung Spezifi- zierung CM + Bug Test Spezifi- zierung Entwurf + Konstruktion Sprint-Endgame Planning Meeting CM + Bug Test Spezifi- zierung Entwurf + Konstruktion Sprint-Endgame Planning Meeting CM + Bug Test Spezifi- zierung Entwurf + Konstruktion Sprint-Endgame Planning Meeting Planning Meeting CM + Bug Sprint-Endgame Planning Meeting CM + Bug Sprint-Endgame Release-Endgame Test Test Entwurf + Konstruktion Entwurf + Konstruktion

21 Detailplanung eines Sprints
28 Tage Sprint - Endgame Retrospektive Code Freeze Sprint - Endgame Retrospektive Sprint Review Spezifizierung Spezifizierung Planning Meeting CM + Bug CM + Bug CM + Bug Planning Meeting Test Test Test Entwurf + Konstruktion Entwurf + Konstruktion Entwurf + Konstruktion Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di.

22 Teamstruktur: das Prinzip des JBF Molecule
Product Owner Team Scrum Master Team Team Product Owner Scrum Master Scrum Master Product Owner Scrum Master Herleitung der organisation: Wir sind mit einem Scrum-Master und zwei Pos gestartet, haben aber erkannt, dass Scrum Master und PO Vollzeit Team Product Owner

23 Teamstruktur: The JBF Molecule
Klaus Huthmacher Frank Gamerdinger Server 5 TM WS & Sec 4 TM Markus Gäbelein Simon Schrezen- meier MIAMI 3 TM Maintenance 1 (+3) TM Roman Koutny Ellen Rottmann Michael Jung Oliver Fischer Simone Sänftl Marek Nowak Client 4 TM BiTemp 5 TM Hans Kellner Markus Haseneder

24 … und wie wir die Ziele erreicht haben
Verbesserung des Know-How-Transfers Einführung Maintenance-Team für Supportaufgaben rollierend und interdisziplinär besetzt gemeinsames Bearbeiten neuer Features (Pair-Designing,Pair-Programming) kürzere Reaktionszeiten auf Anforderungen Anforderungen können jederzeit gestellt werden neue Anforderungen werden durch PO zeitnah bewertet kürzere Time-to-market durch 4-Wochen-Sprints Verbesserung des Know-How-Transfers Einführung eines rollierend, interdisziplinär besetzten Maintenance-Teams für Supportaufgaben (Bearbeitung von Tickets, Bugs & Wishes und Supportanfragen) Gemeinsame Bearbeitung von neuen Features im Team, Pair-Programming bei kritischen Tasks (Auflösen der Wissens-Inseln) Kürzere Reaktionszeiten auf Anforderungen Anforderungen können jederzeit gestellt werden Product Owner tagen jede Woche, neue Anforderungen werden zeitnah bewertet Arbeit in 4-Wochen-Sprints ermöglicht eine kürzere Time-to-market Weniger Aufwände für Bewertungen Es werden nur die Anforderungen detailliert bewertet, analysiert und geschätzt, die auch in den nächsten zwei Sprints umgesetzt werden Anforderungen, die eine niedrige Priorität haben, werden nur soweit analysiert, wie für eine Priorisierung erforderlich Einfachere Priorisierung von Anforderungen Anforderungen werden Kontingenten (Projekte, Betrieb, Strategie, …) zugeordnet und gemeinsam mit einem JBF-externen Kontingent-Verantwortlichen priorisiert.

25 … und wie wir die Ziele erreicht haben (Fortsetzung)
weniger Aufwände für Bewertungen nur Anforderungen für die nächsten zwei Sprints werden detailliert bewertet, analysiert und geschätzt einfachere Priorisierung von Anforderungen Anforderungen werden Kategorien (Projekte, Betrieb, Strategie, …) zugeordnet gemeinsame Priorisierung mit den jeweils Verantwortlichen mehr Transparenz für alle Backlogs sind für alle sichtbar Burndown Charts sind für alle sichtbar für alle offene Meetings Verbesserung des Know-How-Transfers Einführung eines rollierend, interdisziplinär besetzten Maintenance-Teams für Supportaufgaben (Bearbeitung von Tickets, Bugs & Wishes und Supportanfragen) Gemeinsame Bearbeitung von neuen Features im Team, Pair-Programming bei kritischen Tasks (Auflösen der Wissens-Inseln) Kürzere Reaktionszeiten auf Anforderungen Anforderungen können jederzeit gestellt werden Product Owner tagen jede Woche, neue Anforderungen werden zeitnah bewertet Arbeit in 4-Wochen-Sprints ermöglicht eine kürzere Time-to-market Weniger Aufwände für Bewertungen Es werden nur die Anforderungen detailliert bewertet, analysiert und geschätzt, die auch in den nächsten zwei Sprints umgesetzt werden Anforderungen, die eine niedrige Priorität haben, werden nur soweit analysiert, wie für eine Priorisierung erforderlich Einfachere Priorisierung von Anforderungen Anforderungen werden Kontingenten (Projekte, Betrieb, Strategie, …) zugeordnet und gemeinsam mit einem JBF-externen Kontingent-Verantwortlichen priorisiert.

26 … und wie wir die Ziele erreicht haben (Fortsetzung)
mehr Kommunikation, mehr Austausch von Informationen im Team regelmäßiger Informationsaustausch durch Daily Scrum Meeting Vorstellung von Sprintergebnissen im gesamten Team was wir uns nicht vorgenommen, aber nebenbei trotzdem erreicht haben: Anzahl offener Tickets ist deutlich gesunken, Ticketlösungsrate wurde erhöht Teamzufriedenheit ist gestiegen Qualitätsverbesserung Bessere Planbarkeit Ticketlösungsrate verbessert, keine auffälligen Tickets im OKLF

27 agile@JBF im Zeitverlauf
2009 2010 Sprints Start mit einem Scrum Master zwei Product Ownern aber ohne Tool Auslieferung Milestonebuilds Taskgröße max. 5 PT Definition of Done Nutzung von Rational Team Concert Maintenance-Team Mehrere Product Owner JBF Molecule Intensivierung Pair working “Die Dinge, die wir erst lernen müssen, bevor wir sie tun, lernen wir beim Tun.“ - Aristoteles Reviewmeetings Ein Scrum Master je Team Schätzpoker

28 Fragen? – Diskussion? David Brotzer Oliver Fischer
SYRACOM Consulting AG Oliver Fischer Anwendungsentwicklung Technische Architektur Teamleiter JBF 0 89 / – 31 47

29 Ihr IT-Partner Vielen Dank