Scrum & Planning Poker für Ihre Web Strategie

© 2010 Mayflower GmbH

Straight Flush & Full House: Scrum und Planning Poker für Ihre Web-Strategie

Straight Flush & Full House I Mayflower GmbH I 25. März 2010 I 2

Wir wollen ein neues Online Portalfür unseren Kunden entwickeln.Auweiha ...

Vorführender

Präsentationsnotizen

Der Businesscase steht und alle freuen sich, dass das Unternehmen bald viel Geld verdienen wird. Das Projekt ist definiert, es besteh ein Pflichtenheft. Der Zeitplan ist aufgestellt und die Milestones definiert. Es wird von einem Releasetermin in 9 Monaten ausgegangen. Die Konkurrenz schläft nach eigenem Ermessen noch und man wird auf dem Markt ein riesiges Oha haben. Perfekt! Jetzt brauchen wir nur noch ein passendes Entwicklerteam und alles ist geritzt!


Puh...ganz schön viele Features.

Da brauchen wir6-7 Monate für.

Vorführender


Die übliche Konstellation ist, dass man auf der einen Seite einen Vertreter der Fachabteilung hat, der eine Anforderung hat. Und auf der rechten Seite einen Vertreter aus der Entwicklungsabteilung. Der sagt erst einmal: “Was genau meint er?”


3 Monatespäter ...


Wir führen ein neues ERP System ein.Das Fulfillment des Kunden muss

angebunden werden.Neeeeiin ...

Vorführender


Schwierigkeiten entstehen dort, wo mitten im Projekt einfach neue Funktionalitäten von Fachseite “reingedrückt” werden – diese werden oft per Change Request realisiert, in vielen Projekten wird aber dabei nicht auf Prozesse geachtet, so dass Chaos entsteht.


Vorführender


Das erste Problem taucht auf: wie soll die Änderung in den klassischen PM Prozess einfliessen? Es gibt eine Abfolge der Aufgaben, aber keine Priorisierung der einzelnen Aufgabenpakete. Reibungsverluste entstehen. Das Projekt verzögert sich.


1 weiterenMonat später ...


Jetzt wird es wirklich eng. Das Team wurde erweitert, das Projekt ist zu komplex.

Zeit- und Budgetrahmen können wirnicht halten.

grml...

Vorführender


Die Probleme werden immer mehr. Der Projektmanager ist nur noch damit beschäftigt die Gantt Diagramme zu aktualisieren und neue Milestones festzulegen Im Team weiss mittlererweile keiner mehr, was der andere macht. Schnittstellen und APIs werden so häufig geändert, dass ständig an bereits fertigen Stellen nachgearbeitet werden muss. Die Motivation im Team sinkt. Der Zeitplan ist fast nicht mehr zu halten. (Oft versuchen Unternehmen in dieser Phase noch mehr Entwickler auf das Projekt zu stecken, nach dem Motto “Viel hilft Viel”. So etwas hat jedoch immer zunächst mal Einbußen in der Produktivität zur Folge.)


Marketing möchte das Produkt alsApp in XING einbinden. Undzwar NOCH im 1. Release!WTF?

Vorführender


Ein klassischer Fehler: neue Funktionalitäten werden von Auftraggeberseite hineingedrückt. “Das muss jetzt fertig werden”, “Das muss noch mit rein”. Besser: Feature-Tausch. Wenn der Auftraggeber ein Feature noch mit rein haben möchte, das 8h dauert, wird dafür ein bereits geplantes, gleichwertiges Feature mit ähnlicher Dauer entfernt.


KaputterZeitplan


Unser Konkurrent hat sein neuesProdukt vorgestellt. Wir müssenunbedingt sofort nachziehen!

Wie solldas gehen?

Vorführender


Durch die ständige, hohe Änderungsfrequenz auf Seiten des Auftraggebers sinkt die Motivation im Team. Merke: Änderungen sind sinnvoll und möglich, aber nicht auf dieser Art und Weise.


Vorführender


Die Geek Abteilung kann sich jetzt hinsetzen und irgendetwas entwicklen, das wird aber zu Projektende sicherlich nicht den Anforderungen der Fachabteilung entsprechen. Warum nicht? 1. Die Fachabteilung hat es sich anders vorgestellt, konnte es aber nicht kommunizieren 2. Die Bedingungen haben sich geändert und das geplante Produkt muss inzwischen ganz anders aussehen um am Markt erfolgreich zu sein. Die Folge: nach massiver Demotivation im Team kündigen ein oder mehrere der Hauptentwickler des Projekts.


Wie bekommen Sie dasDebakel nun in den Griff?

Vorführender


Das übliche Projekt-Wirrwarr ist entstanden: der Kunde will ständig Änderungen, es existiert kein (schwergewichtiger) Prozess der die hohen Änderungsfrequenzen im Zaum hält. Wie kann man nun erreichen, dass Änderungen (auch hohe Änderungsraten) möglich sind, ohne die beschriebenen Schwierigkeiten?


DAS TEAM

Meet Scrum!

Vorführender


Mit der Implementierung eines leichtgewichtigen Projektmanagement- und Entwicklungsansatzes, namentlich Scrum, sind diese Probleme lös- und managebar. Andere leichtgewichtige Projektmanagement- und Entwicklungsmethoden sind zum Beispiel eXtreme Programming, TDD und FDD.


Scrum in 120 Sekunden(und ohne Bilder)

Vorführender


Einmal kurz zur Methodik von SCRUM. Es gibt einen Product Backlog, in dem steht alles was das Produkt einmal können muß. Hier fließen auch ständig neue Anforderungen rein. Es ist absolut wichtig, dass die dortigen Einträge priorisiert sind und auch Abhängigkeiten zu anderen Paketen geprüft werden. Im Sprint Backlog stehen alle Aufgaben für den aktuellen Sprint. Die Aufgaben müssen klar in einzelne Use Cases aufgeteilt werden. Komplettbeschrieben sein und sehr wichtig, die Akzeptanzkriterien müssen definiert sein, um genau zu wissen, wann eine Aufgabe auch vom Auftraggeber als abgenommen gilt, so sie denn funktioniert. Die Aufgabenmenge wird so bemessen, dass sie in dem für den Sprint vorgesehenen Zeit bearbeitetwerden können. Der Sprint geht über einen gewissen Zeitraum, hier z.B. 30 Tage. Innerhalb des Sprints wird jeden Tag nachgefragt: - Was der Entwickler gestern gemacht hat - Was er heute macht - Welche Probleme er bei der Umsetzung hat. Sollten keine Probleme auftauchen, dann müßte es auch so sein, dass der Sprint exakt nach der Planung fertiggestellt ist. Soweit zur Theorie :-) Man braucht auch noch Menschen die die Aufgaben machen kommen wir mal zu denen...


Product Backlog

I Enthält alle gewünschten Funktionalitäten in Stories

I Wird immer wieder um neue Funktionalitäten ergänzt, die gewünscht sind

I Einträge müssen priorisiert werden

I Prüfung von Abhängigkeiten zu anderen Paketen


I Enthält alle Aufgaben des aktuellen Sprints, wird zusammen mit dem Kunden definiert

I Aufgaben klar aufgeteilt in Stories/Use Cases

I Aufgaben komplett beschrieben

I Definition von Akzeptanzkriterien

I Aufgabenmenge so beschaffen, dass sie vom Team im Sprint erledigt werden kann

Sprint Backlog


I Time boxed: festes Zeitintervall (z.B.: 5, 10 oder 15 Arbeitstage)

I Aufgaben kommen aus dem Sprint Backlog

I Täglich StandUp Meetings

I Theorie: am Ende des Sprints keine Aufgaben mehr übrig :-)

Der Sprint


I Time boxed: feste Dauer (z.B.: 15 Minuten)

I Jeder beantwortet drei Fragen:- Was habe ich gestern getan?

- Was habe ich heute getan?

- Was steht mir im Weg? (z.B.: CSS wurde nicht geliefert)

I Scrum Master beseitigt Unwägbarkeiten

Tägliches Standup Meeting


I Product Owner (PO) definiert die Anforderungen des Produkts

I Scrum Master koordiniert zwischen PO und Team

I Scrum Team ist selbstorganisierend

Beteiligte Personen

Vorführender


Ohne die Leute die es machen gibt es kein Projekt. Wir haben hier einmal den Product Owner, der definiert alle Anforderungen, die das Produkt haben soll. Im Sprint planning erarbeitet der Product Owner zusammen mit dem Team einen Sprint backlog, der alle Aufgaben des Prints beinhaltet. Danach geht das Team ans Werk und liefert nach dem Sprint eine neue Release Version ab, Aber es gibt natürlich noch eine weitere wichtige Person - und das ist der SCRUM Master. Er übernimmt die Koordination zwischen ProductOwner und Team und sorgt bei offenen Fragenoder auch Problemen für Klärung


Pakete im Backlog werden priorisiert nach:

I Wichtigkeit

I Kosten

I Nutzen

I Risiken

I Abhängigkeiten

Das Product Backlog I


I Höher priorisierte Aufgaben werden vom PO eingebracht

I Andere Funktionalitäten verschieben sich zeitlich nach hinten

I Effekt:- Release Termin kann gehalten werden

- Anderer Funktionsumfang als ursprünglich geplant

Das Product Backlog II


I Genaue Beschreibung der Aufgaben im Sprint Planning Meeting

I Commitment des Teams zur Erfüllung der Aufgaben in geschätzter Zeit

Verteilung der Aufgaben


Scrum & Poker ?


Planning Poker

Vorführender


Wozu brauchen wir denn Pokerkarten bei der Softwareentwicklung? Klar manchmal kommt es einem vor, als hätte ein erfolgreicher Release was mit Glück zu tun. Aber dem muß nicht so sein - wir pokern hier nicht um den Release sondern um die Features besser gesagt um die Zeit, die ein Feature benötigt um Fertig zu werden.


Poker Beispiel: User Registration

Für die User Registration brauche ich 1 Tag.

Wir haben doch dafür schon eine Library -das sollte in 2 Tagen machbar sein.

Unter 3 Tagen geht da gar nichts.Wir brauchen schließlich noch einen

Freigabemechanismus und double Opt In.

Vorführender


Auf Basis der Schätzungen entstehen unter Umständen Diskrepanzen. Dies ist sehr wichtig, denn hiermit kommt ein Kommunikationsfluß zwischen den beteiligten Entwicklern in den Gang, der hilft Unwägbarkeiten aufzudecken und so die Schätzung besser konkretisieren zu können. Resultat: realistische Schätzwerte.


Vorteile des Planning Pokers

I Alle geben Schätzungen gleichzeitig ab

I Hierarchien verdecken keine Informationen

I Laufen Schätzungen auseinander, führt dies zu Aufdeckung von:

- versteckten Anforderungen

- Abhängigkeiten

I Alle commiten sich als Team zur finalen Planung


Ihr Nutzen?

I Sie bekommen das Produkt, das Sie zum Release haben möchten.

I Sie sehen ständig den aktuellen Zustand des Projekts.

I Sie als Product Owner haben die Hoheit in der Priorisierung.

I Gesamtkosten des Projekts steigen nicht unbedingt bei Änderungen.

I Änderungen werden managebar und sind gewollt.


Bildnachweise

I UFO Series: http://ufoseries.com/

I Andere Bilder: http://flickr.com/ CC License

http://ufoseries.com/�

Vielen Dank für Ihre Aufmerksamkeit!

© 2010 Mayflower GmbH

Björn [email protected].: +49 931 35 96 5 15

Mayflower GmbHPleichertorstraße 297070 Würzburg

Kontakt

Scrum & Planning Poker für Ihre Web Strategie

Business

Transcript of Scrum & Planning Poker für Ihre Web Strategie