Zdržují vás dlouhé porady a mítinky? Odhalte tajemství agilní práce

Co je to ta tajemná agilita, proč je nyní tak moderní a žádaná a jaké jsou předpoklady správně organizovaného agilního týmu? Několik následujících odstavců se bude snažit vám na tyto otázky odpovědět.

Proč agilně?

Protože doba se nám opravdu velice zrychlila a člověk/klient nechce čekat půl roku nebo i déle na něco, co si objednal už loni.

Chce vidět alespoň kousek hned nebo co nejdříve. Spokojí se s tím, že „ochutná“ kousek nyní, další kousek třeba již za měsíc a takto se postupně dostane k celé své objednané „porci“.

Největší výhoda agilního, přírůstkového (iterativního) vývoje a dodávání je, že můžete kdykoliv říct, že chcete něco jinak, a tato změna nebude znamenat kompletní přeorganizování a přepracování již hotové práce, tedy zbytečné náklady navíc.

Jak to začalo? Přirozeně

Kdokoli se pohybuje kolem IT projektů, ví, že ještě před pár lety byl nejčastějším projektovým standardem tzv. waterfall čili řízení projektu po jednotlivých blocích, od analýzy přes návrh, vývoj, testování, nasazování až po předání do provozu.

Pojďme si to projít na konkrétním příkladu: velká korporace se rozhodla, že chce nový firemní intranet. Vypsala proto výběrové řízení na dodavatele, protože projekt nemohla zajistit vlastními kapacitami. Vybrala vítěze a nastartovala projekt.

V jeho první, analytické části přišli do firmy byznys analytici a začali zkoumat klienta a jeho potřeby, co vlastně přesně chce, aby jeho intranet uměl. Všechno si zapsali, vyrobili 150stránkový dokument zvaný byznys analýza, který měl spoustu textu, grafů, schémat, a celá tato fáze zabrala většinou dva až tři měsíce.

Ukázka, co všechno může zahrnovat zjednodušená byznys analýza. Zdroj: Pixabay.com

Poté se tento dokument schválil do „výroby“ a nastoupila armáda vývojářů, kteří podle tohoto zadání celý intranet začali vyrábět.

Už po pěti měsících tvrdé dřiny měli první verzi, kterou postupně ukazovali nejprve vlastním testerům a poté klientovi. Ten tedy po devíti měsících viděl, co si vlastně objednal.

Bohužel zároveň většinou zjistil, že minimálně polovinu věcí chce jinak, a zadal tedy změnový požadavek, který vedl buď k navýšení ceny, nebo k prodloužení projektu v čase. Změny se zapracovaly, došlo na finální testování a jednoho dne byl nový intranet spuštěn mezi řadovými zaměstnanci.

Od výkopu po spuštění uběhl klidně celý jeden rok. Z praxe víme, že teprve tito zaměstnanci objeví spoustu chyb. S původním intranetem totiž byli zvyklí nějak pracovat a ten nový se najednou ovládá jinak a nemohou tam rychle najít to, co zrovna potřebují.

Tajemné slůvko scrum

Takovýchto projektů proběhly, probíhají a budou probíhat v českém i světovém IT miliony.

Nicméně postupem času si všichni uvědomují, že je nutné zrychlit a jít s výrobkem, ať je to cokoliv, k opravdovým zákazníkům co nejdříve. Tím firmy získávají co nejdříve zpětnou vazbu, tu mohou zapracovat a zase co nejrychleji dodat hotový, již vylepšený produkt.

A hle, zrodil se nám agile. Agilních metodik a přístupů je mnoho, ale zřejmě nejrozšířenější a nejznámější je pro řízení projektů manažerská metodika Scrum (přeloženo z angličtiny to znamená skrumáž, pozn. red.).

Jeho výhodou je předvídatelnost a odhadnutelnost práce, díky čemuž je Scrum oblíbený u stabilních firem, agentur, velkých společností. Podívejme se nyní na to, z čeho a z koho se skládá a jak vlastně funguje.

Tři klíčové role

Scrum rozlišuje tři hlavní role – Scrum master, product owner a Scrum team. Pojďme je projít.

