Dacă vă exprimați scurt punctul de vedere, atunci, așa cum se spune în Odessa: "Acestea sunt două mari diferențe" :-).
Avem nevoie de "criteriile de acceptare" pentru a verifica fiecare Istoric utilizator (caracteristici etc.) și pentru a confirma că, după implementare, sistemul funcționează după dorința clientului. Astfel de criterii vor fi aproape unice pentru fiecare produs de backlog al produsului și ar trebui specificate înainte ca echipa să ia un element în iterație (sprint).
Deoarece aproape toate etapele "criteriilor de pregătire" trebuie efectuate pentru fiecare element din restante, cea mai comună este o listă de verificare simplă. Nikolai Alimenkov a scris în detaliu în articol, cu exemple suficiente și cu exemple de criterii. Este important să rețineți că aceste criterii se aplică tuturor elementelor de întârziere care au fost făcute în sprint. Ar fi bine să vă întrebați ideile testerelor și clienților dvs. și apoi veți produce un "produs potențial gata" care se potrivește cel mai bine situației dvs.
Dacă aveți o echipă care lucrează la lansări pe termen lung ale unei versiuni stabile (așa-numitele versiuni), atunci, cel mai probabil, veți avea criterii cu un nivel și mai ridicat. Ele pot fi numite "criteriile de eliberare" (Definiția făcută pentru eliberare). Aceste criterii vor afecta planificarea întregii probleme și trebuie amintite în mod constant și nu amânate în ultimul moment.
O brainstormă simplă vă va permite să faceți o listă cu 3-10 elemente, care vor fi mai mult decât suficiente. O astfel de listă este utilă pentru planificarea iterației și, dacă există o listă separată, atunci pentru întreaga problemă. La urma urmei, trebuie să planificați exact așa de multă funcționalitate ca și cum veți avea timp de făcut conform tuturor elementelor din lista de verificare cu "criteriile de pregătire". Fii realist 🙂
Ne confruntăm cu confuzii în ceea ce privește: Criterii de pregătire VS Criterii de acceptare
Distribuiți acest link:
Trimiteți-le prietenilor: