Macierz dojrzałości, czyli jak usprawnić proces tworzenia oprogramowania w całej organizacji

Na początku mojej drogi managera otrzymałem od dyrektora z USA pewne zadanie. Polegało ono na tym, aby zbadać w jakim miejscu są nasze zespoły deweloperskie pod względem zarządzania jakością w kilku różnych lokalizacjach. Chcieliśmy się dowiedzieć, czy mają odpowiednie dokumenty, czy używają tych samych standardów i co najważniejsze, czy wszystkie stosują się do tych samych reguł. Zostałem poproszony nie tylko o przeprowadzenie analizy i zbadanie sytuacji, ale także o uspójnienie całości w ramach gildii QA. Wtedy pierwszy raz użyłem czegoś, co nosi nazwę macierzy dojrzałości.

Krzysztof Turowski. SDN R&D Manager w EXATEL. Manager z silnym nastawieniem na zapewnienie jakości oraz zwinnym doświadczeniem. Promuje podejście służebnego przywództwa w zarządzaniu zespołem. Budując zespoły Stawia na ludzi, odkrywając ich ukryte talenty. Fan BDD i automatycznych testów z przekonaniem, że cały zespół jest odpowiedzialny za sukces produktu. W EXATEL odpowiada za zespoły R&D w obszarze SDN. Wolne chwile spędza w lesie.

Moja pierwsza macierz była dosyć prosta i bazowała na około dziesięciu pytaniach. Pytałem o procent automatyzacji testów, pokrycia kodu, czas pełnego cyklu uruchomienia automatyzacji, czy sposobu konfiguracji środowisk i deploymentu. Jej wypełnienie nie zajmowało zbyt wiele czasu, ale było wymagające pod względem pozbierania całości informacji. Wynik tego wysiłku był podstawą do dyskusji nad jakością nie jednego, czy dwóch zespołów developerskich, a całości departamentu wytwarzania oprogramowania w kilku krajach.

Był też początkiem wielu nowych i dobrych procesów, które znacznie ułatwiły nam życie oraz poprawiły jakość wytwarzanego oprogramowania. Pomogły nam także w zwróceniu uwagi na kilka dość ważnych i istotnych kwestii, które, jeśli nie zostałyby zaadresowane, w przyszłości mogłyby nas wiele kosztować.

Czym tak naprawdę jest macierz dojrzałości? Pierwsze wzmianki o macierzy pojawiły się w roku 1979 w książce Quality is Free autorstwa Philipa B. Crosbyego. Jest stałym elementem modelu oceny procesu wytwórczego CMM/CMMI, jednak spokojnie, nie musisz mieć stosu certyfikatów, aby móc używać takiej czy innej macierzy w swojej pracy. Wystarczy, że zrozumiesz zasadę działania, zależności jakie tam występują i postarasz się uczciwie zbadać dojrzałość Twoich zespołów, aby następnie wspólnie zacząć dyskusję nad usprawnieniami i zmianami.

Samo to już jest w pewnym stopniu sukcesem, bo często otwiera oczy na aktualny stan procesów, który może okazać się inny niż wielu może się wydawać. Zarówno jako manager, scrum master czy product owner, jak i sam zespół będziecie świadomi miejsca, w którym jesteście, jak i drogi, która jest przed Wami.

W sieci możemy spotkać bardzo wiele przykładów mini macierzy dojrzałości. Często okraszone są przeróżnymi grafikami czy to rosnącego drzewa, czy schodów, na których końcu czeka na nas puchar np. mistrza jakości.

Źródło: scnsoft.com

Są mało dokładne, nie wnoszą zbyt wiele. Ich wykonanie zajmie nam czasem nie więcej niż kilka minut i w gruncie rzeczy zaproszenie zespołu na wykonanie takiej macierzy przyniesie mocno odwrotny sposób niż planowany. Nie zrozum mnie źle, to dobrze, że takie ćwiczenia się pojawiają, są to jednak mini aktywności przy porannej kawie, a nie coś na czym uda się zbudować coś więcej.

Właściwa macierz dojrzałości

Źródło: scnsoft.com

Właściwe macierze dojrzałości, na które powinieneś zwrócić uwagę są znacznie większe, bardziej dokładne, wymagają poświęcenia znacznie większej ilości czasu i czasem jeden drobny punkt z listy potrafi być wyzwalaczem do naprawdę sporej dyskusji. Macierz powinna być na tyle dokładna i szczegółowa, aby można było w jasny sposób określić miejsce, w którym jesteśmy i cel, do którego zmierzamy.

Macierz dojrzałości, na której obecnie pracuję powstawała latami. Początkowo liczyła dziesięć a następnie kilkanaście pytań dotyczących ogólnego podejścia do testów i jakości wytwarzanego oprogramowania. Ocenialiśmy w skali od 1-5, gdzie 1 to poziom, gdy coś jest trudne, skomplikowane, niezrozumiałe lub nie istnieje, a 5 to poziom idealny, do którego dążymy.

W macierzy pytałem się zespołów zarówno o tak proste rzeczy, jak chociażby bug triage po metryki dotyczące automatyzacji. Wnikałem w szczegóły, dopytywałem, starałem się, aby każde z pytań dotykało szczegółów zagadnienia i powodowało dyskusję. Bo niby o czym szczególnym chcemy rozwiać przy takim procesie jak chociażby bug scrub? Oto jak wygląda dojrzałość w procesie triage dla bugów.

Bug triage:

1. Prowadzony poza zespołem programistów w miesięcznych cyklach. Zespół otrzymuje listę defektów.
2. Prowadzony poza zespołem programistów w cyklach dwutygodniowych. Wymagana obecność członka zespołu deweloperskiego i managera lub product ownera.
3. Prowadzony przez managera lub ownera z zespołem programistów w cyklach dwóch tygodni.
4. Prowadzony przez product ownera z zespołem programistów w cyklach co tygodniowych.
5. Prowadzony przez zespół, codziennie lub ad hoc z pomocą product ownera.

Zobacz, już nawet jedno pytanie o bug scrub z tak skonstruowanymi poziomami i ocenami, otwiera drzwi do dużej dyskusji dotyczącej jakości naszego oprogramowania i naszej dojrzałości.

Proste pytanie, które otwiera dyskusję

Pierwsze i najważniejsze to, czy aby na pewno wiemy ile i jakich bugów mamy w systemie i czy jako zespół developerski mamy nad nimi kontrolę? Kto tak naprawdę odpowiada za to co powinniśmy, a czego nie powinniśmy naprawiać? Jak bardzo pewni jesteśmy tego jak wygląda lista naszych defektów? Które defekty są bardzo ważne, a które mniej? Które defekty są aktualne i czy nie tracimy czasu na coś, co nie jest dla nas ważne i istotne, a usilnie stara się naprawić coś, co zostało zgłoszone przez kogoś z zewnątrz zespołu ponad miesiąc temu, co dawno już zostało naprawione? Kto decyduje, które bugi i kiedy trafiają na naszą tablicę?

Tylko jedno pytanie o tak niewielką rzecz jak bug scrub może naprawdę rozwiązać worek z pytaniami i tematami do dyskusji. Teraz, wyobraź sobie, że pytamy o nieco szersze otoczenie dotyczące jakości:

• Jak wygląda kwestia testów akceptacyjnych?
• Jak wygląda kwestia testowania całości produktu?
• Czy mamy test case managera, a jeśli tak to jaka jest jego forma?
• Ile trwają testy?
• Czy testujemy holistycznie?
• Jak wyglądają raporty?
• Czy mamy standardy testowania?

To dosyć ogólne zagadnienia, ale każdy z nich to oddzielne zagadnienie i każde ma swoje pięć poziomów dojrzałości. Test case manager wydaje się być również oczywistym i prostym tematem, ale wiele osób i zespołów ma do niego różne podejście. Dla jednych będzie to set testów spisanych w notepadzie, dla innych excel ze wszystkimi przypadkami testowymi a mistrzowie będą zarządzali przypadkami testowymi, które będą uruchamiane i wykonywalne za pośrednictwem Gherkina. W ten sposób każdy, wliczając w to interesariuszy, będzie w stanie w dowolnym momencie przetestować całość systemu.

Oferty pracy z

Teoretycznie każdy z powyższych zarządza testami, ale naprawdę dojrzałe podejście to automatyzacja i przekazanie dostępów interesariuszom. Nie muszą uruchamiać naszych testów, ale wystarczy sam fakt, że mogą to zrobić, a wtedy ich zaufanie do zespołu będzie znacznie większe niż gdyby usłyszeli że testy są u kogoś w notatniku.

Dodatkowo, dotykając automatyzacji otwieramy całkiem nowe drzwi:

• Jaki procent automatyzacji posiadamy?
• Jak wygląda pokrycie unit testami, jak postępujemy z tzw. flaky testami?
• Jak wygląda nasze środowisko testowe i jak trudno / prosto się go używa?
• Jak wygląda wdrażanie deweloperów w testowanie automatyczne?

Już moja pierwotna macierz przy każdym z pytań otwierała kilka nowych wątków i dyskusji, uświadamiając nam jak wiele wciąż możemy zmieniać. Co ważne zespoły, z którymi to wykonywaliśmy przy pierwszej jej wersji, pracowały wspólnie od dość długiego czasu, na działającym produkcyjnych systemach, które dobrze funkcjonowały. Nie funkcjonowaliśmy źle, ale spotkanie, na którym wypełnialiśmy macierz dojrzałości pokazywało nam, że możemy działać znacznie lepiej, co przekładało się na lepszą jakość i lepszy produkt.

Taka macierz jest idealnym narzędziem wyjścia do rozmowy nie tylko z zespołem, ale także z przełożonym o budżecie i potencjalnych koniecznych zakupach. Nie powinniśmy oszczędzać na jakości, więc dzięki wynikom byliśmy w stanie jasno zidentyfikować potrzeby – sprzęt, środowisko, narzędzia i oczywiście kompetencje, czyli ludzie.

Po pewnym czasie moja macierz ewoluowała. Doszły zupełnie nowe kategorie i pytania – Podejście do produktu, dobre praktyki inżynieryjne, dynamika, środowisko i otoczenie zespołu oraz zwinność zarówno w postaci dobrych praktyk, jak i samej mechaniki agile. Wiele pytań była i jest bardzo oczywista i często odpowiedzią było “no tak, wiemy od tym od dawna, ale nigdy nie było okazji, żeby poruszyć ten temat lub czasu, aby to zrobić”. Przy niektórych pytaniach pojawiało się sporo zależności. Dotykały one często innych osób, ról, zespołów, ale także i finansów niezbędnych do zakupów, aby móc lepiej zarządzać środowiskami testowymi.

Definition of done

Dzisiaj, w ramach macierzy pytam o bardzo wiele rzeczy od kwestii takich jak morale, teamwork, czy etapy Tuckama. Pojawiają się pytania o rozmiar teamów, kolokację, samoorganizację i ciągłość. Pytam o czas dostarczenia funkcjonalności (od pomysłu do wdrożenia), jak bardzo historię użytkownika są utrzymane w duchu INVEST. Nawet coś tak oczywistego jak definition of done ma swój poziom dojrzałości. Od poziomu “Nie istnieje” przez “istnieje zrozumienie potrzeby zdefiniowania definition of done i / lub istnieje milcząca zgoda co do jej treści”, przez “istnieje mocna, jasna, kompleksowa (ale prosta) definicja ukończenia, która jest wynikiem współpracy większości członków, zgody i wkładu wszystkich, i jest publikowana”. Do najwyższego poziomu “na miejscu, kompleksowa, okresowo przeglądana i aktualizowana, ściśle przestrzegane”.

Zatem jeśli jako zespół chcesz utrzymać wysoki poziom swojej oceny, musisz od czasu do czasu przejrzeć nie tylko swoje otoczenie, ale także definition of done, definition of ready, oraz to jak wygląda podejście do retro, refinementu lub nawet standupów.

Dzisiejsza macierz, której używam bardzo mocno ewoluowała i składa się z prawie 50 pytań. Oczywiście nie jest to konieczne, aby zawsze używać wszystkich i tych samych pytań. Czasem ograniczam się do części, bowiem wszystko zależy od potrzeby i tego, co i gdzie chcemy zmieniać. Nie wszystkie pytania będą pasowały do każdego zespołu, bowiem często zależy to też od tego, w jaki sposób pracują.

