Note Scrum și xp din prima linie. Henrik Knieberg Scrum și XP: Note de la prima linie Cum facem Scrum. Dacă cineva nu știe ce să facă cu el însuși

Cum conducem Scrum-of-Scrums

Scrum-of-scrums sunt întâlniri regulate, al căror scop este de a discuta diverse probleme între Scrum Masters.

Odată am lucrat la patru produse. O echipă Scrum a lucrat la trei dintre ele, iar la a patra au lucrat 25 de persoane, care au fost împărțite în mai multe echipe Scrum. Arăta așa:

Aveam două niveluri de Scrum-of-Scrums: un „nivel de produs”, care a fost realizat cu echipele de produs D și un „nivel de companie” pentru membrii tuturor echipelor.

Scrum-of-Scrums la nivel de produs

Această întâlnire a fost foarte importantă. O făceam cel puțin o dată pe săptămână. Am discutat probleme de integrare, echilibrarea echipelor, pregătirea pentru următoarea planificare a sprintului etc. Am alocat 30 de minute pentru asta, dar de multe ori nu ne-au fost suficiente. O alternativă ar fi să avem un Scrum-of-Scrums zilnic, cu toate acestea, nu am apucat niciodată să-l încercăm.

Agenda noastră a fost următoarea:

1. Toți au spus, la rândul lor, ce a făcut echipa lor săptămâna trecută, ce plănuiesc să termine în această săptămână și ce dificultăți au întâmpinat.

2. Orice alte aspecte legate de competența mai multor echipe în același timp care trebuie discutate. De exemplu, întrebări de integrare.

De fapt, agenda Scrum-of-Scrums nu este atât de importantă - este mai important ca această întâlnire să aibă loc în mod regulat.

Din cartea Scrum și XP: note din prima linie autorul Kniberg Henrik

Din cartea Blog profitabil: creează, promovează și câștigă autorul Litvin Evgeny

Din cartea autorului

Cum facem o demonstrație Sprint demo - foarte parte principală Scrum, pe care mulți încă îl subestimează. „Oh, trebuie să facem un demo? Oricum nu vom arăta nimic interesant!” „Nu avem timp să pregătim diferite &%$# demo-uri!” „Am mult de lucru

Din cartea autorului

Cum rulăm retrospective Deși formatul de bază variază puțin, practic facem asta: Alocați 1-3 ore, în funcție de cât de lungă este de așteptat să dureze discuția. Participanți: proprietarul produsului, întreaga echipă și eu. Ne aflăm fie într-un loc separat

Din cartea autorului

Cum combinăm Scrum cu XP Că Scrum și XP (eXtreme Programming) pot fi combinate eficient este dincolo de orice îndoială. Cea mai mare parte a raționamentului de pe Internet susține această presupunere și nu vreau să pierd timpul cu o justificare ulterioară.Totuși, un lucru trebuie încă de

Din cartea autorului

Îmbunătățiți calitatea incluzând testeri în echipa Scrum. Oh, deja aud acele obiecții: „Dar asta este evident! Echipele Scrum ar trebui să fie interfuncționale!” „Nu ar trebui să existe roluri dedicate într-o echipă Scrum! Nu putem avea o persoană care să facă doar teste!” Aș ține seminarii și cursuri de formare online Acest tip de venit este potrivit pentru cei mai ambițioși și competenți bloggeri, profesioniști, guru, experți în domeniul lor. Sau pentru acei bloggeri care, imperceptibil, au devenit astfel. Un blogger poate câștiga bani pe

Mi-a plăcut foarte mult „Scrum and XP: notes from the front line” de Henrik Kniberg tradus de Agile Ukraine. În ea împărtășește Henrik experienta personala Scrum Master în companii de software. Fără „apă”, fără digresiuni lirice, doar fapte despre cum au funcționat, cum altfel poți lucra și cum nu trebuie să lucrezi. Narațiunea la persoana întâi și umorul ocazional fac din această carte o lectură interesantă și ușoară.

Mai jos este un scurt rezumat al traducerii cărții. Anunțul traducerii este pe Habrahabr. Traducerea în limba rusă a cărții poate fi găsită la scrum.org.ua și originalul la infoq.com.

Backlog de produse și povestea utilizatorului

restante produs este fundamentul Scrum. Totul începe cu el. În esență, un backlog de produse este o listă de cerințe, povești, caracteristici, ordonate după importanță. În același timp, toate cerințele sunt descrise într-un limbaj înțeles de client. Poate fi stocat în Excel cu acces public.

Fiecare poveste este alcătuită din:

ID - un identificator unic - doar un număr de serie. Folosit pentru a identifica poveștile dacă sunt redenumite.
Nume - scurta descriere povestiri. De exemplu, „Vizualizarea jurnalului tranzacțiilor tale”. Ar trebui să fie clar, astfel încât dezvoltatorii și proprietarul produsului (proprietarul produsului) să poată înțelege aproximativ ce este în joc și să distingă o poveste de alta. De obicei, 2 până la 10 cuvinte.
Importanță - gradul de importanță al acestei sarcini, conform proprietarului produsului. De exemplu, 10. Sau 150. Cu cât valoarea este mai mare, cu atât importanța este mai mare. prioritate 0, -1, -2...)
O estimare inițială este o estimare inițială a cantității de muncă necesară pentru implementarea unei povești în comparație cu alte povești. Măsurat în puncte de poveste - o anumită laboriozitate relativă. Aproximativ corespunde numărului de „zile-om ideal” (factorul de focalizare este de 100%). Evaluat de dezvoltatori.
Cum se face demo - O scurtă explicație a modului în care sarcina finalizată va fi demonstrată la sfârșitul sprintului. Practic, este un simplu caz de testare „Fă asta, fă asta, ar trebui să funcționeze”.
Note - orice alte informații: explicații, link-uri către surse suplimentare de informații etc. Este de obicei prezentat sub formă de scurte rezumate.

Câmpuri suplimentare de istoric pentru a ajuta proprietarul produsului:

Categorie (pistă). De exemplu, „panou de control” sau „optimizare”. Cu acest câmp, proprietarul produsului poate selecta cu ușurință toate articolele din categoria „optimizare” și le poate seta la prioritate scăzută.
Componente - Specifică ce componente (de exemplu, baza de date, server, client) vor fi afectate atunci când povestea este implementată. Puteți face casete de selectare. Util pentru mai multe echipe Scrum.
Inițiatorul cererii (solicitantul). Un proprietar de produs poate dori să stocheze informații despre toți clienții care sunt interesați de o anumită sarcină. Acest lucru este pentru a-i ține la curent cu evoluția lucrărilor.
ID în sistemul de urmărire a defectelor (ID de urmărire a erorilor) - este util să stocați link-uri către toate defectele care se referă la acesta.

Poveștile nu trebuie să fie tehnice (creați indici), ci trebuie să descrie De ce acest lucru se face (pentru a accelera căutarea), iar opțional, în comentariu pot fi adăugate sfaturi despre indici. Așa se realizează poveștile orientate spre business.

Calitate

Calitatea externă este modul în care utilizatorii percep sistemul. O interfață de utilizator lentă și neintuitivă este un exemplu de calitate vizuală slabă.
Calitatea intrinsecă se referă la lucruri care nu sunt în mod normal vizibile pentru utilizator, dar care fac o diferență uriașă în mentenabilitatea sistemului. Aceasta este atenția proiectării sistemului, acoperirii testelor, lizibilitatea codului, refactorizarea etc.

Un sistem cu o calitate internă ridicată poate avea uneori unul extern destul de scăzut. Dar opusul este extrem de rar. Este greu să construiești ceva bun pe o fundație putredă. Calitatea internă nu poate fi subiect de discuție. Echipa trebuie să monitorizeze constant calitatea sistemului, așa că pur și simplu nu se discută.

Proprietarul produsului spune „...remediază rapid problema”. El încearcă să folosească calitatea internă ca o variabilă, vrea să reducem estimarea sarcinilor fără a reduce cantitatea de muncă. Cuvântul „plastic” ar trebui să te îngrijoreze.

Sacrificarea calității intrinseci este aproape întotdeauna o idee foarte proastă. Timpul economisit este neglijabil în comparație cu prețul pe care va trebui să-l plătiți atât în viitorul apropiat, cât și pe termen lung. De îndată ce calitatea codului se deteriorează, va fi foarte dificil să-l restabiliți.

Pentru a accelera dezvoltarea, trebuie să reduceți cantitatea de muncă, aruncând poveștile utilizatorilor mai puțin importante și simplificând pe cele mai importante la un nivel minim de lucru.

Planificarea sprintului

Ţintă

oferiți echipei suficiente informații pentru a lucra fără probleme timp de câteva săptămâni
convingeți proprietarul produsului că echipa își poate face treaba.

Înainte și în timpul planificării

Restul de produse trebuie să existe!
Proprietarul produsului trebuie să fie (sau cineva de încredere pentru a-și îndeplini rolul)
Fiecare produs trebuie să aibă un stoc de produse și un proprietar de produs.
Toate cele mai importante sarcini ar trebui clasificate în funcție de nivelul de importanță, iar valorile lor numerice nu trebuie să coincidă (este în regulă dacă sarcinile cu nivel scăzut importanțele au aceleași valori - cel mai probabil, nu vor cădea în sprintul actual și, prin urmare, nu vor fi discutate; nivelul de importanță este folosit numai pentru ordonarea poveștilor, dar nu și pentru compararea importanței; util pentru a lăsa goluri de numere întregi între valorile importanței)
Proprietarul produsului trebuie să înțeleagă fiecare poveste (cel mai adesea ei sunt autorul, deși uneori și alți membri ai echipei pot face sugestii, caz în care proprietarul produsului trebuie să le acorde prioritate). Ei nu trebuie să știe exact ce trebuie făcut, dar trebuie să înțeleagă de ce povestea utilizatorului a fost inclusă în stocul de produse. Prioritatea este atribuită numai de proprietarul produsului.
Determinarea importanței este treaba proprietarului produsului.
Estimarea costurilor cu forța de muncă este un efort de echipă.
Constrângeri de timp (nu folosiți mai mult decât timpul alocat pentru planificare; în fiecare oră există o pauză)

Rezultatul ar trebui să fie

Obiectiv Sprint (obligatoriu; definit în termeni de afaceri)
- poate fi destul de dificil să formulezi un obiectiv de sprint. Mai bine un obiectiv prost decât niciunul.
- scopul ar trebui să fie declarat în termeni de afaceri, nu termeni tehnici. Adică într-un limbaj de înțeles
  chiar și persoanelor din afara echipei
- Scopul sprintului ar trebui să răspundă la întrebarea principală „De ce lucrăm la acest sprint? De ce suntem
  Mergem cu toții doar în vacanță? Ținta definește proprietarul produsului
- obiectivul de sprint poate părea puțin prostesc și exagerat pe tot parcursul planificării. Dar mai des
  dintre toate, valoarea sa principală începe să apară la jumătatea sprintului, când oamenii încep să uite ce
  vor să realizeze în acest sprint.
