Pēdējā laikā arvien biežāk sastopam iepirkumu dokumentus, kuros kā obligāta prasība ir norādīts, ka projekts jāīsteno, izmantojot Scrum. Taču, iedziļinoties detaļās, bieži atklājas pavisam cita aina:
projekts ieplānots uz aptuveni 12 mēnešiem, sprintu plāns detalizēti jādefinē jau projekta sākumā, Product Owner loma nav paredzēta, bet progresa sapulces notiek reizi mēnesī.
Tas rada loģisku jautājumu: vai tas tiešām ir Scrum, vai tomēr tas, ko mēdz dēvēt par “Waterfall sprintos”?
Kāpēc “Waterfall sprintos” bieži neizdodas
Balstoties uz mūsu pieredzi, šāda pieeja bieži noved pie projekta problēmām. Lūk, galvenie iemesli.
1. Zema elastība
Kad projekts ir uzsākts un iesaistītās puses sāk iedziļināties detaļās, ātri kļūst skaidrs, ka ne visu ir iespējams paredzēt sākotnējā plānošanas posmā. Izmaiņas ir neizbēgamas, taču stingri definēta sprintu struktūra padara pielāgošanos sarežģītu un laikietilpīgu.
Tas ir pretrunā vienai no Agile pamatvērtībām, darbojošs risinājums ir svarīgāks par pārmērīgu dokumentāciju.
2. Lēna reakcija uz izmaiņām
Waterfall pieeja pēc būtības slikti pielāgojas mainīgām prasībām un prioritātēm. Pat ja Waterfall tiek “iespiests” sprintu rāmjos, izmaiņu ieviešana projekta gaitā kļūst smagnēja, kas rada neefektivitāti un risku neatbilst reālajām biznesa vajadzībām.
3. Novēlota atgriezeniskā saite
Waterfall projektos atgriezeniskā saite nereti tiek saņemta tikai posma beigās. Ja tas notiek arī sprintu kontekstā, tiek zaudēta iteratīvās pieejas būtība, ātri pielāgoties, laicīgi pamanīt riskus un koriģēt virzienu. Bez regulāras iesaistīto pušu atgriezeniskās saites projekta progress cieš.
Kāpēc hibrīdie modeļi bieži nestrādā
Mēģinot ieviest Agile tradicionāli Waterfall vadītās organizācijās, hibrīdie modeļi nereti cieš no nepietiekamas izpratnes par Agile principiem. Panākumi slēpjas ne tikai procesu ieviešanā, bet arī domāšanas maiņā, prioritāšu pārvaldībā un izpratnē par to, kad kura metodoloģija ir piemērota.
Kas patiesībā strādā
Izglītot iesaistītās puses par Agile ieguvumiem
Daudzas problēmas rodas no gaidām par fiksētu apjomu, budžetu un termiņiem. Agile piedāvā agrāku vērtības piegādi, elastību un labāku saskaņu ar reālajām biznesa vajadzībām.
Pareiza backlog prioritizēšana
Labi sakopts un prioritizēts produkta backlog ir kritiski svarīgs. Tikai augstākās vērtības uzdevumi nonāk sprintos. Šeit būtiska ir Product Owner loma, kas palīdz fokusēties uz to, kas patiesi rada biznesa vērtību.
Waterfall tikai stratēģiskajos posmos
Waterfall var būt lietderīgs sākotnējā plānošanā, prasību apkopošanā vai arhitektūras definēšanā. Taču pēc tam ieteicams pilnībā pāriet uz Agile iteratīvu izstrādi un piegādi.
Pareizi sabalansējot Agile un Waterfall pieejas un nodrošinot, ka iesaistītās puses izprot īstos Agile principus, projekti var izvairīties no “Waterfall sprintos” riskiem. Veiksmes atslēga ir elastība, regulāra atgriezeniskā saite un vērtības piegāde nelielos, pārskatāmos soļos.
Latvia Technologies (ltech.lv) vērtības ir cieši saistītas ar Agile domāšanu, regulāra sadarbība, ātra pielāgošanās tirgus izmaiņām un darbojošs risinājums kā galvenā prioritāte, nevis apjomīga dokumentācija. Ja vēlies uzzināt vairāk par to, kā mēs vadām projektus praksē, aicinām iepazīties ar mums, sazinoties.