Zespoły, z którymi pracowałem czy to bezpośrednio jako manager, czy to pośrednio, jako osoba z zewnątrz, dzięki tej macierzy przechodziły swego rodzaju transformację. Często na podstawie macierzy wyznaczyliśmy wspólnie realne, S.M.A.R.N.-ne cele i zakasywaliśmy rękawy, aby poprawić nasz wynik. Dlaczego nasz? Dlatego, że jeśli odpowiadasz za zespół i chcesz rozmawiać o dojrzałości i przeprowadzić takie ćwiczenie to musisz pamiętać, że to także Twój wynik.

Jeśli jesteś osobą z zewnątrz, która wchodzi w roli eksperta i nadzoruje przeprowadzenie macierzy to nie możesz zostawiać zespołu samego sobie i poprzestać jedynie na przeprowadzeniu samej macierzy. Za tym muszą iść kolejne kroki i akcje. Musisz być dla nich wsparciem, oparciem a także mentorem. Czasem macierz może pokazać też pewne ułomności.

Macierz, jak każde narzędzie może zostać także niewłaściwie wykorzystana. Jeśli bowiem ktoś np. szef zespołu na podstawie jej wyników zamierza kogoś ukarać, to jest to najgorszy kierunek jaki można wybrać. Jeśli chcesz karać i szukać winnych zacznij od siebie i na sobie poprzestań. Zespół natomiast powinien otrzymać od Ciebie wsparcie, powinieneś wsłuchać się w niego i zrozumieć skąd i dlaczego taki wynik, oraz doradzić, co zrobić, aby wynik ten poprawić.

Czy macierze dojrzałości mają sens?

Czytałem też opinie, że macierze dojrzałości nie mają sensu. Osoby, które tak się o nich wypowiadały w moim przekonaniu miały błędne założenia. Niewłaściwie bowiem zakładamy, że można ją zrobić w 4 minuty przy porannej kawie, a dojrzałości zespołu nie trzeba badać, bo przecież wszyscy jesteśmy dorośli i nie powinniśmy mieć problemów ani z testami, ani ze scrumem, ani z całym procesie wytwarzania oprogramowania.

Niestety jesteśmy tylko ludźmi i każdy z nas może popełnić pewne pomyłki. Gdyby świat wytwarzania oprogramowania był idealny nie potrzebowalibyśmy setek książek, szkoleń, certyfikatów a określenie “gaszenia pożarów” odnosiłoby się tylko do czerwonego wozu strażackiego a nie pracy w IT.

Ciężko mi określić, gdzie byłyby moje zespoły, z którymi na bieżąco pracuję, gdyby nie macierz dojrzałości. Wiem, że wystarczyło pół roku i dwa cykle abyśmy bardzo mocno się rozwinęli, zmienili nasze praktyki, zidentyfikowali nasze słabe i mocne strony, oraz świadomie określili sobie cel i drogę, którą chcemy zmierzać. Dzisiaj nie wyobrażam sobie tego, aby nie używać tego narzędzia przy pracy jako manager.

Ważne, że taką macierz można zastosować w wielu różnych rodzajach zespołów i można dostosowywać je do całej organizacji. Jeśli szukasz sposobu na postawienie goli czy OKRów to zacznij używać narzędzia jakim jest macierz dojrzałości. Poszukaj dobrych wzorców, użyj jej do transformacji swoich zespołów i zapewnienia między nimi zarówno spójności jak i rozwoju. Nie ważne czy jesteś developerem, scrum masterem, agile coachem, managerem czy CIO. Używaj tego narzędzia i zachęcaj swoich współpracowników do poszerzania swoich horyzontów i rozwijania skrzydeł.

Pamiętaj też, że sama macierz jest jedynie punktem wyjścia. To co zrobisz dalej w dużej mierze zależy od Ciebie. Na wyciągnięcie ręki dostępna jest bowiem cała masa gotowych rozwiązań czy ćwiczeń, które pomogą zarówno Tobie, jak i Twoim zespołom. Wystarczy tylko chcieć.

Dobry przykład macierzy dojrzałości znajdziecie na tej stronie w dokumencie Agile Maturity Matrix for Teams.

Zdjęcie główne artykułu pochodzi z unsplash.com.