definiția Done (DoD) este o listă de cerințe pe care trebuie să le respecte o poveste de utilizator pentru ca echipa să o numească completă. În timp ce criteriile de acceptare a unei povești de utilizator constau dintr-un set de scenarii de testare care trebuie îndeplinite pentru a confirma că software-ul funcționează conform așteptărilor.
diferența dintre aceste două este că DoD este comună pentru toate poveștile utilizatorilor, în timp ce criteriile de acceptare sunt aplicabile povestirii utilizatorilor specifici., Criteriile de acceptare a fiecărei povești de utilizator vor fi diferite în funcție de cerințele acelei povești de utilizator.cu alte cuvinte, atât DoD, cât și criteriile de acceptare trebuie îndeplinite pentru a completa povestea utilizatorului. Creșterea produsului nu este considerată completă, cu excepția cazului în care ambele liste sunt realizate., Astfel, trebuie să definim două aspecte ale Definiției Făcut (DOD) — Finalizarea Criterii și Criterii de Acceptare:
definiția de Făcut este structurat ca o listă de elemente, fiecare a folosit pentru a valida o Poveste sau PBI, care există pentru a se asigura că Echipa de Dezvoltare de acord cu privire la calitatea muncii sunt încercarea de a produce., Acesta servește ca o listă de verificare care este utilizată pentru a verifica Fiecare element de întârziere a produsului (aka PBI) sau Povestea utilizatorului pentru completitudine. Elementele din definiția „Done” sunt destinate să fie aplicabile tuturor articolelor din lista de produse, nu doar unei singure povești de utilizator.,termenul implică faptul că produsul creștere este shippable
termenul este definit în Ghidul Scrum
Folosit ca o modalitate de a comunica între membrii echipei
în General Software-ul de Calitate
Dacă incrementul este shippable sau nu
obiective de Definire a Făcut
A construi o înțelegere comună în cadrul Echipei despre Calitatea și Exhaustivitatea
de a Folosi ca o listă de verificare care Povești de Utilizator (sau PBIs) sunt verificate împotriva
Asigura creștere livrate la sfârșitul Sprint are de înaltă calitate și că de calitate este bine înțeles de toți cei implicați.,
de exemplu, în industria software, echipele ar putea fi nevoite să pună unele dintre următoarele întrebări pentru a veni cu DoD-ul lor:
Code peer reviewed?
Cod finalizat?
Cod revizuit?
Cod înregistrat?
testele unitare au trecut?
testele funcționale au trecut?
teste de acceptare finalizate?
proprietarul produsului revizuit și acceptat?,
criterii de acceptare
poveștile utilizatorilor sunt unul dintre artefactele principale de dezvoltare pentru dezvoltarea agilă, dar Scrum nu necesită în mod explicit nici povești ale utilizatorilor, nici criterii de acceptare pentru a fi utilizate., Dacă un element din product backlog este considera a fi prea mare pentru a fi pus într-un sprint, în mod normal va fi defalcate în poveste de utilizator și, ulterior, într-un set de sarcini așa cum se arată în Figura:
Povești de Utilizator îngloba Criteriile de Acceptare, astfel, vom vedea de multe ori definiția de făcut și criterii de acceptare a co-existente în scrum noastră proces de dezvoltare. Povestea utilizatorului oferă contextul funcționalității pe care echipa ar trebui să o furnizeze., Criteriile de acceptare oferă îndrumări cu privire la detaliile funcționalității menționate și la modul în care clientul le va accepta. Cele două dintre ele oferă împreună întregul livrabil.
unele dintre criteriile de acceptare vor fi descoperite în evenimentele de rafinare în curs de desfășurare înainte de începerea Sprintului, iar altele vor fi descoperite imediat după planificarea sprintului atunci când stai jos pentru a avea o conversație despre povestea utilizatorului într-o echipă mică. Deci, criteriile de acceptare sunt atribute care sunt unice pentru articolul poveste utilizator sau produs restante.,e Criterii sunt diferite pentru fiecare PBI/Poveste
Termen nu este definit în Ghidul Scrum
Folosit ca o modalitate de a comunica cu toate părțile implicate, care cerințele pentru un anumit PBI/poveste au fost îndeplinite
Aka Teste de Acceptare, Condiții de Satisfacție, în unele cazuri, „Cazuri de Testare,”etc
obiective Criteriilor de Acceptare
Clarifica ce echipa ar trebui să se bazeze înainte de a începe munca
Asigurați-vă că toată lumea are o înțelegere comună a problemei
de a Ajuta membrii echipei știu când Povestea este complet
Ajuta la a verifica Povestea prin teste automate.,
exemplu — criterii de acceptare
Un utilizator nu poate trimite un formular fără a completa toate câmpurile obligatorii
informațiile din formular sunt stocate în baza de date de înregistrări
plata se poate face prin card de credit
un e-mail de confirmare este trimis utilizatorului după trimiterea formularului
exemplu de poveste utilizator cu criterii de acceptare de o poveste de utilizator.,
