Problémy s adopcí agile přístupů

Jelikož čím dál častěji narážím na spoustu dezinterpretací, chybných názorů a různých chytrostí ohledně agile přístupů, rozhodl jsem se napsat tento článek a podělit se tak o své zkušenosti nabyté několikaletou praxí, tj. používáním a zaváděním agile praktik a životního cyklu v projektech vývoje a údržby software. Zmíněné poznámky snad mohou pomoci ostatním při závádění agile praktik a vyvarovat se tak chyb, které již prožili jiní.

Stejně tak jako války a konflikty plynou často z neznalosti, strachu z nového či hájení starých postupů (např. vodopádu) a pravd (ano, země je opravdu kulatá :-), tak i nové přístupy k vývoji software nemají na růžích ustláno, i když jsou podpořeny fakty a argumenty ve formě úspěšných projektů.

K základním lidským stránkám bohužel patří strach z neznámeho (hromy a blesky v dávných dobách) a také rezistence vůči změnám (zřejmé dodnes, či hlavně dnes). Určité typy lidí jen nerady opouštějí zažité postupy, které umí a mohou dále zdokonalovat nebo se naopak již nemusí učit nové věci. Jsou ale také lidé, kterým nevyřešené problémy nenechají spát, rádi se neustále vzdělávají, staví se výzvám. Právě pár takových stálo u zrodu dokumentu zvaného Agile manifesto. Nechci zde o tomto více uvádět, jelikož článků a knih na toto téma už vyšlo opravdu rekordní množství. Pojďme tedy přímo k věci.

Nepravdy o agile

O agile panuje spousta pověstí a nepravd, pár z nich si představíme a vysvětlíme.

1. V agile se nedokumentuje

V agile se nedokumentuje, neexistuje žádná dokumentace, modely, ale pouze kód – není to pravda (je to špatná interpetace principu: working software over comprehensive documentation), modelujeme, dokumentujeme, ale pouze v jiné formě a pouze to, co je nutné. Use case či user stories popisují funkčnost, ale (zde jasné či nepodstatné) detaily jsou zachyceny v unit testech či test casech funkčních. Další dokumentací je samozřejmě dobře strukturovaný a komentovaný zdrojový kód. Modely také existují ale například pouze jako náčrty na tabuli či na papíře. Jelikož jsou běžné krátké releasy, kód se často mění (refaktoruje), stálo by přepracování modelů či jiných dokumentů spoustu úsilí nebo by se tyto staly brzy neaktuální, proto opravdu dokumentujeme jen důležité věci, například architekturu, které se týká další mýtus.

2. Nenavrhujeme žádnou architekturu

Nenavrhujeme žádnou architekturu – je pravdou, že na začátku projektu si nesedneme ke všem požadavkům (protože je ani nemáme) a neřešíme „papírovou architekturu“. V úvodních iteracích ale řešíme určitou kostru aplikace, vrstvy, způsob ukládání dat, komunikaci s ohledem na celé řešení, definujeme rozhraní vrstev, jelikož toto mohou být zásadní technické problémy (např. integrace s bankovním legacy systémem, pravidelné dávkové importy, implementace standardů), které mohou silně ovlivnit celé řešení – použitou technologii, způsob komunikace mezi vrstvami, nutnost prototypů apod. Detailní architekturou se pak zabýváme vždy jen pro danou iteraci (tj. jen pro scénáře které nyní implementujeme), neřešíme architekturu s ohledem na požadavky, které bychom měli implementovat v budoucích iteracích, protože se mohou změnit priority, tyto požadavky se mohou posunout do dalších releasů či úplně zrušit a naše snaha může přijít vniveč. Neděláme tedy architekturu do šuplíku, ale jen pro aktuální potřebu.

3. Jen developeři jsou/mají být agile

