ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 22
Abonament PDF

Metodologia Lean pentru Requirements Engineering

Radu Orghidan
Senior Presales Consultant @ NTT DATA Romania
MANAGEMENT

În prezent, datorită evoluției rapide a tehnologiei și a ușurinței accesului la informație, aproape oricine are posibilitatea de a construi produse sau servicii software pe care să le adreseze pieței globale. Așadar, în ciuda istoriei relativ recente a acestui domeniu, industria software a devenit înfloritoare generând un interes uriaș în domenii de activitate precum dezvoltarea, testarea sau distribuția.

Ingineria specificațiilor, cunoscută sub denumirea de Requirements Engineering (RE) [1,2], este o parte importantă a procesului de dezvoltare de software. S-a demonstrat, atât în literatura [3,4,5] cât și din experiența noastră în ISDC, că erorile rezultate din modelarea imprecisă a proceselor sau neînțelegerea corectă a funcționalității de implementat generează costuri mult mai mici atunci când sunt descoperite în timpul definirii specificațiilor decât atunci când defectele apar în producție. În plus, cea mai mare parte a costurilor unui proiect software este absorbită în faza de mentenanță, aceste costuri fiind influențate în mod direct de calitatea specificațiilor și analizei inițiale.

Directorul de produs (eng. Product Owner - PO) este cel care interacționează cu comunitatea RE și este implicat în procesul aferent pentru a descrie, a documenta și în cele din urmă pentru a construi produsul final cerut de proprii clienți. Pentru un PO comunitatea RE este unul dintre instrumentele folosite pentru a satisface nevoile clienților. Schimbând sistemul de referință, procesul de RE poate fi văzut ca produsul pe care companiile software, prin intermediul echipei de RE, îl oferă clienților lor.

Metodologia Lean a fost introdusă și implementată de Toyota în sistemul propriu de producție. Aceasta se concentrează pe aspectele care produc valoare utilizatorului crescând astfel calitatea produsului obținut, în timp ce durata de dezvoltare și costurile scad.

Eric Ries, în cartea sa "The Lean Startup" [6] definește startupurile ca fiind "instituții umane construite pentru a livra un nou produs sau serviciu în condiții de incertitudine". Un startup implică deci o interacțiune umană ce are loc într-un mod structurat. Similar, specificațiile se obțin folosind tehnici de investigație bine definite precum interviurile, sesiunile de workshop, observarea, construirea de prototipuri etc.. A doua parte a definiției pune accentul pe faptul că startup-urile livrează un produs sau serviciu fără să știe cu certitudine cum se va adapta acesta la nevoile utilizatorilor finali. Iată din nou o similitudine cu activitatea comunității RE care trebuie să dezvolte o serie de cerințe [7,8,9] ce vor trebui să se adapteze nevoilor clientului în timp ce descriu un nou produs cât mai precis posibil. Pornind de la observația că departamentul de RE al unei companii producătoare de software poate fi asimilat cu ușurința unui startup, vom analiza ideea extrapolării principiilor Lean dezvoltate pentru startup-uri și pentru activitatea de RE.

Obiectivul acestui articol este de a prezenta o nouă paradigmă a procesului de RE: În primul rând, activitatea de RE va fi prezentată precum un produs vândut companiilor care investesc în dezvoltarea de produse software; în al doilea rând, vom arăta cum metodologia Lean poate fi aplicată activității de RE. Ca o observație interesantă, metodologia Lean poate fi simultan aplicată ambelor părți implicate în activitatea de RE: clientul o poate folosi pentru a defini activitățile pe care startup-ul trebuie să le desfășoare pentru a construi un produs de succes în timp ce echipa de RE poate aplica metodologia Lean pentru a defini procesul necesar definirii specificațiilor necesare pentru obținerea unui produs software cu funcționalitatea dorită.

Învață, Măsoară, Construiește

Produsele software pot fi dezvoltate folosind diverse metodologii precum: waterfall, iterative sau agile. Independent de soluția aleasă, activitatea de RE este un pas obligatoriu care precedă dezvoltarea de software. În mod obișnuit, faza de RE este urmată de dezvoltare și apoi de lansarea în producție. Așadar, perioada de învățare a unei companii ce lansează un produs nou este împărțită între faza de RE și cea de intrare în producție, cu pondere majoritară după ce produsul începe să fie folosit de clienții finali.

Figura 1 descrie un flux tipic de producție care începe cu construirea specificațiilor urmată de dezvoltare și asigurarea calității produsului terminând cu lansarea produsului.

Figura 1. Perioada de învățare a unei companii ce lansează un produs nou începe în etapa de RE și se finalizează după ce produsul începe să fie folosit de clienții finali.

În timpul primei etape, trebuie să trecem printr-un proces de învățare pentru a adapta cerințele clientului la domeniul de activitate și la constrângerile de ordin tehnic. Cu toate acestea, în faza inițială există foarte puține date despre impactul produsului asupra utilizatorilor finali, despre cum va fi primit și înțeles de piață. Atunci când produsele dezvoltate includ o componentă de inovare importantă este foarte dificil să se anticipeze reacția clienților. În timp ce în cele două etape ce succed procesul de RE efortul principal se concentrează pe dezvoltarea propriu zisă, partea cea mai importantă a procesului de învățare este "recoltată" după lansarea produsului.

Metodologia Lean inversează procesul industrial de producție format din secvența "Construiește, Măsoară, Învață". În loc de aceasta, teoria Lean susține ideea creării unui "Produs Minimum Viabil" care se folosește pentru a învăța ce doresc utilizatorii finali cu adevărat și, prin urmare, permite dezvoltarea unui produs adaptat nevoilor reale ale clienților, după cum este ilustrat în Figura 2.

Figura 2. Crearea unui Produs Minimum Viabil permite comunității RE să îndeplinească nevoile reale ale clienților. Imagine preluată de pe site-ul Lean Entrepreneur (http://LeanEntrepreneur.com/)

Dacă ne concentrăm pe stadiul de RE și continuăm analogia dintre comunitatea RE și un startup, în ISDC am încercat să înțelegem cum să aplicăm metodologia Lean în cadrul unui proces intern de RE. În mod tradițional, procesul de RE cuprinde următorii pași principali: planificarea, obținerea și analizarea cerințelor, dezvoltarea specificațiilor, managementul specificațiilor, transmiterea și auditarea specificațiilor. Așa cum se arată în Figura 3, acest proces urmărește fluxul Construiește, Măsoară, Învață.

Figura 3. Procesul folosit în cadrul comunității RE din ISDC

Pentru a adapta acest proces metodologiei Lean, RE trebuie să dezvolte specificațiile în iterații scurte și să valideze continuu rezultatele cu clientul. Scrierea specificațiilor trebuie să fie o prioritate deoarece aportă informații valoroase echipei de dezvoltare a produsului atât din punct de vedere funcțional cât și din perspectiva înțelegerii modului de lucru al clientului, ale valorilor acestuia și ale așteptărilor pe care le are de la RE.

Prin aplicarea metodologiei Lean, se încearcă acumularea câtor mai multe cunoștințe în fazele incipiente ale procesului de RE. Steve Jobs spunea: "nu este treaba clientului să știe ce vrea". La fel, și comunitatea de RE trebuie să poată să obțină informația corectă creând un Produs de Specificații cu Valoare Minimă (PSVM) și măsurând feedback-ul clientului. Încercarea de a identifica un concept și de a-l valida prin experimente empirice este cunoscut în metodologia Lean ca "învățare validată" (eng., validated learning). Din experiența noastră, lipsa informațiilor de învățare validată duc la frustrări de ambele părți și la întârzieri în dezvoltarea produsului.

Unealta Lean Canvas

Unealta "Lean canvas", oferită de Lean Stack [10], este deosebit de utilă în analiza și construirea unui startup. Prin urmare, Lean canvas poate fi folosit de asemenea de către comunitatea RE.

Considerând "Produsul" și "Piața" ca fiind principalii piloni în jurul cărora se construiește un startup, următoarele aspecte trebuie luate in considerare:

  • Produs
    • Problema: Identificarea problemelor de rezolvat pentru client,
    • Soluția: Identificarea soluției și validarea experimentală,
    • Metricile: Modalitățile de măsurare a succesului
    • Costurile: Identificarea costurilor fixe și variabile.
  • Piața
    • Segmentele de clienți și pionierii: trebuie să se facă o distincție între clienți și utilizatori.Pionierii sunt acele persoane care vor folosi produsul încă de la lansarea acestuia sau chiar dinaintea lansării.
    • Oferta unică: definirea unei oferte unice sau a unui PSVM.
    • Canale: definirea canalelor pentru a ajunge la client.
    • Surse de venit: dacă este posibil, identificarea surselor de monetizare a afacerii.

Unul dintre pașii cei mai importanți în construirea unui startup este identificarea clientului final. În procesul de RE din ISDC, aceasta este echivalentă cu identificarea părților interesate care sunt responsabile cu dezvoltarea produsului. Pentru a identifica persoanele potrivite, analiza trebuie să considere numărul potrivit de candidați. Pe de o parte, nu va trebui să includă un cerc prea extins deoarece acesta va duce la un set de reguli dificil de controlat. Totuși, grupul nu trebuie să fie prea restrâns deoarece segmentul țintă se va micșora ceea ce va duce la pierderea din vedere a opiniilor unor clienți importanți.

Odată ce se stabilesc persoanele responsabile de proiect, cel mai important segment dintre aceștia va trebui să fie identificat. Acesta poate include clienții care au o conexiune cu comunitatea de RE - de exemplu, sunt mai ușor de atins sau pot comunica mai bine. În această fază, este foarte important să fie realizată distincția între clienți și utilizatori: clienții plătesc în timp ce utilizatorii nu. Grupul celor care folosesc primii produsul este format în acele persoane care au cea mai mare nevoie de produs. Acest grup este foarte important deoarece furnizează informații despre cele mai valoroase caracteristici ale produsului chiar și înainte de lansarea acestuia.

Ca și în orice startup, comunitatea RE din ISDC trebuie să poată identifica problemele de rezolvat pentru client. O lecție învățată din proiectele noastre este aceea de a identifica cele mai importante trei probleme ale utilizatorilor folosind analiza cauzală bazată pe cinci întrebări. Este de asemenea foarte interesant de analizat soluțiile pe care clienții le folosesc în momentul construirii produsului pentru a-l substitui. Se pot identifica astfel alternative pentru a îmbunătăți situația existentă. Produsul sau serviciul oferit de RE nu trebuie să fie perfect însă trebuie să fie o îmbunătățire clară a alternativelor existente. De exemplu, în comunitatea noastră, aducem experți în domeniile abordate. Acest lucru ne permite să oferim clientului o privire mai proaspătă și obiectivă comparativ cu ceea ce s-ar obține folosind experții interni ai clientului.

Un alt aspect care trebuie evaluat când se definește o soluție pentru problemele clientului este să se înțeleagă ce anume înlocuiește produsul. Orice produs înlocuiește ceva și echipele noastre de pre-sales și RE au misiunea de a clarifica motivația clientului de a-și asuma riscul prin adoptarea produsului propus. Suntem deosebit de atenți cu aceste aspecte deoarece serviciile oferite clienților noștri vor înlocui probabil unele sarcini realizate de echipe interne sau, în unele cazuri, vor înlocui chiar echipe întregi.

PSVM, adică soluția ce implică cel mai mic efort de dezvoltare care oferă valoare utilizatorului, trebuie să fie definită. Soluția poate să nu fie unică, iar clientul are în general mai multe propuneri, incluzându-le bineînțeles și pe cele ale concurenței. Pentru a atrage atenția clientului ne concentrăm pe a defini o propunere unică. Aceasta trebuie să se poziționeze la intersecția principalei probleme a utilizatorului și soluția propusă de noi. Pentru a avea un impact maxim, propunerea trebuie să fie enunțată cu claritate și să includă descrierea rezultatului livrat utilizatorului, să fie încadrată în timp și să anticipeze potențialele obiecții. De exemplu, o propunere poate să aibă următorul conținut: "Specificații definite cu claritate, livrate în x zile lucrătoare și cu garanția unei soluții fără defecte". Bariera de intrare este un factor intrinsec al companiei sau a soluției propuse, precum brand-ul, experiența în domeniu, dimensiunea sau componenta echipei, nișa de specializare etc.. Acești factori nu pot fi copiați sau cumpărați cu ușurință și pot fi folosiți pentru a întări propunerea noastră. Este de asemenea util de pregătit o metaforă care să ofere clienților mai puțin familiarizați cu termeni tehnici, o imagine clară a serviciilor RE oferite și a caracteristicilor acestora.

Dacă este necesar, se vor defini canalele prin care se poate ajunge la client. În general, se poate începe cu câteva canale și altele vor apărea în mod natural, pe parcurs.

Definirea metricilor de succes este esențială pentru proiectele noastre. Pentru a construi metrici corecte, comunitatea RE identifică ce anume clientul percepe și valorează ca succes. Costurile fixe și variabile sunt de asemenea evaluate pe baza acestor metrici pentru a le putea stabili ordinea de prioritate în mod corect.

Concluzii

Acest articol s-a concentrat pe serviciile RE în contextul oferit de compania noastră. În ISDC, vedem activitatea de RE atât ca un produs în sine cât și ca o activitate antreprenorială. Această viziune a dus la ideea adaptării principiilor Lean activității de RE pentru a îmbunătăți procesul existent. Metodologia Lean se concentrează pe acele activități care produc valoare clientului ducând în același timp la reducerea duratei ciclului de dezvoltare și a costurilor precum și la creșterea calității produsului. Una dintre conceptele cheie ale Lean este MVP (Minimum Viable Product) care reprezintă soluția cu un efort minim de implementare și care totodată oferă valoare clientului. Arătăm, prin analogie, că și specificațiile pot fi elaborate ca un PSVM (Produs de Specificații cu Valoare Minimă).

Alte contribuții ale metodologiei Lean folosite în procesul comunității RE din ISDC sunt conceptele de "Învățare validată" (eng. Validated Learning) și ideea inversării procesului tradițional de construire a documentelor de specificații și transformarea fluxului în secvența "Învață, Măsoară, Construiește". Dezvoltarea specificațiilor în pași mici și validarea rezultatelor cu clienții sunt cruciale. Respectând aceste principii comunitatea RE acumulează cunoștințe importante atât din punct de vedere funcțional cât și în ceea ce privește modul de lucru al clientului și așteptările acestuia în urma procesului de dezvoltare al specificațiilor.

Bibliografie

"Requirements Engineering in an Agile Environment", Yunyun Zhu, Department of Information Technology, Uppsala University, 2009

"Best Practices for Requirements Gathering", Michael Krasowski, Online course at http://pluralsight.com/

"Dependency based Process Model for Impact Analysis: A Requirement Engineering Perspective", Chetna Gupta, Yogesh Singh, Durg Singh Chauhan, International Journal of Computer Applications (0975 - 8887), Volume 6- No.6, September 2010.

"Impact Analysis of Goal-Oriented Requirements in Web Engineering", Jose Alfonso Aguilar, Irene Garrigos, Jose-Norberto Mazon, The 11th International Conference on Computational Science and Its Applications (ICCSA 2011).

"Requirements Engineering", Elizabeth Hull, Ken Jackson, Jeremy Dick, Springer, 5 oct. 2010.

"The Lean Startup: How Today"s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses", Eric Ries, Crown Business (September 13, 2011), ISBN-10: 0307887898, ISBN-13: 978-0307887894

LANSAREA NUMĂRULUI 86

Prezentări articole și
Panel: Autonomous driving

Marți, 20 August, ora 18:00
Bosch R&D, Cluj-Napoca

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects