Problémy při zavádění agilních přístupů

Transkript

1 Jaroslav Procházka Katedra informatiky a počítačů, Přírodovědecká fakulta, Ostravská univerzita v Ostravě / TietoEnator Corp., Jaroslav.prochazka@osu.cz Abstrakt Agilní přístupy k vývoji software jsou v dnešní době již běžně používané a uznávané přístupy. I po více než 15 letech se však můžeme setkat se spoustou dezinterpretací, nepřesností a chybných tvrzení způsobených převážně nepochopením. Autor se na základě své několikaleté praktické zkušenosti se zaváděním agilních přístupů v softwarových projektech snaží v článku některé z těchto nepravd objasnit. Dále jsou v článku zmíněny možné problémy, které nás mohou potkat při zavádění dnes tak velmi populárního přístupu, jímž je Scrum. Klíčová slova: agilní přístupy, problémy, Scrum. Abstract Agile approaches to software development are common and respected approaches in these times. After more than 15 years in IT industry, we can still read and hear lot of false interpretations and mistakes mainly caused by misunderstandings. In this article, author strives to explain the most common false interpretations based on his experience with agile implementations. Article further deals with expected problems when implementing Scrum that is nowadays very popular agile approach. Keywords: agile approaches, problems, Scrum. Agilní přístupy k tvorbě software jsou na poli softwarového inženýrství využívány již více než 15 let. Bohužel i po této době se běžně můžeme setkat se spoustou dezinterpretací, chybných názorů a nepravd ohledně agilních přístupů a to dokonce i v odborné literatuře. Cílem tohoto článku je přispět k osvětlení nejasností a vyvrácení nepravdivých tvrzení a podělit se tak o zkušenosti nabyté několikaletou praxí, tj. používáním a zaváděním agilních praktik a iterativního modelu životního cyklu v projektech vývoje a údržby software. Zmíněné poznámky snad mohou pomoci ostatním při zavádění agilních praktik a vyvarovat se tak chyb, které již prožili jiní. Stejně jako některé chyby softwaru plynou často z neznalosti požadavků, či hájení starých postupů (např. vodopádový přístup v silně se měnícím prostředí), 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ámého (např. hromy a blesky v dávných dobách) a také rezistence vůči změnám (zřejmé dodnes, či právě hlavně dnes, v době častých změn). Lidé určitých psychologických typologií jen neradi 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, viz [1]. Agilní manifest není třeba více rozvádět, jelikož článků a knih na toto téma už vyšlo opravdu velké množství, namátkou jen [2], [3], [4] či [5]. 118 SYSTÉMOVÁ INTEGRACE 3/2008

2 Nepravdy o agilních přístupech Autor se při denodenní práci setkává se spoustou pověstí a nepravd o agilních přístupech, z nichž některé si představíme a vysvětlíme dále v textu. Další, zde nepopsané zmiňují také renomovaní autoři v oblasti agilních přístupů, viz [9], [10], okrajově také [2] a [3]. 1. V agilních přístupech se nedokumentuje, neexistuje žádná dokumentace, modely, ale pouze kód. Toto tvrzení není zcela pravdivé (jedná se o špatnou interpretaci principu agilního manifestu: Working software over comprehensive documentation [1]), ve skutečnosti modelujeme, dokumentujeme, ale v jiné formě a pouze to, co je nutné. Use case či user story 1 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 může se lišit jejich exaktnost, mohou to být pouze náčrty na tabuli či na papíře a přesto maximálně splňují svůj účel, navíc při minimálním úsilí vývojářů a ceně použitého nástroje. Jelikož jsou agilní přístupy typické krátkými iteracemi a častými releasy, tudíž se kód č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á fakta a rozhodnutí, například architekturu, které se týká další mýtus. 2. Nenavrhujeme žádnou architekturu je pravdou, že na začátku projektu se nezabýváme všemi požadavky (protože je ani nemáme) a neřešíme tzv. architekturu do šuplíku, která reflektuje všechno, co bychom ještě mohli v projektu potřebovat a někdy v budoucnu využít (známé programátorské: co kdyby zákazník potřeboval ještě tuto sofistikovanou funkčnost?). V úvodních iteracích však ř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í. Detailním návrhem 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 verzí či úplně zrušit a naše snaha může přijít vniveč. Neděláme tedy architekturu pro předpokládané budoucí požadavky, nýbrž jen pro aktuální potřebu. 3. Jen vývojáři jsou/mají být agilní, 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í, ne-li větší. 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 [12], pak nás samozřejmě ani agilní přístupy nezachrání. Trojúhleník kvality jasně říká, že pokud chceme dodat software v očekávané kvalitě, s danými požadavky, v daném čase a za danou cenu, musí si tým jednu z proměnných požadavky, čas, cena zvolit. Kvalita je proměnná, kde zákazník své požadavky nesleví. Nikdo nechce program plný chyb či náhodně reagující na stejné 1 Use case a user story je forma dokumentování softwarových požadavků propagovaná hlavně frameworkem Rational Unified Process / OpenUP [8] a agilními přístupy [2], [3]. Více o této problematice viz [11]. SYSTÉMOVÁ INTEGRACE 3/

