Metodologii de dezvoltare software: Lean vs. principiile Agile

„Lean” și „Agile” sunt termeni care au fost aruncați foarte des în ultima vreme, adesea cu referire la metodologiile de dezvoltare software, managementul proiectelor sau stiluri organizaționale.

Dar v-ați trezit vreodată întrebându-vă:

Ce este Lean? Ce este Agile? Există o diferență?

Dicționarul Merriam-Webster definește Agile ca fiind „având un caracter rapid, plin de resurse și adaptabil, sau marcat de abilitatea gata să se miște cu grație rapidă și ușoară.”

Lean este definit pur și simplu ca fiind „subțire și sănătos, sau care conține puțină sau deloc grăsime.”

Bazându-ne pe aceste definiții, putem presupune că cineva care este lean și cineva care este agil ar putea avea multe caracteristici comune. Același lucru este valabil și în contextul dezvoltării de software.

Ce este Agile? Ce este Lean?

Agile este acum cunoscut pe scară largă în lumea tehnologiei ca un set de valori și principii pentru a ghida dezvoltarea de software. „Manifestul Agile” prezintă un set de patru valori și 12 principii. Distilat în esența sa, Agile este exact ceea ce credeți că ar putea fi. Este Agile. Metodologia favorizează flexibilitatea, comunicarea, colaborarea și simplitatea.

Lean este mai puțin înțeleasă și nu are o definiție clară susținută de un consens profesional. termenul „Lean” a fost inițial inventat pentru a descrie un model de organizare a producției bazat pe sistemul de producție Toyota, dar este considerat în mod obișnuit un subcadru în cadrul umbrelei Agile de dezvoltare software.

Astăzi, există multă confuzie cu privire la ce este Lean, ce este Agile, dacă sunt unul și același lucru și care ar trebui folosit.

Nașterea noilor metodologii de dezvoltare software

Atât Lean, cât și Agile au fost dezvoltate ca răspuns la deficiențele metodelor existente bazate pe planuri, cum ar fi Waterfall. Folosite încă din anii 1970, dezvoltatorii și managerii de inginerie software au început să observe ineficiența Waterfall prin anii ’90. Cu piețe mai dinamice și consumatori mai pricepuți la tehnologie, Waterfall nu a fost în măsură să răspundă suficient de rapid la cerințele pieței, la schimbările tehnologice sau să livreze software fără erori în mod constant.

În căutarea unui model mai bun, creatorii Lean și Agile au căutat să dezvolte metodologii cu o abordare mai centrată pe client. Noile metodologii au îmbrățișat capacitatea de adaptare ca avantaj competitiv, au favorizat testarea timpurie și continuă și au adus un element uman în managementul și execuția proiectelor.

Principiile Lean vs. Agile

Lean Software Development (LSD) a fost propus pentru prima dată de dr. Robert Charette ca o modalitate de a construi organizații care să tolereze schimbările și care deveneau din ce în ce mai dependente de software.

Apoi a apărut „Manifestul Agile”, care a consacrat cele 12 principii ale Dezvoltării Agile a Software-ului.

Cealaltă lucrare de autoritate privind metodologiile de dezvoltare a software-ului este creditată lui Mary și Tom Poppendieck, care au publicat Lean Software Development: An Agile Toolkit.

Iată o comparație alăturată a valorilor și principiilor fiecăreia dintre ele:

Comparând cele 12 principii ale LSD ale Dr. Charette și cele 12 principii ale Agile, puteți vedea că acestea sunt izbitor de asemănătoare. Cele șapte principii Lean propuse de Poppendiecks sunt mai puțin vizate, dar totuși se suprapun cu „Manifestul Agile” și cu Lean Software Development al lui Charette.

Iată mai multe elemente pe care toate acestea le au în comun:

• Valoarea de a răspunde rapid la nevoile clienților
• Testarea timpurie
• O abordare iterativă a dezvoltării
• Stilul de dezvoltare MVP (Minimum Viable Product) față de feature heavy
• Cooperarea atât în cadrul companiei, cât și cu părțile interesate din exterior

Cronologie

Am investigat evenimentele și publicațiile de referință care au dat naștere acestor terminologii pentru a vedea cum au devenit populare. Consultați cronologia noastră de mai jos care detaliază progresia și adăugați-le pe lista dvs. de lecturi, dacă sunteți înclinați!

Originea Lean și Agile

După cum puteți vedea din cronologie, termenul Lean a fost folosit pentru prima dată de Womack et. al. în 1990 pentru a descrie sistemul de producție Toyota în cartea lor, The Machine That Changed The World. Dr. Robert Charette a adaptat ulterior ideile Lean descrise în publicațiile anterioare pentru a crea lucrarea sa „Lean Software Development”.

Termenul Agile nu a fost adoptat pe scară largă până la publicarea „The Agile Manifesto” în 2001. Termenii Agile și Lean au fost ambii inventați de profesioniști occidentali din domeniul tehnologiei sau de academicieni care făceau referire la Sistemul de producție Toyota (mai multe despre acest lucru mai târziu).

S-ar putea să primim unele critici pentru că spunem acest lucru, dar având în vedere acest lucru, termenii Lean și Agile nu sunt de fapt atât de importanți. A avea doi termeni care derivă din aceleași principii contribuie de fapt la confuzie pe această temă. Acestea fiind spuse, aceasta este terminologia pe care a adoptat-o industria, așa că, în continuare, vom continua să le folosim.

Cronologia este, de asemenea, o altă sursă de confuzie. Dr. Robert Charette și-a introdus ideile despre Lean Software Development la începutul și mijlocul anilor ’90. Scopul tactic și cele 12 principii ale abordării sale Lean Development au fost descrise în 1998 într-un articol intitulat „Lean Development”, cu aproape trei ani înainte de „Manifestul Agile”. Ca o dovadă a suprapunerii dintre Lean și Agile, acest articol a fost scris de Jim Highsmith, care mai târziu a devenit un fondator de bază al mișcării Agile. Cu toate acestea, articolul lui Highsmith nu a fost distribuit pe scară largă și abia în 2003 Charette însuși a scris o explicație mai detaliată în spatele abordării sale de dezvoltare Lean în raportul de cercetare, „Challenging the Fundamental Notions of Software Development.”

Într-un schimb de e-mail cu dr. Charette, acesta s-a grăbit să sublinieze faptul că concepția sa despre Lean Development a fost destinată nivelului organizațional din domeniul software:

A mea a luat naștere dintr-o nevoie strategică, dar și operațională, de a îmbunătăți valoarea afacerii/misiunii IT pentru organizație, iar eu am abordat acest lucru dintr-o perspectivă de gestionare a riscurilor.
-Dr. Robert N. Charette

Acest lucru diferă ușor de Agile, care a fost propus la început strict ca un „mod mai bun de a dezvolta software”, dar acum este aplicat la diverse proiecte și metode de management.

2003 a fost, de asemenea, anul în care Poppendiecks au publicat Lean Software Development: An Agile Toolkit. Această carte a detaliat șapte principii ale dezvoltării Lean, care se corelează direct cu cele șapte forme de risipă din Lean Manufacturing.

Cartea familiei Poppendiecks a consolidat simultan Lean ca metodologie de dezvoltare software și a estompat distincția dintre Lean și Agile, propunând Lean ca metodă complementară în cadrul Agile. De fapt, la momentul publicării, cartea a fost vândută ca fiind cea mai recentă publicație din cadrul seriei The Agile Software Development Series.

Astăzi, multiplele lucrări ale familiei Poppendiecks pe această temă sunt considerate lecturi esențiale pentru practicienii de dezvoltare software Lean și pentru cei care „aspiră la Lean”.

Divergență în aplicare

Potrivit Dr. Charette, una dintre diferențele principale dintre Lean și Agile este că Agile este de jos în sus, în timp ce Lean este de sus în jos. Acest lucru este evident în structura Lean de la un capăt la altul (E2E) și în principiul See the Whole (Vezi întregul) propus de Poppendiecks. Mai jos explicăm aceste principii la lucru în practica cartografierii fluxului de valoare.