Lista membrilor echipei (și gradul de angajare a acestora, dacă nu este sută la sută)
Sprint backlog (lista de povești incluse în sprint din backlog de produse)
- echipa este cea care decide câte povești vor fi incluse în stocul de sprint și nimeni altcineva
- proprietarul produsului poate influența alegerea poveștilor în sprint: schimbați prioritatea; modificarea volumului istoriei, reducând volumul de muncă: împărțirea istoriei în altele mai mici cu priorități diferite
- Poveștile sunt incluse într-un sprint bazat pe intuiție (funcționează bine pentru echipe mici și sprinturi scurte) și contează performanța
- Nu folosiți puncte de poveste fracționate! Deoarece scrum se concentrează pe crearea de produse finite, gata de livrare. Valoarea unei povești pe jumătate realizate este zero (sau chiar negativă).
Data demonstrației
- se determină experimental lungimea sprintului; sprinturile scurte permit companiei să fie cât mai „flexibilă”, ceea ce înseamnă că este pregătită să-și ajusteze frecvent planurile;
- Sprinturile lungi lasă mai mult timp pentru a crește ritmul, mai mult spațiu de manevră pentru a rezolva problemele și mai mult timp pentru a atinge obiectivul de sprint.
- sprinturile scurte sunt mai bune pentru proprietarul produsului, în timp ce sprinturile lungi sunt mai bune pentru dezvoltatori. Lungimea sprintului este întotdeauna un compromis
Locația și ora Scrum-ului zilnic (alese prin compromis; cel mai important este ceea ce vei face, nu ceea ce ai făcut deja)
- prânz: dimineața ar trebui să încercați să vă amintiți ce ați promis echipei să facă astăzi;
- dimineața: dimineața, ar trebui să încercați să vă amintiți ce ați făcut ieri pentru a putea raporta despre asta.

Poveștile scrise pe autocolante sunt lipite pe tablă în ordinea descrescătoare a priorității. În timpul discuției, ordinea se schimbă. Povestea este împărțită în sarcini, autocolante cu sarcini sunt lipite sub autocolantul poveștii corespunzătoare. Nu adăugăm sarcini în backlog-ul de produse în Excel deoarece:

Lista sarcinilor se modifică de obicei frecvent (sarcinile se pot schimba și pot fi revizuite pe tot parcursul sprintului. Este nevoie de prea mult efort pentru a sincroniza backlog-ul produsului în Excel cu ele);
Cel mai probabil, la acest nivel de detaliu, proprietarul produsului nu va fi implicat în proces.

Cantitatea optimă de istorie este de la două până la opt persoane-zile. Cu o productivitate medie a echipei de 40-60 de zile-om, vă permite să includeți aproximativ 10 povești într-un sprint. Uneori 5 și alteori 15.

Povești este ceva ce poate fi demonstrat că are valoare pentru proprietarul produsului

Sarcini- fie nu pot fi demonstrate, fie nu au nicio valoare pentru proprietarul produsului.

Calculul performanței

Tehnica „vremii de ieri”. Definiții.

Performanţă este o măsură a „cantității de muncă depusă”. Calculat ca suma scorurilor inițiale ale tuturor poveștilor care au fost livrate în timpul sprintului.

Disponibil zile-om- suma tuturor orelor de lucru (cu normă întreagă și cu jumătate de normă), luând în considerare timpul liber și concediul medical al fiecărui membru al echipei în timpul sprintului, împărțit la durata zilei de lucru.

Factorul de focalizare este raportul dintre cât de concentrată este echipa asupra sarcinilor sale principale. Când factorul de focalizare este scăzut, echipa se așteaptă la interferențe repetate cu munca lor sau presupune că estimările sunt prea optimiste. Factorul de focalizare este luat din ultimul sprint sau din media ultimelor câteva sprinturi

Performanță reală- suma estimărilor inițiale ale poveștilor finalizate în ultimul sprint. Unitatea de măsură este povestea.

Calculul performanței.

Factorul de focalizare = Performanță_reala / Disponibil_zile-om

Performanță_Proiectată = Disponibil_zile-om * Factorul de focalizare

Criteriul de pregătire

Proprietarul produsului și echipa lucrează împreună pentru a determina criteriile de pregătire. De exemplu

„Povestea este gata să fie implementată pe un server live”
„implementat pe un server de testare și pregătit pentru testarea de acceptare”
„povestea este gata atunci când testerul din echipa noastră Scrum crede că da” (verificarea că dorințele proprietarului produsului au fost corect percepute de echipă rămâne în conștiința testatorului)

Poveștile sunt foarte diferite unele de altele. Astfel, nu este posibil să se definească un criteriu general de pregătire. De aceea bun simț adesea mai bine decât o listă de verificare formală. Dacă deseori vă confundați cu definiția criteriului de pregătire, atunci probabil ar trebui să introduceți un câmp „criteriu de pregătire” pentru fiecare poveste.

Criteriul de pregătire poate fi definit:

descrierea clarificată a poveștii (ar trebui să fie scurtă și concisă)
jucând poker de planificare
o descriere a modului de a demonstra această poveste de utilizator.

O descriere simplă dezvăluie adesea o înțelegere diferită a domeniului de activitate al poveștilor. E bine să știi despre asta dinainte, nu-i așa?

Prioritățile procesului de planificare

Scopul sprintului și data demonstrației
acumulare de sprint
estimări pentru fiecare poveste din stocul de sprint
„cum să demonstrezi” pentru fiecare poveste de sprint în așteptare
calcule de performanță și resurse
un timp și un loc specific pentru scrumul zilnic
poveștile împărțite în sarcini (este, de asemenea, posibil să împărțiți poveștile în sarcini pe măsură ce intră în lucru, combinând acest lucru cu Scrum zilnic, dar nu este recomandat)

Povești tehnice (cerințe nefuncționale)

TI este tot ceea ce trebuie făcut, dar este invizibil pentru client, nu se aplică nici unei povești de utilizator și nu oferă un beneficiu direct proprietarului produsului. Pentru el, prioritizarea TI-urilor în stocul de produse a fost ca și cum ai compara cald cu moale. Prin urmare, ei primesc cea mai mică prioritate. În unele cazuri, proprietarul produsului are într-adevăr dreptate, dar de cele mai multe ori. Proprietarul produsului nu este întotdeauna competent să facă compromisuri în ceea ce privește revendicarea TI. Ce se poate face în privința asta:

Încercați să evitați TI. Căutați o modalitate de a transforma TI într-o poveste normală cu valoare de afaceri măsurabilă;
Dacă nu este posibil să transformați povestea tehnică într-o poveste obișnuită, încercați să includeți această lucrare într-o poveste deja existentă (de exemplu, „refactorizarea accesului la date” ar putea deveni parte din povestea „editează utilizatorul”, deoarece implică lucrul cu date);
Dacă ambele abordări nu au funcționat, îl marchem ca istoric tehnic și stocăm separat o listă cu astfel de povești. Lăsați proprietarul produsului să vadă lista, dar nu să o editeze. În negocierile cu proprietarul produsului, folosim parametrii „factor de focalizare” și „performanță estimată” și alocăm timp în sprint pentru a implementa poveștile tehnice.

Principiul fundamental al Scrum este transparența. Prin urmare, este de dorit să se informeze proprietarul produsului despre TI-urile necesare și nu doar să se prezinte un anumit factor de focalizare (scăzut de dragul TI) înainte de fapt. În același timp, proprietarul produsului trebuie să fie inteligent și competent.

bug tracker

Opțiuni pentru lucrul cu BT:

Proprietarul produsului imprimă sarcinile cu cea mai mare prioritate din BT, le aduce la planificarea sprintului și le atârnă pe perete cu alte povești (indicând implicit prioritatea lor relativă).
Proprietarul produsului creează povești care se potrivesc cu sarcinile din BT. De exemplu, „Remediați cele mai critice erori de raportare ale administratorului, #124, #126 și #180”.
Remedieri de erori nu sunt incluse în sprint, ceea ce înseamnă că echipa determină un factor de focalizare destul de scăzut (de exemplu, 50%), astfel încât să fie suficient timp pentru corecții. Apoi, se introduce ipoteza că echipa din fiecare iterație va petrece o anumită parte din timp pe erori în BT.
Introducem backlog-ul de produse în BT (doar îl transferăm din Excel). Considerăm că bug-urile sunt povești obișnuite.

informație

Este important să ții întreaga companie la curent cu ceea ce se întâmplă în echipa ta. Dacă acest lucru nu se face, atunci restul va începe să se plângă sau - și mai rău - va inventa tot felul de orori despre tine. Pentru a face acest lucru, puteți folosi „pagina de informații sprint”:

Numele echipei
Sprint restante (povestiri și cum să prezentați)
Program (interval de sprint, data demonstrației, locația și ora zilnică a scrumului)
Alinia

Această pagină este pusă pe wiki (și o listă cu toate echipele și sprinturile), iese prin poștă, este postată tipărită pe hol, când se apropie demo-ul, memento-ul se stinge (totul este făcut de scrum master) .

Întârziere de sprint

Tabloul (kanban) este format din 4 coloane (în planurile în curs, gata, informații suplimentare). Fiecare linie este o poveste de utilizator separată cu sarcini în ordinea descrescătoare a priorității (de sus în jos). Pe măsură ce sarcinile sunt finalizate, acestea trec de la „în planuri” la „în curs” la „terminat”. Partea de informații fixează obiectivul sprintului, diagrama de ardere, sarcinile neplanificate, dar necesare care nu au fost incluse în sprintul inițial-backlog și poveștile suplimentare ale utilizatorilor pe care este de dorit să le completeze dacă povestea utilizatorului planificată este finalizată inainte de finalul sprintului.

Simplitatea plăcii este esențială. Nu este nevoie să se complice. De asemenea, pe cardul de sarcini, puteți remedia numele interpretului și/sau identificatorul din bug tracker.

diagrama de ardere

Axa x arată doar zilele lucrătoare până la sfârșitul sprintului. Pe axa Y - cantitatea proiectată de muncă rămasă (în puncte de poveste). Modificările aduse lucrărilor rămase sunt înregistrate zilnic. ScrumMaster este responsabil să se asigure că echipa ia măsurile adecvate atunci când sunt detectate primele simptome de avertizare (deviația severă a curbei punctului de poveste de la linia normală de sprint).

Estimată în zile sau ore?

În majoritatea surselor de scrum, timpul de finalizare a sarcinii este estimat în ore, nu în zile (de exemplu, o zi efectivă de om este egală cu șase ore efective de muncă). Dar este mai bine să nu faci asta pentru că:

estimările în ore de om sunt prea mici, ceea ce duce la apariția un numar mare sarcini mici pentru o oră sau două și, ca urmare, la micromanagement (micromanagement);
s-a dovedit că toată lumea încă estimează în zile-om și când trebuie să obțineți o estimare în ore-om, pur și simplu înmulțesc zilele cu șase. „Hmm, această sarcină va dura aproximativ o zi. Da, trebuie să dau o estimare în ore. Ei bine, asta înseamnă ora șase.”
Două unități de măsură diferite sunt înșelătoare. „Este această estimare în zile-om sau în ore-om?”

