Novinky

Touto „definicí“ se v poslední době zabývá čím dál více lidí, zejména pak IT manažerů, kteří řeší vývoj softwaru. Díky rostoucí popularitě agilního vývoje se už mnoho profesionálů rozhodlo agilní přístup vyzkoušet a implementovat do firmy, ale získání hlavních benefitů agilního přístupu není tak snadné, jak by se na první pohled mohlo zdát.

Za mou mnohaletou práci v tomto oboru jsem už slyšel mnoho příběhů, ale poslední dobou opravdu často slyším velmi podobnou větu. „Tak už děláme agilní vývoj, máte ty denní meetingy a častější releasy“. Z vlastní zkušenosti vím, že tento přístup velmi pomůže komunikaci v týmu a nezhorší výsledek oproti klasickému vodopádu, nicméně agilní přístup je mnohem přínosnější, když je implementován správně.

Jednou z hlavních částí agilního vývoje resp. Scrumu je pravidelnost. Celý tým se pravidelně schází každý den na krátké meetingy (ve stejný čas a pokud možno na stejném místě), pravidelně se prezentuje výsledek práce týmu, pravidelně plánuje, pravidelně hodnotí svou práci. Zkrátka se vše děje opakovaně. 

Velmi důležitou a opomíjenou činností je retrospektiva, která slouží k diskuzi jak celý tým posunout dále, jak dělat věci efektivněji, jak odstranit „waste time“. Právě proto je tento meeting jedním s nejdůležitějších prvků agilního přístupu. Na meetingu se sice vše nevyřeší, ale následné kroky a opatření rozhodnou, zda získáte všechny benefity plynoucí s agilního přístupu.

I když základní implementace je relativně snadná, je potřeba se vyvarovat několika neduhům, se kterými se stále setkávám a které působí problémy v implementaci už jen proto, že implementace agilního přístupu nepřinese očekávané benefity.

Stabilní sprint

Rozsah funkcionalit dodaných v jednom cyklu by měl být stabilní. Změnu by neměl dělat zákazník, ani kdokoli jiný. Toto pravidlo dává týmu jistotu a stabilitu co vše musí stihnout. Na druhou stranu se změny dají zahrnout již do dalšího sprintu např. za 2 týdny.

Prioritizace

Každý z vás jistě někdy řešil určení priorit jednotlivých požadavků. Většina požadavků dostane prioritu 1, několik jich dostane prioritu 2 a priorita 3 se použije, aby se neřeklo. Agilní přístup resp. Scrum má k tomuto problému jednoduchou pomůcku. Každému požadavku musíte určit takovou prioritu, aby byla v rámci celého rozsahu unikátní. Ze vzniklého seznamu je pak velmi snadné určit co má nejvyšší prioritu a nemusíte řešit diskuzi, které priorita 1 je prioritnější.

100% alokace

Toto pravidlo platí hlavně pro vývojáře, kteří se mohou soustředit a pracovat stoprocentně na jednom projektu. Pokud jsou vyrušeni a musí se věnovat jinému projektu, je časově náročné neustále přepínat mezi projekty a řešit dva nebo více projektů najednou.

Změna myšlení

Agilní přístup není jen o změně metodiky vývoje, ale částečně i o změně myšlení. Asi všichni známe případy, kdy se na začátku projektu udělá 50-ti stránková analýza, podle které se postupuje. Na konci projektu sice odevzdáte produkt, který obsahuje všechny požadavky z analýzy, ale otázkou je, zda je někdo bude používat. Dle statistik se v produktech vyvíjených klasickým přístupem používá jen 20% -30% funkčností, zbytek jsou funkce, které se využijí minimálně, nebo vůbec.

Agilní přístup tyto problémy řeší jiným přístupem a snaží se změnit myšlení vše zúčastněných, aby byl výsledek společného snažení co nejpřínosnější. Hlavní změny v myšlení se dají shrnout do následujících bodů:

• Jedinci a jejich spolupráce jsou důležitější než procesy a nástroje
• Fungující software je důležitější než obsáhlá dokumentace
• Spolupráce zákazníka je důležitější než jednání o smlouvě
• Reakce na změnu je důležitější než se držet plánu

Závěr

Implementace agilních metod není jen o změně procesů vývoje a komunikace, ale i o změně myšlení k zažitým postupům.

Pokud se vám podaří implementovat alespoň výše zmíněné kroky, jste na nejlepší cestě získat benefity agilního přístupu k vývoji softwaru, které se dají shrnout do následujících bodů: 

• Častější releasy, dříve dosáhnete business hodnoty
• Výhoda pro klienty, kteří platí za funkcionalitu, kterou skutečně potřebují, protože dříve vidí výsledky práce a výsledný produkt
• Změny v projektu nejsou hrozbou, ale příležitostí