Agile - metodyki zwinne (ver. 2014-04-29)

1. Metodyki zwinne
Wprowadzenie – manifest i zasady Agile

Metodyki zwinne
Spis treści
1. Wstęp do metodyk zwinnych – manifest i zasady Agile
2. Dostarczanie oparte na wartości – ocena, planowanie,
dostarczanie, weryfikowanie i monitorowanie wartości
3. Zaangażowanie interesariuszy – współpraca i komunikacja,
przywództwo
4. Wydajność zespołów – co to jest, od czego zależy i jak ją
poprawiać
5. Planowanie adaptacyjne – koncepcje planowania, estymacja,
planowanie zwinne
6. Problemy – jakość, wykrywanie, zapobieganie i rozwiązywanie
problemów
7. Ciągłe doskonalenie – retrospekcje i udoskonalanie procesów
8. Opis najpopularniejszych metodyk – SCRUM
2014-04-29Łukasz Rzepecki
2

Metodyki zwinne
Projekty pracownika wiedzy
• Rewolucia przemysłowa (XVIII – XX w.) – jest źródłem
większości idei zarządzania projektami
- 3. rewolucja przemysłowa – naukowo-techniczna (formalnie trwa
do dziś): wykresy Gantt’a, WBS  PMI – PMBOK (1983 r.)
• Rewolucja informacyjna (od 2. połowy XX w.) – bazuje
na tzw. pracownikach wiedzy:
- specjaliści w danej dziedzinie
- wymagana wiedza a nie tylko umiejętności
- komunikowanie się i transfer wiedzy ważniejsze od “instrukcji”
3

Metodyki zwinne
Praca przemysłowa vs praca wiedzy
4

Metodyki zwinne
Praca przemysłowa vs praca wiedzy
Praca przemysłowa Praca wiedzy
Efekty pracy są widoczne Pracy nie widać
Praca jest ciągła i taka sama Praca jest zmienna
Nacisk na wykonywanie czynności Nacisk na tworzenie/zmienianie rzeczy
Mała decyzyjność (struktury i procedury) Częste podejmowanie różnych decyzji
Skupienie się na właściwych odpowiedziach Skupienie się na właściwych pytaniach
Zdefiniowanie zadania Zrozumienie zadania
Zarządzanie i kontrola Większa autonomia
Ważniejsza ilość Ważniejsza jakość
Sztywne standardy Innowacje
Wydajność zgodna ze standardami Ciągła nauka i doskonalenie
Pracownik kosztem Pracownik zasobem
5

Metodyki zwinne
Zarządzanie projektami wiedzy
• Próbowano stosować te same koncepcje i techniki z
pracy przemysłowej do projektów pracowników wiedzy
- Praca do wykonania często nie była tak dobrze określona jak w
branży przemysłowej
- Prowadziło to do niepowodzeń i frustracji
• W odpowiedzi powstały koncepcje zwinnych metodyk
zarządzania
• Przez lata wytworzyło się wiele różnych koncepcji –
pionierem branża informatyczna
6

Metodyki zwinne
Manifest Agile (2001 r.)
• Wytwarzając oprogramowanie i pomagając innym w tym
zakresie, odkrywamy lepsze sposoby wykonywania tej pracy.
W wyniku tych doświadczeń przedkładamy:
- Ludzie i interakcje ponad procesy i narzędzia
- Działające oprogramowanie ponad obszerną dokumentację
- Współpraca z klientem ponad formalne ustalenia
- Reagowanie na zmiany ponad podążanie za planem
• Doceniamy to, co wymieniono po prawej stronie, jednak
bardziej cenimy to, co po lewej
• Deklaracja współzależności (DOI) – poszerza manifest o
zastosowania w innych projektach niż IT
7

Metodyki zwinne
Zasady Agile
• Zadowolenie klienta poprzez szybkie dostarczanie użytecznego
oprogramowania
• Otwartość na zmiany, nawet w późnym etapie projektu
• Działające oprogramowanie dostarczane jest często (tygodnie, nie miesiące)
• Działające oprogramowanie jest głównym wskaźnikiem postępu
• Regularność (stały rytm) i ciągłość pracy
• Bliska, codzienna współpraca pomiędzy biznesem a zespołem
• Komunikacja face-to-face jest najlepszą formą komunikacji (kolokacja)
• Projekty tworzą zmotywowane jednostki, którym należy zaufać
• Ciągła uwaga na doskonałość technologiczną i dobry design
• Kluczowa jest prostota – sztuka maksymalizowania ilości pracy nie wykonanej
• Samoorganizujące się zespoły
• Regularna adaptacja do zmieniających się okoliczności
8

Metodyki zwinne
Poziom skomplikowania projektów
9
Agile
Waterfall

Metodyki zwinne
Trójkąt ograniczeń
10
4 podstawowe ograniczenia każdego projektu:
Zmieniając jeden z parametrów należy zmienić pozostałe,
w przeciwnym razie nie dotrzymamy parametru środkowego

Metodyki zwinne
Macierz kompromisów projektowych
Parametr
Ustalony
(dokładnie 1)
Optymalizowany
( dokładnie 1)
Negocjowany
(pozostałe 2)
Czas X
Budżet X
Zakres X
Jakość X
Kluczowy parametr,
nie podlegający
żadnym negocjacjom
w trakcie trwania
projektu
Np. realizując projekt
jak najszybciej,
najtaniej, jak
najwięcej prac lub
dbając o jakość.
Te dwa parametry
mogą się zmieniać o
określonych
granicach
11

Metodyki zwinne
Kiedy stosować Agile
• Klasyka Agile:
- “Ruchomy cel”, np. prace badawcze
- Nieznany/niedookreślony efekt końcowy
• Kiedy faktycznie stosować Agile:
- Cel jest znany i może być bardzo dobrze określony
- …ale wiemy, że na pewno ulegnie zmianie ;)
- Kiedy rezultat projektu jest bardzo trudny/kosztowny do
modyfikacji (vs łatwy/możliwy do zmiany po koszcie zbliżonym
do pierwotnego)
• np. budowa domu, mostu, software pudełkowy
12

Metodyki zwinne
Sukces realizacji projektów – duże/małe
13
The Standish Group: Chaos Manifesto 2013 – Think Big, Act Small
• od 1985 r.
• 50k projektów
• 60% US, 25% EU
• połowa Fortune 1000
• 20% firmy małe

Metodyki zwinne
Sukces realizacji projektów małych
14
The Standish Group: Chaos Manifesto 2013 – Think Big, Act Small
• od 1985 r.
• 50k projektów
• 60% US, 25% EU
• połowa Fortune 1000
• 20% firmy małe

Metodyki zwinne
Rodzaje metodyk zwinnych
15

Metodyki zwinne
• Extreme Programming (XP)
- Daje techniki wytwarzania oprogramowania
- Jest bardzo mało zarządzania
- Trzeba łączyć ją z metodykami zarządzania
• Lean
- Główną zasadą jest eliminacja strat – „Wartością jest to, co klient uzna za wartościowe”
- Przykładem myślenia Lean jest twierdzenie, że nie należy wykonywać wszystkich analiz na
początku, bo zajdą zmiany
- Może być stosowany na poziomie wytwarzania i organizacji
• Scrum
- Zapewnia znakomite podejście oparte na zespole
- Porządkuje (priorytetyzuje) pracę
- Potrzebuje dodatkowego podejścia na poziomie zarządzania projektem (np. DSDM Atern)
- Często łączony z XP (Scrum zapewnia zarządzanie zespołem, a XP techniki wytwarzania)
16

Metodyki zwinne
• DSDM Atern (Dynamic Systems Development Method)
- Najstarsza na świecie metodyka Agile, powstała w 1995 roku (PRINCE2
powstał w 1996!)
- Jako jedyna w pełni opisuje zarządzanie projektami Agile
- Jest w ciągłym rozwoju, a DSDM Atern jest jej najnowszą wersją
• Agile Project Management
- Na początku projektu tworzony jest plan wysokiego poziomu oparty o zarys
wymagań i rozwiązanie widziane „z lotu ptaka”
- Projekt jest realizowany w sposób iteracyjny i przyrostowy
- Kolejny przyrost jest budowany w oparciu o produkt wytworzony w
poprzedniej iteracji
- Szczegółowy plan każdego kroku jest tworzony przez zespół, a nie
Kierownika Projektu
17

Metodyki zwinne
Metodyki zwinne i ich zasady
• SCRUM – Transparency, Inspection, Adaptation
• Extreme Programming (XP) – Simplicity, Communication,
Feedback, Courage, Respect
• Lean Software Development – Eliminate waste, Empower the
team, Deliver fast, Optimize the whole, Build quality in, Defer
decisions, Amplify learning
• Kanban Development – Visualize the workflow, Limit WIP,
Manage flow, Make process policies explicit, Improve
collaboratively
• Dynamic Systems Development Method (DSDM)
• Crystal
• Lean Startup
18

2. Dostarczanie oparte na wartości
Ocena, planowanie, dostarczanie i weryfikowanie

Metodyki zwinne
Dostarczanie oparte na wartości
• Value-Driven Delivery – to kluczowy komponent każdej
metodyki zwinnej
• Powodem realizacji każdego projektu jest wygenerowanie
jakiejś wartości biznesowej
• Ryzyka projektowe (zagrożenia), to anty-wartości
• Maksymalizacja wartości wymaga redukcji ryzyka
• Szybkie dostarczanie wartościowych elementów:
- eliminuje ryzyko porażki
- buduje zaufanie sponsora projektu (udowadnia możliwość realizacji
projektu)
- angażuje zespół
20

Metodyki zwinne
Tematyka
• Ocena wartości
• Planowanie wartości
• Dostarczanie wartości
• Weryfikowanie wartości
• Śledzenie i raportowanie wartości
21

Metodyki zwinne
Ocena wartości
• Projekty biznesowe najlepiej oceniać za pomocą
narzędzi finansowych, takich jak:
- ROI – zwrot z inwestycji
- NPV – bierząca wartość netto
- IRR – wewnętrzna stopa zwrotu
• W niektórych przypadkach, gdy projekt nie generuje
bezpośrednio przychodów, można oszacować koszty
nie zrealizowania projektu
• W ostateczności projekt można uznać za niezbędny i
nie szacować jego wartości
23

Metodyki zwinne
Wskaźniki finansowe
• Zwrot z inwestycji (ROI)
- ROI = 0, gdy przychody z projektu pokrywają jego koszty
- To suma wygenerowanych przychodów minus koszty (należy
uwzględnić infalcję i ew. koszty oprocentowania pożyczek)
• Wartość bieżąca netto (NPV)
- Wartość pieniądza w czasie zmienia się (pieniądze w przyszłości
będą mniej warte niż obecnie)
- NPV określa aktualną wartość przyszłych przychodów
- Pozwala określić bliższy prawdzie czas zwrotu i wartość inwestycji
• Wewnętrzna stopa zwrotu (IRR)
- Oznacza stopę dyskonta, przy jakiej NPV=0
- Projekt jest opłacalny gdy IRR > oprocentowanie
24

Planowanie wartości
Straty (strumień wartości), mapa drogowa, ryzyko

Metodyki zwinne
Planowanie wartości
• Karta projektu
- Powinna zawierać odpowiedź na W5H: What, Why, Who, When,
How – z naciskiem na How
- Jak zamiany będą zatwierdzane i porządkowane w backlogu po
zatwierdzeniu?
- Mniejsze znaczenie ma co będzie wykonane, bardziej jak
• Mapowanie strumienia wartości
- Ilustruje przepływ informacji wymaganych do zrealizowania procesu
- Pomaga ustalić miejsca strat – marnowania czasu i opóźnień
- Efektywność procesu = czas przynoszący realną wartość / łączny
czas pracy w danym procesie
26

Metodyki zwinne
Mapowanie strumienia wartości
27

Metodyki zwinne
Straty - rodzaje
• Częściowo wykonana praca
• Dodatkowy proces
• Dodatkowe funkcjonalności
• Przełączanie sie między zadaniami
• Oczekiwanie
• Ruch
• Wady
28

Metodyki zwinne
Straty – typowe w IT
• Kod oczekujący na testy
• Wymagania czekające na implementację
• Tworzenie nigdy nie używanej dokumentacji
• Nadmiarowe, niepotrzebne akceptacje
• “Wodotryski” i zbędne features w kodzie
• Technologiczne nice-to-haves
• Praca przy wielu projektach równocześnie (switching)
• Czekanie na ocenę/przegląd prototypów/dokumentów
• Czekanie na zatwierdzenie dokumentów
• Komunikacja przy zespołach rozproszonych
• Błędy w specyfikacji wymagań wymagające naprawy
• Wady w oprogramowaniu
29

Metodyki zwinne
Porządkowanie wg wartości dla klienta
• Aby projekt przynosił jak najszybciej wartość dla klienta niezbędne jest
poznanie co to dla niego oznacza – zaangażowanie klienta
• Każda metodyka zwinna ma swój odpowiednik, np.:
- Scrum – product backlog
- FDD – feature list
- DSDM – prioritized requirements list
• Modele porządkowania:
- Priorytet wysoki/średni/niski – mało efektywne
- MoSCoW – Must/Schould/Could have, Would like to have but not…
- Monopoly Money – rozdział budżetu na wymagania przez sponsora
- Metoda 100 punktów – każdy interesariusz ma dowolność w głosach
- Analiza Kano – Exciters/Satisfiers/Dissatisfiers/Indifferent
- Model porządkowania wymagań – ocena 1-9 korzyści z posiadania danej funkcjonalności,
straty za jej nie posiadanie (klient) oraz kosztu i ryzyka (zespół), następnie wg ustalonych
wag porządkuje się wymagania
30

Metodyki zwinne
Lista rankingowa
• Bardzo prosta ale skuteczna metoda sortowania wymagań wg
kolejności oznaczającej wartość dla klienta
- Eliminuje stratę czasu na zastanawianie się nad porządkowaniem
• Lista może określać po których wymaganiach następuje wydanie
oraz które aktualnie się nie mieszczą w budżecie (pod kreską, na
później)
• Pomaga zarządzać zmianą, klient decyduje w którym miejscu na
liście umieścić daną zmianę
• Nowe wymagania umieszczone wyżej spychają pod kreskę nie
mieszczące się w budżecie
• Używa się jednej listy work-to-be-done bez rozdziału na źródło (tzn.
oryginalny backlog + zmiany + błędy + nowe)
31

Metodyki zwinne
Mapa drogowa projektu
• To wizualny przegląd planu wydań produktu
• Story Maps – pomagają wybrać i zgrupować
wymagania do poszczególnych wydań:
- Backbone – niezbędna funkcjonalność, która musi być
- Walking skeleton – najprostszy system, który będzie działał
- Dodatowe funkcjonalności – wszystkie pozostałe, posortowanie
wg ważności (mniej/bardziej opcjonalne)
32

Metodyki zwinne
Story Map #1
33

Metodyki zwinne
Story Map #2
34

Metodyki zwinne
Zarządzanie ryzykiem
• Ryzyko - to zdarzenie lub okoliczności które mogą się
wydarzyć i wpłynąć na projekt – ryzyka mogą być zarówno
negatywne (zagrożenia) jak i pozytywne (możliwości)
• Ryzykiem należy zarządzać i analogicznie do jak
najszybszego dostarczania wartości w projekcie należy
również jak najszybciej identyfikować i przeciwdziałać
ryzykom zagrażającym projektowi
• Wymagania mogą mieć określony poziom ryzyka – te o
wyższym ryzyku powinno się realizować wcześniej
• Backlog powinien zawierać również akcje zapobiegające
zidentyfikowanym ryzykom (poziom ryzyka można określić
jako wartość/wpływ x prawdopodobieństwo)
35

Metodyki zwinne
Zarządanie ryzykiem
36

Kontraktowanie
Modele zawierania umów na projekty zwinne

Metodyki zwinne
Kontraktowanie
• Projekty zwinne, w odróżnieniu od tradycyjnych, starają się określić
dostępne zasoby i czas oraz pozostawić elastyczną funkcjonalność,
starając się dostarczyć produkt o jak najlepszej możliwej jakości
• Idea możliwości nie dostarczenia pełnej funkcjonalności czy też braku
dokładnej wyceny całego projektu może być przez niektórych nie do
zaakceptowania
• Szczegółowy kosztorys wymaga opracowania wnikliwej analizy i
rzetelnej specyfikacji, co również jest procesem czasochłonnym i
kosztownym
• Kontrakt i tak musi zawierać metody na nieprzewidziane przypadki:
zmiany zarówno uzasadnione jak i nieprzewidziane, problemy
techniczne, możliwość niepowodzenia – w metodykach zwinnych
współpraca z klientem (zaufanie) jest ważniejsza od negocjowania
umów
38

Metodyki zwinne
Kontraktowanie
• W zwinnych metodykach ważniejsze jest skupienie się na
dostarczeniu jak najszybciej wartościowego produktu niż debaty jak
będą negocjowane zmiany i jakie tak na prawdę są kryteria
akceptacyjne
• Wymagają również od biznesu większego zaangażowania się w
trakcie poszczególnych iteracji
- Ciągłe ponowne porządkowanie wymagań
- Szacowanie wartości żądanych zmian w stosunku do pozostałej pracy
• Typy kontraktów zwinnych:
- DSDM – zapłata za spełnienie testów a nie wykonanie specyfikacji
- Pieniądze za nic, Zmiany za darmo
- Stała cena uzależniona od wyników
- Pakiety o stałej wartości
39

Metodyki zwinne
Metodyki zwinne vs klasyczne
40

Metodyki zwinne
Money for Nothing and Change for Free
• Na starcie projektu określona jest stała cena (fixed-price) za pracę do
wykonania oraz stawka za wszelkie prace dodatkowe
• Klauzula “zmiany za darmo”
- Jeśli klient jest zaangażowany, PO może porządkować backlog i dokonywać zmian, o ile
całkowita praca się nie zwiększa (wymagania o mniejszej ważności są zdejmowane lub
upraszczane)
• Klauzula “pieniądze za nic”
- Opcja wcześniejszego zakończenia kontraktu w dowolnym momencie przez klienta, kiedy
uzna, że produkt spełnia jego oczekiwania
- Klient płaci np. 20% pozostałej, niewykonanej wartości kontraktu
• Klient może korzystać z tych zapisów tylko jeśli współpracuje aktywnie z
zespołem w trakcie każdej iteracji
• Brak współpracy oznacza, że klauzule tracą ważność
- Każda zamiana będzie traktowana jak praca dodatkowa
- Klient musi zapłacić za (a dostawca wykonać) cały kontrakt
41

Metodyki zwinne
Money for Nothing and Change for Free
42

Metodyki zwinne
Stała cena uzależniona od wyników
• Kontrakt typu fixed-price, w którym obie strony dzielą się
ryzykiem – potencjalnymi zyskami i kosztami
• Ustala się różną stawkę godzinową w zależności od
szybkości zakończenia projektu:
- Wcześniej – dostawca przepracuje mniej ale po wyższej stawce
godzinowej (klient sumarycznie zapłaci mniej)
- Na czas – jak w standardowym kontrakcie
- Później – dostawca przepracuje więcej ale po niższej stawce (klient
zapłaci więcej)
• Jeśli projekt się wydłuży to obie strony tracą pieniądze i będą
niezadowolone – wykonawca przeznaczy więcej zasobów po
niższej stawce a klient musi zapłacić więcej
43

Metodyki zwinne
Pakiety o stałej cenie
• Ustalenie stałej ceny za poszczególne fragmenty projektu
• Łagodzi ryzyko niedoszacowania i przeszacowania poprzez
zawężanie zakresu pracy i kosztów do poszczególnych
modułów
• Dostawca ma prawo reestymować pozostałe pakiety, gdy
pojawiają się nowe informacje lub nowe ryzyka
• Dostawca nie musi wliczać dużego marginesu w budżecie na
ryzyko, gdyż jest ono podzielone na mniejsze pakiety
• Klient może również wprowadzać zmiany do
nierozpoczętych pakietów i ew. zmieniać priorytety lub
zakres prac
44

Monitorowanie i raportowanie
wartości
Narzędzia

Metodyki zwinne
Narzędzia
• Klasyczne harmonogramy (Gantt)
- Są skomplikowane i nieprzyjazne – nieczytelne, trudne do zmiany
- Ograniczają liczbę osób, które mają na nie wpływ
- Zwykle PM aktualizuje harmonogram sam dla siebie
- Narzucają sposób i dokładność raportowania
• Narzędzia zwinne (np. tablice zadań i Kanban)
- Nie zapewniają integralności danych i udokumentowania przebiegu
prac – ale czy to kiedykolwiek było potrzebne?
- W niektórych środowiskach niezbędne jest prowadzenie równolegle
sformalizowanej dokumentacji
- Są zrozumiałe przez wszystkich i dostępne dla wszystkich
- Ułatwiają prace grupową i wymianę informacji, są przyjazne
46

Metodyki zwinne
Limitowanie WIP
• Duże poziomy “pracy w toku” powodują szereg problemów:
- Konsumują zainwestowane pieniądze i nie przynoszą żadnych korzyści (zwrotu z
inwestycji)
- Ukrywają wąskie gardła i problemy z wydajnością (gdy wszystko jest w toku nie
wydać gdzie jest faktycznie problem – na jakim etapie pracy a wszyscy są zajęci)
- Zwiększają ryzoko konieczności wykonania dużej części pracy od nowa (np.
zmiany wpływające na dużą liczbę WIP)
• Celem metodyk zwinnych jest eliminowanie WIP
• Jedną z metod jest stosowanie tablic Kanban, które limitują ilość pracy
w projekcie na różnych etapach
• Celem jest optymizacja przepustowości w projekcie a nie
wykorzystania zasobów!
• Prawo Little – czas realizacji zadań jest proporcjonalny do rozmiaru
kolejki zadań w toku
47

Metodyki zwinne
WIP – Kanban #1
48

Metodyki zwinne
WIP – Kanban #2
49

Metodyki zwinne
Weryfikowanie wartości
• Rezultaty projektów IT są nieuchwytne, nienamacalne
• Bardzo często odbiorca informacji inaczej ją interpretuje (występuje
luka semantyczna)
- Istotne jest zidentyfikowanie luki jak najwcześniej aby wyeliminować ryzyko
wykonywania pracy od nowa
• W weryfikowaniu wartości dla klienta pomocne jest porządkowanie
co iterację pozostałych wymagań – daje to obraz co jest istotne dla
klienta i jaka wg niego jest definicja sukcesu
• Częste demonstracje wykonanych funkcjonalności są kluczowe w
projektach IT
- Dopiero wtedy pojawiają się prawdziwe wymagania: IKIWISI
(I’ll Know It When I See It)
- Eliminują lukę semantyczną
50

Metodyki zwinne
Model luk wg ParasuramanaModel luk wg Parasuramana
51

Metodyki zwinne
Analiza luk jakości
Analiza luk jakości – przykład dla fi rmy
opracowującej projekty
52
Jaka jest luka jakości gdy
specyfikacja powstaje wiele
miesięcy przed realizacją
projektu i/lub tworzy ją
wręcz inny podmiot niż
wykonawca (np. SIWZ)?

Metodyki zwinne
Prawo Little’a
53

Metodyki zwinne
Wartość wypracowana (Earned Value)
• Krzywa-S – pokazuje wydatki w projekcie (np. nakład pracy
w czasie) ale nie postęp wykonania projektu
• Wykres Gantta pokazuje postęp w harmonogramie ale nie
stopień wykorzystania budżetu
• Wartość wypracowana (EV) – zaakceptowane prace
- Umożliwia porównanie bieżącej wydajności (zrealizowanej pracy)
do zaplanowanej, w określonym punkcie czasu
- Kluczowa jest jakość wstępnego planu (wartość wymagań)
- Uwaga! W projektach zwinnych plany się zmieniają i utrudniają
wykorzystanie metody EV do weryfikowania wydajności pracy ale
jest to dobre narzędzie do wizualizacji i prognozowania
54

Metodyki zwinne
Earned Value
55

Metodyki zwinne
Wykres skumulowanych przepływów
(CFD)
• Wykres warstwowy pokazujący na jednym wykresie
całkowitą pracę w projekcie, na którą składają się:
- Praca pozostała do wykonania (backlog produktu)
- Praca w toku (WIP)
- Praca zakończona (EV)
• Wykres pomaga też oszacować długość cyklu realizacji
zadań poprzez analizę wartości pracy w toku (zgodnie z
prawem Little są to wartości proporcjonalne)
56

Metodyki zwinne
CFD
57

Metodyki zwinne
Wąskie gardła i teoria ograniczeń
• Wykres CFD pracy w toku można podzielić na
poszczególne aktywności i uszeregować warstwy wg
kolejności działań
• Jeśli któryś z obszarów się rozszerza, to znaczy, że
wąskie gardło jest w warstwie poniżej
• Umożliwia to wykrycie problemu w skali całej
organizacji bez drobiazgowego analizowania każdego
obszaru
58

Metodyki zwinne
CFD – wąskie gardło
59

Metodyki zwinne
Wykres spalania ryzyka
• Na początku projektu tworzy się listę ryzyk, analogicznie do
product backloga
• Zaangażowani powinni być wszyscy interesariusze i zespół
• Dla każdego ryzyka określa się:
- Koszt jego wystąpienia (wartość finansowa lub w skali punktowej,
np. mały 1 – duży 3)
- Prawdopodobieństwo wystąpienia (procentowo lub również w skali,
np. 0-3)
- Sumarycznie każde ryzyko ma określoną wartość (np. 0-9)
• Co iterację lub ustalony okres czasu (np. miesięcznie)
dokonuje się weryfikacji ryzyk i rysuje wykres spalania
ryzyka – analogicznie jak burndown chart dla wymagań
60

Metodyki zwinne
Wykres spalania ryzyka
61

3. Zaangażowanie interesariuszy
Współpraca i komunikacja, przywództwo
Rozdział w opracowaniu

Metodyki zwinne
Interesariusze projektu
• To wszystkie osoby i grupy, na które będą miały wpływ na projekt
oraz których projekt będzie dotyczył
• W projektach pracownika wiedzy rezultaty prac są często
nienamacalne i nieuchwytne – prowadzi to do powstawania luki
semantycznej w zrozumieniu przez wykonawcę intencji klienta
• Zasady angażowania interesariuszy:
- Istotne jest zidentyfikowanie odpowiednich interesariuszy, którzy pomogą w
zrozumieniu wymagań i celów
- Zaangażowanie powinno być widoczne i monitorowane
- Aktywne zarządzanie zainteresowaniem – świętowanie postępów
- Częste dyskusje co oznacza “done” – eliminacja luki
- Eksponowanie progresu (dema) i możliwości oraz limitów zespołu
- Dyskutowanie estymat i prognoz – prawdziwa wydajność projektu
63

Metodyki zwinne
Wspólne zrozumienie
Eliminowanie luki semantycznej poprzez:
• Makiety – szybki sposób na wizualizację produktu i zrozumienie
przez wszystkich interesariuszy produktu
• Personas – przykładowi interesariusze projektu, np. różni
użytkownicy (opis, wartości dla nich, zainteresowania)
• Historyjki, backlog
- Często mają formę “Jako <Rola> Chcę <Funkcjonalność> Aby <Korzyść>”
(ważne kto i dlaczego) lub Given, When, Then
- Powinny być INVEST, tzn. Independent, Negotiable, Valuable, Estimatable,
Small, Testable
- Obejmują Pionowy zakres funkcjonalny
- Mogą być grupowane pionowo w Features a te w Epics jak również
poziomo w Themes oraz planowane w Story Maps
64

Metodyki zwinne
Komunikacja z interesariuszami
65

Metodyki zwinne
Radiatory informacji
• Radiatory
• Burn Down, Burn Up, CFD
• Velocity
66

Metodyki zwinne
Krytyczne umiejętności miękkie
• Negocjowanie
• Aktywne słuchanie
- Wewnętrzne
- Skupione
- Globalne
• Efektywne spotkania
• Rozwiązywanie konfliktów
• Partycypacyjne metody podejmowania decyzji
67

4. Wydajność zespołów
Co to jest, od czego zależy i jak ją poprawiać

Metodyki zwinne
Tematyka
• Wydajność zespołów
- Przywództwo adaptacyjne
- Inteligencja emocjonalna
- Budowanie umocowanych i wydajnych zespołów
• Praktyka
- Codzienne standupy
- Przestrzeń pracy
- Narzędzia
- Coaching i mentoring
- Burza mózgów
- Zespoły rozproszone
69

Wydajność zespołów
Na czym polega i od czego zależy wydajność zespołów

Metodyki zwinne
Ludzie i interakcje ponad procesy i
narzędzia
• COCOMO (I, II) – popularny model estymacji
oprogramowania
• 7 czynników mających wpływ na koszt, a w nich:
- Czynniki ludzkie – 33%
- Produkt – 10%
- Procesy i narzędzia – 3%
• Wpływ czynników ludzkich jest 10x większy niż wpływ
stosowanych (lub nie) procesów i narzędzi
• Sprawny zespół jakoś sobie poradzi bez żadnych procesów i
narzędzi, najlepsze T&T nic nie poradzą w sytuacji
niedoświadczonego i niezgranego zespołu
71

Metodyki zwinne
Przywództwo adaptacyjne
Formowanie się zespołów zwykle obejmuje cykl:
• Formowanie (forming) – grupa uczy się o sobie
- Kierowanie (directing) – co jest do zrobienia, pomoc w problemach
• Burza (storming) – wewnętrzna rywalizacja w pseudozespole
- Coaching – główny cel, to rozwiązywanie konfliktów
• Normowanie (norming) – potencjalny zespół, uczy się sprawnej
współpracy ze sobą
- Wsparcie (supporting) – zespół pracuje wg własnych reguł, rola
wspierająca, egzekfowanie reguł zespołu, stawianie wysokich celów
• Sprawne działanie (performing) – zespół pracujący jak jeden,
autonomiczny, umocowany, samozarządzający i regulujący się
- Delegowanie (delegating) – lider stawia zespołowi wyzwania a nie zadania,
problemy do rozwiązania wewnętrznie przez zespół
72

Metodyki zwinne
Formowanie się zespołów
73

Metodyki zwinne
Inteligencja emocjonalna
• To zdolność do zaóważania (identyfikowania), oceny
(szacowania) i wpływania na emocje: własne, innych, grup
• Dobra metoda na elastyczne zarządzanie i przywództwo
zmiennymi zespołami
Etapy:
• Samoświadomość (self: recognize)
- Zrozumienie własnych emocji (co mnie denerwuje, frustruje, cieszy,
zadowala itp.) i umiejętność ich prawidłowej oceny
- Pewność siebie - mamy wpływ na własne emocje i na to jak na nie
reagujemy (np. czy pozwalamy aby coś nas dalej denerwowało czy
jakoś zareagujemy)
74

Metodyki zwinne
Inteligencja emocjonalna
• Samokontrola (self: regulate)
- Sumienność
- Zdolność adaptacji
- Motywacja
• Nastrój i zachowanie liderów wpływa na wszystkich innych!
• Świadomość społeczna (others: recognize)
- Empatia - rozumienie otoczenia (np. kiedy jakieś problemy mają
człokowie zespołu)
• Umiejętności społeczne (others: regulate)
- Wpływanie, inspirowanie, przewodzenie i rozwijanie innych tak aby
pomóc w ich pracy i współpracy zespołowej
75

Metodyki zwinne
Empowerment
Samo-organizujące się zespoły:
• Wykorzystanie wiedzy zespołu jak najlepiej wykonać daną pracę i
naturalnej zdolniści ludzi do rozwiązywania złożonych problemów
• Przedstawianie celów a nie zadań wraz ze sposobem ich
wykonania (to zespoł jest ekspertem)
• Pozwolenie zespołom na własną organizację codziennej pracy (w
ramach podstawowych reguł panujących w organizacji)
• Delegowanie odpowiedzialności za sukces projektu na zespół w
celu osiągnięcia założonych celów (downward serving)
• Celem lidera jest ochrona przed czynnikami zewnętrznymi,
eliminowanie przeszkód, komunikowanie wizji, wsparcie…
76

Metodyki zwinne
Empowerment
Samo-zarządzające się zespoły:
• Zespół wytwarza wewnętrzne normy i podejmuje lokalne
decyzje (technologia, priorytety, estymacje)
• Zespól ma duża dowolność – ale w granicach sprintu!
• Złe decyzje (np. technologiczne, złe estymaty) są
dyskutowane na retrospekcji w celu zapobiegnięcia
podobnym sytuacjom w przyszłych sprintach
• Samoorganizacja i samozarządzanie to tylko cele!
• Na początku projektu żaden zespół taki nie jest, może to być
długoterminowym celem zespołu postawionym w fazie
normowania się zespołu.
77

Metodyki zwinne
Budowanie wydajnych zespołów
• Zespół powinien być niewielki (do 12 osób) co ułatwia
budowanie wzajemnych relacji i bezpośrednią komunikację
• Członkowie zespołu powinni mieć komplementarne
umiejętności i rozpowszechniać je w zespole (umożliwienie
zamiany ról, wykonywanie różnych zadań)
• Cele członków zespołu powinny być spójne (zrównane) z
celami projektu
- Indywidualne zobowiązanie do osiągnięcia wspólnego celu
- Świadomość każdego jak cele postawione grupie będą mierzalne i
w jaki sposób będą realizowane przez zespół
- Wzajemna odpowiedzialność członków zespołu za rezultaty
78

Metodyki zwinne
Motywowanie zespołów
• Wynagrodzenie jest za pojawianie się w pracy
• Produktywność w pracy każdego jest inna i zależy w
istotnym stopniu od zmotywowania i zaangażowania
• Etapy produktywności:
- Podważanie i opór (-)
- Pasywna zgodność (0)
- Aktywne uczestnictwo (+)
- Oddanie i poświęcenie (++)
- Pasja i wprowadzanie innowacji (+++)
• Kluczowe jest zrównanie celów indywidualnych członków
zespołu z celami projektu
79

Metodyki zwinne
Wspólne cele
80

Metodyki zwinne
Motywowanie zespołów
• Zrozumienie zarówno osobistych czynników motywujących (i
demotywujących) poszczególne osoby jak i cały zespół (np.
poprzez rozmowy 1-1)
• W większości projektów jest możliwość zaspokojenia
niektórych celów osobistych, choćby tymczasowo
• Wyjaśnienie przez kogoś z wysokiego szczebla organizacji
dlaczego projekt jest ważny dla firmy, jakie są związane z
nim nadzieje (wizja) istotnie może wpłynąć na
zaangażowanie
• Istotne jest świętowanie sukcesów zespołów
• Ew. nagrody dla całych zespołów a nie indywidualne
81

Praktyka
W jaki sposób funkcjonują wydajne zespoły

Metodyki zwinne
Codzienne stand-upy
• To kluczowy element w praktykach zwinnych
• Krótkie (max. 10-15 min.) codzienne spotkanie mające na
celu wyeliminowanie konieczności innych spotkań
• To spotkania zespołu dla zespołu (nie dla kierownictwa)
• Każdy członek zespołu po kolei odpowiada na 3 pytania:
- Co zrobiłem od poprzedniego spotkania?
- Co planuję zakończyć dzisiaj?
- Czy są jakieś blokady lub zależności utrudniające pracę?
• Wszelkie rozpoczynające się dyskusję (np. jak coś
rozwiązać, sprawy techniczne) należy odłożyc na bok (np.
indywidualna rozmowa zaangażowanych osób po stand-
upie)
83

Metodyki zwinne
Coaching i mentoring
• Pomaga zespołom utrzymać kierunek działań,
przezwyciężać problemy i ciągle polepszać
umiejętności
• Powinien być realizowany równolegle indywidualne i z
całym zespołem
• Coaching zespołowy ma miejsce głównie na granicach
sprintu (planowanie, przegląd/demo, retrospekcja)
• Coaching indywidualny głównie w trakcie sprintu
- Spotkania 1-1 umożliwiające prywatną rozmowę na temat ew.
problemów i skarg – szczere z pozytywnym nastawieniem i
poszanowaniem do zgłaszanych uwag
84

Metodyki zwinne
Coaching i mentoring
Pomocne działania:
• Spotkanie się w pół drogi – nie naciskać do osiągnięcia
bezpośrednio punktu końcowego (“bo tak ma być”) ale
wymyślać rozwiązania pośrednie
• Zagwarantowanie poufności – poprzez jej dochowanie
• Współpraca z innymi lidierami – mająca na celu
rozwiązywanie problemów między zespołami i spójną
komunikację w organizacji
• Pozytywne traktowanie – nawet jeśli kogoś nie lubimy
należy to odłożyć na bok aby pomóc danej osobie
85

Metodyki zwinne
Burza mózgów
Pomagają zidentyfikowac różne możliwości, rozwiązywać
problemy, znajdywać drogi do ulepszeń:
• Quiet writing – każdy członek zespołu w określonym czasie
spisuje pomysły indywidualne, eliminuje wpływ i
oddziaływanie innych
• Round-Robin – każdy po kolei zgłasza pomysł, zesół musi
być komfortowy z dzieleniem się pomysłami przed sobą
• Free-for-All – każdy kto chce zgłasza spontanicznie nowy
pomysł, stymuluje dyskusję, zespołowe wetowanie i
rozwijanie pomysłów
86

Metodyki zwinne
Burza mózgów
Pomysły należy następnie uporządkować:
• MoSCoW – technika oparta o wartość:
- Must have
- Should have
- Could have
- Would like to have, but not this time
• Głosowanie – każdy dostaje określoną liczbę głosów (dla
każdego w wysokości ok. 20% z liczby pomysłów) i
przydziela pomysłom głosy wg własnego uznania (można
przydzielić więcej niż 1 głos dla danego pomysłu)
87

Metodyki zwinne
Przestrzeń pracy
• Metodyki zwinne rekomendują interakcje face-to-face oraz
kolokowanie całych zespołów we wspólnym miejscu pracy,
co poprawia pracę grupową i dzielenie się informacjami
• Caves and common – otwarta przestrzeń pracy oraz
miejsca na prywatne rozmowy lub tymczasową pracę w
odizolowaniu umożliwiającą skupienie się i koncentrację
• Komunikacja osmotyczna – to użyteczne informacje
przepływające mimowolnie między członkami zespołu
podczas zwykłych konwersacji
• Milcząca wiedza (tacit knowledge) – niepisana wiedza ale
funkcjonująca w zespole/firmie (na głośno zadane pytanie
ktoś z otoczenia prawdopodobnie będzie znał odpowiedź)
88

Metodyki zwinne
Zespoły rozproszone
• To standard, nie wyjątek (ok. połowa zespołów zwinnych jest
rozproszona – tzn. przynajmniej 1 osoba pracuje zdalnie)
• Niezbędne znalezienie substytutów dla korzyści z
współpracy face-to-face, komunikacji osmotycznej i milczącej
wiedzy oraz lepszych relacji w zespole
• Wykorzystanie narzędzi komunikacji on-line
• Przynajmniej pierwsze spotkanie powinno obejmować cały
zespół
• Problem - osoby poza zasięgiem wzroku łatwiej ignorować,
mają mniejszy wpływ i poważanie
89

Metodyki zwinne
Narzędzia
• Low-Tech, High-Touch
- Wykorzystanie realnych namacalnych i prostych przedmiotów
polepsza komunikację i pracę grupową
- Niechęć do korzystania ze skomplikowanych narzędzi
- Najczęściej wykorzystywane: tablica z zadaniami (to do, doing,
accepted), user stories zapisane na karteczkach, karty do
planning pokera
• Narzędzia on-line
- Pomocne przy pracy w zespołach rozproszonych
- Np. wirtualna tablica, strony wiki, webowe systemy zarządzania
90

5. Planowanie adaptacyjne
Koncepcje planowania, estymacja, planowanie zwinne

Metodyki zwinne
Tematyka – narzędzia i techniki
• Koncepcje planowania
- Timeboxing
- Stopniowe doprecyzowanie
- Proces na miarę
- Minimalna funkcjonalność nadająca się do sprzedaży (MMF)
• Estymacja
- Wideband Delphi, Planning Poker
- Czas idealny
- Szacowanie porównawcze, Story Points
- Estymacja przez podobieństwo
• Planowanie zwinne
- Planowanie iteracji i wydań
92

Metodyki zwinne
Tematyka – wiedza i umiejętności
• Koncepcje planowania
- Analiza oparta o wartość
- Dekompozycja i porządkowanie oparte o wartość
- Gry Agile
• Estymacja
- Szacowanie czasu, budżetu i kosztów
- Zasady kosztorysowania
• Planowanie zwinne
- Karta projektu
93

Koncepcje planowania
Timeboxing, analiza oparta o wartość, gry Agile

Metodyki zwinne
“Mapa nie jest terytorium” (A.
Korzybski)
• Celem metod zwinnych jest eliminacja pracy nie
przynoszącej bezpośrednio wartości biznesowej
• Planowanie z tego punktu widzenia jest trwonieniem
czasu (waste – odpad)
• Celem każdej metodyki jest eliminacja odpadów
• Z punktu widzenia wydajności najlepiej byłoby zaplanować
projekt w całości raz i do tematu nie wracać
• Jest to nieefektywne dla projektów angażujących w
większości tzw. pracowników wiedzy (knowledge worker)
• Powinno się zaplanować replanning i zaakceptować, że
wstępny plan na pewno będzie zawierał wady
95

Metodyki zwinne
Timeboxing
• Dzielenie czasu pracy na krótkie etapy o stałej długości
• Zespół bierze do wykonania w iteracji tyle pracy ile uważa, że będzie
w stanie wykonać (zwykle na 2 tygodnie)
• Niewykonana praca wraca na koniec iteracji do backloga
• Pomaga w ocenie rezultatów, zbierania informacji zwrotnych,
kontrolowaniu kosztów i ryzyka
• Architectural spike – okres czasu dedykowany na PoC
• Narzędzie służące motywowaniu i skupieniu się na zakańczaniu pracy
• Ludzie mają skłonność do rozpraszania się i wykonywania wielu
rzeczy naraz nieefektywnie – analogicznie w projektach
• Pomaga walczyć z prawem Parkinsona (praca zajmie cały
przydzielony czas) i syndromem studenta (praca na deadline)
96

Metodyki zwinne
Stopniowe doprecyzownie (progressive
elabor.)
• Proces uszczegółowania gdy pojawiają się nowe
informacje i detale
• Na początku projektu planuje i estymuje się wstępnie
pracę do wykonania
• Szczegółowo planuje się tylko najbliższe iterację,
kolejne zawierają coraz mniej detali
• Poziom czasu poświęconego na fazy projektu:
- Wstępne planowanie – 10-15%
- Wydanie wersji (iteracje) – 80-85%
- Zamknięcie – 5%
97

Metodyki zwinne
Dopasowanie procesu (process
tailoring)
• Ma na celu indywidualne dopasowanie procesów do
aktualnej sytuacji w projekcie i w organizacji
• Zmiany następują w efekcie retrospekcji w projekcie
• Spotkanie na koniec iteracji z zespołem i biznesem mające
na celu odpowiedź na 3 pytania:
- Co idzie dobrze?
- Które obszary wymagają ulepszenia?
- Co powinno być realizowane w inny sposób?
• Problemy są rozwiązywane poprzez burzę mózgów
• Rozwiązania są testowane i analizowane przez kilka iteracji
a następnie wdrażane na stałe lub zmieniane
98

Metodyki zwinne
Minimally Marketable Feature (MMF)
• Każde wydanie oprogramowania powinno być sensowne,
użyteczne i wartościowe dla klienta
• MMF oznacza rozwiązanie kompletne na tyle aby było
użyteczne dla klientów/użytkowników ale na tyle małe, że nie
reprezentuje całego projektu
• Udostępnia biznesowi korzyści zanim cały projekt będzie
gotowy
• Umożliwia szybszy zwrot z inwestycji podczas gdy zespół
kontynuuje rozwijanie kolejnych funkcjonalności
• Np. ołówek: MMF – pozostawia ślad na papierze, dodatkowa
funkcjonalność – gumka do mazania itp.
99

Metodyki zwinne
Analiza oparta o wartość
• Na każdym etapie projektu zadajemy pytania:
- Jaka jest wartość biznesowa danej funkcjonalności?
- Które funkcjonalności mają najwyższą wartość biznesową?
• Następnie porządkujemy pracę tak aby dostarczyć w
pierwszej kolejności funkcjonalności o najwyższej wartości
biznesowej
• Należy wziąść pod uwagę również koszt ich wytworzenia
(element o wartości 5 ale kosztujący 4 ma niższą wartość
biznesową od elementu o wartości 3 kosztującego 1)
• Uwaga na zależności – realizacja zadań o niskiej wartości
może być niezbędna, żeby zrealizować te o wyższej
100

Metodyki zwinne
Dekompozycja i porządk. oparte o
wartość
• To proces wydobywania wymagań od biznesu,
porządkowania oraz włączania w proces produkcyjny
• Kick off – powinien obejmować wysiłek na zdefiniowanie
wizji projektu na wysokim poziomie oraz wyrównanie wśród
wszystkich interesariuszy wspólnej misji, celów i kryteriów
sukcesu (tak samo rozumianych)
• Warsztaty – mają na celu wyodrębnienie z wizji
potencjalnych wymagań (candidate feature list)
• Lista jest następnie porządkowana wg wartości biznesowej i
ryzyk oraz poddana iteracyjnemu procesowi realizacji
• Następuje dalsze stopniowe doprecyzowanie wymagań
101

Metodyki zwinne
Dekompozycja i porządk. oparte o
wartość
• W metodykach zwinnych nie doprecyzowuje się dokładnie
wymagań z góry, są “gruboziarniste” – doprecyzowanie
następuje w trakcie postępu projektu
• Pomaga to utrzymać projekt zbalansowany, bez
nadmiernego (niepotrzebnego) wykonania w niektórych
obszarach
• Opóźnia się decyzje o detalach implementacji do ostatniej
chwili (last responsible moment) – nie wykonuje się
funkcjonalności, które mogą (prawie na pewno) się zmienić
w wyniku nowych informacji lub zmian
• Zmiany wprowadzane wcześniej kosztują mniej
102

Metodyki zwinne
Gry Agile
Remember the Future
• Badania wykazały, że jest istotna różnica gdy poprosi się o
odpowiedź na pytanie “Co system powinien robić?” (zwykle
następuje generowanie kompletnej listy potencjalnie
niepotrzebnych funkcjonalności) od poproszenia o
wyobrażenie sobie punktu w przyszłości – po releasie
zakończonym z sukcesem – i “przypomnienie sobie” co
zostało wykonane w ramach projektu
• Każdy interesariusz przez 20 minut spisuje na karteczkach
wymagania, dzieki którym udało się zrealizowac projekt
• Kolejne 20 minut wspólnie grupują i wyjaśniają sobie
wymagania oraz eliminują duplikaty
103

Metodyki zwinne
Gry Agile
Prune the Product Tree
• Gra pomaga w zrozumieniu porządkowania i zdefiniowania
kolejności prac
• Wykorzystanie burzy mózgów w celu narysowania drzewa
wymagań i funkcjonalności oraz zależności
• Pień reprezentuje to co wiemy lub zostało już wykonane
• Gałęzie to nowe funkcjonalności lub wymagające
zaprojektowania
• Wymagania zależne umieszcza się dalej na gałęzi lub wyżej
drzewa
104

Metodyki zwinne
Gry Agile
Speedboat
• Gra pomaga w wyodrębnieniu ryzyk i możliwości
• Niektórzy potrzebują możliwości i sposobu na
wyartykułowanie swoich wątpliwości przed
przystąpieniem do pracy
• Kiedy ich obawy zostaną zaóważone i “zapisane” będą
mogli z mniejszym obciążeniem przystąpić do dalszej
pracy i lepiej współpracować
105

Metodyki zwinne
Gry Agile
106

Metodyki zwinne
Estymacja
• Jest niezbędna do szacowania rozmiaru i akceptowania
projektów, ustalania pracy możliwej do wykonania w
ramach wydania bądź iteracji, wyliczeń ROI/IRR/NPV
• Powinna być określana jako przedziały uwzględniające
niepewność
• Wstępne szacunki są najmniej dokładne, należy
reestymować projekt (czas i koszt) cały czas w jego
trakcie
• Nie powinna się tym zajmować tylko 1 osoba lecz cały
zespół, który jest/będzie zaangażowany w pracę
108

Metodyki zwinne
Wideband Delphi
• Metoda iteracyjna, adaptacyjna oparta o zespół ekspertów
• Każdy członek zespołu estymuje anonimowo
- Eliminacja skłonności do zgadzania się z liderem i przyjmowania opinii innych zamiast własnych
ocen danego problemu
• Sesja zaczyna się od podziału całego projektu na fragmenty (estymowane osobno),
specyfikuje się problem, przyjmuje założenia i ograniczenia projektu (w tym minimalne)
• Definiuje się wspólne jednostki estymacji i kryteria zakończenia procesu wyceny (np.
różnice w wycenach max. +/- 20%)
• Iteracja zaczyna się od dyskusji nt. złożoności problemu
• Każdy na kartce zapisuje zadania i ich estymaty wg uznania
• Na koniec iteracji sumy estymat są zapisywane na tablicy (bez wskazywania autorów)
• Jeśli są zbyt duże różnice robi się kolejną iterację
• Na koniec tworzy się wspólną główną listę zadań z wszystkich
109

Metodyki zwinne
Planning Poker
• Rozwinięcie poprzedniej metody
• Oparta na kartach z wartościami (często liczby
Fibonacciego: 1, 2, 3, 5, 8, 13, 21, 34) wyrażającymi
czasochłonność mh/md lub inne jednostki np. Story Points
• Wymagania są czytane kolejno i każdy jednocześnie głosuje
• Przyjmuje się wycenę większości, drobne różnice się pomija,
jeśli ktoś miał zdecydowanie odmienne zdanie jest
dyskutowane a głosowanie jest powtarzane aż do
osiągnięcia konsensusu przez zespół
110

Metodyki zwinne
Czas idealny
• Zwykle praca w ciągu dnia jest rozpraszana i
przerywana przez inne aktywności, nie związane
bezpośrednio z wykonaniem zadania (spotkania, e-
maile, kawa itp.)
• Szacowanie wg czasu idealnego zakłada pominięcie
wszelkich rozpraszających czynników, tzn. pracę
skupioną wyłącznie nad danym zadaniem i przy
założeniu, że nie ma żadnych innych przeszkód do jego
wykonania
111

Metodyki zwinne
Szacowanie porównawcze, Story Points
• Pomaga rozwiązać problem ludzi z dokładnym szacowaniem
całkowitego czasu pracy jak również zwalczyć niechęć do
skomplikowanego procesu wycen
• Łatwiej jest opisywać zjawiska przez porównanie do innych
znanych (np. coś jest 2x większe od…) niż określać je dokładnie
• Bazuje na pracy już wykonanej przez zespół w projekcie
(porównanie do estymat zakończonych zadań)
• Pozwala łatwiej pogodzić się z niewłaściwymi estymacjami (jeśli
wycena nie była w godzinach to przekroczony czas pracy nie
informuje wprost, że estymacja była błędna)
• Zmiana wyceny może nastąpić zawsze gdy tak uzna zespół, w
szczególności gdy pojawiają się nowe informacje
112

Metodyki zwinne
Szacowanie porównawcze, Story Points
• Definicja SP wychodzi z zespołu projektowego, to on ustala
co oznacza 1SP (np. stworzenie prostego ekranu aplikacji
lub 1 dzień idealny), SP między zespołami i w różnych
projektach mogą oznaczać co innego
• Estymaty w SP powinny być all-inclusive (zawierać testy,
refactoring itp.), nie powinno wprowadzać się mnożników
• Suma estymat szczegółowych zadań/wymagań może się
różnić od wstępnej ogólnej wyceny wymagania/wydania
• Estymaty w SP powinny być relatywne (4x5SP = 20x1SP) a
nie określać stopnia skomplikowania
• Powinno się brac pod uwagę 3 aspekty: złożoność problemu,
wymagany nakład pracy oraz ryzyko
113

Metodyki zwinne
Estymacja przez podobieństwo (affinity est.)
• Proces grupowania wymagań w kategorie/kolekcje, np. wg
ich estymat
• Daje możliwość łątwiejszego porównania czy w danej
kategorii wymagania są faktycznie o porównywalnej
wielkości
• Można do tego wykorzystać tablicę podzieloną na pionowe
kolumny, z których każda określa estymację lub jakiś
przedział
• Po wycenie nowego wymagania lub rewycenie porównuje się
czy jego wielkość faktycznie wydaje się być podobna do
innych w danej kolumnie – możliwość dyskusji
114

Metodyki zwinne
Szacowanie czasu, budżetu i kosztów
• Określenie rozmiaru projektu – np. Planning Poker, w czasie
idealnym lub innych jednostkach (SP)
• Skalkulowanie wymaganego nakładu pracy w
godzinach/dniach/tygodniach/miesiącach roboczych –
wymaga przeliczenia estymat z uwzgl. dostępności zasobów
(w tym – określenie stosunku godzina robocza/idealna dla
każdego z członków zespołu)
• Zaplanowanie harmonogramu z uwzględnieniem
wymaganych dni roboczych i rozmiaru zespołu
• Wyliczenie kosztu projektu wg stawek wynagrodzeń oraz
innych kosztów + rezerwa na ryzyko i niepewność
115

Metodyki zwinne
Zasady kosztorysowania
• Do określenia kosztu projektu należy wyliczyć koszt każdego
z członków zespołu – np. roczne wynagrodzenie (koszt) /
liczba tygodni w roku (52)
• Do kosztu należy doliczyć inne obciążenia firmy (czynsz,
sprzęt, administracja)
• Powinno się unikać określania dokładnej ceny lecz podawać
przedziały, na różnych etapach projektów IT inne:
- Wizja – cena: 25-400% / harmonogram (czas): 60-160%
- Definicja, zakres projektu – 50-200% / 80-125%
- Specyfikacja wymagań, ident. historyjek – 66-150% / 85-115%
- Specyfikacja projektowa, gotowy backlog – 80-125% / 90-110%
- Dokładna specyfikacja, 50% wykonane – 95-105% / 98-105%
116

Planowanie zwinne
Cykl życia projektu, karta projektu, planowanie iteracji i wydań

Metodyki zwinne
Planowanie zwinne
Istotnie różni się od planowania tradycyjnego:
• Wersje testowe i demo ujawniają prawdziwe wymagania, które
wymagają replanningu
- Zamiast tworzyć szczegółowe specyfikacje lepiej zbudować prototyp aby lepiej
zrozumieć problem i wykorzystać go do dalszego planowania
• Planowanie zwinne, to większy wysiłek w trakcie projektu niż przed
jego rozpoczęciem
- Ważniejsze jest określenie ryzyk i niepewności
- Uszczegóławianie w trakcie sprzyja lepszemu dopasowaniu wraz z nowymi
informacjami
- Zwykle planowanie zajmuje sumarycznie więcej czasu od tradyc.
- Eliminuje ryzyka błędnego zaplanowania już na początku
• Normą są zmiany w trakcie realizacji projektu
- Podejście kierowanego pocisku zmierzającego do ruchomego celu
118

Metodyki zwinne
Cykl życia projektu zwinnego
119

Metodyki zwinne
Karta projektu
• To pierwszy i podstatowy dokument projektowy
• Odpowiada na 5 pytań (W5H):
- O czym jest projekt – wizja, misja, cele
- Dlaczego jest realizowany – racjonalne wyjaśnienie biznesu
- Kiedy się rozpocznie i zakończy – plan
- Kto będzie zaangażowany – lista interesariuszy
- Gdzię będzie realizowany – fizycznie i technicznie
- Jak będzie realizowany – opis podejścia, zasady realizacji
• Okeślenie przez interesariuszy celów projektu w 140 zn.
• Nie ma standardów – może to być zarówno 1 strona jak i
skomplikowany szczegółowy dokument, ważne aby był
120

Metodyki zwinne
Planowanie iteracji i wydań
• Projekty zwinne dzielą się na wydania i iteracje
• Wydanie to zbiór iteracji, których realizacja skutkuje
dostarczeniem wartościowego produktu bieznesowi/klientowi
• Wydanie może byc uzależnione od terminu (deadline, np.
targi) lub osiągnięcia określonej funkcjonalności – w
zależności od tego, z wykorzystaniem informacji o prędkości
zespołu, szacujemy co uda się zrobić w danym czasie lub
kiedy osiągniemy daną funkcjonalność
• Do planowania wydań stosuje się Story Maps – podział
najpierw wg zależności a później funkcjonalności
121

Metodyki zwinne
Planowanie iteracji i wydań
• Planowanie iteracji robi zespół wybierając wymagania o
najwyższym priorytecie, które uda się zaimplementować,
przetestować i dostarczyć na koniec iteracji
• Istotne jest określenie głównych celów do osiągnięcia na koniec
iteracji z biznesem – klientem lub Product Ownerem (w celu
właściwego doboru wymagań)
• W przypadku Scruma, PO powinien przyjść na planning
przygotowany ze świeżo uporządkowanym backlogiem
- Pierwszą połowę spotkania PO opowiada o wymaganiach, które chciałby
zrealizować a zespół zobowiązuje się do wykonania określonych wymagań
w ramach swoich możliwości
- Przez drugą połowę spotkania zespół dzieli wymagania na zadania oraz
dyskutuje jak będą realizowane – powstaje sprint backlog
- Przypisywanie zadań do osób może być później i może się zmieniać
122

6. Problemy
Jakość, zapobieganie i rozwiązywanie problemów

Wykrywanie problemów
Czas cyklu, niewykryte wady, jakość

Metodyki zwinne
Czas cyklu
• Mierzy jak długo zajmuje wykonywanie zadań (od rozpoczęcia do
akceptacji)
• Jest blisko związany z pojęciem pracy w toku (Work in progress –
WIP)
• Duża liczba WIP wiąże się z problemami:
- Oznacza inwestycję w toku, z której nie ma zwrotu
- Ukrywa wąskie gardła i maskuje problemy z wydajnością
- Zwiększa ryzyko potencjalnych zmian – duża liczba niezaakceptowanych
wymagań w toku, mogących wpływać na siebie
• Długi czas cyklu zwiększa liczbę WIP – dlatego metody zwinne
dążą do jego skracania i dzielenia pracy na fragmenty
• Czas cyklu = WIP / przepustowość
125

Metodyki zwinne
Czas cyklu
• Pojęcie to jest użyteczne do analizowania wad i napraw
• Można niezależnie monitorować czas cyklu naprawy wad
• Im dłużej wady są nienaprawione tym są kosztowniejsze
• Kluczowe jest szybkie wykrywanie problemów na jak
najwcześniejszym etapie aby zredukować ryzyko
wykonywania pracy od nowa:
- Programowanie w parach
- Continuous integration
- Test-driven development
- Partycypacja interesariuszy
- Częste demonstracje produktu (opinie od biznesu/klienta)
126

Metodyki zwinne
Niewykryte wady (escaped defects)
• To wady, które nie zostały wykryte na etapie produkcji
ani kontroli jakości i przedostały się do oprogramowania
działającego produkcyjnie, ew. wykryte przez klienta
• Są najbardziej kosztowne do naprawy
• Monitorowanie liczby takich wad pojawiających się w
poszczególnych wydaniach może pomóc w ich
eliminacji w przyszłości
127

Metodyki zwinne
Koszt zmiany
128

Metodyki zwinne
Standardy jakości
• Dotyczą tego co zespół będzie robił aby zapewnić jakość i
właściwą wartość produktu?
• Standardy mogą być spisane lub nieformalne w postaci
wymagań i wytycznych, za które zespół bierze
odpowiedzialność
• Źródła wiedzy o standardach jakości:
- Standardy formalne – spisane
- Monitorowanie, audyty
- Rozmowy i dyskusje
- Przeglądy (dema)
- Retrospekcje
129

Metodyki zwinne
Standardy jakości – praktyki
• Mierzenie jakości przez testy i akceptację biznesu/klienta
• Testy automatyczne
• Zapewnienie aby testowanie było częścią każdej iteracji
• Staranie się naprawy 90% wad w następnej iteracji
• Ujednolicenie rozumienia kryterów akceptacyjnych wśród
developerów, biznesu i ew. osób odpowiedzialnych za jakość
• Akceptacja naprawy wad nie przez developerów a biznes
• Współpraca osób wykrywających wady z developerami
mająca na celu umożliwienie powtórzenia błedu
• Monitorowanie liczby wad, rządań zmian i wyjaśnień oraz
utrzymania wskaźników w poziomach tolerancji
130

Metodyki zwinne
Przyczyny problemów
• Popełnianie błędów ludzkich
• Działania zachowawcze – zwłaszcza w przypadku wysokiej
niepewności, wykorzystanie dotychczasowej wiedzy, która
nie jest najoptymalniejsza do wykonania danego zadania
• Wynajdywanie nowych metod (narażonych na wady) zamiast
wykorzystania gotowych, sprawdzonych, re-używalnych
rozwiązań
• Przyzwyczajenie – unikanie zmian gdy są konieczne
• Brak konsekwencji we wdrażaniu nowych rozwiązań
131

Rozwiązywanie problemów
Sposoby zapobiegania i rozwiązywania problemów

Metodyki zwinne
Metody zapobiegania problemom
• Continuous Integration – zapobieganie problemom
wynikającym z częstego dołączania nowego kodu przez
różnych członków zespołu do repozytorium projektu
• Risk-Based Spike – krótkie ćwiczenie typu PoC mające na
celu przeanalizowanie sposobu rozwiązania problemu w celu
pomniejszenia ryzyka przed właściwą implementacją
• Test-Driven Development (TDD) – testy są pisane przed
kodem, wymaga zastanowienia się jak rozwiązanie będzie
testowane i jak ma działać, testy nie przejdą dopóki napisany
kod nie będzie spełniał założonych kryteriów
- Red  Green  Refactor (Red  Green  Clean)
133

Metodyki zwinne
Metody zapobiegania problemom
• Acceptance Test-Driven Dev. (ATDD) – przeniesienie testowania
z kodu na wymagania biznesowe, 4 etapy:
- Discuss – omówienie wymagań, kryteriów akceptacyjnych
- Distill – ustrukturyzowanie i wprowadzenie testów do narzędzia typu FIT
(Frmrk For Integrated Testing) lub FitNesse
- Develop – kodowanie i podpięcie kodu do testów
- Demo – końcowe testy akceptacyjne i demo produktu
• Częsta weryfikacja i walidacja – funkcjonuje na każdym poziomie
projektów zwinnych, np. programowanie w parach/code review,
testy jednostkowe, stand-upy, testy akceptacyjne, przegląd
iteracji/demo itp. – każde z tych działań ma na celu jak najszybcie
wykrycie i wyeliminowanie problemów
134

Metodyki zwinne
Rozwiązywanie problemów
3 fazy:
• Zebranie danych – mające na celu wspólny pogląd na problemy
- Timeline – zaznaczenie wydarzeń (+/-/!) na linii czasu i emocji zesp.
- Triple Nickels – 5 pomysłów x 5 iteracji w zespole na karteczkach
• Wnioski – przeanalizowanie zebranych danych, interpretacja,
zrozumienie następstw
- Burza mózgów – wygenerowanie, przefiltrowanie i posortowanie
- 5 pytań Dlaczego – dojście od ogółu do rdzenia/przyczyny problemu
- Fishbone – diagram doprecyzowujący Five whys
• Decyzje co zrobić – jasne decyzje
- Short Subjects – np. Keep/Drop/Add, Zacznij/Przestań/Więcej/Mniej
- SMART – Specific, Measurable, Attainable, Relevant, Timely
135

Metodyki zwinne
Zaangażowanie zespołu w rozw. problemów
• Zaangażowanie zespołu w rozwiązywanie problemów jest
bardzo ważne:
• Brak konieczności “sprzedaży” rozwiązania zespołowi
• Zespół jest bliżej szczegółów i może znać lepsze rozw.
• Zespół wygeneruje bardziej praktyczne rozwiązania
(uniknięcie odpowiedzi “nie da się”)
• Ludzie zapytani o pomoc lubią zastanawiać się i pracować
nad najlepszymi rozwiązaniami oraz doceniają to
• Prośba o pomoc pokazuje zaufanie a nie słabość
• Wpływa na porządany sposób zachowań w organiazcji
136

7. Ciągłe doskonalenie
Retrospekcje i udoskonalanie procesów

Metodyki zwinne
Retrospekcja
• To wydarzenie odbywające się po sprincie mające na celu
naukę i refleksję aby doskonalić metody działania i pracę
zespołową ze sprintu na sprint a nie dopiero po projekcie (jak
klasyczne lessons learned)
• Typowe spotkanie składa się z kilku etapów (czas trwania dla
sprintu 2-tygodniowego, to max. 2 godziny):
- Przygotowanie – 5%
- Zebranie informacji – 30-50%
- Wnioski – 20-30%
- Decyzje co zrobić – 15-20%
- Zamknięcie – 10-15%
138

Metodyki zwinne
Retrospekcja
Przygotowanie
• Ma na celu skoncentrowanie się na celach spotkania, wytworzenie
przyjaznej atmosfery sprzyjającej rozmowie na problematyczne
tematy, zaplanowanie tematów do dyskusji
• Pomocne narzędzia:
- Check-In – podsumowanie w 1-2 słowach przez każdego po kolei czego
oczekuje od spotkania, głównego tematu do podjęcia lub odczuć co do
retrospekcji
- Focus On / Focus Off
- ESVP – Explorers, Shoppers, Vacationers, Prisoners – anonimowa ankieta
jakie są nastroje na spotkanie i omówienie wyników
- Working agreements – praca w podgrupach nad tematyką retrospekcji
139

Metodyki zwinne
Retrospekcja
Zebranie informacji
• Stworzenie wspólnego obrazu co się wydarzyło podczas
iteracji/wydania/projektu – zebranie obserwacji, faktów, odkryć
• Narzędzia (rozdz. VI):
- Timeline
- Triplce nickels
- Color code dots
- Mad, sad, glad
- Locate strengths
- Satisfaction histogram
- Team radar
- Like to like
140

Metodyki zwinne
Retrospekcja
Wnioski
• Czas na ocenę informacji i wyciągnięcie z nich
wniosków, celem jest pomoc w zrozumieniu implikacji
odkryć i podjętych decyzji
- Burza mózgów
- Five whys
- Fishbone
- Prioritize with dots
- Identify themes
141

Metodyki zwinne
Retrospekcja
Decyzje co zrobić
• Zastanowienie się co można zmienić w kolejnych iteracjach i
co zrobić inaczej
• W tym etapie zespół identyfikuje i porządkuje działania do
podjęcia, tworzy plan ew. eksperymentów, ustala mierzalne
cele do osiągnięcia i spodziewane rezultaty
- Short subjects
- SMART goals
- Retrospective planning game
- Circle of questions
142

Metodyki zwinne
Retrospekcja
Zamknięcie
• Refleksja na temat samej retrospekcji
• Narzędzia:
- Plus/Delta – spisanie w dwóch kolumnach pomysłów co idzie
dobrze (+) i co można by zmienić (Δ) w retrospekcjach
- Helped (Pomocne), Hindered (Utrudnienia), Hypothesis
(Przypuszczenia) – rozmowa na temat samego procesu
retrospekcji, jak go poprawić w kolejnych iteracjach
- Return on Time Invested (ROTI) – czy zespół sądzi, że poświecony
czas został dobrze wykorzystany
- Uznania – wzajemne podziękowania za pomoc, wkład w
rozwiązywanie problemów itp.
143

Metodyki zwinne
Dzielenie się wiedzą
• Jest kluczowe w projektach zwinnych, w środowiskach
pracownika wiedzy
• Odbywa się na wielu poziomach – podczas dema (zespół-
klient), wiedza niepisana w środowisku f2f, poprzez
komunikację osmotyczną, na stand-upach, retrospekcjach
• Klutura organizacyjna powinna promować dzielenie się
wiedzą, odkrycia i innowacje a nie jednostki które mają dużą
wiedzę (guru) ale się nią nie dzielą (klasyczne podejście)
• Najlepszym sposobem do zachęcania do pracy grupowej,
wzajemnej pomocy i dzielenia się wiedzą jest mierzenie
efektów o poziom wyżej – tzn. nie konkretnego pracownika
ale całego zespołu, nie zespołu ale całego działu itp.
144

Metodyki zwinne
Udoskonalanie procesów
• Ma na celu lepsze dopasowanie metodologii do środowiska
projektu
• Np. Kanban zaleca modyfikowanie metodologi do własnych
potrzeb ale Scrum jest mniej elastyczny
• Niektórzy promują podejście “proces per projekt”
• Kluczowe jest doświadczenie zespołów w realizacji kilku
projektów by-the-book a dopiero później ich modyfikowanie
do własnych potrzeb
• Proste projekty o znanej technologii i dokładnej specyfikacji
wymagań wcale nie potrzebuja metodyk zwinnych! Z drugiej
strony jeśli projekt jest w stanie chaosu metodyki zwinne
również nie pomogą
145

Metodyki zwinne
• Analiza procesu
- Antywzorce:
• Jeden rozwmiar dla wszystkich projektów
• Nietolerancyjny
• Ciężki
• Upiększony
• Niewypróbowany
• Użyty raz
- Kryteria pozytywne:
• Projekt został zakończony i sprzedany
• Lider nie został zwolniony
• Zespół pracowałby ponownie w ten sam sposób
146

Metodyki zwinne
• Kryteria sukcesu
- Komunikacja face-to-face
- Nadmiar narzutu metodologii jest kosztowny – minimalizacja
produkowanej dokumentacji
- Większe zespoły wymagają cięższych metodologii
- Projekty krytyczne wymagają większych rygorów metodyki
- Informacje zwrotne i częsta komunikacja redukują potrzebę
dostarczania częstych pośrednich rezultatów
- Ważniejsza jest dyscyplina, umiejętności i zrozumienie niż procesy,
formalności i dokumentacja
- Wydajność można zwiększać tylko w środowiskach bez wąskich
gardeł
147

Metodyki zwinne
• Stosowanie nowych praktyk
- Nie stosować dopóki nie jest to niezbędne
- Czy jest jakieś inne rozwiązanie – głównego problemu?
- Czy nowe rozwiązanie faktycznie coś poprawia?
- Próbować nowe praktyki w małych dawkach (kilka iteracji)
- Analizować skutki uboczne – retrospekcje
• Proces ciągłego doskonalenia
- Analogia Plan-Develop-Evaluate-Learn do Plan-Do-Check-Act Deminga
- Iteracyjne i przyrostowe tworzenie jest formą ciągłego doskonalenia a
informacje zwrotne od klienta kierują zespół na finalne rozwiązanie
• Samoocena – nie tylko proces i produkt ale równiez zespół
wymaga oceny, jak działa i co wymaga poprawy
148

SCRUM
Zespół, zdarzenia, artefakty

Metodyki zwinne
SCRUM
• Określa ramy postępowania przy rozwiązywaniu złożonych
problemów adaptacyjnych – optymalizuje elastyczność,
kreatywność i produktywność
• Podejście iteracyjne i przyrostowe w celu zwiększenia
przewidywalności i lepszej kontroli ryzyka
• Opiera się na:
- Przejrzystości – wszystkie aspekty procesu muszą być widoczne,
jasne i jednakowo zrozumiałe przez wszystkich (np. wspólna
definicja “ukończonej” pracy – DoD)
- Inspekcji – częsta weryfikacja realiacji celów sprintu
- Adaptacji – jeśli któryś z aspektów projektu wykracza poza ramy,
należy szybko dokonać niezbędnych korekt
151

Metodyki zwinne
Zespół Scrumowy (Development Team)
• Jest samo-organizujący się i międzyfunkcjonalny
- Zespół sam decyduje jak najlepiej wykonać pracę
- Nie jest kierowany przez nikogo z zewnątrz
- Posiada wszelkie kompetencje do wykonania pracy – nie jest
zależny od osób spoza zespołu
• Dostarcza ukończone produkty iteracyjnie i przyrostowo
- Zwiększone szanse na wczesne uzyskanie informacji zwrotnej
- Nieprzerwana dostępność działającej użytecznej wersji
• Zespół Scrumowy, to:
- Product Owner – właściciel produktu
- Zespół developerski
- Scrum Master
152

Metodyki zwinne
Właściciel Produktu (Product Owner)
• To pojedyńcza osoba, nie komitet
• Może reprezentować interesy grupy osób
• Wszelkie zmiany w backlogu muszą przechodzić przez
właściciela produktu
• Cała organizacja musi respektować jego decyzje (treść i
kolejność elementów w backlogu)
• Nikt inny nie może nakazać zespołowi realizacji innych
wymagań
153

Metodyki zwinne
Właściciel Produktu (Product Owner)
• Odpowiada za maksymalizację wartości produktu i pracy
• Jest jedyną osobą zarządzającą backlogiem produktu:
- Jasne artykułowanie elementów backlogu
- Ustalanie kolejności elementów w sposób pozwalający osiągać założone
cele i misje
- Optymalizowanie wartości pracy wykonywanej przez zespół
- Zapewnianie dostępności, przejrzystości oraz że jest jasny i zrozumiały
przez wszystkich
- Dobrze opisuje to, czym zespół będzie się zajmował w dalszej kolejności
- Zapewnianie, że zespół rozumie elementy backlogu w wymaganym stopniu
• Może zlecić realizację tych zadań na zespół ale właściciel produktu
pozostaje za nie w pełni odpowiedzialny
154

Metodyki zwinne
Zespół developerski
• Złożony jest z profesjonalistów, którzy tworzą przyrost
• Jest uprawniony do samodzielnego organizowania własnej pracy i zarządzania
nią
• Nikt (nawet Scrum Master) nie może nakazać zespołowi jak przekształcać
elementy backloga w przyrosty
• Nie uznaje tytułów innych niż “developer” (np. nazwa stanowiska czy ranga
starszy/młodszy) ani podzespołów
• Mimo, że pojedyńcze osoby mogą mieć specjalizację, to odpowiedzialność za
rezultat ponosi solidarnie cały zespół
• Zespołowi nie wolno podejmować działań w oparciu o to co mówią inne osoby
niż właściciel produktu
• Idealny rozmiar, to 3-9 osób (+ PO i SM)
• Product Owner i Scrum Master mogą być członkami zespołu, jeśli
jednocześnie wykonują też pracę wynikająca z backloga
155

Metodyki zwinne
Scrum Master
• Jest odpowiedzialny za to aby Scrum był zrozumiany i był
stosowany, szczególnie gdy nie jest jeszcze w pełni przyjęty i
rozumiany w danej organizacji
• Wspiera właściciela produktu w technikach efektywnego
zarządzania backlogiem i maksymalizowania wartości
• Wspiera zespół scrumowy w rozumieniu i praktykowaniu
zwinności i empirycznego podejścia rozwoju produktu
• Wspomaga przebieg zdarzeń scrumowych – jeśli jest to
konieczne lub zostanie o to poproszony
• Coachuje zespół w zakresie samoorganizacji
• Usuwa przeszkody ograniczające postęp pracy zespołu
156

Metodyki zwinne
Zdarzenia w Scrumie
• Są okazją do inspekcji i adaptacji – niewykonanie któregoś z
nich redukuje przejrzystość i możliwość dokonania inspekcji i
adaptacji, które są filarami Scruma
• Wprowadzają regularność i ograniczają konieczność
organizowania innych spotkań
• Wszystkie zdarzenia są organiczone czasowo (timeboxing)
• Zdarzenia w Scrumie:
- Sprint
• Planowanie sprintu (Sprint Planning)
• Codzienny Scrum (Daily Scrum)
• Przegląd sprintu (Sprint Review)
• Retrospektywa sprintu (Sprint Retrospective)
157

Metodyki zwinne
Sprint
• Musi posiadać cel – opis tego co ma powstać, cel uspójnia działania zespołu
• Iteracja ograniczona czasowo do maksymalnie 1 m-ca
- Dłuższy czas wzmaga ryzyko zmiany definicji celów i zwiększa złożoność
- Inspekcja i adaptacja są regularne
• Czas trwania jest ustalany w momencie rozpoczęcia i nie może być zmieniany ale
najlepiej aby miały stałą długość przez cały projekt
• Wytwarza przyrost – ukończony, gotowy do użycia i potencjalnego wydania
• Zakres pracy może być wyjaśniany trakcie sprintu z PO
• Może również być renegocjowany z PO jeśli pojawiają się nowe informacje, np. charakter
prac okazuje się inny od zaplanowanych
• Nie można wprowadzać zmian zagrażających realizacji celów sprintu bądź obniżających
cele jakościowe
• W trakcie sprintu zespół może uczestniczyć w doskonaleniu backloga (max. 10% czasu
sprintu)
• Może być przerwany tylko przez PO np. jeśli zdezaktualizują się cele
158

Metodyki zwinne
Planowanie sprintu
• Spotkanie całego zespołu scrumowego, maksymalnie 8h dla 1-
miesięcznego sprintu
• Co może zostać zrobione w Sprincie?
- Zespół prognozuje zakres prac, które może zrealizować
- PO omawia założenia sprintu oraz elementy backloga, które temu służą
- Zespół scrumowy uzgadnia cel sprinta a zespół developerski podejmuje
zobowiązanie które elementy backloga wykona
• W jaki sposób wybrany zakres pracy zostanie zrealizowany?
- Zespół planuje w jaki sposób elementy backloga produktu zostaną
przekształcone w ukończony przyrost – tworzy projekt i zadania
- Wybrane elementy backloga produktu wraz ww. planem tworzą backlog sprintu
• Zespół może zaprosić na spotkanie inne osoby z wiedzą techniczną
lub z danej domeny
159

Metodyki zwinne
Codzienny Scrum
• Zdarzenie zespołu developerskiego (tylko), max. 15 minut, o stałym miejscu i
porze, wygodnej dla wszystkich, za którego przebieg jest odpowiedzialny sam
zespół
• Scrum Master jest jednakże odpowiedzialny za to aby zdarzenie miało miejsce
i trwało nie dłużej niż 15 minut
• Służy synchronizacji działań, ocenie postępu prac, trendów i zaplanowaniu
następnych 24 godzin (to nie tylko status)
• Każdy członek zespołu udziela pozostałym informacji:
- Co wykonał od poprzedniego spotkania aby pomóc zespołowi przybliżyć się do osiągnięcia
cel sprintu?
- Co zrobi w tym celu do następnego spotkania? (planowanie!)
- Czy widzi jakiekolwiek przeszkody w realizacji celu przez zespół?
• Po codziennym scrumie członkowie zespołu mogą szczegółowo omówić
wybrane zagadnienia i problemy
• Jest to spotkanie kluczowe dla procesu inspekcji i adaptacji
160

Metodyki zwinne
Przegląd sprintu
• Spotkanie całego zespołu scrumowego i kluczowych interesariuszy na
zakończenie sprintu, max. 4h dla 1-miesięcznego sprintu
• Celem jest inspekcja przyrostu i ew. dostosowanie backloga produktu w celu
zwiększenia dostarczanej wartości
• To spotkanie robocze a nie statusowe:
- PO wyjaśnia, które funkcjonalności uznał za ukończone
- Zespół prezentuje wykonany przyrost oraz wyjaśnia co poszło dobrze a gdzie były problemy i
jak zostały rozwiązane
- PO omawia aktualny backlog produktu
- Uczestnicy rozważają co najlepiej wykonać w następnej kolejności aby dostarczyć
maksymalną wartość
- Rewiduje się czas, budżet i wprowadza ew. zmiany do backloga
- PO dokonuje podsumowania całej pozostałej do wykonania pracy i porównuje ją ze stanem
poprzednim (ocena możliwości realizacji celów w wyznaczonym terminie, np. wykorzystując
wskaźnik prędkości pracy)
- Rezultatem jest zaktualizowany backlog produktu
161

Metodyki zwinne
Retrospektywa sprintu
• Spotkanie zespołu scrumowego, odbywające się
między przeglądem i planowaniem sprintów, max. 3h
dla 1-miesięcznego sprintu
• Ma na celu autoinspekcję własnych działań zespołu i
opracowaniu planu usprawnień na kolejny sprint:
- Sprawdzenie, co działo się w ostatnim sprincie, z
uwzględnieniem ludzi, relacji, procesów i narzędzi
- Co się sprawdziło a co wymaga usprawnienia
- Opracowanie plananu usprawnień
• np. doprecyzowanie definicji “ukończenia”
162

Metodyki zwinne
Artefakty Scruma
• Artefakty w Scrumie, to:
- Backlog produktu
- Backlog sprinta
- Przyrost – suma wszystkich ukończonych elementów backloga
produktu zgodnie z definicją DoD zespołu scrumowego
• Musi być zachowana ich pełna przejrzystość
• Są podstawą podejmowanych decyzji mających na celu
optymalizację wartości i kontrolę ryzyka
• Zadaniem Scrum Mastera jest dbanie o ich przejrzystość
- Inspekcja
- Wyłapywanie różnic między oczekiwaniami a wynikami
163

Metodyki zwinne
Backlog produktu (Product Backlog)
• Jedyne źródło wymagań: lista wszystkich cech, funkcji, wymagań, ulepszeń i korekt błędów
• Elementy zawierają: opis, kolejność, oszacowanie, wartość
• PO jest za niego odpowiedzialny ale oszacowania dokonuje wyłącznie zespół developerski
• Nigdy nie jest kompletny, ewoluuje wraz z produktem i środowiskiem, dynamicznie się zmienia
• Doskonalenie backloga (refinement) – ciągła praca zespołu scrumowego: przeglądanie i
korygowanie
- Dodawanie szczegółów, oszacowań, porządkowanie
• Istnieje tak długo jak produkt
• Jeśli nad jednym produktem pracuje kilka zespołów scrumowych, to korzystają z tego samego
backloga
• Elementy najwyżej, na najbliższy sprint, muszą być szczegółowo opisane i możliwe do realizacji
w ramach sprintu
- Statusy: Nieprzygotowane  Przygotowane (gotowe do realizacji, wystarczająco zrozumiałe i wystarczająco
małe)  Ukończone
164

Metodyki zwinne
Backlog sprintu (Sprint Backlog)
• To zbiór elementów backloga produktu wybranych do realizacji na dany sprint,
rozszerzony o:
- Plan dostarczenia przyrostu produktu
- Plan realizacji celu sprintu (praca niezbędna wg zespołu developerskiego do jego
osiągnięcia)
• Wystarczająco szczegółowy
• Jest modyfikowany przez zespół developerski w trakcie trwania sprintu (w
miarę realizacji celów i wyłaniania się nowych informacji aby je osiągnąć)
- Dodatkowa praca jest dodawana do backloga sprintu z zbędne elementy usuwane – tylko
zespół developerski może go zmieniać!
• W miarę postępu prac aktualizowane jest oszacowanie pozostałej do
wykonania pracy w sprincie (przynajmniej raz dziennie podczas codziennego
scruma)
• Na koniec sprintu nowy przyrost musi być ukończony i być przetestowany z
poprzednimi przyrostami (muszą działać razem)
165

Metodyki zwinne
Definicja ukończenia (DoD)
• Każdy musi rozumieć co oznacza ukończenie elementu
backloga produktu albo przyrostu produktu (pracy w
kolejnym sprincie)
• Zespół scrumowy musi mieć wspólne rozumienie DoD
• Celem każdego sprintu jest dostarczenie gotowej do
wydania funkcjonalności, zgodnie z aktualną definicją
ukończenia funkcjonującą w zespole scrumowym
• Konwencja, standardy i wytyczne w organizacji
stanowią minimum definicji ukończenia – jeśli ich nie
ma musi je wypracować sam zespół
166

Metodyki zwinne
Podsumowanie Scruma
• Scrum istnieje tylko w swojej pełnej postaci
• Może stanowić ramy dla innych technik, metodyk i
praktyk
167

Metodyki zwinne
SCRUM
168

Metodyki zwinne
Dziękuję
169

Agile - metodyki zwinne (ver. 2014-04-29)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Agile - metodyki zwinne (ver. 2014-04-29)

Similaire à Agile - metodyki zwinne (ver. 2014-04-29) (20)

Agile - metodyki zwinne (ver. 2014-04-29)