Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Funcțiile suplimentare, cum ar fi hârțogăraia și funcțiile care nu sunt folosite des de clienți, sunt deșeuri. Schimbarea oamenilor între sarcini este risipă. Așteptarea altor activități, echipe, procese este risipă. Reînvățarea necesară pentru a finaliza munca este risipă. Defectele și calitatea scăzută reprezintă risipă. Cheltuielile generale manageriale care nu produc valoare reală sunt risipă.
Pentru a identifica risipa se utilizează o tehnică de cartografiere a fluxului de valoare. Al doilea pas este acela de a evidenția sursele de risipă și de a le elimina. Eliminarea risipei ar trebui să aibă loc în mod iterativ până când chiar și procesele și procedurile aparent esențiale sunt lichidate.
Amplificați învățareaEdit
Dezvoltarea de software este un proces de învățare continuă bazat pe iterații la scrierea codului. Proiectarea de software este un proces de rezolvare a problemelor care implică dezvoltatorii care scriu codul și ceea ce au învățat. Valoarea software-ului se măsoară prin adecvarea la utilizare și nu prin conformitatea cu cerințele.
În loc să se adauge mai multă documentație sau o planificare detaliată, se pot încerca diferite idei prin scrierea codului și construirea. Procesul de culegere a cerințelor utilizatorilor ar putea fi simplificat prin prezentarea de ecrane utilizatorilor finali și obținerea opiniilor acestora. Acumularea de defecte ar trebui să fie prevenită prin rularea de teste imediat ce codul este scris.
Procesul de învățare este accelerat prin utilizarea unor cicluri scurte de iterații – fiecare dintre acestea fiind cuplate cu refactorizare și teste de integrare. Creșterea feedback-ului prin intermediul unor sesiuni scurte de feedback cu clienții ajută la determinarea fazei actuale de dezvoltare și la ajustarea eforturilor pentru îmbunătățiri viitoare. În timpul acestor sesiuni scurte, atât reprezentanții clienților, cât și echipa de dezvoltare învață mai multe despre problema domeniului și își dau seama de posibile soluții pentru dezvoltarea ulterioară. Astfel, clienții își înțeleg mai bine nevoile, pe baza rezultatului existent al eforturilor de dezvoltare, iar dezvoltatorii învață cum să satisfacă mai bine aceste nevoi. O altă idee în procesul de comunicare și învățare cu un client este dezvoltarea bazată pe seturi – aceasta se concentrează pe comunicarea constrângerilor soluției viitoare și nu a soluțiilor posibile, promovând astfel nașterea soluției prin dialogul cu clientul.
Decideți cât mai târziu posibilEdit
Deoarece dezvoltarea de software este întotdeauna asociată cu o anumită incertitudine, ar trebui obținute rezultate mai bune cu o abordare bazată pe seturi sau pe opțiuni, întârziind cât mai mult posibil deciziile până când acestea pot fi luate pe baza faptelor și nu pe presupuneri și predicții incerte. Cu cât un sistem este mai complex, cu atât mai multă capacitate de schimbare ar trebui să fie încorporată în el, permițând astfel amânarea unor angajamente importante și cruciale. Abordarea iterativă promovează acest principiu – capacitatea de a se adapta la schimbări și de a corecta greșelile, care ar putea fi foarte costisitoare dacă sunt descoperite după lansarea sistemului.
Cu dezvoltarea bazată pe seturi: Dacă este nevoie de un nou sistem de frânare pentru o mașină, de exemplu, trei echipe pot proiecta soluții la aceeași problemă. Fiecare echipă învață despre spațiul problemei și proiectează o soluție potențială. Pe măsură ce o soluție este considerată nerezonabilă, aceasta este tăiată. La sfârșitul unei perioade, proiectele care au supraviețuit sunt comparate și una dintre ele este aleasă, poate cu unele modificări bazate pe învățarea de la ceilalți – un exemplu excelent de amânare a angajamentului până în ultimul moment posibil. Deciziile în materie de software ar putea beneficia, de asemenea, de această practică pentru a minimiza riscul adus de o proiectare mare în avans. În plus, ar exista apoi mai multe implementări care funcționează corect, dar care sunt diferite (din punct de vedere al implementării, la nivel intern). Acestea ar putea fi utilizate pentru a pune în aplicare sisteme tolerante la erori care verifică toate intrările și ieșirile pentru corectitudine, în cadrul implementărilor multiple, simultan.
O abordare agilă de dezvoltare a software-ului poate muta construcția de opțiuni mai devreme pentru clienți, întârziind astfel anumite decizii cruciale până când clienții își vor fi realizat mai bine nevoile. Acest lucru permite, de asemenea, adaptarea ulterioară la schimbări și prevenirea unor decizii anterioare costisitoare legate de tehnologie. Acest lucru nu înseamnă că nu ar trebui să fie implicată nicio planificare – dimpotrivă, activitățile de planificare ar trebui să se concentreze pe diferitele opțiuni și pe adaptarea la situația actuală, precum și pe clarificarea situațiilor confuze prin stabilirea unor modele de acțiune rapidă. Evaluarea diferitelor opțiuni este eficientă din momentul în care se realizează că acestea nu sunt gratuite, ci oferă flexibilitatea necesară pentru luarea deciziilor târzii.
Livrează cât mai repede posibilEdit
În epoca evoluției rapide a tehnologiei, nu cel mai mare supraviețuiește, ci cel mai rapid. Cu cât produsul final este livrat mai repede, fără defecte majore, cu atât mai repede poate fi primit feedback-ul și poate fi încorporat în următoarea iterație. Cu cât iterațiile sunt mai scurte, cu atât mai bune sunt învățarea și comunicarea în cadrul echipei. Cu viteză, deciziile pot fi amânate. Viteza asigură satisfacerea nevoilor actuale ale clientului și nu a ceea ce acesta a cerut ieri. Acest lucru le oferă posibilitatea de a amâna luarea unei decizii cu privire la ceea ce au nevoie cu adevărat, până când obțin cunoștințe mai bune. Clienții apreciază livrarea rapidă a unui produs de calitate.
Ideologia producției just-in-time ar putea fi aplicată la dezvoltarea de software, recunoscând cerințele și mediul specific al acestuia. Acest lucru se realizează prin prezentarea rezultatului necesar și lăsând echipa să se organizeze și să își împartă sarcinile pentru realizarea rezultatului necesar pentru o anumită iterație. La început, clientul furnizează informațiile necesare. Acesta ar putea fi prezentat pur și simplu în mici carduri sau povești – dezvoltatorii estimează timpul necesar pentru implementarea fiecărui card. Astfel, organizarea muncii se transformă într-un sistem de auto-tragere – în fiecare dimineață, în timpul unei ședințe de stand-up, fiecare membru al echipei analizează ce s-a făcut ieri, ce urmează să se facă astăzi și mâine și solicită orice contribuții necesare de la colegi sau de la client. Acest lucru impune transparența procesului, ceea ce este benefic și pentru comunicarea în echipă.
Mitul care stă la baza acestui principiu este că graba face risipă. Cu toate acestea, implementarea lean a prevăzut că este o bună practică să livrezi rapid pentru a vedea și analiza rezultatul cât mai devreme.
Împuternicește echipaEdit
A existat o credință tradițională în majoritatea afacerilor cu privire la procesul de luare a deciziilor în organizație – managerii le spun lucrătorilor cum să își facă propria muncă. Într-o tehnică de work-out, rolurile sunt inversate – managerii sunt învățați cum să îi asculte pe dezvoltatori, astfel încât aceștia să poată explica mai bine ce acțiuni ar putea fi întreprinse, precum și să ofere sugestii de îmbunătățire. Abordarea lean urmează principiul agile „construiește proiecte în jurul unor indivizi motivați și ai încredere în ei pentru a face treaba”, încurajând progresul, depistând erorile și eliminând impedimentele, dar nu microgestionând.
O altă credință greșită a fost considerarea oamenilor ca fiind resurse. Oamenii ar putea fi resurse din punctul de vedere al unei fișe de date statistice, dar în dezvoltarea de software, precum și în orice activitate organizațională, oamenii au nevoie de ceva mai mult decât lista de sarcini și asigurarea că nu vor fi deranjați în timpul îndeplinirii acestora. Oamenii au nevoie de motivație și de un scop mai înalt pentru care să lucreze – un scop în cadrul realității accesibile, cu asigurarea că echipa ar putea să-și aleagă propriile angajamente. Dezvoltatorilor ar trebui să li se ofere acces la client; liderul echipei ar trebui să ofere sprijin și ajutor în situații dificile, precum și să se asigure că scepticismul nu distruge spiritul echipei. Respectarea oamenilor și recunoașterea muncii lor este o modalitate de a împuternici echipa.
Construiți integritatea înEdit
Clientul trebuie să aibă o experiență globală a sistemului. Aceasta este așa-numita integritate percepută: modul în care acesta este promovat, livrat, implementat, accesat, cât de intuitivă este utilizarea sa, prețul său și cât de bine rezolvă problemele.
Integritatea conceptuală înseamnă că componentele separate ale sistemului funcționează bine împreună ca un întreg, cu un echilibru între flexibilitate, mentenabilitate, eficiență și capacitate de reacție. Acest lucru ar putea fi obținut prin înțelegerea domeniului problemei și rezolvarea acesteia în același timp, nu secvențial. Informațiile necesare sunt primite în loturi mici – nu într-o singură bucată vastă – de preferință prin comunicare față în față și nu prin documente scrise. Fluxul de informații ar trebui să fie constant în ambele direcții – de la client la dezvoltatori și înapoi, evitându-se astfel cantitatea mare și stresantă de informații după o dezvoltare îndelungată în izolare.
Una dintre căile sănătoase către o arhitectură integrală este refactorizarea. Cu cât se adaugă mai multe caracteristici la baza de cod originală, cu atât devine mai dificil să se adauge noi îmbunătățiri. Refactorizarea are ca scop păstrarea simplității, clarității, a unui număr minim de caracteristici în cod. Repetițiile în cod sunt semne ale unei proiectări proaste a codului și trebuie evitate. Procesul complet și automatizat de construcție ar trebui să fie însoțit de o suită completă și automatizată de teste pentru dezvoltator și client, având aceeași versiune, sincronizare și semantică ca și starea actuală a sistemului. La final, integritatea ar trebui să fie verificată prin teste amănunțite, asigurându-se astfel că sistemul face ceea ce se așteaptă clientul să facă. Testele automatizate sunt, de asemenea, considerate parte a procesului de producție și, prin urmare, dacă nu aduc valoare adăugată, ar trebui să fie considerate deșeuri. Testarea automatizată nu ar trebui să fie un scop, ci mai degrabă un mijloc pentru atingerea unui scop, mai exact reducerea defectelor.
Optimizarea întreguluiEdit
Sistemele software moderne nu sunt doar suma părților lor, ci și produsul interacțiunilor lor. Defectele în software tind să se acumuleze în timpul procesului de dezvoltare – prin descompunerea sarcinilor mari în sarcini mai mici și prin standardizarea diferitelor etape de dezvoltare, cauzele profunde ale defectelor ar trebui să fie găsite și eliminate. Cu cât sistemul este mai mare, cu cât mai multe organizații sunt implicate în dezvoltarea sa și cu cât mai multe părți sunt dezvoltate de echipe diferite, cu atât mai mare este importanța de a avea relații bine definite între diferiți furnizori, pentru a produce un sistem cu componente care interacționează fără probleme. Pe parcursul unei perioade mai lungi de dezvoltare, o rețea de subcontractanți mai puternică este mult mai benefică decât optimizarea profitului pe termen scurt, care nu permite relații avantajoase pentru ambele părți.
Gândirea lejeră trebuie să fie bine înțeleasă de toți membrii unui proiect, înainte de a fi implementată într-o situație concretă, din viața reală. „Gândește la scară mare, acționează la scară mică, eșuează rapid; învață rapid” – aceste sloganuri sintetizează importanța înțelegerii domeniului și adecvarea implementării principiilor lean de-a lungul întregului proces de dezvoltare software. Numai atunci când toate principiile lean sunt implementate împreună, combinate cu un puternic „bun simț” în ceea ce privește mediul de lucru, există o bază pentru succesul în dezvoltarea de software.
.