“Definicja zrobione" powtarza się w każdej książce o scrumie bez większego znaczenia inżynieryjnego. Zwykle ląduje jako 12-punktowa lista kontrolna, której nikt nie czyta po drugim sprincie.
Ten post jest wersją inżynierską: co za przydatne definicja „gotowego” faktycznie zawiera informacje o tym, co upuścić i jak sprawić, by było to element, na podstawie którego Twój zespół decyduje, czy zadanie nadaje się do wysyłki; a nie rytuał zgodności.
Dlaczego większość DoDów staje się dekoracją
Standardowy scrum DoD wygląda następująco:
- Kod jest napisany
- Kod jest sprawdzany
- Testy są pisane
- Testy przechodzą
- Dokumentacja jest aktualizowana
- Demo dla właściciela produktu
- Połączone z głównym
- Wdrożony do inscenizacji
Każdy zespół widział takiego. Każda drużyna również przestała to czytać po trzecim sprincie. Dlaczego?
Ponieważ większość tych kul też jest oczywiste („kod jest zapisany”; tak), aspiracyjny („dokumentacja została zaktualizowana”; pod jaką definicją „zaktualizowana”?), lub nie do sprawdzenia w praktyce („pisze się testy”; dla jakich zachowań, w jakim zakresie?).
DoD, do którego nikt się nie odwołuje przy podejmowaniu decyzji o połączeniu, to ciężar własny. To plakat ścienny, a nie narzędzie.
Co robi przydatny DoD
Działający DoD odpowiada dokładnie na jedno pytanie: czy praca spełnia wymagania, aby mogła zostać wysłana już teraz przez kogokolwiek z zespołu?
To wszystko. Nie „czy postępowaliśmy zgodnie z procesem”. A nie „czy zaznaczyliśmy pola”. DoD to umowa pomiędzy Tobą a Tobą z przyszłości: kiedy to zadanie zostanie oznaczony jako gotowy, czy następna osoba w kolejce może mu zaufać?
Trzy właściwości sprawiają, że DoD jest użyteczny:
- Możliwość sprawdzenia w kilka sekund. Każdy element musi zostać sprawdzony w czasie krótszym niż minuta. Jeśli „dokumentacja została zaktualizowana” wymaga przeczytania trzech dokumentów i trzech żądań śledczych w celu sprawdzenia, jest to zbyt niejasne.
- Niezależnie niesprawne. Każdy element musi być czymś, o czym recenzent może niezależnie powiedzieć „to się nie wydarzyło”. Nic machanego ręką.
- Jest własnością inżynierii, a nie ceremonii. DoD to nie miejsce, w którym mieszka „demo’d to PM”. To bramka przepływu pracy, a nie bramka jakości.
Inżynieryjny DoD, który działa
Oto wersja, którą polecamy. Sześć pozycji, wszystkie możliwe do sprawdzenia.
1. Testy obejmują zachowania, które zmienił zadanie
Nie „istnieją testy”. Nie „pokrycie wynosi X%”. DoD pyta: czy dla każdego zachowania dodanego lub zmienionego przez ten zadanie istnieje test, który zakończy się niepowodzeniem, jeśli cofniesz to zachowanie?
To jedyny pasek testowy, który ma znaczenie. Procenty pokrycia mogą przejść, gdy ścieżki krytyczne nie są przetestowane. „Napisane testy” mogą być technicznie prawdziwe, podczas gdy test nie stwierdza niczego znaczącego.
Jeśli zadanie zmienił obliczenie, istnieje test, który zakończy się niepowodzeniem, jeśli złamiesz obliczenia. Jeśli zadanie dodał punkt końcowy, następuje test, który go trafia. Jeśli zmienił ścieżkę błędu, przeprowadzany jest test na obecność błędu.
2. Ręczny test dymny szczęśliwej ścieżki
Człowiek przyglądał się zmianom w działającym środowisku (programowanie, testowanie lub produkcja) i widział, jak funkcja działa od początku do końca. Nie poprzez zrzut ekranu; poprzez kliknięcie.
Jeśli zmiana nie dotyczy interfejsu użytkownika, komunikat będzie brzmieć: „Uruchomono odpowiednie polecenie CLI / trafiono odpowiednie polecenie API i zwrócono oczekiwaną odpowiedź”.
Wychwytuje to klasę błędów, które przechodzą testy, ponieważ konfiguracja testowa jest błędne. Wszyscy to doświadczyliśmy: zielone testy, wadliwa funkcja, próbna wersja nie odzwierciedlała produkcji.
3. Żadnych nowych awarii lintera i CI
CI zielony, kłaczki czyste, brak nowych ostrzeżeń. Jest to najtańszy element do sprawdzenia (patrz GitHub) i najmniej stosowany. Wiele zespołów ma DoD z „przepustkami CI”, ale pozwala na połączenie z ignorowaniem niestabilnego testu. Nie.
4. Recenzent wymieniony w opisie PR zaakceptował
Nie „kod jest sprawdzany”. To wyrażenie jest zbyt niejasne; kod sprawdzany przez kogo? Z jaką głębokością?
Wersja konkretna: opis PR wymienia recenzenta, recenzent ten pozostawił akceptację, a akceptacja nastąpiła po ostatniej znaczącej zmianie. Jeśli autor na siłę wypchnął refaktor po zatwierdzeniu, uzyskaj ponowne zatwierdzenie. Koszt jest niewielki; koszt pominięcia jest czasami bardzo zaskakującym błędem.
5. Zmiany schematu są odwracalne lub ich wycofanie jest udokumentowane
To ten, który zapobiega 90% incydentów nocnych. Jeśli zadanie modyfikuje schemat bazy danych, zapisywana jest ścieżka wycofania; albo jako migracja w dół, która działa, albo jako komentarz w PR wyjaśniający „jest to migracja w jedną stronę, ponieważ X, oto jak możemy odzyskać”.
W przypadku zmian innych niż schematy ta pozycja nie dotyczy. Ale każdy zespół powinien mieć go na liście, ponieważ koszt nieodwracalnej złej migracji jest ogromna.
6. Opis zadania odpowiada temu, co faktycznie robi PR
Przeczytaj zadanie. Przeczytaj PR. Czy opisują to samo?
Jest to przede wszystkim sprawdzenie pełzania zakresu. Jeśli postanowiłeś „naprawić błąd podpowiedzi” i dostarczono „napraw błąd podpowiedzi + refaktoryzację całego komponentu podpowiedzi + dodanie nowego zdarzenia analitycznego”; należy podzielić zadanie lub zaktualizować opis. Błędy, w których opis i PR różnią się od siebie, powodują, że wysiłek włożony w recenzję jest poświęcany niewłaściwej rzeczy i wkradają się regresje.
Co wyrzucić ze standardowego DoD
Trzy elementy, które wyglądają rozsądnie, ale w rzeczywistości stanowią hałas.
Upuść: „połączono z głównym”
Jeśli zadanie nie zostanie scalony, nie zostanie to zrobione. Ta kula jest tautologią. Nie umieszczaj tego na liście.
Upuść: „demo do PO”
To jest etap przepływu pracy, a nie pasek jakości. Należy to do twojego rytuału przeglądu sprintu lub planowania, a nie do DoD. Jeśli jest to w DoD, inżynierowie będą oznaczać zadania przed „demo”, ponieważ DoD twierdzi, że wystarczy połączenie z głównym. Kodujesz sprzeczność.
Upuść: „dokumentacja została zaktualizowana”
W obecnej, niejasnej formie ten punkt jest przeważnie ignorowany. W razie potrzeby zastąp go dwoma konkretnymi wymaganiami:
- Jeśli zmiana dotyczy udokumentowanego publicznego API: dokumentacja API została zaktualizowana w ramach tego żądania PR, w tym samym zatwierdzeniu.
- Jeśli zmiana wprowadza nieoczywiste zachowanie operacyjne (zadanie cron, nowa flaga konfiguracyjna, nowa zależność zewnętrzna): w elemencie Runbook lub w odpowiednim pliku README znajduje się jednoakapitowa notatka.
Jeśli żaden z tych warunków nie ma zastosowania, ten punkt nie dotyczy zadania. Nie zamieniaj go w stałe pole wyboru, przy którym z przyzwyczajenia zaznaczasz „tak”.
Uczynić to widocznym
Definicja ukończenia działa tylko wtedy, gdy jest obok pracy. W trzech miejscach zaobserwowaliśmy, że to działa, w przybliżeniu według skuteczności:
- Przypięty na górze szablonu zgłoszenia modułu śledzenia problemów. Every new ticket renders the DoD checklist. Inżynierowie zaznaczają pola na bieżąco. Reviewers can spot-check.
- Bot komentuje każdy PR który zawiera listę pozycji DoD i prosi autora o zaznaczenie każdego z nich (lub zaznaczenie N/A). Dla autora 30 sekund, znacznie szybciej niż pamięć dla recenzenta.
- Przypięta wiadomość na kanale zespołu inżynierskiego. Najmniej wysiłku, ale najszybsza dezaktualizacja. Używaj tego tylko jako rozwiązania zapasowego.
We support the first two natively in SprintFlint; jest Szablon listy kontrolnej definicji ukończenia pojawia się w opisach zadań, a integracja łącza PR na platformie wyświetla DoD w tekście obok łącza GitHub.
Wersja 6-elementowa vs wersja 12-elementowa
Dlaczego 6 elementów, a nie 12?
Ponieważ każdy dodatkowy przedmiot rozcieńcza reszta. DoD składający się z 12 elementów zamienia się w rytuał składający się z 12 elementów. Faktycznie używany DoD składający się z 6 pozycji wychwytuje więcej błędów niż DoD składający się z 20 pozycji, który jest ignorowany.
Kryterium decydujące o tym, czy coś powinno znaleźć się w DoD, brzmi: czy w przypadku braku tego elementu odrzuciłbym PR? Jeśli odpowiedź brzmi „prawdopodobnie nie, po prostu zostawię komentarz”; to nie jest element DoD, to preferencja dotycząca przeglądu kodu.
Jak wprowadzić to bez zbędnych ceremonii
Jeśli Twój zespół obecnie nie ma DoD lub ma taki, którego nikt nie czyta:
- Sprint 1: zgódź się na 6 elementów, umieść je w dokumencie. Nie wymuszaj. Po prostu je miej.
- Sprint 2: dodaj je jako listę kontrolną w szablonie zadania. Engineers self-rate, reviewers spot-check.
- Sprint 3: w retro, zapytaj: „czy w ostatnim sprincie oznaczono jako ukończone zgłoszenie, które nie powinno nim być?”. Jeśli tak, który punkt DoD zawiódł? Zaostrz egzekwowanie tylko tego punktu.
- Sprint 4: na tym etapie DoD ma już znaczenie wypracowane przez zespół. Nie jest zapożyczone z książki.
Nie próbuj wprowadzać ciężkiego DoD na mocy edyktu. Umierają. Wersja 6-elementowa jest wystarczająco lekka, aby lądować bez oporu.
Jak powinno wyglądać „zrobione”.
Dla Twojego zespołu, po 4–6 sprintach biegania w ten sposób:
- „Gotowe” oznacza przedstawiłbyś to teraz klientowi. Żadnych niespodzianek.
- Recenzent może oczyścić PR w 5 minut, ponieważ większość pracy wykonał DoD.
- Nowy pracownik może spojrzeć na zamknięty zadanie i zaufać mu.
- „Gotowe” znika z Twojego słownika, ponieważ „zrobione” już oznacza gotowe.
O to właśnie chodzi. DoD to nie papierkowa robota. To kontrakt, który pozwala na inżynierię prędkość pozostać zrównoważonym. Wygeneruj własne za pomocą Definicja generatora gotowego.
SprintFlint jest dostarczany z natywnymi listami kontrolnymi DoD, szablonami zgłoszeń i integracją PR; stworzony dla zespołów, które chcą kontraktu, a nie papierkowej roboty. 5 GBP/użytkownik/miesiąc, mieszkanie. Zacznij bezpłatnie: 50 bezpłatnych zadań miesięcznie, bez karty.