Méně práce s řízením organizace

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í.

Vlastní zkušenost

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.

Nebezpečné zásady agilního vývoje

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.

Funkční software je důležitější než vyčerpávající dokumentace

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á.

Spolupráce s klientem má přednost před domlouváním smluv

Reagovat na změny je důležitější než dodržování plánu

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 lhostejné, 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é.

12 principů agilního vývoje

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.

Nejvyšší hodnotu je uspokojit zákazníka rychlými a trvalými dodávkami kvalitního software

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.

Dodávat funkční software často, v intervalech týdnů až měsíců a se snahou o kratší intervaly mezi dodávkami

Agilní procesy propagují udržitelný vývoj. Sponzoři, vývojáři i uživatel musí být schopni dodržovat stálý výkon neomezeně, dokud je třeba, tj. bez stanoveného konce

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.

Lidé z businessu a vývojáři musí na projektu denně spolupracovat

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á:

  1. Lidé z businessu nemají čas. Obzvlášť ne ti schopní, kteří mohou pomoci nejlépe.
  2. Mnoho programátorů nemá schopnosti business analytiků, takže jejich komunikace s businessem je velmi neefektivní a často vede ke špatným výsledkům.

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.

Jednoduchost - umění co nejvíce práce vůbec nedělat - je nezbytná

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í.

Agilně ano či ne?

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í.

PDQM, s.r. o.   1997-2007-2015   Podmínky užití stránek

Hlavní stránka

O firmě

Blog

Dotazy a odpovědi

Manifest agilního programování

Blog projektového řízení

Return to main page www.pdqm.cz Podpora řízení Školení Analýzy Vývoj Software Standardy O nás

Telefon: +420 605 203 938

Email:

Kontakt