Vizibilitate tuturor!

Sunt adeptul suprimării formelor fără fond cu precădere prin educație, viziune comună, focalizarea energiilor, obiectivism și foarte multă răbdare.

Alte diferențe dintre Scrum și Kanban. PDCA sau PDCASA sau PDSA?

Ciclul de ameliorare continuă PDCA (Plan + Do + Check + Act) a fost creat de Walter A. Shewhart, fiind dezvoltat și promovat ulterior de către W. Edwards Deming. Cele două modele, PDSA și PDCA, sunt similare și se bazează pe metoda științifică creată de Francis Bacon. Conform wikipedia, PDCA este rezultatul preferinței japonezilor pentru această prescurtare, însă ulterior Deming a înlocuit Check cu Study argumentând că PDSA se apropie mult mai mult de intenția lui Shewhart decât PDCA.

Ce înseamnă PDCA?

  • PDCA_-_ciclul_lui_DemingPlan – Definim ipotezele și ce ne dorim să verificăm. Tot în această etapă precizăm cum va decurge experimentul și măsurătorile pe care trebuie să le facem.
  • Do – faza de execuție.
  • Check – Comparăm rezultatele experimentului cu ceea ce ne-am dorit să obținem inițial.
  • Act (mai nou Adjust) – Analizăm cauzele obținerii rezultatelor diferite față de ipotezele inițiale și deducem ce anume vom schimba în iterația următoare.

Pentru PDCA și PDSA s-au mai folosit și denumirile Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, și doar la Laurent Morisseau am auzit de diferențierea celor două (PDCA <> PDSA). Mai târziu, reflecțiile mele au mers mai departe de micile nuanțe semantice: a verifica însemnând controlul de conformitate cu așteptările definite (Check), în timp ce a studia presupune un proces mult mai complex de inspecție, analiză, reflecție, memorare, reamintire și reprezentare (Study).

Care sunt diferențele dintre PDCA și PDSA?

Din punctul meu de vedere, există o diferență majoră între PDCA și PDSA, iar în tabelul de mai jos am încercat să descriu exemplific utilizând cadrul Scrum și metoda Kanban:

Scrum Kanban
Etapă Descriere Etapă Descriere
Plan Evenimentul numit „Planificarea sprintului” (Engleză: Sprint Planning) corespunde acestei etape. Plan Specificăm următorul experiment: cum ajustăm limitarea cantității de muncă, cum îmbunătățim debitul folosind un model demonstrat științific ș.a.m.d. Ulterior ne facem un plan, fără să stabilim neapărat și așteptările legate de următoarele funcționalități care vor rezulta în timpul execuției.
Do Realizarea experimentului are loc odată cu execuția sprintului, după Planificarea Sprintului. Do Pornim robinetul: realizarea muncii în flux continuu.
Check Inspectarea rezultatelor, activitate ce ține de „Revizuirea Sprintului” (Sprint Review). Se vor identifica defecte, cerințe care n-au fost implementate conform așteptărilor, etc.  Study Observăm sistemul și efectele aplicării noului plan, ceea ce nu implică neapărat o inspecție a rezultatului produsului – suntem la nivel de sistem.
Act În „Revizuirea Sprintului” analizăm cauzele diferențelor dintre așteptări și rezultat, elaborând acțiunile corective.  Act Analizăm cauzele distanței dintre rezultate și așteptări. Apoi trecem la concluzie și pregătim următorul experiment.
Study În „Retrospectiva Sprintului” echipa se studiază pe ea însăși. Echipa reflectează asupra Definiției lui Finalizat (pentru o cerință, pentru sprint, etc.), asupra eficienței în general, etc.
Act În „Retrospectiva sprintului” echipa își adaptează comportamentul în funcție de cele învățate.
 Plan+Do+Check+Act+Study+Act  Plan+Do+Study+Act

Observați coloana Scrum. Mulți consideră un Sprint în Scrum ca fiind un ciclu PDCA, unde Check = Revizuirea Sprintului, iar Act = Retrospectiva Sprintului. În realitate, atât în Revizuirea Sprintului cât și în Retrospectiva Sprintului, inspectăm, analizăm și luăm decizii. Deci facem Check+Act, sub rezerva că retrospectiva este mult mai profundă decât o inspectare și o adaptare simple. Din acest motiv, eu apreciez retrospectiva ca fiind un eveniment de studiu și de adaptare (Study + Act). Am putea vorbi despre un model: PDCASA.

Plan-Do-Plan+Do+Check+Act-Study-ActDin păcate, lipsa unui Plan + Do care să includă PDCA într-un ciclu PDSA limitează ameliorarea sistemului în Scrum. Deci, în Scrum avem o singură etapă de Plan și una singură de Do, atât pentru concluziile ce țin de verificarea rezultatelor cât și pentru cele ce țin de studierea sistemului.

În imaginea din stânga am încercat să reprezint un ciclu PDCA inclus într-unul PDSA.

Tot din această cauză cred că Scrum-ul încurajează echipele auto-centrate. Toate ameliorările se vor rezuma la cantitatea și calitatea funcționalităților livrate, dovezi indirecte și deseori insuficiente în evaluarea performanței organizației.

De exemplu, în Retrospectiva Sprintului echipa statuează că modificarea codului vechi generează prea multe probleme. Echipa hotărăște să învețe și să aplice TDD. Deseori, o astfel de ajustare nu este abordată în Planificarea Sprintului (Plan), este greu de verificat în Revizuirea Sprintului (Check), iar în următoarea Retrospectivă (Study) uităm să analizăm cum a evoluat sistemul în urma aplicării noilor practici.

Când vine vorba de Kanban, lipsește un ciclu PDCA din corpul de reguli. Acest lucru nu înseamnă că un astfel de ciclu nu poate fi adăugat în practică, doar că nu este predefinit.

Plan-Do-Plan+Do+Check+Act-Study-Act_Kanban_Scrum_Ideal

Alte exemple PDCA

Scrum-ul zilnic (Daily Scrum) poate fi corelat și el cu modelul PDCA:

Etapă Întrebare
Plan Ce voi face astăzi ca să-mi ajut echipa să-și atingă obiectivul de sprint?
Do Munca efectuată până la următorul Scrum zilnic (Daily Scrum).
Check Ce am făcut ieri pentru a ajuta Echipa de Dezvoltare să atingă Obiectivul Sprint-ului?
Act Văd vreun impediment care m-ar putea împiedica pe mine sau pe Echipa de Dezvoltare să atingem Obiectivul Sprint-ului?

Concluzie

În literatura IT întâlnim frecvent cele două modele, însă eu găsesc exagerat acest fapt din cauza încălcării principiului igieniei din metoda științifică. Conform acestui principiu, înainte de începerea unei noi iterații, trebuie să reinițializăm contextul experimentului. În producția software moștenim de la o iterație la alta condiții care pot schimba radical natura experimentului. O decizie specifică etapei „Act”,de ajustare, poate duce la rezultate diferite dacă se execută în a doua iterație sau în ultima. Astfel, din punctul meu de vedere, referirile la PDCA sau PDSA în cursurile de management IT țin mai mult de domeniul marketingului decât de cel al științificului.

Laurent Morisseau spunea în cartea sa, Kanban pour l’IT: PDSA este preferat de sistemele complexe unde este dificil să definești rezultatele așteptate. În consecință, a treia etapă (Check) nu poate rămâne o verificare, ci una a studiului (Study) sistemului.

Din punctul meu de vedere, dacă cele două modele sunt văzute așa cum le-am definit în acest articol, PDSA ar trebui să fie preferat în defavoarea PDCA, chiar și când vine vorba de Scrum.

Alte diferențe dintre Scrum și Kanban. Plan+Do+Check+Act sau Plan+Do+Check+Act+Study+Act sau Plan+Do+Study+Act?

Cornel FătulescuArticol scris de Cornel Fătulescu. Găsiți mai multe informații despre Cornel Fătulescu pe pagina membrilor AgileHub, în articolul despre mine sau la pagina de contact.

Comentarii

Comentarii