Hlavní navigace

Agilní metody a Scrum

25. 6. 2009
Doba čtení: 11 minut

Sdílet

Vývoj softwaru prošel posledních pár let ohromným boomem. Firmy objednávaly informační systémy, nasazovaly nové technologie, analyzovaly data. Přesto podle Standish Group Study více než 70% IT projektů končí neúspěšně, vezmeme-li jako kritérium úspěchu včasné dokončení, bez překročení rozpočtu a s požadovanou funkcionalitou. To se sice na první pohled zdá být hodně, ale podíváte-li se detailněji na IT projekty ve svém okolí, jaké procento by jich bylo s ohledem na zmíněná kritéria opravdu úspěšných?

Na tento trend firmy reagují zavedením ISO, SixSigma, nebo Agilních metod. Zjednodušeně by se dalo konstatovat, že tím, co je pro výrobní firmu proces štíhlé výroby, tím jsou pro softwarovou firmu Agilní metody. Navíc Agilní metody jsou softwaru přímo šité na míru. Co jsou základní kameny Agilního procesu? Tak určitě práce v krátkých cyklech, pravidelné odevzdávání úloh, zapojení zákazníka do procesu plánování a samozřejmě organizace týmu. Agilní metody jsou souborem nejlepších praktik a doporučení, ale jako každá metodologie nesmějí být brány nijak dogmaticky. Z tohoto pohledu jsou tyto metody spíše volnou filozofií, kterou podpoříte firemní kulturu, než striktními pravidly, kterými budete lidem přikazovat.

Jedním z nejčastěji zaváděných Agilních přístupů je Scrum proces, jehož cílem je rozčlenit velké a komplexní softwarové projekty, které je těžké najednou obsáhnout a pochopit. Rozděluje rozsáhlé oblasti na menší celky a stanovuje priority jednotlivých úloh.

 

Rozdělení a ohodnocení úloh

Jedním z nejčastějších problémů při vývoji softwaru jsou špatné odhady úloh a celého projektu mající obvykle za následek doručení dlouho po termínu. Jedním z důvodů špatného ohodnocení je velká komplexita problému. Scrum proces proto zavádí takzvaný Backlog, ve kterém se komplexní úlohy - Story - rozdělí na jednoduché a jasně definované úlohy, které je snadnější si představit v celé šíři a tedy je i ohodnotit. Dobrou praxí je ohodnocovat úlohy body, namísto běžných člověkodní. Body nemají přímou vazbu na čas, spíše je to ohodnocení komplexity úlohy a jako takové je tedy vývojářům bližší.

 

Práce v cyklu

Celý Scrum proces probíhá v pravidelných cyklech - Sprintech - které by obecně neměly být delší než 30 dní. Délka Sprintu závisí na povaze projektu, ale měla by umožňovat dokončení běžné úlohy v rámci jednoho Sprintu. Výhodou Sprintů je pravidelnost. Každý Sprint tým odevzdává svoji práci a prezentuje výsledky - měl v jeho rámci dokončit stejné množství bodů, v pravidelném intervalu, tedy pokaždé stejné množství práce. Vždy se zkontrolují úlohy v Backlogu, a podle celkového počtu bodů se případně upraví konec projektu. Pokaždé je tedy vidět, jestli jde projekt dobře, nebo jestli má problémy.

 

Proces plánování

Podívejme se teď detailněji na plánování úloh, které probíhá dvoufázově. Před začátkem Sprintu je porada před plánováním (pre-planning meeting), kde se sejdou zástupci všech zájmových skupin - architekt, zástupce vedení, zákazníka, zástupce jiných týmů závislých na výstupu. Ti společně stanoví priority na následující Sprint a identifikují oblasti - Story, na kterých budou jednotlivé týmy pracovat.

Následuje plánovací porada, kde tým sám plánuje práci ze seznamu nejdůležitějších oblastí identifikovaných na předchozí poradě jednotlivé úlohy. Výsledkem je už konkrétní plán, který se tým zaváže splnit. Vzhledem k tomu, že se zaměstnanci podílí na plánování, je i jejich zainteresovanost na výsledku vyšší než obvykle. Navíc se tím učí nejen odhadovat ale i organizovat práci a jejich výsledky jsou předvídatelné a spolehlivé.

Rozhodně byste se měli vyvarovat zasahování zvenku do již existujícího plánu týmu či do samotného plánování. Od toho je porada před plánováním, která určila funkcionalitu, již potřebujete mít rychle hotovou. Aby celý proces fungoval, potřebuje mít tým dostatečnou samostatnost v rozhodování, plánování či případném přeplánování úloh jiným lidem. Aby mohli zaměstnanci nést zodpovědnost za své výsledky, musí o nich také plně rozhodovat. Máte-li často potřebu měnit priority v průběhu Sprintu, je velmi pravděpodobné, že je moc dlouhý vzhledem k potřebám a formě projektu.

Nikdy nevyhodnocujte jednotlivce, ale vždy hodnoťte tým jako celek. Je jen a jen na týmu, jak si práci interně zorganizuje, aby dosáhl naplánovaných a očekávaných a výsledků. Chcete-li povzbudit soutěživost, je dobré mít týmy dva.

 

Zapojení zákazníka

Zástupci zákazníků, a to jak interních tak externích, by měli být rozhodně přítomni plánování na poradě před plánováním, aby byli zapojeni do procesu a spolupodíleli se na určování priorit. Na konci Sprintu je pak dobré zorganizovat pro zákazníky prezentaci, aby byla zajištěna zpětná vazba a úlohy se mohly případně upravit podle jejich potřeb už během procesu, a předešlo se tak špatným či nevyhovujícím výsledkům. Na zákazníka tak časově nejsou kladeny nijak velké nároky, navíc pravidelně, vždy na konci Sprintu vidí výsledek, což je často k nezaplacení.

 

Intenzivní Komunikace

Agilní metody jsou přímo založené na skupinové spolupráci - dobře nastavený tým je mnohem efektivnější než vzájemně nekomunikující jedinci. Jednou z mnoha technik jak nastavit fungující tým, je zavedení krátkého každodenní porady - tzv. Scrumu. Jejím účelem je všechny v rámci týmu informovat o stavu jednotlivých úloh a zajistit prostor pro identifikaci a řešení problémů. Scrum meeting musí být krátký, neměl by trvat déle než pět až deset minut. Měl by dát prostor všem členům týmu zhodnotit, jak pokračují na zadaných úlohách - co dělali včera a co plánují dělat dnes.

Síla je v pravidelnosti. Ta pak umožňuje rozpoznat problém včas a začít ho řešit. Ať už tím, že se úloha v rámci týmu přidělí někomu jinému, nebo tím, že někdo zkušenější poradí. Díky tom, že všichni vědí, co kdo dělal a umí, vědí také, kdo by jim s jejich úlohou mohl poradit a na koho se obrátit. Ruku v ruce s tím jde i automatické nabídnutí pomoci v rámci týmu těm, kteří pomoc potřebují.

Další z dobrých praktik spočívá v posazení týmu do jedné místnosti. Když lidé, kteří spolu pracují, sdílejí i jednu kancelář, komunikace ostatních, již na pozadí vnímají, se jich většinou i v jistém smyslu týká. Týká se projektu, na kterém pracují, a oni, i když nepřímo, přijímají informace, na které by jinak bylo třeba pořádat formální meetingy. Říká se tomu osmotická komunikace.

Budete-li začínat s Agilními metodami, zapojte tým i do nastavování Agilních procesů. Nikdy by to nemělo být chápáno jen jako nařízení shora. Vyžadujte závazek i aktivní spolupráci a nebojte se měnit nastavené hodnoty, když se ukáží jako nevyhovující. Dobrým nástrojem jak dát členům týmu vědět, že čekáte na jejich připomínky, je reflexní porada - tím, co zde zazní, se pak ale také musíte seriózně zabývat.

 

Závěrem

Výhodou Agilních metod je, že jsou flexibilní a přímo uzpůsobené na použití v různých prostředích. Agilní metody a Scrum můžete nasadit na projektech různých velikostí a to včetně náročných projektů vyžadujících specifické kontrolované procesy, jako je vývoj aplikací pro zdravotnictví, řízení letových provozů, či řízení výroby. Je jen na vás, jak si projekt nastavíte a přizpůsobíte procesy svým potřebám. Začátek bude možná náročný, ale vynaložená energie se bohatě vrátí ve vyšší efektivitě týmu, lepší kvalitě výsledné práce a spolehlivém odhadu termínu dokončení.

 

Autorka vede outsourcingové softwarové projek­ty ve společnosti Certicom na pozici Program Manager 

 

Byl pro vás článek přínosný?