DORA, DevEx i inne zestawy metryk pomocnych w procesie wytwarzania oprogramowania

Dziś porozmawiamy o metrykach w procesie wytwarzania oprogramowania. Pokażę na wstepie fajną grafikę którą znalazłem na kanale: LeaderShip Failed Successfully - podcast liderski. To grafika będzie podstawą do omówienia każdej metryki oraz oceny dla kogo i po co te metryki są potrzebne.

Zacznę od filmu, który skłonił mnie do omówienia tematu:

▶ Video: https://www.youtube.com/watch?v=HeeKUe_pbQM&t=2130s

Szczególnie zainteresował mnie raport, który chłopaki pokazali w filmie:

Grupy metryk

Widzimy 4 grupy najpopularniejszych metryk. Sam zanim nie zagłebiłem się w temat dużo słyszałem o DORA. Zostałem też o to zapytany na ostatniej rozmowie kwalifikacyjnej. Może zacznijmy od DORA właśnie:

DORA - DevOps Research and Assessment

Składa się z 4 metryk (wg autorów filmu 5. metryka została dodana - sprawdziłem to i uwzględnie to w poniższym opisie). Metryki mają na celu badać szybkość dostarczania oraz bezpieczeństwo zmiany.

Deployment Frequency (DF)
Jak często zespół wdraża zmiany na produkcję
→ mierzy zdolność do szybkiego dostarczania wartości

Lead Time for Changes - Cycle Time (LT)
Czas od commit/merge do uruchomienia zmiany na produkcji
→ mierzy sprawność procesu delivery

Change Failure Rate (CFR)
Procent wdrożeń powodujących incydenty, rollbacki lub hotfixy
→ mierzy jakość i stabilność zmian

Mean Time to Recovery (MTTR)
Średni czas przywrócenia systemu po awarii
→ mierzy odporność systemu i zespołu

Reliability
mierzy, na ile system faktycznie spełnia oczekiwania użytkowników pod względem:

• dotrzymywania SLO / SLA.
• dostępności,
• stabilności,
• poprawności działania,

Jeśli zerkniemy na grafikę, zauważymy że najlepsze zespoły (elite) są w stanie deployować kod średnio codziennie. Oznacza to, że codziennie na produkcję wskakuje przynajmniej jedna wersja kodu (nowy feature, funkcjonalność). To samo dotyczy Lead Time For Changes (Cycle Time). Od momentu zacommitowania zmiany, nie powinien minąć więcej niż jeden dzień w przybliżeniu aby zmiana ta została uruchomiona na produkcji.

Change Failure Rate - to bardzo ważna metryka i wg raportu ilość problematycznych wdrożeń powinna być niższa niż 1% - co więcej są zespoły, które takie wyniki dowożą.

Kolejną metryką z raportu jest MTTR - czyli zdolność do reagowania na bugi/incydenty na produkcji. Czas na regenerację jest bardzo ważny - nie chcemy przecież żeby nasi klienci/użytkownicy korzystali z zepsutej aplikacji. Najlepsze zespoły potrafią te problem rozwiązać w mniej niż 6 godzin.

Dora - dobra na start ale zbyt ogólna dla programistów

Mój wniosek o zagłębeniu się w temat jest prosty - DORA pomaga całemu zespołowi ale w szczególności zespołowi DevOps utrzymać płynnośc i stabilność systemu na dobrym poziomie.

Z pomocą przychodzi kolejna grupa metryk czyli DevEx:

Mamy tutaj kilka elementów:

• Coding Time (hours) - Coding time is what we like best - top teams need on average less than an hour to code a solution.
• Pickup Time (hours/minutes) - Pickup time - The time it takes a programmer to start a task and change its status to in-progress. The best teams need less than 75 minutes to do this.
• Approve Time (hours) - the amount of time needed to receive approval for deployment to production; <10 hours is already an excellent result according to the table above.
• Merge Time (hours) - the number of hours between completing a CR and merging changes to the main branch. Elite teams can do this in 2 hours (on average).
• Review Time (hours) - how long a code review takes. The best teams can do it in less than 3 hours.
• Deploy Time (hours) - how many hours it takes to deploy after merging to the main branch. Elite teams can do it in less than 6 hours. This reflects Lead Time for Changes from DORA.
• Merge Frequency (per dev/week) - czyli ile PR na jednego programistę jest mergowane tygodniowo - najlepsi są w stanie utrzymać tą metrykę na poziomie > 2.25 PR tygodniowo
• PR Maturity - bardzo ważna metryka mówiąca o tym jaki odsetek PRs jest do razu przydatna do wdrożenia bez sesji poprawek po code review. Najlepsze zespoły utrzymują to na poziomie >91%

Other metrics. Do we need them?

I will answer this question briefly: NO. In my opinion, DORA + DevEX is more than enough to observe and draw conclusions. However, if you're interested in learning about Predictability and PM Hygiene, I encourage you to watch the video or at least take a look at the graphic I've shared above.

Summary

In conclusion, I'd like to remind you that metrics aren't meant to put pressure on us as developers or DevOps teams, but rather to help us continuously improve our performance and identify bottlenecks in the software development process. If you want to implement metrics gradually, I suggest starting with DORA, then adding (perhaps not even all) the DevEx elements. This should be enough to test the metrics in your environment and select the ones you can influence.

I hope this article has been encouraging. After all, it's all about becoming better professionals. And what if you want to be better at something you don't measure? Metrics are just measurable tools for continuous process improvement, and I'd like to leave you with that thought today. I'd appreciate any comments and sharing experiences. Thanks!