Każdy z nas chce być szczęśliwy. Jednak czy da się zmierzyć szczęście? Czy możemy z pełnym przekonaniem stwierdzić, o ile jesteśmy szczęśliwsi danego dnia? Czy ktokolwiek usłyszał „dzisiaj jestem o 10% bardziej szczęśliwy niż tydzień temu”? Szczerze wątpię, jednak jeśli nawet, to czy miałoby to jakikolwiek sens? Nikt przecież nie oczekuje matematycznego podejścia do uczuć. Inaczej natomiast wygląda to w przypadku oprogramowania.

Eksperckie przeczucia

Tu równie często spotykam się z bardzo luźnym podejściem, „na czuja”, zamiast operowania twardymi liczbami. A mogłoby się wydawać, że to właśnie liczby powinny być naturalnym sposobem komunikacji w świecie technologii.

Szkolenia z architektury systemów często rozpoczynam od pytania: co rozumiemy przez „dobrą architekturę”? Jakie cechy świadczą o tym, że jest ona właściwa? Zazwyczaj odpowiedzi uzależnione są od profilu konkretnej firmy. Kilka z nich jednak się powtarza i ustalamy, że architektura powinna być:

  • utrzymywalna,
  • elastyczna,
  • dopasowana,
  • testowalna,
  • bezpieczna.

Gdy mamy już gotową listę, proszę o zapisanie na kartkach definicji jednej z powyższych cech, np. testowalności. Następnie każdy czyta swoją definicję i z każdą kolejną wypowiedzią rośnie konsternacja.

„Testowalność oznacza możliwość weryfikacji każdego komponentu systemu”

„Testowalność osiągamy przez krótki czas wykonania testów”

„Testowalność rozumiemy jako wysoki procent pokrycia kodu testami automatycznymi”

Co się stało? Chwilę wcześniej wszystko było uzgodnione, a teraz pojawiły się rozbieżności. I całe szczęście, że wydarzyło się to w kontrolowanych warunkach, podczas szkolenia, a nie kiedy wszyscy już wrócili do pracy. Wtedy skończyłoby się na tym, że jeden zespół dodaje testy, aby zwiększać pokrycie, a drugi je usuwa, byleby kompilacja odbywała się tak szybko, jak wcześniej. I konflikt gotowy. A wystarczyło wyrównać poziom świadomości.

Wyrównywanie poziomu świadomości

Do takiej operacji uspójniania oczekiwań możemy wykorzystać liczby. Uzgodnienie skali (bądź też skal) danej cechy, ujednolica jej rozumienie. Przeanalizujmy poniższe przykłady:

„Czas w minutach potrzebny do wykonania testów automatycznych na środowisku ciągłej integracji”

„Procent ścieżek krytycznych pokrytych testami end2end”

„Liczba funkcjonalnych błędów blokujących wykrytych na środowisku produkcyjnym”

„Procent procesów biznesowych możliwych do przetestowania akceptacyjnie bez wykorzystania GUI”

Oczywiście skale te bardzo się między sobą różnią. Ciężko wypracować „jedyną słuszną” definicję jakiejś cechy. Zawsze zależy ona od technologii (będzie inna dla aplikacji web i systemów embedded), stanu projektu (właśnie startuje czy jest rozwijany od 12 lat) czy też oczekiwań klienta (safe to fail czy fail-safe). Ważne jest jednak, że w obrębie jednej grupy ludzi dane zagadnienie rozumiane jest jednoznacznie.

Metryki

Skoro mamy już skale, możemy pójść krok dalej i zdefiniować metryki. Zazwyczaj określamy trzy wartości: obecną (current), cel (goal) oraz znakomitą (wish) . Dla czasu wykonania testów może to być np.:

  • wartość aktualna = 8 minut
  • cel = 6 minut
  • wartość znakomita = 4 minuty

Mierząc zmiany wartości metryki, widzimy, w jakim kierunku zmierza nasz projekt i na ile udało nam się osiągnąć założone cele. Doszliśmy zatem do poziomu, w którym możemy śmiało powiedzieć, że zgodnie z naszą definicją „po ostatnich zmianach aplikacja jest o 21% bardziej testowalna”. Już nie „przeczucia”, a liczby świadczą o właściwej bądź niewłaściwej realizacji zadań. Powoduje to też wzrost przejrzystości naszej pracy w oczach biznesu (czyli naszego klienta). Przenosi nas z poziomu „zawsze coś tam dłubiecie i refaktoryzujecie” do poziomu „Wasza praca ma teraz mierzalne efekty”.

A jakie są Wasze doświadczenia z metrykami? Zachęcam do podzielenia się nimi w komentarzach.

Dodaj komentarz

avatar
  Subscribe  
Powiadom o