Proiectul de management al proiectului Partea 1: O comparație cuprinzătoare între Agile, Scrum, Kanban și Lean

Prezentare generală

Multe metodologii sunt folosite astăzi în dezvoltarea de software. Este posibil să fi auzit cuvinte la modă precum Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming etc.

În acest articol, voi defini acești termeni, voi discuta despre modul în care sunt legați unul de celălalt și cum diferă unul de celălalt. Multe dintre cuvintele la modă menționate mai sus se bazează pe concepte de la Lean Manufacturing, care sa bazat inițial pe Toyota Manufacturing System (TPS), așa că vom vorbi mai întâi despre asta.

Metodologia Lean

Originile Lean și Lean Manufacturing

Termenul „Lean” își are originile în producție, unde a fost inventat pentru a descrie un model de producție bazat pe Toyota Production System (TPS) dezvoltat inițial de Sakichi Toyoda, Kiichiro Toyoda și Taiichi Ohno, care au fost inspirați inițial de Henry Ford. TPS s-a concentrat pe filozofia „eliminării complete a tuturor deșeurilor” și a revoluționat producția în anii 1950 până în anii 1970. TPS a devenit cunoscut sub numele de „Lean Manufacturing” în 1990, când a fost publicată „Mașina care a schimbat lumea”.

TPS a identificat trei tipuri mari de deșeuri la Toyota:

• Muda: tradus ca „deșeuri”. La Toyota au fost identificate șapte tipuri de muda și un al optulea a fost adăugat ulterior. Acestea sunt:
  • Defecte: efort implicat în găsirea și remedierea defectelor
  • Supraproducție: producție înaintea cererii
  • În așteptare: așteptarea următorului pas de producție, întreruperi etc.
  • Talent neutilizat: capacități subutilizate, pregătire inadecvată etc
  • Transport: piese sau produse în mișcare care nu sunt necesare procesării
  • Stocuri: inventar terminat și lucrări în curs
  • Mișcare: mișcare sau mers mai mult decât ceea ce este necesar pentru procesare

  • Prelucrare în exces: de la scule proaste sau de la proiectarea produsului

• Muri: tradus ca „supraveghere”. Muri rezultă de obicei din mura, dar poate rezulta din muda. Muri se manifestă prin avarii, absenteism, probleme de siguranță etc.
• Mura: tradus ca „denivelare”. Mura poate fi găsită în fluctuația cererii clienților, timpii de proces per produs sau variația timpilor de ciclu pentru diferiți operatori. Când mura nu este redusă, se mărește posibilitatea pentru muri și, prin urmare, muda. Mura poate fi redusă prin crearea unei deschideri în lanțul de aprovizionare, prin schimbarea designului produsului și prin crearea unei lucrări standard pentru toți operatorii.

TPS a lucrat pentru a elimina deșeurile prin aplicarea acestor două concepte de bază:

• Jidoka: tradus vag prin „automatizare cu atingere umană” prevede că „Calitatea trebuie să fie construită în timpul procesului de fabricație!” ceea ce înseamnă că atunci când apare o problemă, echipamentul se oprește imediat, împiedicând producerea produselor defecte.
• Just-in-Time: faceți doar „ceea ce este necesar, când este necesar și în cantitatea necesară”.

Pe măsură ce TPS a evoluat, acești piloni de bază și valori s-au construit pe conceptele Jidoka și JIT și s-au înrădăcinat:

• Imbunatatire continua:
  • Provocare: formarea unei viziuni pe termen lung și îndeplinirea provocărilor cu curaj și creativitate pentru a realiza visele
  • Kaizen: îmbunătățirea continuă a operațiunilor de afaceri, conducând mereu spre inovație și evoluție, eliminând câte o mudă la un moment dat
  • Genchi Genbutsu: practică genchi genbutsu, mergând la sursă pentru a găsi faptele pentru a lua decizii corecte, a construi consens și a atinge obiectivele la cea mai bună viteză.
• Respect pentru oameni:
  • Respect: respectându-i pe ceilalți și depunând toate eforturile pentru a se înțelege unul pe celălalt, asumându-și responsabilitatea și făcând tot posibilul pentru a construi încrederea reciprocă
  • Munca în echipă: stimularea creșterii personale și profesionale, împărtășirea oportunităților de dezvoltare și maximizarea performanței individuale și a echipei
• Andon: un indicator vizual al stării sau problemelor
• Heijunka: înseamnă nivelare sau nivelare a producției
• Hansei: înseamnă auto-reflecție. Pentru a îmbunătăți eficiența, lucrătorii ar trebui să conteste ipotezele din spatele proceselor actuale pentru a găsi altele mai bune.
• Kanban: un panou folosit ca instrument vizual pentru controlul producției
• Poka-yoke: Denumit și verificarea erorilor sau verificarea erorilor
• Sistem de tragere: Materialul este tras într-o stație de lucru exact așa cum este necesar
• Seiri: este principiul care oglindește deșeurile. Seiri dictează că ceea ce este inutil ar trebui eliminat. Aceasta include toate cele șapte deșeuri inițiale de TPS
• Standardizare: organizează toate lucrările în jurul mișcării umane și creează o secvență de producție eficientă, fără muda. Acest lucru ajută la calitate, la un ritm constant și permite îmbunătățirea continuă.

Diagrama de mai jos arată modul în care conceptele de bază și valorile de bază se leagă între ele.

Management Lean

Sistemul de produse Toyota și Lean Manufacturing au evoluat de-a lungul timpului și au fost aplicate într-un număr de domenii, inclusiv management.

Lean Management a aplicat valorile de bază ale îmbunătățirii continue și respectului față de oameni și le-a distilat într-un set de cinci principii prescriptive Lean care vor fi repetate de mai multe ori pentru a îmbunătăți continuu și a elimina risipa:

1. Identificați valoarea: specificați o valoare din punctul de vedere al clientului final în funcție de familia de produse.
2. Map Value Stream: Identificați toți pașii din fluxul de valoare pentru fiecare familie de produse, eliminând ori de câte ori este posibil acei pași care nu creează valoare.
3. Creați flux: faceți ca pașii de creare a valorii să aibă loc într-o secvență strânsă, astfel încât produsul să curgă fără probleme către client.
4. Stabiliți atracție: pe măsură ce se introduce fluxul, permiteți clienților să atragă valoare din următoarea activitate din amonte.
5. Căutați perfecțiunea: Pe măsură ce valoarea este specificată, fluxurile de valoare sunt identificate, pașii irositi sunt îndepărtați și sunt introduse fluxul și tracțiunea, începeți din nou procesul și continuați-l până când se atinge o stare de perfecțiune în care se creează valoarea perfectă fără risipă.

Aceste principii și alte aspecte ale managementului Lean au fost oficializate atunci când Womack & Jones au publicat „Lean Thinking” în 1996.

Dezvoltare software Lean

De atunci, Lean a fost aplicat managementului, dezvoltării de software și altor domenii.

În anii 1980 și 1990, industria dezvoltării de software se apropia de criză, deoarece proiectele executate folosind metodologiile tradiționale în cascadă durau din ce în ce mai mult. Acest lucru a dus adesea la un decalaj uriaș între identificarea unei nevoi de afaceri și livrarea unei soluții software. Uneori, acest decalaj a fost măsurat în mai mulți ani sau chiar în decenii în anumite industrii cu cerințe specifice, cum ar fi industria aerospațială.

În timpul acestor intervale de timp multianuale, cerințele, sistemele sau chiar afaceri întregi s-au schimbat. Adesea, proiectele ar fi anulate parțial sau își vor completa domeniul, doar pentru a afla că ceea ce au livrat nu mai satisface nevoile de afaceri identificate la începutul proiectului.

Metodologia Waterfall a recompensat părțile interesate pentru că s-au gândit la orice, deoarece au fost forțați să scrie un contract, deși probabil nu erau siguri de ce aveau nevoie. Metodologia Waterfall a forțat să se ia decizii în timpul fazei de cerințe sau de proiectare, iar aceste decizii au fost foarte greu de schimbat fără modificarea contractului și adăugarea de costuri la proiect. Un procent mare de proiecte software au eșuat complet sau au fost livrate cu întârziere și peste buget sau nu au reușit să livreze ceea ce era necesar.

Această frustrare generală a dus la diverși lideri de gândire care încearcă să îmbunătățească Waterfall. Exemplele timpurii includ Dezvoltarea rapidă a aplicațiilor (RAD), care sa concentrat pe reducerea deșeurilor prin scurtarea cerințelor și fazelor de proiectare prin dezvoltarea rapidă a unui prototip și colaborarea cu afacerile pentru a dezvolta în continuare cerințele. A existat, de asemenea, o mișcare către dezvoltarea iterativă, unde un mic proiect a fost finalizat și caracteristici au fost adăugate în iterații continue. Deși aceste metodologii au ajutat, ele nu au rezolvat problemele principale asociate cu Cascada.

În anii 1990 și începutul anilor 2000, câțiva autori au publicat cărți despre aplicarea principiilor Lean în dezvoltarea de software. Dr. Robert Charette a publicat „Lean Software Development” în 1993 și „12 Principles of Lean Software Development” în 2003.

Tom și Mary Poppendieck au publicat „Lean Software Development: An Agile Toolkit” în 2003. Această carte a detaliat șapte principii ale Lean Development, care se corelează direct cu cele șapte forme de deșeuri din Lean Manufacturing. Asemănările și diferențele dintre cele două publicații diferite Lean și Agile (discutate în secțiunea următoare) sunt prezentate în diagrama de mai jos.

Diferențele dintre Lean și Agile

Potrivit Dr. Charette, una dintre diferențele principale dintre Lean și Agile este că Agile este de jos în sus, în timp ce Lean este de sus în jos.

Cadrul Agile

Origins of Agile și The Agile Manifesto

Cam în aceeași perioadă în care Charette și Poppendieck și-au publicat cărțile, Agile Framework a fost creat pentru a ajuta la rezolvarea acelorași probleme. În februarie 2001, un grup de pionieri Agile s-au întâlnit la infama întâlnire Snowbird din Snowbird, Utah, pentru a încerca să găsească o soluție.

Rezultatul a fost Manifestul Agile, care a prezentat un set de valori și principii pentru o metodologie care încearcă să se adapteze la cerințele în schimbare și la nevoile clienților, să reducă risipa și să ofere beneficii mai rapid folosind o abordare incrementală, iterativă.

Manifestul Agile scrie după cum urmează:

„Descoperim modalități mai bune de a dezvolta software făcându-l și ajutând pe alții să o facă. Prin această muncă am ajuns să prețuim:

• Indivizi și interacțiuni peste procese și instrumente
• Software de lucru peste documentație cuprinzătoare
• Colaborarea clientului peste negocierea contractului
• Răspunsul la schimbare în urma unui plan

Adică, deși există valoare în articolele din dreapta, prețuim mai mult articolele din stânga.”

Aliniate cu valorile din manifest sunt cele 12 principii din spatele Manifestului Agile:

„Urmăm aceste principii:

1. Prioritatea noastră cea mai mare este să satisfacem clientul prin livrarea timpurie și continuă a software-ului valoros.
2. Bun venit cerințele în schimbare, chiar și întârzieri în dezvoltare. Procesele agile valorifică schimbarea pentru avantajul competitiv al clientului.
3. Furnizați software de lucru în mod frecvent, de la câteva săptămâni la câteva luni, cu o preferință față de intervalul de timp mai scurt.
4. Oamenii de afaceri și dezvoltatorii trebuie să lucreze împreună zilnic pe tot parcursul proiectului.
5. Construiți proiecte în jurul unor persoane motivate. Oferiți-le mediul și sprijinul de care au nevoie și aveți încredere în ei pentru a duce treaba la bun sfârșit.
6. Cea mai eficientă și eficientă metodă de a transmite informații către și în cadrul unei echipe de dezvoltare este conversația față în față.
7. Software-ul de lucru este principala măsură a progresului. Procesele agile promovează dezvoltarea durabilă.
8. Sponsorii, dezvoltatorii și utilizatorii ar trebui să poată menține un ritm constant la nesfârșit.
9. Atenția continuă pentru excelența tehnică și designul bun sporesc agilitatea.
10. Simplitatea – arta de a maximiza cantitatea de muncă neefectuată – este esențială.
11. Cele mai bune arhitecturi, cerințe și design-uri apar din echipele auto-organizate.
12. La intervale regulate, echipa reflectă cum să devină mai eficientă, apoi își reglează și își ajustează comportamentul în consecință.”

Valorile și principiile de mai sus sunt aplicații ale principiilor Lean precum Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka și reducerea deșeurilor.

Principii Agile aplicate dezvoltării software

Agile este un cadru umbrelă care se aplică oricărui proces care aplică setul de valori și principii Agile.

Câteva exemple sunt:

