Čím více poznávám programátorských týmů, tím silnější mám pocit, že jen málokdo má nějakou konkrétní představu, co to vlastně ty agilní metodiky jsou. Názory se většinou dělí na dvě skupiny:
- Agilní vývoj nesystematický, neplánováný, takové code & fix (kuriózní je, že přesně proto se některé týmy považují za agilní)
- Nevíme přesně, co to “agile” je, ale je to moderní, tak se k tomu budeme hlásit (prostě další “buzzword”)
Překvapivě mnoho lidí se s jedním z těchto názorů spokojí a vůbec necítí potřebu ověřit si, zda odpovídají realitě. (Pokud patříte mezi ty, kterým agilní vývoj nic neříká, věnujte prosím minutu alespoň hlavním principům (česky)).
Agilní metodiky reagují na časté problémy softwarových projektů a snaží se eliminovat jejich příčiny za pomoci specifických technik a postupů (jako třeba právě iterativní vývoj). Tyto techniky pak zasazují do uceleného rámce – konkrétní metodiky.
Nechci se nyní pouštět do popisu všech rysů agilního vývoje (třeba jeho obrovského důrazu na systematičnost a efektivitu), chci se zaměřit jen na iterace. Nicméně bych na tomto konkrétním příkladu rád demonstroval celkový přístup agilních metodik.
Iterace
Iterativní vývoj je jedním z velmi viditelných rysů agilních metodik, je ale součástí i mnoha jiných metodik. Co to iterativní ale přesně znamená?
Hlavní myšlenka je ta, že na konci každé iterace (jejíž délka je obvykle několik týdnů) dostanete funkční program, který byste mohli dodat zákazníkům (ačkoli fakticky to asi uděláte až tehdy, kdy má dostatek funkcionality). Jinak řečeno, opakovaně vytváříte hotový program, s postupně rostoucí sadou funkcí.
To pomáhá řešit několik častých problémů:
- Neodkládáte část práce na neurčito. Na konci iterace je sice program možná funkčně chudý, ale jeho funkce jsou otestovány, zdokumentovány a akceptovány. Nenabalujete tedy dluh v podobě rizik v neotestovaném kódu, nestane se, že na konci projektu není čas na dokumentaci (a tak dále) a můžete se plně soustředit na novou funkcionalitu.
- Můžete kdykoli změnit směr. Pokud dlouhé měsíce programujete něco, co bylo navrženo před několika dalšími měsíci, dost možná se míjíte se zákazníkovými prioritami. Mnohdy také musíte reagovat na neočekávané problémy se zvolenou technologií, změnami v týmu a tím vším, k čemu běžně na projektech dochází. Při iterativním vývoji prostě zohledníte změněnou situaci při plánování další iterace.
Mimochodem – zhodnocení, co se daří a co nedaří, je další důležitá (a často opomíjená) součást každé iterace. - I když třeba na tým na team buildingu spadne satelit UARS, stále můžete doručit funkční produkt, byť s omezeným množstvím funkcí. Bez iterativního vývoje byste měli jen cosi rozestavěného, co prakticky nemůžete k ničemu použít.
Je to celkem jednoduché, ne? Možná se dokonce ptáte, proč to vůbec vysvětluji. No, podívejme se na některé postupy, považované za iterativní vývoj:
Na konci iterace máme kód, otestujeme a zdokumentujeme ho později.
Jinak řečeno, na konci “iterace” není funkcionalita vůbec dokončena – byl jen napsán nějaký kód, o jehož správnosti a úplnosti se můžeme jen dohadovat, a spoustu práce je nutné ještě udělat. Vlastně se tím nic nevyřešilo – část práce bude možná odložena na neurčito, tým musí zároveň řešit aktuální iteraci a nedodělky z minulé iterace a tak dále.
Když přijde konec iterace, zakomentujeme kód bránící kompilaci a pokračujeme v něm v další iteraci.
To je jen ještě ošklivější varianta předchozího bodu – “iterace” zde není nic víc než nějaký časový úsek. Ale pouhé přiřazením datumů, kdy je kód někam zkopírován, žádnou agilitu pochopitelně nepřináší.
Dělíme projekt na iterace, ale postupujeme podle předem určeného plánu a nezohledňujeme změny priorit
A není to škoda? Proč vyvíjet něco, co někdo kdysi naplánoval, namísto toho, co zákazník potřebuje? Speciálně ERP systémy se musí stále přizpůsobovat potřebám a procesům firmy, ta se musí reagovat na situaci na trhu a sama přicházet s inovacemi… Změny nejsou výjimka, změny jsou nevyhnutelné.
Závěr
Iterace z pohledu agilních metodik zkrátka znamená pravidelně přinášet hotový produkt, s postupně rostoucí sadou funkcí. To pomáhá řešit některé problémy, které se jinak na projektech s železnou pravidelností opakují. Pokud ale “iterace” nenaplňuje zmíněné rysy, nelze očekávat ani takové výsledky.
I jen o samotných iteracích by se dalo napsat ještě mnoho – a mnoho už napsáno bylo. A agilní metodiky se skládají z mnoha dalších dílků. Pokud chcete těžit z výhod agilního přístupu, musíte zejména pochopit, jaké problémy se snaží konkrétní technika řešit a jakým způsobem toho dosahuje. Bez tohoto porozumění se často balí staré procesy do nového hávu (s velkým počtem “správných” slov jako agile, scrum, use case nebo třeba stand-up meeting), ale staré problémy vůbec neřeší.
