V předchozím článku jsem otevřel debatu o nezdravých návycích v rámci scrum týmu, které dříve či později povedou k neúspěchu v dodávání. V tomto textu bych chtěl na tuto problematiku navázat a detailněji se podívat na fungování procesů uvnitř týmu.
Tyto procesy jsou stejně klíčové jako technické dovednosti členů týmu. I když jsou všichni jednotlivci velmi kompetentní, existují aspekty, které mohou jejich snahu o dosažení dokonalosti zhatit. Nejedná se přitom o jejich přímou vinu, ale spíše o odpovědnost projektového managementu. Ten musí zajistit vhodné procesy, které tým podpoří v dosahování stanovených cílů s jasnými a předvídatelnými kroky.
Tým s úzce specializovanými rolemi
Představme si tým, kde jsou schopní vývojáři, pracují samostatně a plní sliby o včasném dodání dohodnutého obsahu sprintu. I v takovémto ideálním (a málo pravděpodobném) případě, může tým mít problém udržet krok s neustále rostoucím backlogem, pokud jsou specializace členů týmu striktně oddělené.
Příklady z praxe
- Tým má jednoho nebo dva inženýry DevOps, kteří jsou schopni provádět jakékoli úpravy automatizovaných procesů nebo spravovat služby v rámci platformy. Zbytek týmu o této oblasti nemá tušení. Diskuze o těchto úkolech na scrum setkáních, například při upřesňování, tak povede ke ztrátě času pro většinu týmu, která se nebude moci aktivně zapojit. Naopak, vývojář DevOps nebude mít zájem o zbytek úkolů, které jsou zaměřené na funkčnost, a čas na setkání bude taktéž z větší části promarněný.
- Tým má pouze jednoho experta na databáze. V závislosti na složitosti datových řešení v systému, na kterém tým pracuje, může být tento člověk neustále zahlcen úkoly a nemůže je včas dokončit, obzvláště s ohledem na priority. Další úkoly také musí čekat, protože jsou závislé na datech, která databázový expert vytváří.
- Pokud se produkt primárně zaměřuje na backend, má tým pouze jednoho frontend vývojáře (protože občas je potřeba provést nějakou malou úpravu v uživatelském rozhraní). V tomto případě je opět většina scrum setkání pro tohoto člena týmu ztrátou času, protože jeho znalosti jsou omezeny pouze na frontend.
Kam to vede?
Ve všech zmíněných případech dochází k plýtvání časem, případně k neschopnosti vyrovnat se s požadavky. Členové týmu blokují ostatní v zahájení práce na dalších úkolech, nebo snižují celkovou efektivitu scrum týmu, protože dochází k neefektivnímu využití času ve sprintu.
Na první pohled ale tým stále disponuje dostatečným počtem vývojářů. Navenek není vidět, že někteří lidé uvnitř týmu nejsou schopni pracovat na některých úkolech jen proto, že jsou příliš specializovaní. Nemohou tedy pomoci ostatním členům týmu, i když by to jejich kapacita dovolovala a priority úkolů by s tím souhlasily.
Pro product ownera je pak obtížné sestavit smysluplný obsah sprintu, protože musí brát v potaz, kolik lidí může pracovat na každém úkolu a zda se do sprintu vejde více podobných úkolů současně. V konečném důsledku je kapacita týmu vyčerpána, i když existují lidé, kteří by na těchto úkolech mohli pracovat, ale nemají potřebné znalosti.
Jak z toho ven?
Je to dilema, které je třeba řešit, a projektoví manažeři by měli vědět, jakou cestu zvolit. Konkrétně jde o rozhodování mezi:
- Mít mnoho full-stack vývojářů schopných pracovat na širším spektru úkolů, ale nemají expertní znalosti v mnoha oblastech. Mohou jít do šířky, ale ne do hloubky. Dodávka tak může být rychlá, ale kvalita může trpět.
- Mít specializované odborníky pro každou technologii, ale akceptovat omezení a více pracovat na lépe přizpůsobeném obsahu sprintů. Tito lidé mohou jít do hloubky a vytvářet skvělé úkoly, ale k úkolům se bude muset přistupovat postupně, což prodlouží dobu dodání.
Slabý Product Owner
Není to zcela „procesní záležitost“ v klasickém smyslu, ale chápeme ji tak proto, že vytváření solidních úkolů lze považovat za proces, který by měl být kompatibilní s vývojovým týmem.
Slabost neznamená nedostatek znalostí u dané osoby, ale spíše neschopnost Product Ownera dodávat týmu úkoly, kterým vývojáři rozumí a dávají smysl z pohledu produktové strategie. Oboje je pro úspěšný scrum tým zásadní.
Pokud úkolům chybí detaily, aby vývojáři jasně pochopili účel, funkční hodnotu nebo technická očekávání, mohou nastat dvě situace:
- Vývojáři vytvoří něco jiného, než co Product Owner zamýšlel. Je těžké to odhalit i během sprintu, protože Product Owner neměl možnost sledovat vývoj úkolů do detailu a většinou jen očekává, že se to nějak „samo“ vyřeší.
- Vývojáři stráví mnoho času upřesňováním úkolů a opakovanými diskusemi, namísto toho, aby se pustili do práce. To zahrnuje další komplikace, opakované domlouvání a odkládání práce na pozdější fázi sprintu. Dostanou se do bodu, kdy původní odhady úkolů již nejsou platné a úkoly není možné v rámci sprintu dokončit a přechází do dalších sprintů. V horším případě se tato situace v následných sprintech opakuje.
Čas na zamyšlení
Obvykle je těžké si to přiznat, ale Product Owner by si měl najít čas k zamyšlení, podívat se na vytvořené úkoly a porovnat je s vizí produktové strategie, pokud mezi nimi existuje spojení, a pokud vůbec nějaká produktová strategie existuje. Pokud ne, je to první věc, kterou je třeba napravit. Někdy je nejlepším řešením přiznat si, že Product Owner je příliš vzdálený týmu a svému vlastnímu cíli.
V takovém případě je nutné přistoupit k řešení s Product Ownerem. Najmutí zkušeného business analytika orientovaného spíše na obsah týmu než na business by mohlo být v takové situaci vhodné, i za cenu zvýšených nákladů.
Testování bez pevného časového rámce
Co když testovací aktivity nemají pevný harmonogram v rámci scrum sprintu?
Na první pohled to může vypadat jako něco pozitivního, co je pro agilní/scrum tým žádoucí. Flexibilita je vždy vítána.
Moje zkušenost ale ukazuje, že takováto svoboda vede spíše k chaosu, než k flexibilitě. Neříkám, že řešením by mělo být vytváření „vodopádů uvnitř sprintu“ s testovacími fázemi hned po dokončení vývoje. To není správný přístup. Více se o tom můžete dočíst v mých příspěvcích o strategii testování scrumu a životním cyklu agilního testování.
Stále je možné zachovat flexibilitu a zvolit plán testování, který se zdá nejvhodnější pro aktuální vývojový tým a vlastnosti produktu. Nicméně, měly by být splněny dva hlavní cíle:
Pokud jsou tyto podmínky splněny, tým se přirozeně přizpůsobí procesu a harmonogram dodávek nebude ovlivněn neplánovanými testovacími aktivitami.
Závěrem, nejdůležitější je spolehlivé a předvídatelné uvolňování sprintů, což mě přivádí k poslednímu bodu tohoto článku.
Nedefinovaný proces vydávání
To by mělo být samozřejmostí pro každý scrum tým. Ale překvapivě se jedná o jeden z nejvíce podceňovaných procesů.
Často scrum tým prohlašuje, že bude vydávat po každém sprintu, ale toto tvrzení není podloženo solidním procesem. Následkem je spousta chaotických a nepředvídatelných aktivit, které se objeví během doby vydávání. Najednou jsou všichni zaměstnáni „úkoly spojenými s vydáním“ a nikdo se nedokáže soustředit na další vývoj. Metriky sprintu nejsou správné a vydání vypadá z pohledu klienta jako náhodná, nepředvídatelná aktivita.
Tým se tak soustředí na backlog, obsah sprintu, vývoj, testování a prezentaci výsledků, že zapomíná, že jakmile s tím skončí, další sprint již běží a oni tak ztrácí čas.
Kdy je tedy ten správný čas pro vydávání?
Kdy by tedy tým měl reálně provést vydání do produkce? Jedná se o nejdůležitější otázku, na které nakonec záleží.
Odpověď na tuto otázku je obsažena v procesu, za předpokladu, že nějaký máte. Záleží na:
- složitosti obsahu, který tým vytváří během sprintu,
- délce trvání sprintu,
- počtu ovlivněných komponent v systému,
- počtu uživatelů, kteří vyžadují změny.
Měl by být zaveden proces opakovaného vydávání a tento proces by měl být dodržován. Přesná pravidla procesu lze opět flexibilně definovat, ale mělo by se jednat o stabilní proces, který je předvídatelný a naplánovaný na konkrétní dny, aby se na něj bylo možné spolehnout.
Možnosti volby
Možné formy tohoto procesu mohou být například tyto:
- Dokončete testování funkcí z aktuálního sprintu během následujícího sprintu a uvolněte obsah na konci tohoto sprintu (po dokončení testování). To znamená, že každé vydání nebude obsahovat nic z posledního sprintu, ale bude obsahovat úkoly z předchozích 2 sprintů.
- Poslední sprint před vydáním je věnován testování obsahu z předchozích dvou sprintů.
- Neznamená to, že vývoj v tomto „testovacím sprintu“ bude zastaven, pouze říká, že obsah vyvinutý v tomto sprintu nebude zahrnut v příští verzi.
- Pokud je automatizace testů na dostatečné úrovni, snažte se o uvolnění po každém sprintu. V tomto případě se ale musí jednat o velmi striktní proces s lidmi, kteří se mu budou plně věnovat. Stále by to ale nemělo nijak ovlivnit zbytek vývojového týmu.
- Můžete se rozhodnout pro vydávání jednou za měsíc nebo jednou za N měsíců, pokud to bude v pořádku pro koncové uživatele. To zvýší zátěž na straně testování pro každý sprint (protože obsah bude pro každé vydání větší), ale na druhou stranu sníží množství opakujících se činností, což může být pro tým výhodné. V důsledku toho může tým vytvářet více funkcí mezi vydáními, i když se funkce ve skutečnosti dostanou do produkce s pomalejší kadencí.
Jak už ale bylo řečeno, nezáleží na tom, který z těchto procesů si vyberete. Důležitější je, jak dobře se tým bude tohoto procesu držet a stane se z něj zvyk.
Můžete si také přečíst tohoto průvodce procesem a postupy správy vydávání.