Tym razem chciałbym przyjrzeć się, w jaki sposób w naszych procesach Scrum / Kanban wspieramy jakość kodu ustawienia procesu tworzenia oprogramowania. Przeanalizuję niektóre etapy takich procesów i sprawdzimy, jak jawna obecność poszczególnych kroków wspiera utrzymanie Czystego Kodu w zespołach i organizacjach.
Poniżej pytania pochodzące z lat moich obserwacji które warto zadać szukając odpowiedzi dotyczących kontroli jakości
- Czy pojęcie jakości jest jasno zdefiniowane na każdym etapie procesu tworzenia oprogramowania?
- Na jakiej podstawie dany etap zostaje uznany za prawidłowo zakończony?
- Czy termin “jakość kodu” jest omówiony, uzgodniony, zapisany i ogłoszony, czy też jest jakość jest “po prostu oczekiwana” od pracowników?
- Czy można łatwo ominąć kontrolę jakości (także jakości kodu) w danym kroku, na przykład ze względu na pilność?
Tablica w najprostszej postaci
Przez prawie 20 lat pracy w kilku firmach oraz jako szkoleniowiec odwiedziłem wiele biur i rozmawiałem z wieloma zespołami. W tych biurach widziałem wiele tablic, na których wizualizowany był proces tworzenia oprogramowania danego zespołu, np. Kanban lub Scrum.
Oto przykład najprostszej tablicy.
W jaki sposób powyższy proces wspiera jakość? Gdzie jest miejsce na przeglądy kodu lub dodanie brakujących przypadków testowych czy zadbanie o czysty kod? Gdzie jest miejsce na refaktoryzację, kiedy kod przestał być czytelny dla innych po dokonaniu zmian, co utrudni jego dalszy rozwój?
Muszę przyznać, że zespoły w których pracowałem wiele lat temu także używały podobnych tablic. Wielokrotnie najczęstsze pytanie dotyczyło tego, czy funkcjonalność jest już zaimplementowana. Na to pytanie odpowiadała najczęściej osoba pełniąca rolę „testera”.
Dbanie o jakość to nie gra w chowanego
Na podstawie mojego doświadczenia w powyższym przypadku rzeczy takie jak dodanie brakujących testów, posiadanie zautomatyzowanych raportów jakości kodu, refaktoryzacja, dostosowanie architektury projektu do nowych wymagań – jeżeli będą miały miejsce to będą wykonywane w sposób ukryty… Nie będzie się mówić o nich oficjalnie, tylko programiści będą wydłużać etap programowania lub testowania aby gdzieś takie zadania “upchnąć”…
Kroki które nie są oficjalną częścią tego procesu łatwo mogą zostać pominięte. Ewentualnie zostają wykonane poza procesem ale to zawsze wywołuje dyskomfort programistów.
Najgorszy scenariusz to mikrozarządzanie oparte na nieprawidłowym (nie-kompletnym) procesie. Kiedy programiści są kontrolowani co robią z godziny na godzinę a dbałość o jakość nie jest oficjalną częścią procesu to z pewnością nie zagości w zespole. Być może będzie miała miejsce w przypadku programistów świadomych konsekwencji długu technicznego oraz zastanego kodu- ale i tak w ukrytej formie wydłużania planowanego czasu implementacji.
Ekstremalny przypadek z którym się spotkałem dotyczył nagradzania managera za szybkość dostawy produktu, podczas gdy potem programiści / testerzy byli jedynymi „odpowiedzialnymi” za liczbę wad zgłaszanych przez klienta w następnych miesiącach.…
Wprowadzenie transparentności
Czy w procesie znajdują się poniższe punkty kontroli
- Czy został dokonany przegląd kodu?
- Jaka jest czytelność kodu po zmianach?
- Jakie jest pokrycie przez testy komponentowe i/lub integracyjne?
- Czy napisane są unit testy?
Częsta Praktyka jest taka, że jeżeli nie jesteśmy oficjalnie oceniani za coś w pracy to prawdopodobnie nie będziemy się tym przejmować. Może się zdarzyć, że w tym samym czasie członkowie zespołu są wynagradzani tylko za szybkość dostawy i nigdy nie są oceniani na podstawie liczby wad zgłaszanych przez klientów. Kto w takim przypadku otrzymuje podwyżkę? Takie podejście może stworzyć niezdrową atmosferę pomiędzy programistami pracującymi z większą prędkością a tymi którzy bardziej dbają o jakość kodu.
Przejdźmy do analizy kolejnej tablicy
Czy tutaj dbanie o jakość wygląda lepiej? Czy w tym przypadku można pominąć proces rewizji kodu? Dodatkowo proces ten podkreśla, że nikt nie może testować rozwiązania w środowisku integracyjnym przed zakończeniem przeglądu kodu opartego np. o zasady Czystego Kodu.
Chociaż taka konfiguracja brzmi bardziej niezawodnie pod względem kontroli jakości, to i tak widziałem jej różne wyniki w oparciu o różne reguły organizacji pracy. Oto dwa prawdziwe przykłady
- Co najmniej 2 programistów powinno dokonać rewizji zmiany kodu. Ale kto w takim przypadku jest w pełni odpowiedzialny za dokonanie tej rewizji? Może się zdarzyć, że 2 różnych programistów dokonało równocześnie pobieżnej rewizji aby przyspieszyć zadanie czekające na przetestowanie przez „dostępnego” inżyniera jakości. Co więcej, każdy z tych dwóch programistów mógł założyć, że drugi dokona przeglądu bardziej dokładnie.
- Tylko jedna osoba dokonuje przeglądu kodu w tym samym czasie i bierze pełną odpowiedzialność za czytelność, pokrycie przypadków testowych, możliwość rozszerzania jeżeli zatwierdza dokonane zmiany. Jeśli taka osoba ma jakiekolwiek wątpliwości co do jakości, ma prawo przekazać swoje uwagi autorowi lub następnemu recenzentowi do ich potwierdzenia.
Drugie podejście wydaje się bardziej odporne na „wyciek defektu”.
Jeszcze więcej transparentności
Dodajmy kolejną kolumnę do poprzedniej tablicy.
W powyższym przypadku jest bardzo wyraźne, że testowanie wykonywane przez Inżynierów Jakości odbywa się tylko w środowisku integracyjnym. Wyraźnie widać również, kiedy zadanie zostało już przeglądnięte i czeka na wdrożenie na środowisku integracyjnym.
[FM_form id=”2″]
Transparentność “poprawek” czyszczenia kodu
Wynikiem rewizji kodu może być konieczność dokonania poprawek. Taka poprawka może być pilną refaktoryzacją, dodaniem brakujących testów integracyjnych. Może być także ustanowieniem terminu sesji ponownego przedyskutowania architektury ponieważ problem musi zostać omówiony na poziomie całego zespołu.
Niektóre zespoły mogą uznać, że jest w porządku i wystarczy, aby odłożyć dane zadanie na najwyższy priorytet z powrotem do kolumny „do zrobienia”. Ale czy to pozwala odróżnić zadanie z nową funkcjonalnością od zadania “poprawki”? Czy nie spowoduje to, że zadania związane z przeróbką będą konkurować z nowymi zadaniami dotyczącymi nowej funkcjonalności w kolumnie “do zrobienia”? Inną opcją będzie więc jawne dodanie kolumny gdzie zadanie przechodzi dodatkowe “poprawki”.
Oczywiście kolumna poprawki może zostać pominięta, jeśli przegląd kodu przebiegnie dobrze, ale jej istnienie podkreśla, że wykonywanie poprawek jakości kodu na bieżąco jest całkowicie w porządku – na przykład z powodu braku czytelności lub braku testów – nawet jeśli kod działa zgodnie z oczekiwaniami.
Kolejne transparencje…
Bądź zwinny. Omawiaj cyklicznie wszystkie kwestie dotyczące kontroli jakości podczas retrospekcji. Umieszczaj najważniejsze etapy dotyczące kontroli jakości w procesie. Spraw aby były one “legalne” i oficjalne. Bierz odpowiedzialność za jakość kodu.
Analogicznie jeszcze jeden przykład : wdrożenie na produkcję – niech będzie widoczne co się dokładnie dzieje z każdym zadaniem. Korzyści takiej kolumny możesz omówić już samodzielnie.
Podsumowanie – zadbaj o widoczność kontroli jakości kodu
Jeśli chcesz zadbać o jakość, musisz stworzyć procesy i procedury, które zachęcają ludzi do podnoszenia jakości i zniechęcają do jej pomijania. Powinno to być środowisko, w którym ludzie doświadczają konsekwencji swoich decyzji dotyczących braku jakości ale także są uprawnieni do samodzielnego ulepszania tych zasad.
Zwróć dużą uwagę na kształt swojego procesu. Spraw, aby jego kroki były bardzo wyraźne i dobrze zdefiniowane pod kątem kontroli jakości. Proces powinien podkreślać wszystkie rzeczy związane z wymaganiami, takie jak jakość, czytelność kodu, zakres testów, możliwości dokonania refaktoryzacji, być może nawet wymianę wiedzy technicznej i biznesowej.
Pamiętaj, że procedury, procesy zapewniają nam bezpieczeństwo psychologiczne w pracy. Stanowią wytyczne dotyczące wykonywania naszych obowiązków i oceny naszej pracy. Jeżeli „oczekiwany” wynik nie zostanie wyraźnie określony, prawdopodobieństwo jego wystąpienia będzie niewielkie.
Aby wprowadzić nawyk refaktoryzacji do czystego kodu z zespole przeczytaj także :
Jak rozpocząć refaktoryzację kodu w zespole?
Co motywuje zespół do refaktoryzacji do Czystego Kodu?
