Agile vs waterfall

Tocmai am citit proposalul (cuprinsul) noii carti a lui Dan Bunea - despre teoria si practica metodologilor agile.

Arata foarte bine.

Am surprins insa o potentiala capcana in modul in care sunt introduse metodologiile agile ca raspuns la esecul metodologiilor clasice.
Atentie la sindromul "shfortza mea e mai mare decat a ta" - C-ul e mai tare decat Basic-ul, .Net-ul e mai tare decat Visual Foxul si agile-ul e mai cool decat waterfall-ul.
Programatorii sunt fiinte teribil de sensibile si mai ales orgolioase - si argumentatiile de genul x e mai tare decat y au tendinta de a starni furtuni pentru ca sunt teribil de interpretabile in lipsa descrierii exacte a contextului ... (x e mai bun decat y pentru (si numai pentru) problema z).
Mare grija asadar la modul in care trebuie introdus/motivat agile-ul. - nu cred ca e musai o alternativa la "esecul" metodologiilor clasice.
N-as incerca sa-l vand ca pe un panaceu (universal), nici macar ca pe cura care te vindeca de waterfall.
Dan Blendea mi-a atras atentia asupra unui articol mai vechi al lui Joel - http://www.joelonsoftware.com/articles/FiveWorlds.html . Exista zone din industria de software unde nu se pot aplica tehnicile incrementale - si unde first shot is the only shot : embedded, game developement, drivers, poate chiar si aplicatiile cu foarte multi clienti.
Mai mult, waterfall-ul poate fi o motodologie de succes daca toti oamenii implicati lucreaza precum ceasornicul elvetian (inclusiv clientul care iti defineste corect si complet problema inca de la inceput). La drept vorbind exista foarte multe exemple de proiecte mari de succes scrise pe waterfall (nu stiu cate exemple de agile - adevarul e ca noi ne bucuram cand auzim ca M$-ul spre exemplu foloseste elemente agile, insa standardul in industria software cred ce e departe de a fi agile-ul).
Waterfall pleaca de la premiza ca orice schimbare costa - si costa din ce in ce mai mult cu cat produsul se apropie de faza finala.
Conceptele din waterfall probabil sunt imprumutate din industria traditionala : in momentul in care te apuci sa construiesti fundatiile unei cladiri, planurile arhitecturale trebuie sa fie complete si 100% corecte ; nu iti mai poti permite sa schimbi structura cladirii dupa ce ai construit primul etaj (sau sa accepti cereri de modificare din partea clientului chiar inainte de inaugurare).
Traditional, schimbarile sunt IMPOSIBILE dupa trecerea la urmatoarea faza - si arhitectii si constructorii au invatat sa se descurce cu chstia asta si sa-si faca treaba bine - iar clientii au invatat sa respecte contractul si sa inghita in sec cand vad cladirea care parca nu seamana cu ce aveau ei in cap.
Si totusi cladiri se construiesc destul de multe - si as zice ca in general, sunt destul de putine refuzate ca avand prea multe bug-uri. Asta ma face sa cred ca si waterfall-ul ar trebui sa mearga ok in software - diferenta probabil e fie ca arhitectii software si programatorii lucreaza mai prost decat meseriasii cu mistria, fie ca dinamica (durata de viata si necesitatea schimbarii) in software e mult mai mare decat in constructii.
Concluzia - as zice ca metodologiile agile nu incearca sa repare problemele din waterfall, ci mai curand incearca sa beneficieze de avantajele pe care ti le ofera lucrul la o chestie atat de virtuala precum softul. In software NU E IMPOSIBIL sa schimbi cate ceva dupa ce ai trecut la o faza avansata de executie si, daca respectam cateva reguli de baza, poate sa nu fie nici chiar asa de costisitor precum pare. In software ne putem permite sa schimbam planurile cladirii dupa ce am construit deja primul nivel si ne putem permite sa fim mai flexibili in dialogul cu clientul, ne putem permite sa amanam deciziile pe cat mai tarziu, sa minimizam costurile cerute de executia ireprosabila a fiecarui pas inainte de construirea urmatorului.
Si in definitiv - uneori e foarte greu sa explici clientului de ce o modificare foarte tarzie in specificatii implica costuri prea mari de implementare sau determina rescrierea produsului. Clientii STIU ca facem software si nu cladiri - clientii CER modificari cat mai tarziu (si dupa darea in folosinta ... ). Chestie valabila cu atat mai mult cu cat clientul e mai afon in notiunile de project management in software.
Pana la urma agile-ul NU te invata cum sa scrii soft (poti sa o faci si cu waterfall) - ci cum sa fi mai putin rigid, mai adaptabil, mai eficient economic, mai aproape de client.
Mai aproape de succes.

Cosmin
On 2/18/06, Dan Bunea wrote:
---------- Forwarded message ----------From: Dan Bunea Date: Feb 18, 2006 4:06 PMSubject: Book reloaded - second attempt TOCHi,I have refined now the TOC, and I belive I have done a much better jobnow. I have attached it in a document, with estimated on pages and anexplanation of what each will contain, and in the end a list ofpractices from XP, SCRUM, Crystal and Lean that will be exposed ineach part, that is more like a todo/reminder list for me, but Iincluded it as I believe adds to the clarity of what's going to beincluded.I am trying to come up asap, (early next week) with some content. Someof the content will be adapted from my previous writing(communication, XP, TDD) so that we are still on schedule for thedelivery.Thank you,Dan Buneahttp://danbunea.blogspot.com--Dan Buneahttp://danbunea.blogspot.com