PR Review - Mierzenie usprawnień
Wspólnie z Krzysztofem Witczakiem stworzyliśmy serię artykułów, w których zastanawiamy się skąd tak duża popularność Pull Request Review, oraz jakie problemy Pull Request Review tworzy w naszych zespołach. Następnie podjęliśmy temat rozwiązywania kwestii PR Review i mierzenia, czy jest lepiej.
W serii PR Review:
Mierzenie usprawnień [TEN ARTYKUŁ]
Poprzedni odcinek newsletteru z Krzyśkiem poświęciliśmy powodom wystepowania PR Review. Nie chcemy jednak zostawić Ciebie bez rozwiązań. Nie chcemy jednak zostawiać Cię bez planu działania. Przychodzimy więc z dzisiejszą kontynuacją - opowiemy o mierzeniu usprawnień. 😃
Jak mierzyć, czy jest lepiej
Nie chcemy tutaj przechodzić od razu do rozwiązań i proponować zmian. Jako pierwszy krok, warto zastanowić się:
Jakie problemy związane z PR Review zauważamy w naszym zespole?
Jak możemy zmierzyć obecny wpływ PR Review na nasz proces developmentu?
Jak chcielibyśmy by te miary wyglądały po zmianach?
To ma na celu:
Pokazanie jak obecnie wpływa na nas PR Review.
Zbudowanie koalicji dookoła zmian.
Określenie punktu docelowego, do którego chcemy dążyć.
Mierzenie postępów w działaniu.
Warto się nad tym wcześniej zastanowić – jeśli nie skwantyfikujemy zmiany, to osoby na podstawie własnego widzimisię mogą mówić, że jest gorzej. Nawet jeśli wcale nie będzie. Ich poprzednie doświadczenie z PR Review będzie ich pchało z powrotem do starych nawyków.
Szczególnie, że na początku rzeczy mogą rzeczywiście iść gorzej niż poprzednio. Jak to obrazował Seth Godwin w swoim poście Understanding Local Max:
Na początku rezultaty będą gorsze. Trzeba się nauczyć pracy w parach, usprawnić CI/CD, kooperować z PM by zmniejszać rozmiar partii. To są ciężkie zadania, które dopiero z czasem procentują. Przygotujmy się na tygodnie a nawet miesiące zmieniania nawyków, obserwacji metryk i wprowadzania korekt.
Więc co mierzyć?
Poniżej spis tego, co możemy mierzyć. Ważna uwaga – nie chcemy mierzyć wszystkiego. Wybieramy to co uważamy za istotne dla naszego zespołu.
DORA – prędkość i jakość dostarczania
Warto rozpocząć od metryk DORA. Tutaj przypomnienie dla czytelników od Allstacks:
Pomiar metryk DORA i klasyfikacja naszego zespołu (self-assessment) pozwoli nam szybko stwierdzić, gdzie jesteśmy teraz i określić, gdzie chcielibyśmy być.
Ponadto metryki DORA dzielą się na te powiązane z throughputem zespołu i jakością, więc powinniśmy dostrzec czy nie polepszamy jednego obszaru kosztem drugiego.
DevEx – odczucia pracy
Kolejnym obszarem, na który możemy zwrócić uwagę jest DevEx – Developer Experience. Z materiałami przychodzi tutaj Abi Noda i jego Applying the DevEx framework, jak i również ankiety Developer Experience od CTO firmy DevEX, Laury Tacho (link).
Wspomnieliśmy wcześniej jak klasyczny PR Review wpływa negatywnie na obszary:
Flow (nagła i pilna dystrakcja w postaci review),
Feedback Loops (czekamy na review)
Cognitive Load (zmiana kontekstu, zbyt dużo zmian do przejrzenia w krótkim czasie).
Każdy z obszarów DevEx możemy próbować mierzyć i optymalizować.
Atrybuty jakościowe – jakość produktu
Metryki DORA mierzą prędkość procesów dookoła DevOps.
Można spojrzeć szerzej i skupić się na atrybutach jakościowych samego produktu. Jeśli je mierzymy to wdrażając usprawnienia do PR Review nasza jakość powinna wzrastać.
Poniżej spis kilkunastu z atrybutów, na które można zwrócić uwagę z ebooka Radka: Drivery architektoniczne w twoim zespole.
W ramach zmian dookoła PR Review powinny poprawiać się wskaźniki takie jak:
Możliwość konserwacji – wcześniej zauważamy problemy dookoła utrzymania produktu.
Konfigurowalność – na etapie implementacji jesteśmy w stanie wyłapać, że nasze zmiany zamykają opcje dostosowania rozwiązania pod inne przypadki użycia.
Bezpieczeństwo – unikamy dziur bezpieczeństwa wdrażanych do oprogramowania.
A to już można kwantyfikować i oceniać.
Jak w takim razie usprawnić PR Review?
W kolejnych artykułach kontynuujemy temat PR Review i skupiamy się na podaniu rozwiązań. Przygotowaliśmy ich aż 16 - rozpoczynamy od alternatywnych podejść do Code Review: