Mnoho organizací, které vyvíjí nebo spravují software, koketuje s myšlenkou agility jako způsobu vývoje. Co ale vlastně agilita ve vývoji znamená a jak na ní?
Potřebné plánování
V oblasti plánování je důležitých hned několik rovin. Předně je to možnost rozpadu a zaplánování jednotlivých požadavků do sprintů/iterací a následný přehled postupu prací včetně „Burn-down/up“ grafů, „Team Velocity“ a dalších ukazatelů (v této oblasti je často používaná také analýza, která pomáhá automaticky identifikovat požadavky, které jsou sice zaplánované do sprintu, ale tým nemá dostatečnou kapacitu je včas doručit).
Asi nejdůležitější rovina plánování ve SCRUMu je plán týmu. Zde má team leader možnost vidět aktuálně naplánované úkoly dle jejich vlastníků, vytíženost jednotlivých lidí v týmu, postup práce celého týmu nebo jednotlivců. Má tak jednoduchou možnost přeplánovat práci v týmu, je-li to třeba (např. kvůli přetížení klíčových zdrojů). To vše na úrovni času i náročnosti (story bodů).
Šikovnou pomůckou je také grafická vizualizace aktivit jednotlivých členů týmu (ToDo - In Progress - Done), kterou týmy prochází při pravidelných SCRUM schůzkách a diskutují o nich. Na úrovni jednotlivce pak plánování představuje jednoduchý ToDo list, který vždy aktuálně informuje o všech vlastních úkolech a umožňuje s nimi jednoduše a rychle pracovat. Velké množství aktivit je automatizovaných a vzájemná spolupráce se pak stává téměř zábavou.
Scrum používají také v Seznamu. Komunikace probíhá každý den na dálku mezi vývojovými týmy v Brně a Praze.
Mimo plánování nabízí prostředí Team Concert verzování všeho, co je ve vývojovém projektu třeba verzovat (modely, kód, dokumentaci, testy apod.), a to i při paralelním způsobu vývoje (více vývojářů pracuje současně na stejném kódu). Oblíbenou součástí je i automatizace buildů, kdy při využití existujících kompliátorů (Ant, Maven, MS Build, perl kompilátory apod.) umožňuje prostředí Team Concert zapojit individuální, kontinuální, noční i integrační buildy (včetně Unit testů) a udržovat automaticky vazbu mezi požadavky/úkoly, verzemi zdrojového kódu a buildy. Snadno a rychle je tak možné dohledat řádek i kontext nahlášené chyby i v hodně starých verzích kódu.
Mezi hlavní důvody, proč se týmy často rozhodují pro prostředí Team Concert, patří jeho dostupnost (zdarma do 10 uživatelů), možnost podpořit současně agilní i tradiční týmy (SCRUM, OpenUP, Waterfall, vlastní procesy), jednoduchost a rychlost práce/nasazení s cílem omezit tradiční „projektovou byrokracii“ a šíroká podpora jak klientských (Java, .NET, PHP, System I, System P, Mainframe, Oracle) i serverových prostředí (Jira, Subversion, Hudson, SharePoint, HP QC aj).
I když jsou projektové nástroje jen jedním z několika důležitých aspektů nasazení nové metodiky, významně ovlivňují její úspěšnost. I proto se snažíme doporučovat technologie, které sami pro agilní vývoj intenzivně používáme.
Agilní vývoj sám o sobě nedokáže vyřešit problémy, které mezi sebou lidé ve vývojových projektech často mají. Začít používat agilní praktiky totiž předpokládá více než jen studium příslušné literatury. Nasazení agilního vývoje znamená, že se projektový tým (nejen vývojáři) naučí aplikovat konkrétní agilní praktiky, začne je každodenně využívat v nástrojích, které jsou k tomu účelu připravené, a bude se pravidelně se učit ze svých chyb.
Je tedy agilita jenom marketingová bublina? Rozhodně není. Naše zkušenost ukazuje, že agilní vývoj může být prakticky nasaditelný a že nasazením lze dosáhnout významných zlepšení. Úspěchu dostáhneme především se skutečným obsahem konkrétně aplikovatelným v běžných projektech a pokud nezapomeneme na klíčové předpoklady úspěšného nasazení – metodika, tým, nástroje. Výsledky agilních projektů našich partnerů a zákazníků to nakonec dokládají.
Autor Pracuje v softwarové divizi ve společnosti IBM.
