Patrně každý programátor projde při svém vývoji obdobím, které bych si dovolil nazvat "hurá styl". Je to doba, kdy je v podstatě ještě bez zkušeností, má za sebou pouze několik pokusů hello world, ale již si plně uvědomuje, jakou mu dávají programovací jazyky moc. Od počátečního "ono to skutečně něco dělá" se dostává procesem pokusů a omylů k pozdějšímu "ono to skutečně dělá to, co chci". Programátor nabírá nové zkušenosti, ale když před ním stojí první velký, skutečný a opravdový projekt, uvědomí si, že pokud chce pracovat efektivně, již si dále se zmíněným "hurá stylem" nevystačí. Uvědomí si, že není možné jen tak na sebe vrstvit různé proměnné, funkce, třídy,... Uvědomí si, že je potřeba mít systém. Tedy abych byl přesný, tohle všechno si uvědomí pouze v tom lepším případě; v tom horším si to neuvědomí a jistě mi dají mnozí za pravdu, že pozdější spolupráce s takovým programátorem je utrpení.

               Metodologie programování jsou vlastně různé pokusy změnit chaos okolo vývoje softwaru v řád. Vývoj se samozřejmě neskládá jenom z vlastního programování, jeho další důležité složky jsou i analýza, testování a konečná integrace. V průběhu let se samozřejmě objevilo mnoho různých systémů, metodologií. Každá z nich kladla na různé části vývoje jiný důraz, některé se osvědčily více, jiné méně či vůbec. Během posledních několika let se dostávají do popředí právě agilní metodologie. Je to soubor metodik, které pomáhají vývojářům při řešení otázky, jak co nejefektivněji uspokojit potřeby zákazníků. Tedy, jak co nejrychleji vyvíjet software tak, aby odpovídal požadavkům zadavatele, aby splňoval všechny vytyčené cíle, aby bylo možné ho rychle nasadit (implementovat), a aby se dal později lehce udržovat. To vše aniž by zákazník musel slevit z požadované vysoké kvality, či počtu a záběru funkcí vyvíjeného softwaru. Současný zákazník totiž kromě vysoké kvality vyžaduje i vysokou rychlost vývoje, samozřejmě za co nejnižší ceny. Konkurenční prostředí tedy nutí vývojáře softwaru hledat nové cesty, jak efektivně (rychle a levně) vyvíjet. To byl právě jeden z hlavních podnětů, proč byl v polovině února 2001 vytvořen Manifest agilního vývoje softwaru (Manifesto for Agile Software Development, The Agile Manifesto). Spolu s tímto manifestem byla založena Aliance pro agilní vývoj softwaru (The Agile Alliance). U jejího počátku stálo sedmnáct programátorů z různých končin světa, kteří do té doby vyznávali různé postupy vývoje softwaru. Během víkendu se shodli na třinácti bodech manifestu a představili tak vývojářské veřejnosti svůj inovativní, do značné míry netradiční, přístup k vývoji softwaru. Myslím, že je jasné, že ne všechny myšlenky jsou zcela nové a původní, to ostatně ani nebylo cílem při tvorbě manifestu. Jen jsou použity v nové souvislosti.

               Některé myšlenky agilních metodologií do jisté míry zcela popírají klasické poučky softwarových inženýrů. Pro někoho zcela nepředstavitelně snižují význam analýzy či hodnotu dokumentace. Naopak staví do popředí rychlost vývoje, komunikaci uvnitř týmu i mezi týmem a zákazníkem a možnosti a schopnosti reagovat na změny (které mohou vycházet z nových potřeb zákazníka či mohou být způsobené různými nepředvídatelnými událostmi). Jakým způsobem se agilní přístupy snaží urychlit vývoj? Zejména zkracují dobu jednotlivých cyklů návrh-implementace-test-oprava a zároveň zvyšují počet těchto cyklů. V praxi se tedy do softwaru velmi často přidávají jednotlivé funkce, na rozdíl od klasického postupu, kdy se méně často přidávají velké komplexní části. To umožňuje zákazníkovi pružně reagovat na tyto nově přidané funkce, například žádostmi o úpravu stávajících či na přidání nových, v dřívějším zadání nezmíněných. Také může snadno (na rozdíl od klasického přístupu) měnit prioritu zapracování jednotlivých funkcí. Navíc zákazník může průběžně sledovat postup vývoje a jasně vidí, že se na projektu pracuje. To mu kromě zmíněné možnosti rychle reagovat přináší i vynikající možnost kontroly, jasně vidí, za co vydává peníze po většinu doby vývoje. To je myslím, pro něho mnohem výhodnější, než když první funkční výsledek vidí třeba až po roce vývoje. Je zřejmé, že zákazník je, na rozdíl od klasického postupu, více vtažen do procesu vývoje, spolupracuje na návrhu či sám provádí některé testy. Právě proto agilní metodologie tolik vyzdvihují nutnost komunikaci mezi vývojovým týmem a zákazníkem. Doporučují pravidelné schůzky mezi vývojáři a zákazníky, které mohou zamezit různým nejasnostem v zadání či podkladech a zároveň posouvají vývoj dopředu. Stejně důležitá je nutnost otevřené komunikace uvnitř týmu, kde kromě klasických vnitrofiremních porad, nabývá na významu například párové programování a několikanásobná refaktorizace kódu (úprava kódu bez změny funkčnosti). Protože nové verze vyvíjeného projektu se mohou objevovat třeba každý den, je nutné průběžné testování, stále častěji se používají automatizované testy, které se mohou snadno často opakovat. Většina z agilních metodologií doporučuje, aby tyto testy byly napsány dříve než kód, který mají testovat. Tak se spíše zajistí to, že skutečně budou testovat funkčnost podle zadání projektu a ne podle samotné implementace, která může být formálně správná, ale nemusí přesně vyhovovat zadání.

               A proč se snižuje význam dokumentace? Agilní metodologie nám říkají, že nejzákladnější a zcela jednoznačnou dokumentací je samotný zdrojový kód. To, myslím, na druhou stranu nutně zvyšuje pozornost, kterou je nutné věnovat jeho tvorbě. Je nutné mnohem více při jeho tvorbě dbát na tzv. štábní kulturu i na různá vnější doporučení a normy. Vzhledem k jinému způsobu vývoje, je totiž mnohem více pravděpodobné, že se k již napsanému kódu bude jeho autor či jiný vývojář později vracet a budou ho chtít rychle pochopit a jednoduše modifikovat. Snižuje se i doba věnovaná komplexní analýze projektu. Důvod je jasný, současní zákazníci netouží po přehršli materiálu, který k nim putuje od vývojářů při využití klasických postupů. Objektové návrhy ani struktury databází jim nic neřeknou, nemají pro ně žádný smysl a hlavně žádný užitek. Ten jim přinese až funkční software, který potřebují a očekávají v krátkém časovém horizontu. Proto agilní metodologie doporučují či přímo vynucují zkrácení iterací, zvýšení počtu cyklů, soustředění se na aktuálně řešené funkce a dočasné zapomenutí funkcí, které se budou implementovat někdy v budoucnu a jejich zadání se tedy pravděpodobně ještě bude měnit. Aby nedošlo k nedorozumění - agilní metodologie nezatracují návrh, naopak zdůrazňují nutnost jeho kvality. Ale neberou ho jako etapu, kterou je nutno dokončit před zahájením samotného programování. Jak vyplývá z agilních přístupů, počítá se s jeho průběžnou úpravou, protože požadavky na změny přicházejí právě během implementace softwaru. Změny návrhu jsou tedy zcela přirozené a neznamenají jeho špatnou kvalitu, ale spíše naznačují dobrou úroveň komunikace mezi vývojovým týmem a zákazníkem. Práce na návrhu je tedy pro programátory stejně každodenním jevem jako programování samotné. Agilní metodologie reflektují také další změnu v chování zákazníků. Ti si stále více uvědomují, že často platí za funkce, o kterých se domnívali, že pro ně budou potřebné, ale po integraci se v praxi ukázalo, že je vůbec nevyužívají a jsou pro ně zbytečné. Proto v současnosti chtějí spíše méně funkcí, které budou ihned využívat intenzivně. Tudíž agilní přístupy se zaměřují na jednoduchost v návrhu i v implementaci, většina programátorů z vlastní zkušenosti ví, že je snazší k jednoduchému základu v budoucnu přidávat než z komplexních všeobjímajících postupů něco odebírat. A navíc i v programování platí, že v jednoduchosti je síla.

               Agilní metodologie tedy dávají jasně najevo, že pro vývojáře (a vlastně i pro zákazníka) není prvotní zadání projektu žádným "zákonem", tedy neměnitelným dokumentem. Právě naopak, během vývoje je zákazníkovi umožněno, zadání měnit, modifikovat a doplňovat. Ba co víc, je to vlastně žádoucí. Naproti tomu je před začátkem vývoje přesně definovaná jeho délka v čase a množství zdrojů (tedy zejména částka, kterou zákazník zaplatí). Čas a zdroje se během vývoje nemění. Je to tedy přesně naopak než u klasických přístupů, kdy je pevně stanoveno zadání projektu a mění se čas a zdroje potřebné k jeho dokončení. Je myslím jasné, že v drtivé převaze případů dochází k prodražení a odkladům dokončení.

               Agilní přístupy k vývoji softwaru se zatím používají ve větší míře u nekomerčních, často open-source projektů. U celé řady programů dávají vývojáři k dispozici kromě stabilních verzí, které jsou (měly by být) řádně otestované a plně podporované, i verze vývojové, které se často mění každý den (tzv. "night build" - překládáno většinou jako "noční sestavení programu"). U většiny těchto projektů není v podstatě žádný zákazník či zadavatel. Ten je nahrazen komunitou uživatelů, kteří průběžně reagují na změny v programu, používají (tedy vlastně testují) nově přidané funkce, hlásí jejich problémy či chyby, stejně tak zjišťují jestli byly vhodně opraveny chyby již známé. Kromě toho samozřejmě tvůrcům předávají nové požadavky na další funkce. Není ničím výjimečným, že členové mnoha takových vývojových týmů žijí na různých místech a nikdy se navzájem osobně nesetkali. Domnívám se, že je zřejmé, že to podporuje požadavek agilních metodologií na kvalitu kódu ve smyslu jeho pozdější čitelnosti. To samozřejmě klade vyšší nároky na osobu programátora. Ovšem pokud si takové návyky osvojí, vrátí se mu v budoucnu v podobě úspory času. A čas, jak známo, jsou peníze.

               Jestli se agilní přístupy prosadí v budoucnu, ukáže až čas. Je jasné, že pro některé typy projektů zůstávají i nadále výhodnější klasické přístupy a postupy vývoje. Ale pro projekty, u kterých například není možné z jakýchkoliv příčin na počátku přesně a definitivně formulovat zadání, nám agilní metodologie nabízí zajímavé alternativy vývoje. Každý má na výběr, zda zůstane u klasického přístupu, či vyzkouší některou z konkrétních metodologií založenou na agilních principech. A jestliže vyzkouší, pak se musí rozhodnout, co mu více vyhovuje a co mu umožňuje efektivnější práci. Stále více programátorů nalézá výhody, které jim nabízí například extrémní programování (extreme programming, XP) nebo adaptivní vývoj (adaptive software development). Další se přiklání kupříkladu k vlastnostmi řízenému programování (feature-driven development, FDD). V každém případě si myslím, že, vzhledem k rychlosti jakou se agilní přístupy šíří a rozšiřují, neupadnou tyto metodologie v zapomnění a nejspíše budou v budoucnu stát vedle klasických RUP (Rational unified process) postupů, protože každý z nich má své klady i zápory a tak jsou různě vhodné pro různé typy projektů.