• Home
  • Blog
  • Przewidywalność = efektywne wytwarzanie oprogramowania

TECHNOLOGIE, ORGANIZACJA

23.07.2021 - Przeczytasz w 9 min.

Przewidywalność = efektywne wytwarzanie oprogramowania

23.07.2021 - Przeczytasz w 9 min.

Czym jest wysoka przewidywalność zespołu, jaki ma wpływ na efektywność wytwarzania oprogramowania, czy można ją zmierzyć, nazwać? Zobacz, jakie narzędzia i rozwiązania mogą pomóc zespołowi w codziennej pracy.

Przewidywalność = efektywne wytwarzanie oprogramowania - rst

Czym jest przewidywalność?

Od kilku lat mierzymy tzw. przewidywalność zespołów Scrumowych. Przewidywalność to miara wynikająca ze stosunku punktów (z ang. story points), które dostarczane są w sprincie, do tych, które są zakładane podczas planowania. Zrealizowanie wszystkiego w sprincie oznacza przewidywalność równą 100%. W przypadku, nie ukończenia wszystkich zadań – przewidywalność spada. W przypadku, gdy coś zostanie wykonane więcej niż założono na starcie – przewidywalność również spada. Nie można być przewidywalnym na 120%.

Po co mierzymy przewidywalność?

Wiedząc, jak zespół prosperuje np. w perspektywie kwartału, można z większą pewnością planować kolejne kwartały. W przypadku, gdy przewidywalność zaczyna spadać (przez kilka kolejnych sprintów), to być może jest to odpowiedni moment, żeby zweryfikować, co się do tego przyczyniło.

Czy mierzenie przewidywalności może mieć negatywne konsekwencje?

Na potrzeby tego wpisu omówię pracę standardowo pracującego zespołu, zaangażowanego, chcącego dowozić wspólnie wytwarzane funkcjonalności. Należy mieć na uwadze, że zdarzają się sytuacje, gdzie zespoły celowo biorą mniej zadań, niż mogą wykonać, finalnie i tak dostarczając 100%. Taki zespół może również zawyżać estymaty.

Jak z tym walczyć?

Nie traktować tego jako miarę produktywności i nie porównywać między zespołami, ale bardziej jako parametr, a najlepiej jeden z parametrów pozwalających na określenie zakresu sprintu czy releasu.
 

“Tell me how you measure me, and I will tell you how I will behave”

Eliyahu M. Goldratt

 
 

Praca zespołowa kluczem do sukcesu

Poniżej znajduje się wykres przedstawiający przewidywalność w kilku ostatnich sprintach. Jak widać przewidywalność oscyluje w okolicach 100%. 

WYKRES = przewidywalność efektywność

Do takich wyników doszliśmy poprzez wielomiesięczną pracę nad sposobem efektywnego wytwarzania oprogramowania i mamy zamiar utrzymać ten poziom. W szerszym zakresie wyglądało to nieco inaczej (warto zauważyć, że trend zbliżający się do 100% nastąpił po pewnym czasie):

Przewidywalność - efektywność

Zmiany i narzędzia

Poniższe pomysły na usprawnienia to nie jest „silver bullet”, który pomoże każdemu zespołowi na świecie i nie jest odkryciem w świecie IT, ale jeśli znajdzie się choć jeden zespół, który z tego skorzysta – cała przyjemność po mojej stronie. Pomysły spisane są w kolejności losowej – nie jest to kolejność ich wprowadzania w życie.

Komandor - członek zespołu - wytwarzanie oprogramowania

Rola „Komandora”

Tajemniczo brzmiąca nazwa – zastanawialiśmy się nad nią mniej więcej tyle, ile nad każdą istotną zmienną w kodzie (czyt. długo).

Co się pod nią kryje? 

Komandorem jest osoba z zespołu, jest to rola rotacyjna, którą pełni każdy członek zespołu przez tydzień, a po tym czasie następuje zmiana.

Zadania Komandora

W każdej organizacji, podczas pracy zdalnej, możemy zostać oderwani od pracy np. poprzez komunikator. Mając przykładowo 5-osobowy zespół, czy warto, aby 5 osób zmieniało kontekst wykonywanych działań? Oczywiście, że nie, ale chcemy przecież odpowiedzieć na zadane pytanie stosunkowo szybko. Tutaj na białym koniu wjeżdża Komandor, który obsługuje większość „zewnętrznej”/poza zespołowej komunikacji, jest pierwszą linią frontu (nie bez powodu inny zespół nazywa tę rolę „Firewall”), a także reprezentuje zespół na spotkaniach, o ile to możliwe.

I to tyle?