Prin urmare, este mai bine să folosiți zile-persoană ca unitate principală în estimarea timpului (numiți-le puncte de poveste). În acest caz, alegeți cea mai mică valoare de 0,5. Acestea. orice probleme evaluate mai puțin de 0,5 sunt fie eliminate, fie combinate cu altele, fie scorul rămâne 0,5 (nu este nimic în neregulă cu un scor ușor supraevaluat). Elegant și simplu.

Inca

Asezati echipa impreuna

La îndemână (toată lumea din echipă poate vorbi cu orice alt membru al echipei fără să strige sau să se ridice de la birou)
Vizibil (fiecare membru al echipei poate vedea pe toți ceilalți. Toți pot vedea panoul de activități. Nu trebuie să fie suficient de aproape pentru a citi, dar măcar să vadă)
Standalone (dacă dintr-o dată întreaga ta echipă se ridică și începe o discuție bruscă și foarte animată despre arhitectura sistemului, niciunul dintre cei care nu sunt membri ai echipei nu va fi suficient de aproape pentru a interfera cu ea. Și invers. Standalone. nu înseamnă că echipa ar trebui să fie complet izolată. Într-un spațiu împărțit în secțiuni, s-ar putea să existe o secțiune separată pentru echipă, cu pereți suficient de înalți pentru a ține departe cea mai mare parte a zgomotului din exterior)

Nu lăsa

Produsul proprietarului este prea aproape. Proprietarul produsului ar trebui să fie suficient de aproape de echipă, astfel încât, dacă apar întrebări, echipa să-l poată întreba în persoană și să aibă posibilitatea de a merge singur la panoul de sarcini. Dar nu ar trebui să stea în aceeași cameră cu echipa. Pentru că există posibilitatea ca el să nu poată intra în detalii, iar echipa să nu poată lucra corespunzător (adică să nu obțină o stare de autonomie completă, automotivare și super-productivitate).
Managerii și antrenorii sunt prea apropiați. Dacă sunteți un Scrum Trainer (și posibil și un rol de manager), nu vă fie teamă să lucrați foarte strâns cu echipa. Dar numai pentru o anumită perioadă de timp, apoi lăsați echipa în pace și lăsați-o să lucreze împreună și să se organizeze. Verificați din când în când (dar nu foarte des). Acest lucru se poate face prin participarea la o demonstrație, studiind panoul de sarcini sau participând la Scrum zilnic.

Scrum zilnic

Efectuat pentru a menține actualizat stocul de sprint. Mai bine să o facă toată echipa.

Este mai bine să organizați o întâlnire în picioare (reduce probabilitatea de a întârzia „planificarea” cu mai mult de 15 minute)

Pe măsură ce fiecare membru al echipei vorbește despre ceea ce a făcut ieri și despre ce va face astăzi, el mută autocolantele pe panoul de sarcini.

Sau toți membrii echipei actualizează tabloul de sarcini înainte de fiecare întâlnire.

De îndată ce povestea se referă la o sarcină neplanificată, un nou autocolant este lipit pentru ea.

La actualizarea evaluărilor de timp, o nouă evaluare este scrisă pe autocolant, iar cea veche este tăiată. Uneori, ScrumMaster gestionează autocolante în timp ce participanții vorbesc.

fiind întârziat

Puteți obține o pușculiță specială. Dacă întârzii, chiar și pentru un minut, arunci o anumită sumă în pușculiță. Chiar dacă ai sunat înainte de începerea Scrum-ului zilnic și ai avertizat. Această abordare funcționează bine. Dar trebuie să-l folosești numai în cazul în care oamenii întârzie adesea.

Dacă cineva nu știe ce să facă cu el însuși

Puteți doar să transmiteți cuvântul celui următor. În același timp, ia-l pe un creion.
- După ce toată lumea a vorbit, treceți peste panoul de sarcini împreună cu echipa și verificați dacă datele de pe panoul de sarcini sunt actualizate și că toată lumea înțelege sensul fiecărei povești.
- Invitați fiecare membru al echipei să lipească autocolante noi.
- Revenim la cei care nu știau ce să facă cu întrebarea „după ce ne-am plimbat pe tablă, ați avut o idee despre ce să faceți?” Apare de obicei.
- Dacă nu, puteți afla dacă există o oportunitate de programare în pereche.
Consultați obiectivul de sprint
- Cereți să demonstrați obiectivul sprintului (realizați ceea ce este scris acolo).
- Dacă nu sunteți pregătit să întrebați ce trebuie făcut pentru demonstrație.
- Lipiți autocolante noi, atribuiți.
Doar lipiți autocolante noi.

Demo

Demo este necesară:

O evaluare pozitivă a muncii inspiră echipa.
Toți ceilalți vor ști ce face echipa ta.
La demonstrație, părțile interesate fac schimb de feedback vital.
Demo-ul are loc într-o atmosferă prietenoasă, iar echipele pot comunica liber între ele și pot discuta probleme stringente. Aceasta este o experiență valoroasă.
Rularea unei demonstrații obligă echipa să termine lucrurile și să le lanseze (chiar dacă este doar pe un server de testare). Fără o demonstrație, am ajuns întotdeauna cu o grămadă de lucrări finalizate în proporție de 99%. Rulând o demonstrație, s-ar putea să obținem mai puține sarcini, dar acestea vor fi de fapt terminate, ceea ce (în cazul nostru) este mult mai bine decât o grămadă de caracteristici care sunt „un fel” făcute și care vor rămâne sub picioare în următorul sprint.
Dacă demonstrația nu are succes, echipa va încerca să termine totul în următorul sprint! Se vor gândi „bine, poate în următorul sprint ar trebui să arătăm doar două lucruri în loc de cinci, dar la naiba, de data asta vor FUNCȚIONA!”.

