această versiune HTML a Ghidului Scrum este un port direct al versiunii din Noiembrie 2020 disponibil ca PDFhere.

scopul Ghidului Scrum

am dezvoltat Scrum la începutul anilor 1990. am scris prima versiune a Ghidului scrum în 2010 pentru a ajuta oamenii din întreaga lume să înțeleagă Scrum. Am dezvoltat Ghidul de atunci prin mici actualizări funcționale.Împreună, stăm în spatele ei.

Ghidul Scrum conține definiția Scrum. Fiecare element al cadrului servește unui scop specific care este esențial pentru valoarea generală și rezultatele realizate cu Scrum. Schimbarea designului de bază sau a ideilor Scrum, omiterea elementelor sau nerespectarea regulilor Scrum, acoperă problemele și limitează beneficiile Scrum, potențial evenrendering inutil.

urmărim utilizarea tot mai mare a Scrum într-o lume complexă în continuă creștere.Suntem umiliți să vedem Scrum fiind adoptat în multe domenii care dețin o muncă extrem de complexă, dincolo de dezvoltarea de produse software, unde Crum își are rădăcinile. Pe măsură ce utilizarea Scrum se răspândește, dezvoltatorii, cercetătorii,analiștii, oamenii de știință și alți specialiști fac munca. Folosim cuvântul” Dezvoltatori ” în Scrum nu pentru a exclude, ci pentru a simplifica. Dacă obțineți valoarede la Scrum, considerați-vă inclus.

pe măsură ce Scrum este utilizat, tiparele, procesele și informațiile care se potrivesc cadrului Crum așa cum este descris în acest document pot fi găsite, aplicate și modificate. Descrierea lor este dincolo de scopul Ghidului Scrum, deoarece sunt sensibile la context și diferă foarte mult între utilizările Scrum.Astfel de tactici pentru utilizarea în cadrul Scrum variază foarte mult și sunt descrise în altă parte.

Scrum Definition

Scrum este un cadru ușor care ajută oamenii, echipele și organizațiile să genereze valoare prin soluții adaptive pentru probleme complexe.

pe scurt, Scrum necesită un Scrum Master pentru a promova un mediu în care:

1. un proprietar de produs comandă lucrarea pentru o problemă complexă într-un ProductBacklog.

2. Echipa Scrum transformă o selecție a lucrării într-o creștere a valorii în timpul unui Sprint.

3. Echipa Scrum și părțile interesate inspectează rezultatele și ajustează pentru următorul Sprint.

4. Repeat

Scrum este simplu. Încercați-l așa cum este și determinați dacă filosofia, Teoria și structura sa ajută la atingerea obiectivelor și la crearea de valoare. Cadrul Scrum este intenționat incomplet, definind doar părțile necesare pentru implementarea teoriei Scrum. Scrum este construit de colectivinteligența oamenilor care o folosesc. În loc să ofere oamenilor instrucțiuni detaliate, Regulile Scrum le ghidează relațiile și interacțiunile.

diverse procese, tehnici și metode pot fi utilizate în cadrul cadrului. Scrum se înfășoară în jurul practicilor existente sau le faceinutile. Scrum face vizibilă eficacitatea relativă a tehnicilor actuale de management, mediu și de lucru, astfel încât să se poată face îmbunătățiri.

teoria Scrum

Scrum se bazează pe empirism și gândire slabă. Empirismul afirmăcă cunoștințele provin din experiență și luarea deciziilor pe baza a ceea ceeste observat. Gândirea slabă reduce deșeurile și se concentrează pe elementele esențiale.Scrum folosește o abordare iterativă, incrementală pentru a optimiza previzibilitatea și pentru a controla riscul. Scrum angajează grupuri de oameni carecolectiv au toate abilitățile și expertiza pentru a face munca și a împărtăși sau a dobândi astfel de abilități după cum este necesar.Scrum combină patru evenimente formale pentru inspecție și adaptare în cadrul unui eveniment de întreținere, Sprint. Aceste evenimente funcționează deoarece implementează pilonii empirici ai transparenței, inspecției și adaptării.

