Iteratīvā pieeja projektu vadībā un produktu izstrādē pret tradicionālo waterfall metodi. Katrai no metodēm noteikti ir sava vieta un savs laiks, bet lai būtu skaidrība, ko tas nozīmē, apskatīsim abas metodes un veiksim nelielu salīdzinājumu.
Tradicionālajā (kaskādes/waterfall) projektu vadības metodē izstrāde tiek organizēta secīgi, definējot izstrādājamo produktu, projektējot risinājumu, veicot produkta izstrādi, testēšanu un rezultātā – produkta piegādi klientam, jeb nododot ekspluatācijā radīto produktu.
Izmantojot Agile pieeju (iteratīvā pieeja), produkta izstrāde tiek veikta iteratīvi, jeb sadalīta posmos, kur katra posma beigās ir gatavs potenciāli piegādājams inkrements, jeb strādājoša un vērtību nesoša programmatūra klientam.
Tradicionālā (Waterfall) metode:
- Darba apjoms tiek fiksēts izstrādes sākumā;
- Risinājums tiek detalizēti analizēts un nofiksēts;
- Projektu vada projekta vadītājs;
- Pavēles un kontroles sistēma;
- Visi izstrādes darbi ir fiksēti un veicami pēc līguma.
Iteratīvā (Agile) metode:
- Darba apjoms ir mainīgs;
- Risinājums tiek attīstīts projekta izstrādes laikā;
- Pašorganizētas komandas;
- Uz sadarbību vērsts modelis;
- Darbiem tiek noteikta prioritāte un visi definētie darbi nav obligāti jāizstrādā, lai pabeigtu projektu.
Atkarībā no izvēlētās projektu vadības metodes, var paskatīties uz dažādām no tā izrietošām likumsakarībām, kas jāņem vērā vienā vai otrā gadījumā:
Tradicionālās projektu vadības gadījumā caurskatāmība par izstrādāto produktu ir augsta tikai produkta izstrādes sākuma posmā (un tā var būt maldīga, ja definētās prasības tiek interpretētas dažādi), kā arī beigu posmā, kad tiek piegādāts izstrādātais produkts. Savukārt Agile izstrādes gadījumā, pateicoties inkrementālai izstrādes pieejai, tiek nodrošināta caurskatāmība visā projekta izstrādes gaitā.
Pielāgojamības iespējas Agile izstrādes gadījumā ir ļoti augstas visā izstrādes gaitā, savukārt tradicionālās metodes gadījumā jāņem vērā, ka produkta pielāgojamība var būt ļoti dārga vai pat neiespējama tehnisku risinājumu dēļ. Līdz ar to arī projekta izgāšanās risks ir ļoti augsts, ja klients neakceptē izstrādāto risinājumu projekta beigās.
Kā jau minēts iepriekš – risks tradicionālajā projektu izstrādes metodē saglabājas ļoti augsts visu izstrādes posmu, līdz gala produkts ir nodots un akceptēts, jo pastāv liela varbūtība, ka kāda no prasībām ir saprasta atšķirīgi (pasūtītāja pusē un izstrādātāja). Agile gadījumā visā projekta izstrādes laikā tiek saņemta atgriezeniskā saite no klienta, tāpēc risks ir būtiski zemāks. Ir iespējams, ka kāds no posmiem netiek pieņemts, taču tas uzreiz tiek labots.
Agile izstrādes gadījumā vērtību nesošs produkts klientam tiek piegādāts jau ļoti agrā izstrādes posmā. Agile pieeja paredz, ka katrs izstrādes posms sniedz vērtību produktam un ši vērtība ir jau lietojama gala lietotājam (iesākumā ar minimālu funkcionalitāti). Savukārt tradicionālās izstrādes gadījumā visu izstrādes posmu produkts atrodas pie izstrādātāja un tikai pēc izstrādes beigām tas ir piegādājams klientam, kas nozīmē, ka nekādu vērtību biznesam tas nerada, kamēr netiek piegādāts.