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.

Niciun proces final. Care sunt diferențele dintre un proces empiric și unul definit?


În continuarea articolului „Gânduri despre agilitate. Ce înseamnă să fim agili?”.

„Niciun proces final”, sau fără proces finit, era denumirea unui paragraf în cartea „Scaling Lean & Agile Development” a lui Craig Larman. Nimic nu putea fi mai șocant pentru mine. Tocmai fusesem formatat, în perioada 2007-2008, la standardul ISO 9001, care punea accentul pe proces înainte de orice altceva.

Craig Larman - Scaling Lean & Agile Development - No final process O parte din răspunsul la această nedumerire a venit din înțelegerea diferențelor dintre rezultate stocastice sau deterministe, explicându-mi principiul procesului de control statistic și cum se poate răspunde diferitelor nevoi prin implementarea proceselor definite sau empirice. Am învățat că sisteme pe deplin deterministe nu există, cu excepția experimentelor de laborator. Orice proces industrial are în cel mai bun caz ieșiri parțial deterministe. Chiar și un proces definit poate produce rezultate stocastice.

Cu cât înaintam în lumea agilă, cu atât aceste noțiuni erau mai bine conturate. Întreaga comunitate părea să fie de acord cu:

  • procesul definit este ca o linie de producție, care caută aceleași ieșiri de fiecare dată,
  • de foarte mult timp, metodologiile de dezvoltare software s-au bazat pe procese definite de control
  • controlul empiric se face prin inspecție și adaptare frecvente
  • dezvoltarea software nu este un proces care să genereze aceleași ieșiri pornind de la o anumită intrare
  • toate seturile de reguli și practici agile, metodologiile agile, împărtășesc recunoașterea că dezvoltarea software este un proces empiric.

Martin Fowler explică foarte elegant diferențele dintre cele două tipuri de procese, comparând procesele realizării unei prăjituri cu cel de a face un duș.

Prăjitura de fructe

prăjitura_cu_fructe

  • înțelegem procesul foarte bine,
  • știm cum să facem prăjitura pentru că am făcut-o de mai multe ori,
  • luăm același număr de ingrediente,
  • le combinăm în exact același fel,
  • le punem în cuptor pentru cât timp știm deja că trebuie să stea,
  • de fiecare dată iese aceeași prăjitură cu fructe,
  • și putem continua așa la nesfârșit, repetând procesul pentru foarte mult timp și obținând mereu aceleași rezultate.

Acesta este un proces bine definit, este bine înțeles, totul poate fi pregătit dinainte, executăm procesul și obținem rezultatul.

defined

Dușul

duș

Când facem duș într-o cameră de hotel în care n-am mai fost, folosim celălalt tip de proces, procesul empiric, pentru că nu cunoaștem cum să poziționăm cadranul în vederea obținerii apei la căldura de care avem nevoie.

  • dăm drumul la duș,
  • băgăm mâna să vedem temperatura apei,
  • este prea rece, prea caldă? ajustăm după cum vrem,
  • intrăm în duș, apa este plăcută la început, dar pe măsură ce ne încălzim vrem ca apa să fie mai caldă.

Deci, ne uităm la ieșiri (rezultat), inspectăm ieșirile și adaptăm intrările bazându-ne pe ceea ce am învățat. Toate acestea pentru că gestionăm ceva ce ne este mai puțin cunoscut. Chiar dacă este un proces simplu, tot nu știm în avans cum va fi apa înainte să dăm drumul la duș.

empiric

Cele două procese comparate

duș și prăjitură

Martin subliniază că folosirea procesului definit acolo unde datele de intrare sunt necunoscute poate fi periculos. În software, avem aceste componente neliniare, ingredientele, reprezentate de oameni. Deci nu putem folosi eficient un proces definit în aceste circumstanțe. Avem nevoie de un proces empiric în loc. Acest lucru presupune că trebuie să inspectăm ieșirile și să integrăm această inspecție într-un ciclu de feedback, motiv pentru care feedbackul este așa o parte centrală în gândirea agilă.

La cele spuse mai sus, putem veni ca o completare cu argumentul lui Ken Schwaber, co-creatorul Scrum:

„Nu va exista un Scrum 2.0. De ce nu? Pentru că scopul Scrum-ului nu este să rezolve problemele specifice legate de dezvoltare. Premiza de bază a Scrum-ului este că oamenii, tehnologia și specificațiile majorității proiectelor software sunt prea complexe pentru o singură soluție. Scrum-ul scoate la iveală problemele cauzate de această complexitate și lasă organizațiile să le rezolve, una câte una, iar și iar. Metodologiile tradiționale aduc răspunsuri la toate problemele, din acest motiv ele nu funcționează – ele presupun o problemă simplistă în loc de una complexă…”

În încheiere, mai fac o paralelă cu întrebarea „casă în agile”. Craig Larman explică în cărțile sale cum a aplicat principiul metodologiei abia suficiente (Barely Sufficient Methodology)  în industria nucleară, având proiecte agile auditate de NUPIC, fără nicio problemă identificată, devenind astfel un model în întreaga industrie. Dacă a funcționat acolo, poate că merită să încercăm și noi folosirea proceselor empirice în proiectele noastre?!

Citește în continuare …

Niciun proces final. Care sunt diferențele dintre un proces empiric și unul definit? Empirism.

Cornel FătulescuDacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți ca voluntar pe pagina membrilor AgileHub, asociație în care sunt cofondator, ca mentor la ScriuCod, ca CTO la Pentalog sau să citiți unul dintre primele articole despre mine și să mă contactați la pagina de contact.

Acest articol a fost citit de 1512 ori