Metryki sprzyjające zwinności. Project Managera skrzynka z narzędziami, cz. XIII

Najlepsze praktyki, wymiana wiedzy, dobre rady, przydatne narzędzia – wszystko to znajdziemy w książkach o zarządzaniu projektami, blogach i artykułach umieszczanych w sieci, w odpowiedziach kolegów i koleżanek z pracy czy podczas spotkań branżowych na konferencjach i innych wydarzeniach. Z jednej strony wszystko to jest łatwo dostępne, z drugiej ciągle czegoś szukamy. Nadal poszukujemy idealnych narzędzi, które pomogą nam zakomunikować albo nawet rozwiązać nasze projektowe wyzwania. I choć często są one bardzo pomocne, zdarza się nam zapomnieć, że najlepsze są te najprostsze, czasem wręcz banalne. W tym numerze chciałabym poruszyć temat przydatnych metryk oraz sposobu ich wykorzystywania w projektach realizowanych zwinnie.

---

Miara sukcesu

Siódma zasada Agile mówi, że podstawową miarą postępu jest działające oprogramowanie. To właśnie gotowy, działający produkt powinien być naszą podstawową metryką, gdy pracujemy wykorzystując zwinne podejście. Spełniając kryteria definicji ukończenia (DoD – Definition of Done) danej funkcjonalności wiemy jak nam idzie. To w zasadzie powinno wystarczyć, jednak sami wiemy z własnego doświadczenia, że nie zawsze tak jest i często musimy pokazywać o wiele więcej z różnorakich powodów.

Ważny jest cel

Metryki oraz ich graficzna prezentacja potrafią zdziałać wiele. Muszą być odpowiednio dobrane do naszego projektu, zespołu czy firmy. Ważne jest także to, aby były zrozumiałe przez ich odbiorców. Będąc w roli Scrum Mastera, Agile PM-a, Release Train Engineera, czy innej podobnej roli, w ramach której wspieramy zespół pracujący zwinnie, spoczywa na nas obowiązek transparentnej komunikacji pomiędzy zespołem, a Właścicielem Produktu (PO – Product Owner) i interesariuszami. W agile’owym podejściu dużo mówi się o transparentności, czyli byciu przejrzystym. Metryki w tym kontekście powinny być zatem takie same dla wszystkich. Mają pokazywać jaki jest postęp prac i jakość tego co robimy. Nie powinniśmy nimi manipulować i fałszować faktycznego stanu rzeczy. Pamiętajmy, że tak zwane malowanie trawy na zielono nigdy nie przynosi nic dobrego, a z własnego projektowego ogródka wiem, że można nawet zły stan projektu przedstawić kilkoma grafami tak, aby inni zobaczyli że jest całkiem dobrze i ukryć to, co niewygodne.

Dzięki metrykom możemy komunikować interesariuszom obecny stan, ale też prognozować przyszłe rezultaty. Pomagają nam one także w prezentacji dostarczanej jakości, a co najważniejsze: ich analiza może okazać wyjątkowo pomocna w identyfikowaniu najistotniejszych problemów, które – jeśli rozwiążemy – powinny przyczynić się do poprawy jakości, prędkości lub terminowości dostarczania. Metryki pomogą również zespołom w planowaniu kolejnych iteracji, sprawiając że przewidywalność dostarczenia będzie większa, a tym samym sam zespół bardziej wiarygodny. Dzięki nim możemy łatwiej zbudować dobre relacje i zdobyć zaufanie kluczowych interesariuszy, a w takim otoczeniu zawsze pracuje się dużo przyjemniej.

Podstawowe mierniki

W Scrumie najbardziej powszechną i podstawową miarą jest prędkość zespołu (ang. velocity). Jest to suma wszystkich estymat dla poszczególnych historyjek użytkownika lub zadań, które zespół ukończył w danym sprincie. Ważne, aby zespół określił co estymuje, a czego nie. W większości zespołów, z którymi pracowałam, najczęstszymi przypadkami elementów niewycenianych były błędy, zadania techniczne związane z dostępnością środowisk, itp. Najogólniej chodzi o pracę, którą trzeba wykonać, ale nie jest ona wartością dodaną dla budowanego produktu. Naszym celem jest uzyskanie równej prędkości zespołu, dzięki czemu łatwiej jest nam komunikować co i kiedy będziemy w stanie dostarczyć, a także wywiązywać się ze swoich zobowiązań (ang. commitment). Zmierzone i stabilne velocity ułatwia zespołowi planowanie.

Przepustowość lub zdolność zespołu (ang. capacity) to kolejny ważny miernik, bez którego zespół zwyczajnie nie będzie w stanie dobrze zaplanować kolejnych iteracji. Capacity zespołu powinno być weryfikowane co sprint. Może ono być różne ze względu na wiele czynników. Licząc je powinniśmy zweryfikować dostępność poszczególnych członków zespołu (np. urlopy, szkolenia, zwolnienia lekarskie), ilość błędów, technicznych zadań do wykonania, wsparcie produkcji, czy wdrożenia oraz wszelkich innych aktywności, które mogą obniżyć dostępność zespołu w stosunku do zadań, nad którymi pracują by zrealizować swój cel sprintu. Capacity jest miernikiem, który musimy zawsze stosować i przedstawiać razem z velocity zespołu. Tylko wtedy jesteśmy w stanie wiarygodnie planować i przedstawiać to co udało nam się zrealizować. Bardzo pomocne w obliczaniu capacity zespołu są kalkulatory w Excelu bądź innym narzędziu, które pozwoli nam szybko policzyć, ile punktów może zespół wziąć w danym sprincie. Im dłużej pracujemy z zespołem, tym łatwiej będzie nam wprowadzić średnie wartości dla poszczególnych elementów, które zmniejszają przepustowość zespołu.

Przewidywalność (ang. predictability) zespołu, którą pokazujemy wynikiem procentowym, jest niczym innym jak ilorazem sumy punktów ukończonych elementów w stosunku do ilości punktów zaplanowanych. Im bliżej 100%, tym oczywiście wyższa przewidywalność, a także zaufanie interesariuszy do powierzonej pracy. Wynik ten może również być wyższy 100% – dzieje się tak, wtedy kiedy zespół dostarczy więcej niż zaplanował. SAFe^® mówi, że powinno nam zależeć na przewidywalności powyżej 80%, taki wynik możemy uznać za satysfakcjonujący. Choć przewidywalność w SAFe^® liczona jest nieco inaczej i dotyczy okresu 4-6 sprintów i sumy punktów wartości biznesowej dowiezionej vs. zaplanowanej, to jest to z pewnością kierunek jaki powinniśmy obrać dla naszych zespołów.

Dbanie o jakość

Liczba błędów. Tylko i aż tyle już pomoże nam w weryfikacji naszej jakości. Liczba zgłaszanych błędów jest źródłem danych o tym, co możemy w naszej pracy poprawić. Przy okazji retrospektywy powinniśmy przedstawiać zespołowi liczby, a także analizę związaną z przyczynami zgłaszanych błędów. Możemy również mierzyć je w zależności od częstotliwości ich występowania, kategorii czy priorytetu. Wszystkie te kryteria zawsze warto ustalić z zespołem i interesariuszami, aby mieć spójne dane. Nieraz pewnie spotkaliśmy się z tym, że ktoś zakłada nam na przykład wyłącznie krytyczne błędy, bo chce aby zostały one szybko naprawione. Nierzadko zdarzają się także błędy, które de facto są nowymi wymaganiami i je powinniśmy odrzucać, pokazując także jaki procent błędów odrzucamy i z jakich powodów, tak by unikać podobnych sytuacji w przyszłości.

Błędy można również przeliczać względem liczby wykonanych historyjek. Im niższy współczynnik, tym lepsza jakość. Możemy także z zespołem zdecydować o tym aby poza błędami oznaczać zablokowane historyjki. I tak zwane blokery (ang. impediment) również odnotowywać i transparentnie pokazywać w ramach podsumowania sprintu.

Czas rozwiązania błędów – to może okazać się zdecydowanie pomocne w przypadku pracy dla klienta zewnętrznego. Mierząc czas rozwiązywania błędów w zależności od ich priorytetów od momentu zgłoszenia do ich rozwiązania pokazujemy, że wywiązujemy się z naszych umów. Takie metryki, o ile oczywiście są dobre, mogą nam pomóc w zdobyciu nowego klienta, bo podnoszą naszą wiarygodność.

Pokrycie testami (ang. code coverage) to metryka wyrażona w procentach, która pokazuje jaka część kodu napisanego przez developerów jest zweryfikowana testami. Dobry wynik pokrycia testami z pewnością przyczyni się do mniejszej liczby zgłaszanych błędów. Metryka ta może okazać się istotna gdy chcemy właśnie zmniejszyć liczbę błędów, a do tej pory nasz zespół nie skupiał się zanadto nad testowaniem dostarczanego kodu.

Realny plan

Stosując zwinne podejście tworzymy plan w oparciu o określony budżet i czas. Zlecający projekt może określić, ile czasu nam daje i jaki budżet przeznacza na daną pracę, my – jako zespół – określamy, co jesteśmy w stanie dostarczyć w ramach powyższych ograniczeń, skupiając się oczywiście na tym, co jest dla naszego klienta najważniejsze. Jest to ogromna przewaga zwinnego podejścia względem tradycyjnego, gdzie często chcemy całość zakresu projektu mieć dostarczoną w określonym czasie i budżecie. Niezależnie czy pracujemy dla klienta zewnętrznego czy wewnętrznego, zależy nam na dowiezieniu tego, do czego się zobowiązujemy. Aby jeszcze lepiej dostarczać możemy wprowadzić dwa kolejne mierniki, które możemy analizować i na ich podstawie poprawiać się jeszcze bardziej, dostarczając wartość klientowi jeszcze szybciej.

Lead time i cycle time to dwie metryki, które przedstawione na grafach mogą nam wiele powiedzieć o naszej sytuacji i są zdecydowanie najczęstszym powodem do przeanalizowania i szukania usprawnień w naszej codziennej pracy. Dzięki temu szybciej dostarczymy wartość użytkownikom, co często przekłada się na zdobycie nowych klientów, zwiększenie udziałów w rynku, a tym samym lepsze wyniki finansowe naszej firmy. Lead time to okres czasu jaki mija od momentu zgłoszenia zadania/funkcjonalności do wdrożenia go na produkcję. Cycle time to natomiast całkowity czas pracy nad realizacją zadania lub zamówionej funkcjonalności. Pierwszy z tych parametrów bardziej interesuje klienta, bo dzięki temu wie, ile będzie mniej więcej czekał na zamówioną funkcjonalność. Natomiast drugi jest dużo bardziej interesujący dla samego zespołu, bo dzięki niemu jest w stanie zobaczyć gdzie znajdują się tak zwane „wąskie gardła” i nad czym warto pracować, aby jeszcze lepiej zoptymalizować swoją pracę.

Metryki czasu zamówienia i cyklu realizacji są bardzo ważne gdy stosujemy podejście Kanban, bez nich wręcz możemy stwierdzić, że nie pracujemy w prawdziwym Kanbanie. Ważne jest zwłaszcza dla cycle time aby na podstawie flow zespołu znaleźć te aspekty pracy zespołu, które powodują największe przestoje albo zajmują zbyt dużo czasu. Im lepiej zwizualizowana jest tablica zespołu, tym łatwiej będzie nam dojść do właściwych wniosków i pracować w pierwszej kolejności nad usprawnieniami, które znacząco wpłyną na skrócenie czasu cyklu realizacji.

Opłacalność dostarczonego rozwiązania

Koszt jednego story point (miara estymacji historyjek w Scrum) można dość łatwo policzyć. Znając koszt poszczególnych członków zespołu oraz jego prędkość możemy najpierw poznać ile kosztuje nas praca całego zespołu przez jeden sprint, a znając velocity będziemy również znali koszt dostarczenia jednego story pointa. Przydatne może się to okazać w doborze rozwiązań i priorytetyzacji kolejnych wymagań. Znając te wartości, możemy także łatwiej uzasadniać, dlaczego pewnych funkcjonalności zwyczajnie zespół nie będzie realizował, bo są zbyt drogie w stosunku do ich ważności i wykorzystywania przez użytkownika końcowego.

