Taip yra todėl, kad krioklio metodas uždaro duris specifikacijų pasikeitimams, kai tik prasideda projektavimo etapas, tačiau visi žinome, kad projektuojant atsiras geresnių idėjų. Taip pat realiame pasaulyje dizainas neužstringa, kai jis yra pasirašytas: jei programuotojas pastebi Reikėtų apsvarstyti geresnį ar efektyvesnį būdą, tačiau su kriokliu dizaineris jau paliko pastatas! Tai reiškia, kad programuotojai greičiausiai atliks pakeitimus, tačiau remdamiesi visišku bendro dizaino nesupratimu. Bene didžiausia krioklio metodo problema yra ta, kad jis teikia visą programą, visi iš karto, paprastai per vėlai kūrimo cikle, kad klientas galėtų ką nors padaryti reikšmingą pokyčius. Iš esmės klientui to neturėtų prireikti, jei specifikacijos buvo įvykdytos, tačiau tai yra realus pasaulis.
Priešingoje tvoros pusėje yra vadinamosios judriojo programavimo metodikos, kurios skatina greitai atlikti darbus. Yra daug variantų, tačiau „NlightN“ mes linkę pradėti nuo „didelio vaizdo“ taikymo srities nustatymo pratimo. atsakyti į klausimą: „Kaip mes žinosime, kai ten pateksime? Apskritai, kokias savybes mes turime reikalauti? Pavyzdžiui, su
www.passyourtheory.co.uk, žinojome, kad norime paslaugos, į kurią būtų įtraukti DSA teorijos testo kelių pasirinkimų ir pavojaus suvokimo komponentai, taip pat ženklų atpažinimo mokymai ir el. mokymai, apimantys Kelių kodeksą. Kadangi tai yra prenumeratos paslauga, mums taip pat reikės vartotojo prisiregistravimo ir autentifikavimo priemonių bei administravimo funkcijų. Tada apibūdinome kiekvieno iš šių komponentų tikslus: pavyzdžiui, elementą su daugybe pasirinkimų, kurių reikia jausti panašus į tikrąjį testą, o pavojaus suvokimo elementas buvo sutelktas į naudotojo mokymą, o ne į pratimą praktika. Galiausiai sukūrėme plačius duomenų srautus prieš kurdami bendrą vaizdą ir pojūtį ir šiuo metu nekurdami kiekvieno ekrano.Mūsų judriojo programavimo versijoje žiniatinklio programą padalijome į loginius komponentus ir apibrėžėme, suprojektavome, programavome ir įdiegėme kiekvieną dalį. Pavyzdžiui, nusprendėme anksti imtis administravimo funkcijų, todėl nurodėme, kas jose turi būti, suprojektavome ekranus ir visus juos suprogramavome per trumpą laiką. To paties požiūrio buvo laikomasi atliekant kelių atsakymų testą, tada pavojaus suvokimą ir pan. – tai panašu į namą vienu metu įrengiant vieną kambarį, o tai gali būti nepraktiška statybininkui, bet dažnai puikiai tinka programinei įrangai plėtra. Kai kurie šio požiūrio pranašumai yra tai, kad projektavimo komanda visada yra pasiekiama, nes jie dirbs su kita dalimi, kol programuotojai koduos šią. Tai taip pat reiškia, kad projektas pradedamas (ir todėl baigiamas) greičiau; klientas mato bet kokią pažangą; Ankstesniuose etapuose išmoktos pamokos ir sprendimai gali būti pritaikyti vėlesniems, o ne modifikuoti pabaigoje.
Vis dėlto tai ne visos geros naujienos. Agile apsunkina biudžeto nustatymą ir tai veikia tik tuo atveju, jei turite specialią komandą, kuri gerai dirba kartu; tai taip pat reikalauja kasdieninio kliento įsitraukimo. Kai dirbome su „Virtual World for Collins Reference“, taikėme judrų metodą, kuris leido pateikti pristatymą per rekordiškai trumpą laiką, bet pasisekė tik todėl, kad du „Collins“ projektų vadovai buvo įsipareigoję šiam reguliariam įsitraukimui ir buvo pasirengę nedelsiant imtis veiksmų sprendimus. Šis metodas netiks visiems projektams ar visiems klientams, tačiau kuo ilgesnis kūrimo laikas ir didesnis biudžetas, tuo jis labiau apsimoka.