Cartografierea fluxului de valoare

Pentru a realiza principiul See the Whole, Poppendiecks detaliază o metodă de cartografiere a fluxului de valoare pentru a dezvălui activitățile cu valoare adăugată față de activitățile fără valoare adăugată de-a lungul procesului de dezvoltare end-to-end.

Cartografierea fluxului de valoare analizează ciclul de dezvoltare din momentul în care se primește o cerință până în momentul în care aceasta este livrată clientului. Scopul este de a identifica risipa de stocuri staționare și de așteptare (întârzieri în producție) și de a explora noi practici pentru a reduce lucrările în curs de execuție (WIP) și timpul de execuție.

Potrivit celor de la Poppendieck, cartografierea fluxului de valoare este un exercițiu simplu care necesită doar un creion și o bucată de hârtie. Procesul este următorul:

1. Hașează fluxul de valoare actual (începând cu o cerință și o cronologie a acțiunilor pe drumul spre livrare)
2. Analizează cea mai mare cauză a risipei (Ce reține Work-in-Progress?)
3. Dezvoltați un plan pentru a reduce această risipă la jumătate
4. Creați o hartă viitoare a fluxului de valoare

Paradigma Agile, așa cum este prezentată în „Manifestul Agile”, favorizează ciclurile scurte de iterații și livrările frecvente în detrimentul unei viziuni holistice de la un capăt la altul. Prin urmare, accentul pe E2E este unic pentru Lean. De fapt, datorită construcției E2E, Lean (mai degrabă decât Agile) este mai des aplicat ca structură organizațională și stil de management.

Vederea de la un capăt la altul necesită ca întreaga organizație să participe pentru a elimina risipa. Acest lucru face ecou scopului declarat de Dr. Charette pentru conceptul său original de Lean Development:

Lean Development este o filozofie, un mod de a vedea și de a gândi despre IT și relația sa cu o organizație, la fel de mult ca și o abordare de dezvoltare.

Lean Kanban Vs. Agile Kanban

Atât Lean cât și Agile au adoptat sistemul TPS Kanban cu mici variații. Sistemul Kanban de la Toyota a fost conceput pentru a limita Work-in-Progress.

Spre deosebire de producția tradițională de tip „push manufacturing”, care împinge inventarul către următoarea etapă a procesului, Kanban atrage material nou în producție doar după ce piesa curentă a fost procesată și componentele trebuie să fie reaprovizionate.

Cărțile Kanban devin comenzi de reaprovizionare și sunt trimise înapoi la etapa anterioară a producției. Ca urmare, volumul de lucru în desfășurare este minimizat, iar inventarul inactiv este redus.

În dezvoltarea de software, în loc să se treacă cardurile Kanban de la o etapă de producție înapoi la cea anterioară, se folosește o tablă Kanban. Se folosesc notițe lipicioase, cel mai adesea pentru a reprezenta cerințele în curs.

Potrivit capitolului la care a contribuit Kai Petersen în Modern Software Engineering Concepts and Practices: Advanced Approaches, atât Agile, cât și Lean folosesc o listă de cerințe prioritizate din care să extragă sarcinile.

Spre deosebire de Agile, care folosește cicluri de iterații cu durată fixă pentru a limita timpul de dezvoltare și pentru a guverna tabloul Kanban, Lean limitează numărul de sarcini permise la un moment dat. Acest lucru permite Lean să își îndeplinească obiectivul principal de limitare a WIP, în timp ce măsoară cu mai multă acuratețe timpul de execuție și identifică risipa în producție. Odată ce o sarcină este finalizată, o nouă sarcină poate fi extrasă din lista de priorități. În timp ce Lean folosește conceptul de flux continuu, Agile începe fiecare nouă iterație cu o planșă nouă.

Câteva echipe recunosc beneficiile ambelor abordări și încep să folosească o metodă hibridă cunoscută sub numele de scrumban.

Acestea sunt doar două dintre diferențele subtile de abordare pe care Lean și Agile le au pentru a atinge obiective comune. Un alt articol publicat pe Codementor explorează mai multe dintre utilizările și aplicațiile Lean și Agile.

În practică, indiferent dacă echipa dvs. adoptă o așa-numită abordare „Agile” sau o abordare „Lean”, nu are importanță. Ceea ce este important este să găsiți practicile potrivite pentru a vă optimiza fluxurile de lucru și pentru a oferi în mod constant valoare clienților dumneavoastră, ceea ce ambele metodologii consideră a fi scopul final.

Conexiunea TPS

Atunci ce legătură au toate acestea cu Sistemul de producție Toyota? Cam totul. Creatorii atât ai Agile cât și ai Lean au fost puternic influențați de TPS, după cum descriu Womack et. al. în The Machine That Changed the World. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. Compania nu putea spera să urmeze modelul de producție în masă din Detroit și să supraviețuiască.

În aceste condiții, Taiichi Ohno și Kiichiro Toyoda și-au propus să rămână profitabilă prin eliminarea risipei în producție, prin reducerea timpului de execuție și prin producerea doar a ceea ce aveau nevoie clienții, cunoscută și sub numele de producție Just-in-Time (JIT).

Pentru a elimina risipa, Ohno s-a hotărât să producă doar ceea ce era necesar, când era necesar și doar în cantitatea necesară.

Procesul iterativ Lean și Agile, care se concentrează pe minimizarea dezvoltării de caracteristici și pe maximizarea livrării de actualizări, reflectă în mod direct producția Just-in-Time a Toyota.

Jidoka

Jidoka (自働化) poate fi tradus ca automatizare cu o atingere umană, denumită uneori „automatizare inteligentă”. Jidoka joacă un rol major în eliminarea risipei în producție, făcând mașinile mai independente, ceea ce eliberează oamenii pentru a juca un rol mai activ în producție și deblochează creativitatea umană.

Jidoka se bazează pe mașini inteligente care se opresc automat atunci când există o neregulă. Lucrătorii umani pot merge apoi să rezolve problema, împiedicând transmiterea defectelor în procesul de producție.

Jidoka împuternicește, de asemenea, fiecare angajat să oprească linia de producție atunci când este detectată o problemă. Principiul include un proces în patru pași pentru a elimina risipa de produse defecte:

1. Detectați anomalia
2. Întrerupeți producția
3. Reparați sau corectați condiția imediată
4. Investigați cauza principală și remediați situația

Puteți vedea conceptul Jidoka în concentrarea Lean și Agile pe testarea timpurie și frecventă pentru a elimina erorile și accentul pus pe consultarea clienților pentru a identifica durerile utilizatorilor.

Deșeurile TPS în contextul dezvoltării de software

Pentru a realiza producția JIT, Taiichi Ohno a subliniat șapte forme de deșeuri care trebuie eliminate. Numărul opt a fost adăugat ulterior. Dacă vă uitați mai atent la valorile, obiectivele și principiile Agile și Lean, puteți vedea că acestea sunt concepute pentru a se proteja împotriva celor opt deșeuri ale TPS. În cartea lor din 2003, Lean Software Development: An Agile Toolkit, soții Poppendieck au prezentat risipa TPS într-un context de dezvoltare software:

1. Risipa de supraproducție. Risipa de supraproducție este unul dintre cele mai mari motive pentru care metoda Waterfall a fost abandonată. Supraproducția este considerată codare suplimentară pentru caracteristici care nu au fost solicitate și pe care clientul poate să nu le dorească.

Aceasta se reflectă în următoarele principii:

Agile ⟶ simplitate
Charette’s Lean⟶ minimalism
Poppendiecks’ Lean ⟶ eliminarea risipei

2. Risipă de așteptare. În producția JIT, așteptarea unei mașini sau a unui muncitor inactiv este o risipă. În dezvoltarea de software, risipa este așteptarea unei echipe cu capacitate excedentară. Dacă există întârzieri în producție care determină o echipă să fie în așteptare sau determină clientul să aștepte livrarea, există risipă.

Principiile de potrivire sunt următoarele:

Agile ⟶ cicluri frecvente
Charette’s Lean ⟶ ⅓ din timp (obiectivul LSD), 80% soluție astăzi
Poppendieck’s Lean⟶ livrați cât mai repede posibil

3. Risipa din transport. În dezvoltarea de software, transportul se traduce prin „schimbarea sarcinilor”. Prea multe transferuri sau angajați repartizați la mai multe echipe cu o cerere de multitasking excesiv este ineficientă și reprezintă o risipă.

Principiile care corespund:

Agile ⟶ colaborarea părților interesate, echipe care se auto-organizează, cultură a
încrederii, sprijinului și motivației
Charette’s Lean ⟶ efortul echipei
Poppendieck’s Lean ⟶ împuternicește echipa

4. Risipă de supraprocesare. Acestea sunt pur și simplu procese suplimentare care nu sunt cu adevărat necesare pentru a oferi valoare clientului. Exemplul principal este documentația. Documentația excesivă pentru procese inflexibile nu va fi valoroasă, la fel cum nu sunt nici manualele de utilizare prea detaliate care ar putea fi rezumate într-o pagină sau două. Documentația este consumatoare de timp, dar oferă o valoare limitată pentru utilizatorul final.

Principiile care se potrivesc:

Agile ⟶ simplitate, software de lucru ca măsură
Charette’s Lean ⟶ minimalism
Poppendiecks’s Lean ⟶ eliminarea risipei

5. Risipa de inventariere. Deșeurile din inventar sunt lucrări în curs de execuție pentru care s-a făcut o investiție, dar care nu au nicio valoare până la finalizare. Cu alte cuvinte, un software incomplet nu oferă nicio valoare pentru utilizator. Lean și Agile valorizează livrările rapide și frecvente, punând accentul pe cicluri iterative frecvente și pe livrarea de software funcțional.

Principii care se potrivesc:

Agile ⟶ satisfacția clienților (prin livrări timpurii și frecvente către clienți)
Charette’s Lean ⟶ 80% soluție astăzi
Poppendieck’s Lean ⟶ livrează cât mai repede posibil

6. Risipa de mișcare. Risipa de mișcare este efortul în exces necesar pentru a obține informații sau a răspunde la întrebări. Acest lucru este frecvent atunci când echipele nu sunt colocalizate, dacă sarcinile sunt finalizate și rezultatele nu sunt puse imediat la dispoziția tuturor părților relevante sau când părțile interesate nu sunt ușor de consultat.

Principii de potrivire:

Agile ⟶ colaborarea cu părțile interesate, comunicarea față în față
Charette’s Lean ⟶ participarea clientului, efortul echipei
Poppendiecks’ Lean ⟶ eliminarea risipei

7. Risipa de defecte. La fel ca în producție, producerea de software defectuos sau cu bug-uri reprezintă o investiție irosită de către companie. Cu cât un defect este detectat mai repede, cu atât este mai probabil ca risipa să fie atenuată. Multe dintre principiile Agile și Lean urmăresc să stopeze risipa de defecte. Pentru a reduce defectele, toate cele trei metodologii pun accent pe testarea timpurie și frecventă.

Principiile care se potrivesc:

Agile ⟶ excelență tehnică, software de lucru ca măsură
Charette’s Lean ⟶ satisfacția clientului
Poppendiecks’ Lean⟶ amplifică învățarea

8. Risipa creativității nefolosite a angajaților. În dezvoltarea de software, creativitatea nefolosită rezultă dintr-o foaie de parcurs rigidă și din lipsa de colaborare umană. La fel ca Jidoka (自働化), Agile și Lean caută să maximizeze cooperarea și inovarea umană pentru a obține cele mai bune rezultate din tehnologie.

Principii care se potrivesc:

Agile ⟶ colaborarea părților interesate, reflecția în echipă
Charette’s Lean ⟶ al 13-lea principiu „nescris” al satisfacției prin
lucru
Poppendiecks’ Lean ⟶ amplifică învățarea

Valorile TPS în metodologia de dezvoltare software

Multe dintre valorile de bază care alcătuiesc TPS sunt, de asemenea, reflectate în metodologiile de dezvoltare software Agile și Lean.

Kaizen (改善) se traduce prin îmbunătățire continuă. Cu modele flexibile, iterative, axate pe client, îmbunătățirea continuă este poate cea mai importantă valoare a metodologiilor de dezvoltare software Agile și Lean.

Hansei (反省) înseamnă auto-reflecție. Ca mijloc de îmbunătățire a eficienței, Manifestul Agile adoptă în mod direct auto-reflecția echipei ca al 12-lea principiu. Prezentând modelul său de dezvoltare Lean, Dr. Charette îi provoacă pe cititori să reflecteze asupra tuturor ipotezelor actuale care dictează procesele pe care le folosesc, ca un prim pas spre găsirea unora mai bune. Principiul de amplificare a învățării al lui Poppendiecks poate fi considerat, de asemenea, Hansei.

Respectul pentru oameni (尊重) este central în toate cele trei paradigme. Prima valoare a „Manifestului Agile” este de a „prețui indivizii și interacțiunile în detrimentul proceselor și instrumentelor.”

Respectul pentru oameni apare, de asemenea, în afirmația Dr. Charette privind importanța ca indivizii să experimenteze satisfacție prin muncă și în principiul Lean al lui Poppendiecks de împuternicire a echipelor. Această valoare recunoaște că, atunci când indivizii sunt implicați în luarea deciziilor și în îmbunătățirea mediului lor de lucru, ei sunt lucrători mai inovatori și mai eficienți.

Seiri (整理) este principiul care oglindește risipa. Seiri dictează că ceea ce este inutil trebuie eliminat. Acesta cuprinde toate cele șapte risipe originale ale TPS, pentru care am identificat deja risipa paralelă în mediul de dezvoltare software.

Gengchi Genbutsu (現地現物) se traduce literal prin „loc real, lucru real”. În practică, acest lucru înseamnă „inspectat pentru a înțelege”. Atunci când există o problemă în procesul de producție, managerul ar trebui să meargă la sursă pentru a înțelege problema și a determina cum să o rezolve.

În dezvoltarea de software, această valoare se manifestă prin accentul pus pe ciclurile scurte de iterații, pe testarea timpurie și pe colaborarea cu clienții, astfel încât inginerii de software să poată construi software funcțional pe care utilizatorii îl doresc cu adevărat.

Concluzie

După cum am menționat în primele paragrafe ale acestei postări, metodologia Lean este mai puțin înțeleasă și este adesea considerată a fi o practică Agile. Lean este poate mai puțin bine definită pur și simplu din cauza aplicațiilor sale mai largi.

Lean are o relație mai directă cu Sistemul de Producție Toyota și a fost propusă pentru prima dată ca un set organizațional de metode și practici pentru managementul afacerilor și abia mai târziu a fost aplicată la dezvoltarea de software. Agile, pe de altă parte, a fost dezvoltat special pentru dezvoltarea de software de către profesioniști dedicați în domeniu.

După ce am detaliat contextul comun și principiile generale ale acestor două metodologii, puteți vedea că aceste două paradigme au mai multe în comun decât diferențe.

Unul dintre principalii autori ai „Manifestului Agile”, Martin Fowler, care a lucrat, de asemenea, îndeaproape cu familia Poppendieck, a subliniat faptul că Lean și Agile nu se exclud reciproc:

Lean și Agile sunt profund interconectate în lumea software-ului. Nu poți vorbi cu adevărat despre faptul că sunt alternative….nu faci Agile sau Lean, ci faci Agile și Lean.

1. Cele 12 principii ale Lean Software Development ale lui Charette au fost de fapt descrise pentru prima dată în articolul lui Jim Highsmith „Lean Development” din 1998. Ulterior, acestea au fost elaborate în propriul articol al lui Dr. Charette „Challenging the Fundamental Notions of Software Development” ︎

.