Nie, to tylko jedna z funkcji Komandora. W życiu zespołu zawsze pojawiają się zadania, nazwijmy je ,,poboczne” (typu maintenance), jak request do administratorów, weryfikacja problemu, niewydajnych zapytań do bazy danych, czy naprawa pipeline’a CI.

Jak podejść do rozwiązywania takich zadań? 

Jeśli wyniknie ich dużo w sprincie może się okazać, że zespół zbyt mocno skupi się na zadaniach pobocznych i przez to ucierpią historie zaplanowane do wykonania.

Pomysłem na takie zadania jest utworzenie w każdym sprincie zadania – „worka” na wymienione wcześniej zadania. Pomaga to w przede wszystkim w ogarnięciu liczby zidentyfikowanych problemów czy zadań do rozwiązania. Zespół mając je w jednym miejscu, jest w stanie zadecydować, które z nich są pilne i są do zrobienia w najbliższym sprincie, a które mogą trochę poczekać. Dodatkowo mając zadanie główne („worek”)jesteśmy w stanie je wyestymować na podstawie zgłoszonych w nim zadań. W naszym przypadku staramy się dobierać liczbę zadań tak, aby Komandor miał też szansę uczestniczenia w bieżących historiach zespołu i nie spędził całego tygodnia na zadaniach pobocznych. Trzeba też brać poprawkę na to, że w trakcie sprintu mogą się wydarzyć różne rzeczy do obsługi na bieżąco – tutaj nie ma złotego środka – należy bazować na przeszłości i oszacować potrzebne zaangażowanie takiej osoby w sprawy bieżące.

Przerwidywalność zespołu a efektywność pracy

Proces Scrumowy

Daily, refinement, review, retro … Wszyscy, którzy pracowali w Scrumie doskonale wiedzą o czym mowa. Kilka z tych wydarzeń postanowiliśmy dopracować.

Daily/Checkpoint

Czy jedno daily dziennie jest wystarczające? W zespole stwierdziliśmy, że nie, ponieważ:

  • niejednokrotnie nie da się z góry zaplanować całego dnia,
  • zadania mogą okazać się większe/trudniejsze, niż zakładaliśmy,
  • możemy na bieżąco analizować czy ktoś nie ma przestrzeni na przejęcie innych zadań.

Znaleźliśmy na to receptę. Checkpoint co 2h – tryb pracy wygląda następująco:

daily – 8:30
checkpoint 1 – 11:00
checkpoint 2 – 13:00
checkpoint 3 – 15:00

Checkpoint formą jest bardzo zbliżony do daily – każdy z członków zespołu wypowiada się czym się zajmuje aktualnie i dobiera kolejne zadania.

Nie planujemy całego dnia na daily, tylko zadania do pierwszego checkpointu – jesteśmy w stanie dużo bardziej precyzyjnie określić co zrobimy przez 2-3h niż przez 8. Możemy efektywniej dobierać zadania, a zespół jest informowany na bieżąco o zadaniach innych. Dzięki równemu poziomowi wiedzy widzimy, gdy zadanie przekracza wyestymowany czas, możemy dopytać o nie lub zaproponować pomoc. Daily i checkpointy trwają 5-10 minut, dzięki temu nikt nie traci skupienia na tym co mówią inni.

Dodatkowo, aby nie zapominać o checkpointach, proponujemy wrzucić sobie jakiś komunikat na slacku/mailu/czymkolwiek, który zawoła cały zespół.

Pre Backlog refinement (Pre BR)

Mając trudności z brakiem wystarczających informacji podczas refinementu, postanowiliśmy wprowadzić do niego agendę (dostarczaną maksymalnie dzień przed), zapowiadającą tematy na kolejne spotkanie.

Dało nam to możliwość zastanowienia się i przygotowania:

  • jakie mogą być potencjalne problemy,
  • czego jeszcze nie ma spisanego, a będzie potrzebne do rozwiązania zadania,
  • jeśli są jakieś zależności do innych usług, to czy wiemy do jakich i gdzie szukać dokumentacji
    itd.

Rozwiązanie było skuteczne na moment, aż okazało się, że uczestnicy nie czytali agendy, nie mieli na to czasu. Postanowiliśmy zrobić krok dalej i wprowadzić tzw. PreBR, polegający na wewnętrznym, zespołowym spotkaniu, poprzedzającym właściwy refinement z biznesem.

Co ma on na celu?

Adresuje wyżej wymienione potrzeby – czyli zastanowienie się nad tym czego nam brakuje, spisanie do historii pytań do biznesu, które już zdążyły się zrodzić, sprawdzenie zewnętrznych usług itd. Z takim przygotowaniem, sam refinement jest znacznie sprawniejszy. Mając dobrze opisane historie, znacznie łatwiej jest nam je wyestymować. Dobra estymata pomaga naturalnie lepiej zaplanować kolejny sprint.

Refinement

Jedna historia zajmująca cały sprint? Niech pierwszy zespół rzuci kamieniem, który nie miał takiego sprintu. Długo analizowaliśmy, co powoduje, że ,,nie idzie” nam z dużymi historiami.

Jesteśmy zespołem stricte backendowym – tzn. nie dostarczamy czegoś klikalnego, czegoś co interesariusze zobaczą od razu (bez pracy innego zespołu). Dużym wyzwaniem dla nas było zaprezentowanie tego, to co zrobiliśmy, na review. Tłumaczyliśmy sobie, że oglądanie JSONów przez ludzi z biznesu nie ma za bardzo sensu. Stąd pojawiła się “mania” dużych, czasami wręcz wypełniających cały sprint, historii. Wszystko po to, aby dać coś namacalnego klientowi.

Często nie udawało nam się dowozić tej jednej historii, ze względu na jej złożoność. W jednym z kwartałów doszło do kuriozalnej sytuacji, gdzie nie zrealizowaliśmy w pełni założeń 5 z 6 sprintów, równocześnie dowożąc cel kwartalny (cały czas goniliśmy spadek z poprzedniego sprintu, aż na końcu była mniejsza część do zrobienia i udało się oznaczyć cel za spełniony).

Mimo zrealizowania założeń, czuliśmy pasmo porażek i nie potrafiliśmy określić, ile zaplanować na kolejny sprint. Dodatkowo na efekt naszej pracy czekały inne zespoły.

Jak podeszliśmy do rozwiązania problemu?

Postanowiliśmy nasze wątpliwości skonfrontować z klientem i okazało się, że nie ma niczego złego w prezentowaniu technicznych kwestii. Zaczęliśmy dzielić historię tak, żeby dostarczać mniejsze, przewidywalne fragmenty. Okazało się, że z jednej dużej historii można wyodrębnić np. 3-4 mniejsze. Obecnie skupiamy się na konkretnym, małym kawałku funkcjonalności, a to pozwala nam szybciej wyłapać niejasności, bądź niepoprawne założenia biznesowe. Mniejszy element jest łatwiej testowalny. Dodatkowo uwolniliśmy się od strategii „wszystko albo nic” – nawet w przypadku potknięcia, jesteśmy w stanie pokazać, że tak naprawdę, nie działa np. 1/5 elementów, natomiast całą resztę udało nam się zrobić. Komfort pracy jest większy zarówno dla nas jak i klienta.

Jeśli chcesz przeczytać o naszym doświadczeniu w Scrumie, koniecznie przeczytaj artykuł Łukasza Osiadłego: Korzyści i wyzwania w Scrumie.

Przewidywalność pracy zespołu architektura

„Zaplanowanie architektury”

Jako młody zespół borykaliśmy się z problemem spójnej wizji rozwiązania danego problemu. Podczas rozdzielania zadań każdy z nas brał jakiś większy element do implementacji, nad którym przeważnie spędzał 1-2 roboczodni. Szybko okazało się, że problemem jest łączenie elementów w całość, co wychodziło na jaw dopiero na etapie “code review”. Mam na myśli sytuację, gdy kilka osób realizowało tą samą funkcjonalność, myśląc, że jest odpowiedzialną osobą za implementację danego elementu. Najgorsze okazywało się niedostosowanie implementacji do potrzeby – zdarzało się, iż wykonana praca lądowała w koszu. Zdarzały się też naturalnie rozminięcia pomiędzy punktami styku – elementami implementowanymi równocześnie przez różne osoby w zespole.

Jak sobie z tym poradziliśmy?

Wprowadziliśmy zadanie ,,zaplanowanie architektury” podczas którego Komandor udostępnia ekran, pokazuje spisaną historię i wspólnie zastanawiamy się nad architekturą rozwiązania. Po chwili dyskusji komandor przechodzi do IDE (środowiska programistycznego) i zaczynamy budować szkielet rozwiązania, tak, aby mieć załatwione wszystkie istotne powiązania pomiędzy poszczególnymi elementami w kodzie, ale bez logiki w nich zawartych(!). W bardziej skomplikowanych elementach są również spisane kolejne kroki w tzw. pseudokodzie, które przewidzieliśmy do zrobienia. Tak gotowy branch (w rozumieniu systemu kontroli wersji GIT) zostaje wystawiony i każda osoba w zespole bazuje na tym, co zostało wypracowane. Minimalizuje to możliwość popełnienia błędu oraz pozwala na wyłapanie większości błędów w założeniach znacznie wcześniej. Każdy członek zespołu ma takie samo rozumienie danego zagadnienia czy problemu i o niejasnościach mówimy jednym, wspólnym językiem. Minusem jest poświęcony czas pracy zespołu. W naszym przypadku plusy znacznie przewyższyły minusy i z powodzeniem wykorzystujemy tę technikę w codziennej pracy. Takie podejście jest szerzej znane w świecie IT jako “mob programming” – jako zespół wypracowaliśmy sobie własną wersję tego podejścia, natomiast każdy powinien dostosować ten sposób pracy do siebie.

