În continuarea articolului „Dezvoltarea în flux continuu”.
Să spunem că avem un proiect în care ne stabilim ca bază ideală de lucru următoarea metamorfoză a specificațiilor:
- Utilizatorii finali fac sugestii responsabilului de produs.
- Acestea sunt asumate sau refuzate. Cele refuzate nu ne mai interesează.
- Sugestiile asumate trebuie rafinate.
- Odată conforme cu criteriile INVEST, ele sunt analizate de echipă, estimate și planificate, devenind astfel pregătite.
- Cerințele pregătite sunt incrementate până când sunt considerate finalizate și gata pentru inspecție.
- Responsabilul de produs le validează și solicită utilizatorilor finali să accepte munca dezvoltatorilor, testând într-un mediu sigur de pre-producție.
- Munca acceptată este livrată în producție.
Cele spuse mai sus sunt conforme cu principiile dezvoltării într-un flux continuu:
Cu scopul evitării risipei, în procesul nostru nu ar trebui să intre sugestii pe care nu le putem transforma în funcționalități utile și n-ar trebui să livrăm mai mult decât ar putea utilizatorii să accepte și să folosească:
Utilizatorii pot fi disponibili o săptămână pe lună pentru acceptanță (5 zile). O cerință are în medie o mărime estimată de 3 puncte relative,iar acceptarea unei cerințe de o asemenea talie ocupă o zi întreagă pentru cei doi utilizatori disponibili. Această ipoteză ne duce cu gândul la a nu produce mai mult de 15 puncte relative pe lună (5 zile X 3 puncte relative). Sesizăm diferența de abordare față de modul de lucru tradițional?
Când toate cerințele din etapa „Acceptanță” au trecut în coloana „De livrat”, primul dezvoltator disponibil livrează incrementul în producție.
Când mărimea cerințelor din coloana „De acceptat” ajunge la 15 puncte relative, responsabilul de produs, solicită utilizatorii să înceapă acceptanța. În cazul identificării unui defect, aceștia se adresează direct echipei de dezvoltare, care se oprește din muncă, corectează și se asigură că reduce sau elimină complet șansele ca un astfel de defect să se mai reproducă.
Echipa este obișnuită să lucreze în iterații de câte două săptămâni, având o viteză constantă de aproape 8 puncte relative. N-are niciun sens să se accepte mai multă muncă în iterație.
Când echipei nu-i mai rămâne nicio cerință de realizat (0 puncte relative), adică toate au trecut în etapa „Gata pentru inspecție”, fiind conforme cu definiția unei cerințe finalizate, i se demonstrează responsabilului de produs rezultatul muncii. Responsabilul de produs invalidează anumite cerințe sau le trece în „De acceptat”. Discută cu echipa de dezvoltare referitor la ce poate fi adaptat pentru următoarea iterație și se trece la cerințele din „De planificat”, unde echipa :
- analizează cerințele,
- le estimează în puncte relative,
- le împarte în sarcini de lucru (tasks) și
- trece în etapa „De făcut” cerințele considerate pregătite.
Când în etapa „Sugesii asumate” mai rămân cel mult două sugestii, responsabilul de produs organizează un atelier cu utilizatorii finali, solicitându-le astfel noi idei pe care le va asuma.
Regulile date mai sus, pot fi făcute vizibile astfel:
Rezultatul se numește limitarea cantității de muncă cu scopul optimizării debitului optimal. Noi abia am început, și n-am făcut decât să reprezentăm ipotezele noastre. În următoarele articole vom discuta și despre cum și în ce condiții putem reveni asupra acestor reguli.
Un exemplu de dezvoltare în flux continuu
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 3170 ori