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í?
Kapitoly článku:
Během posledních deseti let se způsob vývoje hodně posunul dopředu – technologicky, znalostně i organizačně. Před několika lety stačilo mít špičkového specialistu (vývojáře, databázistu atp.), na kterého bylo možné spolehát. Dnešní projekty jsou tvořeny většími či menšími týmy lidí, kteří přicházejí s různými zkušenostmi, různými pracovními návyky a často i jinou firemní kulturou (zejmené v projektech, kterých se účastní více firem). To klade logicky vyšší nároky na koordinaci prací lidí, chcete-li týmovou práci.
Způsobů, jak práci v týmu organizovat, je hodně. Cílem většiny takových přístupů je naučit členy týmu spolupracovat jako dobrou kapelu hrající jazz. V takové kapele je totiž každý hudebník svébytným originálem s vysokou mírou kreativity. Dohromady ale musí tvořit sehraný tým, který si vzájemně naslouchá a vždy tvoří neopakovatelné hudební dílo.
Aby bylo něco takového možné vytvořit i v softwarovém světě, je třeba pomoci jednotlivým specialistům hrát roli kreativních a zkušených jedinců, kteří naslouchají svému týmovému okolí. To však není vždy jednoduché. Mnoho týmů se o to pokouší vlastními metodami (různé varianty vodopádového vývoje nebo jiné, vlastní přístupy). Některé týmy se nechávají více či méně inspirovat klasickými vývojovými metodikami (např. Rational/Open Unified Process). Stále částěji se ale pozornost týmů stáčí na agilní přístupy. V obecné rovině koketuje s agilitou asi každý vývojový tým, jak ji ale prakticky zavést a na co se soustředit?
Pravidlo „just enough“
Mnoho obecných agilních principů je popsáno už v dokumentu „Agile Manifesto“ a mnoha studiích, které tyto myšlenky dále rozvíjejí. Většina těchto dokumentů se však snaží postihnout základní principy agility a nezaměřuje se už tolik na její praktické nasazení. Přitom praktické nasazení a praktické zkušenosti jsou to, co může agilní vývoj rozšířit do formy běžně používaného standardu.
IBM Rational Team Webtop.
Jednou z cest, jak začít, je přijmout myšlenku, že v agilním světě je třeba se snažit dívat optikou „just enough“. Je-li tedy cílem zefektivnit fungování týmu, pak může být dobrým krokem vpřed začít zjednodušovat vnitřní pravidla a procesy. A to nikoli proto, abyste některá důležitá témata mohli vynechat, ale proto, abyste se zaměřili na činnosti, které jsou pro dosažení vašich cílů opravdu důležité a dělali je v minimálním smysluplném rozsahu (tedy tak, abyste s minimálním úsilím dosáhli toho, co skutečně potřebujete).
Agile requirements, agile testing, atd. často potom znamená aplikaci pravidla „just enough“ na jednotlivé disciplíny softwarového vývoje. Nejde ale o to vyhnout se správě požadavků či testování jako takovým. Naopak jde o to se zaměřit na co možná nejefektivnější sběr, sdílení a údržbu požadavků v aktuálním stavu bez zbytečného úsilí navíc.
SCRUM kam se podíváš
Mnoho týmů ale nechce experimentovat se zaváděním agilních principů do vlastních metodik, ale rozhodují se pro přechod na některou z osvědčených agilních metodik. I když jich existuje celá řada, jednou z nejčastěji používaných je SCRUM.
Existuje mnoho popisů metodiky SCRUM a mnohé firmy nabízejí školení s možností certifikace účastníků na SCRUM mastery. To, co je ale velmi těžké školením či dokumentem předat, je vlastní zkušenost se zaváděním takové metodiky. Malé týmy (do 5 až 7 lidí) se často rozhodují pro adopci metodiky SCRUM samy a učí se na vlastních chybách. Větší týmy se i vzhledem k souvisejícím rizikům obvykle rozhodují pro odbornou asistenci se zaváděním metodiky.
S oblastí zavádění agilních metodik máme široké zkušenosti například u nás v IBM. Celou řadu těchto zkušeností jsme získali, když jsme se před několika lety rozhodli převést pod vedením Scotta Amblera velkou část svého interního vývoje na agilně řízené projekty. Tyto agilně řízené projekty se velmi úspěšně rozvíjejí (jedním z příkladů je transparentní a otevřená týmová platforma Jazz). Mimo to interně zkoušíme i další přístupy, jako je např. KANBAN apod.
Důležitějším zdrojem zkušeností jsou pro nás ale praktické pojekty, ve kterých jsme pomohli a dále pomáháme našim partnerům a zákazníkům úspěšně přejít například na metodiku SCRUM. Mezi příklady zákazníků lze zařadit významné organizace z oboru bankovnictví, telekomunikací či logistiky, a to v celém regionu střední a východní Evropy včetně České republiky, Slovenska, Polska a Turecka.
Ve všech zmíněných projektech klademe důraz na tři klíčové podmínky úspěšného zavedení nového přístupu k vývoji – metodiku, tým a nástroje.