Próbujemy obowiązkowej weryfikacji kodu przy każdym zatwierdzeniu - nic nie dostaje się do wzorca, co nie zostało zatwierdzone przez co najmniej 1 osobę niebędącą autorem - dla kilku sprintów. Mamy wpisowe od deweloperów i kadry zarządzającej (co jest niesamowitą sytuacją) i chcemy uzyskać niektóre z korzyści, z których jest znany:
- oczywista redukcja błędów
- większa świadomość zmian zachodzących wokół projektu
- „Wiem, że ktoś na to spojrzy, więc nie będę leniwy” / efekt anty-kowbojski
- zwiększona spójność w ramach / pomiędzy projektami
Ale wprowadzamy coś, co jest znane ze zmniejszania prędkości, a jeśli zrobione źle, może stworzyć głupi biurokratyczny krok w procesie zatwierdzania, który nie zajmuje nic, tylko zajmuje czas. Rzeczy, które mnie niepokoją:
- recenzje przekształcają się w zbieranie nitów
- (hiperbolicznie) ludzie otwierają ogromne problemy architektoniczne w ramach przeglądu zatwierdzania dwóch linii.
- Nie chcę uprzedzać odpowiedzi w innych sprawach.
Chociaż wszyscy jesteśmy rozsądnymi ludźmi i będziemy przeprowadzać wiele samoanalizy, zdecydowanie możemy skorzystać z pewnego wygranego w bitwie wglądu w to, jakie rzeczy powinniśmy starać się osiągnąć w sesji przeglądowej, aby recenzje naprawdę działały dla nas . Jakie wytyczne i zasady okazały się skuteczne?
źródło
Mamy prawie jak listę kontrolną:
Działa dość dobrze.
źródło
Myślę, że wystarczy osoba, która ma władzę nad innymi, administrator lub moderator, aby wyciąć niepotrzebne komentarze i przyspieszyć recenzowanie rzeczy, które wymagają szybkiej oceny. Pojedynczy decydent.
Minusem tego byłoby to, że ta osoba musi to zrobić jako główne zadanie, podczas gdy on mógłby robić coś innego, i prawdopodobnie chciałbyś mieć najbardziej doświadczoną osobę na tym stanowisku.
Drugą rzeczą jest automatyzacja jak najwięcej!
Te rzeczy usuną przynajmniej niektóre rzeczy, które ludzie mogą komentować bez prawdziwej potrzeby. Jeśli nie buduje się lub ma spacje końcowe, nie jest wystarczająco dobry do recenzji, napraw go i ponownie ubiegaj się o recenzję. Jeśli nie buduje się lub jakiś test kończy się niepowodzeniem, jest oczywiste, że nie jest wystarczająco dobry.
Wiele zależy od twoich technologii, ale im więcej możesz sprawdzić, tym lepiej.
Nie wygraliśmy jeszcze tej bitwy, ale to nam się przydało.
źródło