Będąc liderem w IT bardzo często pracujemy po stronie dostarczania produktów, a więc oprogramowania. Kiedy bierzemy odpowiedzialność za daną inicjatywę, chcemy również podejmować decyzje, które są data-informed, a może nawet data-inspired. Oznacza to z jednej strony bazowanie na twardych danych, z drugiej z kolei niezamykanie się tylko na nie, podejmowanie również decyzji w kontekście i w oparciu o inne przesłanki. Więcej na temat tych pojęć mówiłam w poniższym odcinku podcastu:
Kiedy więc wiemy, że mierzyć chcemy, pozostaje pytanie, co i jak mierzyć? Nad tym właśnie zastanowimy się dzisiaj i zajrzyjmy za kulisy metryk wykorzystywanych w trakcie dostarczania oprogramowania. W szczególności tych, moim zdaniem, najważniejszych i najczęściej używanych.
Metryki wykorzystywane w wytwarzaniu oprogramowania:
- Velocity – czyli prędkość dostarczania oprogramowania. Bardzo sławna metryka, często wspominana. Jednocześnie moim zdaniem należąca do tak zwanych vanity metrics, a więc metryk próżności z uwagi na fakt, że wiele osób koncentruje się tylko i wyłącznie na jej wartości post priori celebrując sukces i nie łącząc jej w żaden sposób z działaniami przyszłymi. Warto obserwować korelację pomiędzy jej wartością a działaniami podjętymi przez zespół lub też wykorzystywać jej średnią wartość do prognozowania przyszłości.
- Ilość cykli testowych
- Delivery time accuracy – różnica między estymowanym a rzeczywistym czasem dostarczenia
- Work in progress– długość kolejki czyli liczba rzeczy będących w trakcie realizacji. Jest to metryka znana z metodyki Kanban. Dążymy do tego, aby WIP był stosunkowo niski, np zakładamy, że powinien wynosić on maksymalnie 10 na zespół (zazwyczaj wstępnie ustalamy go jako liczbę członków zespołu+1)
- Mean time to failure (MTTF) – jest średnim czasem, jaki upływa do momentu, gdy wystąpi awaria systemu. W niektórych źródłach podaje się, że jest to średni czas do awarii, która nie jest naprawialna, a więc przy tej interpretacji do momentu zakończenia działania systemu
- Mean time to repair (MTTR) – jest średnim czasem potrzebnym, aby przywrócić system/aplikację do działania
- Technical debt- dług techniczny tworzony między innymi przez aplikowanie nieodpowiednich rozwiązań technicznych, często pod wpływem pośpiechu, braku odpowiedniego warsztatu programistycznego, wiedzy z zakresu inżynierii oprogramowania lub niedbałość
- Test coverage- procentowe pokrycie kodu testami jednostkowymi
- Build and Integration Frequency– liczba zintegrowanych i przetestowanych buildów na jednostkę czasu
- Release Frequency – liczba releasów na jednostkę czasu, np. tygodniowo, miesięcznie, rocznie. Liczba ta pomaga oszacować czas potrzebny na odpowiedź zespołu na nowe zapotrzebowanie klienta
Miary czasowe.
- Lead time
- Cycle time
- Touch time
To trzy miary, które bardzo często ze sobą mylimy. Lead time określa czas, jaki upływa od pojawienia się nowego zapotrzebowania (zamówienia, 'demand’, 'request’), a jego dostarczenia przez zespół. Ta miara odpowiada na typowe pytanie „O ile wcześniej muszę dać Ci znać, abyś..”. Cycle time z kolei jest zazwyczaj krótszy. To czas od momentu, kiedy zespół zacznie pracować nad funkcjonalnością do czasu jej dostarczenia. Mamy jeszcze „touch time”, a więc rzeczywisty czas poświęcany na pracę nad danym tematem (tutaj z pominięciem wszystkich dni wolnych od pracy i ogólnie czasu, kiedy nie pracujemy). W łatwy sposób można skojarzyć go z liczbą „person hour” (dawniej „manhour”). Oczywiście możemy spotkać się z różnymi wariacjami tych miar, jak m.in. Time-to-remove-impediment.
- Time2Market – czas od początku realizacji projektu do wejścia produktu na rynek; w przeciwieństwie do niej time2value, czyli metryka, która w moim przekonaniu jest dużo ważniejsza, gdyż uwzględnia w sobie dostarczoną wartość biznesową, nie byłaby już przeze mnie uznana za metrykę wykorzystywaną w trakcie wytwarzania oprogramowania
- Customer Cycle Time – czas pomiędzy momentem, kiedy zespół zaczyna pracować nad releasem a momentem, kiedy jest on rzeczywiście dostarczany na produkcję
- Release Stabilisation Period – czas pomiędzy momentem, kiedy zespół deweloperski deklaruje, że funkcjonalność jest skończona a momentem, kiedy rzeczywiście zostanie ona dostarczona na produkcję
