Wpis gościnny Moniki Dzingielewskiej.
„Mierz i działaj” czyli miary, metryki, statystyki i trendy
Przebrnęliśmy przez pierwszy etap cyklu Deminga, czyli planowania i powoli możemy przechodzić do drugiego etapu, czyli działania. Mamy zdefiniowane różne kryteria i raporty, według których będziemy badać i usprawniać nasz projekt – super! Co dalej? Wypadałoby zacząć z nich korzystać. Jak często? Tak często jak to jest potrzebne. A jak często jest to potrzebne? To zależy, na jakim etapie i w jakiej kondycji jest nasz projekt.
Żeby nie brnąć niepotrzebnie w kolejne pytania, krótko przedstawię jakie pomiary są szczególnie pomocne w mojej pracy na poszczególnych etapach wytwarzania oprogramowania i jak na bazie metryk możemy identyfikować i wdrażać działania naprawcze i usprawniające.
1. Przyrost funkcjonalności
Z mojego doświadczenia wynika, że pierwszym istotnym kryterium jest przyrost funkcjonalności W skrócie powinniśmy na bieżąco monitorować aktualny stan backlogu wymagań do realizacji, tzn:
- jaki procent funkcjonalności jest gotowy do realizacji a jaki wymaga jeszcze uzgodnień z klientem,
- jaki procent funkcjonalność został już zaimplementowany i przetestowany, a ile jeszcze pozostaje do realizacji,
- jakie są odchylenia od planu (zarówno jeśli chodzi o terminy jak i koszty).
Oczywiście możemy to mierzyć wg dostępnych nam kryteriów – czasem bazujemy tylko na liczbie wymagań w backlogu, czasem dysponujemy przygotowanym wcześniej planem realizacji zdefiniowanego zakresu z oszacowaną pracochłonnością (w osobodniach, story points, czy dowolnych innych jednostkach). W zależności też od charakterystyki i złożoności projektu dane te można podawać całościowo (w odniesieniu do całego zakresu funkcjonalnego), lub też podzielone względem określonych grup funkcjonalnych, modułów, wydań.
Co dają nam takie metryki?
Możemy:
- szybko zidentyfikować, gdzie pojawiały się rozbieżności względem planu bazowego i jaki wpływ mogą one mieć na ewentualne opóźnienia w projekcie,
- określać tempo pracy zespołu realizacyjnego (jego przepustowość) i lepiej przewidywać termin zakończenia prac projektowych,
- identyfikować niespodziewane przyrosty wymagań,
- wychwycić wąskie gardła, czyli miejsca, w których nasza praca utyka lub jest realizowana nieoptymalnie.
Te wszystkie czynniki umożliwiają wczesne identyfikowanie obszarów wymagających podejmowania bieżących akcji naprawczych, zanim miał szansę wybuchnąć w naszym projekcie „pożar”. Dzięki temu, stosunkowo niewielkim nakładem pracy możemy przygotować czytelny raport dla Klienta, Kierownika Projektu, czy innego interesariusza i w porozumieniu z nim ustalić priorytety dla poszczególnych funkcjonalności, wprowadzić procedury zapewniające lepszą kontrolę zakresu, podjąć decyzję o wzmocnieniu i\lub odciążeniu jakiegoś zespołu, czy też zidentyfikować powtarzalne czynności, które mogą zostać zastąpione przez automatyczne mechanizmy (np. automatyczne wydawanie wersji na środowisko testowe).
Również gospodyni piekąca ciasto, gdy wie, co już zostało wykonane, a co jeszcze ją czeka, dobrze wie także, w których obszarach przyspieszyć, a jeśli jest to niemożliwe potrafi określić, na którą godzinę przełożyć spotkanie z gośćmi.
2. Niezawodność oprogramowania
Choć niezawodność oprogramowania to szerokie pojęcie, ja skupię się tylko na jednym jego aspekcie, a mianowicie na liczbie i rodzaju defektów. Cóż nam po tym, że zaimplementowaliśmy większość funkcjonalność skoro jest ona kompletnie niezdatna do użycia i nie może być wdrożona u Klienta.
Szczególnie ciekawe mogą być tu:
- trendy zgłaszania i naprawiania defektów w danym odcinku czasu, pozwalające ocenić wyporność i intensywność prac na poszczególnych etapach projektu
- liczba otwartych defektów, uwzględniając ich priorytet
Analiza takich zależności umożliwia odpowiednie sterowanie i obciążanie pracą w zespołach, tak, aby z jednej strony układać jak najbardziej realistyczne harmonogramy, a z drugiej strony kłaść nacisk na jak największe wykrywanie defektów na wczesnym etapie testów wewnętrznych (zanim klient będzie miał szansę ocenić jakość naszego produktu). Warto również pamiętać, jak głoszą wszelkie mądrości (chciałoby się rzec ludowe), że wraz z upływem czasu, koszt poprawy defektów dość znacząco rośnie.
Widząc, że mamy dużo defektów możemy ponownie zweryfikować, czy przyczyną jest jakiś problem na etapie samej implementacji (np. naciski na nierealny termin), zbyt duża liczba jednocześnie realizowanych zadań, czy niejasno zdefiniowane priorytety. A może się również okazać, że błędy to tak naprawdę nowe wymagania lub błędy specyfikacji wymagań.
Dzięki analizie takich danych możemy tymczasowo wstrzymać implementację nowych funkcjonalności by zlikwidować dotychczasowy dług techniczny, wprowadzić lepsze standardy dotyczące opisu błędu (tak, aby jego obsługa była jak najkrótsza), czy może nawet dodać automatyczne testy dla najbardziej problematycznych obszarów, które pozwolą wykryć błędy zanim wersja oprogramowania trafi do testów.
Dlatego gospodyni najpierw próbuje surowego ciasta, aby ocenić czy jest wystarczająco słodkie, bo wiadomo, że posypywanie cukrem już upieczonego ciasta może nie przynieść oczekiwanych efektów, a na nowy wypiek może zwyczajnie nie starczyć ani czasu, ani składników.
Zobacz wszystkie wpisy z serii:
Monika Dzingielewska – kierownik zespołu programistów
Moje doświadczenia skupia się głównie wokół koordynowania prac zespołów programistycznych w dużych i złożonych projektach informatycznych. Od początku pracy zawodowej fascynują mnie zagadnienia związane z procesem wytwórczym, planowaniem wydań oraz zarządzaniem konfiguracją oprogramowania.
