Před nedávnem jsme na projektu zavedli metodiku Scrum. Jedná se o metodiku, která se řadí mezi agilní metodiky pro řízení vývoje. Zájímavé na této metodice je to, že částečně eliminuje roli projektového managera a zodpovědnost za dodávku nechává v rukou samotných vývojářů.

Na první pohled může to, co jsem uvedl znít „divoce“, ale už za pár dní jsem nabyl pocitu, „ze to může fungovat“.

Nejprve trochu terminologie. Samotný termín Scrum je odvozen od názvu tzv. mlýnu, který sportovní fanoušci mohou znát z rugby. Pro nesportovce (jako jsem třeba já)- jedná se o takový útvar, kdy se hráči postaví do zástupu a rozehrávají hru tím, že se mezi ně hodí míč a oni se o něj poperou. Dalšími termíny jsou pigs (prasata) a chickens (kuřata). Pigs jsou programátoři a chicken ti nad nimi (projekťáci, architekti, sponzoři projektu…).

Celý proces vývoje se dělí na tzv. sprinty, což jsou období dlouhá několik týdnů (obyčejně tři až čtyři, ale může to být i delší). Pro tento sprint existuje plán úkolů, který se připraví do tzv. backlogu. V rámci sprintu si programátoři berou jeden úkol za druhým a postupně je realizují. Důležité je, aby doba realizace jednotlivých úkolů trvala ideálně jeden den. Navíc programátoři mohou do backlogu přidávat další úkoly, které je nutné realizovat během vývoje.

Jak to celé funguje?

Na počátku každého sprintu/etapy se svolá plánovací schůzka. Výsledkem této schůzky je plán pro příští sprint v takové formě, že s ním souhlasí každý člen týmu. Tento plánovací meeting je naplánován na celý den a povinně se účastní všichni „pigs“. Mohou být pozváni i zástupci z řad „chicken“, ti však nejsou oprávněni diskutovat. Je také vhodné pozvat zástupce z řad „business vlastníka“ (zadavatel nebo analytik)

Tento meeting může být rozdělen do dvou částí. V první části se prochází jeden úkol backlogu za druhým a diskutuje se o tom, jak jej implementovat, co to má vlastně dělat apod. Jak bylo již uvedeno, právě pro tuto fázi je ideální, aby se této části meetingu zúčastnili i zástupci z business analytiků. Ti jsou tak však pouze od toho, aby zodpovídali dotazy.

V druhé části se jednotlivé úkoly ohodnocují body podle náročnosti. K tomuto účelu jsme s výhodou využili klasických hracích karet, kdy každý z členů měl k dispozici karty v hodnotě A, 2, 3, 5, 8 a K. Karty (kromě K) značí bodovou hodnotu, Král znamená „nelze realizovat“. Členové týmu u každého požadavku naráz ukáží kartu s jejich předpokladem (naráz proto, aby se nemohli ovlivňovat). Tuto „hru“ můžeme nazvat třeba „hodnotící poker“. Důležité je, aby ve výsledku všichni členové týmu souhlasili s výslednou bodovou hodnotou. Tyto hodnoty se zapisují ke každému požadavku a stávají se závaznými. V našem týmu jsme tyto dvě etapy sloučili do jedné a přišlo mi to efektivnější.

Při hodnocení je důležité určit si převodní jednotku – tedy to, co vlastně znamená právě jeden bod. U nás je problém, že se nám nepodařilo úkoly rozdělit na tak atomické úkoly, že by měl jeden zabrat maximálně jeden den. Stanovili jsme tedy, že jeden bod znamená 0,5MD.

Dalším důležitým krokem určení tzv. velocity, což je zjednodušeně řečeno výkonnost týmu. Ta se počítá v různých jednotkách. V našem případě ji přepočítáváme na body, které reflektují pracnost úkolu, kterou jsme si určili na plánovacím meetingu pomocí hodnotícího pokeru. Vlastní velocita pak říká, kolik těchto bodů jsme schopni zrealizovat během jedné iterace (sprintu).

Během vlastní iterace(sprintu) se každý den uspořádá schůzka, které se říká scrum a vede ji Scrummaster. Délka této schůzky je striktně omezena na 15 minut. Během této schůzky každý vývojář odpoví na tři otázky:

• Co jsi udělal od poslední schůzky?
• Co plánuješ udělat dnes?
• Vyskytly se nějaké překážky, které bránily dokončení Tvého předhozího úkolu?

Důležité je, že na této schůzce se případné problémy pouze identifikují, jejich řešení probíhá mimo scrum. Důvod je logický – nebudeme zdržovat ostatní členy týmu záležitostmi, které se jich přímo nedotýkají. A poslední věc: Scrumy je potřeba provádět ve stoje. Důvod je jednoduchý, relativně snadno se tím zabrání tomu, aby se účastníci scrumu rozpovídali (pokud nezabírá pořádat scrum ve stoje, pořádejte ho třeba v ruštině-uvidíte, že všichni budou rázem stručnější). Pokud je více týmů/scrumů, pořádá se ještě tzv. Scrum of Scrum. Na této schůzce Scrummasteři reportují problémy a status ze „svých“ scrumů. A ještě jedna důležitá věc ke scrumům. Scrumy jsou určeny pouze pro členy týmů-projekťáci, sponzoři apod. se zúčastnít mohou, ale nesmí do schůzky nikterak zasahovat.

Na konci sprintu se pak uspořádá schůzka, kde se zhodnotí uplynulá iterace a diskutují se problémy, které se vyskytly během právě uplynulé iterace a hledá se jejich řešení.

Výhodou této metodiky je to, že zapojíme programátory přímo do procesu vývoje, navíc programátoři získají část zodpovědnosti za realizaci díla, termíny a kvalitu. Díky tomu nemají pocit, že by byli jen cvičenými opicemi. Další celkem důležitou záležitostí je fakt, že manažeři projektu ztratí část pravomocí, které se deleguje přímo na projektový tým. Manager pak má pouze funkci kontrolní, což ne vždy může být pro projektového manažera akceptovatelné. S tím se pojí nejdůležitější věc na celém procesu zavedení této metodiky. Vedení projektu musí plně důvěřovat vývojovému týmu, tomuto procesu vývoje a nesnažit se zavádět do této metodiky postupy, které znají ze své běžné praxe.

Uvidíme na konci projektu, jestli nám tato metodika pomohla lépe a s větší efektivitou zvládnout tu obrovskou horu práce, kterou realizujeme-určitě pak podám report. A co Vy? Používáte nějaké agilní metodiky vývoje (nebo i konzervativní)? Pokud ano, jaké s nimi máte zkušenosti?