transparență

procesul și munca emergentă trebuie să fie vizibile atât pentru cei care efectuează lucrarea, cât și pentru cei care primesc lucrarea. Cu Scrum, importantdeciziile se bazează pe starea percepută a celor trei acte formale. Artefactele care au o transparență scăzută pot duce la deciziicare diminuează valoarea și cresc riscul.

transparența permite inspecția. Inspecția fără transparență estemislavitoare și risipitoare.

inspecție

artefactele Scrum și progresul către obiectivele convenite trebuie să fie inspectate frecvent și cu sârguință pentru a detecta variante sau probleme potențial nedorite. Pentru a ajuta la inspecție, Scrum oferă cadențăsub forma celor cinci evenimente.

Inspecția permite adaptarea. Inspecția fără adaptare esteconsiderat inutil. Evenimentele Scrum sunt concepute pentru a provoca schimbări.

adaptare

Dacă orice aspect al unui proces deviază în afara limitelor acceptabile sau dacă produsul rezultat este inacceptabil, procesul aplicat sau materialele produse trebuie ajustate. Ajustarea trebuie efectuatăcât mai curând posibil pentru a minimiza abaterea ulterioară.

adaptarea devine mai dificilă atunci când persoanele implicate nu sunt împuternicite sau autogestionate. Se așteaptă ca o echipă Scrum să adapteze momentulînvață ceva nou prin inspecție.

valorile Scrum

utilizarea cu succes a Scrum depinde de oameni devin mai competenți inliving cinci valori:

angajament, concentrare, deschidere, Respect și curaj

Echipa Scrum se angajează să-și atingă obiectivele și să se sprijine reciproc. Accentul lor principal este pe munca Sprintului pentru a face cele mai buneprogres posibil spre aceste obiective. Echipa Scrum și acționarii săi sunt deschiși cu privire la muncă și provocări. Membrii echipei Scrum se respectă reciproc pentru a fi oameni capabili, independenți și sunt respectați ca atare de oamenii cu care lucrează. Membrii echipei Scrum au curajul să facă ceea ce trebuie, să lucreze la probleme dificile.

aceste valori dau direcție echipei Scrum cu privire la munca,acțiunile și comportamentul lor. Deciziile luate, măsurile luate și modul în care Scrum este utilizat ar trebui să consolideze aceste valori, nu să le diminueze sau să le submineze. Membrii echipei Scrum învață și explorează valorile caei lucrează cu evenimentele și artefactele Scrum. Când aceste valori sunt încorporate de Echipa Scrum și de oamenii cu care lucrează, pilonii empirici ai transparenței, inspecției și adaptării ajung la încrederea în construirea vieții.

Scrum Team

unitatea fundamentală a Scrum este o echipă mică de oameni, o echipă Scrum.Echipa Scrum este formată dintr-un Scrum Master, un proprietar de produs șidezvoltatori. În cadrul unei echipe Scrum, nu există sub-Echipe sau hierarchies.It este o unitate coezivă de profesioniști axată pe un singur obiectiv la un moment dat, obiectivul produsului.

echipele Scrum sunt inter-funcționale, ceea ce înseamnă că membrii au toate abilitățile necesare pentru a crea valoare în fiecare Sprint. Ele sunt, de asemenea, auto-gestionare, ceea ce înseamnă că decid intern cine face ce, când și cum.

Echipa Scrum este suficient de mică pentru a rămâne agilă și suficient de mare pentru a finaliza o muncă semnificativă într-un Sprint, de obicei 10 sau mai puțin people.In generale, am constatat că echipele mai mici comunică mai bine și suntmai productive. Dacă echipele Scrum devin prea mari, ar trebui să ia în considerare organizarea în mai multe Echipe Scrum coezive, fiecare axată pe același produs. Prin urmare,acestea ar trebui să împartă același obiectiv de produs, Product Backlog și Product Owner.

Echipa Scrum este responsabilă pentru toate activitățile legate de produs, de la colaborarea, verificarea, întreținerea,operarea, experimentarea, cercetarea și dezvoltarea și orice altceva care ar putea fi necesar. Ele sunt structurate și împuternicite de către organizațiegestiona propria lor activitate. Lucrul în sprinturi într-un ritm durabil îmbunătățește concentrarea și coerența echipei Scrum.

întreaga echipă Scrum este responsabilă pentru crearea unei creșteri valoroase, utile în fiecare Sprint. Scrum definește trei conturi specifice în cadrul echipei Scrum: dezvoltatorii, proprietarul produsului și ScrumMaster.

Developers

Developers sunt oamenii din Echipa Scrum care se angajează să creeze orice aspect al unei creșteri utilizabile la fiecare Sprint.

abilitățile specifice necesare dezvoltatorilor sunt adesea largi și vor varia în funcție de domeniul de activitate. Cu toate acestea, dezvoltatorii sunt întotdeauna responsabili pentru:

• crearea unui plan pentru Sprint, Sprint Backlog;

• insuflarea calității prin aderarea la o definiție a făcut;

• adaptarea planului lor în fiecare zi spre obiectivul Sprint; și,

• ținându-se reciproc responsabili ca profesioniști.

Product Owner

Product Owner este responsabil pentru maximizarea valorii produsului rezultat din munca echipei Scrum. Modul în care se face acest lucru poate variala scară largă între organizații, Echipe Scrum și persoane fizice.

proprietarul produsului este, de asemenea, responsabil pentru gestionarea eficientă a Backlog-ului produsului, care include:

• dezvoltarea și comunicarea explicită a obiectivului produsului;

• crearea și comunicarea clară a elementelor din Backlog-ul produsului;

• comandarea articolelor din Jurnalul de produse; și,

• asigurarea faptului că Jurnalul de produse este transparent, vizibil și înțeles.

Product Owner poate face munca de mai sus sau poate delega responsabilitatea altora. Indiferent, Proprietarul Produsului rămâneresponsabil.

pentru ca proprietarii de produse să reușească, întreaga organizație trebuie să le respectedeciziile. Aceste decizii sunt vizibile în conținutul și ordinea restanțelor produsului și prin incrementarea inspectabilă la revizuirea tipăririi.

Product Owner este o persoană, nu un comitet. Proprietarul Produsului poatereprezintă nevoile multor părți interesate din lista de produse restante. Cei care doresc să schimbe restanțele de produse pot face acest lucru încercând să convingă Proprietarul Produsului.

Scrum Master

Scrum Master este responsabil pentru stabilirea Scrum așa cum este definit în Ghidul Scrum. Ei fac acest lucru ajutând pe toată lumea să înțeleagă teoria și practica Scrum, atât în cadrul echipei Scrum, cât și al organizației.

Scrum Master este responsabil pentru eficacitatea echipei Scrum. Fac acest lucru permițând echipei Scrum să-și îmbunătățească practicile, în cadrul programului.

Scrum Masters sunt adevărați lideri care servesc Echipa Scrum și cea mai mare organizație.

Scrum Master servește Echipa Scrum în mai multe moduri, inclusiv:

• Coaching-ul membrilor echipei în auto-management și funcționalitate încrucișată;

• ajutând echipa Scrum să se concentreze pe crearea de creșteri de mare valoare care îndeplinesc definiția Done;

• provocând eliminarea impedimentelor din progresul echipei Scrum;și,

• asigurarea faptului că toate evenimentele Scrum au loc și sunt pozitive,productive și păstrate în caseta de timp.

Scrum Master servește Product Owner-ului în mai multe moduri, printre care:

• ajutând la găsirea tehnicilor pentru definirea eficientă a obiectivelor de produs și gestionarea restanțelor produselor;

• ajutând echipa Scrum să înțeleagă necesitatea unor elemente clare și concise ale restanțelor produselor;

• ajutând la stabilirea planificării empirice a produselor pentru un mediu complex; și,

• facilitarea colaborării părților interesate, după cum este solicitat sau necesar.

Scrum Master servește organizația în mai multe moduri, inclusiv:

• conducerea, instruirea și instruirea organizației în Scrumadoption;

• planificarea și consilierea implementărilor Scrum în cadrul organizației;

• ajutarea angajaților și a părților interesate să înțeleagă și să adopte o abordare empirică pentru munca complexă; și,

• eliminarea barierelor dintre părțile interesate și echipele Scrum.

Scrum Events

sprintul este un container pentru toate celelalte evenimente. Fiecare eveniment din Scrum este ooportunitate normală de a inspecta și adapta artefactele Scrum. Aceste evenimente sunt special concepute pentru a permite transparența necesară. Failureto opera orice evenimente ca rezultate prescrise în oportunități pierdute pentru ainspecta și să se adapteze. Evenimentele sunt folosite în Scrum pentru a crea regularitate și pentru a diminua nevoia de întâlniri care nu sunt definite în Scrum.

optim, toate evenimentele sunt ținute în același timp și loc pentru a reducecomplexitate.

sprintul

sprinturile sunt bătăile inimii lui Scrum, unde ideile sunt transformate în valoare.

sunt evenimente de lungime fixă de o lună sau mai puțin pentru a crea consistență.Un nou Sprint începe imediat după încheierea precedentuluiimprimare.

toate lucrările necesare pentru a atinge obiectivul de produs, inclusiv SprintPlanning, Scrums de zi cu zi, Sprint Review, și Sprint Retrospective, happenwithin Sprints.

în timpul sprintului:

• nu se fac modificări care ar pune în pericol Obiectivul Sprintului;

• calitatea nu scade;

• Backlogul produsului este rafinat după cum este necesar; și,

• domeniul de aplicare poate fi clarificat și renegociat cu proprietarul produsului pe măsură ce se învață.

sprinturile permit predictibilitatea prin asigurarea inspecției și adaptării programului Către un obiectiv de produs cel puțin în fiecare lună calendaristică. Când orizontul aSprint este prea lung, obiectivul Sprint poate deveni invalid, complexitatea poate crește și riscul poate crește. Sprinturile mai scurte pot fi utilizate pentru a genera mai multe cicluri de învățare și pentru a limita riscul de cost și efort la un interval de timp mai mic. Fiecare Sprint poate fi considerat scurtproiect.

există diverse practici pentru a prognoza progresul, cum ar fi burn-downs, burn-up-uri sau fluxuri cumulative. Deși s-au dovedit utile, acestea nu înlocuiescimportanța empirismului. În medii complexe, ceea ce se va întâmpla estenecunoscut. Numai ceea ce sa întâmplat deja poate fi folosit pentru a anticipa luarea deciziilor.

un Sprint ar putea fi anulat dacă Obiectivul Sprintului devine învechit. Numaiproprietarul produsului are Autoritatea de a anula sprintul.

planificarea sprintului

planificarea sprintului inițiază sprintul prin stabilirea lucrărilor care trebuie efectuate pentru Sprint. Acest plan rezultat este creat demunca colectivă a întregii echipe Scrum.

Product Owner se asigură că participanții sunt pregătiți să discute despre cele mai importante elemente din Product Backlog și despre modul în care se mapează la ProductGoal. Echipa Scrum poate invita și alte persoane să participe la SprintPlanning pentru a oferi sfaturi.

Sprint Planning abordează următoarele subiecte:

subiectul unu: de ce este acest Sprint valoros?

Product Owner propune modul în care produsul ar putea crește valoarea șiutilitate în Sprint curent. Întreaga echipă Scrum colaborează apoi pentru a defini un obiectiv Sprint care comunică de ce sprintul este valoros pentru acționari. Obiectivul Sprintului trebuie finalizat înainte de sfârșitplanificarea imprimării.

subiect doi: Ce se poate face acest Sprint?

prin discuții cu Product Owner, dezvoltatorii Selectează itemsdin Product Backlog pentru a include în sprintul curent. ScrumTeam poate rafina aceste elemente în timpul acestui proces, ceea ce crește înțelegerea și încrederea.

selectarea cât de mult poate fi completat într-un Sprint poate fi o provocare.Cu toate acestea,cu cât dezvoltatorii știu mai multe despre performanțele lor anterioare, capacitatea lor viitoare și definiția lor de făcut, cu atât mai multîncrezători vor fi în previziunile lor Sprint.

subiectul trei: Cum se va face lucrarea aleasă?

pentru fiecare element de Backlog produs selectat, dezvoltatorii planifica lucrareanecesare pentru a crea un Increment care îndeplinește definiția Done. Acest lucru se face adesea prin descompunerea elementelor restante ale produselor în elemente de lucru mai mici de o zi sau mai puțin. Cum se face acest lucru este la discreția exclusivă dedezvoltatorii. Nimeni altcineva nu le spune cum să transforme elementele restante ale produsuluiîn incremente de valoare.

Obiectivul Sprintului, elementele din Product Backlog selectate pentru Sprint, Plus planul de livrare a acestora sunt denumite împreună SprintBacklog.

planificarea Sprint este timeboxed la un maxim de opt ore pentru o lună-print. Pentru sprinturi mai scurte, evenimentul este de obicei mai scurt.

Daily Scrum

scopul grămezii zilnice este de a inspecta progresul spre SprintGoal și de a adapta restanțele Sprintului după cum este necesar, ajustând lucrările planificate viitoare.Daily Scrum este un eveniment de 15 minute pentru dezvoltatorii ScrumTeam. Pentru a reduce complexitatea, este ținută în același timp și loc în fiecareziua lucrătoare a sprintului. Dacă Product Owner sau Scrum Master lucrează activ la articolele din Sprint Backlog, aceștia participă ca dezvoltatori.

dezvoltatorii pot selecta orice structură și tehnici doresc,atâta timp cât Scrum lor de zi cu zi se concentrează pe progresul spre obiectivul Sprint și produce un plan de acțiune pentru a doua zi de lucru. Acest lucru creeazăse concentreze și îmbunătățește autogestionarea.

Scrum-urile zilnice îmbunătățesc comunicarea, identifică impedimentele, promovează luarea rapidă a deciziilor și, prin urmare, elimină necesitatea altor întâlniri.

Daily Scrum nu este singura dată când dezvoltatorilor li se permite să se ajustezeplanul lor. Se întâlnesc adesea pe tot parcursul zilei pentru mai detaliatediscuții despre adaptarea sau reproiectarea restului activității Sprintului.

Sprint Review

scopul Sprint Review este de a inspecta rezultatul sprintului și de a determina adaptările viitoare. Echipa Scrum prezintă rezultatele activității lor părților interesate cheie și se discută despre progresele înregistrate în vederea atingerii obiectivului de produs.

în timpul evenimentului, Echipa Scrum și părțile interesate revizuiesc ce a fost realizat în Sprint și ce s-a schimbat în mediul lor.Pe baza acestor informații, participanții colaborează la ce să facă în continuare. Restanțele produselor pot fi, de asemenea, ajustate pentru a satisface noi oportunități. Revizuirea tipăririi este o sesiune de lucru și Echipa Scrum ar trebui să evitelimitarea acesteia la o prezentare.

Sprint Review Este al doilea până la ultimul eveniment al sprintului și istimeboxed la maximum patru ore pentru un Sprint de o lună. Pentru shorterSprints, evenimentul este de obicei mai scurt.

Sprint Retrospective

scopul Sprint Retrospective este de a planifica modalități de a creștecalitate și eficacitate.

Echipa Scrum inspectează modul în care a mers ultimul Sprint în ceea ce privește indivizii, interacțiunile, procesele, instrumentele și definiția lor. Elementele inspectate variază adesea în funcție de domeniul de lucru. Presupunerile care i-au rătăcit sunt identificate și originile lor explorate. Echipa Crum discută ce a mers bine în timpul sprintului, ce probleme s-au confruntat și cum au fost (sau nu) Rezolvate aceste probleme.

Echipa Scrum identifică cele mai utile modificări pentru a-și îmbunătăți eficiența. Cele mai importante îmbunătățiri sunt abordate cât mai curândposibil. Acestea pot fi chiar adăugate la Sprint Backlog pentru nextSprint.

retrospectiva Sprintului încheie sprintul. Este timeboxed la amaximum de trei ore pentru un Sprint de o lună. Pentru sprinturi mai scurte, evenimentul este de obicei mai scurt.

Scrum Artifacts

Scrum ‘ s artifacts reprezintă muncă sau valoare. Acestea sunt concepute pentru a maximizatransparența informațiilor cheie. Astfel, toată lumea care le inspectează areaceeași bază pentru adaptare.

fiecare artefact conține un angajament de a se asigura că furnizează informații care sporesc transparența și concentrarea față de care progresul poate fi măsurat:

• pentru restanțele de produse, acesta este obiectivul produsului.

• pentru Sprint Backlog este obiectivul Sprint.

• pentru Increment este definiția Done.

aceste angajamente există pentru a consolida empirismul și valorile Scrum pentru Echipa Scrum și părțile interesate ale acestora.

Product Backlog

Product Backlog este o listă ordonată emergentă a ceea ce este necesar pentru îmbunătățirea produsului. Este singura sursă de muncă întreprinsă de echipa Crum.

elementele din Jurnalul de produse care pot fi realizate de Echipa Scrum în cadrul oneSprint sunt considerate pregătite pentru selecție într-un eveniment de planificare Sprint. Acestea dobândesc de obicei acest grad de transparență după activitățile de rafinare.Produs backlog rafinament este actul de rupere jos și furtherdefining produs Backlog elemente în elemente mai mici mai precise. Aceasta este o activitate continuă pentru a adăuga detalii, cum ar fi o descriere, o comandă și o dimensiune. Atributele variază adesea în funcție de domeniul de lucru.

dezvoltatorii care vor face munca sunt responsabili pentru thesizing. Proprietarul produsului poate influența dezvoltatorii ajutându-iînțelegeți și selectați compromisurile.

angajament: obiectivul produsului

obiectivul produsului descrie o stare viitoare a produsului care poate servi ca o țintă pentru Echipa Scrum să planifice împotriva. Scopul produsului este înlogul de produse. Restul restanței produsului apare pentru a defini” ce ” va îndeplini obiectivul produsului.

un produs este un vehicul pentru a furniza valoare. Are o limită clară, părți interesate cunoscute, utilizatori sau clienți bine definiți. Un produs ar putea fi un serviciu, un produs fizic sau ceva mai abstract.

obiectivul produsului este obiectivul pe termen lung pentru Echipa Scrum. Eitrebuie să îndeplinească (sau să abandoneze) un obiectiv înainte de a-l lua pe următorul.

Sprint Backlog

Sprint Backlog este compus din Obiectivul Sprint (de ce), setul de produse Backlog elemente selectate pentru Sprint (CE), precum și un plan de acțiune pentru livrarea Increment (cum).

Sprint Backlog este un plan de către și pentru dezvoltatori. Este o imagine extrem de vizibilă, în timp real, a lucrării pe care dezvoltatorii intenționează să o realizeze în timpul sprintului pentru a atinge Obiectivul Sprintului.În consecință, Sprint Backlog-ul este actualizat pe tot parcursul Sprintului, cum ar fimai mult este învățat. Ar trebui să aibă suficiente detalii pe care să le poată inspectaprogresul lor în Scrum-ul zilnic.

angajament: Obiectivul Sprintului

Obiectivul Sprintului este obiectivul unic pentru Sprint. Deși obiectivul de imprimare este un angajament al dezvoltatorilor, acesta oferă flexibilitateîn ceea ce privește munca exactă necesară pentru realizarea acestuia. Obiectivul Sprintului creează, de asemenea, coerență și concentrare, încurajând Echipa Scrum să lucreze împreună mai degrabă decât pe inițiative separate.

Obiectivul Sprint este creat în timpul evenimentului de planificare Sprint și apoi adăugat la Sprint Backlog. Pe măsură ce dezvoltatorii lucrează în timpul sprintului,ei țin cont de Obiectivul Sprintului. Dacă lucrarea se dovedește a fi diferitădecât se așteptau, ei colaborează cu proprietarul produsului pentru a negocia domeniul de aplicare al restanțelor Sprintului în cadrul Sprintului, fără a afecta obiectivul de imprimare.

Increment

o incrementare este o piatră de temelie concretă către obiectivul produsului. Fiecare creștere este aditivă la toate creșterile anterioare și verificată temeinic,asigurându-se că toate creșterile funcționează împreună. Pentru a oferi valoare,Incrementul trebuie să fie utilizabil.

incremente Multiple pot fi create într-un Sprint. Suma creșterilor este prezentată la Sprint Review susținând astfel empirismul.Cu toate acestea, o creștere poate fi livrată părților interesate înainte de sfârșitul Sprintului. Revizuirea Sprint nu ar trebui să fie niciodată considerată o portăvaloare de eliberare.

munca nu poate fi considerată parte a unei creșteri decât dacă îndeplinește definiția Done.

angajament: definiția Done

definiția Done este o descriere formală a stării creșterii atunci când îndeplinește măsurile de calitate necesare pentru produs.

în momentul în care un articol din Product Backlog îndeplinește definiția Done, se naște o creștere.

definiția Done creează transparență, oferind tuturor o înțelegere clară a lucrărilor finalizate ca parte a creșterii. Dacă un element din lista de produse nu corespunde Definițieifăcut, nu poate fi lansat sau chiar prezentat la Sprint Review.În schimb, se întoarce la Product Backlog pentru examinare viitoare.

dacă definiția Done for a increment face parte din standardele Organizației, toate echipele Scrum trebuie să o urmeze cel puțin. Dacă nu este un standard organizațional, Echipa Scrum trebuie să creeze o definiție adecvată pentru produs.

dezvoltatorii sunt obligați să se conformeze definiției Done. Dacă există mai multe Echipe Scrum care lucrează împreună la un produs, acestea trebuie să definească reciproc și să respecte aceeași definiție a Done.

notă finală

Scrum este gratuit și oferit în acest ghid. Cadrul Scrum, așa cum este prezentat aici, este imuabil. În timp ce punerea în aplicare numai părți ale Scrum esteposibil, rezultatul nu este Scrum. Scrum există numai în întregime și funcționează bine ca un container pentru alte tehnici, metodologii și practici.

mulțumiri

oameni

dintre miile de oameni care au contribuit la Scrum, ar trebui să-i eliminăm pe cei care au contribuit la început: Jeff Sutherland a lucrat cu Jeff McKenna și John Scumniotales, iar Ken Schwaber a lucrat cu Mike Smith și Chris Martin și toți au lucrat împreună. Mulți alții au contribuit în anii care au urmat și fără ajutorul lor Scrumnu ar fi rafinat așa cum este astăzi.

istoria Ghidului Scrum

Ken Schwaber și Jeff Sutherland au co-prezentat pentru prima dată Scrum la OOPSLAConference în 1995. În esență, a documentat învățarea pe care Ken și Jeff au câștigat-o în ultimii ani și au făcut publică prima definire formală a Scrum.Ghidul Scrum documentează Scrum ca fiind dezvoltat, evoluat și susținut timp de 30 de ani de Jeff Sutherland și Ken Schwaber. Alte surse oferămodele, procese și Perspective care completează cadrul Scrum.Acestea pot crește productivitatea, valoarea, creativitatea și satisfacția cu rezultatele.

istoria completă a Scrum este descrisă în altă parte. Pentru a onora primullocurile în care a fost încercat și dovedit, recunoaștem Individual Inc., Newspage, Fidelity Investments și IDX (acum GE Medical).

2020 Ken Schwaber și Jeff Sutherland această publicație este oferită pentru licență sub licența AttributionShare-Alike a Creative Commons, accesibilă athttps://creativecommons.org/licenses/by-sa/4.0/legalcode și, de asemenea, descrisă în formă sumară athttps://creativecommons.org/licenses/by-sa/4.0/. Prin utilizarea acestui ScrumGuide, recunoașteți și sunteți de acord că ați citit și sunteți de acord să fiți legat de termenii licenței de atribuire a licenței de partajare a CreativeCommons.