sâmbătă, octombrie 13, 2012

The Scrum Way!

Cateva probleme observate in viata de zi cu zi folosind Scrum - o sinteza de idei care mi s-au parut de folos si le-am notat aici. Daca incepeti un proiect nou sau folositi deja Scrum (agile) in proiectele voastre se poate sa va fie de folos si voua (trebuie sa aveti notiuni de baza de Scrum pentru a intelege cele descrise in continuare).


Nu toti oamenii sunt pregatiti pentru Scrum si agile dar mai ales pentru a dezvolta in echipa; la inceput scoala si mai apoi firmele de la noi nu incurajeaza echipa. Vorbesc aici de ideea de beautifull team cu oameni de valoare asemanatoare lucrand impreuna pe termen lung (indefinit) si nu de chirurg cu asistenti cum se intapla de obicei la noi. La noi se incurajeaza individul (Competence Culture bazata pe specializare, certificari, etc si nu Collaboration or Cultivation Culture). Ca un contra exemplu in scolile din Japonia, elevii fac toate activitatile din timpul zilei  impreuna in grupe iar cea mai mare pedeapsa pentru cineva este aceea de a fi exclus din grup; poate nu intamplator Scrum isi are radacini si in Japonia (Takeuchi and Nonaka - The Scrum Way). Astfel intr-o echipa Scrum trebuie detectati sabotorii si distinsi de cei care sunt doar sceptici (sunt usor de distins pe scrum board, planning, si in general prin atitudinea care o au fata de metodologie) - o solutie pentru sabotori este ca ei sa fie gestionati prin management clasic in afara echipei de Scrum.

De la inceput trebuie respectate principiile fundamentale ale metodologiei Scrum pentru a nu face de fapt dezvoltare adhoc (poate este mai rau decat a folosi efectiv si corect RUP sau orice metodologie neagila dar iterativa - exludem Waterfall despre care este stiut ca este un esec inca din anii 70 in tarile civilizate dar care la noi este folosita pe scara larga -  deoarece esecul sau succesul in proiecte nu conteaza). Empirismul in Scrum vine din reglarile pe care le facem la nivelul acestor reguli de baza (spre exemplu estimarile), dar regulile trebuie respecate absolut si nu arbitrar. De asemenea rolurile in Scrum trebuie respectate si de asemenea metricile trebuie folosite - planning cu estimari, determinarea velocity (cel mai sigur in sprint 3), mentinerea unui ritm continuu: sustainable pace. Daca nu folosim toate acestea, obtinem doar rezultate partiale cum ar fi focusare, sincronizare pentru echipa, unele sprinturi reusite.

Story-urile nu trebuie sa fie use case-uri detaliate - trebuie incurajate discutiile si nu scrierea de documente iar product owner-ul trebuie sa fie mereu disponibil pentru ceilalti pentru a le clarifica in timpul sprint-ului - nu trebuie sa faca o alta activitate (mai grav, el trebuie sa participe la stand up meeting pentru a urmari evolutia storiurilor si a actualiza backlog-ul pentru sprinturile urmatoare - atentie: nu pentru task-uri ci pentru story-urile de pe scrum board); Story-urile trebuie sa aiba o forma as a/when/then care implica si flow nu doar aspecte statice (pagini spre exemplu); pot fi initialal epics sau teme pana la grooming; de asemena, pentru a compensa lipsa specificatiilor, codul trebuie sa fie bine scris (clean code) si acoperit cu teste pentru ca el devine un fel de documentatie a proiectului (deoarece alta documentatie nu exista)

Alte principii care trebuie respectate (ordinea conteaza):
  • trebuie tinut cont ca echipa sa fie cross functional si self managed (cuprinde toti oameni de care e nevoie pentru a implementa scopul sprint-ului si nu e nevoie de nimeni din exterior sa-i gestioneze); cei care participa si in extra activitati trebuie introdusi cu o anumita norma - nu trebuie sa faca alte task-uri inafara de cele din sprint; echipa trebuie sa fie relativ constanta pentru a putea calcula velocity si a se putea forma impreuna
  • trebuie sa se lucreze incremental (un set de features facute end to end si gata de delivery in orice increment - adica nu toata aplicatia in lucru la un moment dat); Scrum este o metodologie agila (embrace change) dar si iterativa (iteratii cu cadenta fixa in timp) si incrementala (increment de funtionalitate la finalul fiecarei iteratii - eventual shipable)
  • a nu se folosi pentru inceput unelte/tool-uri sofisticate pentru ca ele nu salveaza (trebuie physical scrum board cu post its, excel product/release/sprint backlog, planning poker cards); uneltele pot fi folosite ulterior cand exista confidence interval pentru velocity
  • a se evita ownership-ul pe parti ale aplicatiei de catre dezvoltatori (chiar daca e un responsabil pe story sau task care se asigura ca va deveni done - per increment lucreaza mai multi in acelasi timp - cunostintele sunt impartasite de mai multi si se evita expuneri de interfete cu  tot felul de integrari costisitoare)
  • viata de zi cu zi a echipei trebuie sa fie ghidata de evenimentele din Scrum; metodologia trebuie sa devina un mod de viata pentru echipa in orele de lucru (ete inacceptabil ca cineva sa cheme pe ceilalti la meeting-uri!)
  • product owner nu este un project manager ci doar un membu al echipei; el nu trebuie in nici un fel sa opreasca sau limiteze creativitatea echipei - nu este responsabil de cum se implemneteaza intern story-urile; el este parte a echipei si nu un judecator al celorlalti - implicarea lui este activa, zi de zi in viata echipei (demo nu inseamna scaun de judecata si de aceea ar fi mai bine sa fie numit review)
  • definitia lui done trebuie negociata de la inceput si bine stiuta de toti (poate fi mai slaba - functionalitatea de baza si mici bug-uri deschise; sau 0 bugs); done in mod ideal inseamna automated unit/integration tested (inseamna ca membrii echipei sa foloseasca TDD, ATDD de la inceput) - testele automate garanteaza calitatea codului pe termen lung (regresii usor de facut)
  • estimarea se poate face in story points (greu la inceput din cauza diferentelor de intelegere a complexitatii si a alegerii unei referinte relativ la care sa se estimeze) care marcheaza cantitatea de munca sau ideal days care insemna spre exemlu 6 din 8 ore pentru o zi
  • product backlog trebuie sa existe inainte de sprint-uri si trebuie mereu mentinut cu grooming de story-uri si estimari noi de story points or ideal days; este datoria PO; trebuie mentinut intre sprinturi si grooming la fiecare sprint planning meeting
  • in planning evaluarea trebuie facuta pe story-uri de toti (nu doar de catre cel care o sa o implementeze - eventual folosind poker planning ca in XP - deoarece la planning nu se stie cine o sa implementeze efectiv)
  • granularitatea pe scrum board (in cazul in care se folosesc ideal days) trebuie sa fie intre 0.5 si 2 zile
    • daca e mai mica -> micromanagement
    • daca e mai mare -> surprize, surprize
  • burndown chart-ul se deseneaza in functie de estimarea a cat mai e de facut si nu a cat s-a facut (intr-un excel se tin noile estimari) - se taie estimarea de pe task si se pune noua estimare (deci nu conteaza cat timp real se pierde ci cat se estimeaza ca o sa mai fie nevoie - de fapt e o reestimare); de asemenea la calcularea velocity conteaza estimarile initiale si nu timpul real cheltuit per story-uri
  • spatiul de lucru (recomandat sa fie open office) trebuie sa fie conform metodologiei; oarecum oamenii trebuie sa stea toti impreuna; scrum board-ul trebuie sa fie langa ei