Pregătirea și realizarea unei demonstrații:

Încercați să fiți cât mai clar posibil cu privire la scopul acestui sprint. Luați câteva minute pentru a aduce pe toți la curent.
Nu petrece mult timp pregătind o demonstrație sau creând o prezentare. Aruncă tot ce nu este necesar și concentrează-te pe demonstrarea doar a unui cod care funcționează cu adevărat.
Asigurați-vă că demonstrația rulează într-un ritm rapid. Concentrați-vă pe crearea unui demo care nu este atât de frumos, cât este dinamic.
Păstrați-vă demonstrația orientată spre afaceri, uitați de detaliile tehnice. Concentrați-vă pe „ceea ce am făcut” mai degrabă decât pe „cum am făcut-o”.
Dacă este posibil, lăsați publicul să încerce singur produsul.
Nu este nevoie să arătați o grămadă de remedieri de erori mici și caracteristici elementare. Le poți menționa, dar nu le arăta pentru că îți va lua mult timp.

Lucrurile „nedemonstrabile”, cum ar fi optimizarea codului pentru performanță, pot fi demonstrate fie prin grafice, diagrame sau tabele.

Retrospective

Retrospectiva este a doua activitate ca importantă în Scrum (după planificare). Retrospectiva este importantă pentru că acesta este cel mai bun moment pentru a începe să vă îmbunătățiți. Fără retrospective, veți descoperi că echipa calcă mereu și iar pe aceeași greblă.

Este posibil ca retrospectivele să nu aibă un plan clar, dar subiectul principal- mereu la fel: „Ce putem îmbunătăți în următorul sprint”. Practic, o retrospectivă se poate face astfel:

Alocați 1-3 ore, în funcție de cât de lungă este de așteptat să dureze discuția.
Implicați: proprietar de produs, întreaga echipă și ScrumMuster.
Instalează-te fie într-o cameră separată, fie pe terasă. Este bine ca discutia sa se desfasoare intr-o atmosfera linistita si relaxata.
Nu țineți retrospective în sala de lucru, deoarece acest lucru distrage atenția participanților.
Alege pe cineva care să fie secretarul tău.
ScrumMaster arată stocul de sprint și rezumă rezultatele sprintului cu participarea echipei. Evenimente importante, concluzii etc.
Să începem o serie de discuții. În acest moment, toată lumea are șansa de a comenta ceea ce a considerat că este bine, ce ar putea fi îmbunătățit și ce ar face diferit în următorul sprint. În același timp, nimeni nu îl întrerupe.
Comparăm performanța anticipată și cea reală. Dacă există discrepanțe semnificative, atunci încercăm să analizăm și să înțelegem de ce s-a întâmplat.
Când timpul expiră, ScrumMaster încearcă să rezume toate sugestiile specifice pentru ceea ce putem îmbunătăți în următorul sprint.

Tabloul retrospectiv este împărțit în 3 coloane:

Bun (dacă ar trebui să repetăm acest sprint, atunci am face exact la fel).
Ar putea fi mai bine (dacă ar fi să repetăm acest sprint, atunci am face-o altfel).
Îmbunătățiri (idei specifice despre cum pot fi îmbunătățite lucrurile în viitor).

După ce ați făcut brainstorming asupra tuturor acestor autocolante, faceți un „vot punctual” pentru a identifica îmbunătățirile cărora ar trebui să li se acorde o atenție specială în următorul sprint. Fiecare membru al echipei are trei magneți pe care îi poate folosi pentru a vota. Fiecare membru al echipei poate sculpta magneți după bunul plac, cel puțin toți trei deodată pentru o singură sarcină. Pe baza acestui vot, alege 5 îmbunătățiri pe care să încerci să le implementezi în următorul sprint și verifică ce s-a întâmplat la următoarea retrospectivă.

Este important să înveți din greșeli. Posibilele soluții la problemele găsite de echipă în retrospectivă pot fi
utile altora. ScrumMaster poate juca rolul unui link aici. Puteți scrie un raport, dar nimeni nu le citește. Ofițerul de legătură trebuie:

fii un bun ascultator;
Fiți gata să puneți o întrebare simplă, dar la obiect, care va stârni oamenii într-o discuție dacă retrospectiva merge foarte încet. De exemplu: „Dacă ai putea reface acest sprint din prima zi, ce ai face diferit?”;
Sunt de acord să-mi petrec timpul participând la toate retrospectivele tuturor echipelor;
să aibă autoritatea necesară pentru a prelua îmbunătățirile propuse de echipă dincolo de propriile capacități ale echipei.

Uneori este suficient doar să definiți clar problema și adesea se rezolvă singură în următorul sprint. Pentru a face acest lucru, atârnă notițe pe retrospectivă pe peretele din camera de lucru. Cu toate acestea, fiecare schimbare are prețul ei. Dacă încerci să faci ceva ca răspuns la fiecare plângere, oamenii vor fi reticenți să vorbească despre problemele lor chiar și cele mai mici, care pot fi îngrozitoare.

Odihnește-te între sprinturi

