Audyt procesów inżynierskich: na co patrzymy i dlaczego

Gdy zespół dowozi wolno, przyczyną prawie nigdy nie są inżynierowie. Zwykle to cztery albo pięć konkretnych tarć, których nikt nie zmierzył.

«Zespół jest wolny» to objaw, a założyciele zwykle diagnozują go błędnie jako problem z ludźmi. Z naszego doświadczenia to niemal zawsze problem systemowy: praca czeka w kolejkach, zmiany są duże i ryzykowne, wdrożenie budzi strach, a nikt nie ma liczb, którymi mógłby argumentować.

Zacznij od czterech pomiarów

Te cztery są dobrze ugruntowane i — co ważniejsze — diagnostyczne: każdy zły wynik wskazuje na konkretną klasę problemu.

Typowe ustalenia

Code review jest wąskim gardłem, a nie bramką jakości

• Pull requesty są zbyt duże, by je sensownie przejrzeć, więc review staje się teatrem zatwierdzania
• Brak oczekiwań co do czasu reakcji w review, więc zmiany leżą całymi dniami
• Jeden inżynier senior jest jedynym zatwierdzającym — kolejka z jednym okienkiem

Wdrożenie jest wydarzeniem

• Ręczne kroki, które zna tylko jedna osoba
• Brak rollbacku, któremu ktokolwiek ufa, więc wydania są łączone w paczki, co czyni je ryzykowniejszymi, co czyni je rzadszymi
• Wdrożenia planowane na spokojne godziny — mocny sygnał, że zespół nie ufa procesowi

Praca nie jest właściwie zdefiniowana

• Tickety wymagające rozmowy, zanim ktokolwiek zacznie
• Brak wspólnej definicji ukończenia, więc praca odbija się między programowaniem a QA
• Zbyt wiele pracy w toku — wszyscy zajęci, nic się nie kończy

Co zmienić najpierw

1. Uczyń wdrożenia nudnymi — zautomatyzuj, dodaj rollback, przećwicz go. Wszystko inne poprawia się, gdy wydawanie jest bezpieczne.
2. Zmniejsz partie — mniejsze zmiany łatwiej przejrzeć, bezpieczniej wydać, szybciej zdiagnozować.
3. Ustal SLA review — godziny, nie dni, z drugim zatwierdzającym, żeby jedna osoba nigdy nie była wąskim gardłem.
4. Ogranicz pracę w toku — kończenie bije zaczynanie.
5. Oprzyrząduj to, co czują klienci, żeby incydenty znajdować wewnętrznie, a nie dostawać w zgłoszeniach.

Szybkość i bezpieczeństwo nie są kompromisem w dostarczaniu oprogramowania. Zespoły wdrażające najczęściej mają też najniższe odsetki awarii — bo małe, częste, odwracalne zmiany są jednocześnie szybsze i bezpieczniejsze.

Badaj pracę bez tworzenia rankingów ludzi

Porównywalne zadania ujawniają ograniczenia systemu. Wyjaśniaj czekanie i poprawki bez utożsamiania aktywności z produktywnością.

1. Wybierz kilka zakończonych zmian, w tym pilną poprawkę.
2. Zmierz kolejki, przeglądy, przekazania i trudności wdrożeń.
3. Przetestuj usprawnienie z punktem wyjścia i datą oceny.

• konsulting DevOps →
• postmortem dobre praktyki →