W moim poprzednim opracowaniu zainicjowałem rozważania na temat nieefektywnych nawyków, które mogą pojawić się w zespołach scrumowych, a które w konsekwencji prowadzą do trudności z terminową realizacją projektów. W tym tekście pragnę pogłębić to zagadnienie, koncentrując się na aspektach operacyjnych w obrębie zespołu.
Są one równie istotne co doskonałość techniczna. Nawet jeśli zespół składa się z ekspertów w swojej dziedzinie, nadal istnieją obszary, które mogą zaprzepaścić ich starania. Nie jest to zazwyczaj ich wina, lecz wynik decyzji zarządczych dotyczących projektów oraz zdolności do wdrożenia procesów wspierających zespół, z wyraźnie określonymi celami i przewidywalnymi działaniami.
Zespół o silnej specjalizacji
Wyobraźmy sobie zespół, w którym każdy programista jest wysoce kompetentny, niezależny i w stanie terminowo realizować zadania sprintu. Nawet w tak idealnym (choć mało prawdopodobnym) scenariuszu, zespół może mieć problem z nadążaniem za stale rosnącym backlogiem, jeśli umiejętności członków zespołu są ściśle zdefiniowane i ograniczone.
Przykłady
- W zespole jest jeden lub dwóch inżynierów DevOps, którzy potrafią dokonywać zmian w automatycznych potokach lub zarządzać usługami na platformie, podczas gdy reszta zespołu nie ma o tym pojęcia. W takim przypadku omawianie historii związanych z DevOps na spotkaniach scrumowych jest stratą czasu dla większości zespołu, ponieważ nie mogą wnieść żadnego wkładu. Analogicznie, inżynierowie DevOps nie będą zainteresowani pozostałymi zadaniami zorientowanymi na funkcjonalność.
- Gdy cały zespół ma jednego eksperta od baz danych. W zależności od złożoności i wykorzystania danych w systemie, ta osoba może być przeciążona zadaniami, których nie jest w stanie wykonać na czas. Ponadto, inne zadania będą musiały poczekać, ponieważ zależą od danych dostarczanych przez eksperta od baz danych.
- Gdy produkt jest skoncentrowany na backendzie, jedyny programista front-endu jest obecny „na wszelki wypadek”. Większość ceremonii scrumowych jest dla niego stratą czasu, ponieważ jego wiedza ogranicza się tylko do front-endu.
Konsekwencje
W każdym z powyższych przypadków, ludzie albo marnują czas, albo nie są w stanie dotrzymać terminów. Blokują reszcie zespołu możliwość rozpoczęcia nowych zadań, a ogólna efektywność zespołu spada. W sprintach pojawia się zbyt wiele niewykorzystanego czasu.
Zespół nadal ma tę samą liczbę programistów. Z zewnątrz trudno dostrzec, że niektórzy członkowie zespołu nie są w stanie podjąć się pewnych zadań ze względu na zbyt wąską specjalizację. Nie mogą pomagać innym, nawet jeśli ich umiejętności na to pozwalają, a priorytet zadań mógłby to uzasadniać.
Nawet właścicielowi produktu trudno jest stworzyć sensowny plan sprintu, ponieważ musi uwzględnić, ile osób jest w stanie pracować nad danym zadaniem. Zbyt wiele podobnych zadań wprowadzonych do sprintu w tym samym czasie może przeciążyć zespół, mimo że są ludzie, którzy mogliby je realizować, gdyby tylko mieli odpowiednie kompetencje.
Rozwiązanie dylematu
Jest to dylemat, który trzeba rozwiązać, a kierownicy projektów powinni zdawać sobie sprawę z konsekwencji dokonywanych wyborów. Należy podjąć decyzję między:
- Zatrudnieniem wielu programistów, którzy są w stanie pracować nad różnorodnymi zadaniami, ale nie są ekspertami w wielu dziedzinach. W takim przypadku tempo pracy może być szybkie, ale jakość może na tym ucierpieć.
- Zatrudnieniem ekspertów w poszczególnych technologiach, akceptując ograniczenia i dążąc do lepszego dopasowania zadań do ich umiejętności. W takim przypadku ludzie mogą tworzyć wysokiej jakości rozwiązania, ale proces będzie sekwencyjny i zajmie więcej czasu.
Nieskuteczny właściciel produktu
Nie jest to typowy problem „procesowy”, ale traktuję go w ten sposób, ponieważ tworzenie solidnych zadań jest procesem, który powinien być usprawniany i dostosowany do zespołu programistów. Przez „nieskutecznego właściciela produktu” nie rozumiem brak wiedzy, ale raczej niezdolność do dostarczania zespołowi zadań, które są zrozumiałe i mają sens w kontekście mapy drogowej produktu. Oba te aspekty są istotne dla sukcesu zespołu scrumowego.
Jeśli zadaniom brakuje szczegółów, uniemożliwiając programistom zrozumienie celu, wartości lub oczekiwań, mogą wystąpić dwa scenariusze:
- Programiści zbudują coś innego niż oczekiwał właściciel produktu. Trudno to zauważyć w trakcie sprintu, ponieważ właściciel produktu często nie śledzi postępów w detalach i oczekuje, że wszystko „magicznie” się wydarzy.
- Programiści spędzą zbyt dużo czasu na wyjaśnianiu i omawianiu zadań, zamiast je realizować. Powoduje to dodatkowe konsultacje, wielokrotne ustalenia i opóźnienia w rozpoczęciu pracy. Pierwotne szacunki czasu pracy przestają być trafne, a zadania nie są zamykane w sprincie i przechodzą do kolejnych. W najgorszym przypadku sytuacja powtarza się w kolejnych sprintach.
Czas na refleksję
Właściciel produktu powinien poświęcić czas na refleksję, przeanalizować zadania i porównać je z wizją mapy drogowej produktu. Jeśli nie ma spójności, jest to pierwszy problem do rozwiązania. Czasem rozwiązaniem jest przyznanie, że właściciel produktu jest zbyt odległy od zespołu i od samego produktu.
W takim przypadku trzeba przeanalizować rolę właściciela produktu w zespole. Rozwiązaniem może być zatrudnienie analityka biznesowego zorientowanego na treść, co może wiązać się z wyższymi kosztami, ale może poprawić efektywność zespołu.
Testowanie bez harmonogramu
Co się stanie, gdy testowanie nie jest ściśle powiązane z harmonogramem w sprincie scrumowym?
Na pierwszy rzut oka może to być korzystne dla zespołu zwinnego. Elastyczność jest zawsze cenna i dobrze brzmi w teorii.
Z mojego doświadczenia wynika, że takie podejście prowadzi raczej do chaosu niż elastyczności. Nie oznacza to, że rozwiązaniem jest tworzenie „wodospadu w sprincie” z dedykowanymi fazami testowania po zakończeniu programowania. Nie jest to właściwe podejście. Możesz więcej przeczytać na ten temat w moich artykułach na temat strategii testowania scrum i cyklu życia testów.
Można zachować elastyczność i wybrać harmonogram testów, który najlepiej odpowiada zespołowi i charakterystyce produktu. Warto jednak pamiętać o dwóch celach:
Jeśli te warunki zostaną spełnione, zespół dopasuje się do procesu, a na harmonogram dostaw nie będą wpływać nieplanowane testy.
Najważniejsza jest niezawodna i przewidywalna realizacja sprintu, co prowadzi mnie do ostatniego punktu tego tekstu.
Niezdefiniowany proces wydania
Dla każdego zespołu scrumowego to oczywista kwestia, ale jednocześnie jest to jeden z najbardziej niedocenianych procesów.
Często zespół deklaruje, że wydanie nastąpi po każdym sprincie, ale nie jest to poparte żadnym konkretnym procesem. Powoduje to chaos i nieprzewidywalne działania w momencie wydania. Wszyscy są zajęci „zadaniami wydaniowymi” i nikt nie może skupić się na rozwijaniu nowych zadań sprintu. Metryki sprintu są zakłócone, a wydanie wygląda na przypadkowe z perspektywy klienta.
Ludzie są tak skoncentrowani na backlogu, zadaniach, rozwoju, testowaniu, że zapominają, że po zakończeniu tego wszystkiego, następny sprint już trwa, a zespół traci czas.
Kiedy jest dobry czas na wydanie?
Kiedy zespół powinien wydać oprogramowanie do produkcji? To najważniejsze pytanie.
Odpowiedź na to pytanie kryje się w procesie wydania, o ile taki istnieje. Zależy on od:
- złożoności zadań realizowanych przez zespół w sprintach,
- czasu trwania sprintu,
- liczby komponentów dotkniętych zmianami,
- liczby użytkowników korzystających z systemu i zgłaszających zmiany,
Należy opracować proces wydawania i konsekwentnie go stosować. Zasady procesu mogą być elastyczne, ale podobnie jak w przypadku testów, ważne jest, aby proces ten był przewidywalny i realizowany w określonych dniach w przyszłości.
Możliwe podejścia
Możliwe podejścia to:
- Zakończenie testów z bieżącego sprintu w następnym sprincie i publikacja treści na jego zakończenie. W takim przypadku wydanie nie będzie zawierało żadnych elementów z ostatniego sprintu, ale z dwóch poprzednich.
- Ostatni sprint przed wydaniem jest zawsze przeznaczony na testowanie elementów z poprzednich dwóch sprintów.
- Rozwój podczas „sprintu testowego” nie jest wstrzymywany, tylko treści z tego sprintu nie wchodzą w skład następnego wydania.
- Jeśli automatyzacja testów jest wystarczająca, wydanie może odbywać się po zakończeniu każdego sprintu. W takim przypadku proces musi być rygorystyczny, a zaangażowane osoby powinny być maksymalnie skoncentrowane. Nadal nie powinno to wpływać na resztę zespołu.
- Można również wybrać wydanie raz w miesiącu lub co N miesięcy. Zwiększy to wysiłek w testowanie, ale z drugiej strony zmniejszy liczbę powtarzalnych czynności i potencjalnie pozwoli zespołowi na tworzenie większej liczby nowych funkcji między kolejnymi wydaniami.
Ważniejsze od wyboru konkretnego procesu jest to, jak zespół będzie się go trzymał i jak stanie się on trwałym nawykiem.
Zapraszam również do lektury przewodnika po procesach i praktykach zarządzania wersjami.
newsblog.pl
Maciej – redaktor, pasjonat technologii i samozwańczy pogromca błędów w systemie Windows. Zna Linuxa lepiej niż własną lodówkę, a kawa to jego główne źródło zasilania. Pisze, testuje, naprawia – i czasem nawet wyłącza i włącza ponownie. W wolnych chwilach udaje, że odpoczywa, ale i tak kończy z laptopem na kolanach.