Jakie byłoby wspaniałe, gdyby stan projektu (lub aktualna faza projektu) dał się wyrazić jednym prostym wykresem? Właśnie to jest możliwe w SCRUMie, gdy użyjemy diagramu Burndown. Dzięki niemu możemy sprawdzić, ile zadań musimy ukończyć w bieżącym sprincie. Diagram Burndown zawsze dotyczy bieżącego sprintu. Nowy sprint to nowy diagram Burndown.
Idealny wykres ma funkcję y = [stała całkowita ilość pracy w sprincie] - x. Na osi poziomej (x) znajduje się liczba dni bieżącego sprintu. Na osi pionowej (y) znajduje się objętość pracy przypisaną do bieżącego sprintu. Idealny wykres sprintu w SCRUMie możemy porównać do tej samej utopii, jak założenie, że wszyscy będą chętni do pracy dobrowolnie tam, gdzie firma ich potrzebuje i będą kupować tylko to, czego naprawdę potrzebują, a wówczas możemy znieść pieniądze (copyright tej sparafrazowanej myśli należy do panów Marksa i Engelsa).
Diagram Burndown powinien (a raczej musi) zmierzać do stanu y=0, co oznacza, że wszystkie zadania zostały zakończone, a więc objętość pracy przypisana do bieżącego sprintu wynosi 0. Ten stan jest jednak możliwy do osiągnięcia tylko w warunkach laboratoryjnych. W rzeczywistych projektach wykres kołysze się wokół idealnego stanu – raz nam idzie lepiej i wykonujemy większą ilość pracy, innym razem, na przykład, dowiadujemy się, że juniorzy (studenci) mają przed sesją i nie mają takiej produktywności, jaką od nich początkowo oczekiwaliśmy, albo odkrywamy, że użycie jednej technologii wymaga nauki innej technologii, by poprawnie i skutecznie ją wdrożyć. Jak wiemy, w SCRUMie jakość oprogramowania jest priorytetem. Pamiętacie zakończenie utworu rapowego JBMNT? Może rozwój utworów Kontrafaktu jest kierowany przez SCRUM...
Co jeśli wykres pokazuje, że sprint zakończy się wcześniej niż zaplanowano? Może to być doskonała praca zespołu, który na początku sprintu włożył więcej wysiłku, niż to wynika z ich średniego tempa pracy. Może to także świadczyć o złym zaplanowaniu zadań, których czas wykonania został przeceniony, co może być odebrane przez Product Ownera jako marnotrawstwo środków finansowych. SCRUM Master powinien skupić się na jakości wykonanej pracy. Czy zadania rzeczywiście zostały rozwiązane, czy tylko powierzchownie? Czy będziemy musieli je później poprawiać, co zabierze nam 10 razy więcej czasu niż teraz? A jak wygląda produktywność? Wiecie, jak produktywny jest programista, który pracował całą sobotę i niedzielę, a potem w poniedziałek (8. dzień pracy bez przerwy) przychodzi do pracy? Doświadczony SCRUM Master powinien wiedzieć, kiedy zwolnić tempo, aby zespół był w dobrym nastroju i utrzymywał stałą wydajność.
Co jeśli wykres pokazuje, że sprint nie zdąży się zakończyć w ustalonym terminie? Ponownie możemy stwierdzić, że sprint był źle zaplanowany, a siły zostały przecenione. Może SCRUM Master zaplanował prace, myśląc „jeśli każdego dnia będziemy podkręcać tempo, to zdążymy nawet z tym...”. To jakby studentka Danka zaplanowała, że wyjedzie godzinę przed wykładem, kiedy jej podróż tramwajem z Dúbravki będzie trwała 55 minut. Zdecydowanie spóźni się na wykład, zje bagietę, wchodzi do sali, kiedy wykładowca już zacznie, a ona z pewnością będzie musiała zmierzyć się z dziwnymi spojrzeniami i starać się zapamiętać twarz wykładowcy... Albo to jakby student Josef planował wybór tapicerki do swojej nowej Škody Octavii RS, którą chce kupić za 3 miesiące, ale nie chce brać nowego kredytu, bo właśnie spłacił starą Dacię. Na pewno nie zdąży jej kupić.
Co jeśli wykres wcale nie przypomina funkcji y = stała - x? Znów błąd może wynikać z błędnego oszacowania czasu przez SCRUM Mastera. Może projekt został zaplanowany "ponad siły" zespołu w obecnym składzie. W takim przypadku powinien zacząć od łatwiejszych zadań, które umożliwią mu naukę na tyle, aby mógł „wejść na lód na drugiej i trzeciej tercji, pokazać co potrafi” i spróbować odwrócić wynik.
Na wykresie Burndown masz kilka opcji, jaką wielkość nanieść na oś Y, na przykład liczba User Stories w sprincie. Co to jednak mówi? Gdybym miał zgadywać, ile masz pieniędzy w portfelu, a Ty powiedziałbyś mi, ile masz banknotów w portfelu, to nadal nie potrafiłbym oszacować, ile masz pieniędzy.
Według mnie najlepsza jest oś Y, na której znajdą się człowiekogodziny wszystkich członków zespołu. Całkowity dostępny czas sprintu można wyrazić w następujący sposób:
Całkowity dostępny czas = LICZBA_DNI_SPRINTU * LICZBA_CZŁONKÓW_ZESPOŁU * 8
zakładając, że średnia długość dnia roboczego wynosi 8 godzin.
Należy liczyć się z tym, że oszacowanie całkowitej pracy to tylko oszacowanie, które nie musi być w pełni zgodne z rzeczywistością. Na przykład opiera się na założeniu, że wszyscy pracują równie efektywnie, co nie jest prawdą. Jest to jednak wystarczająco przydatne oszacowanie dla celów projektu. Należy liczyć się z rezerwą na wypadek problemów. A drobne problemy (czyli wyzwania do rozwiązania) na pewno się pojawią.
Nawet jeśli nasz wykres Burndown bieżącego sprintu przypomina przynajmniej w przybliżeniu idealny wykres, to niekoniecznie tak już zostanie. Możemy napotkać poważny błąd podczas testowania wewnętrznego innej User Story. Może się okazać, że User Story, którą oznaczyliśmy jako ukończoną, wcale nie jest ukończona. Z praktyki wynika, że zdarza się to juniorom, którzy rozumieją zadanie, wykonują je w 80%, zostawiając 20% niedokończonej pracy, którą przeoczyli (np. program nie reaguje na taką kombinację danych wejściowych, jakiej nie przewidywali).
W duchu zwinnego rozwoju klient może zmienić lub dostosować specyfikację, co ponownie otworzy zamknięte zadania w sprincie. Traktujemy to jako drobne poprawki, dla których nie będziemy zwoływać spotkania Backlog Refinement. Nie mogę sobie darować, że klient chętnie nazywa tę zmianę „bugiem”, co daje do zrozumienia, że to nie jego wina, może się po prostu źle zrozumieliśmy. W praktyce jest obojętne, jak klient to nazwał, chodzi o to, że zarówno zmiany, jak i błędy muszą zostać usunięte ze oprogramowania w duchu zwinnego rozwoju jeszcze przed zakończeniem sprintu.
Marián Knězek