 |
Podpora řízení | Školení | Analýzy | Vývoj Software | Standardy | O nás |
Fenomén agilního programování, metodik a řízení projektů hýbe myslí i emocemi IT lidí již řadu let. Jak už to tak bývá, k otázce se zasvěceně vyjadřuje více lidí, než kolik jich věci skutečně rozumí.
Předně bychom měli předeslat, že s agilním řízením vývoje software máme dobré zkušenosti. Tímto způsobem u nás proběhl vývoj softwarové aplikace ze skupiny tzv ?mission-critical?, tj aplikací, na jejichž běhu závisí chod businessu a firmy. Nešlo o Real-Time, který by řídil technologie, ale provozní systém (tzv. OSS ? Operational System Support), bez něhož by se firma neobešla a jehož výpadek znamenal, že firma jako celek stála a nic nedělala.
Druhým pozitivním příkladem je vlastní produkt, který nejenom, že vznikl v rámci projektu řízeného v souladu s manifestem agilního programování, ale jehož záměrem je umožnit využití principu agilního řízení i pří řízení firemních procesů a organizace práce.
Navzdory vlastním pozitivním zkušenostem považujeme agilní metodiky za vhodné pouze pro poměrně omezenou skupinu projektů. Agilní metodiky jsou vhodné tam, kde celý projekt svou organizací a vztahy mezi všemi účastníky splňuje pravidla, která manifest agilního vývoje obsahuje. Pokud je projekt ve svých kořenech - a těmi jsou zejména smluvní vztahy a tým - nesplňuje, nemůže agilní přístup fungovat. Jeho prosazování pak úspěšnost projektu ohrožuje ještě více, než trvání na "zastaralém" vodopádovém modelu.
V následujících odstavcích se podrobněji díváme na problémové zásady agilního vývoje. Všechny zásady jsou uvedeny v již zmíněném manifestu.
Na první i druhé přečtení jde o zásadu zcela nespornou. Zákazník skutečně chce především kvalitní a funkční software, mnozí zákazníci se dokonce o dokumentaci nezajímají vůbec. A to ani při předávání ani později. Zato se téměř všichni zajímají o udržovatelnost, možnost úprav a rozvoje software. A každá firma, která se o software několik let starala, potvrdí, že s přibývajícím věkem aplikace je její dokumentace stále důležitější. Mnoho aplikací končí svůj život ne proto, že by nefungovaly, ale protože už nikdo neví, jak fungují, takže je nikdo není schopen opravit.
Abychom byli spravedliví, hodí se poznamenat, že agilní metodiky nebrání tvorbě dokumentace. Jenom jí dávají menší prioritu, než samotné aplikaci. V praxi si ovšem naprostá většina týmů toto pravidlo vyloží tak, že dokumentace je druhořadá, tedy podružná potažmo nepodstatná.
Většině z nás, kdo někdy odpovídal za tým v softwarové firmě, se nad těmito zásadami zvedají vlasy na hlavě. Mnoha vývojářům jsou skutečně smlouvy a plány ?ukradené?, ale jejich odměny a prémie jim ukradené nejsou a pokud jsou, tak se čertí. Nebozí manažeři (zejména finanční a projektový) musí mezi těmito protichůdnými požadavky projekt vést.
Uvedené zásady jsou ve skutečnosti klíčové pro rozhodování, jestli projekt může nebo nemůže využívat agilní metodiku. Pokud je smlouva nastavena tak, že vývojáři mohou dávat požadavkům na změnu přednost před dodržováním plánu a nemusí se starat o termíny, objem práce a různá penále, mohou využít všech výhod agilního programování. Mnoho smluv je skutečně koncipovaných tak, že tuto svobodu dávají - fakturace podle opracovaných hodin, dílčí objednávky na jednotlivé Springy (pardon, etapy) nebo dokonce interní vývojový tým zodpovědný jenom vedení firmy a sám sobě jsou většinou prostředím, které agilní přístup umožňuje a přímo k němu vybízí. Většina softwarových firem ovšem nemá tak svobodomyslné zákazníky, takže si luxus přehlížení smluvních závazků nemohou dovolit. A v tu chvíli přestávají být základní principy agilního použitelné.
Manifest agilní metodiky kromě základních principů definuje i 12 principů, které svou podstatou směřují k naplnění samotného manifestu. Řada z těchto principů je pro softwarovou firmu vyvíjející produkty a řešení pro zákazníka podobně kontroverzní, jako samotný manifest.
Předpoklad platil v době překotného technologického boomu a rychlé obměny technologií. Pokud tým vyvíjí software z kategorie ?spotřebního zboží? (rozuměj: použij a zahoď), může se touto logikou skutečně řídit. Obzvláště v době recese ale firmy hledí na celkovou užitnou hodnotu software a pak se spíš než na rychlost dodávky ptají, kolik užitku jim skutečně přinese. A při 7 a více letech plánovaného používání systému už nějaký ten měsíc zdržení při nasazování není tak rozhodující. Zato potřeba trvalých dodávek oprav a úprav dokáže s TCO (celkovou cenou) pořádně zamávat.
Trvale udržitelný vývoj a krátké intervaly nasazování jsou ideální pro vývojový tým, ale jen zřídkakdy pro zákazníka. Zvláště koncoví uživatelé spěchají na novou dodávku zpravidla jen tehdy, když ta předchozí byla tak nekvalitní, že toužebně očekávají odstranění velkých závad. Jinak uživatelé preferují stabilitu a ne časté změny.
Žádný sponzor nejásá nad proklamací, že projekt nemá konec. Naopak ho chce vidět, a to co nejdříve.
Požadavek na trvalou spoluprácí vzešel ze strany programátorů, business lidí se na jejich názor nikdo neptal. Většinou se jich nikdo neptá ani při začátku skutečného projektu. Blízká součinnost je samozřejmě výborná, a pokud je pro ni prostor a schopnosti, nelze než ji doporučit. Jsou však dva základní důvody, proč to většinou selhává:
Uplatnění tohoto principu většinou způsobí, že do projektu jsou z businessu nominování (nej)méně schopní jedinci nebo nováčci, kteří nemohou podat dostatečně kvalitní přehled přes business. Výsledkem je, že hotové dílo pak zkušené pracovníky spíše děsí. A dodavatel? Ten přece dodal, co business žádal.
Princip jednoduchosti je dobrý v případě, že můžete kdykoli provést refaktoring a jednoduché řešení upravit. Ještě ale nikdo nevymyslel refaktoring databázového schématu, který by se následně promítl do všech sestav, interface a navazujících modulů (např. datových pump).
Přístup ?skočme do práce rovnýma nohama? je použitelný opravdu jen tam, kde tým od začátku vidí na konec cesty a může si být jist, že jednoduché řešení mu následně nezlomí vaz. Jiná zásada dovoluje, že kdykoli během vývoje mohu přijmout změnový požadavek a jednoduché řešení zcela předělat.
Princip jednoduchosti vyžaduje splnění jiného již zmíněného principu, a totiž otevřený konec a neomezené možnosti předělávání.
Horst Rittel v polovině devadesátých let prohlásil, že vodopádový model vývoje software selhal, protože v sobě ukrýval příliš velké zjednodušení pohledu na software. Inženýři se snažili na software dívat jako na jednoduchou věc, kterou popíší a pak s ní budou pracovat, ale software je příliš složitý, než aby se dal v úvodu uchopit. Agilní programování zvolilo druhý extrém, kdy se o uchopení celku vůbec nesnaží a razí cestu postupného přibližování s vírou, že přístup bude konvergentní. Přiznává, že není možné říct, jak dlouho bude "přibližování" trvat a kolik bude stát. Pokud tyto limity nevadí, tomu bude agilní přístup vyhovovat.
V úvodu jsme zmínili, že sami máme s agilním přístupem dobré zkušenosti. Skutečně je nemálo projektů, kde se agilní přístup uplatnit dá a je efektivní. Již bylo zmíněno, že řada zákazníků nastavuje smlouvy na dodávky tak, že agilní přístup umožňují. Pokud se takto nastavený vztah potká s motivovaným a schopným týmem (mimochodem, také explicitní požadavek manifestu), spolupráce je velmi efektivní. Stejně tak interní vývoj produktu, pokud není dušen stresem termínů a nedostatečných kapacit, je produktivní a nejefektivnější právě při agilní formě vývoje. Ovšem v okamžiku, když vedení firmy začne klást termíny a omezovat zdroje, celý princip agilního programování se hroutí.