• Programare extremă
• Scrum
• Kanban

Scrum

Scurtă istorie a scumului

Scrum este un cadru care aplică principii Agile care a fost inventat separat de mai multe persoane, dintre care mai multe au semnat Manifestul Agile:

• Hirotaka Takeuchi și Ikujiro Nonaka au introdus inițial termenul „scrum” într-un context de producție în cartea lor albă „The New Product Development Game”. publicat în 1986 în Harvard Business Review.
• Jeff Sutherland, John Scumniotales și Jeff McKenna au implementat Scrum la Easel Corporation în 1993.
• Ken Schwaber a folosit ceea ce avea să devină Scrum la compania sa, Advanced Development Methods în anii 1990.

Schwaber și Sutherland au colaborat de-a lungul anilor 1990 pentru a dezvolta și perfecționa cadrul într-un context de dezvoltare software, vorbind la diferite conferințe. Schwaber a lucrat cu Mike Beedle pentru a descrie metoda în cartea „Agile Software Development with Scrum” în 2001.

Schwaber a continuat să creeze ambele autorități principale de certificare Scrum:

• Scrum Alliance: creată în 2001. Creați seria de acreditare Certified Scrum .
• Scrum.org: creat în 2009 după ce Schwaber a părăsit Alianța Scrum. Creați seria paralelă de acreditare Professional Scrum .

De-a lungul timpului, au fost create mai multe cadre/organisme de certificare pentru a aborda scalarea cadrului Scrum către echipe și proiecte mai mari, deoarece Scrum a fost conceput inițial pentru echipe mici (7 plus sau minus 2 membri):

• SAFe: Scaled Agile Framework
• Mai puțin: Scrum la scară largă
• Scrum@scale: Scrum at Scale creat de Jeff Sutherland

Valori Scrum

Potrivit Alianței Scrum:

Scrum este un set de principii și practici simplu, dar incredibil de puternic, care ajută echipele să livreze produse în cicluri scurte, permițând feedback rapid, îmbunătățire continuă și adaptare rapidă la schimbare.

Scrum este un cadru prescriptiv, incremental și iterativ pentru dezvoltarea de software care aplică principiile Agile. Valorile și principiile Scrum sunt subliniate în graficele de mai jos și au o aliniere semnificativă cu valorile și principiile Lean și Agile.

Prezentare generală a Scrum

Munca este împărțită în iterații scurte, numite sprinturi, care sunt de obicei de 1-3 săptămâni. Acest lucru este în contrast puternic cu planificarea în profunzime a Cascadei. Lucrarea planificată pentru sprintul curent este aleasă din partea de sus a unui backlog prioritizat de articole de lucru numit Product Backlog (Pull System, Heijunka) și este remediată odată ce începe sprintul. Scopul este de a avea software funcțional la sfârșitul fiecărui sprint, permițând feedback rapid.

La sfârșitul sprintului, echipa se întâlnește pentru a revizui munca finalizată, cum a decurs sprintul și pentru a planifica următorul sprint. Lungimea sprintului, precum și ritualurile de sprint și cadența, sunt fixe pentru fiecare sprint.

Sprinturile sunt executate de echipe interfuncționale care conțin toate abilitățile necesare pentru a finaliza munca în sprint. Planificarea zilnică și urmărirea progresului se realizează folosind artefacte vizuale, cum ar fi tabla scrum și diagramele de ardere de sprint.

Munca într-un sprint este extrasă dintr-un întârziere prioritizat. Urmărirea acestor metode permite schimbarea cerințelor în timp și încurajează feedback-ul constant din partea utilizatorilor finali.

Diagrama hărții mintale de mai jos subliniază câteva dintre conceptele principale ale Scum, care vor fi discutate în secțiunile următoare.

Roluri Scrum

Scrum are trei roluri:

• Scrum Master : Scrum Master este un lider servitor al echipei Scrum. Ei sunt antrenorul echipei care ajută la facilitarea colaborării, elimină impedimentele, impune și protejează procesul Scrum și protejează echipa. Acest lucru înseamnă, de obicei, că organizează și facilitează ritualurile de sprint, se asigură că proprietarul produsului are un restanță prioritizat și îngrijit în mod corespunzător, se asigură că echipa nu este presată să se angajeze excesiv la un sprint, se asigură că domeniul de aplicare nu este adăugat la un sprint. sprint, se asigură că este respectată Definiția de Done. Ei nu atribuie sarcini membrilor echipei (Genchi Genbutsu) și nu sunt responsabili pentru livrarea unui proiect
• Proprietarul produsului : proprietarul produsului este „unicul gât care se poate strânge” responsabil pentru livrarea produsului. Proprietarul produsului definește viziunea a ceea ce vrea să construiască și transmite acea viziune echipei și organizației. Proprietarul produsului deține cerințele de afaceri și de piață și prioritizează toată munca care trebuie făcută prin crearea și gestionarea stocului de produse. Ei decid ce caracteristici să livreze când. Ei lucrează cu echipa și cu alte părți interesate pentru a se asigura că toată lumea înțelege elementele din stocul de produse. Acceptă sau resping munca finalizată într-un sprint la demonstrația de sprint.
• Membru al echipei : Echipa Scrum este o echipă interfuncțională, auto-organizată, formată de obicei din cinci până la șapte membri. Toți cei din proiect lucrează împreună și se ajută reciproc și nu sunt neapărat legați de roluri distincte, cum ar fi arhitect, programator, designer sau tester. Toată lumea completează setul de lucru împreună. Echipa Scrum planifică cât de multă muncă poate finaliza fiecare sprint și deține planul (Genchi Genbutsu).

Scrum Flow, activități și ceremonii

După cum sa discutat mai sus, Scrum are un flux definit și un set de ritualuri și activități. Fluxul unui sprint este următorul.

Planificarea sprintului:

Înainte de începerea unui sprint, Scrum Master facilitează o întâlnire cu echipa scrum și cu proprietarul de produs, numită întâlnire de planificare a sprintului, unde proprietarul de produs identifică obiectivele următorului sprint, iar apoi echipa își planifică munca în funcție de obiective.

Acest lucru se face de obicei cu următoarele activități:

• Capacitate de sprint: echipa determină capacitatea pentru sprint, ținând cont de numărul de zile, numărul de membri ai echipei, vacanțe etc.
• Obiective de sprint: proprietarul produsului identifică care sunt obiectivele pentru sprint. Este esențial ca stocul de produse să fie prioritizat în funcție de obiective (adică, poveștile relevante sunt în top) și îngrijite.
• Selecția muncii: poveștile sau sarcinile sunt trase din partea de sus a restanțelor în sprint până la atingerea capacității estimate. Pe măsură ce poveștile sunt introduse, proprietarul produsului va explica povestea și va răspunde la întrebările echipei, actualizând povestea după cum este necesar, până când proprietarul produsului și echipa Scrum au o înțelegere bună și comună a poveștii. Odată ce această activitate este finalizată, echipa are un scop inițial de sprint propus.
• Defalcarea sarcinilor: echipa Scrum discută fiecare poveste în detaliu, punând accent pe planificarea modului în care vor finaliza povestea și abordează toate criteriile de acceptare și DoD. Ei vor produce o listă de subsarcini necesare pentru a finaliza povestea. Odată ce lista de subsarcini este completă, estimarea poveștii este revizuită și actualizată dacă este necesar.
• Angajamentul de sprint: odată ce toate poveștile sunt defalcate și estimările sunt actualizate, domeniul de aplicare inițial propus de sprint este revizuit. Poveștile pot fi eliminate din sprint și repuse în stoc și/sau pot fi adăugate povești suplimentare. Odată realizat acest lucru, NUMAI echipa Scrum (și nu Scrum Master sau proprietarul produsului) se angajează să finalizeze munca în sprint, iar sprintul este început.

Cantitatea totală de muncă sau domeniul de aplicare la care sa angajat pentru sprint este măsurată în puncte de poveste.

Execuție Sprint

În timpul sprintului, membrii echipei extrag elemente de lucru (povestiri ale utilizatorilor, sarcini etc.) din partea de sus a listei de lucruri de făcut din sprint pentru a lucra. Diferiți membri ai echipei vor lucra la diferitele elemente de lucru sau subsarcinile acestora. Ei vor actualiza starea unui articol atunci când este cazul, mutându-l de la o coloană la următoarea (de obicei De făcut > În curs > Testare > Efectuat sau o variație a acestuia) pe Scrum Board până când este finalizat.