Spike / Poc

Wielokrotnie podczas refine’owania historii dochodziliśmy do momentu, w którym brakowało nam wiedzy technicznej, aby wskazać najlepsze rozwiązanie. Wtedy estymowaliśmy takie zadania, jak wszystkie inne, rozpoznając nie do końca znany nam temat, co oczywiście kończyło się z różnym skutkiem i nie było dobrym przykładem przewidywalności. Taka nieprzewidywalność mocno nam dokuczała i postanowiliśmy temu przeciwdziałać. W takiej sytuacji tworzyliśmy spike’i, będące zadaniami, mającymi na celu coś sprawdzić, potwierdzić lub odrzucić dane rozwiązanie. Taki spike był automatycznie blokerem dla danej historii – tzn. biznes otrzymywał informację, że nie wycenimy tego, dopóki nie zweryfikujemy czy rozwiązanie, które przypuszczamy za właściwe będzie miało sens. W efekcie pewniej przystępujemy do realizacji historii, ponieważ rozwialiśmy wszystkie znane nam niejasności na moment startu prac.

A co zrobić jak jednak w trakcie prac coś niespodziewanie „wybuchnie” i mamy w głowach np. 2 potencjalne rozwiązania, nie wiedząc które jest lepsze? Radzimy sobie poprzez sprawdzenie obu koncepcji (tzw. proof of concept) przez 2 różne osoby, bądź czasami 2 różne mini zespoły.

Słowo pisane, jest zapamiętane

Programistów na świecie jest wielu. Większość ma już jakieś swoje doświadczenia i przemyślenia na temat oprogramowania i poprawnie napisanego kodu. Problem pojawia się wtedy, gdy zderza się kilka światów i co najlepsze – każdy z nich może mieć rację i wszystkie rozwiązania mają sens. Dlaczego wspominam o tym we wpisie o ogólnych usprawnieniach pracy zespołów programistów? Jako zespół oczywiście różnimy się zdaniem na temat idealnego kodu. Potrafiliśmy tracić kilka godzin tygodniowo na dyskusje w zespole, na tematy powiązane z kodem. Pewnie nic strasznego by się nie stało, gdyby to działo się jednokrotnie – takie rozmowy w kwestii wyjaśnienia są jak najbardziej pożądane. Gorzej, jeżeli tak jak w naszym przypadku – problem wraca np. co miesiąc i omawiamy w zasadzie to samo co wcześniej, dochodząc do tych samych wniosków, tylko tyle, że mamy o godzinę mniej czasu w sprincie. Od jakiegoś czasu postanowiliśmy, że rezultaty takich „sporów” zapiszemy w jedno miejsce z zespołowymi zasadami pracy z kodem. W razie kolejnej dyskusji na ten temat będzie można się odwołać w tamto miejsce i uciąć dyskusję na samym początku. Jak na razie – podejście zdaje egzamin.
 

Podsumowanie

Każdy zespół jest inny i ma swoje, wypracowane metody pracy. Pytanie brzmi: czy zespół jest efektywny w tym co robi? Czasami warto coś zmienić w stylu pracy swojego zespołu. Wymienione w tym artykule sposoby pracy w przypadku mojego zespołu zadziałały – bazując na wykresach przedstawionych na początku, można zauważyć, iż praca po pewnym czasie się ustabilizowała i pozytywnie wpłynęło to na efektywność oraz przewidywalność zespołu. Powyższe tylko pokazuje, że monitorowanie „zdrowia” zespołu ma sens i może przynieść korzystny rezultat.

Czy przedstawione rozwiązania działają zawsze i wszędzie? Oczywiście, że nie, ale być może znajdzie się ktoś, komu one pomogą. Niniejszym życzę wszystkim udanego dążenia do perfekcji i budowania efektywnego zespołu – z pewnością klient/biznes doceni to, prędzej czy później.

Tagi:

Ocena artykułu

Udostępnij

Sławomir Szczurek-RST Software

Sławomir Szczurek

Developer

Absolwent wydziału Informatyki i Zarządzania na Politechnice Wrocławskiej. Od dłuższego czasu związany z językiem Java, lubi rozwiązania proste i przejrzyste, stoi na straży jakości kodu i nie tylko. Po pracy śledzi F1 i majsterkuje przy samochodach.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.