Definition of Done w Jira: uzgodnij, co znaczy „gotowe”

Programista kończy zmianę i przesuwa zgłoszenie dalej. Testerka odkrywa, że nowy ekran działa, ale istniejący proces się zepsuł. Wsparcie dowiaduje się o zmianie od zdezorientowanego klienta. Wszyscy powiedzieli „gotowe”, lecz mieli na myśli coś innego.

Definition of Done daje zespołowi wspólny standard ukończenia. Uwidacznia oczekiwane kontrole jakości przed rozpoczęciem, dzięki czemu przegląd mniej zależy od tego, kto pamięta o właściwym pytaniu.

W poradniku opracujemy przykład fikcyjnego portalu, odróżnimy wspólne kontrole jakości od kryteriów funkcji i umieścimy obie listy przy zgłoszeniu za pomocą Definition of Done & AC w Power Pack.

Czym jest Definition of Done?

Scrum Guide opisuje Definition of Done jako standard jakości, który musi spełniać przyrost. Zapewnia wspólne rozumienie ukończonej pracy. Jeśli organizacja ustaliła standard, jest on minimum dla jej zespołów Scrum. Zobacz oficjalny Scrum Guide.

W praktycznym przykładzie to niewielki zestaw pytań zadawanych przy każdej istotnej zmianie. Czy implementacja została sprawdzona? Czy uzgodnione kontrole przeszły? Czy dostępne są informacje potrzebne do obsługi zmiany?

Dokładne pytania zależą od produktu i ryzyka. Publiczny portal, wewnętrzny raport i system krytyczny dla bezpieczeństwa wymagają innych standardów. Kopiowanie cudzej listy bez rozmowy może pozostawić ważne luki i dodać bezcelową pracę.

Użyteczny standard opisuje obserwowalny wynik. „Wysoka jakość” to ambicja. „Uzgodnione testy regresji przeszły, a wyniki są podlinkowane w Jira” to coś możliwego do sprawdzenia.

Oddziel wspólną jakość od zachowania funkcji

Fikcyjny zespół dodaje preferencje powiadomień. Klienci włączą lub wyłączą cotygodniowe podsumowanie. Ważne wiadomości konta pozostają poza tą preferencją.

Funkcja potrzebuje własnych kryteriów akceptacji. Na przykład zapisany wybór musi być widoczny po wylogowaniu i powrocie. To wymaganie tej funkcji, bo opisuje doświadczenie klienta.

Definition of Done obejmuje szerszy standard zakończenia. Przegląd kodu, sprawdzenie dotkniętych istniejących zachowań i aktualizacja instrukcji wsparcia mogą dotyczyć wielu zmian.

Obie listy są ważne. Funkcja może działać zgodnie z życzeniem, choć brakuje niezbędnej pracy jakościowej. Także przejrzany kod i zaliczona regresja nie dowodzą poprawnego działania zamówionej funkcji.

Zacznij od rzeczywistych luk zespołu

Zaproś osoby budujące, sprawdzające i wspierające produkt na krótką rozmowę. Wykorzystaj niedawny przykład pracy uznanej za gotową, która wymagała niespodziewanej poprawki.

Zespół wskazuje trzy powtarzalne problemy: nierozwiązane komentarze przeglądu, słabe pokrycie istniejących ustawień konta regresją oraz instrukcje wsparcia dostarczane dopiero po udostępnieniu funkcji.

Te problemy wskazują przydatne kontrole. Uzasadniają też krótką listę: każdy wpis powinien zapobiegać rozpoznawalnemu błędowi lub potwierdzać potrzebny warunek jakości.

Zapytaj, jak ktoś zweryfikuje proponowany wpis. Jeśli nikt nie umie opisać dowodów, popraw treść przed przyjęciem. „Dokumentacja gotowa” może oznaczać opis wydania, projekt wewnętrzny lub artykuł pomocy. Ustal potrzebne informacje i ich miejsce.

Ustal też, kto zwykle wykonuje kontrole. Można zrobić to w zwykłym planowaniu. Sama lista nie przydziela recenzenta ani nie rezerwuje czasu w kalendarzu.

Przygotuj praktyczną wspólną listę

Oto pierwszy szkic zespołu portalu. Jest przykładem porozumienia roboczego, a nie uniwersalnym standardem.

• Przegląd implementacji zakończony, wymagane komentarze rozwiązane.
• Uzgodnione kryteria akceptacji zgłoszenia zweryfikowane.
• Uzgodnione testy regresji dotkniętych procesów konta przeszły.
• Uzgodnione kontrole dostępności zmienionych ekranów przeszły.
• Instrukcje wsparcia odpowiadają zmienionemu zachowaniu klienta.
• Wyniki weryfikacji i odpowiednie odnośniki przeglądu zapisano w Jira.

Przed użyciem listy zespół zapisuje zakres regresji i dostępności. Inaczej dwie osoby mogłyby zaznaczyć to samo zdanie po wykonaniu różnej pracy.

Dla portalu regresja obejmuje logowanie, otwarcie ustawień konta i zmianę istniejącego pola profilu. Przegląd dostępności zmienionych kontrolek obejmuje klawiaturę, widoczny fokus i jasne etykiety. To wybrane kontrole tego zespołu, nie pełny standard dostępności.

Wpis wsparcia także wymaga praktycznej interpretacji. Jeśli zmiana nie wpływa na klienta, zespół powinien wcześniej ustalić właściwy standard takiej pracy. Nie zmuszaj sprawdzających do wymyślania wyjątków tylko po to, by lista była zielona.

Dodaj standard do zgłoszenia Jira