3 Jaroslav Procházka podněty. Pokud jsou všechny tři proměnné fixně definovány zákazníkem a tým je schopný opravdu s danými omezeními vše doručit, tím co nesplní předpoklady je právě kvalita (viz Obr. 1). Pokud zákazník nebude chtít spolupracovat, nebude se chtít účastnit pravidelných demonstrací, kde si hraje s dosud vyvinutým řešením, komentuje je a připomínkuje a pak dané řešení v praxi nezačně využívat, nelze očekávat úspěch. Musíme zákazníka neustále 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í [6]), ž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 Chaos Reportu [7] více než polovina, viz Obr. 2) a na konci očekával řešení (to už ale víme, že nefunguje), jehož přínos a také kvalita jsou mnohdy diskutabilní. Obr. 1: Klasický trojúhleník kvality Obr. 2: Požadavky zákazníka definované na počátku projektu versus jejich využití Z grafu je zřejmé, že pro zákazníka je opravdu potřebných, tj. využívaných jen asi 20% všech dopředu definovaných požadavků (Often a Alaways hodnoty), zbylých 80% není téměř nikdy využíváno (Never, Rarely, Sometimes hodnoty), zdroj [7] 120 SYSTÉMOVÁ INTEGRACE 3/2008

4 4. Podpora managementu firmy není třeba, stačí aby nám vývojářům naši nadřízení řekli: Ano, tak si tedy programuj agilně, když chceš. toto je další častou chybou a naivní představou, co je ještě horší, je zavádět agilní praktiky a iterativní model tajně. 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 podporovat a bojovat za ni) a bez oficiálních prostředků a schválení (vývojáři absolvují tréninky, zpomalí se tempo vývoje) agilní přístup ani zavést nelze, což platí v případě jakékoliv metodiky. Jedná se totiž o úplnou změnu chování a myšlení všech lidí v organizaci a také o změnu vystupování směrem k zákazníkovi, což potají moc provést nelze. Standish Group ne nadarmo řadí podporu managementu (executive support) ve výše zmíněném výzkumu úspěšnosti softwarových projektů na 1. místo z pohledu důležitosti [7]. Pro zdůraznění důležitosti této podpory ještě zmíním, že na 2. místo odsunul dosud vedoucí angažovanost uživatelů v projektu [7]. 5. Agilní přístupy jako Scrum, XP, Lean development, OpenUP, RUP (ano i RUP ctí a naplňuje agilní principy) jsou metodiky další zásadní omyl, jedná se totiž o procesní frameworky (v případě Scrum, OpenUP, RUP) či sady best practices (v případě Lean development či Extrémního programování XP), jak ostatně vysvětlují sami autoři, viz [3], [8], [9] a [10]. Metodika je předepisující, i když je nutné ji nejdříve upravit pro potřeby daného projektu, adoptujeme ji většinou jako celek a neprovádíme zásadní změny. Našim potřebám přizpůsobený proces pak přesně a konkrétně říká co, kdy, kdo a jak má dělat v rámci celého životního cyklu vývoje software. Když nevím, co provést v následujícím kroku, nalistuji si danou oblast v popisu adoptované metodiky a na straně 216 najdu detailní popis postupu. Procesní frameworky jsou mírně odlišné, 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 a přístupy se v praxi osvědčily v různých podoblastech softwarového inženýrství [3], [9]. Na nás pak je, abychom si vybrali, co konkrétně v našem projektu potřebujeme, uznáme za vhodné dělat, tj. použili v projektu nějakou techniku či princip. Různé techniky procesního frameworku můžeme využít v jakémkoliv modelu životního cyklu (ať iterativním nebo vodopádovém). Pokud chceme implementovat všechny základní principy procesního frameworku, děláme to po částech a v několika iteracích, běžně několik měsíců či roků. Abychom mohli upřímně říci, že jsme plně implementovali XP či RUP / OpenUP 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, podle potřeby zkusíme něco nového a snažíme se tomu přijít na chuť, naučit se to, ale musíme dodržovat určité zásady. Jídlo servírujeme na talíři, jíme příbory, nápoje naléváme do skleniček. Agilní přístupy a certifikace Samostatným bodem je problematika certifikací. Certifikace a agilní přístupy je téma velmi diskutované především v zahraničí. Podle mého názoru nejdou agilní přístupy (způsob myšlení) 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 takový způsob práce 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). SYSTÉMOVÁ INTEGRACE 3/

5 Jaroslav Procházka Přínosem takové certifikace je to, že víme, že daný člověk má o přístupu alespoň povědomí. Agilní přístupy jsou tedy o způsobu myšlení a pracování lidí, ne o tom, jestli sedím na kurzu, za který dostanu certifikát. Agilní myšlení se projevuje tak, že dělám jen to co je nutné, přínosné (modelování, tvorba mezi-dokumentů, modelů, ), aby tyto kroky vedly k cíli, jímž je spustitelný kód bez chyb, který přináší zákazníkovi hodnotu. Tento názor si autor udělal po absolvování kurzu Scrum Master (metoda Scrum). Jako závěr k problematice certifikací můžeme říci, že výše řečené platí v softwarovém inženýrství obecně, nejen v případě agilních přístupů. Problémy Scrumu Jelikož velmi moderním agilním přístupem se v dnešní době stal Scrum (viz publikace [3]), upozorníme na běžné problémy, které mohou nastat při jeho implementaci. Scrum se totiž stal dalším módním jevem těchto let na poli softwarového inženýrství, alespoň co se Evropy týká. Všichni o něm mluví, upravují podle něj model životního cyklu projektu, ale nikdo pořádně neví nebo si neuvědomuje problémy, které může způsobit při nevhodné implementaci. Samozřejmě je nutné zmínit, že Scrum odkrývá problémy, obsahuje výborné praktiky jako denní meetingy, samostatně řízené týmy (self-managed team) a koncept sdílených kompetencí v týmu, které potřebujeme k vývoji software (crossfunctional team). Scrum samotný však při vývoji software nestačí. Scrum je obecným přístupem pro řízení projektů, neobsahuje a nepopisuje praktiky pro vývoj software, což překvapivě mnoho jeho uživatelů neví! Proč tedy použití Scrumu způsobuje v některých oblastech problémy? Neznalost faktu, že Scrum je pouze metodou, resp. frameworkem pro řízení projektů, jak již bylo zmíněno, Scrum nepopisuje inženýrské praktiky, které jsou při vývoji software kritické, tj. jak software dělat. Proto Scrum tak dobře funguje v kombinaci s XP (protože to jsou zase téměř pouze inženýrské praktiky) a proto implementace samotného Scrumu vede velmi často ke stejným problémům, hlavně v týmech s několika nezkušenými vývojáři. 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 (klasický případvodopádu). Nic nás explicitně nenutí identifikovat a naplánovat do úvodních iterací technicky rizikové implementace. Například v RUP jsou rizika součástí životního cyklu a jejich odstranění, snížení je hlavním cílem Elaboration fáze. Scrum není orientován na architekturu systému, čímž nemyslím vodopádové tvoření robustní a mnohdy zbytečně těžkopádné architektury dopředu, ale identifikování základních vrstev, definic rozhraní a způsobu komunikace mezi nimi, jak již ostatně bylo popsáno výše. User stories vs. use cases (způsob zachycení požadavků zákazníka, viz výše) problémem stories je možná ztráta souvislostí a vazeb při jejich použití (porovnejte s use case a jeho scénáři). Use case mají v tomto případě dvě logické úrovně: use case zastřešující celý scénář včetně možných variant průchodu a scénář popisující detailní kroky, podmínky a zúčastněné aktory. Díky vrstvě use case neopomeneme závislosti scénářů a vyvarujeme se možných zbytečných předělávek v budoucnu. 122 SYSTÉMOVÁ INTEGRACE 3/2008

6 Závěrem Na závěr tedy můžeme shrnout, že agilní přístupy jsou o lidech (jako všechny přístupy), jejich spolupráci ale hlavně o změně myšlení. Většina technik je sice méně sofistikovaných, neformálních (např. user stories, modelování), ale některé jsou naopak docela náročné na disciplínu, např. testy řízený návrh (Test-First Design). 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 ověřených technikách a praktikách v oblasti agilních metod a přidává další ověřené je OpenUP [8]. OpenUP 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. Použité zdroje [1] Agile manifesto. Dostupné na [ [2] Beck, K.: Extreme Progamming Explained: Embrace Change. 2nd Ed. Addison-Wesley. 224 p ISBN [3] Schwaber, K.: Agile Project Management with Scrum. 1st Ed. Microsoft Press. 192 p ISBN X. [4] Kadlec, V.: Agilní programování. 1. vyd. Brno, Computer Press str. ISBN [5] Buchalcevová, A.: Metodiky vývoje a údržby informačních systémů. 1. vyd. Praha, Grada str. ISBN [6] Wegner, P.: Why interaction is more powerful than algorithms. Communications of the ACM. vol.40. May pp [7] Standish Group Chaos Report Dostupné na: [ chaos.pdf]. [8] OpenUP. Dostupné na: [ [9] Poppendieck, M., Poppendieck, T.: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley str. ISBN [10] Eckstein, J.: Typical Pitfalls in Agile Software Development. JavaPolis 2006 Conference. Podcast dostupný na [ [11] Cockburn, A.: Use cases. Jak efektivně modelovat aplikace. 1. vyd. Brno, Computer Press str. ISBN [12] Lewis, James P.: Project Planning, Scheduling & Control, 4E. McGraw Hill ISBN SYSTÉMOVÁ INTEGRACE 3/