Adoptarea Scrum în proiecte software se mai poate dovedi ca o tentativă dificilă în anumite industrii, în care de mai multe decenii gestionarea proiectelor se bazează pe metodologii tradiționale. Acest articol descrie strategia noastră de prezentare a avantajelor Scrum, cum ar fi dezvoltarea iterativă și incrementală a unui software, livrarea continuă de valoare, adaptarea la schimbări și prioritizarea, pentru a convinge clienți din diverse industrii de manufacturing să folosim această abordare.
Cu ocazia primelor întâlniri, cei mai mulți dintre clienții se folosesc de analogii inginerești pentru a descrie ceea ce cred ei că este un software. Una dintre cele mai frecvent utilizate analogii în industria de manufacturing este că un software este similar unei case și dezvoltarea software este similară cu construirea unei case pe baza unui plan (blueprint); odată ce acest plan a fost întocmit nu mai e necesară colaborarea dintre client și executant. Această concluzie rămâne să fie confirmată de constructori, dar așa cum s-a evidențiat de multe ori de-a lungul timpului, asemănarea unui software cu bunuri tangibile, respectiv a dezvoltării software cu o linie de producție destinată fabricării acelor bunuri nu este potrivită. Software-ul trebuie comparat cu ceva intangibil, cum ar fi o simfonie sau un film, unde oamenii interpretează muzică după o partitură sau joacă roluri dintr-un scenariu. Software-ul este despre oameni și este produsul intelectual al colaborării lor. Așa cum o carte sau un scenariu poate fi sursa a nenumărate adaptări cinematografice și așa cum partitura unei simfonii poate fi interpretată în multe feluri de către diverse orchestre (nu neapărat pentru mine, ci pentru cei care au ureche muzicală), aceleași idei și cerințe vor rezulta în sisteme software foarte diferite, în funcție de cum colaborează părțile implicate. Un software va îndeplini într-o măsură mai mare nevoile clienților, atunci când aceștia contribuie în mod activ la proiect decât atunci când nu se implică.
Produsele în masă sunt obținute printr-un proces repetabil; dezvoltarea software nu este un proces repetabil, e mai mult o călătorie și ar trebui să fie evoluționară. Când se construiește o casă, este gata o singură dată. Când se dezvoltă un software, acesta poate fi gata în mai multe stadii, fiecare stadiu oferind valoare adițională clientului și utilizatorului final. Dacă vrem să adaptăm analogia casei, în fiecare stadiu software-ul este o clădire nouă, evoluând de la cabană la castel.
Una dintre caracteristicile cheie ale fiecărui proiect software este incertitudinea rezultatelor.
În momentul inițierii proiectului, dar și mai târziu, este imposibilă garantarea succesului la finalul proiectului. Având în vedere această incertitudine, este important ca livrarea rezultatelor să fie începută cât mai devreme posibil după demararea proiectului.
Fiind un proces iterativ bazat pe prioritizare și cicluri scurte de dezvoltare, Scrum are ca scop principal să livreze permanent valoarea maxim posibilă într-un interval de timp minim.
Cu metodologia tradițională Waterfall nu se livrează valoare până în etapele târzii ale proiectului:
Proiectele Scrum oferă valoare pe tot parcursul proiectului:
În plus, valoarea livrată poate proveni și din schimbările cerute de către client de-a lungul iterațiilor.
Spre deosebire de gestionarea tradițională a proiectelor, Scrum nu necesită toate cerințele în avans, ci promovează luarea deciziilor în mod iterativ și cât mai târziu posibil, adică atunci când prioritățile o cer și informațiile avute la dispoziție o permit. Prin urmare clienții pot schimba cerințele sau chiar identifica nevoi sau oportunități de afaceri pe parcursul proiectului. De aceea, în caz optim, valoarea efectiv livrată va depăși valoarea prevăzută la inițierea proiectului. Clienții chiar pot opri proiectul după oricare sprint, cu condiția ca acest lucru să fie permis în contract, dacă își dau seama că produsul sau serviciul livrat satisface deja așteptările lor.
Dacă clienții sunt întrebați care sunt funcționalitățile (features) care vor furniza valoarea cea mai ridicată, răspunsul cel mai des primit este că ,,toate". Ei consideră, și pe bună dreptate, că software-ul pe care-l vor primi la sfârșitul proiectului va trebui să acopere toate funcționalitățile de care ei au nevoie. În această situație este bine să întrebăm care funcționalități vor implica cel mai ridicat cost atâta timp cât livrarea lor este amânată, determinând astfel clienții să se gândească la banii pierduți în perioada în care funcționalitățile vor lipsi din mediul de producție. Acest cost al amânării se poate obține folosind valoarea funcționalităților și durata lor de livrare. În plus, pe baza acestora putem calcula așa numita metrică CD3 (Cost of Delay Divided by Duration) pe care o putem folosi la prioritizare.
Valoarea realizată printr-o funcționalitate după livrarea acesteia se poate exprima pe o anumită perioadă de timp, de exemplu o săptămână, în diverse feluri, cum ar fi venitul adițional, economia de costuri sau costul evitat. O funcționalitate simplă în manufacturing este ca operatorii să vadă comenzile de producție cu alertă în topul listei comenzilor, astfel încât să poată reacționa rapid la lipsuri și defecțiuni. Costurile astfel reduse sau evitate, de ex. costurile aferente timpului de inactivitate, pot fi cuantificate și utilizate ca valoare realizată prin această funcționalitate pentru calculul CD3. Durata de livrare a unei funcționalități se măsoară în sprinturi, care se raportează la timp de regulă în săptămâni.
Derek Huether descrie în detaliu diferite scenarii privind prioritizarea funcționalităților în [1] și arată că CD3 este cel mai eficient. Pentru exemplificare, să considerăm funcționalitățile din tabelul de mai jos:
Primul scenariu este acela de a nu prioritiza funcționalitățile deloc și de a le implementa simultan. Acesta este cazul metodologiei Waterfall deoarece toate cele trei funcționalități vor fi livrate deodată, după 48 de săptămâni. Clientul va pierde 92 dolari săptămânal, costul amânării fiind în total \$ 4,416 (92 x 48).
În cel de-al doilea scenariu, funcționalitățile sunt prioritizate exclusiv după valoarea furnizată, astfel încât acestea vor fi livrate în următoarea ordine: C, B, A. O funcționalitate va implica costul amânării până când aceasta și toate funcționalitățile cu valoare mai mare vor fi livrate. Costul total al amânării este de \$3,336, calculat după cum urmează:
În cel de-al treilea și ultimul scenariu considerat în acest articol, prioritizarea se face folosind CD3. Ordinea în acest caz este B, A, C, iar costul total al amânării este de \$2,976:
Următorul tabel prezintă costurile de amânare pentru cele trei scenarii analizate:
În concluzie, în acest caz metodologia Waterfall oferă rezultatele cele mai nefavorabile, dar s-ar putea să nu fie o decizie economică optimă nici ca cea mai valoroasă funcționalitate să fie livrată prima. Cu toate că prezentarea costului amânării este o modalitate puternică de a demonstra importanța ordinii de implementare a funcționalităților în cadrul unor proiecte lungi și complexe, acesta este doar unul dintre factorii care trebuie considerați la prioritizarea funcționalităților pentru livrare și nicidecum nu este menit să diminueze avantajele abordării Waterfall în cazul proiectelor mai mici cu cerințe statice și foarte bine înțelese.
Un MVP (Minimum Viable Product) este un produs cu un set minim de funcționalități esențiale și are ca scop îndeplinirea cel puțin parțială a celor mai importante nevoi ale unor utilizatori dintr-un grup țintă, aceștia urmând să ofere feedback pentru dezvoltarea ulterioară a produsului. Un MVP este funcțional, nu este nici prototip și nici versiune beta a unui produs. Costă mult mai puțin decât produsul final și se implementează într-un timp relativ redus, de obicei o lună sau două. În contextul nostru, un MVP este menit să ilustreze clienților modul de lucru Scrum și să-i convingă de beneficiile acestuia, oferindu-le totodată valoare. Rămânând la analogia cu casa, iată cum arată un MVP în raport cu produsul final:
Un MVP este prima versiune livrată, "cabana", la care se vor adăuga toate funcționalitățile ulterioare.
Pentru a convinge clienții să folosim Scrum în așa fel încât ei să rămână implicați pe tot parcursul procesului de dezvoltare, am pregătit o serie de metode specifice pe care le putem aplica în diferite situații. Adaptarea prin storytelling a unei analogii răspândite pare să fie o abordare mai bună pentru a elimina preconcepții eronate legate de software decât, de exemplu, compararea procesului empiric utilizat in Scrum cu procesul definit utilizat în Waterfall.
Clienții vor să vadă rezultate rapid, iar aici prinde bine prezentarea livrării continue de valoare. Faptele și cifrele transmise de costul amânării ajută la accelerarea semnificativă a prioritizării funcționalităților. Nu în ultimul rând, un posibil tratament pentru reticența cronică a clienților este implementarea și livrarea la timp a unui MVP cu funcționalitatea potrivită.
[1] Huether, D. Prioritizing to Minimize Cost of Delay (2015)
[2] Leung, C. H. MVP: Images Explained (2016)
[3] Kovalchuk, O. What is Minimum Viable Product And How To Make It Right (2018)
de Edwin Hobor
de Ovidiu Mățan
