Care este Metodologia corectă de management de proiect

Înainte de a răspunde direct la întrebarea din titlu, este întotdeauna bine să clarificați care este obiectivul final al proiectului pe care doriți să îl atingeți

Cum va arăta produsul într-o lună, jumătate de an și peste un an. Dar descrie-l acum. Acest lucru vă va oferi o anumită perspectivă și vă va stabili așteptările de bază cu privire la nivelul dvs. de predictibilitate, flexibilitate, agilitate, viteza de intrare pe piață și fixarea costurilor în timp.

Da, astăzi, înființarea proiectelor de cascadă pare a fi o idee ridicolă. Mai ales dacă s-a dovedit deja de nenumărate ori că, dacă vrei să reacționezi rapid la schimbările de pe piețe, nu ai altă opțiune decât să mergi agil. Dar dacă obiectivul tău este să livrezi un produs peste un an cu funcții care sunt deja destul de clare și limitate chiar de la început și ai echipe de oameni fără experiență anterioară cu metodologia agilă, atunci sigur, fii conservator și mergi în cascadă.

Nu toate cazurile sunt atât de simplu de concluzionat. Să aruncăm o privire la cum să evaluăm mai bine care metodologie este mai bună pentru proiectul tău.

Cum arată o cascadă?

În loc să intram în unele definiții pe care toată lumea le cunoaște deja de câteva decenii, un rezultat practic al unui proiect de cascadă arată de obicei astfel:

Mai întâi, planificați ceea ce doriți să faceți ca rezultat/produs final și cât poate costa aproximativ.

Începeți procesul de colectare a cerințelor. Ați discutat în detaliu toate detaliile produsului final, ați obiectat, ați pus la îndoială, ați convenit, ați discutat din nou și, în final, ați confirmat.

Estimați totul și confirmați așteptările bugetare.

Proiectați soluția. Conduceți mai multe întâlniri cu părțile interesate. Creați diverse documente și lăsați părțile interesate să le revizuiască. Confirmați și aprobați proiectul final funcțional și tehnic.

Implementați soluția pe baza designului. Aici dezvoltați produsul final complet.

Intră în faza de testare și execută diverse tipuri de teste. Teste unitare, teste de sistem, teste funcționale, teste de integrare, teste de performanță, teste de regresie, teste de acceptare a utilizatorilor și, potențial, multe altele (în funcție de cultura companiei). Documentați totul și lăsați părțile interesate să-l revizuiască și să aprobe.

Implementați soluția în mediul de producție. Aici utilizatorii țintă încep să folosească produsul final și complet.

Programați o fază de asistență în timpul căreia echipa de dezvoltare corectează potențialele erori ale soluției.

Întregul proces poate dura câteva luni până la câțiva ani. După cum puteți prezice, utilizatorii vor vedea rezultatele doar la sfârșitul acelui proces. Deci, după o lungă așteptare, vine momentul adevărului (sau al eșecului).

Dacă ceva se schimbă în acest timp lung și produsul final ar trebui să arate puțin diferit, aceasta este o situație pe care o numiți o cerere de modificare. Designul trebuie redeschis, reluat și reaprobat. Prelungește întregul program de timp cu o altă parte. Fiecare modificare necesită o repornire a întregului proces înainte.

Pe de altă parte, aveți o definiție de fază solidă, un buget fix pentru fiecare fază și un timp fix. Chiar dacă trebuie să aștepți mult pentru a obține primul rezultat, dacă șansele de schimbări pe parcurs sunt minime, poate fi totuși o opțiune preferabilă.

Cum arată un Agile?

Acum, acesta este modul în care proiectul poate funcționa într-o configurație Agile:

Definiți viziunea de afaceri a produsului final. Aproximativ, dar cu cerințe clare de afaceri și așteptări cu privire la ceea ce produsul va îndeplini pentru utilizatori.

Creați o listă de epopee funcționale și facilitatori tehnici care acoperă viziunea.

Efectuați o estimare la nivel înalt a epopeilor și a factorilor de sprijin pentru a stabili unele așteptări de bugetare slabă și termenul de livrare. Definiți ce este produsul minim viabil (MVP) și care sunt restul caracteristicilor care formează produsul final.

Creați o echipă scrum și programați sprinturile în intervalul de timp. Împărțiți epopeele în caracteristici și povești cu echipa. Estimați poveștile și planificați-le pentru sprinturile viitoare în funcție de prioritatea pe care o au caracteristicile și poveștile.

Lucrează la poveștile la fiecare sprint. Includeți toate activitățile din sprinturi, adică proiectarea, dezvoltarea, testarea și implementarea. La sfârșitul fiecărui sprint, prezentați rezultatul creșterii utilizatorilor și căutați feedback.

Dacă ceva iese din pistă sau are un rezultat dorit, modificați caracteristicile sau poveștile pentru a se adapta la realitatea actualizată. Reflectați-l imediat de la următoarele sprinturi.

Imediat după finalizarea domeniului de aplicare a MVP, eliberați-l utilizatorilor finali pentru a colecta feedback rapid de producție.

Continuați să dezvoltați restul caracteristicilor reflectând rezultatele feedback-ului utilizatorului din partea deja lansată a sistemului.

Acesta este doar un rezumat rapid, dar diferența față de cascadă este deja clară. Feedback rapid, adaptare, reflectarea nevoilor actuale care se schimbă în timp, primul produs valoros livrat în cel mai scurt timp posibil. Toate acestea sunt proprietăți pe care nu aveți șanse să le obțineți într-un proiect de cascadă.

Agil vs. Cascada

Un proiect nu poate avea succes fără o metodologie adecvată de management de proiect. Aceasta înseamnă definirea proceselor, metricilor, evaluărilor și modalităților generale de lucru pentru echipele care formează proiectul.

Echipele trebuie să știe ce reguli să urmeze, ce vor defini etapele, când să le atingă și cum să măsoare și să evalueze succesul. În același timp, părțile interesate trebuie să înțeleagă la ce să se aștepte de la proiect și când vor putea vedea primele rezultate ale lucrării.

Cu puțină generalizare, putem spune că proiectele care funcționează în medii cloud sunt mult mai probabil să încline către metodologii agile (sau ar trebui, cel puțin). Proiectele care lucrează cu infrastructuri on-premise încă preferă foarte des procesele în cascadă. Aceasta vine ca o concluzie firească.

Mediul cloud este construit de la sol pentru a se potrivi mediului în continuă schimbare. Se adaptează cât mai repede posibil (cu diverse servicii „elastice”) la noua realitate. Mediul on-premise este adesea predefinit la început. Este greu de schimbat în timp, așa că echipele lucrează cu variabile deterministe pe toată durata proiectului.

Rezumatul abordării Agile vs. Waterfall.

FeatureWaterfall ApproachAgile ApproachHandling User RequirementsChange este tratată ca un proces formal (Change Request). Este posibil ca munca să fie refăcută, impactând costurile și termenele. Acceptă schimbările ca parte a procesului standard, fără un impact semnificativ asupra costurilor sau calendarului. Fazele sunt rigide și aderă la planul inițial. Are o viziune clară asupra produsului final, dar permite modificări. Munca este organizată în sprinturi cu flexibilitate în modul în care sarcinile sunt finalizate. Urmărirea progresului proiectului Urmărirea progresului în fiecare fază. Întârzierile într-o fază pot afecta întreaga cronologie a proiectului. Urmăriți progresul prin sesiuni demo la sfârșitul fiecărui sprint. Se concentrează pe produsul funcțional. Colaborare în echipă Oameni diferiți în diferite faze ale proiectului, interacțiune limitată. Echipă interfuncțională cu comunicare constantă între membrii echipei și părțile interesate. Managementul riscului Urmărirea stării pe baza progresului fazei. Răspunde la riscuri retrospectiv în timp ce aderă la plan. Se concentrează pe rezolvarea dependențelor dintre echipe și activități în mod proactiv. Adaptează planul pentru eliminarea riscurilor proiectate.Cadru de implementare Metodologie tradițională.Necesită practici de transformare pentru a se adapta la abordarea agilă. Implică schimbarea obiceiurilor și a mentalității.

Această alegere va defini, totuși, mai multe aspecte ale proprietăților de execuție a proiectului.

#1. Cerințele proiectului și managementul schimbărilor

Unul dintre cele mai importante aspecte care definesc alegerea este modul în care vor fi gestionate cerințele utilizatorului. Și, de asemenea, care este procesul dacă mai târziu este necesară o modificare a cerințelor deja convenite?

Cu un proiect de cascadă, toate cerințele sunt definite și aprobate de părțile interesate la început; dacă apare vreo modificare a acelei stări, proiectul o tratează ca pe o cerere de modificare. Trebuie să fie din nou validat, agreat și confirmat.

Orice lucrare deja făcută până în acel moment trebuie revăzută și reluată. Costurile trebuie reajustate (deoarece este o muncă suplimentară care nu este acoperită de contractul inițial). În cel mai rău caz, chiar și întregul calendar al proiectului trebuie prelungit.

Cu o configurare agilă, schimbările sunt binevenite. Tratezi modificările ca pe o afacere standard de zi cu zi. Sunteți de acord cu părțile interesate (probabil ca rezultat al celei mai recente demonstrații de sprint) că schimbările sunt cruciale pentru a menține viziunea proiectului. Apoi, programezi acele modificări imediat pentru următoarele sprinturi.

Conținutul anterior se va schimba odată cu asta, iar echipele continuă să lucreze cu noi cerințe din acea zi. Nu există pierderi de timp sau costuri. Pur și simplu te adaptezi la noua realitate imediat și înlocuiești planul inițial cu cel nou. Nu este deloc nevoie de un management special al cererilor de modificare. Totul face parte din inițiativele de planificare a sprintului.

#2. Planificarea proiectului și domeniul de aplicare

După cum v-ați putea aștepta, proiectul cascadă stabilește și fixează toată domeniul de aplicare la început. Generați planul de proiect în jurul acestui domeniu. Apoi, împărțiți durata proiectului în faze specifice (de obicei analiză, proiectare, dezvoltare, testare, implementare, asistență și întreținere) și reparați echipele și resursele în jurul acelor faze. Pentru cea mai mare parte a cronologiei proiectului, obiectivul dvs. principal este să rămâneți cu acest plan original în ceea ce privește costurile și calendarul cât mai mult posibil.

Un proiect agil are o viziune asupra produsului final în loc de un plan dur. Starea finală este clară, dar calea pentru a ajunge la acea stare este liberă să se schimbe. De asemenea, calendarul proiectului este încă definit și convenit pe baza unei estimări preliminare a cererii și a experienței de încărcare a capacității pentru echipele care lucrează la proiect. Planul nu are faze separate. În schimb, fiecare sprint este o fază mică în sine, care conține toate activitățile de care echipa are nevoie pentru a lansa cu succes produsul incremental.

În rezumat, proiectul cascadă tratează schimbările ca pe o complicație de rezolvat (și o oportunitate pentru vânzători de a achiziționa bani suplimentari). În schimb, proiectul agil tratează schimbarea ca pe o afacere ca de obicei, fără consecințe suplimentare (altele decât un produs final mai potrivit).

#3. Urmărirea progresului proiectului

Proiectul cascadă urmărește progresul planului în fazele proiectului. Faza de proiectare nu poate începe înainte de finalizarea fazei de analiză, testarea nu poate începe înainte ca întreaga construcție să fie finalizată și așa mai departe.

Dacă unele dintre faze au întârzieri, aceasta va afecta progresul fazelor rămase ale proiectului. De aceea, este important să verificați activitățile din cadrul fiecărei etape și să vă asigurați că progresează liniar în timp. În caz contrar, creșteți riscul de a întârzia acea anumită fază și, în consecință, întregul proiect.

Proiectul agil urmărește progresul, în principal cu sesiuni demo care au loc la sfârșitul fiecărui sprint. Produsul lucrabil este principala măsură a progresului. Desigur, doriți să vă asigurați că fiecare sprint se termină cu conținut complet de sprint. Nicio poveste sau doar un minim de povești sunt transferate la următoarele sprinturi.

În cele din urmă, este mult mai ușor să vedeți progresul general al proiectului dacă puteți încerca direct creșterea actuală a produsului și puteți reveni imediat la echipă cu feedback foarte concret.

#4. Colaborarea în echipă

Este vorba despre activități strict separate de cascadă față de colaborarea continuă cu toate părțile unei echipe agile.

Un proiect de cascadă are de obicei diferiți oameni care lucrează în diferite faze ale proiectului. S-ar putea să se debordeze unul pe altul într-o oarecare măsură, dar sunt încă grupuri diferite de oameni. Aproape silozurile, ai putea spune.

Definiția unei echipe agile constă în comunicare și valoare. Va fi, de asemenea, o echipă interfuncțională capabilă să execute toate activitățile ciclului de viață al produsului. Silozurile echipelor este ceva ce nu vrei să existe. Comunicarea constantă înainte și înapoi între echipă și părțile interesate externe este o definiție de bază a unui proiect agil de succes.

#5. Managementul riscurilor

Evident, doriți să aveți un proces pentru urmărirea oricăror riscuri, probleme sau orice fel de obstacole pe care proiectul le-ar putea aduce în timpul cronologiei sale.

În cazul unui proiect în cascadă, aceasta se traduce prin urmărirea stării fazei curente a proiectului. Raportarea standard de stare asemănătoare unui semafor va fi verde (totul este în regulă și în conformitate cu planul), galben (există unele probleme importante, dar există încă o înțelegere clară a modului de rezolvare a acestora) sau roșu (adică proiectul are probleme serioase care pot afecta termenele sau bugetul original).

Proiectul agil este și aici diferit. Nu prea urmăriți progresul către obiectiv. Mai degrabă, rezolvi dependențele dintre diferite echipe și tipuri de activități. Scopul este să se asigure că nicio echipă nu așteaptă o altă echipă cu activitățile de progres.

Desigur, pot apărea riscuri, dar atunci soluția trebuie să schimbe planul în viitor, astfel încât riscul să dispară, mai degrabă decât să găsească soluția pentru risc, păstrând în același timp planul original.

Cu alte cuvinte, o configurare agilă a proiectului folosește toate modalitățile posibile pentru a schimba planul pentru a nu face față riscurilor proiectate, ceea ce înseamnă că managementul riscului este proactiv. În cazul unui proiect de cascadă, răspunzi la riscuri retrospectiv și încerci să le rezolvi în cel mai scurt timp posibil respectând planul inițial.

#6. Cadrul de implementare

Tactica de implementare pentru proiectele în cascadă este evident mai puțin problematică decât pentru proiectele agile. De obicei, metodologia cascadei este status quo-ul pe care oamenii l-au practicat deja de mulți ani.

Pe de altă parte, proiectele necesită practici de transformare agile pentru a-și schimba obiceiurile, mentalitatea și modurile de lucru. Este un proces dificil și adesea și destul de de lungă durată. Companiile investesc cantități semnificative de timp și resurse pentru a-i învăța pe oameni să se adapteze la procesele agile.

Beneficiile sub forma adaptării rapide la nevoile în schimbare ale clientului sunt semnificative, dar schimbarea mentalității oamenilor și a mediului de lucru general este partea cea mai dificilă.

De cele mai multe ori, este și singura modalitate de a rămâne competent pe piață, astfel încât compromisurile sunt răsplătite cu mare succes pentru cei care reușesc.

Cuvinte finale

Să spunem clar. Cu excepția cazului în care aveți un client foarte conservator, fără o mare motivație pentru a oferi rezultate rapid în producție (din orice motiv ar putea avea pentru asta), cel mai bun pariu este să începeți să modelați echipele agile chiar de la început. Acest lucru este, literalmente, o idee simplă în lumea de astăzi. Acest lucru este valabil chiar și în cazul instalării sistemelor tradiționale on-premise. Mai ales dacă echipa este nouă sau pornește de la zero cu oameni originali, mai are sens să transformăm procesele pentru a se alinia cu metodologiile agile.

Acestea fiind spuse, încă văd proiecte în care oamenii pur și simplu refuză să urmeze acest tip de proces agil sau orice altă configurație, dar organizarea strict specifică a unei faze a muncii. Ei urmează calea obișnuită de contractare a lucrării pentru un anumit timp și buget. Apoi, se așteaptă ca proiectul să urmeze această configurație fără abateri de la plan și bani (cu rezultate diferite, de obicei nu bune).

Aceasta este o decizie pe care au dreptul să o ia, dar în cele din urmă, cu o astfel de decizie, decid să rămână în trecut. S-ar putea să le funcționeze pentru o vreme, dar este doar o chestiune de timp până nu va mai funcționa.

În continuare, consultați articolul detaliat despre ciclul de viață al testării Agile.