ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 84
Abonament PDF

Cum vindem Scrum?

László Papp
Agile Coach/Scrum Master @ Accenture



MANAGEMENT


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.

Esența dezvoltării software

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.

Livrarea continuă de valoare

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.

Adaptarea la schimbări

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.

Costul amânării (Cost of Delay)

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.

MVP pentru început

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.

Sumarul metodelor

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ă.

Referințe

[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)

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects