Je to preto, že vodopádový prístup zatvára dvere k zmenám špecifikácií hneď, ako sa začne fáza návrhu, a predsa všetci vieme, že počas navrhovania sa objavia lepšie nápady. Rovnako tak v skutočnom svete dizajn nezmrazí, keď je odhlásený: ak programátor spozoruje lepšie alebo efektívnejšie by sa to malo zvážiť, ale s vodopádom už dizajnér opustil budova! To znamená, že programátori pravdepodobne urobia zmeny aj tak, ale na základe úplného nepochopenia celkového dizajnu. Snáď najväčším problémom vodopádového prístupu je to, že poskytuje celú aplikáciu, všetko naraz, zvyčajne príliš neskoro vo vývojovom cykle na to, aby klient urobil niečo podstatné zmeny. V zásade by to klient nemal potrebovať, ak bola splnená špecifikácia, ale toto je skutočný svet.
Na opačnej strane plota sú takzvané agilné programovacie metodológie, ktoré podporujú rýchle vykonávanie vecí. Existuje veľa variácií, ale v NlightN máme tendenciu začať s „veľkým obrazom“ nácviku odpovedzte na otázku: „Ako to budeme vedieť, keď sa tam dostaneme? Všeobecne povedané, aké vlastnosti máme vyžadovať? Napríklad s
www.passyourtheory.co.uk, vedeli sme, že chceme službu, ktorá bude obsahovať komponenty s možnosťou výberu z viacerých možností a vnímanie nebezpečenstva teoretického testu DSA spolu s tréningom rozpoznávania značiek a e-learningom na pokrytie Kódexu cestnej premávky. Ako predplatiteľská služba by sme potrebovali aj možnosti registrácie a overenia používateľov spolu s funkciami správcu. Potom sme opísali naše ciele pre každú z týchto zložiek: napríklad prvok s viacerými možnosťami, ktorý je potrebné cítiť podobný skutočnému testu, zatiaľ čo prvok vnímania nebezpečenstva sa zameral skôr na školenie používateľov ako na rutinu prax. Nakoniec sme navrhli široké dátové toky pred vytvorením celkového vzhľadu a pocitu a bez toho, aby sme v tomto bode navrhovali každú obrazovku.V našej verzii agilného programovania sme potom rozdelili webovú aplikáciu na logické komponenty a každý kúsok sme určili, navrhli, naprogramovali a nasadili. Rozhodli sme sa napríklad riešiť admin funkcie hneď na začiatku, takže sme špecifikovali, čo by mali obsahovať, navrhli sme obrazovky a naprogramovali ich všetky v krátkom čase. Rovnaký prístup sa použil pri teste s výberom z viacerých odpovedí, potom vnímaní nebezpečenstva a tak ďalej – je to ako budovanie a dom dokončením jednej miestnosti naraz, čo nemusí byť praktické pre stavebníka, ale často funguje dobre pre softvér rozvoj. Niektoré z výhod tohto prístupu spočívajú v tom, že dizajnérsky tím je vždy k dispozícii, pretože bude pracovať na ďalšom kúsku, kým programátori kódujú tento. Znamená to tiež, že projekt sa spustí (a teda skončí) rýchlejšie; klient vidí akýkoľvek pokrok tak, ako sa dosiahol; Ponaučenia a rozhodnutia prijaté v skorších fázach sa dajú použiť na neskoršie, a nie dodatočne na konci.
Nie sú to však všetky dobré správy. Agile sťažuje stanovenie rozpočtu a funguje iba vtedy, ak máte špecializovaný tím, ktorý dobre spolupracuje; vyžaduje si to aj každodennú angažovanosť klienta. Keď sme pracovali na virtuálnom svete pre Collins Reference, prijali sme agilný prístup, ktorý nám umožnil dodať v rekordnom čase, ale uspeli len preto, že dvaja projektoví manažéri v Collins sa zaviazali k tomuto pravidelnému zapojeniu a boli pripravení okamžite podniknúť kroky rozhodnutia. Tento prístup nebude vyhovovať všetkým projektom alebo všetkým klientom, ale čím dlhší je časový horizont vývoja a čím väčší rozpočet, tým sa to oplatí.
