În cazul în care dezvoltatorul vede un defect în dorințele clientului, ar trebui să indice cât mai politicos posibil acest lucru și să încerce să discute cu clientul acest defect.
Asociat cu punerea în aplicare a dorințelor clientului, dezvoltatorul trebuie să înțeleagă ceea ce clientul dorește să evalueze cu exactitate a muncii. În cazul în care dezvoltatorul este dificil de a da o estimare exactă, el ar trebui să evalueze efortul, cel puțin aproximativ, și de a cere clientului să-i dea mai mult timp, timp în care el a explorat în detaliu problema și pentru a genera o estimare corectă.
Clientul este unul dintre cele mai importante roluri din echipă. Fiecare client are puncte forte și puncte slabe. Unii clienți descriu dorințele cu o cantitate excesivă de detalii. Alții formulează foarte mult dorințele, oferind detaliat elaborarea dezvoltatorului. Uneori, dezvoltatorul este familiarizat cu zona subiectului într-o măsură mai mare decât clientul. În unele cazuri, clientul reprezintă interesele anumitor utilizatori finali ai produsului software, în alte cazuri, utilizatorul final este o entitate pur ipotetică.
Un client bun ar trebui:
• cunoașteți temeinic domeniul de activitate pentru care se dezvoltă produsul software;
• Înțelegeți ce avantaje va oferi produsul software în această arie de subiect;
• să colaboreze la crearea constantă a unor rezultate intermediare mici, în care se realizează puține funcții noi;
• să ia decizii cu privire la care funcții ar trebui implementate mai întâi;
• nu anulați livrarea unui produs software;
• aveți încredere în estimările efortului depus de dezvoltatori, în ciuda faptului că acestea din urmă pot fi confundate;
• să poată asuma principala responsabilitate pentru succesul sau eșecul proiectului;
Procesul flexibil de planificare tehnologie captată în mod deliberat pentru cele două părți - client și dezvoltator (echipa de dezvoltare). De fapt, partea abstractă a clientului poate fi jucat de mai multe persoane. Acestea includ utilizatorii finali pentru a dezvolta un produs software, naratorul (membrii echipei, formularea cerințelor folosind povești de utilizator (Story utilizator)), acceptori (povestitori sau persoane care acționează în numele acestora, care efectuează teste de recepție), finanțe (furnizează resurse pentru proiect) planificatorii (până versiuni de sisteme de programul de lansare a stabilit gradul de realizare a funcționalității produsului, determină necesitatea lansarea unei noi versiuni).
5.2. Planificarea versiunii Pentru fiecare versiune a produsului software, clientul selectează o listă de dorințe care trebuie implementată în versiunea publicată oficial a produsului.
Planificarea versiunii este formată din trei faze:
• explorare - în acest stadiu este necesar să se determine ce ar trebui să facă produsul software;
• confirmare - în acest stadiu este necesar să se decidă ce subset de cerințe ale clienților să fie îndeplinite în următoarea versiune a produsului software;
• management - în acest stadiu este necesar să se gestioneze procesul de dezvoltare, pe măsură ce realitatea face ajustările planului.
Etapele sunt modificate ciclic.
Versiunea este de obicei făcută o dată pentru câteva luni. Dacă lansați versiuni mai des, acestea vor diferi puțin unul de celălalt. Dacă eliberați versiuni mai rar, puteți rămâne în urma concurenților.
Etapa de cercetare Etapa de cercetare include următoarele acțiuni:
• Scrierea dorințelor (User Story) de către client;
• evaluarea dorințelor dezvoltatorului;
• Separarea dorințelor de către client.
Evaluarea dorințelor dezvoltatorului După ce au fost compilate dorințele, dezvoltatorii trebuie să evalueze efortul necesar implementării fiecărei dorințe și să le înregistreze folosind unități speciale în colțul din dreapta sus al cartelei. Un exemplu de card cu o dorință și o estimare estimată a costurilor forței de muncă este prezentată în Fig. 14.
Dezvoltatorul notei Fig. 14. cărți de exemplu, cu dorințele și estimarea costurilor forței de muncă ca unități de muncă în tehnologii flexibile [3] a decis să utilizeze un moment perfect - perioada de timp în care dezvoltatorul funcționează numai pe o singură sarcină, fără a fi distras de orice altă activitate, cu o capacitate de aproape de maxim . În practică, de multe ori ca o unitate de timp folosit de idealul de om-săptămâni sau ideală de jumătate de săptămână umană. Cea de a doua estimare este mai realistă, deoarece există multe obstacole, inclusiv corespondența de e-mail, întâlniri, membrii echipei de ajutor, week-end, boală, concediu, care nu permite utilizarea unui timp ideal ca o unitate de forță de muncă pentru evaluare.
Fiecare evaluare ar trebui să fie luată în considerare, testată și susținută de experiență și considerații suplimentare. Cea mai simplă și mai eficientă metodă de determinare a efortului este de a compara această dorință cu dorințele pe care dezvoltatorul le-a implementat mai devreme. Dacă anterior dezvoltatorul nu sa confruntat cu o sarcină similară, ar trebui să efectueze un studiu suplimentar (să conducă o discuție suplimentară a dorințelor cu clientul, să efectueze o pre-programare etc.).
Procesul de formare a dorințelor și evaluarea acestora este iterativ și necesită întâlniri multiple ale clientului cu dezvoltatorii. Formarea dorințelor și evaluarea costurilor forței de muncă pentru implementarea acestora este munca comună a clientului și dezvoltatorilor. În unele cazuri, dezvoltatorul poate scrie o notă la cererea clientului într-un câmp special al cardului.
Trebuie remarcat în mod special faptul că evaluarea costurilor forței de muncă nu este o promisiune de a îndeplini implementarea dorinței absolut exact în perioada indicată pe card. Prin urmare, la evaluarea muncii, trebuie să acordați atenție următoarelor puncte cheie:
• pe card este necesară o estimare de timp aproximativă;
• Când evaluezi munca, nu intra în detaliile de proiectare sau de codificare, dar nu le ignori complet;
• Timpul necesar pentru evaluarea dorinței trebuie limitat.
Evaluarea muncii în tehnologii flexibile este probabil cel mai dificil proces pentru acele echipe care nu au suficientă experiență. În același timp, acesta este un proces constructiv, în cursul căruia evaluările devin din ce în ce mai exacte.
Cu cât se execută mai mult, cu cât sunt obținute mai multe estimări reale, cu atât mai exactă echipa poate estima costurile forței de muncă. Prin urmare, nu trebuie să așteptăm rezultate bune din estimările inițiale, deoarece ele vor deveni mai precise și mai exacte în timp. Pentru ca estimatorul costului forței de muncă să funcționeze pe deplin, este necesar să se stabilească o muncă reală pentru implementarea unor dorințe specifice cu același grad de detaliere ca în planificare.
Dorințele utilizatorului ar trebui să fie implementate pe principiul "tot sau nimic". Dacă volumul dorinței este prea mare (laboriositatea vânzării este mai mare de 5 unități), clientul este rugat să-l descompună. În acest caz, cuvântul "divide" este scris în colțul din dreapta sus al cardului.
Împărțirea dorințelor utilizatorului este sarcina clientului. Dezvoltatorul poate oferi numai recomandări cu privire la modul cel mai bun de a efectua separarea, dar în final, clientul are ultimul cuvânt.
Cea mai bună modalitate de a împărtăși dorința clientului este de a încerca să creați două sau mai multe dorințe independente. Acest lucru este destul de ușor de făcut dacă clientul dorește să înregistreze mai mult de o acțiune, care poate fi efectuată independent unul de altul. Această soluție nu numai că reduce efortul necesar pentru a pune în aplicare o dorință, dar, de asemenea, minimizează dependențele dintre dorințe.
Dacă pe card este scrisă o dorință, dar este prea mare, decorațiile ar trebui eliminate, i. acele adăugiri la dorința care îi conferă valoare adăugată, dar fără care puteți face fără. Puteți elimina peisaje prin excluderea acestora din implementare sau prin crearea unei noi dorințe cu cea mai mică prioritate. De exemplu, dorința din exemplul prezentat în Fig. 14, inițial ar putea conține o cerință de a furniza o listă de hoteluri cu logo-urile lor.
Etapa de confirmare În acest stadiu, clientul trebuie să determine domeniul de activitate și data de lansare a versiunii următoare, iar dezvoltatorii trebuie să confirme cu încredere că sunt capabili să-și îndeplinească domeniul de activitate planificat până la termenul specificat. Faza de confirmare include patru etape.
obligatoriu - fără implementarea acestor dorințe, produsul software nu va putea funcționa sau va fi inutil pentru client;
opțional - punerea în aplicare a acestor dorințe poate fi amânată.
Ordinea de realizare a dorințelor pentru client este determinată de prioritatea lor.
• Sortați dorințele în funcție de risc.
Dorințe care pot fi evaluate cu un grad ridicat de precizie;
Dorințe care pot fi evaluate cu un grad acceptabil de acuratețe;
dorințe care sunt aproape imposibil de evaluat.
Dezvoltatorii preferă să înceapă implementarea cu dorințele care prezintă cel mai mare risc. Cu această abordare, dacă există probleme în procesul de implementare, dezvoltatorii vor avea timp suficient pentru a le rezolva.
• Determinarea vitezei de implementare.
Dezvoltatorii spun clientului câte unități de timp au nevoie echipa pentru a pune în aplicare dorințele planificate.
• Determinarea sferei de lucru - clientul selectează un set de carduri pentru următoarea versiune. Există două strategii principale pentru determinarea domeniului de activitate:
clientul stabilește data finalizării lucrărilor asupra versiunii și selectează un set de dorințe în conformitate cu evaluarea și viteza de lucru a proiectului;
clientul alege un set de dorințe în conformitate cu evaluarea acestora, pe baza căreia se stabilește apoi data finalizării.
Este dificil să alegeți dorințele astfel încât numărul total de unități de muncă necesare pentru a implementa dorințele selectate să corespundă exact dimensiunii iterației. De exemplu, cele trei priorități cele mai importante necesită implementarea a 24 de unități de muncă, în timp ce dimensiunea calculată a iterației este de 26 de zile. Într-o astfel de situație, este mai bine să lași puțin timp decât să întrerupeți punerea în aplicare a iterației sau să faceți o performanță slabă. Dacă intenționați să faceți mai puțin iterații în mai multe iterații succesive, puteți programa următoarea iterație pentru a programa un volum de lucru mai mare decât iterația.
Cum se rezolvă conflictul între succesiunea implementării dorințelor propuse de client și succesiunea pe care o propun dezvoltatorii? Dacă dezvoltatorii prevăd riscuri mai mari, clientul ar trebui să-și asculte argumentele. Temerile dezvoltatorilor pot fi cauzate de mai multe motive, dintre care cele mai frecvente sunt următoarele:
• dezvoltatorii nu sunt siguri că vor putea să evalueze cu exactitate efortul necesar pentru punerea în aplicare a acestei solicitări;
• realizarea unei anumite dorințe este legată de utilizarea de software dezvoltat de terțe părți, în legătură cu care nu poate fi în întregime de încredere;
• Dezvoltatorii nu știu cum să atingă productivitatea specificată a produsului software;
• Dezvoltatorii nu știu cum să execute proiectarea software-ului, astfel încât în viitor implementarea oricărei dorințe neplanificate să nu conducă la procesarea întregului cod.
În orice caz, succesiunea realizării dorințelor este determinată de client. Sarcina dezvoltatorilor este să avertizeze deschis despre prezența tuturor riscurilor și să nu ia o decizie pentru client.
Faza de administrare Există mai multe motive care pot determina echipa să se întoarcă la procesul de planificare a versiunilor sistemului. Principalele sunt o schimbare a priorităților în dorințele clientului și o schimbare în viteza dezvoltatorilor. În comparație cu metodologiile tradiționale, în tehnologiile flexibile, clientul nu trebuie să descrie în detaliu ce produs software dorește să primească înainte de a începe să lucreze. Apariția unor noi dorințe este un proces previzibil și justificat.
Faza de control include următoarele etape:
• Iterație - la începutul fiecărei iterații, care durează o săptămână sau trei săptămâni, clientul selectează câteva din cele mai valoroase dorințe pentru acesta, care vor fi implementate în cadrul acestei iterații. Ca urmare a implementării dorințelor primei iterații, ar trebui să se producă un produs software care funcționează de la început până la sfârșit, chiar și în starea foarte rudimentară.
• Regenerarea - în cazul în care dezvoltatorii ajung la concluzia că au supraestimat viteza proprie, aceștia sunt de acord cu clientul care ar trebui să păstreze cele mai importante dorințe în versiunea curentă. La determinarea acestui set se iau în considerare viteza și estimările revizuite.
• O nouă dorință - dacă în mijlocul lucrărilor pentru versiunea următoare clientul ajunge la concluzia că trebuie adăugată o nouă dorință la versiune, el o poate scrie. Dezvoltatorii evaluează noua dorință, după care clientul elimină dorințele din setul rămas cu o evaluare totală echivalentă și adaugă o nouă dorință planului.
• Reevaluarea - dacă dezvoltatorii ajung la concluzia că planul nu mai corespunde imaginii exacte a proiectului, acesta poate reevalua dorințele rămase și poate redefini domeniul de activitate și viteza de dezvoltare.
În practică, apar situații care necesită o revizuire substanțială a planului. Astfel de situații includ următoarele:
• amânarea "pentru mai târziu" dorințele devin prea mult;
• viteza comenzii se modifică semnificativ.
În aceste cazuri este necesar să se considere că planul devine nevalabil și este necesar să se dezvolte un nou plan.
Reciclarea planului începe cu faptul că dezvoltatorii reevaluează cantitatea de muncă. În acest moment, dezvoltatorii au avut o experiență specifică de a lucra la acest proiect, așa că în procesul de lucru asupra planului, aceștia pot deja să funcționeze cu indicatori reali luați din dorințele trecute și, prin urmare, să evalueze mai bine volumul lucrărilor viitoare. Este deosebit de important să se reevalueze costurile forței de muncă pentru implementarea dorințelor planificate la începutul lucrării, de vreme ce primele planuri se dovedesc a fi cel mai puțin exacte.
Imediat ce dezvoltatorii specifică lucrarea, clientul analizează din nou toate dorințele și le sortează în funcție de ordinea de execuție necesară. Apoi procesul de planificare se desfășoară ca de obicei.
După cum arată practica, planul de lansare trebuie revizuit la fiecare trei sau patru iterații. Primul plan de emitere a versiunilor suferă schimbări deosebit de mari, de când este compilat, nu există încă statistici și dorințe realizate. Primul plan este un punct de pornire din care puteți urmări progresul proiectului, acumulați date statistice despre proiect.
Articole similare
Trimiteți-le prietenilor: