17.06.2010

Problémy a 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, mockupech či v klikatelných prototypech, které sloužily k vyjasnění potřeby a chování funkčnosti. 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ší typický 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 (tolik) 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 a samozřejmě třeba pro podobnou věc, která má přijít v příštím 1-2 sprintech. Ty se asi nezruší a vyplatí se udělat něco navíc, než pak velký kus kódu refaktorovat. Ale jak moc, vždy záleží na konkrétním kontextu.

3. Neexistuje žádný plán

A co vlastně tedy vyvíjíte, když tedy nemáte žádný plán? To denně reaktivně reagujete na zmínky od zákazníků tak, že jeden týden přidáte novou feature (když někomu chybí) a další týden ji odstraňujete (když někdo křičí že je zbytečná a jen produkt komplikuje)?? A co komunikují vaši obchodníci, když jedou k zákazníkům? Jak odpovídají na otázky, co bude v další verzi produktu? A co jiného je produktový backlog, než plán, výhled na následující období? Pravdou tedy je, že plán v Agile samozřejmě existuje, jen opět v jiné formě – ve formě backlogu – a úroveň detailu se také s výhledem dál a dál do budoucna mění z konkrétních user stories na epics a dále na ideas a třeba i jen pouhé „mohli bysme také udělat …“.

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

Agilní transformace znamená celofiremní změnu, nejen změnu IT. Dopad neagilní části firmy je často na priority a způsobuje vyrušování vývoje. Pokud není zbytek firmy agilní, dost těžko se agilní IT na tento zbytek napojuje. Příliš mnoho rozpracovaných věcí, předávky z/do jiných oddělení, to vše bude způsobovat problémy hlavně vývoji a lidem v týmech, kde se tyto symptomy sejdou a dopadnou na lidi.

5.  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í (mindset) 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.

6.  Metodika a proces vývoje SW

Agile přístupy jako Scrum, XP, Lean development, OpenUP, RUP (ano i RUP je 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, mnohdy s nutným základním jádrem (např Scrum). 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 a nebo implementovat jádro frameworku. 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, to si zase vymyslel někdo kdo nepochopil principy RUP), 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 aktuálně nutné a přínosné (modelování, tvorba mezidokumentů, modelů, …), aby tyto kroky vedly efektivně k cíli, jímž je doručená hodnota pro zákazníka (ano, často ve formě spustitelného kódu bez chyb). Ale ten kód, ten produkt zákazníka moc nezajímá, on chce vykonat efektivně svoji činnost a software mu v tom jen pomáhá.

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 a nepochopení RUP).

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í, zdánlivě podle něho jedou, ale nikdo pořádně neví o čem přesně je nebo si neuvědomuje možné problémy a dopady, které může tato neznalost způsobit. Samozřejmě je nutné zmínit, že vhodná implementace Scrum ve vhodném kontextu pomůže extrémně pomoci a může odkrýt a pomoci vyřešit základní problémy. Scrum může být také jen studnice praktik jako jsou denní meetingy, jediný zásobník práce, retrospektivy, self-managed a cross-functional týmy. Scrum samotný však mnohdy nestačí a zde je právě největší problém. Všichni ho berou kvůli jeho jednoduchosti jako všelék, ale on jím není a ani nikdy nechtěl být.

1.  Scrum je primárně metodou pro řízení (softwarových) projektů, vůbec nepopisuje inženýrské praktiky, které jsou při vývoji software kritické, tj. jak ten software vlastně popsat, analyzovat, navrhnout, napsat, otestovat, releasovat. 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 méně zkušenými týmy vede téměř vždy ke stejným problemům.

2.  Scrum není implicitně řízen riziky (risk-driven), nemluví o nich nahlas, jen je to jaksi zmíněno mezi řečí, že rizika spoluutváří prioritu story v backlogu, ale hlavní je byznys hodnota. 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, ale kdybychom od startu řešili nejrizikovější věci, mohli jsme tomu předejít.

3.  Scrum není orientován na architekturu, čímž nemyslím vodopádové tvoření šílené a navíc papírové architektury dopředu, ale vyřešení základních struktur, definic rozhraní, jak bylo popsáno výše. Což je samozřejmě záměrné (viz bod 1), ale proto se stává, že nezkušené týmy architekturu prostě přeskočí, neřeší a vznikne moloch.

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), což nemusí být problém u běžných produktů, ale u složitějších systémů bank a telco operátorů s více týmy na částech produktu to může způsobit velké problémy.

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 nebo self-managed týmy. 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. 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.

Máte k tomu co říct?

0 komentáře: “Problémy a adopcí agile přístupů”

  1. Máte nějaké tipy čeho se vyvarovat při psaní USER STORY? Nebo naopak jak je nejlépe psát, aby se z nich neztratilo to co máme v Use Case?

    Díky.
    Robert

  2. Dobry den,

    moznych problemu s US, tak jak jsem se s nimi setkal ja, je nekolik.
    1/ predne je treba opakovane zduraznovat, ze US je pouze pozvanka ke komunikaci. Neni to nahrada diskuse se zakaznikem, coz ostatne neni zadna specka. Komunikace a pravidelne demonstrace jsou nutnou podminkou zavedeni US

    2/ Big picture – pokud nemate Epics nebo neco jako Use cases, je mozne, ze ztratite kontext a budete muset predelavat nebo upravovat. Proto drzte v nejake forme i vazby mezi jednotlivymi US.

    3/ Technicka rec misto reci byznysu – v CZ firmach je bezne, ze analytik keca do technickeho reseni a navrhuje, jak to ci ono bude resene technicky v aplikaci. To se pak promitne i do formy dokumentace US, ktera je spis programatorskou dokumentaci, nez popisem byznys potreby zakaznika 😉

    4/ jsou ukecana – mnohdy z nich clovek zvykly na tradicni specku udela roman a to pak neni US. My doporucujeme mit detaily ve spustitelne forme – v unit testech, Foote ci Fitnesse a v US textove jen opravdu to gro.

    5/ Chybi u nich Akceptacni kriteria a zodpovedna osoba na strane zakaznika, s kym dojasnovat nejasne interpretace, komu ukazovat demo.

    My mame pro obchodniky, zakazniky a dalsi co budou US pouzivat 1 denni hru, kde se nauci nejen US a jejich formu, ale hlavne proces okolo, proc a jak a s kym mluvit, proc tuna specifikace nenahradi diskuse a pravidelne demonstrace. Vsichni zucastneni maji prozitek, diky kteremu chapou a usetri si spoustu problemu v praxi.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *