W dzisiejszym odcinku przybliżę dwie „techniki”, które używamy w celu
monitorowania.
Przeszkadzajki
W projektach dev-ops
(deweloperka nowych funkcjonalności przy jednoczesnym utrzymaniu działającego
produkcyjnie systemu) niezwykle istotna jest kontrola tzw. „focus factor”,
czyli w jakim stopniu zespół koncentruje się na realizacji celu sprintu.
Oczywiście w idealnym przypadku nie powinniśmy wykonywać żadnej pracy, która
nie zliża nas do wspomnianego celu, ale takiej utopii nie udało nam się jeszcze
osiągnąć J. W naszym przypadku główne źródła „dekoncentracji”
zespołu to:
- Wsparcie procesu deploymentu (pomoc działowi IT w konfiguracji środowisk, konsultacje z testerami)
- Wparcie dla biznesu (odpowiedzi na pytania klienta związane z planowanymi funkcjonalnościami)
- Wsparcie użytkowników końcowych w procesie onboardingu (integracji ich systemu z naszym systemem)
- Analiza problemów i błędów, które pojawiły się na systemach produkcyjnych
Na koniec dwie
przestrogi:
- Ustalcie jasno i klarownie, czym jest wrzutka przeszkadzajka (naszą definicję znajdziecie wytłuszczoną w tekście powyżej)
- Starajcie się unikać jednostek czasu liczonej w godzinach (my niestety wpadliśmy w tą pułapkę) – szczególnie, jeśli dane prezentujecie Product Ownerowi. Niestety 1 godzina pracy nad wrzutką przeszkadzajką nie uwzględnia kosztu „zmiany kontekstu” (porzucenia zadania, które było poprzednio wykonywane oraz ponownego powrotu do niego). Jeśli możecie wprowadźcie swoją miarę w postaci: Distraction Points, litrów, kilogramów, kubików, łokci, marchewek … czegokolwiek byle nie czasu. Unikniecie przez to żmudnych tłumaczeń, dlaczego zespół narzeka na wrzutki skoro zajmują one jedynie - powiedzmy 5% ich czasu.
Olewajki
Wasz zespół pracuje
niczym małe pszczółki w ulu (Zimoch moim idolem ;)). Wszyscy skoncentrowani są
na celu sprintu i nagle <bam> test z jakiegoś starego projektu przestaje
przechodzić, znaleźliście „kwiatek” w legacy kodzie, który spowodował, że
wszystkim obecnym zjeżył się włos na głowie, padł serwer, który wprawdzie udało
się podnieść, ale wszystko powiązane jest sznurkami. Jeśli zajmiecie się
rozwiązaniem problemu nie zrealizujecie celu sprintu, jeśli „olejecie” problem
może za jakiś czas uderzyć ze zdwojoną siłą. Co teraz? Naszym pomysłem było
stworzenie kartek-olewajek. Na takiej karteczce wpisujemy, z czym jest problem
i umieszczamy ją w osobnym backlogu. Na Sprint Planningu zespół wybiera
niezrealizowane „olewajki”, które powiązane są z obszarem aplikacji, nad którym
będą pracować i wrzuca je, jako techniczne zadania do wykonania w ramach User
Story.
Czemu osobny backlog ?
Ponieważ te problemy
dotyczą stricte technicznych zagadnień, które ciężko zrozumieć Product Ownerowi
(a ponieważ tego nie rozumie, nadaje tym problemom niski priorytet). Dodatkowo
w większości nie są to „pełnoprawne” User Stories, ale raczej zadania
techniczne do wykonania.
Jak zorganizować taki backlog?
Jak chcecie. My mamy
macierz, której rzędy reprezentują obszary systemu a wiersze
priorytet/krytyczność problemu
Priorytet/obszar
|
Obszar 1
|
Obszar 2
|
Najwyższy priorytet
|
Fix XYZ
|
|
Najniższy priorytet
|
Refaktor kodu w XXX
|
Jaką strategię obrać przy realizacji olewajek?
Ponieważ nie są to
zadania niezbędne do ukończenia User Story (a raczej doczepione do niego)
zespół miał tendencję do odwlekania realizacji na „ostatnią chwilę”. Jak można
się domyśleć w związku z tym były rzadko robione. Dlatego odwróciliśmy sytuację
przez dodanie nowej reguły działania zespołów: „Kartka olewajka musi być
zrealizowana w przeciągu 2 pierwszych dni sprintu (a najlepiej zanim zaczniemy
pracę nad danym User Story)”
Co zmieniło się przez wprowadzenie kartek olewajek?
Zaczęliśmy PLANOWAĆ poprawki, a nie realizować je
ad-hock (zawalając przy okazji inne rzeczy, które były w celu sprintu) lub
totalnie ignorować (może nie wybuchnie)
Categories:
Organizacja zespołu,
SCRUM,
Sprint Backlog
