sâmbătă, aprilie 27, 2013

Visual Scrum

Pentru ca deja am inceput sa uit, am incercat sa schitez in acest post cateva idei cu care am ramas dupa cursul de CSM. Nu exista o ordine prea clara in idei si in general e ceea ce nu stiam sau nu-mi era clar, precum si particularitati ale modului in care prezentatorul abordeaza Scrum (accent pe visual management). Deci nu sunt chestiuni de baza ale Scrum care se gasesc in carti.

Idei generale
  • Scrum a fost denumit framework si nu metodologie pentru a reflecta natura sa schematica (skeleton - golurile trebuie sa fie umplute de nevoile specifice ale fiecarui proiect - loc pentru empirism); o metodologie implica o descriere amanuntita a tuturor detaliilor si impune respectarea lor (RUP spre exemplu)
  • Scrum fata de XP are o natura nontehnica dar s-a observat ca fara tehnicile din XP este aproape imposibil sa se creeze working software dupa fiecare Sprint (demo pentru Review)
  • Scrum Sprint este time boxed si nu scope boxed
  • Scrum master is not a secretary - echipa este cea care-si gestioneaza progresul 
  • Scrum Master = training and coaching (Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime)
Lucruri de care nu stiam sau nu eram constient
  • Definition of ready - similar with the definition of done, this definition express what are the criteria to be accomplished to consider a story ready to be taken in a sprint and implemented (http://www.romanpichler.com/blog/product-backlog/the-definition-of-ready)
  • Improvements backlog - a separate backlog managed by team containing just technical improvements (for keeping project backlog just with items reflecting business value for PO) (http://coachingagile.blogspot.ro/2010/12/build-team-improvement-backlog.html)
  • Inception - reprezinta perioada de inceput a proiectului inainte de primul sprint in care se creaza backlogul initial, si se poate definiti/schita arhitectura generica a proiectului pentru a oferi consistenta intregului proiect (http://www.infoq.com/news/2008/09/sprint_zero)
  • Definition of done - just generic rules for entire set of items from backlog (not individual acceptance criteria); any story from initial product backlog that is a constraint for all backlog items will be put in DOD (performance constraints for example)
  • Acceptance criteria nu fac parte din DOD ci sunt enuntate de testeri ca test case-uri la inceputul sprintului si pot fi folosite in Review (se poate pregati demo-ul cu ele)
  • Nu e recomandat ca Scrum Master-ul sa fie si partea a echipei de dezvoltare (ex. 50%) deoarece va trebui sa aleaga intre task-urile lui si moderarea procesului
  • Sprint burndown chart (project/release burndownchart da) nu este recomandat deoarece folosind visual management este redundant (e invechit - Scrum 1.0)
  • Story-urile nu au nici un voluntar asociat (nici task-urile dacat in momentul in care se iau in lucru  de pe scrum board) ci se estimeaza in grup cu plannig poker (sau mai simplu se aseaza pe un perete sub cartile de planing poker corespunzator valorii estimate) 
  • Cel mai prioritar task de pe board este cel care aduce cea mai mare valoare echipei, asemanator cu prioritizarea backlog-ului pe criterii de business (cand cineva isi alege task-ul nu trevuie sa-l ia pe cel mai usor sau pe cel care il stie cel mai bine)
  • Tasks rules (anyone must work/ prioritized by most valuable thing to the team/ no one can tell anyone what to do)
  • Folosirea de post-it-uri si in Retrospective - votarea cu puncte a importantei subiectelor pentru a vedea care e importanta (se pastreaza un istoric a pprblemelor de al o retrospectiva la alta si se face check ca au fost rezolvate de la sprint la sprint)
  • Pe Scrum Board se lasa in mod intentionat o linie goala pentru a putea primi task-uri urgente de la PO legate de proictul din productie (trebuie discernamant in acceptarea lor)
  • Pentru a evita transformarea sprinturilor in micro-waterfalls trebuie ca echipa sa paralelizeze munca tinand cont ca sunt mai multe story-uri in lucru: testerii fac testcase-uri cu analistii la primul story apoi urmeaza implementarea, al doilea story intre in dezvoltare si se face testarea la primul story, etc
  • Votarea poate fi foarte simpla folosind o mana - deseori este nevoie sa supunem la vot  (da - palma, nu - pumnul, degetele pentru valori de la 1 la 5)
  • In cazul in care sunt mai multe echipe se prefera ca denumirile lor sa fie cate de culori si nu nume de animale
  • Scrum of scrums - o intalnire la care sunt delegati sa participe cate un membru a fiecarei echipe (nu neaparat Scrum Masterul); asemanatoare cu daily scrum cu accent pe posibilele interactiuni intre echipe
Link-uri cu resurse