Jen developeři jsou/mají být agile, obchodníci a management nemusí být – toto je další z problémů a nepochopení, i když ne tolik zmiňovaný jako ostatní. Jeho dopad je však stejně zásadní. Pokud zákazníkovi řekneme (tedy spíše naši obchodníci), že jsme schopni dodat opravdu všechno, co si vymyslel, za tu cenu, v tom čase a v té kvalitě (což se opravdu často děje), bez ohledu na to, co říká trojúhelník kvality, pak nás samozřejmě ani agile nezachrání. Pokud zákazník nebude chtít spolupracovat, nebude se chtít účastnit pravidelných user play, kde si hraje s dosud vyvinutým řešením, komentuje je a připomínkuje, nelze očekávat úspěch. Musíme zákazníka učit, vysvětlovat, proč je nutné vidět aplikaci a korigovat své i naše představy (viz Wegnerova Lemma říkající, že nejsme schopni kompletně popsat interaktivní systém, náš mozek to prostě neumí), že jen tak dostane opravdu to, co očekával. Je to těžké, protože zákazník byl po léta zvyklý na začátku nadiktovat všechny, tedy i ty nepotřebné požadavky (kterých je podle Standish Group výzkumu více než polovina) a na konci očekával řešení (to už ale víme, že nefunguje), jehož přínos a také kvalita jsou mnohdy diskutabilní.

4. Podpora managementu firmy není třeba

Podpora managementu firmy není třeba, stačí aby mně jako vývojáři řekli: ano, nějak si to teda udělej (rozuměj zaveď agile) – toto je další častou chybou a naivní představou, co je ještě horší, je zavádět agile praktiky a životní cyklus potají. Tajné zavádění či nedostatečná podpora ze strany managementu v podstatě úplně zhatí celou snahu, jelikož bez podpory managementu (který má tuto vizi protlačit) a bez oficiálních prostředků a schválení (vývojáři absolvují tréninky, zpomalí se tempo vývoje) agile přístup ani zavést nelze, jedná se totiž o úplnou změnu chování a myšlení (mind set) všech lidí v organizaci a také o změnu vystupování směrem k zákazníkovi (což potají moc dobře nejde :-). Standish Group ne nadarmo řadí podporu managementu (executive support) na 1. místo svého pravidleného Chaos reportu, který popisuje situaci ohledně projektů v IT. Pro zdůraznění důležitosti této podpory ješte zmíním že na 2. místo odsunul dosud vedoucí angažovanost uživatelů v projektu.

5. Metodika

Agile přístupy jako Scrum, XP, Lean development, OpenUP, RUP (ano i RUP je podle mě agile) apod. jsou metodiky – další omyl, jedná se většinou o procesní frameworky (Scrum, OpenUP, RUP) či sady best practices (Lean development, XP). Metodika přesně říká co, kdy, kdo a jak má dělat. Když nevím co teď, mrknu do knihy na stranu 216,5 a přečtu si to. Procesní frameworky jsou jiné, popisují jen jaké kroky je možné provádět při vývoji software, jaké artefakty mohou zachycovat různé informace, prostě jaké činnosti se v praxi osvědčily. Na nás pak je, abychom si vybrali, co konkrétně nyní potřebujeme, uznáme za vhodné dělat, tj. vytvořili si vlastní proces. Je to pochopitelné, každá organizace je jiná, má jinou strukturu, kulturu, distribuce týmu se různí, členové týmu mají jiné zkušenosti a znalosti, jejich povahové rysy jsou různé, také zákazník se chová jinak. Proto není možné postupovat vždy podle stejné či podobné metodiky, ale je třeba si daný proces vývoje upravit podle potřeb daného projektu (přesně toto doporučují či říkají dané přístupy). Samozřejmě je třeba dodržet a následovat určité zásady a principy. Funguje to stejně jako s bufetem ve formě švédských stolů. Bereme si jen to, co máme rádi (ne všechno – častá dezinterpretace RUPu, že je příliš těžkopádný; nikde však není psáno, že máme dělat vše, co RUP popisuje), s čím máme dobré zkušenosti, sem tam zkusíme něco nového a snažíme se tomu přijít na chuť, ale musíme dodržovat určité zásady. Jídlo dáváme na talíř, většinou jíme příbory, nápoje naléváme do skleniček apod.

