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 http://fluidcircle.net
3. Kontrakt
• Jesteśmy na Ty!
• Dwie krótkie przerwy
• Telefony, tablety, laptopy
• Inne?
3 http://fluidcircle.net
4. Szokujące marnotrastwo!
60% funkcjonalności systemów
informatycznych jest używana nigdy
lub prawie nigdy. [Standish Group]
4 http://fluidcircle.net
5. 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
5 http://fluidcircle.net
6. Wieczór #1
Rzut okiem na Scrum
Na tym szkoleniu dowiesz się:
• Co to jest i jak działa Scrum?
• Do czego może się przydać?
oraz poznasz:
• zarys historii Scrum,
• główne założenia teorii Scrum.
6 http://fluidcircle.net
7. Wieczór #2
Estymacja i planowanie
Na tym szkoleniu dowiesz się m.in. o:
• Zarządzaniu wymaganiami w duchu agile z
użyciem User Stories
• Względnym szacowaniu złożoności zadań
i zwinnym planowanie prac
7 http://fluidcircle.net
8. Wieczór #3
Komunikacja w Zespole
Na tym szkoleniu dowiesz się:
• jak przekształcić grupę w zespół?
• jak rozwiązywać konflikty w zespole?
• jak stymulować stały rozwój?
8 http://fluidcircle.net
9. Wieczór #4
Wdrożenie i skalowanie
Na tym szkoleniu dowiesz się:
• Jak skutecznie wprowadzić Scrum do
organizacji?
• Jak skoordynować pracę wielu zespołów
w dużych projektach?
9 http://fluidcircle.net
10. Poznajmy się!
• Kim jesteś?
• Jaką rolę pełnisz w swojej organizacji?
• Co wiesz o Scrum?
• Do czego może Ci się przydać Scrum?
10 http://fluidcircle.net
12. Trzy filary Scrum
Inspekcja i adaptacja
vs. przewidywanie wszystkiego z góry
Współpraca z klientem
vs. głuchy telefon
Praca zespołowa
vs. mikro-zarządzanie
12 http://fluidcircle.net
13. Co może dać Scrum?
Im więcej ryzyka i niepewności w
projekcie tym większą przewagę ma
Scrum nad tradycyjnymi podejściami
opartymi o planowanie i specyfikację.
http://en.wikipedia.org/wiki/File:DPLE.jpg
13 http://fluidcircle.net
14. Co może dać Scrum?
Większa produktywność
przez ciągłe doskonalenie praktyk i
systematyczne usuwanie przeszkód
organizacyjnych.
Wymaga dyscypliny i motywacji zespołu oraz wsparcia kierownictwa!
14 http://fluidcircle.net
15. Co może dać Scrum?
Większa wartość produktów
dzięki priorytetyzacji i adaptacji do
prawdziwych wymagań.
Wymaga zaangażowania klienta!
15 http://fluidcircle.net
16. Co może dać Scrum?
Zaangażowanie i satysfakcja zespołu
dzięki samostanowieniu i namacalnym efektom
pracy.
Wymaga szacunku i zaufania kierownictwa!
16 http://fluidcircle.net
17. Uwaga!
Scrum bezlitośnie obnaża
największe słabości
organizacji (aby można je
było usunąć!)
http://www.flickr.com/photos/ikkoskinen/3575379515/
17 http://fluidcircle.net
18. Kto używa Scrum?
• Duże firmy i startupy • Rząd i wojsko!
• Produkty i usługi • Nie tylko IT!
18 http://fluidcircle.net
20. Waterfall
• Kiedy działa dobrze?
• gdy (prawie) wszystko da się przewidzieć i zaplanować
• Kiedy działa źle?
• koszt zmian jest wysoki i szybko rośnie:
• ~> unikanie zmian, zamiatanie problemów pod dywan
• ~> zbyt wolne reagowanie na zmiany ~> strata okazji
• kumulacja opóźnień, brak przejrzystości ~> zawiedzione oczekiwania
• zamrożony zakres ~> klient chce upchnąć jak najwięcej, bo potem nie
będzie miał szansy zmienić zdania
20 http://fluidcircle.net
21. Agile
http://www.flickr.com/photos/erikcharlton/410939714/
przewidywanie ~> pomiar i adaptacja
• paradoksalnie: zwiększa przewidywalność
• zmiana jest stałym elementem procesu
• szybsze wykrywanie (i rozwiązywanie) problemów
• lepsze dopasowanie produktu do potrzeb i oczekiwań klienta
21 http://fluidcircle.net
22. Historia Agile
• ~1950 Deming (cykl PDCA, Japonia)
• ~> Toyota Production System
• ~> Lean Manufacturing
• ~> Total Quality Management
22 http://fluidcircle.net
23. Historia Agile
• ~1990 zalążki Scrum na bazie TPS/Lean
• 1993 pierwszy Scrum w Easel Corp.
• 1995 Jeff Sutherland i Ken Schwaber
prezentują Scrum na konferencji OOPSLA
• 11-13 lutego 2001 Agile Manifesto
powstaje na spotkaniu w Snowbird w USA
23 http://fluidcircle.net
24. Manifest Agile
Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze
sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:
Ludzi i interakcje nad procesy i narzędzia.
Działające programy nad obszerną dokumentację.
Współpracę z klientem nad formalne ustalenia.
Reagowanie na zmiany nad podążanie za planem.
Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.
24 http://fluidcircle.net
25. Trzy filary Scrum
Inspekcja i adaptacja
vs. przewidywanie wszystkiego z góry
Stały kontakt z klientem
vs. głuchy telefon
Samoorganizacja
vs. mikro-zarządzanie
25 http://fluidcircle.net
26. Scrum
Szkielet zespołowego procesu twórczego:
Role
Artefakty
Wydarzenia
Reguły
Praktyki techniczne do ustalenia przez zespół!
26 http://fluidcircle.net
28. Role
Product Owner
Zespół
Scrum Master
28 http://fluidcircle.net
29. Product Owner
Jest odpowiedzialny za:
• Maksymalizację wartości pracy zespołu
• Komunikowanie ogólnej wizji produktu i
wyjaśnienie wymagań
• Akceptację gotowych fragmentów
produktu
29 http://fluidcircle.net
30. Zespół
• Samoorganizujący się
• Interdyscyplinarny
• Stabilny
• Kompetentny
• 7 +/- 2
30 http://fluidcircle.net
32. Scrum Master
• Wyjaśnia i dba o przestrzeganie reguł
Scrum
• Usuwa przeszkody organizacyjne!
• Pomaga zespołowi rozwijać się
• NIE jest “szefem” zespołu
32 http://fluidcircle.net
34. Backlog Produktu
• Uporządkowana lista wymagań mających
widoczną wartość dla Klienta
• Elementy backlogu NIE zawierają pełnej
specyfikacji – są obietnicą przyszłej
rozmowy między PO a Zespołem
• Uporządkowany przez PO z
uwzględnieniem wartości biznesowej,
złożoności i ryzyka technicznego i innych
34 http://fluidcircle.net
35. Backlog Produktu
• Często złożony z User Stories
• Złożoność elementów jest oszacowana w
jednostkach względnych (punktach)
• Elementy backlogu produktu są rozbijane
na zadania podczas Planowania Sprintu
35 http://fluidcircle.net
36. Backlog Sprintu
• Zawiera plan zespołu na
zrealizowanie wybranych
wymagań z PBL
• Tworzony podczas
Planowania Sprintu
36 http://fluidcircle.net
37. Backlog Sprintu
• Oszacowany w idealnych
godzinach
• Uaktualniany na bieżąco
(np. podczas Codziennego
Scrumu)
• Pozostały czas nie zawsze
maleje!
37 http://fluidcircle.net
38. Fragment Produktu
• W pełni realizuje wymagania wybrane do
danego Sprintu zgodnie z Definicją
Gotowości (Definition of Done)
• Mógłby zostać wdrożony lub opublikowany
(ale nie zawsze musi)
• Pokazuje realne możliwości zespołu i
postępy w drodze do pełnego produktu
38 http://fluidcircle.net
40. Sprint
• W czasie sprintu zespół zamienia wybrane
na początku wymagania w gotowy do
użycia fragment produktu
• Wybrane wymagania są zamrożone; reszta
wymagań może się zmieniać
• Stałej długości (zwykle 2~4 tygodni)
• Wyznacza stały rytm prac i punktów
kontrolnych (okazji do adaptacji)
40 http://fluidcircle.net
41. Planowanie Sprintu
• Ograniczony w czasie (8h dla miesięcznego
sprintu, proporcjonalnie mniej dla
krótszego)
• Część 1: PO wyjaśnia wymagania, zespół
określa ile wymagań ze szczytu PBL bierze
do realizacji
• Część 2: Zespół planuje realizację wymagań
rozbijając wybrane wymagania na zadania
41 http://fluidcircle.net
42. Codzienny Scrum
• max 15 minut (twardy limit), na stojąco
• Zespół wymienia się informacjami między
sobą; NIE raport dla przełożonych
• Każdy członek zespołu odpowiada na trzy
pytania:
• Co skończyłeś robić?
• Co planujesz zrobić?
• Czy coś Cię spowalnia?
42 http://fluidcircle.net
43. Przegląd Sprintu
• Zespół prezentuje wyniki swoich prac
• PO akceptuje lub odrzuca realizację
poszczególnych elementów PBL
• Nie w pełni zrealizowane wymagania
wracają do PBL – nie ma dokańczania w
międzyczasie!
• Po obejrzeniu gotowego fragmentu
43 http://fluidcircle.net
44. Retrospekcja
• Okazja dla zespołu do identyfikacji
przeszkód i ulepszenia procesu
wytwórczego
• BEZ indywidualnej oceny uczestników – na
potrzeby retrospekcji zakładamy, że każdy
pracował najlepiej jak mógł!
• Wspierana przez Scrum Mastera i/lub
coacha
44 http://fluidcircle.net
45. Wydarzenia Pomocnicze
• Planowanie Wydania
• Konstruowanie PBL, wstępne oszacowanie kiedy i z
jakimi funkcjonalnościami zostanie wydany produkt
• Porządkowanie Backlogu
• Rozbijanie zbyt dużych elementów i konsolidacja
małych
• Dopisywanie nowych elementów i aktualizacja starych
45 http://fluidcircle.net
46. Reguły Scrum
• Na codzienne spotkania zespołu mogą
przychodzić inni (PO, CEO, ...) ale mówić
mogą jedynie członkowie zespołu!
• Wydarzenia są ograniczone czasowo -
kończą się niezależnie od wyniku: nie
przedłużamy sprintów choćby nie wiem co!
46 http://fluidcircle.net
51. Trzy filary Scrum
Pomiar i adaptacja
vs. przewidywanie wszystkiego z góry
Współpraca z klientem
vs. głuchy telefon
Praca zespołowa
vs. mikro-zarządzanie
51 http://fluidcircle.net
52. Osobisty Scrum
Pomiar i adaptacja
Często dostarczaj małe (ale nie rozgrzebane) kawałki wartości, stale
ulepszaj jakość i trafność produktów oraz własną efektywność.
Współpraca z klientem
Zawsze wiedz kto jest Twoim odbiorcą i sprawdź, czy Twoja praca ma realną
wartość dla jej tych odbiorców! Jeśli nie to zmień podejście (lub odbiorców).
Praca zespołowa
Pielęgnuj konstruktywne relacje z innymi – pomagaj innym i korzystaj z
pomocy. Model geniusza-samotnika to fikcja.
52 http://fluidcircle.net
53. Retrospekcja
Co, z tego co się nauczyłeś było:
najciekawsze? najbardziej przydatne?
Co było niezrozumiałe?
Jak można by to lepiej wyjaśnić?
Co jeszcze można by ulepszyć:
w treści? w materiałach? w logistyce?
53 http://fluidcircle.net
54. 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
54 http://fluidcircle.net