W moim poprzednim artykule rozpocząłem dyskusję na temat źle wykształconych nawyków w zespole scrumowym, które prędzej czy później doprowadzą do niepowodzenia w dostarczaniu. W tym artykule chciałbym jeszcze raz rozwinąć ten temat i skupić się teraz na procesach funkcjonalnych wewnątrz zespołu.
Są one równie ważne jak doskonałość techniczna zespołu. Nawet jeśli ludzie w środku są super wykwalifikowani do pracy, którą mają wykonać, wciąż istnieją obszary, które mogą zrujnować ich wysiłki w dążeniu do perfekcji. I nie będzie to w dużej mierze ich wina, ponieważ będzie to bezpośrednia odpowiedzialność za decyzje dotyczące zarządzania projektami i ich zdolność do służenia zespołowi procesami dopasowanymi do celu, aby wspierać zespół z jasnymi intencjami i przewidywalnymi działaniami.
Spis treści:
Wysoce segregowany zespół z odrębnymi zestawami umiejętności
Wyobraź sobie, że zespół ma wykwalifikowanych programistów, całkowicie niezależnych i zdolnych do dotrzymywania obietnic i dostarczania uzgodnionej treści sprintu na czas przed końcem sprintu. Nawet w tak idealnym scenariuszu (co i tak jest mało prawdopodobne), zespół będzie miał problemy z nadążaniem za (stale rosnącymi) funkcjami backlogu, jeśli umiejętności będą ściśle rozdzielone między członków zespołu.
Kilka przykładów
- Zespół ma 1 lub 2 inżynierów DevOps zdolnych do wprowadzania dowolnych zmian w zautomatyzowanych potokach lub dbania o usługi wewnątrz platformy, ale reszta zespołu nie ma pojęcia o takich rzeczach. Następnie omawianie tych historii na ceremoniach scrumowych, takich jak udoskonalanie, doprowadzi do zmarnowania czasu dla większości zespołu poprzez trzymanie się na spotkaniu bez żadnego udziału i odwrotnie – programista DevOps nie będzie zainteresowany resztą historii zorientowanych na funkcjonalność i czas na spotkaniu też będzie w większości stracony.
- Dla całego zespołu jest jeden ekspert od baz danych. W zależności od złożoności i wykorzystania rozwiązań danych w systemie, nad którym pracuje zespół, osoba ta może być stale przeładowana historiami, których nie ma szans na ukończenie w odpowiednim czasie, zwłaszcza biorąc pod uwagę jej priorytety. Co gorsza, inne historie również będą musiały poczekać, ponieważ są one zależne od źródła danych zapewnianego przez historie bazy danych.
- Kiedy dany produkt jest głównie zorientowany na rozwój backendu, jedyny programista front-endu jest tam na wszelki wypadek (ponieważ od czasu do czasu potrzebna jest niewielka zmiana nawet w aplikacji UI). W takim razie znowu większość ceremonii scrumowych to strata czasu dla tego członka zespołu, ponieważ jego wiedza ogranicza się tylko do front-endu i nic innego się nie liczy.
Gdzie się kończy
W każdym z powyższych przypadków rezultat jest taki, że ludzie albo marnują swój czas, albo, alternatywnie, nie są w stanie nadrobić zaległości. Blokują reszcie zespołu rozpoczęcie pracy nad kolejnymi historiami lub skutecznie obniżają ogólną efektywność zespołu scrumowego, ponieważ w sprincie jest zbyt dużo czasu, który nie jest wykorzystany.
Zespół ma jednak nadal taką liczbę programistów. Z zewnątrz nie widać (nawet nie chcąc być zdemaskowanym), że ludzie wewnątrz zespołu nie są w stanie podjąć pewnych historii tylko dlatego, że są zbyt zorientowani na jakiś konkretny zestaw umiejętności. Nie mogą więc pomagać innym członkom zespołu w opowiadaniach, nawet jeśli pozwalają na to ich możliwości, a priorytety opowiadań również by na to sprzyjały.
Nawet właścicielowi produktu trudno jest skomponować sensowną treść sprintu dla zespołu, ponieważ właściciel produktu musi zawsze brać pod uwagę, ile osób może pracować nad każdą pojedynczą historią i czy więcej podobnych historii jest wprowadzanych do sprintu w tym samym czasie , ostatecznie możliwości zespołu są przepełnione, nawet jeśli w rzeczywistości są ludzie, którzy mogliby pracować nad tymi historiami, ale nie mają umiejętności, aby zacząć od nich.
Rozwiązanie dylematu
Jest to dylemat do rozwiązania, a kierownicy projektów powinni być świadomi, jaką drogę wybrać. Konkretnie wybór pomiędzy:
- Posiadanie wielu pełnoetatowych programistów zdolnych do pracy nad szerszymi treściami, ale niezbyt ekspertów w wielu tematach. Mogą więc iść szeroko, ale nie głęboko. Wtedy dostawa może postępować szybko, ale jakość może ucierpieć.
- Posiadanie dedykowanych ekspertów dla każdej technologii, ale potem akceptacja ograniczeń i cięższa praca nad lepiej dopasowanymi treściami do druku. Wtedy ludzie mogą sięgać głębiej i tworzyć wspaniałe historie, ale trzeba będzie podchodzić do nich sekwencyjnie, co zajmie więcej czasu.
Słaby właściciel produktu
To niekoniecznie jest „kwestia procesu” z definicji, ale traktuję to w ten sposób tylko dlatego, że tworzenie solidnych historii można rozumieć jako proces, który zespół powinien chcieć mieć solidny i kompatybilny z zespołem programistów.
To, co rozumiem przez słabe, nie musi odnosić się do właściwości wiedzy danej osoby, ale raczej do zdolności właściciela produktu do obsługi historii zespołu, które programiści mogą zrozumieć i które mają jasny sens z perspektywy mapy drogowej produktu. Oba te elementy są bardzo ważne dla odnoszącego sukcesy zespołu scrumowego.
Jeśli w historiach brakuje szczegółów, aby programiści mogli jasno zrozumieć cel, wartość funkcjonalną lub oczekiwania techniczne, to w zasadzie mogą się zdarzyć dwa scenariusze:
- Deweloperzy zbudują coś innego niż faktycznie chciał właściciel produktu. Nawet podczas samego sprintu trudno to złapać, ponieważ przeważnie właściciel produktu nie miał możliwości śledzenia postępów w historiach na tak szczegółowym poziomie, a najczęściej PO będzie po prostu oczekiwać, że coś się wydarzy (magicznie).
- Deweloperzy będą spędzać zbyt dużo czasu na wyjaśnianiu historii i dyskutowaniu ich w kółko, zamiast zacząć je budować. Wiąże się to z wieloma dodatkowymi telefonami, wielokrotnymi uzgodnieniami i odkładaniem prac na późną fazę sprintu. Osiąga punkt, w którym pierwotne szacunki dotyczące historii nie mogą być już uważane za dokładne, a historie nie są możliwe do zamknięcia w ciągu sprintu i przechodzą do kolejnych sprintów. W najgorszym przypadku sytuacja powtarza się w kolejnych sprintach.
Czas na autorefleksję
Zwykle trudno to przyznać, ale właściciel produktu powinien znaleźć czas na refleksję, przejrzeć stworzone historie zaległości i ostatecznie porównać je z wizją mapy drogowej produktu, jeśli nadal istnieje jakiś sensowny związek między tymi dwoma – jeśli istnieje jakakolwiek mapa drogowa w ogóle. Jeśli nie, to jest to pierwsza rzecz do rozwiązania. Czasami rozwiązaniem jest przyznanie, że właściciel produktu jest zbyt daleko od zespołu i zbyt daleko od własnego celu.
W takim przypadku do rozwiązania jest część zespołu będąca właścicielem produktu. Co więcej, sprowadzenie do zespołu solidnego analityka biznesowego zorientowanego bardziej na treść zespołu niż na treść biznesową (w tym przypadku mamy już właściciela produktu w tym przypadku) może być dobrą opcją, nawet za cenę wzrost całkowitych kosztów zespołu.
Testowanie procesów bez ustalonej osi czasu
Co jeśli czynności testowe nie są ściśle związane z konkretnym harmonogramem w ramach sprintu scrumowego?
Na pierwszy rzut oka może to wyglądać na coś dobrego dla zespołu zwinnego/scrumowego. Elastyczność jest zawsze mile widziana i dobrze brzmi na zewnątrz.
Z mojego doświadczenia wynika, że rezultatem tej swobody jest więcej chaosu niż elastyczności. Nie oznacza to, że rozwiązaniem tego problemu powinno być tworzenie „wodospadów w sprincie” z dedykowanymi fazami testowania, które mają miejsce tuż po zakończeniu programowania. Nie jest to bynajmniej właściwe podejście w tym przypadku. Możesz przeczytać więcej na ten temat w moich postach na temat strategii testowania scrum i zwinnego cyklu życia testów.
Nadal możemy pozwolić sobie na pewną elastyczność i wybrać harmonogram testów, który wydaje się najbardziej odpowiedni dla obecnego zespołu programistów i danych właściwości produktu, który zespół dostarcza. Istnieją jednak dwa główne cele, które powinny zostać osiągnięte przez ten wybór:
Jeśli te warunki zostaną spełnione, zespół w naturalny sposób dostosuje się do procesu dopasowywania, a na harmonogram dostaw nie będą miały wpływu nieplanowane i przedłużające się czynności testowe.
W końcu liczy się przede wszystkim niezawodne i przewidywalne wydanie sprintu, co prowadzi mnie do ostatniego punktu tego bloga.
Niezdefiniowany proces wydania
Teraz jest to tak oczywista rzecz dla każdego zespołu scrumowego. Jednak, co ciekawe, jest to również zwykle jeden z najbardziej niedocenianych procesów.
Bardzo często zespół scrumowy po prostu mówi, że wydanie nastąpi po każdym sprincie, ale nie jest to poparte solidnym procesem. W rzeczywistości dzieje się wtedy wiele chaotycznych, nieprzewidywalnych działań, które będą miały miejsce w czasie premiery. Nagle wszyscy ludzie są zajęci „zadaniami zwalniającymi” i nikt nie jest w stanie skupić się na dalszym opracowywaniu nowych historii sprintu. Metryki sprintu są wyłączone, a wydanie wygląda jak przypadkowa, nieprzewidywalna aktywność z perspektywy trzeciej osoby (zwykle klienta).
Ludzie są tak skupieni na backlogu, treści sprintu, rozwoju, testowaniu i wreszcie pokazywaniu wyników, że zapominają, że kiedy już to wszystko skończą, następny sprint już trwa, a oni już tracą czas.
Szukasz dobrego czasu na wydanie
Więc kiedy dokładnie zespół powinien dokonać rzeczywistego wydania do produkcji? Jedyna ważna rzecz, która ma znaczenie na końcu.
Odpowiedź na to pytanie znajduje się w trakcie, zakładając, że ją masz. Zależy od:
- złożoność treści tworzonych przez zespół w sprintach,
- czas trwania sprintu,
- liczba dotkniętych komponentów w systemie
- liczbę osób korzystających i żądających zmian,
należy ustanowić proces wielokrotnego uwalniania i postępować zgodnie z nim w przyszłości. Dokładne zasady procesu mogą być znowu elastyczne w definiowaniu. Ale podobnie jak w przypadku testowania, uczynienie z niego trwałego nawyku, przewidywalnego i zaplanowanego na konkretne dni w przyszłości, sprawia, że można na nim polegać i odwoływać się do niego.
Wybory do wyboru
Możliwymi formami takiego procesu mogą być dowolne z poniższych lub inne:
- Zakończ testowanie funkcji z bieżącego sprintu podczas kolejnego sprintu i opublikuj zawartość na końcu tego sprintu (po zakończeniu testowania). Oznacza to, że każde wydanie nie będzie zawierało żadnych treści z ostatniego sprintu, ale będzie zawierało historie z dwóch wcześniejszych sprintów.
- Ostatni sprint przed wydaniem jest zawsze poświęcony testowaniu treści z poprzednich dwóch sprintów.
- Nie oznacza to, że rozwój podczas „sprintu testowego” zostanie zatrzymany; mówi tylko, że treść opracowana w tym sprincie testowym nie zostanie jeszcze uwzględniona w następnej wersji.
- Jeśli istnieje już wystarczająca liczba zautomatyzowanych działań testowych, staraj się przeprowadzać wydanie po zakończeniu każdego sprintu. W takim razie musi to być bardzo rygorystyczny proces, w którym zaangażowani ludzie skupiają się na tych kilku dniach na 100%. Nadal nie powinno to w żaden sposób wpływać na resztę zespołu programistów.
- Możesz także wybrać wydanie raz w miesiącu lub raz na N miesięcy, głównie jeśli będzie to w porządku z perspektywy użytkowników końcowych. Zwiększy to wysiłek po stronie testowania dla każdego sprintu (ponieważ zawartość będzie większa dla każdego wydania). Ale z drugiej strony będzie to oznaczać mniejszą ilość powtarzających się czynności w czasie, co w tym przypadku może przynieść zespołowi korzyści. W rezultacie może umożliwić zespołowi tworzenie większej liczby nowych funkcji między kolejnymi wydaniami, mimo że funkcje te będą faktycznie wprowadzane do produkcji z wolniejszą kadencją.
Ale jak już kilka razy wspomniano wcześniej, nie jest tak ważne, który z tych procesów zostanie wybrany. O wiele ważniejsze jest, jak dobrze zespół będzie trzymał się tego procesu i sprawi, że stanie się on trwałym nawykiem.
Możesz także przeczytać ten przewodnik po procesie i praktykach zarządzania wersjami.