Wdrap si\u0119 na g\u00f3r\u0119 tylko tyle, by sprawdzi\u0107, \u017ce jest g\u00f3r\u0105. Nie zobaczysz g\u00f3ry z jej szczytu.<\/p>\n<\/blockquote>\n\n\n\n
M\u00f3wi\u0105c mniej poetycko \u2013 nasze cele s\u0105 wa\u017cne, ale droga do ich osi\u0105gni\u0119cia r\u00f3wnie\u017c. Czasami mo\u017ce si\u0119 okaza\u0107 nawet bardziej istotna od punktu docelowego.<\/p>\n\n\n\n
Zespo\u0142y wci\u0105\u017c si\u0119 zmieniaj\u0105, czasem na lepsze, czasem \u2013 niestety \u2013 na gorsze. Z czego wynika spadek wydajno\u015bci zespo\u0142\u00f3w i jak uchroni\u0107 si\u0119 przed jego skutkami? W jaki spos\u00f3b odnale\u017a\u0107 te elementy, kt\u00f3re s\u0105 przewag\u0105, atutami danego zespo\u0142u i jak je wzmocni\u0107? Tutaj z pomoc\u0105 przychodz\u0105 nam metryki. Ale metryki u\u017cywane m\u0105drze \u2013 nie jako narz\u0119dzie do wywierania presji na zesp\u00f3\u0142 czy oceniania go, ale jako spos\u00f3b na szybkie zauwa\u017canie problem\u00f3w i reagowanie na nie. Jest to szczeg\u00f3lnie wa\u017cne, je\u015bli chcemy, aby zesp\u00f3\u0142 wci\u0105\u017c si\u0119 rozwija\u0142 i d\u0105\u017cy\u0142 do samodoskonalenia.<\/p>\n\n\n\n
Na pocz\u0105tek nale\u017cy zda\u0107 sobie spraw\u0119, \u017ce metryki nie s\u0105 sobie r\u00f3wne. Mo\u017cemy je podzieli\u0107 na dwa typy: metryki mierz\u0105ce post\u0119p prac nad produktem oraz metryki mierz\u0105ce rozw\u00f3j i zwinno\u015b\u0107 zespo\u0142\u00f3w. Metryki produktowe, skupiaj\u0105ce si\u0119 na \u015bledzeniu rozwoju produktu, mog\u0105 pom\u00f3c w analizowaniu czy tworzony produkt jest odpowiednio dostosowany do potrzeb rynku. Natomiast metryki skupione na analizie zespo\u0142u, \u015bledz\u0105ce post\u0119py w jego rozwoju, pomagaj\u0105 w lepszym zrozumieniu procesu dostarczania przyrostu i optymalizacji wydajno\u015bci zespo\u0142u. <\/p>\n\n\n\n
Oba typy maj\u0105 na siebie wzajemny wp\u0142yw i fluktuacje w zakresie pomiaru zespo\u0142u maj\u0105 wp\u0142yw na wytwarzany produkt. Podobnie jak zmiany w zakresie p\u0142ynno\u015bci dostarczania przyrostu, nigdy nie pozostan\u0105 bez wp\u0142ywu na zesp\u00f3\u0142.<\/p>\n\n\n\n
Dzi\u015b kr\u00f3tko o jednych z najbardziej znanych metryk i typ\u00f3w wykres\u00f3w stosowanych w Scrum \u2013 wykresach spalania.<\/p>\n\n\n\n
Burn-down chart<\/h2>\n\n\n\n
Jest to metryka, kt\u00f3ra \u015bledzi post\u0119p prac na produktem, ale w mojej ocenie jest najbardziej przydatna w kontek\u015bcie pomiaru post\u0119pu zespo\u0142u, poniewa\u017c pokazuje jak szybko w trakcie pracy nad produktem Zesp\u00f3\u0142 Deweloperski ko\u0144czy prac\u0119 nad User Stories (US) lub nad zadaniami (w zale\u017cno\u015bci od przyj\u0119tego przez zesp\u00f3\u0142 sposobu estymacji pracy). Na osi Y wykresu zaznaczana jest ilo\u015b\u0107 pracy (mierzona np. w Story Point lub zadaniach), za\u015b na osi X przedstawiany jest czas w odniesieniu do projektu. <\/p>\n\n\n\n
Ka\u017cdy projekt musi mie\u0107 arbitralnie ustanowiony pocz\u0105tek, cz\u0119sto okre\u015blany jest tak\u017ce jego koniec oraz tzw. milestony. Projekty z nieokre\u015blonym czasem zako\u0144czenia wyst\u0119puj\u0105 niezwykle rzadko, dlatego burn-down chart jest \u015bwietnym narz\u0119dziem do \u015bledzenia post\u0119p\u00f3w i mo\u017cliwo\u015bci dostarczenia produktu w sko\u0144czonym czasie. W odniesieniu do Sprint\u00f3w wykres spalania obrazuje kilka rzeczy:<\/p>\n\n\n\n
- \n
- Ile pracy zosta\u0142o wykonane do tej pory, czyli ile Story Point’\u00f3w (SP) mamy zako\u0144czone.<\/li>\n\n\n\n
- Ile pracy powinni\u015bmy jeszcze wykona\u0107?<\/li>\n\n\n\n
- Kiedy prawdopodobnie uda si\u0119 zako\u0144czy\u0107 prace nad produktem?<\/li>\n<\/ol>\n\n\n\n
Idealny burn-down chart jest lini\u0105 prost\u0105, spadaj\u0105c\u0105 od lewej do prawej strony w kierunku 0 dla osi Y (funkcja monotoniczna malej\u0105ca). Niestety w praktyce sytuacja idealna, czyli wykres stale malej\u0105cy, jest trudna do osi\u0105gni\u0119cia. Wp\u0142yw na to maj\u0105 m. in.: zmienna pr\u0119dko\u015b\u0107 pracy zespo\u0142u, a tak\u017ce fluktuacje zakresu. <\/p>\n\n\n\n
Najistotniejsz\u0105 kwesti\u0105 jest wykorzystanie burn-down chart jako narz\u0119dzia do podparcia dyskusji na temat mo\u017cliwych usprawnie\u0144 i dostosowania pracy do wci\u0105\u017c zmieniaj\u0105cych si\u0119 wymaga\u0144 i uwarunkowa\u0144. Wykres prowadzony w granulacji Sprint\u00f3w, gdzie jednostk\u0105 czasu jest pojedynczy Sprint, pozwala na \u015bledzenie tendencji zmian zachodz\u0105cych w zakresie prac nad produktem. Z kolei wykres prowadzony dla pojedynczych Sprint\u00f3w, gdzie jednostk\u0105 czasu jest dzie\u0144, pozwala na \u015bledzenie prac zespo\u0142u.<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/1.jpg\")
<\/a><\/figure>\n\n\n\nPowy\u017cej zamieszczony przyk\u0142ad wykresu burn-down chart mo\u017cemy przeanalizowa\u0107. \u0141atwo zaobserwowa\u0107, \u017ce w dw\u00f3ch pierwszych Sprintach, zesp\u00f3\u0142 wykona\u0142 mniej pracy ni\u017c zak\u0142ada\u0142, po czym w Sprincie 3. wyprzedzi\u0142 nieznacznie harmonogram (ilo\u015b\u0107 zrealizowanych Story Point znajduje si\u0119 poni\u017cej linii prognozy teoretycznej). Wykres niestety nie dostarcza nam informacji co mog\u0142o si\u0119 wydarzy\u0107 w Sprincie 4., gdzie (teoretycznie) nie zrealizowano \u017cadnego Story Point\u2019a. R\u00f3\u017cnica rzeczywistych Story Point’\u00f3w mi\u0119dzy Sprintem 4 a 5 wynosi 0.<\/p>\n\n\n\n
Jestem zwolenniczk\u0105 prowadzenia burn-down chart dla pojedynczych Sprint\u00f3w, aby Zesp\u00f3\u0142 Deweloperski m\u00f3g\u0142 dzie\u0144 po dniu (np. w trakcie Daily) \u015bledzi\u0107 swoje post\u0119py. Pozwala to na zauwa\u017cenie, na mo\u017cliwie wczesnym etapie prac, sytuacji, w kt\u00f3rej Cel Sprintu zaczyna by\u0107 zagro\u017cony. Praca deweloperska wymaga czasu, to oczywiste, zatem wypracowane Story Point’y rzadko pojawiaj\u0105 si\u0119 na wykresie ju\u017c pierwszego dnia. Jednak, je\u015bli Definition of Done (DoD) dla User Stories jest spe\u0142niana wy\u0142\u0105cznie pod koniec Sprintu i staje si\u0119 to tendencj\u0105, to jest ewidentnie obszar, kt\u00f3ry wymaga ulepszenia. <\/p>\n\n\n\n
Rol\u0105 Scrum Mastera jest zauwa\u017canie tego trendu, mo\u017cliwych zagro\u017ce\u0144 z niego wynikaj\u0105cych i wsparcie Zespo\u0142u w ich usuni\u0119ciu. Wizualizacja post\u0119pu pracy pozwala na szybkie i \u0142atwe zauwa\u017cenie sytuacji, w kt\u00f3rej Sprint Backlog nie zostanie prze\u0142o\u017cony na przyrostu lub gdy Cel Sprintu jest zagro\u017cony. Mo\u017cliwo\u015b\u0107 dostosowania si\u0119 do konkretnych reali\u00f3w jest mo\u017cliwa jedynie wtedy, kiedy zdajemy sobie spraw\u0119 z wyst\u0119powania niedogodno\u015bci lub problem\u00f3w. <\/p>\n\n\n\n
Czasami nie uda si\u0119 zapobiec sytuacji, w kt\u00f3rej zakres Sprint Backlogu nie zostanie zrealizowany, mimo dostrze\u017cenia tych zagro\u017ce\u0144. Niemniej du\u017co lepsz\u0105 sytuacj\u0105 jest jedno uko\u0144czone w pe\u0142ni User Stories z np. trzech zaplanowanych ni\u017c trzy US w trakcie prac i zerowy przyrost na koniec Sprintu.<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/2.jpg\")
<\/a><\/figure>\n\n\n\nPowy\u017cej znajduje si\u0119 wykres burn-down dla pojedynczego Sprintu \u2013 4. z wykresu ca\u0142ego projektu. Sprint ten by\u0142 nietypowy, poniewa\u017c \u2013 w teorii \u2013 zesp\u00f3\u0142 nie uko\u0144czy\u0142 \u017cadnego Story Point. Bardziej szczeg\u00f3\u0142owa analiza pozwala na lepsze zrozumienie, co si\u0119 wydarzy\u0142o w trakcie rzeczonej iteracji. <\/p>\n\n\n\n
Z pocz\u0105tku zesp\u00f3\u0142 nie wytwarza\u0142 przyrostu, jednak pod koniec 5. dnia Sprintu wyprzedzi\u0142 w\u0142asne za\u0142o\u017cenia, co prze\u0142o\u017cy\u0142o si\u0119 na dorzucenie nowych zada\u0144 do Sprintu (zmiana scope\u2019u). Przyczyny mog\u0105 by\u0107 r\u00f3\u017cne. Jedn\u0105 z nich mo\u017ce by\u0107 dobranie przez zesp\u00f3\u0142 zbyt wielu zada\u0144 z Product Backlogu, ze wzgl\u0119du na dobry timing i w efekcie nie uko\u0144czenie pracy. Z drugiej strony – r\u00f3wnie\u017c ze wzgl\u0119du na dobre tempo pracy zespo\u0142u \u2013 mog\u0142y pojawi\u0107 si\u0119 tzw. \u201ewrzutki\u201d, czyli dodatkowe zadania narzucone na deweloper\u00f3w, kt\u00f3re nie by\u0142y brane pod uwag\u0119 podczas Planowania. <\/p>\n\n\n\n
Warto zwr\u00f3ci\u0107 uwag\u0119 na to, co zadzia\u0142o si\u0119 mi\u0119dzy 3 a 6 dniem Sprintu, kiedy nast\u0105pi\u0142 gwa\u0142towny spadek Story Point. Czy zesp\u00f3\u0142 faktycznie przy\u015bpieszy\u0142 czy ze wzgl\u0119du na zmieniaj\u0105ce si\u0119 uwarunkowania biznesowe zrezygnowano z cz\u0119\u015bci scope\u2019u? <\/p>\n\n\n\n
Niezale\u017cnie od przyczyny, rol\u0105 Scrum Mastera jest ka\u017cdorazowe reagowanie na te sytuacje, czy to poprzez uniemo\u017cliwienie dodawania nowych zada\u0144 przez osoby zewn\u0119trzne czy poprzez prac\u0119 z zespo\u0142em nad wybraniem najbardziej optymalnej \u015bcie\u017cki wykorzystania zyskanej przewagi. <\/p>\n\n\n\n
Mo\u017ce czas, kt\u00f3ry deweloperzy zyskali warto po\u015bwi\u0119ci\u0107 na likwidacj\u0119 cz\u0119\u015bci d\u0142ugu technologicznego lub refaktoryzacj\u0119? A mo\u017ce warto dobra\u0107 z Backlogu Produktu dodatkowe zadanie? Decyzja nale\u017cy oczywi\u015bcie od zespo\u0142u, jednak Scrum Master musi mie\u0107 pewno\u015b\u0107, \u017ce deweloperzy oraz Product Owner s\u0105 \u015bwiadomi konsekwencji podj\u0119tych dzia\u0142a\u0144 a zesp\u00f3\u0142 b\u0119dzie w stanie wytworzy\u0107 sko\u0144czony przyrost (spe\u0142niaj\u0105cy DoD).<\/p>\n\n\n\n
Wykres szczeg\u00f3\u0142owy dla Sprintu 4. mo\u017ce wygl\u0105da\u0107 nieco inaczej. Poni\u017cej inny przyk\u0142ad wykresu dla tego Sprintu, skutkuj\u0105cy tak\u0105 sam\u0105 adnotacj\u0105 na wykresie produktu:<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/3.jpg\")
<\/a><\/figure>\n\n\n\nW tym wypadku w dalszym ci\u0105gu ilo\u015b\u0107 Story Point, z kt\u00f3r\u0105 zesp\u00f3\u0142 zaczyna\u0142 Sprint nie zmniejszy\u0142a si\u0119, jednak przebieg prac w Sprincie jest inny ni\u017c w poprzednim przyk\u0142adzie. Jak widzimy, ju\u017c na pocz\u0105tku Sprintu zesp\u00f3\u0142 wytwarza\u0142 przyrost, p\u00f3\u017aniej jednak nie by\u0142 w stanie osi\u0105gn\u0105\u0107 ani zak\u0142adanego tempa prac, ani nie zbli\u017cy\u0142 si\u0119 do prognozy teoretycznej. Po 5. dniu (czyli w po\u0142owie Sprintu) ilo\u015b\u0107 Story Point’\u00f3w zacz\u0119\u0142a wzrasta\u0107. <\/p>\n\n\n\n
Przyczyn\u0105 tego stanu rzeczy mog\u0142y by\u0107 problemy om\u00f3wione dla poprzedniego przyk\u0142adu, czyli \u201ewrzutki\u201d lub zmian scope, ale r\u00f3wnie\u017c reestymacja zada\u0144. Zesp\u00f3\u0142 widz\u0105c post\u0119p i jako\u015b\u0107 pracy zmieniaj\u0105 spos\u00f3b estymacji zada\u0144, a w trakcie Retrospektywy, w celu wytworzenia produktu o jak najlepszej jako\u015bci, mo\u017ce dodatkowo wprowadzi\u0107 modyfikacje w obszarze Definition of Done. Ta teoria jest realna, je\u015bli spojrzymy, jak uk\u0142ada\u0142a si\u0119 praca w przeci\u0105gu nast\u0119pnych czterech iteracji (Sprinty 5-9). Story Pointy by\u0142y sukcesywnie \u201espalane\u201d, a\u017c do osi\u0105gni\u0119cia zak\u0142adanego zakresu na koniec 9. cyklu.<\/p>\n\n\n\n
Osobi\u015bcie polecam technik\u0119 estymowania ka\u017cdego zadania, kt\u00f3re zesp\u00f3\u0142 wykonuje w trakcie iteracji (niezale\u017cnie czy jest to zadanie zaplanowane czy \u201ewrzutki\u201d) oraz zaznaczania na wykresach kr\u00f3tkich opis\u00f3w, z czego wynikaj\u0105 poszczeg\u00f3lne fluktuacje. Czy zabrak\u0142o kilku lub jednej os\u00f3b w zespole? Pojawi\u0142y si\u0119 dodatkowe zadania? A mo\u017ce zmieniono kierunek biznesowy i by\u0142a konieczno\u015b\u0107 zmiany zakresu? Przyk\u0142ad stosowania tego typu opisu zaprezentowano poni\u017cej:<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/sticky.jpg\")
<\/a><\/figure>\n\n\n\nPami\u0119tajmy, \u017ce ka\u017cda metryka jest prowadzona nie tylko w celu wizualizacji post\u0119pu i przewidywania czasu, ale r\u00f3wnie\u017c mo\u017ce da\u0107 wiele informacji na temat tego, jak wspom\u00f3c zesp\u00f3\u0142, gdzie pojawiaj\u0105 si\u0119 najwi\u0119ksze problemy, a w kt\u00f3rych obszarach zesp\u00f3\u0142 odnosi najwi\u0119ksze sukcesy. Jest tak\u017ce wspania\u0142ym wk\u0142adem na Retrospektyw\u0119, gdzie maj\u0105c realne dane dotycz\u0105ce pracy zespo\u0142u mo\u017cemy popracowa\u0107 nad ulepszeniami.<\/p>\n\n\n\n
Burn-down chart jest bardzo przydatn\u0105 metryk\u0105 nie tylko dlatego, \u017ce pozwala \u015bledzi\u0107 post\u0119py zespo\u0142u, ale r\u00f3wnie\u017c w \u0142atwy spos\u00f3b pozwala generowa\u0107 inne przydatne miary jak Capacity oraz Velocity (wi\u0119cej informacji tutaj: https:\/\/sii.pl\/blog\/przystepny-slownik-pojec-agile\/<\/a>).<\/p>\n\n\n\n
Burn-up chart<\/h2>\n\n\n\n
Typ metryki pozwalaj\u0105cy zar\u00f3wno na pomiar post\u0119pu prac nad produktem jak i post\u0119p\u00f3w zespo\u0142u. Osobi\u015bcie sk\u0142ania\u0142abym si\u0119 bardziej do grupy metryk produktowych, co wyja\u015bni\u0119 poni\u017cej.
Konstrukcja samego wykresu jest podobna: na osi Y zaznaczamy zakres w przyj\u0119tej skali (np. w Story Point lub zadaniach), za\u015b na osi X czas (np. w Sprintach lub datach).<\/p>\n\n\n\nZasadnicza r\u00f3\u017cnica mi\u0119dzy bli\u017aniaczym wykresem burn-down chart, jest taka, \u017ce na burn-up chart zaznaczamy zmian\u0119 zakresu, a predykcj\u0119 uko\u0144czenia prac nanosimy na wykres wykorzystuj\u0105c dane o velocity zespo\u0142u. Mo\u017cna oczywi\u015bcie przyj\u0105\u0107 inn\u0105 form\u0119, jednak bior\u0105c pod uwag\u0119 zmienno\u015b\u0107 velocity, ta metoda daje najbardziej realny obraz sytuacji. W poni\u017cszym przyk\u0142adzie prace powinny zosta\u0107 zako\u0144czone w 8. Sprincie (o ile nie zwi\u0119kszy si\u0119 zakres).<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/4.jpg\")
<\/a><\/figure>\n\n\n\nNa powy\u017cszym wykresie dodatkowo zaznaczono pr\u0119dko\u015b\u0107 zespo\u0142u w danym sprincie (V) oraz r\u00f3\u017cnic\u0119, mi\u0119dzy za\u0142o\u017conym a uko\u0144czonym zakresem (\u0394). Tak jak w przypadku burn-up chart, zach\u0119cam do nanoszenia na wykres wszelkich danych, kt\u00f3re pomog\u0105 w jego interpretacji. Pozwoli to okre\u015bli\u0107 realny termin uko\u0144czenia produktu oraz b\u0119dzie stanowi\u0142o swoist\u0105 dokumentacj\u0119 pracy i samodoskonalenia zespo\u0142u. <\/p>\n\n\n\n
\u015awiadomo\u015b\u0107 o obszarach dotycz\u0105cych zalet i wad, stanowi nieocenione \u017ar\u00f3d\u0142o informacji o zespo\u0142ach zwinnych. Pomaga im nie tylko d\u0105\u017cy\u0107 do ulepszania proces\u00f3w, ale tak\u017ce wspiera umacnianie mocnych stron i pe\u0142ne wykorzystanie potencja\u0142u zespo\u0142u.<\/p>\n\n\n\n
Wykres burn-up dostarcza bardzo wielu danych, nawet bez szczeg\u00f3\u0142owej analizy:<\/p>\n\n\n\n
- \n
- Jak zmienia si\u0119 zakres prac przewidzianych w projekcie?<\/li>\n\n\n\n
- Ile pracy wykonano do tej pory?<\/li>\n\n\n\n
- Kiedy mo\u017cliwe jest uko\u0144czenie prac nad projektem?<\/li>\n\n\n\n
- Ile pracy szacunkowo wykonamy w nast\u0119pnym Sprincie?<\/li>\n<\/ol>\n\n\n\n
Informacje jakie zawiera, s\u0105 przydatne zar\u00f3wno z punktu widzenia Product Owner\u2019a, jak r\u00f3wnie\u017c Zespo\u0142u Deweloperskiego. Zesp\u00f3\u0142 ma zwizualizowane tempo w jakim pracuje, \u0142atwo mo\u017ce r\u00f3wnie\u017c okre\u015bli\u0107, w kt\u00f3rym punkcie rozwoju produktu si\u0119 znajduje, co nie pozostanie bez wp\u0142ywu na dalsze planowanie prac. Z kolei Product Owner widzi, w jaki spos\u00f3b zmiana kierunku lub wizji biznesowej wp\u0142ywa na termin zako\u0144czenia prac. <\/p>\n\n\n\n
Wgl\u0105d w ten wykres pozwala r\u00f3wnie\u017c na lepsze zrozumienie zespo\u0142u, czym jest tempo jego pracy i jak istotne jest utrzymanie sta\u0142ego zakresu prac przy niezmiennych terminach wykonania produktu. Z tego wzgl\u0119du bardziej sk\u0142aniam si\u0119 ku klasyfikacji burn-up chart jako metryki produktowej, kt\u00f3ra najwi\u0119cej informacji dostarcza Product Owner\u2019owi, poprzez zbieranie danych przydatnych w podejmowaniu decyzji.<\/p>\n\n\n\n
Epic burn-down<\/h2>\n\n\n\n
Ostatnim omawianym rodzajem wykresu spalania jest epic burn-down chart \u2013 metryka stricte produktowa. O ile wykres burn-down chart obrazuje prac\u0119 w uj\u0119ciu Sprintu, o tyle epic burn-down chart skupia si\u0119 na \u015bledzeniu post\u0119p\u00f3w prac w wi\u0119kszej granulacji \u2013 ca\u0142ych epik\u00f3w. Jest bardzo ciekaw\u0105 metryk\u0105, poniewa\u017c bierze pod uwag\u0119 wizj\u0119 biznesow\u0105 w konfrontacji z harmonogramem. <\/p>\n\n\n\n
Obrazuje zar\u00f3wno czas jaki poch\u0142on\u0119\u0142o zako\u0144czenie pracy nad poszczeg\u00f3lnymi epikami, jak r\u00f3wnie\u017c fluktuacje zakresu. \u015aledzenie post\u0119p\u00f3w sprint\u00f3w jak i epik\u00f3w daje pe\u0142ny obraz prac Zespo\u0142u Deweloperskiego oraz Product Owner\u2019a i pozawala na \u0142atwiejsze i trafniejsze wychwytywanie zagro\u017ce\u0144 i problem\u00f3w.<\/p>\n\n\n\n
Na wykresie na osi Y pokazany jest zakres \u2013 w Story Point\u2019ach (lub innej przyj\u0119tej skali), natomiast na osi X czas w uj\u0119ciu sprint\u00f3w. Po ka\u017cdym Sprincie na wykresie zaznaczane s\u0105 nast\u0119puj\u0105ce elementy:<\/p>\n\n\n\n
- \n
- Ilo\u015b\u0107 Story Point, kt\u00f3re pozosta\u0142y do uko\u0144czenia.<\/li>\n\n\n\n
- Ilo\u015b\u0107 Story Point, kt\u00f3re zosta\u0142y zako\u0144czone.<\/li>\n\n\n\n
- Ilo\u015b\u0107 dodanych Story Point (rozszerzenie zakresu).<\/li>\n<\/ol>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/5.jpg\")
<\/a><\/figure>\n\n\n\nPredykcje uko\u0144czenia danego epic\u2019a mo\u017cna wyliczy\u0107 na podstawie danych z ostatnich 3 Sprint\u00f3w. Jest to warto\u015b\u0107 Velocity zespo\u0142u dla danego epika, nie dla Sprintu (zak\u0142adaj\u0105c oczywi\u015bcie ca\u0142kowite zaanga\u017cowanie zespo\u0142u w realizacje danego epika). Dla powy\u017cszego wykresu w ci\u0105gu iteracji 2-4 zesp\u00f3\u0142 zrealizowa\u0142 30 Story Point (SP), zakres prac r\u00f3wnie\u017c wzr\u00f3s\u0142 o 30 SP. <\/p>\n\n\n\n
Prognoz\u0119 zawsze opieramy o aktualnie posiadane dane. Oznacza to, \u017ce obliczamy, ile cykli zajmie praca nad aktualnym zakresem (przy za\u0142o\u017ceniu, \u017ce zakres nie wzro\u015bnie). W powy\u017cszym przypadku: 60 SP przy tempie prac \u015brednio 10 SP per Sprint (30 SP\/ 3 Sprinty = 10 SP). W teorii, je\u015bli Zesp\u00f3\u0142 utrzyma tempo pracy, powinien uko\u0144czy\u0107 epik na koniec 10 Sprintu. Jest to jednak niebezpieczne za\u0142o\u017cenie, poniewa\u017c zakres ulega\u0142 znacznym zmianom. Ponadto, zesp\u00f3\u0142 nie posiada \u017cadnego buforu czasowego na ewentualne fluktuacje scope\u2019u i nie jest to jedyny epik, nad kt\u00f3rym pracuje.<\/p>\n\n\n\n
Jak wida\u0107 powy\u017cej epic burn-down chart jest wykresem s\u0142upkowym, gdzie jeden s\u0142upek odpowiada jednemu epikowi. W zale\u017cno\u015bci od ilo\u015bci epik\u00f3w, jak\u0105 mamy do zrealizowania, musimy zdecydowa\u0107 czy b\u0119dziemy przedstawia\u0107 je na jednym wykresie czy na wielu. Pokazanie na wykresie zmian dla wi\u0119cej ni\u017c 3 epik\u00f3w sprawi, \u017ce stanie si\u0119 nieczytelny, \u0142atwo w takim przypadku o pomy\u0142k\u0119. Spos\u00f3b prowadzenia epic burn down chart’\u00f3w powinien by\u0107 indywidualnie wypracowany przez Zesp\u00f3\u0142 Scrumowy, aby jego u\u017cytkowanie by\u0142o maksymalnie proste i zrozumia\u0142e dla wszystkich os\u00f3b. Przyk\u0142ad tego wykresu z wizualizacj\u0105 3 epik\u00f3w przedstawiono poni\u017cej:<\/p>\n\n\n\n
![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2021\/07\/6.jpg\")
<\/a><\/figure>\n\n\n\nAnaliza wykresu epic burn-down jest szczeg\u00f3lnie przydatna dla Product Owner\u2019a. W powy\u017cszym przyk\u0142adzie zesp\u00f3\u0142 ma szans\u0119 uko\u0144czy\u0107 epik 1. (E1) w 7. Sprincie. Maj\u0105c czas 10 Sprint\u00f3w przy za\u0142o\u017ceniu, \u017ce zakres nie b\u0119dzie si\u0119 zwi\u0119ksza\u0142, jest to dosy\u0107 bezpieczna estymata. Sytuacja jest bardziej skomplikowana dla pozosta\u0142ych epik\u00f3w \u2013 E2 oraz E3. Epik 2. najcz\u0119\u015bciej ulega\u0142 zmianom, ale zesp\u00f3\u0142 te\u017c realizowa\u0142 najwi\u0119cej Story Point’\u00f3w w ramach prac nad nim. <\/p>\n\n\n\n
Mo\u017ce to oznacza\u0107, \u017ce ten epik ma du\u017c\u0105 warto\u015b\u0107 biznesow\u0105 i jest istotny z punktu widzenia interesariuszy i u\u017cytkownik\u00f3w ko\u0144cowych. Z drugiej strony mo\u017ce skupia\u0107 si\u0119 na istotnych elementach podstaw produktu, zatem zesp\u00f3\u0142 k\u0142adzie du\u017cy nacisk na jego realizacj\u0119. Z kolei dla E3 w przeci\u0105gu 4 iteracji nie zosta\u0142 wytworzony \u017caden przyrost. Mo\u017ce to wskazywa\u0107 na nisk\u0105 warto\u015b\u0107 biznesow\u0105 zakresu danego epika. A mo\u017ce ten epik zawiera pomys\u0142y, kt\u00f3re b\u0119d\u0105 mog\u0142y by\u0107 wdro\u017cone po wykonaniu innych zada\u0144? Zar\u00f3wno stagnacja jak i nadmierna fluktuacja s\u0105 sygna\u0142em o pojawieniu si\u0119 mo\u017cliwych problem\u00f3w.<\/p>\n\n\n\n
Zmiany zakresu oraz ilo\u015b\u0107 uko\u0144czonych Story Point’\u00f3w, dla danego epika, s\u0105 istotn\u0105 informacj\u0105 dla Product Owner\u2019a, szczeg\u00f3lnie podczas pracy nad Backlogiem Produktu. Obrazuj\u0105, gdzie mog\u0105 pojawi\u0107 si\u0119 funkcjonalno\u015bci, kt\u00f3re nie s\u0105 istotne z punktu widzenia klienta (brak zmian), a kt\u00f3re zadania wymagaj\u0105 uszczeg\u00f3\u0142owienia wizji biznesowej (mocne wahania zakresu).<\/p>\n\n\n\n
Wykres prowadzony w granulacji epik\u00f3w pozwala na spojrzenie wysokopoziomowe na projekt. Pomaga tak\u017ce w zauwa\u017ceniu post\u0119pu zespo\u0142u w kwestii realizacji produktu w nast\u0119puj\u0105cych po sobie Sprint\u2019ach. Czy wzrost zakresu jest proporcjonalny w stosunku do ilo\u015bci zako\u0144czonych prac, a tak\u017ce jak cz\u0119sto nast\u0119puje zmiana zakresu, w tym dodawanie nowych epik\u00f3w. Chroniczne zmiany zakresu prac mog\u0105 wskazywa\u0107 na k\u0142opoty po stronie Product Owner\u2019a, co powinno by\u0107 sygna\u0142em dla Scrum Master\u2019a, \u017ce pojawi\u0142 si\u0119 obszar, kt\u00f3ry nale\u017cy usprawni\u0107.<\/p>\n\n\n\n
Czy musimy stosowa\u0107 wszystkie te wykresy?<\/h2>\n\n\n\n
Absolutnie nie! Szczerze odradzam stosowanie wszystkich mo\u017cliwych typ\u00f3w metryk jakie om\u00f3wiono powy\u017cej. Metryk\u0119 nale\u017cy dobra\u0107 zar\u00f3wno do zespo\u0142u, jak i projektu. W projektach, dla kt\u00f3rych zakres prac jest sta\u0142y, bardzo dobrze sprawdzi si\u0119 burn-down chart. Z kolei dla tych, gdzie scope ulega ci\u0105g\u0142ym zmianom warto stosowa\u0107 te\u017c burn-up chart. Je\u015bli natomiast pracujemy z wykorzystaniem epik\u00f3w wykres epic burn down chart b\u0119dzie bardzo dobrym narz\u0119dziem do pracy dla Product Owner\u2019a. <\/p>\n\n\n\n
Przy wyborze odpowiedniej metody \u015bledzenia post\u0119pu projektu, jak i pracy, istotne jest zwr\u00f3cenie uwagi na najpilniejsze potrzeby zespo\u0142u. Metryki spe\u0142ni\u0105 swoje zadanie tylko wtedy, kiedy pozwol\u0105 na doskonalenie proces\u00f3w, produktu, jak r\u00f3wnie\u017c samego zespo\u0142u i organizacji. Stosuj\u0105c zbyt du\u017c\u0105 ilo\u015b\u0107 metryk nie b\u0119dziemy w stanie czerpa\u0107 z nich korzy\u015bci, czyli skupia\u0107 si\u0119 na ci\u0105g\u0142ym usprawnianiu, poniewa\u017c ograniczenie Retrospektywy wy\u0142\u0105cznie do przegl\u0105du i omawiania metryk ca\u0142kowicie pozbawi to spotkanie sensu. Zmieni je w sesj\u0119 raportowania, nie pozostawiaj\u0105c przestrzeni na prac\u0119 zespo\u0142u nad usprawnieniami, kt\u00f3re \u2013 o ironio! \u2013 zosta\u0142y zauwa\u017cone w metrykach.<\/p>\n\n\n\n
Wykorzystujmy metryki jako u\u0142atwienie w codziennej pracy, narz\u0119dzie wspomagaj\u0105ce nas w wizualizacji post\u0119pu i procesu, a tak\u017ce w wykrywaniu nieprawid\u0142owo\u015bci i mo\u017cliwych problem\u00f3w. Metryki s\u0105 detektorem, narz\u0119dziem analitycznym, a tak\u017ce punktem wyj\u015bcia do rozmowy z zespo\u0142em. Bo to w\u0142a\u015bnie bliska wsp\u00f3\u0142praca ludzi nale\u017c\u0105cych do zespo\u0142u daje najlepsze rezultaty. Tak \u2013 to na pewno zosta\u0142o kiedy\u015b zmierzone \ud83d\ude42<\/p>\n\n\n