Progresul este urmărit folosind un grafic de ardere care arată cantitatea de muncă finalizată și rămasă măsurată în puncte de poveste. Punctele de poveste rămase sunt afișate pe axa Y, iar timpul rămas este afișat pe axa X. Diagrama de ardere este actualizată când se termină poveștile.

Zilnic, Scrum Master se concentrează pe:

• Facilitează întâlnirea zilnică de standup pentru a planifica ziua și a revizui progresul (vezi mai jos)
• Se asigură că echipa are un plan pentru ziua respectivă
• Îndepărtează blocajele rutiere
• Protejează domeniul de sprint și echipa de distrageri
• Ajută echipa să își mențină graficul de ardere și alte statistici Scrum

Standup zilnic

La începutul fiecărei zile în sprint, Scrum Master facilitează o scurtă întâlnire de 15 minute cu echipa scrum și proprietarul produsului pentru a planifica ziua și a revizui progresul sprintului. Aceasta este o întâlnire scurtă în care toată lumea se află în fața Scrum Board și fiecare persoană din întâlnire răspunde la următoarele întrebări în 2 minute sau mai puțin, referindu-se la anumite elemente de pe tabla de sprint:

• Ce ai făcut ieri?
• Ce ai de gând să faci astăzi?
• Există impedimente care vă împiedică să vă finalizați munca?

Acest lucru permite tuturor să vadă la ce lucrează toată lumea, să vadă ce progrese se fac sau nu și să identifice impedimentele și/sau ajutorul necesar.

Finalizare Sprint

Scrum Master facilitează două ceremonii pentru a închide sprintul înainte de a planifica următorul sprint.

Sprint Demo

La sfârșitul sprintului, Scrum Master facilitează o întâlnire demonstrativă de sprint în care fiecare poveste finalizată este demonstrată pe software-ul de lucru proprietarului produsului și restului echipei. Proprietarul produsului fie va accepta povestea dacă sunt îndeplinite toate criteriile de acceptare, fie va respinge povestea. Dacă o poveste este respinsă, deficiențele sunt identificate și povestea este repusă în backlog-ul de produse în ordinea de prioritate pentru a fi finalizată mai târziu sau deloc. Adesea, părțile unei povești pe care proprietarul produsului nu le acceptă sunt împărțite într-o poveste separată(i), iar povestea originală este închisă.

Numărul total de puncte de poveste finalizate per sprint (Velocity) este calculat și sprintul este închis. Viteza este folosită pentru a urmări nivelul de ieșire al echipei și este folosită pentru a estima când vor fi finalizate funcțiile sau lansările.

Retrospectiva sprintului

După demonstrația de sprint, dar înainte de următoarea întâlnire de planificare a sprintului, Scrum Master facilitează o retrospectivă a sprintului în care echipa reflectă asupra sprintului care tocmai s-a finalizat și discută ce a mers bine și ce nu a mers bine, astfel încât să poată îmbunătăți continuu și progresiv procesul și calitate în timp (Kaizen, Hansei). Există o multitudine de formate sau exerciții retrospective care pot fi folosite pentru a ajuta echipa să genereze discuții.

Este produsă o listă de acțiuni de îmbunătățire și, uneori, acestea au ca rezultat adăugarea de articole în stocul de produse, modificări ale DoD sau ale documentului echipei etc.

Managementul stocului de produse

Creare backlog de produse

Înainte ca un sprint să poată fi planificat sau executat, proprietarul produsului trebuie să creeze un număr de produse în așteptare. Restul începe de obicei cu elemente de dezvoltare a caracteristicilor numite povești scrise de proprietarul produsului și, în timp, devine, de asemenea, populate cu sarcini de dezvoltare sau QA, vârfuri și defecte etc. potențial create de orice membru al echipei. Toate articolele din backlog sunt aranjate în ordine de prioritate.

Îngrijirea întârzierilor

Odată ce stocul inițial de produse este creat și prioritizat, procesul de îngrijire a restanțelor în curs preia controlul. Scopul este acela de a avea întotdeauna, cel puțin, un număr suficient de elemente de top din întârziere îngrijite și estimate, astfel încât acestea să fie gata să fie atrase într-un sprint în timpul unei întâlniri de planificare a sprintului. Acest lucru se face de obicei prin organizarea de întâlniri regulate de îngrijire a restanțelor cu managerul de produs și echipa facilitată de Scrum Master.

Înainte de întâlnire, o listă de povești este trimisă echipei, astfel încât să poată revizui și să se pregătească pentru întâlnirea de îngrijire. La întâlnirea de îngrijire, fiecare articol este discutat în ceea ce privește criteriile de acceptare, complexitate, risc, dimensiune, strategie de implementare etc. Criteriile de acceptare și alte detalii ale poveștii sunt revizuite și revizuite până când echipa, proprietarul produsului și Scrum Master au o înțelegere comună a poveștii. În acel moment, povestea este estimată în puncte de poveste utilizând o tehnică numită planning poker.

Estimarea punctului de poveste

Punctele de poveste sunt o unitate de efort care utilizează dimensionarea relativă în care poveștile sunt comparate cu lucrări anterioare, cunoscute și bine înțelese. Întotdeauna pui întrebarea „este această poveste mai mare, mai mică sau aproximativ de aceeași dimensiune” ca o altă lucrare.

Scara Fibonacci (1, 2, 3, 5, 8, 13, 21...) este scara cel mai frecvent utilizată, unde fiecare increment este de aproximativ de două ori mai mare decât precedentul (adică, o poveste cu cinci puncte este mai mult sau mai puțin de două ori mai mare decât cea precedentă). mare ca o poveste în trei puncte). Uneori se folosesc și alte solzi precum mărimile de tricouri (XS, S, M, L, XL) sau chiar pește (mini, pește auriu, păstrăv, ton, balenă etc.). Orice scară care vă permite să comparați dimensiunea a ceva în raport cu altul va funcționa.

Punctele de poveste reprezintă întregul efort al echipei de a implementa o poveste, inclusiv dezvoltarea, testarea, proiectarea și alte sarcini diverse necesare pentru definirea Terminat. Estimarea ia în considerare cantitatea de muncă, complexitatea și riscul. Odată ce dimensiunea relativă a poveștii este determinată, o dimensiune pe scară este atribuită ca estimare.

Echipele se pregătesc pentru procesul de estimare a punctului de poveste, stabilind mai întâi o linie de bază pentru estimare, alegând o poveste de dimensiune „cea mai medie” pe care întreaga echipă o înțelege ca o poveste de referință. Sunt alese și câteva povești de referință suplimentare care sunt mai mari și mai mici.

Estimarea punctului de poveste se face în timpul întâlnirilor de îngrijire și uneori în timpul planificării sprintului folosind Planning Poker:

1. Fiecare membru al echipei/estimator are un set de carduri.
2. Elementele din backlog sunt discutate pe rând, așa cum este descris mai sus.
3. Odată ce articolul a fost discutat pe deplin, fiecare estimator alege în mod privat un card care să-și reprezinte estimarea.
4. Când toți estimatorii și-au făcut estimările, își dezvăluie cărțile în același timp.
   • Dacă toate estimările se potrivesc, estimatorii selectează un alt element în restanță și repetă același proces.
   • Când estimările diferă, estimatorii discută problema pentru a ajunge la un consens.

Avantajele estimării punctului de poveste sunt:

• Rapid: estimările sunt legate de articolele din backlog de produse deja finalizate.
• Destul de precis: suficient de precis pentru a oferi o imagine de ansamblu asupra domeniului de aplicare, a planifica lucrările viitoare, a stabili prioritățile și a gestiona așteptările.
• Acceptă incertitudinea: punctele de poveste specifică un interval de timp necunoscut. Selectarea dintr-o anumită secvență de puncte de poveste, asemănătoare lui Fibonacci, permite surprinderea incertitudinii.
• Sportul de echipă: implică pe toată lumea (dezvoltatori, designeri, QA, manageri de produs). Utilizează mai multe perspective pentru a determina dimensiunea muncii, dar numai membrii echipei care fac munca pot estima
• Măsoară viteza echipei: măsoară cât de multă muncă face o echipă într-un sprint în comparație cu cantitatea de timp petrecută lucrând. Pe măsură ce echipa se îmbunătățește, vor completa poveștile de aceeași dimensiune mai repede, rezultând o viteză mai mare a punctului de poveste în timp.

Estimarea și urmărirea lansării

Estimarea punctului de poveste este utilizată și într-un context de planificare a lansării, folosind următoarea tehnică:

1. Enumerați toate poveștile care trebuie dimensionate
2. Pune-le în ordine de la cel mai mic la cel mai mare
   • Luați prima și a doua poveste de utilizator.
   • Decide care este mai mare și pune-l pe cel mai mare dedesubt
   • Apoi ia-l pe următorul și decide unde se potrivește relativ la celelalte două
   • Repetați procesul până când toate poveștile sunt acum în listă (într-o secvență de la cel mai mic la cel mai mare)
3. Măriți poveștile

Estimările poveștilor pentru toate poveștile dintr-o lansare, combinate cu viteza echipei, vă vor permite să estimați când va fi finalizată o lansare și să urmăriți progresul acesteia. Acest lucru este adesea arătat într-o diagramă de ardere a lansării.

Artefactele și termenii Scrum

• Product Backlog: o listă de backlog cu toate elementele de lucru pentru un anumit produs, care poate include caracteristici (povestiri), sarcini tehnice, vârfuri și defecte
• Release Burn-up: O diagramă grafică folosită pentru a arăta progresul la un nivel de lansare și pentru a prezice când se va termina o lansare folosind Sprint Velocity. Punctele de poveste finalizate sunt afișate pe axa Y, iar sprinturile sunt afișate pe axa X.
• Sprint Backlog: O listă a tuturor elementelor de lucru care trebuie finalizate într-un sprint dat. Conținutul backlog-ului de sprint este convenit în timpul întâlnirii de planificare a sprintului.
• Scrum Board: O tablă de stil de masă care urmărește progresul muncii angajate pentru sprint. Stările sunt afișate în partea de sus în coloane verticale și elementele de lucru sunt mutate în fiecare stare până când sunt terminate. Tabloul scrum este populat în timpul întâlnirii de planificare a sprintului și este resetat la sfârșitul unui sprint.
• Sprint Burndown: O diagramă grafică care arată cantitatea de muncă finalizată și rămasă măsurată în puncte de poveste pe toată durata sprintului. Punctele de poveste rămase sunt afișate pe axa Y, iar timpul rămas este afișat pe axa X.
• Sprint Velocity: numărul de puncte de poveste pe care o echipă Scrum le completează într-un sprint.
• Impediments Backlog: O listă de impedimente care trebuie abordate de Scrum Master, pentru ca echipa să poată continua să lucreze. Când un membru al echipei este blocat, acesta va adăuga un element la acumularea de impedimente pentru a oferi vizibilitate echipei și Scrum Master.
• Epopee: o epopee este un corp mare de lucrări constând din mai multe povești asociate utilizatorilor.
• Povestea utilizatorului: o poveste a utilizatorului este o descriere a unei caracteristici software din perspectiva utilizatorului final. Povestea utilizatorului descrie tipul de utilizator, ce își dorește și de ce. O poveste de utilizator ajută la crearea unei descrieri simplificate a unei cerințe și include criterii de acceptare. Poveștile utilizatorilor sunt create și întreținute de proprietarul produsului.
• Sarcină: o sarcină este o lucrare introdusă de Scrum Master sau de un membru al echipei care poate avea legătură directă sau indirectă cu poveștile utilizatorilor. Acestea sunt de obicei de natură tehnică și vor include criterii de acceptare.
• Spike: un spike este un tip special de sarcină care este utilizat atunci când trebuie să cercetați, să creați prototipuri și/sau să construiți un arhitect înainte de a putea decide cum să implementați sau să estimați o poveste de utilizator.
• Sarcină secundară : o sarcină secundară este o sarcină care este introdusă ca pas de implementare către finalizarea unei povești sau a unei sarcini de utilizator. Acestea sunt de obicei introduse de echipă în timpul unei întâlniri de planificare a sprintului.
• Story Point Estimates: O scară de estimare a dimensiunilor relative care se bazează pe scara Fibonacci (1, 2, 3, 5, 8, 13, 21...)
• Criterii de acceptare: Lista de articole specifice, testabile, incluse în fiecare poveste, care trebuie finalizată înainte ca un proprietar de produs să accepte o poveste ca fiind finalizată.
• Definiția gata (DoD): o listă de pași sau criterii obișnuiți care trebuie finalizați înainte ca orice poveste să poată fi considerată finalizată. Echipa este de acord cu acest lucru și îl documentează astfel încât să nu fie nevoie să fie enumerat în fiecare poveste.

Avantajele și dezavantajele Scrum

Avantajul principal al Scrum este aplicarea valorilor și principiilor Agile, precum și a conceptelor Lean precum Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System și Iterații. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.