LA viata reala este imposibil să alergi ca un sprinter tot timpul. Între curse, trebuie să te odihnești oricum. Dacă alergi la o viteză maximă constantă, atunci în esență faci doar jogging. Același lucru este valabil și pentru Scrum și dezvoltare. softwareîn general. Sprinturile sunt foarte obositoare. Puțini se pot lăuda: „Mi-am petrecut cea mai mare parte a zilei punând picioarele pe masă, răsfoind bloguri și bând cappuccino”.

Un alt argument este că după demo și retrospectivă, echipa și proprietarul produsului vor fi copleșiți de informații și tot felul de idei pe care ar fi trebuit să le facă brainstorming. Dacă se ocupă imediat cu planificarea următorului sprint, atunci nu vor putea să eficientizeze toate informațiile primite sau să tragă concluziile corespunzătoare. În plus, proprietarul produsului nu va avea suficient timp pentru a-și ajusta prioritățile după demo.

Ar trebui să încercați să vă asigurați că retrospectiva sprintului și următoarea planificare a sprintului nu au loc în aceeași zi. Înainte de a începe un nou sprint, toată lumea ar trebui să doarmă bine fără să se gândească la sprinturi.

Una dintre variante - zile de inginerie. Acesta este momentul în care dezvoltatorilor li se permite să facă practic tot ce doresc. (citiți despre cele mai recente instrumente de dezvoltare și API-uri, pregătiți-vă pentru certificare, discutați despre plictisurile computerului cu colegii, lucrați la proiectul dvs. personal, mențineți-vă cunoștințele la zi). Este bine dacă putem face o zi de inginerie pentru toate echipele deodată (vor fi luate mai în serios). Poate fi fix (prima vineri a fiecărei luni) sau plutitor (la sfârșitul fiecărui sprint).

Voi revizui restul cărții puțin mai târziu.

Henrik Kniberg

Scrum și XP: note din prima linie

Din păcate, ni s-a dat doar o pagină pentru a ne mulțumi. Prin urmare, voi încerca să-i prezint pe toți activiștii noștri în fapte.

Maxim Kharchenko a reușit să traducă chiar și pe mare. Multumesc Hyper. NET

Dima Danilchenko este regizor și part-time (și asta se întâmplă ☺) unul dintre cei mai activi traducători din proiectul nostru.

Dacă în cursul cărții ți-a plăcut foarte mult traducerea și ai zâmbit, atunci cel mai probabil acest capitol a fost tradus de Artyom Serdyuk.

Borya Lebeda a automatizat conversia originalului din format Word în format wiki. Nu aveam idee că se poate face atât de ușor.

Yaroslav Hnatiuk îl cunoaște personal pe Henrik.

Anton Maryukhnenko este cel mai tânăr și mai promițător.

Sergey Petrov este cel mai bătrân și mai experimentat.

Marina Kadochnikova este singura noastră traducătoare.

Serezha Movchan, desigur, nu te-am uitat ☺. Am vrut doar să vă mulțumesc special. Ai fost a doua locomotivă, datorită căreia am reușit să ajungem la capătul victorios. La urma urmei, așa cum se spune într-un proverb japonez: „A începe este ușor, a continua este dificil”.

Mulțumim Marinei Zubritskaya și Lyosha Mamchiy pentru corectarea și editarea finală. Au reușit să găsească peste o sută de erori în textul deja aparent șlefuit. Nu există limită pentru perfecțiune.

Nu vom uita de cei care au avut o dorință, dar, așa cum se întâmplă adesea, nu a fost timp: Serghei Yevtushenko, Artyom Marchenko, Alexei Tigarev, Tim Evgrashin, Alexander Kulik.

Lyosha Solntsev,

inițiator și coordonator al primului proiect ucrainean de crowdsourcing, Certified Scrum Master

P.S. Puteți descărca cartea originală de la http://www.infoq.com/minibooks/scrum-xp-from-the-tranches

Cuvânt înainte de Jeff Sutherland

Echipele trebuie să cunoască elementele de bază ale Scrum. Cum se creează și se evaluează un backlog de produse? Cum să obțin backlog de sprint din el? Cum să lucrezi cu un grafic de ardere și să calculezi performanța (viteza) echipei tale? Cartea lui Henrik este un ghid de bază pentru începători pentru a ajuta echipele să treacă de la „încercăm Scrum” la „facem Scrum cu succes”.

O bună implementare a Scrum devine din ce în ce mai importantă pentru echipele care doresc să se investească.Acționez ca un coach agil pentru un grup de companii cu capital de risc, ajutându-le în încercarea lor de a investi doar în companii adevărate Agile.Șeful grupului de investitori solicită companiilor care alcătuiesc un portofoliu de investiții să răspundă la întrebarea dacă cunosc performanța echipelor lor. Mulți oameni sunt nedumeriți de această întrebare. Investițiile viitoare necesită ca echipele să își cunoască propria productivitate în dezvoltarea de software.

De ce este atât de important? Dacă echipa nu își cunoaște propria performanță, atunci proprietarul produsului nu poate dezvolta un plan strategic de dezvoltare a produsului cu date de lansare sigure. Fără un astfel de plan, compania poate eșua, determinând investitorii să-și piardă banii.

