// articol...

Notiuni generale

Agile vs. Waterfall, aplicabilitate

În ultimii 10 ani, mai ales, dezvoltarea agilă a fost aplicată în cele mai diverse situații, arătându-și superioritatea în unele dintre ele și limitele în altele. Noțiunea de “Agile Development” are la bază un document numit “The Manifesto for Agile Software Development”, publicat în 2001 de 17 programatori și dezvoltatori software, care doreau să revoluționeze modul în care se dezvoltă software. E de menționat faptul că noțiunea de Agile a absorbit o sumedenie de metode “alternative” de dezvoltare, cum ar fi, de exemplu XP (extreme programming) sau RAD (rapid application development). Cuvântul “Agile” s-a răspândit atât de mult în ultimii ani, încât a devenit un cuvânt magic, care e folosit adesea, golit de conținutul și de aplicabilitatea lui inițială, pentru a desemna un fel anume de atitudine. Agile a ajuns un Hype.

Dezvoltarea agilă presupune dezvoltarea continuă, în cicluri egale succesive a unui sistem sau produs, pornind de la un set minim de cerințe. Astfel, se poate teoretic pune la dispoziția clientului un produs minim viabil relativ devreme în desfășurarea proiectului, urmând ca produsul final să se dezvolte odată cu cerințele. Cu alte cuvinte, atunci când un client nu are o idee foarte clară asupra a ceea ce vrea, prin metoda agile, i se promite că va avea totuși în final produsul pe care și-l dorește. În contrast cu aceasta, metoda clasică, Waterfall, prevede o separare clară a fazelor de concepție, dezvoltare și test. În cadrul acestei metodologii, dezvoltarea nu începe, până ce rezultatul final nu este clar definit, măsurabil și planificabil.

Deși confuzia e destul de răspândită, Agile și Waterfall nu sunt metodologii de Project Management ci se referă strict la metodologia de dezvoltare. Scrum, metodologia care se aplică cel mai des proiectelor cu dezvoltare agilă, se concentrează asupra organizării comunicării, management-ului cerințelor și al ciclurilor de dezvoltare (sprint-uri), fără a aborda capitole esențiale ale management-ului de proiect, cum ar fi beneficiul clientului, management-ul risc-ului, al configurației, al bugetului total și nu face distincția clară între change și claim. Un proiect cu dezvoltare agilă este foarte instabil și impredictibil, este ca un automobil condus noaptea doar cu luminile de poziție. Capacitatea de a prevedea costurile finale, durata totală, nevoia de resurse, costurile suplimentare provocate de cerințe noi (change) e limitată.

De aceea, metodologia agilă nu poate fi aplicată nediferențiat și nu pe întreaga durată a unui proiect complex. Există o contradicție fundamentală între nevoia de predictibilitate, mai ales din punct de vedere financiar, într-un proiect complex și gradul înalt de variabilitate a cerințelor, caracteristic metodei agile.

În ultimul timp metoda agilă se aplică de obicei controlat în cadrul unui proiect condus după metodologia clasică, rezumându-se la fazele creative, cu un buget relativ mic în raport cu bugetul total al proiectului. În felul acesta se reduc riscurile asupra bugetului total, păstrându-se avantajele de creativitate ale metodologiei agile. Aceste faze creative sunt de obicei cea de analiză, de concepția, de dezvoltare a unui prototip, sau chiar faza de dezvoltare a produsului, dar având la bază un catalog de cerințe/un caiet de sarcini bine detaliat. În acest ultim caz, rămâne agilă doar dezvoltarea software însăși, dezvoltarea cerințelor fiind în mare parte încheiată în timpul fazei de concepție.

Proiectele eminamente creative, asemănătoare proiectelor de cercetare, în care rezultatul final nu poate fi cunoscut de la început, sunt în continuare cele mai potrivite pentru metodologia agilă, însă aceste proiecte sunt mai degrabă excepția, de obicei, se știe de la început ce problemă trebuie să rezolve, sau cărei nevoi trebuie să răspundă produsul final al proiectului. Metoda agilă se folosește de asemenea în situații în care există un deadline fix, dar nu se știe cât de departe va putea fi dezvoltat produsul până atunci. Exemplul clasic:

  • Un site web: e esențial ca site-ul să există la o dată x, e mai puțin important cât din funcționalitățile planificate inițial vor fi disponibile la data x. Și în acest caz, doar dezvoltarea are loc după metoda agilă, cerințele au fost definite în faza anterioară.

În concluzie, metodologia agilă, dacă nu este aplicată nediferențiat, dacă nu e desenată pe tricou, ca o formă de modă, poate fi aplicată cu succes în anumite cazuri, în completarea metodologiei clasice de Project Management.
Așteptăm cu interes critici și comentarii, poate alte povești de succes cu implicarea metodei agile.

Discussion

No comments yet.

Post a comment