Estymacja i Planowanie – drugi z cyklu czterech Wiosennych Wieczorów ze Scrum prezentowanych przez Fluid Circle (fluidcircle.net).

1. Wieczór #2
Estymacja i Planowanie
2012-03-13
1

2. O nas
• Pomagamy zespołom rozwijać się
dzięki agile i Scrum.
• przez doradztwo, coaching,
szkolenia, warsztaty i publikacje.
Daniel Skowroński
•Certified Scrum Master
•Microsoft Certified Technology Specialist
•5 lat w branży IT m.in. jako developer, architekt, project
manager i niezależny przedsiębiorca
Michał Parkoła
•5 lat w branży IT m.in. jako analityk,
projektant i product manager
•Professional Scrum Master
2

3. „Żaden plan nie przetrwał nigdy
kontatku z przeciwnikiem.”
Generał George Patton

4. • 2012-03-06 Rzut okiem na Scrum
• 2012-03-13 Planowanie i estymacja
• 2012-03-20 Budowanie zespołu
• 2012-03-27 Wdrożenie i skalowanie
Scrum
4

5. Organizacja
• Jesteśmy na Ty!
• Dwie krótkie przerwy
• Telefony, tablety, laptopy
• Inne?

6. Po co planować?
• 5~10 przykładów, 4 minuty, w parach

7. Po co planować?
• Żeby móc podejmować lepsze decyzje:
– inwestycyjne: robimy ten projekt czy nie?
– biznesowe: jaki problem powinniśmy rozwiązać?
– techniczne: jak zminimalizować ryzyko?
• Żeby móc skoordynować pracę poszczególnych
członków zespołu oraz zespołu z partnerami.

8. Kiedy planowanie zawodzi?
• 5~10 przykładów,
• 4 minuty, w
parach

9. Kiedy planowanie zawodzi?
• Brak kontaktu z rzeczywistością: myślenie
życzeniowe i zbyt późna weryfikacja założeń.
• Zlekceważenie ryzyka i długu technicznego.
• Prawo Parkinsona “Praca przedłuża się by wypełnić
zaplanowany na nią czas.” --> kumulacja opóźnień
• Ludzki mózg nie jest przystosowany do
precyzyjnego szacowania.

10. Organizacje źle planują
• “Kryteria sukcesu: budżet, czas, zakres
według definicji na starcie projektu”
[Standish Group CHAOS Report]
• Badania ukazują marny stan realizacji tych
kryteriów:
– “~60% dostarczonych funkcji leży odłogiem”
– “średni projekt przekracza harmonogram o 100%”
– “ponad 2/3 projektów przekracza budżet”

11. Jak skutecznie planować?
• Postaw wartość produktu na pierwszym planie
vs. realizacja zaplanowanych zadań
• Planuj tylko tak daleko jak jesteś w stanie dojrzeć!
• Oszacuj rozmiar, oblicz czas
• Zawsze korzystaj z najświeższych informacji
+ Gromadź dane historyczne!
• Monitoruj postępy na wielu poziomach
Także wewnątrz sprintu. Oddzielnie.

12. Narzędzia planowania
• User Stories
• Planning Poker
• Dostarczone fragmenty produktu!
• Tablica Scrum
• Burndown

13. Narzędzia planowania
• Zanim ruszymy musimy wiedzieć dokąd
zmierzamy!
• Czego chce odbiorca? – Jednostka produkcji o
• widocznej wartości dla Klienta.
• Jako <rola>, chce <funkcja>, żeby <wartość>.
• Obietnica rozmowy

14. Dobre historyjki
• Independent
• Negotiable
• Valueable
• Estimable
• Small
• Testable

15. Co to znaczy “gotowe”?
•Kryteria akceptacji – o co trzeba
zadbać dla danej historyjki?
•Definition of Done – co jest
spełnione dla każdej historyjki?

16. User Stories
“Aby zwyciężyć na coraz bardziej konkurencyjnym rynku,
Twoja firma wdraża Scrum. Jako osoba najlepiej
rozumiejąca specyfikę zwinnych metod zarządzanie
otrzymałeś zadanie opracowania listy potrzeb, jakie
powinno spełniać narzędzie wspierające pracę zespołu
stosującego Scrum.”
Wypisz 10~20 historyjek użytkownika biorąc pod uwagę
potrzeby członków zespołu, Scrum Mastera, właściciela
produktu oraz wyższego kierownictwa.
12 minut, w parach

17. Jak dobrze umiemy szacować?
Oszacuj następujące liczby takimi przedziałami, aby
prawdziwa wartość mieściła się w nich z
prawdopodobieństwem 90%.
3.Ile osób mieszka obecnie w Zimbabwe?
4.Ile wynosiło PKB Polski w 2009? Jaki to był % PKB całej Unii Europejskiej?
5.W którym roku urodził się George Lucas?
6.Ile efektów specjalnych zastosowano w trylogii Władca Pierścieni?
7.Ile lat temu zbudowany został Wielki Ziggurat w Ur (Sumeria)?
8.Ile litrów piwa wypija rocznie statystyczny Polak? Rosjanin? Japończyk?

18. Jak dobrze umiemy szacować?

19. Jak lepiej szacować?
• Porównać względny rozmiar prac
• Szacować rozmiar, mierzyć czas
• Spytać osoby, które będą to robić
• Połączyć wiedzę kilku ekspertów

20. Planning Poker
• Właściciel produktu wyjaśnia historyjkę zespołowi.
• Każdy członek zespołu wybiera swoje oszacowanie.
• Wszyscy odkrywają oszacowanie jednocześnie!
• Jeśli nie ma zgody, osoby ze skrajnymi wartościami
wyjaśniają swój punkt widzenia, po czym następuje kolejna
runda szacowania.
• Jeśli różnica jest niewielka bierzemy większe oszacowanie.

21. Planning Poker
• Jako zespół oszacujemy przygotowane
wcześniej historyjki za pomocą Planning
Pokera.

22. Scrum

23. Planowanie Sprintu
• Część 1 (2h dla dwutygodniowego sprintu)
– właściciel produktu wyjaśnia najważniejsze historyjki
– zespół wstępnie wybiera, do ilu historyjek się
zobowiąże
• Cześć 2 (2h dla dwutygodniowego sprintu)
– zespół planuje jak dostarczyć historyjki rozpisując
zadania i podejmując odpowiednie decyzje
architektoniczne
– zespół potwierdza lub renegocjuje zobowiązanie

24. Planowanie Sprintu
Jako zespół zaplanujemy wybrane trzy
wcześniej napisane i oszacowane historyjki
dotyczące narzędzia wspierającego pracę
zespołów Scrum.

25. Postępy wewnątrz sprintu
• Codzienny Scrum
– aktualizacja backlogu zadań i pozostałych godzin (sprint burndown)
– okazja do wczesnego wykrycia problemów i zagrożeń
– okazja do bieżącej optymalizacji (współ)pracy zespołu

26. Przykład: Acme Products
• Firma Acme Products rozpoczęła projekt
przygotowania nowego wydania swojego flagowego
produktu przed targami, które odbędą się za 6
miesięcy.
• Jacek, właściciel produktu, przygotował listę około 50
potrzeb i pomysłów jakie chciałby dodać do produktu.
• Zespół produktowy w składzie Andrzej, Marcin, Hania,
Duarte i Ashok oszacował względną złożoność
poszczególnych historyjek. Suma punktów (objętość)
całego backlogu wyniosła 157.

27. Pierwsze trzy sprinty
• Sprint 1 – Jacek wybrał 3 najważniejsze historyjki, ale
zespół był w stanie dostarczyć tylko dwie z nich za w sumie
6 punktów. Podczas retrospekcji zespół zidentyfikował brak
narzędzia continuous-integration jako istotną przeszkodę
spowalniającą prace.
• Sprint 2 - Duarte zainstalował narzędzie CI i zespół
korzystając z niego dostarczył 3 historyjki za w sumie 9
punktów.
• Sprint 3 – Hania zainstalowała ekspres do kawy w sali
zespołu dzięki czemu zespół dostarczył dwie duże historyjki
za w sumie 13 punktów.

28. Po 6 tygodniach
• Dostarczono 28 ptów z backlogu – Jacek ma do dyspozycji działający
fragment systemu, który już realizuje 18% wszystkich pomysłów i to tych
najbardziej wartościowych.
• Średnia prędkość = 9.3 – zespół, Jacek i kierownictwo firmy widzą
wyraźnie jaka jest rzeczywista efektywność prac.
• Spodziewana objętość po 12 sprintach = 145 (92%)
• Przewidywany czas wyczerpania backlogu = 7.5 m-ca

29. Tymczasem u konkurencji
• Waterfall Inc.
– Dostarczona wartość = zero
– Weryfikacja założeń co do zakresu i harmonogramu =
domysły
– Weryfikacja trafności rozwiązania = brak

30. Dalsze prace
• Sprint 4 – za namową Andrzeja zespół zaczął stosować TDD, aby zapewnić
jakość kodu pozwalającą utrzymać stałe tempo prac. Nauka nowej
techniki sprawiła, że zespół dostarczył tylko 3 historyjki za w sumie 7
punktów.
• Sprint 5 – zespół przyzwyczaił się już do TDD i dostarczył nowej
funkcjonalności za 11 ptów.
• Katastrofa? – po 5 sprincie odszedł Ashok – główny ekspert zespołu, który
jako jedyny dobrze rozumiał kluczowy podsystem produktu.
• Sprint 6 – Zespół samo-zreorganizował się i mimo to dostarczył historyjki
za 6 ptów. Podczas retrospekcji zespół postanowił część czasu pracować w
parach aby zminimalizować koszt podobnych problemów w przyszłości.
• Sprint 7~12 – Do zespołu doszła Alicja i przez resztę projektu pomogła
zespołowi dostarczyć średnio 10 ptów backlogu w każdym sprincie.

31. Prędkość i burnup
• Zespół dostarczył funkcjonalność za 112 ptów – 71% całego backlogu.
• Funkcje te reprezentują znacznie więcej niż 71% wartości!
• Pozostałe funkcje mogę okazać się być warte mniej niż koszt dodatkowych
sprintów. Jeśli nie, Jacek w porozumieniu z Zarządem może przedłużyć projekt
mając
a) gotowy wartościowy produkt b) swobodę podjęcia tej decyzji.

32. Przewidywanie przyszłości

33. Scrum vs. Waterfall

34. Pytania i odpowiedzi
?

35. Podsumowanie
• Postaw wartość produktu na pierwszym planie
Historyjki Użytkownika (User Stories)
• Oszacuj rozmiar, oblicz czas
Planning Poker, Prędkość (Velocity)
• Używaj zawsze najświeższych informacji
Działające Fragmenty Produktu, Burndown/Burnup
• Monitoruj postępy także wewnątrz sprintu
Scrum Board, Sprint Burndown

36. • 2012-03-06 Rzut okiem na Scrum
• 2012-03-13 Planowanie i estymacja
• 2012-03-20 Budowanie zespołu
• 2012-03-27 Wdrożenie i skalowanie
Scrum
36

37. Dziękujemy!
37