Agile a certifikace

Samostatným bodem je problematika certifikací. Certifikace a agile je téma velmi diskutované především v zahraničí. Podle mého názoru nejde agile a certifikace moc dohromady, jelikož jak jsem zmínil již výše, jedná se spíše o způsob myšlení a chování a ne každý je pro to vhodný, čímž chci říct, že agile certifikace neudělá z nevhodného člověka pro tento přístup člověka vhodného (i když se tak samozřejmě může někdy stát). Přínosem takové certifikace je to, že víme, že daný člověk má o daném přístupu alespoň povědomí. Agile je tedy o způsobu myšlení a pracování lidí, ne o tom, jestli sedím na kurzu, za který dostanu certifikát. Agile myšlení se projevuje tak, že dělám jen to co je nutné, přínosné (modelování, tvorba mezidokumentů, modelů, …), aby tyto kroky vedly k cíli, jímž je spustitelný kód bez chyb, který přináší zákazníkovi hodnotu.

Jen na doplnění, měl jsem tu možnost absolvovat ScrumMaster training od Borise Glogera (Sprint-iT GmbH) a moc mě neuspokojil. Boris nedokázal odpovídat na naše otázky ohledně věcí chybějících ve Scrumu (risk management, zaměření na architekturu v úvodu), ohledně připomínek týkajících se user stories vs. use cases a místo argumentů říkal: you must trust me! Nakonec nás dostal, když začal mluvit o RUPu jako o vodopádu či příliš komplexní metodice (běžné dezinterpetace pramenící z neznalosti).

Problémy Scrumu

Jelikož velmi moderním agile přístupem se v dnešní době stal Scrum, chtěl bych upozornit na pár problémů, které mohou způsobit problém s jeho implementací. Scrum se totiž stal daším „buzzword“. Všichni o něm mluví, jedou podle něho, ale nikdo pořádně neví nebo si neuvědomuje problémy, které může způsobit. Samozřejmě je nutné zmínit, že Scrum pomůže odkrýt problémy, má výborné praktiky jako denní meetingy, self-managed a cross-functional týmy. Scrum samotný však nestačí.

1. Scrum je pouze metodou pro řízení projektů, vůbec nepopisuje inženýrské praktiky, které jsou při vývoji software kritické, tj. jak ten software vlastně dělat. Proto Scrum tak dobře funguje v kombinaci s XP (protože to jsou zase téměř jen inženýrské praktiky) a proto implementace samotného Scrumu vede téměř vždy ke stejným problemům.
2. Scrum není řízen riziky (risk-driven), nemluví o nich explicitně, proto se může stát, že nás v průběhu vývoje překvapí zásadní věc, která může zhatit celý projekt.
3. Scrum není orientován na architekturu, čímž nemyslím vodopádové tvoření šílené architektury dopředu, ale vyřešení základních struktur, definic rozhraní, jak bylo popsáno výše.
4. User stories vs. use cases – problémem je možná ztráta souvislostí a vazeb při jejich použití (porovnejte s UC a jejich scénáři).

Závěrem

Na závěr tedy můžeme říct, že agile je hlavně o lidech a jejich spolupráci. Většina technik je sice lightweight (např. user stories, modelování), ale některé jsou naopak docela náročné na discilínu, např. Test-first přístup. Zásadní pro implementaci těchto přístupů je myšlení a závazek, disciplína (ve smyslu anglického commitment) lidí. Procesním frameworkem, který staví na dobrých věcech v agile a přidává další ověřené je OpenUp (http://www.eclipse.org/epf/). Open Up může být pro většinu týmů dobrým startovním krokem, pokud si opět uvědomíme, že je třeba svůj proces vývoje nejdříve z daného frameworku vytvořit.