Companiile de toate felurile se confruntă cu această provocare: mari și mici, vechi și noi, cu și fără finanțare. În timpul unei discuții recente despre implementarea Scrum de către Google la o conferință de la Londra, am decis să întreb o audiență de 135 de persoane care folosesc Scrum? Am primit doar un răspuns afirmativ de la treizeci de persoane. Apoi am întrebat dacă procesul lor a urmat dezvoltarea iterativă standard Nokia. Dezvoltarea iterativă este un principiu cheie al Agile Manifest: „Încercați să furnizați versiuni ale software-ului funcțional cât mai des și cât mai devreme posibil.” Ca rezultat al efectuării retrospectivelor cu sute de echipe Scrum de-a lungul mai multor ani, Nokia a dezvoltat câteva cerințe de bază pentru dezvoltare iterativă:

Iterațiile trebuie să aibă o lungime fixă și să nu depășească șase săptămâni.

Până la sfârșitul fiecărei iterații, codul ar trebui să fie testat de departamentul de calitate (QA) și să funcționeze așa cum ar trebui.

Dintre cei treizeci de oameni care au spus că lucrează conform Scrum, doar jumătate au confirmat că echipele lor aderă la primul principiu al Agile Manifest și respectă standardul Nokia.

Apoi i-am întrebat dacă au respectat standardul Nokia Scrum:

O echipă Scrum ar trebui să aibă un proprietar de produs și echipa ar trebui să știe cine este acesta.

Proprietarul de produs trebuie să aibă un stoc de produse cu povești și evaluările lor efectuate de echipă.

Echipa trebuie să aibă o diagramă de ardere, iar echipa însăși trebuie să-și cunoască performanța.

În timpul sprintului, nimeni nu ar trebui să interfereze cu munca echipei.

Din cele 30 de echipe care implementau Scrum, doar trei au avut un proces de dezvoltare care a îndeplinit standardele Nokia. Cred că doar aceste trei echipe vor primi investiții suplimentare de la capitaliștii de risc.

Valoarea principală a cărții lui Henrik este că, dacă îi urmați sfaturile, veți avea un backlog de produse, scoruri de backlog de produse și un grafic de ardere. De asemenea, vei cunoaște performanța echipei tale și vei putea folosi toate cele mai importante practici ale echipelor Scrum performante. Vei trece testul Nokia Scrum, pentru care investitorii te vor aprecia. Dacă ești o companie start-up, atunci poate vei primi astfel de injecții financiare care sunt vitale pentru proiectul tău. Poate că ești viitorul dezvoltării de software, ești creatorul unei noi generații de software care va deveni lider de piață.

Cuvânt înainte de Mike Cohn

Atât Scrum, cât și XP (programare extremă) necesită ca echipele să finalizeze o lucrare tangibilă care poate fi livrată utilizatorului la sfârșitul fiecărei iterații. Aceste iterații sunt planificate să fie scurte și fixate în timp. Accentul pe eliberarea codului de lucru într-o perioadă scurtă de timp înseamnă un singur lucru: nu există loc pentru teorie în Scrum și XP. Metodologiile agile nu urmăresc modele UML frumoase realizate cu instrumente speciale pentru cazuri, creând specificații detaliate sau scriind cod care se potrivește tuturor ocaziilor. În schimb, echipele Scrum și XP se concentrează pe realizarea lucrurilor. Aceste echipe pot tolera erorile pe măsură ce merg, dar înțeleg că cel mai bun mod de a prinde aceste erori este să nu te mai gândești la software la nivel teoretic de analiză și design și să-ți sufleci mânecile și să te concentrezi pe construirea produsului.

Accentul pus pe acțiune, mai degrabă decât pe teorie, face ca această carte să iasă în evidență de restul. Că Henrik împărtășește aceste opinii este evident încă de la primele pagini ale cărții. Nu ne oferă o descriere lungă a ceea ce este Scrum; în schimb, pur și simplu se leagă la resursele web necesare. În primul rând, Henrik începe prin a descrie modul în care echipa sa lucrează cu stocul de produse. Apoi trece prin toate elementele și practicile unui proiect agil bine plasat. Fără teoretizare. Fără date de fundal. Nimic din toate acestea nu este nevoie: cartea lui Henrik este nu este o explicație filozofică a motivului pentru care Scrum funcționează sau de ce ar trebui să o facem în acest fel și nu altfel. Aceasta este o descriere a modului în care funcționează o echipă agilă de succes.

Henrik oferă o selecție de bune practici și exemple concrete pentru a ne ajuta să înțelegem cum să folosim Scrum și XP în prima linie.

Cuvânt înainte - Hei! Și Scrum funcționează!

Scrum funcționează! Cel puțin ni s-a potrivit (mă refer la proiectul clientului meu din Stockholm, al cărui nume nu aș vrea să-l numesc). Sper că ți se potrivește și ție! Și, poate, această carte vă va ajuta pe calea stăpânirii Scrum-ului.

A fost pentru prima dată în viața mea când am văzut cum funcționează metodologia (ei bine, da, Ken, - framework-ul) „de la capăt”. Doar plug and play. Și, în același timp, toată lumea este fericită: dezvoltatori, testeri și manageri. În ciuda tuturor necazurilor de pe piață și a reducerii de personal, Scrum ne-a ajutat să ieșim din cea mai dificilă situație, ne-a permis să ne concentrăm asupra obiectivelor noastre și să nu ne pierdem impulsul.

Nu vreau să spun că sunt surprins, dar... sunt. După ce am răsfoit câteva cărți despre acest subiect, Scrum mi-a făcut o impresie bună, prea frumoasă pentru a fi adevărat. Deci nu e de mirare că am fost puțin sceptic. Cu toate acestea, după un an de utilizare a Scrum, sunt atât de impresionat (și majoritatea oamenilor din echipele mele) încât cel mai probabil voi folosi Scrum pentru toate proiectele noi, ei bine, dacă nu există un motiv întemeiat să nu o fac.