7 deșeuri în dezvoltarea software Lean și cum să le preveniți

Gândirea Lean Process prioritizează eradicarea și reducerea generării deșeurilor. În ciuda abordării „lean” adoptate de marile companii, unele practici standard de „deșeuri” persistă datorită „natura lor evidentă”. Natura care este adânc gravată în practicile umane și organizaționale este încăpățânată până când se adoptă o abordare strictă.

Ce este deșeurile?

Orice lucru care necesită resurse/timp sau efort, dar nu dă rezultate relevante în performanță sau venituri este denumit „Risip”.

În cele din urmă, procedura de „reducere a deșeurilor” este concepută și ghidată pentru a crește productivitatea și rezultatele echipei.

Cu toate acestea, acum că dezvoltarea software Lean este strămoșul agilului, putem adopta aceste șapte principii de reducere a deșeurilor în inginerie și dezvoltare software pentru a produce produse și servicii eficiente, reduce costurile și timp mai rapid de lansare pe piață a produsului.

1. Muncă parțial terminată

Dacă lucrarea anterioară nu este repornită niciodată, atunci acel efort a fost risipitor.

Orice lucrare până la finalizare/terminare nu adaugă la propunerea de valoare a clientului; astfel, pierde timp și provoacă menținerea codului dacă este pus în așteptare.

Un exemplu contemporan este atunci când un client necesită modificări sau caracteristici suplimentare pentru un produs. Afacerea se angajează să le finalizeze urgent; echipa de dezvoltare trebuie să oprească activitatea în curs și să acționeze în conformitate cu cerințele. Pe aceeași pagină, dacă lucrarea anterioară nu este repornită niciodată, a fost o risipă de efort.

sau

Documentație necodificată: cerințele sunt detaliate, dar nu sunt niciodată implementate.

Cum să reduc aceste deșeuri?

• Accentul ar trebui să fie pe „terminarea” și nu doar „începerea” unui proiect.
• Reduceți mandatele de lucru în curs.
• Întrerupeți așteptarea specificațiilor detaliate pentru fiecare cerință până când echipa este gata să implementeze eforturile (nu va fi o cauză pierdută atunci).

2. Procese suplimentare

Orice proces adăugat sau documentație necitită care nu transmite valoare practică și prelungește în mod inutil timpul sau realizarea pieței produsului este o risipă.

Cu toate acestea, politicile de afaceri impun adesea astfel de documente, cu documente considerabile, dar niciodată citite. Aceste eforturi sunt extravagante.

Exemple tipice:

• Detalierea inutilă a documentației.
• Management suplimentar sau planificare fără execuție.

Cum să-l reduc?

Organizațiile pot face diferența între ceea ce este o cauză/efort pierdut și ceea ce aduce valoare la masă, accentul ar trebui să fie pe producerea de rezultate semnificative și să canalizeze eforturile de a face mai multă muncă „de calitate” prin limitarea muncii „cantității”.

3. Caracteristici suplimentare

Orice caracteristică sau funcții de valoare redusă care sunt adăugate pentru/de către client, dar care nu sunt solicitate/nu contribuie la creșterea veniturilor este o risipă de efort.

Companiile fac această eroare de dezvoltare atunci când adaugă funcții care nu vor fi foarte utilizate sau exercitate; această nouă caracteristică rămâne într-adevăr inactivă și crește complexitatea aplicației.

Regula Software 80/20 joacă un rol important - 80% dintre utilizatori folosesc doar 20% din funcțiile sale. Prin urmare, accentul ar trebui să se pună pe realizarea acestor 20% caracteristici de top pentru a păstra utilizatorii existenți.

Codurile suplimentare au dezavantajele lor:

• Mărește complexitatea aplicației.
• Poate crea un potențial punct de blocare a aplicației.
• Necesită un efort ulterioară inutil de urmărire și întreținere pe parcursul ciclului de viață al produsului.

Cum să reduc aceste deșeuri?
Concentrați-vă pe dezvoltarea iterativă - ceea ce înseamnă că, în timpul lansării inițiale a produsului, construiți caracteristici primare solide care definesc USP-ul aplicației dvs.

Concentrează-te pe a-l face funcțional și validează învățarea progresului continuu al produsului. Mai mult, continuați să construiți funcții adecvate pe baza analizei pieței, a comportamentului consumatorilor și a feedback-ului.

4. Schimbarea sarcinilor

Atribuirea oamenilor la mai multe sarcini atunci când nu se simt confortabil cu aceasta și le împiedică procesul existent le poate dura o mare parte din zile. Cea mai eficientă modalitate de a termina o anumită sarcină sau două este de a termina una câte una.

În timp ce comutați între sarcini, există un cost de timp mic pentru a închide cea existentă și a obține impuls pentru cealaltă, aceasta se numește comutare de context și, dacă vă așteptați la o tranziție constantă de la una la alta, aceste comutări de conținut se acumulează, ceea ce întârzie „rezultat” sau „timpul de livrare”.

Cum să-l reduc?

Simplu - Un lucru la un moment dat.

• Reduceți schimbarea de conținut.
• Minimizați întreruperile sau distragerile.
• Amână-le pe cele neimportante.
• Alocați resurse ca un proiect la un moment dat.

5. Asteptare/Intarzieri

Dependența de aprobare ar trebui să fie cronometrată în primul rând în timpul foii de parcurs pentru produs; dacă nu este alocat un anumit interval de timp, fiți gata pentru răspunsuri și feedback întârziați. De asemenea, întârzierile împiedică consumatorul să realizeze valoarea reală a produsului. Dar, în calitate de dezvoltatori sau designeri, trebuie să așteptați aprobarea cu privire la munca depusă; astfel, nu puteți evita cu totul intervalul de timp.

Ce poți face pentru a reduce acest lucru?

• Alegeți/alocați ceva în timp ce așteptați feedback-ul existent.
• Alocați timp pentru introducere și revizuire.
• Luați în considerare apelurile rapide, conversațiile față în față, mai degrabă decât trimiterea prin e-mail a modificărilor.
• Feedback regulat.

6. Mișcare

Dacă echipele de dezvoltare sau de cercetare au fost împrăștiate cu informații dobândite și nu le-au marcat/etichetat în mod corespunzător, poate dura o veșnicie pentru a atenua confuzia și prezentarea. Dacă informațiile sunt greșite de fiecare dată când un produs este predat; va împiedica drastic rezultatele.

Cum să-l reduc?

• Etichetați sarcinile sau resursele achiziționate.
• Reduceți timpul de feedback.
• Colaborări față în față.

7. Defect

Cantitatea de deșeuri cauzată de defect = (Impactul defectului) x (Timpul în care trece nedetectat)

Datorită complexității sale, dezvoltarea software-ului produce defecte inevitabile, dar problema apare atunci când acestea sunt prelungite în execuție și fixare sau costurile suportate în impactul fixării sau relucrării. În plus, erorile și erorile majore ale codului pot afecta și împiedica întregul ciclu de viață al produsului și îl pot lăsa vulnerabil la amenințările de securitate, ceea ce duce la pierderi de milioane de venituri.

Ce poți face pentru a reduce acest lucru?

• Testare imediată.
• Integrare constantă.
• Testarea produsului și lansat cât mai curând posibil.