În continuarea articolului „De la estimări relative la buget și un plan”.
Ca estimarea să fie pertinentă, câteva elemente trebuie clarificate. În primul rând, este necesar să înțelegem cu toții același lucru înainte să ne jucăm cu cifrele. Când vorbim despre o cerință estimată, răspundem la întrebarea:
- când va fi gata? (ciclul de terminare al cerinței) sau
- care este efortul pe care-l vom consuma? (efortul de terminare al cerinței)
O cerință poate fi simplă de implementat dar să necesite un efort mare, sau poate fi foarte complexă și să necesite un efort mic. Așa cum spuneam mai devreme, noi avem nevoie de efort, nu de complexitate chiar dacă deseori efortul poate fi influențat de complexitate.
Cu alte cuvinte, putem spune că cerința Y va fi terminată în 2 zile cu un efort de 1.5 zile. Diferența constând în puterea de concentrare (pauze, diferite evenimente, etc.), în proces ș.a.m.d.
Alte două chestiuni pe care trebuie neapărat să le clarificăm înaintea începerii estimărilor sunt
- identificarea soluției (infrastructură, arhitectură, tehnologii, etc) și
- definirea metamorfozei cerințelor în increment (folosim TDD, testăm pe X navigatoare și Y platforme, etc.)
Diferența de efort poate fi destul de mare între implementarea unui site e-commerce cu Magento și o nouă dezvoltare bazată pe tehnologii Java-web. La fel de mari pot fi și diferențele de efort în funcție de tehnicile pe care le practicăm și etapele prin care trecem de-a lungul incrementării cerințelor în produs. Acesta poate fi unul din motivele pentru care ne-am dori să avem pe proiect ceea ce se numește definiția unei cerințe finalizate (Definition of Done for a feature). Mai jos găsiți exemplul unei astfel de definiții:
- Codul scris utilizând TDD (testele sunt scrise și trec) compilează în local și este revizuit în urma analizei statice de cod
- Toate cazurile de test asociate cerinței trec cu succes
- Codul este împins pe serverul de surse
- Build-ul a fost creat cu succes pe platforma de integrare continuă
- Criteriile de analiză statică de cod trec și pe platforma de integrare continuă
- Codul este revizuit (sau s-a programat în pereche)
- Testare manuală pe platforma X și navigatorul Y
- Feedback rapid de la responsabilul de produs înainte de demo
- Tabloul de vizibilitate este adus la zi
Această definiție este tot un obiect de hotar între responsabilul de produs și echipa de dezvoltare, așteptările celui dintâi putând fi diferite comparativ cu ceea ce se gândea echipa să facă și să livreze. De exemplu, responsabilul de produs vrea ca aplicația să meargă pe toate navigatoarele utilizate în mod curent indiferent de versiunile lor. Însă echipa de dezvoltare ar consuma foarte multă energie testându-le, ceea ce duce la negociere. Prezența definiției unei cerințe finalizate este benefică din motivele următoare:
- asigură că întreaga echipă înțelege același lucru înainte de a considera orice cerință finalizată,
- crește transparența,
- aduce argumente în negocierile dintre dezvoltatori și responsabilul de produs sau între membrii echipei,
- poate preveni derapajele grave între vânzări și ceea ce se produce efectiv.
Această definiție este creată și menținută la zi de întreaga echipă de dezvoltare.
Definiția unei cerințe finalizate.
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 2736 ori