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?
Plan – 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. | ||
 |
 |
||
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.
Din 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.
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?
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 4898 ori