Otwórz zgłoszenie i znajdź kartę Definition of Done & AC w Power Pack. Zawiera osobne zakładki Acceptance Criteria i Definition of Done. Przed dodaniem wspólnych kontroli wybierz Definition of Done.

Dla krótkiej listy wpisz tytuł kontroli i wybierz Add lub naciśnij Enter. Każdy tytuł powinien dotyczyć jednego weryfikowalnego warunku. Długie zdanie z trzema niezależnymi kontrolami utrudnia pokazanie częściowego ukończenia.

Możesz też wybrać Bulk Import i wkleić listę Markdown. Na przykład skopiuj sześć powyższych punktów z myślnikiem i spacją na początku każdego wiersza. Obsługiwane są również zwykłe pola wyboru Markdown.

Import dodaje wpisy do wybranej zakładki. Sprawdź ją przed potwierdzeniem i obejrzyj wynik. Powtórny import tej samej treści może tworzyć duplikaty, więc nie używaj go jako odświeżenia.

Dla niezweryfikowanej pracy używaj niezaznaczonych pozycji. Zaznaczone pola Markdown importują się jako ukończone; znaczki skopiowane z poprzedniego zgłoszenia nie zastępują kontroli bieżącej zmiany.

Uzgodniony standard trzeba ręcznie umieścić w każdym odpowiednim zgłoszeniu. Zachowaj wzorzec w dokumentacji zespołu i wklejaj stosowne kontrole do nowych zgłoszeń. To praktyka zespołowa, nie automatyczne powiązanie centralnego standardu ze wszystkimi zgłoszeniami.

Przeprowadź rzeczywisty przegląd

Załóżmy, że preferencje są gotowe do kontroli. Maya sprawdza wyniki dla klientów, a Priya wykonuje ustaloną regresję. Leo rozwiązuje pozostałe komentarze implementacji i podlinkowuje przegląd.

Pierwsza próba pokazuje poprawny zapis preferencji, ale znikający fokus klawiatury po Save. Zespół pozostawia dostępność nieukończoną, opisuje problem w zwykłej dyskusji Jira i naprawia go przed ponownym testem.

Instrukcja wsparcia też nie jest skończona. Pozostaje to widoczne mimo spełnionych kryteriów funkcji. Osobne listy wyjaśniają, dlaczego nadal jest praca do zrobienia.

Po rzeczywistym zaliczeniu kontroli wybierz Done. Wybierz ponownie, jeśli nowe informacje wymagają przywrócenia pozycji do zrobienia. Wyniki, linki i ważne decyzje zapisuj zwykłym procesem Jira lub dokumentacji.

Ukończony wpis zapisuje ocenę zespołu. Nie wykonuje kontroli, nie zbiera dowodów ani nie ustala, kto ją przeprowadził. Jeśli istotne są nazwisko lub czas, zapisz je wyraźnie w normalnym procesie przeglądu.

Uważnie czytaj wskaźnik gotowości

Narzędzie pokazuje ukończone i wszystkie pozycje dla każdej zakładki. Ready for Release pojawia się tylko wtedy, gdy obie listy mają co najmniej jeden wpis i wszystkie są ukończone. W innym przypadku widnieje In Verification.

Ta reguła pomaga znaleźć otwarte pozycje. Wyjaśnia też, dlaczego pełna Definition of Done nie daje ogólnego stanu ukończenia, gdy Acceptance Criteria jest pusta.

Traktuj napis jako podsumowanie stanu list. Nie dowodzi wystarczających kontroli, przekonujących dowodów ani bezpieczeństwa wydania. Źle napisany warunek można oznaczyć jako gotowy równie łatwo jak dobry.

Lista nie blokuje też przejścia Jira ani scalenia pull requestu. Takie decyzje nadal podejmuj w normalnym procesie dostarczania i publikacji.

Utrzymuj użyteczność standardu przy zmianach

Sprawdzaj standard, gdy powtarzalny defekt ujawnia brak kontroli, produkt istotnie się zmienia lub istniejąca kontrola przestaje dostarczać przydatnych informacji.

Na przykład preferencja może działać natychmiast, ale zawodzić po opóźnionej synchronizacji. Może to prowadzić do szerszej reguły weryfikacji funkcji zależnych od opóźnionego przetwarzania. Zespół powinien najpierw ustalić zakres reguły i dowody sukcesu.

Zaktualizuj wzorzec i omów zastosowanie do pracy w toku. Istniejące listy nie dziedziczą zmiany automatycznie. Sprawdź odpowiednie zgłoszenia i ręcznie dodaj nowe uzgodnione kontrole tam, gdzie trzeba.

Nie rozszerzaj listy po każdym jednostkowym błędzie. Czasem lepsze jest konkretne kryterium akceptacji, jaśniejsze zadanie lub poprawa procesu przeglądu. Wspólny standard powinien pozostać zrozumiały i rzeczywiście stosowany.

Wypróbuj na aktualnym zgłoszeniu

Wybierz zgłoszenie zbliżające się do przeglądu. Uzgodnij krótki standard jakości, dodaj go pod Definition of Done, a konkretne wyniki klienta umieść pod Acceptance Criteria.

Przejdź wspólnie przez kontrole i podlinkuj dowody w zwykłym miejscu. Oznaczaj gotowość dopiero po weryfikacji, a pozostałą pracę omawiaj normalnym procesem realizacji.

Korzyścią jest jaśniejsza rozmowa. Gdy ktoś powie, że preferencje są gotowe, zespół wyjaśni, które wyniki działają, jakie kontrole jakości przeszły i skąd wynika ten wniosek.

• Scrum Guide — Definition of Done