Pavel Šimek
7.1.2013

Agilní metodiky a vývoj software



Mnoho firem dnes zavádí Scrum. Jejich cíle jsou jasné: vyhodit projekťáka a vyvíjet lepší software, aniž by vývojáři vylezli ze sklepa a někoho obtěžovali. To ale nefunguje.

Agilní metodika přišla celkem přirozeně jako reakce na přesun vývoje software z velkých firem do každé IT společnosti a každému na stůl. Místo velkých týmů se objevilo mnoho malých skupinek programátorů, kteří si začali předávat a vyměňovat zkušenosti i open-source kód po internetu dříve netušeným způsobem. To přineslo i změnu myšlení. Historie agilních metodik sahá až do roku 1986, kde vznikly první zmínky o agilním přístupu k projektovému řízení, rozšiřovat se však začaly teprve před jedenácti lety, kdy spatřil světlo světa Agilní manifest. Dá říci, že od té doby tyto metodiky vyzrávají a začínají být skutečně vnímány jako alternativní a úspěšný způsob vývoje software.

Celosvětové průzkumy ukazují, že agilní metodiky v praxi fungují, jsou stále více využívány a akceptovány. Situaci v ČR však nevnímám tak optimisticky. Nejen, že se tento nový typ vývoje k nám dostal poměrně pozdě, ale většina firem tento přístup jednoduše nepoužívá, neví o něm nebo ho zavrhly. Nemám k dispozici statistiku, ale zdá se, že agilní metodiky používá méně než třetina IT firem a část firem od ní dokonce ustupuje. Jeden z průzkumů Masarykovy univerzity v Brně uvádí, že nejzávažnější důvody jsou: právní riziko finančních ztrát, plynoucí z nižší úrovně právního ošetření smluv s klienty odmítnutí agilních postupů stávajícími zákazníky, kteří chtějí waterfall jež je ověřený obava firem z nemožnosti vyvíjet bez provedení detailní analýzy nižší použitelnost agilních metodik pro rozsáhlé projekty.

Ať už jsou důvody jakékoliv, vypadá to, že české firmy jsou poměrně konzervativní a nerady zavádějí změny, které by mohly ohrozit jejich fungování. U nás v Aspectworks, kde pracuji, úspěšně využíváme Scrum již 3 roky. Touto metodikou jsme vyvíjeli např. nový projekt Hithit, nebo náš procesní software Orinoco. Mé vlastní zkušenosti se Scrumem začaly v roce 2009, kde jsem se podílel na jednom mezinárodním projektu řízeným jinou českou firmou. Už v té době mě takovýto přístup k řízení projektů zaujal, i když jsem mu hlouběji nevěnoval příliš mnoho pozornosti. Tehdy jsem se zabýval metodikou PRINCE2, která tak nějak stojí mezi agilním vývojem a „waterfallem“. Scrum mě zaujal svou jednoduchostí a hmatatelnou efektivitou. Díky krátkým iteracím se zaměřením na konkrétní funkčnosti vyvíjeného softwaru, přináší Scrum rychlou zpětnou vazbu na zákaznické požadavky. Spokojenost zákazníka je ve většině případů měřítkem pro úspěšný či neúspěšný produkt. Na rozdíl od starších metodik, Scrum dokáže rychle reagovat na změny zadání, obvykle vyvolané změnami situace na trhu.

Aniž bych se pouštěl do vysvětlování pojmů a procesů Scrumu, (vše je de facto definováno v manifestu a 12 principech agilního vývoje), chtěl bych sdělit pár osvědčených rad, jak vůbec začít s agilním řízením projektů a na co se v začátcích zaměřit.
Agilní metody jsou vhodné jen pro určitý typ projektů. Přinášejí velkou efektivitu tam, kde můžete dopřát vývojovému týmu dostatečnou svobodu a zcela selhávají v případech kdy, čas, rozpočet i rozsah funkčnosti jsou fixní a předem dané. Agilní metody se dobře uplatňují u interních projektů, protože firma obvykle ví, co chce, a dokáže lépe zapojit odpovědné lidi do vývoje. Zainteresujte zákazníka Funguje to dobře i tehdy, když zákazník chápe princip agilního řízení a má o něj zájem. Tady bych zdůraznil slovo „chápe“, jelikož v mnoha firmách, zejména lidé ve vyšších pozicích, chápou Scrum často mylně. Ty je třeba informovat, případně vyškolit v tom, jak vývoj ve Scrumu bude probíhat, co je dobré očekávat, jaké přínosy bude mít pro finální produkt a také co Scrum neumí.
V mnoha případech se setkávám se zažitým systémem, ve kterém vám sdělí rozpočet (budget) a datum spuštění (deadline) a vy si to řiďte, jak chcete. Hlavně že to bude v termínu. V takovémto případě raději vycouvejte, Scrum nezavádějte a hledejte jinou cestu či metodiku pro řízení takového projektu. Snažte se do vývoje zapojit pokud možno i budoucí uživatele, jen tak si můžete být jisti, že produkt bude po spuštění správně fungovat. Úzká spolupráce programátorů s cílovými uživateli systému a testery je nezbytná. Dotaženo do extrému, uživatelé se na vývoji přímo podílejí, protože jako součást vývojového týmu programátorům poskytují okamžitou zpětnou vazbu a spolupracují při všech fázích vývoje. Zapojte vývojový tým. Ochota ke změně zadání je hlavním přínosem agilních metodik pro řízení projektu. Tým i software si musí být schopen uchovat flexibilitu, aby na změny dokázal reagovat. Zaměřte se na součinnost lidí z byznysu, ti jsou dost často klíčem k úspěchu. Pravděpodobně však budou dost zahlceni svoji prací a tak dostanete k rukám nějakého nováčka, který ne vždy musí mít kompletní přehled o všem, co se daného projektu týká.
Abyste neztratili kontakt s realitou, musíte si informace získávat i jinak – od uživatelů, ze statistik, od zkušených vývojářů apod. Snažte se dodržet jeden z principů agilního vývoje a co nejvíce práce vůbec nedělat. Zaměřte se na jednoduchost. S tím vám může pomoci role designéra zaměřeného na použitelnost. Stále komunikujte Pilířem Scrumu je jednoznačně osobní komunikace. Ta je ovšem možná jen tehdy, když je vývojový tým malý a centralizovaný. Ideální je, aby všichni zúčastnění pracovali z jednoho místa a potkávali se každý den.

Pokud chceme použít agilní přístup k vývoji i pro distribuované týmy, musíme se vypořádat s různými překážkami jako je jazyková bariéra, nedostatek vhodných nástrojů pro komunikaci, jiná časová pásma, nedostatek času na komunikaci, rozdíly ve firemní i národní kultuře, rozdíly v terminologii apod. Osobně jsem řídil jeden větší distribuovaný projekt ve společnosti DHL a moje zkušenosti jsou pozitivní, ale je třeba věnovat velkou pozornost výběru členů týmu, případně jejich zainteresování do Scrumu. Je třeba naplánovat osobní setkání. Na začátku projektu je vhodné uspořádat zahajovací setkání v délce alespoň jednoho týdne. Potom je vhodné se osobně setkávat v pravidelných intervalech, ať už v telekonferencích nebo osobně. Také na závěr projektu je vhodné uspořádat osobní setkání celého týmu, od vývojářů, testerů i po ostatní zainteresované osoby. Řízení distribuovaného týmu je velmi náročné na organizaci. Je třeba mít jasnou organizační strukturu, která určuje vztahy v rámci lokálních pracovišť vůči centru. Dále je třeba stanovit jasnou komunikační strategii, vybrat vhodné nástroje a zavést shodné prostředí pro vývoj ve všech lokacích. Pokud si dáte od začátku pozor na vysvětlení Scrumu projektovému vedení, zapojení všech zainteresovaných osob do vývoje a zajistíte dobrou komunikaci, pravděpodobně projekt zvládnete úspěšně rozběhnout. Ctěte agilní přístup, ale pamatujte si, že pokud nástroje, procesy, plány a metodiky pomáhají vývoji, jsou vítány. Jakmile začnou překážet, je nutné je změnit. Další úskalí sice číhají v rámci jednotlivých iterací, ale o tom zase v příštím článku.

Vaše emailová adresa nebude zveřejněna

Komentáře

Děkujeme za váš komentář
Další