Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006

Größe: px

Ab Seite anzeigen:

Download "Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006"

Jasper Gerber
vor 8 Jahren
Abrufe

1 Überleben mit Scrum Andrea Schulz

2 Hintergrund Projektmanager, Scrummaster, SW-Entwickler Siemens Healthcare Webbasierte Software Produkte (Releases als Projekte) Teilweise Medizinprodukt Scrum seit 2006

3 Häufige Erwartungen an / Gründe für Scrum Neu, modern, innovativ Einfach (Kochrezept) Schnellere Entwicklung Einhaltung von Terminen und Scope Wichtige Themen zuerst Höhere Kundenzufriedenheit Höhere Mitarbeiterzufriedenheit Mehr Transparenz

Einhaltung von Terminen und Scope Wichtige Themen zuerst

4 Unsere Ausgangssituation Anzahl Entwickler, Produktmanger, Tester Kunden und Anforderungen Anzahl Lieferungen Prozessanforderungen Kommunikations- und Verständnisprobleme Transparenz Prozess fordert V-Modell (Medizinprodukt) Wir wollen Scrum

Prozessanforderungen Kommunikations- und Verständnisprobleme

5 ScrumimVModell V-Modell Problem: Entwicklung erst nach Analyse/Konzept erlaubt Lösung: Sprints im ganzen Release durch Definition: iti Während Analyse: Prototype-Sprints Während Entwicklung: Produktiv-Sprints Entwicklungsabschluss: Stabilisierungs-Sprint Während Systemtest: Test- und Bugfix-Sprints

Analyse: Prototype-Sprints Während Entwicklung: Produktiv-Sprints

6 ScrumimVModell V-Modell Problem: Release-Inhalt, Termine und Kosten sind Teil der ersten Meilensteine Lösung: n Sprints Nur große Punkte Grün-Gelb-Rot-Liste Kosten in Sprints über Personen x Zeit

7 n Sprints: ScrumimVModell V-Modell Berechnet aus Endtermin und Zeit für Abschlussarbeiten b (Systemtest, t t Doku ) Wichtig: Puffer einplanen Gefahr: das können wir ja noch im nächsten Sprint machen das können wir noch im Stabilisierungssprint glattziehen es kommt ja noch ein Systemtest Wichtig: rechtzeitig gegensteuerng

das können wir ja noch im nächsten Sprint machen das können wir noch im

8 ScrumimVModell V-Modell Nur große Punkte: Managertauglich Lässt Spielräume in der Umsetzung Wichtig: rechtzeitig Klärung und Schätzung mit kleinen(!) Punkten und Neuschätzung in jedem Sprint (Release-Burndown) Grün-Gelb-Rot-Liste: Grün: in jedem Fall enthalten (Velocity) Gelb: sollte möglich sein; wird dem Kunden nicht versprochen, da nicht sicher Rot: normal nicht enthalten

) Punkten und Neuschätzung in jedem Sprint (Release-Burndown) Grün-Gelb-Rot-Liste: Grün: in

9 ScrumimVModell V-Modell Problem: Bedenken unseres Q Departments (Wie könnt Ihr mit Scrum sicher sein und auch beweisen, dass tatsächlich die Requirements und Risiko-Mitigations implementiert werden, über Impact und Risk nachgedacht wurde.) Lösung: Sprint Review Protocol pro Team und Sprint

Requirements und Risiko-Mitigations implementiert werden, über Impact

10 Tab1:SprintPlan Sprint Backlog plus Zuordnung zu Requirements plus Impact Analyse

11 Tab2:SprintReview Datum, Namen und Unterschriften Requirements Risiko Mitigations Was wurde erledigt (done) was ist noch offen? Unterschrieben vom gesammten Team. Dokumente Deficiencies / Lessons Learned

12 Tab3:Checkliste Ch kli t i h t ll d ll P h itt b ü k i hti t Checkliste um sicherzustellen, dass alle Prozessschritte berücksichtigt wurden

13 Tab 4: Risk Assessment Team mit Product Owner und Risk Manager Brainstorming als Input für Risiko Analyse (pro Sprint und Team)

14 Das Brett Karten nebeneinander Verschiedene Farben für Product Backlog Items und Tasks Out-of-sprint Bereich mit geschätzten Tasks Vorteile: Besserer e Überblickb Abhängigkeiten klarer Flexibilität durch priorisierte i i out-of-sprint t Tasks