• Scrum master je bystrý, všímavý a komunikačně schopný organizátor, který neustále dohlíží na to, aby celý tým spokojeně pracoval, nebyl rušen a měl vždy v zásobníku dostatek dobře promyšlených nápadů a úkolů.
  V praxi je to většinou bývalý klasický „projekťák“, který zvládá komunikaci s ředitelem firmy i s juniorním testerem. Organizuje všechny scrumové seance/mítinky a funguje jako SPOC (single point of contact). Dělá bariéru a zároveň komunikátora mezi okolním světem a týmem.
• Product owner, jak název napovídá, je osoba, jež vymýšlí a připravuje to, co se vlastně má vyrobit. Má k tomu pečlivě organizovaný a přehledný seznam, jemuž se říká backlog, tedy zásobník práce. Je to člověk, který zastupuje klienta, takže jedná v jeho zájmu a chce mu co nejrychleji dodat to, co si objednal.
• Scrum team je tvůrčí tým, to jsou ty ruce, které všechno vyrobí. Běžně jsou to vývojáři, kodéři, testeři, analytici atp.

Nejběžnější scrumový tým se skládá většinou z pěti až deseti lidí. Méně i více je na škodu a tým s více než deseti lidmi již není tak agilní a efektivní.

Obecné schéma fungování metodiky Scrum. Zdroj: Uniberasoft.com

Hlavní stavební prvky

Stejně jako klasický waterfall projekt, i projekty s agilním vývojem mají své artefakty.

Pod tímto pojmem se skrývají (převážně) fyzické výstupy či dokumenty, které sledují průběh projektu. Nicméně oproti vodopádovým projektům jsou tyto výstupy mnohem živější, upravují se častěji a jsou obsahově řádově kratší, tedy pro rychlý vývoj praktičtější.

Pojďme na jednotlivé typy artefaktů:

Backlog – ten už jsme nakousli výše. Představte si jej jako seznam všech úkolů, zásobník práce, který je potřeba vyřešit nebo vyrobit a dodat. Položky, jež jsou nahoře, mají nejvyšší prioritu a musí se na nich začít pracovat co nejdříve.
Výsostným správcem je pouze product owner, ale úplně každý má právo přispět a dodat svůj nápad, svoji myšlenku. Tu potom product owner zhodnotí a rozhodne se, klidně po poradě s týmem, zda se nápad bude realizovat, nebo ne, a určí jeho prioritu.

Sprint – jde o časovou, ucelenou jednotku, nejčastěji dvoutýdenní blok, který má jasný začátek i konec a v ideálním případě platí, že co si na začátku tým naplánuje, to taky na konci dodá klientovi.

Sprint backlog – jde o tu část backlogu, která je náplní jednoho bloku vývoje – sprintu. Prostě seznam úkolů a práce pro jeden sprint.

Increment – nehezké slovo, jejž můžeme nahradit českým ekvivalentem přírůstek. Je to přesně ten kousek hotového produktu, který se dá už nějakým způsobem použít.
Představte si jej například jako stěrače v autě – má to již tu ovládací páčku, motorek i vlastní stěrače, a když se to celé připojí k elektrice, stěrače stírají. A z takovýchto podobných kousků (inkrementů) je složen celý výsledný produkt – v našem případě auto.

Burn-down-chart – něco shořelo, že? Naštěstí ne. Jde jen o propracovaný graf, který nám ukazuje, jak si vedeme v plnění jednotlivých úkolů během sprintu.

Scrum board – jedná se o nástěnku, nejlepší je opravdu stará dobrá tabule nebo zeď a nové moderní post-it lístečky. Každý člen týmu má svůj řádek, své přidělené úkoly (co úkol, to lísteček) a ty postupně přelepuje mezi jednotlivými sloupci (TO DO – IN PROGRESS – DONE), aby bylo jasné, co už má hotovo, na čem dělá a co teprve bude dělat.
Nástěnka by měla být veřejná, aby i člověk mimo projekt mohl jedním pohledem zjistit, jak si tým vede a co už má hotové.

Seance aneb klíčová je komunikace

Agilita dovoluje mnohem pružnější komunikaci mezi zákazníkem a dodavatelem (ať už se jedná o interní, či externí vztahy), nicméně i tato komunikace musí mít svůj řád.

Neznamená to totiž, že všechno se může pořád měnit, ale jasně udává, kdy je vhodný moment pro případný zásah.

Scrumové mítinky neboli seance tedy pomáhají držet správný směr a zároveň ukazují, kdy je dobré zasáhnout a směr poupravit. I seance mají svoje stavební prvky:

Planning – jde o naplánování další práce pro následující sprint. Product owner určí sprint goal, tedy hlavní cíle, kterých musí být dosaženo, a tým si rozebere jednotlivé „lístečky“ s úkoly. Scrum master poté oficiálně zahájí sprint. Tento mítink by neměl trvat déle než jednu hodinu.

Grooming – slouží k tomu, aby vývojový tým zhodnotil a dal zpětnou vazbu na nápady, které do týmu přinesl product owner. Ten si například vymyslí, že by chtěl všechna tlačítka a další aktivní prvky na všech obrazovkách přemalovat, zvětšit a zároveň jim přidat nové funkce. Myslí si, že se to zvládne za jeden sprint, a tým mu to buď potvrdí, nebo vyvrátí, případně mu vysvětlí, proč to je, nebo není jednoduché. Rovněž i grooming by ideálně neměl trvat déle než hodinu.

Stand-up – je asi nejznámější pojem z celého agilního vývoje. Jde o velice svižný synchronizační mítink, který by měl ideálně trvat právě tolik minut, kolik je členů na stand-upu.
Osmičlenný, skvěle organizovaný tým tedy zvládne tento mítink za osm minut. Každý člen totiž během své minuty slávy řekne jen to, co dělal včera, čemu se bude věnovat dnes a zda má nějaké překážky nebo problémy. Tyto překážky si Scrum master zaznamená a vyřeší je AŽ po skončení tohoto mítinku, protože ne všechny zajímají tytéž potíže. Výhoda je, že na denní bázi ví každý člen týmu, co se v projektu děje (na rozdíl od týdenních statusů). Hlavním cílem stand-upu ovšem není mikromanagement jednotlivých členů, ale především zjištění, co bude dělat tým jako celek v nejbližších hodinách.

Demo – po skončení sprintu následuje demo. Na demo chodí zástupci klienta, klidně může přijít i samotný klient, prostě lidi mimo projekt, a těm se předvádí, co tým zvládl udělat během posledního sprintu.
Klienti můžou dodat zajímavé reakce i zpětnou vazbu, diskutují s týmem, přinášejí podněty. Časově demo zabere zhruba hodinu, v případě velkého a aktivního obecenstva i více, maximálně však dvě hodiny.

Retro – neboli retrospektiva je interní mítink členů týmu, kde zhodnocují svoji vlastní práci a přístup k ní. Předávají si pozitivní i rozvíjející zpětnou vazbu na sebe i na tým. Sdělí si, co je baví, co ne, s čím by chtěli začít, s čím skončit. Na konci se určí tři až čtyři hlavní výstupy, těm potom Scrum master určí odpovědnou osobu a ta do další retrospektivy zajistí nápravu. Tento mítink by opět neměl trvat déle než naši magickou jednu hodinu.

Více času na práci

Pokud tedy vezmeme ideální tým, správně naplánovaný dvoutýdenní sprint a dobře promyšlený backlog, můžeme mít vyhráno.

Jednoduše se dá spočítat, že není potřeba trávit denně dvě až tři hodiny schůzkováním a rokováním o projektu, ale stačí nám jeden planning, jeden grooming, jedno demo, jedno retro a deset denních stand-upů.

Celkem tak na mítincích strávíme maximálně tři hodiny týdně. Rozdíl, že? Scrum se dokonce ujal jako účinný nástroj a pomocník i mimo IT svět.

Univerzální nástroj

Běžně se tak setkáváme s tím, že firemní pravidelné porady se odehrávají formou stand-upů.

Management firmy neplánuje pětiletky, ale spíše krátkodobé cíle, které obratem zpětně vyhodnocuje. A zpětná vazba probíhá formou interních retrospektiv, týmy se potkávají častěji, ale po výrazně kratší dobu a nikdo není z dlouhých porad otrávený.

Scrum je tedy skutečně univerzální způsob vývoje, a pokud je dobře organizován, uspoří mnoho času i prostředků.

Jeho největší výhodou je, že extrémně rychle reaguje na změny a dodá vám jen to, co opravdu chcete. Naopak klade vyšší důraz na organizaci týmu a zapojení jednotlivců než standardní „vodopádové“ vývojové postupy – určitě to není a ani nesmí být chaos.