Artykuły o Agile i nie tylko.
Największy w Polsce portal o zwinności

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.

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”.

Reklama


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

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
X