Błędy z zeszłych sprintów. Jak z nimi postępować?

Zespół scrumowy (zespół deweloperski) skończył pracę na przyrostem. Właściciel produktu odebrał go i przekazał do Klienta (interesariuszy). Klient wdrożył gotowe oprogramowanie (produkt). Po kilku sprintach, kiedy zespół robi już zupełnie inne rzeczy, Klient znajduje błędy w przekazanym oprogramowaniu. I zgłasza je do zespołu scrumowego. Sytuacja z życia wzięta, codzienna. Jak sobie z nią poradzić? Przygotowałem dla Was grafikę obrazującą jedną z możliwych ścieżek postępowania.

Reklama


Grafika obrazuje proces obsługi błędów dla funkcji, które już zostały wdrożone jakiś czas temu. Oczywiście nie jest to jedyna możliwa ścieżka postępowania. Co produkt i organizacja, obsługa błędów może wyglądać w szczegółach inaczej. Nie mniej jednak traktujcie go proszę jako generyczną wersję procesu. Samą grafikę zrobiłem w narzędziu Canva (canva.com) i możecie ją skopiować i stworzyć na jej podstawie własną, uwzględniającą Waszą specyfikę pracy. Grafika “Błędy z zeszłych sprintów”.

Proces pokazany na grafice rozpoczyna się w momencie zgłoszenia błędu. Jeżeli jest to błąd krytyczny, to należy się zastanowić, czy możemy dla takiego problemu wdrożyć od razu obejście (ang. workaround). I tu pojawia się pierwsza rzecz, którą przed wdrożeniem samego procesu musimy uspójnić. Mianowicie co to znaczy błąd krytyczny oraz workaround. Aby oba te pojęcia mogły funkcjonować, zespół deweloperski oraz interesariusze (w tym przypadku są to osoby, które zgłaszają błędy), muszą mieć tożsame rozumienie obu w/w pojęć. Jest to kluczowe, ponieważ doświadczenie mi pokazuje, że jednym z najczęstszych problemów np. dla zespołu deweloperskiego jest właśnie nadawanie priorytetów przez interesariuszy (magiczny “biznes”; wszystko jest “krytyczne”).

Innym elementem, na który chcę Wam zwrócić uwagę, jest naprawa błędu (jesteśmy w procesie dalej) poprzez dodanie go do bieżącego sprintu. Chcę Wam zasugerować, że de facto nie mówimy tutaj o dodaniu błędu do bieżącego sprintu, ale o podmianie tego zadania z innym zadaniem. Jako zespół deweloperski na planowaniu sprintu podejmujecie zobowiązanie (albo bardziej przewidujecie), że na koniec danej iteracji zrealizujecie określony cel sprintu, w tym jego zakres. Jeżeli w trakcie trwania iteracji pojawia się coś krytycznego do zrealizowania, oznacza to, że obecny zakres nie może zostać zrealizowany. Stąd na grafice hasło, że “…podmieniamy go (błąd) z innym zadaniem z bieżącego sprintu…”. Z jakim zadaniem jest błąd podmieniany, zależy to od Product Ownera.

Chciałbym, aby grafika została docelowo tak dopracowana, aby było możliwe jej powieszenie przy każdym zespole deweloperskim, który jeszcze w ten sposób nie postępuje. Czego jeszcze w niej brakuje, aby to zrobić? Podzielcie się proszę Waszymi przemyśleniami/ uwagami.

PS. Grafika powstała przy konsultacji z Ewą LudwiczakDominiką Ciszewską.

PS2. Grafikę przygotowałem przy użyciu Canva

Komentarze do wpisu: “Błędy z zeszłych sprintów. Jak z nimi postępować?

  1. Łukasz Mozalewski

    Co to znaczy że błąd jest podmieniany z innym zadaniem? Co się dzieje z tym zadaniem? Co z wyceną tej akcji (nie ma kroku)? Załóżmy że sprint backlog został wyceniony na 100 SP. Prędkość średnia to 103 SP. W momencie podjęcia blędu wszystkie zadania są podjęte i błąd wyceniamy na 5 SP a zajmuje nam zasobów jak zadanie na 1 SP lub okazuje się że zależności? Brakuje określenia zależności, wyceny, aktualnego postępu prac oraz gotowości. Workaround to wzrost długu technologicznego.

    • Dawid Lewandowicz

      Dzięki Łukasz za Twój komentarz.
      Moja odpowiedź będzie dość długa, ponieważ zawarłeś w swoim komentarzu wiele pytań. I tak:
      1. Co to znaczy że błąd jest podmieniany z innym zadaniem?
      Oznacza to, że zespół może w ramach danej iteracji “przerobić” określoną liczbę tasków. Innymi słowy ma określona pojemność (ang. capacity). Jeżeli zdecydujemy, że dany błąd musi być naprawiony od razu oznacza to, że musimy z czegoś zrezygnować (nie da się zwiększać możliwości zespołu jeżeli już wziął ich “pod korek”, tzn zaplanował na przyszły sprint swoją pojemność maksymalnie). Oczywiście, że możemy mieć tutaj do czynienia z sytuacją, kiedy zespół tak planuje zadania na przyszły sprint, aby 10-20% swojej pojemności rezerwować na zadania nieplanowane (w tym przypadku rzeczony błąd) lub np jest wyznaczony tzw. dyżurny, który takie zgłoszenie obsługuje. W naszej sytuacji nie było to przewidziane, więc należy dany błąd zamienić z zadaniem już realizowanym lub świadomie sobie powiedzieć, że z uwagi na inne priorytety, danego zadania możemy nie zrealizować.
      2. Co się dzieje z tym zadaniem?
      Jeżeli zespół zdecyduje o podmianie zadania, to to, które nie jest już realizowane trafia z powrotem do Rejestru Produktu. Jego priorytetyzacja jest wtedy kwestią Product Ownera i może ono trafić na następną iterację (sprint) lub nie. Podobnie jak nieskończone zadania ze sprintu bieżącego.
      3. Co z wyceną tej akcji (nie ma kroku)?
      Jeśli mówimy o błędzie, z definicji on nie jest wyceniany. Deweloperzy argumentują to tak, że bardzo trudno wycenić błąd ponieważ jego natura jest taka, że nie wiadomo co należy zrobić i jakie to jest skomplikowane.
      Jeśli mówimy o zadaniu, które zostało zastąpione i trafiło z powrotem do Rejestru Produktu, jego wycena następuje standardowo (w tym przypadku najczęściej w zespołach widzę reestymację zadania z uwzględnieniem tego, co już zostało zrobione).
      4. Nie do końca rozumiem stwierdzenie “…błąd wyceniamy na 5 SP a zajmuje nam zasobów jak zadanie na 1 SP…”.
      Nie wiem, czy wyżej już nie kryje się odpowiedź na ta kwestię. Co do zasobów (zwłaszcza ludzi), to jest to bardzo Project Managmentowe podejście i staramy się go w pracy z zespołami nie używać.
      5. Brakuje określenia zależności, wyceny, aktualnego postępu prac oraz gotowości.
      Co do zależności – zgadzam się, nie ma tego ujętego w grafice i może być powinno (chociaż doświadczenie mi pokazuje, że błędy ich raczej nie mają).
      Wycena – patrz pkt. 3
      Aktualny postęp prac – jeżeli zespół używa jakiegoś narzędzia, to nie widzę problemu, aby uwzględnić w nim podmianę, jeżeli miała miejsce.
      Gotowość – co miałeś na myśli?
      6. Workaround to wzrost długu technologicznego.
      Tak, workaround to wzrost długu technicznego (http://www.agile247.pl/dlug-techniczny/). Ale jeżeli musimy usprawnić naszą usługę na szybko, zespół wraz z PO mogą się na to zdecydować z pełną świadomością, że będą kiedyś musieli wrócić do tego zastosowanego obejścia i problem trwale, porządnie naprawić.

    • Krzysztof Łazarski

      Łukasz, daj proszę znać w jaki sposób estymujecie bugi i jakie to daje efekty?
      Z doświadczenia wiem, że estymowanie bugów często gęsto kończy się tragicznie. W szczególności dla zespołów, które kurczowo trzymają się estymat i średniej prędkości zespołu.
      Jakbyś sobie poradził w sytuacji kiedy zespół stosowałby estymaty koszulkowe? Jak wtedy byś to wszystko obliczył
      Nie ukrywam, że to to dla mnie zabawne jak niektóre zespoły tak kurczowo trzymają się tych magicznych liczb zwanych estymacjami.
      „Brakuje określenia zależności, wyceny, aktualnego postępu prac oraz gotowości.” Nah, przecież mieliście planowanie, wiecie jakie macie priorytety. Na koniec planowania sprintu powinniście już wiedzieć jakie ewentualnie zadania „poświęcicie” na rzecz nieoczekiwanego buga. Jeśli nie, to proponuję się nad tym zastanowić. Święta się zbliżają, pomyślcie czy nie lepiej przy Sprintowym stole nie zostawić jakiegoś wolnego slotu na „niespodziewanego gościa”. A przecież ten „niespodziewany gość” to nie musi być bug. Równie dobrze to może być zwykła „wrzutka” od Stakeholdera, który się uparł 😀
      Więcej luzu w sprintach życzę! 😉

  2. Ja już od dawna stosuję Bradley Bug chart (https://scrumcrazy.files.wordpress.com/2018/09/scrumbug-613-2.pdf) i mam wrażenie, że w porównaniu do Waszego diagramu traktuje problem szerzej. Chociaż faktycznie może pojawić się problem „dopychania kolanem” kilkunastu bugów dwugodzinnych. Można też prowadzić statystyki – ile czasu zajmuje nam naprawa takich bugów w ostatnich x sprintach (ja łączę to też z wykładniczą średnią kroczącą) – oczywiście trzeba tu mierzyć ile czasu się spędza nad naprawą błędów.
    Tylko potem powstaje problem, że błędy mniej krytyczne są wrzucane do backloga i nie ruszane przez 3+ miesiące (albo i dłużej).


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x