W przypadku skalowania, gdy pracujemy z kilkoma zespołami, możemy porównywać także ten koszt i starać się zoptymalizować koszty dostarczania. Mnie osobiście ta metryka w połączeniu z szerszą analizą pomogła w ułożeniu pracy dla pięciu zespołów i zaplanowaniu zmian, a także zwróceniu uwagi na już utopione koszty w niektórych, skomplikowanych rozwiązaniach, z którymi zespoły nie mogły sobie poradzić. Wpłynęło to na decyzję osób odpowiedzialnych za produkt o zawieszeniu dalszych prac.

Wartości i samopoczucie zespołu 

Nie od dziś wiadomo, że zmotywowany i zadowolony pracownik, to zaangażowany pracownik. Jeśli dobrze się czujemy w naszej pracy i zwyczajnie lubimy do niej chodzić, wówczas jesteśmy bardziej wydajni i efektywni, popełniamy mniej błędów i staramy się wykonać powierzone prace jak najlepiej. Tym samym nasze produkty są lepszej jakości i częściej dostarczane są w deklarowanym czasie. Stąd tak ważne jest również mierzenie tego jak się mają ludzie, z którymi pracujemy. Możemy to robić za pomocą rozmów, ankiet czy różnych innych narzędzi. Ważne by robić to regularnie i mieć jeden stały miernik, który pokaże nam, gdy zaczyna dziać się coś złego, aby w porę zareagować.

W sieci możemy znaleźć wiele inspiracji dotyczących tzw. happiness index czy też team radar albo health check. Wszystkie one pomogą nam mierzyć jak się ma nasz zespół. Jedne są mniej rozbudowane i mogą dotyczyć jedynie motywacji i samopoczucia członków naszych zespołów. Inne mogą być bardziej rozbudowane i pomocne, zwłaszcza jeśli chcemy wiedzieć, czy sposób pracy odpowiada pracownikom, a także czy pracujemy wedle ustalonych założeń. Możemy oprzeć ankietę o wartości Scruma i zapytać o to, czy wartości jakie są fundamentem naszej pracy są rozumiane i szanowane przez zespół, jak i jego otoczenie. Bardziej rozbudowana ankieta przyda się w momencie kiedy tworzymy nowy zespół, bądź decydujemy się na zmianę podejścia. Transformacja w kierunku Agile niesie za sobą dużo pułapek i żeby wiedzieć czy idziemy w dobrym kierunku warto pytać o to naszych pracowników, tak aby lepiej się komunikować, planować i wdrażać kolejne zmiany.

Przerost formy nad treścią 

Nie potrzebujemy wielu metryk, wystarczy kilka dobrych, które pokażą nam jak nam idzie, gdzie jesteśmy w danym punkcie czasu. Dobrze przygotowane grafy oraz metryki pomogą nam szybko zidentyfikować największe problemy. Ważne, abyśmy regularnie zbierali dane, udostępniali je naszym zespołom i potrafili wyciągać właściwe wnioski oraz akcje, tak by stawać się jeszcze lepszym zespołem i na końcu każdego kolejnego sprintu mogli świętować następne sukcesy. Możemy tworzyć grafy, które pokazują trendy i jak poszczególne wskaźniki zmieniały się na przestrzeni czasu. „Mniej, często znaczy więcej” – niech ta maksyma przyświeca nam przy tworzeniu raportów przedstawiających postępy naszej pracy. Już kilka prostych grafów będzie w stanie więcej zakomunikować niż wielostronicowe opisy czy kilkugodzinne konferencje. Nie zapominajmy również komunikować i świętować nawet najmniejsze sukcesy związane z lepszymi wynikami i poświęconą pracą nad ich poprawą. Nic tak dobrze nie wpływa na poprawę dostarczania czy jakości produktu, jak zasłużona pochwała i nagroda dla zespołu, choćby w postaci wspólnego wyjścia integracyjnego.