3 zwinne raporty wypalania i jak z nich korzystać

Zwinne praktyki, dla niewtajemniczonych i niedoinformowanych, mogą czasem pojawiać się jako metody tworzenia oprogramowania ad hoc i zarządzania projektami. Prawda jest zupełnie inna.

Jedna z 12 zasad zwinnego oprogramowania brzmi: „Najlepsze architektury, wymagania i projekt wyłaniają się z samoorganizujących się zespołów”, ale większość organizacji stosujących zwinne praktyki, w tym scrum i Kanban, narzuca pewne istotne rygory i rytuały procesowe. Na przykład wiele organizacji wdraża zwinne praktyki planowania, w tym szacowanie punktów fabularnych, standardy architektury i dyscypliny zarządzania wydaniami, aby poprawić wpływ na biznes, jakość i niezawodność wydań aplikacji.

Większość zespołów decyduje się na użycie elastycznego narzędzia, takiego jak Jira Software lub Azure DevOps, do zarządzania zaległościami, sprintami i współpracą między zespołami zwinnymi. Głównym celem tych narzędzi jest centralne zarządzanie wymaganiami, stanem sprintu, przepływem pracy i współpracą między członkami zespołu zwinnego i wieloma zespołami zwinnymi. Jednak im bardziej organizacje rygorystycznie stosują te narzędzia, tym bardziej narzędzia te mogą pomóc liderom i zespołom identyfikować problemy, informować interesariuszy o stanie i usprawniać ich wykonanie.

Jednym z najczęstszych raportów „po wyjęciu z pudełka” jest raport wypalenia. Ponieważ praktyki zwinne umożliwiają właścicielom produktów zmianę priorytetów zaległości w oparciu o opinie klientów, tradycyjne raporty, takie jak wykresy Gantta, nie są w stanie uchwycić płynnego charakteru zwinnego wykonywania. Zasadnicze znaczenie dla wykresu spalania polega na tym, że uwzględnia on ukończoną pracę, nową pracę dodaną do zakresu i inne zmiany zakresu. Wykres wypalenia może zapewnić szybki obraz tego, jak zespoły maszerują w kierunku swoich celów.

Czytanie podstawowego wykresu wypalania sprintu

Wykresy wypalania zwykle mają czas wzdłuż osi X i szacunki na osi Y. Wiele zespołów szacuje w punktach opowieści, ale wiele narzędzi zwinnych może sporządzać wykresy wypalania na podstawie liczby historii lub szacunków w godzinach. W tym artykule zakładam, że używane są punkty fabularne.

Raport wypalania sprintu przedstawia liczbę punktów opowieści, które są objęte zakresem dla przedziału czasu. Gdy zespół kończy historie, wykres pokazuje, w jaki sposób „wypalają” listę historii i innych rodzajów pracy (problemy w Jira, typy elementów roboczych w Azure DevOps) do momentu zakończenia pracy lub zakończenia sprintu. Kiedy zespoły wykonują pracę związaną z sprintem, wykreślona linia przecina oś X, wskazując, że wszystko zostało wykonane.

Wypalenie sprintu jest najłatwiejsze do konceptualizacji. Pierwszego dnia sprintu zespół zobowiązuje się do przedstawienia historii i łącznej liczby punktów z opowieści. Jeśli przejrzysz wykres wypalania tego dnia, na osi Y powinien pojawić się pojedynczy punkt reprezentujący liczbę punktów, na które zespół zobowiązał się w dniu zerowym sprintu.

Gdy historie są oznaczone jako gotowe, nagranie sprintu pokazuje pozostałą liczbę punktów do ukończenia.

Jak w praktyce wykorzystuje się wypalanie sprinterskie? Zdrowe wypalenie pokazuje liniową i idealnie wykładniczą krzywą aż do zera. Jeśli krzywa ma płaskie nachylenie we wczesnej części sprintu, może to wskazywać na bloki lub dużo pracy w toku i że sprint może być zagrożony. Płaskie lub wolno opadające wypalanie może być bardzo problematyczne, jeśli przeprowadzanych jest wiele testów na historiach z pełnym kodem i jeśli prace testowe nie mogą się rozpocząć przed kilkoma ostatnimi dniami sprintu.  

Szybko malejące wypalenie w sprincie jest generalnie dobrą rzeczą, ale może wskazywać, że zespół nie angażuje się lub wybrał tylko mniejsze historie w sprincie.

Epickie wypalenia śledzą postępy względem czynników biznesowych i technicznych

Wypalenia sprintu są bardzo przydatne do śledzenia krótkoterminowych wyników i pomagają zespołom w pomyślnym wypełnianiu zobowiązań sprinterskich. Aby lepiej śledzić postępy w realizacji celów długoterminowych, epickie i wypalenia zapewniają niezbędną widoczność.

Epickie spłaty działają najlepiej, gdy zespoły definiują kilka długotrwałych działań, takich jak wdrażanie głównych funkcji użytkownika końcowego, techniczne strategie zadłużenia, ulepszenia wydajności lub ewolucja procesów. Aby wykorzystać epickie wypalenia, zaległości powinny zawierać:

  • Od pięciu do 15 eposów, które potrwają co najmniej kilka miesięcy, a ich ukończenie zajmie sześć lub więcej sprintów.
  • Funkcje, historie i fragmenty historii, które łączą się z eposem i reprezentują wysoki poziom planu do wykonania w eposie.
  • Szacunki wysokiego poziomu, najlepiej w punktach opowieści dla każdej historii lub fragmentu historii, który znajduje się pod eposami.

Po ich wdrożeniu epickie wypalenie przedstawia zmiany w tym planie. Jego oś X reprezentuje sprinty, a oś Y przedstawia całkowite oszacowanie historii i fragmentów opowieści przypisanych do eposu. Na epickim wykresie postępu prac Jira Software widać wykres słupkowy z jednym kolorem przedstawiającym historie ukończone w trakcie sprintu, a drugim przedstawiającym dodane punkty historii. Punkty fabularne zwiększają się, gdy do eposu zostaną dodane nowe historie lub fragmenty historii lub gdy zmienią się szacunki.

Istnieje kilka sposobów korzystania z epickiego wykresu wypalania:

  • Ilustruje szybkość wypełniania funkcji i historii wbrew planowi. Gdy plany są dokładne, a prędkość zespołu jest spójna, może stanowić wskazówkę, kiedy praca nad eposem jest zakończona.
  • Większość planów zwinnych nie jest kompletna, a zespoły dodają, zmieniają i usuwają historie na podstawie opinii użytkowników końcowych, odkrycia złożoności technicznych i rozwiązania problemu zadłużenia technicznego wprowadzonego podczas podróży. Epickie wypalenie wskazuje następnie, jak daleko od planu zależy od tego, jak bardzo rośnie zaległości w porównaniu z ukończeniem sprintu po sprincie.
  • Epickie wypalenia pomagają również w porównywaniu wysiłków w wielu sprintach i ocenie, ile pracy planowania i realizacji jest wykonane w jednym eposie w porównaniu z innymi.

Wypalanie wydań informuje zespoły, czy premiera osiągną datę i zakres

Zaawansowane zespoły, które w pełni automatyzują swoje potoki dostaw za pomocą ciągłej integracji, ciągłego testowania i ciągłego dostarczania, mogą nie potrzebować wypalania wersji. Zespoły, które wdrażają się często, powinny śledzić, jakie funkcje i historie są powiązane z wydaniem, ale wypalanie wydania nie jest zbyt przydatne, ponieważ często śledzi postępy w sprincie.

Dla innych zespołów, które stosują się do praktyk zarządzania wydaniami i standaryzują wydania wielodruku, wypalenie wydania może być najważniejszym narzędziem właściciela produktu i zespołu.

Wypalanie wydania jest podobne do wypalenia epickiego, z wyjątkiem tego, że zamiast śledzenia funkcji, historii i fragmentów historii przypisanych do eposu, wypalanie wydania pokazuje, co jest przypisane do wydania. Oś i pręty są wtedy identyczne z epickimi wypaleniami.

Zespoły korzystające z wypalania wersji mogą więc śledzić zakres i oś czasu wydania. Zespoły, które są na torze, zobaczą spalone zbocze w dół do osi X z nachyleniem zgodnym z prędkością zespołu. Wydania, które mogą zbaczać z toru, albo mają mniejsze nachylenie, albo przedstawiają więcej dodawanych punktów fabularnych (gdy do wydania zostanie dodany większy zakres) niż to, co jest ukończone.

Jira Software pomaga w tych prognozach. Zakładając, że zespół pracował nad projektem przez co najmniej trzy sprinty, Jira Software obliczy średnią prędkość zespołu i przewiduje końcowy sprint dla wydania opartego na tej szybkości.

Sprint, epicki i wypalenia dają zespołom kilka łatwych w użyciu narzędzi do dostosowania się do celów. Kiedy zespoły wspólnie rozumieją zakres, uzgadniają priorytety, planują kilka sprintów do przodu i odpowiednio tagują historie w swoich zaległościach, wypalenia mówią o tym, czy planowanie i wykonanie są zgodne z celami. Kiedy tak nie jest, są narzędziem opartym na danych, które może podsycać dyskusję na temat tego, jakie korekty mogą być potrzebne.