Co sprawdzić przed developmentem
Przejdź tę checklistę na refinementcie. Odpowiedź „nie” otwiera rozmowę, a nie automatycznie odrzuca zadanie.
1. Cel
- Jaki problem rozwiązujemy, jaki ma być wynik i dla kogo?
- Czy zespół potrafi wyjaśnić wartość zmiany bez opisywania implementacji?
2. Zakres
- Który ekran, usługa lub proces jest objęty pracą? Co pozostaje poza zadaniem?
- Czy jeden ticket nie urósł do kilku niezależnych zmian?
3. Oczekiwane zachowanie
- Jaka akcja będzie dostępna, co zobaczy użytkownik i co oznacza sukces?
- Czy obecne zachowanie różni się od oczekiwanego?
4. Role i uprawnienia
Gdy dostęp ma znaczenie, ustal, kto może wykonać akcję, a kto nie. Sprawdź, czy istnieje odpowiednie uprawnienie. Nie wymyślaj nowej roli tylko dlatego, że ticket o niej milczy.
5. Przypadki brzegowe i błędy
Rozważ tylko przypadki, które mogą zmienić implementację. Przy eksporcie faktur pusty wynik i nieudane żądanie są istotne; dziesiątki hipotetycznych nazw pliku raczej nie. Jeśli operacja może zawieść, ustal komunikat, możliwość ponowienia i ewentualny częściowy sukces.
6. Zależności
Czy dostępne są potrzebne API, projekt interfejsu, treści, dane lub uprawnienia? Czy najpierw musi zakończyć się inne zadanie? Podlinkuj źródło ustaleń i wskaż właściciela każdej otwartej zależności.
7. Kryteria akceptacji
Czy zespół potrafi rozpoznać, że praca została wykonana? Zapisuj sprawdzalne warunki na podstawie potwierdzonych wymagań. Poradnik kryteriów akceptacji pokazuje, jak nie zamieniać założeń w wymagania.
Blocker czy zwykłe pytanie?
Blocker to decyzja, której odpowiedź może zmienić rozwiązanie lub sprawić, że implementacja będzie ryzykowna. Jeśli nikt nie wie, czy płatność jest jednorazowa czy cykliczna, nie da się odpowiedzialnie zaprojektować procesu.
Zwykłe pytanie można zamknąć w trakcie pracy bez cofania sensownego kroku. Jeśli przycisk korzysta z istniejącego design systemu, a jego końcowa etykieta brzmi „Pobierz” albo „Eksportuj”, często można już budować logikę eksportu. Właściciela decyzji i termin nadal warto zapisać.
Granica zależy od zadania i zespołu. Definition of Ready a AC wyjaśnia decyzję o starcie. Gdy ważne braki są zamknięte, oszacuj pracę. Możesz też wkleić ticket do narzędzia gotowości zadania, by przed refinementem zobaczyć brakujące decyzje.