geschätzten Tasks Vorteile: Besserer e Überblickb

15 Status der Karten Offen In Arbeit Done

16 Tipps: Die Teams Feature Teams (nicht: UI Backend, nicht: separates Reste-Team Fall 1: Commitment nicht so stark - nicht ihre Features es Fall 2: Machen die Arbeit, aber fühlen sich wie das ungeliebte Stiefkind) Product Owner mit Delegate (nicht: zweiter Product Owner) Scrum Master Product Owner (falls nötig: lieber jemand aus dem Team) Teamzusammensetzung nicht zu oft ändern (ein neues perfektes Team is weniger produktiv als ein etabliertes Team die Spezialisten fragen sie sowieso bei Bedarf)

(nicht: zweiter Product Owner) Scrum Master Product Owner (falls nötig: lieber jemand aus dem Team) Teamzusammensetzung

17 Tipps: Verteilte Teams Zumindest für Sprint Planning treffen Falls nur 1 Meeting: Retrospective am Tag der Sprintplanung Telko für Daily Scrum Sprint Backlog, Burndown und Foto des Bretts verfügbar für alle (e.g. Wiki) (Obwohl Sprint Backlog normalerweise die gleiche Information enthält, hilft das Foto des Bretts wirklich)

18 Tipps: Sprint Planning Entwickler Items im Backlog berücksichtigen (Verhindert überraschende must-have Tasks am Ende, aber unbedingt korrekt mit priorisieren) Items und Tasks verständlich für alle (nicht: Product Owner diskutiert nur mit dem wahrscheinlichen Entwickler er könnte am Schluss zu viele Tasks haben oder Geld erben ) Karten klar verständlich (nicht: UI 5 Tage, nicht: Doku 30 Tage, davon timeboxed 5 Tage) Eti Estimation durch hdas ganze Team (Keine meine Tasks deine Tasks) Doku und (Unit-)Test mit auf die einzelnen Tasks (nicht: große Sammelkarten dafür landen meistens out-of-sprint) Nicht zu viele Themen anfangen (fertig machen nicht vergessen und Release Burndown beachten gegen zu viel Perfektionismus)

(nicht: UI 5 Tage, nicht: Doku 30 Tage, davon timeboxed 5 Tage) Eti Estimation durch hdas ganze Team (Keine meine Tasks deine Tasks) Doku und (Unit-)Test mit auf die einzelnen

19 Tipps: Im Sprint Im Daily Scrum: Nicht Tage abziehen - Restaufwand schätzen Klare Definition von Done Done (jaa, das steht in jedem Scrum-Buch) Abnahme durch Product Owner vor Done (frühes Erkennen von Missverständnissen) Daily/Nightly Build System - auch für Product Owner (Gelegenheit, UseCases komplett durchzuspielen und Fehler, insbesondere Seiteneffekte, früh zu erkennen) Unit Tests (Seiteneffekte schneller erkennen) Einfache Dokumentation (z.b. Wiki, insbesondere Entscheidungen) Vorheriges Durchspielen des Sprint-Review (findet häufig Fehler)

Owner (Gelegenheit, UseCases komplett durchzuspielen und Fehler, insbesondere Seiteneffekte, früh zu erkennen) Unit Tests (Seiteneffekte

20 Sprint Retrospective: Sonstige Tipps Lessons Learned Müdigkeit kreativ bekämpfen (z.b. rote und grüne Karten, Fragen auf Flipchart mit Klebepunkten ) Aufgabenverteilung: Team selbst verteilen lassen (zufriedener und besser) Nicht schon im Planning alles verteilen (Flexibilität) Sprint Review: Kunden teilnehmen lassen (bessere Qualität, höheres Kundenvertrauen, Feedback an Entwickler, schnellere und daher oft günstigere und/oder einfachere Änderungen möglich) Feste Sprintlänge (einzige Ausnahme: Weihnachten - keine Ausreden) Vortests (Fehler aus Systemtest t t haben hohen h Verwaltungsaufwand) Release Retrospective (andere Themen als in Sprint Retrospective)

rote und grüne Karten, Fragen auf Flipchart mit Klebepunkten ) Aufgabenverteilung: Team selbst verteilen lassen (zufriedener und besser) Nicht schon im Planning alles

21 Vielen Dank.

Ähnliche Dokumente

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende