Dacă sunteți membru al unei echipei scrum, cu siguranță cuvântul "produs" vă pare cunoscut. Ce este mai precis un produs și cum este legat de procesul de dezvoltare agilă? Un produs software este un set de fișiere executate de computer, grupate împreună pentru a construi un singur program folosind resursele Hardware si de a efectua operațiuni specifice. Un produs Software este utilizabil de către părțile interesate, comercializabil, urmăribil prin licență și numărabil. Bine cunoscutul "SaaP" (Software-ul ca produs) este un produs dezvoltat pentru a fi vândut utilizatorilor cu rolul de a satisface nevoile de tip informatic. Câteva exemple de "SaaP": Microsoft Office, Google Docs, Slack, etc.
"Produsul" este un termen bine cunoscut în procesele Agile. Există roluri definite pentru a avea responsabilitate în a defini produsul ca pachete mici, care împreună, în cele din urmă livrează Software-ul ca produs. Un astfel de rol în Scrum este proprietarul de produs („Product Owner”), care este membru al echipei responsabile de colaborarea dintre echipa de dezvoltare și părțile interesate / clienți.
Când vorbim despre dezvoltarea produselor, ne referim la proiecte. Un produs software constă într-unul sau mai multe proiecte, care reprezintă de fapt procese administrative în crearea produsului.
De la prototipuri la vânzare de produs, există diferite etape care trebuie executate și fac parte din ciclul de viață al produsului. Fazele din ciclul de viață al produsului sunt cadre de timp, denumite în managementul de proiect "Milestone-uri". Un "milestone" este un eveniment programat care indică finalizarea evenimentului livrării unui proiect major.
"Milestone-urile" din PM sunt utilizate pentru a indica fazele proiectului:
Începutul fazei semnificative de lucru;
Sfârșitul unei faze de lucru semnificative;
Să indice termenele limită;
Utilizarea etapelor de planificare reprezintă o provocare pentru metodologiile Agile. Pentru ca procesele Agile să funcționeze, trebuie făcută o nouă adaptare la vechea abordare a "modelului V". Managerul de proiect cu echipa de dezvoltare, clarifică nevoile proiectului și pe baza expertizei lor, estimează funcționalitatea necesară care trebuie pusă în aplicare, rezultând în stabilirea reperelor pentru versiuni importante. Există, de asemenea, cazuri în care se recomandă să nu se schimbe obiectivele de referință precum conferințele în care este prezentat produsul.
În acest caz, membrii echipei stabilesc gradele de importanță ale articolelor de lucru și estimează doar caracteristicile necesare pentru eveniment.
În marile corporații, unde produsele sunt mari și de obicei au versiuni mai vechi, care au fost reînnoite, "modelul V" este abordarea cea mai adoptată de către conducerea superioară.
Există trei întrebări principale care trebuie rezolvate prin orice proces: "De ce?", "Ce?" și "Cum?". De ce dezvoltăm produsul? Ce ar trebui să facă produsul? Cum ar trebui să livrăm funcționalitatea? Toate răspunsurile trebuie integrate în procesul de dezvoltare, iterativ și măsurabil. ( În cazul nostru "V-model").
De obicei, primul "Milestone", care poate fi numit diferit de la companie la companie, să zicem "Milestone" M1 în exemplul nostru, este prototipul. Pentru a reduce riscurile și eșecurile, este necesar un "Milestone" mai scurt pentru a solicita și a obține în timp util răspunsul și aprobarea clientului pentru a continua. În mod obișnuit, în această fază incipientă, fie definim viziunea, obiectivele, elaborăm trasee și ținem contactul cu departamentul de vânzări, fie în cazul "SaaP", pe baza experienței dezvoltatorilor, se dezvoltă un prototip funcțional.
"Milestone" M2 constă în:
Elaborarea cerințelor clienților;
Identificarea normelor și reglementărilor;
"Milestone" M3:
Definirea cerințelor disciplinei;
Elaborarea arhitecturii disciplinei;
Definirea cerințelor de livrare a disciplinei;
Dezvoltarea articolelor de lucru;
Unit test;
Integrarea subsistemelor;
"Milestone" M4:
Verificarea cerințelor subsistemului;
Validarea produsului;
Certificarea produsului;
"Milestone-ul" M4 din exemplul nostru este destinat vânzării produsului, în timp ce ultimele M5 și M6 sunt destinate comercializării și închiderii. Închiderea este ultima fază din ciclul de viață al produsului când acesta este scos din uz.
După cum se poate observa, există o diferență de concept între "modelul V" și abordarea agilă datorită dezvoltării incrementale care este pusă în scenă și se consideră a fi o strategie de programare.
În concluzie, când ne referim la Software ca produs ("SaaP"), avem în plan existența unuia sau mai multor proiecte pentru a atinge obiectivele produsului. Pentru a prezice lansările de produs, "modelul V" poate fi mapat eficient într-un sistem "Milestone" și poate adopta o dezvoltare progresivă.
de Ovidiu Mățan
