Ve svém předchozím článku jsem zahájil diskuzi o špatně vyvinutých návykech uvnitř scrum týmu, které nakonec povedou (dříve nebo později) k selhání při doručování. V tomto článku bych chtěl toto téma ještě jednou rozšířit a zaměřit se nyní na funkční procesy uvnitř týmu.
Ty jsou stejně důležité jako technická dokonalost týmu. I když jsou lidé uvnitř super zruční pro práci, kterou se chystají vykonávat, stále existují oblasti, které mohou jejich snahu o dokonalost zničit. A nebude to ani tak jejich chyba, jako spíše přímá odpovědnost za rozhodnutí projektového managementu a jejich schopnost sloužit týmu vhodnými procesy, které podporují tým s jasným záměrem a předvídatelnými činnostmi.
Table of Contents
Vysoce segregovaný tým s odlišnými dovednostmi
Představte si, že tým má šikovné vývojáře, dokonale nezávislé a se schopností dodržet své sliby a dodat dohodnutý obsah sprintu právě včas před koncem sprintu. I v tak dokonalém scénáři (což je stejně vysoce nepravděpodobné) bude mít tým problémy udržet krok s (stále rostoucími) funkcemi nevyřízených věcí, pokud budou dovednosti mezi členy týmu přísně odděleny.
Několik příkladů
- Tým má 1 nebo 2 inženýry DevOps, kteří jsou schopni provádět jakékoli změny v automatizovaných kanálech nebo se starat o služby uvnitř platformy, ale zbytek týmu o takových věcech nemá ponětí. Pak diskuse o těchto příbězích na ceremoniích skrumáže, jako jsou upřesňování, povede ke ztrátě času pro většinu týmu tím, že zůstane na schůzce bez jakékoli účasti a naopak – vývojář DevOps nebude mít žádný zájem o zbytek příběhů zaměřených na funkce a čas na schůzce bude také většinou ztracený.
- Pro celý tým je jeden databázový expert. V závislosti na složitosti a využití datových řešení v systému, který tým vyvíjí, může být tato osoba neustále zahlcena příběhy, které nemá šanci dokončit dostatečně brzy, zvláště když zohledníme své priority. Ještě horší je, že další příběhy budou muset také počkat, protože ty jsou závislé na zdroji dat, který databázové příběhy poskytují.
- Když je konkrétní produkt převážně orientován na backendový vývoj, je tam pro každý případ jediný front-end vývojář (protože čas od času je stejně potřeba nějaká malá změna i v UI aplikaci). V tom případě je opět většina scrumových ceremonií pro tohoto člena týmu ztrátou času, protože jeho znalosti jsou omezeny pouze na frontend a na ničem jiném nezáleží.
Kde to končí
V kterémkoli z výše uvedených případů je výsledkem to, že lidé buď plýtvají časem, nebo naopak nejsou schopni dohnat nevyřízenou poptávku. Blokují zbytek týmu v zahájení práce na dalších příbězích, nebo účinně snižují celkovou efektivitu scrum týmu, protože je příliš mnoho času, který není využit ve sprintu.
Tým však stále má tento počet vývojářů. Zvenčí není vidět (ani nechci být odhalen), že lidé uvnitř týmu nejsou schopni převzít některé příběhy jen proto, že jsou příliš orientovaní na nějakou konkrétní sadu dovedností. Nemohou tedy pomáhat ostatním členům týmu s příběhy, i když by to jejich kapacita umožňovala a priority příběhů by tomu také vyhovovaly.
Pro produktového vlastníka je dokonce obtížné sestavit nějaký smysluplný obsah sprintu pro tým, protože produktový vlastník musí vždy mít na paměti, kolik lidí může pracovat na každém jednotlivém příběhu a zda se do sprintu dostane více podobných příběhů současně. , nakonec je kapacita týmu přeplněná, i když ve skutečnosti existují lidé, kteří by na těchto příbězích mohli pracovat, ale nemají potřebné dovednosti, aby s nimi začali.
Řešení dilematu
Je to dilema, které je třeba vyřešit, a projektoví manažeři by měli vědět, jakou cestu zvolit. Konkrétně na výběr mezi:
- Mít mnoho full-stack vývojářů schopných pracovat na širším obsahu, ale ve skutečnosti nejsou odborníky na mnoho témat. Mohou tedy jít do šířky, ale ne hluboko. Pak může dodávka postupovat rychle, ale kvalita může utrpět.
- Mít specializované odborníky pro každou technologii, ale pak přijmout omezení a usilovněji pracovat na lépe přizpůsobeném obsahu tisku. Lidé pak mohou jít do hloubky a budovat skvělé příběhy, ale k příběhům bude třeba přistupovat postupně, takže jejich dodání bude trvat déle.
Slabý vlastník produktu
To není nutně „procesní záležitost“ z definice, ale beru to tak, protože vytváření solidních příběhů lze chápat jako proces, který by tým měl chtít mít pevný a kompatibilní s vývojovým týmem.
To, co myslím slabou stránkou, nemusí odkazovat na znalostní vlastnost osoby, ale spíše na schopnost produktového vlastníka sloužit týmovým příběhům, kterým vývojáři rozumí a které dávají jasný smysl z hlediska produktové mapy. Obojí je pro úspěšný scrum tým velmi důležité.
Pokud příběhy postrádají podrobnosti, aby vývojáři byli schopni jasně pochopit účel, funkční hodnotu nebo technická očekávání, pak mohou nastat v zásadě dva scénáře:
- Vývojáři postaví něco jiného, než co produktový vlastník skutečně chtěl. Je dokonce těžké to zachytit během samotného sprintu, protože většinou produktový vlastník neměl možnost sledovat průběh příběhů na tak podrobné úrovni a většinou PO bude jen očekávat, že se to stane (magicky).
- Vývojáři stráví příliš mnoho času objasňováním příběhů a diskutováním o nich znovu a znovu, než aby je začali budovat. To zahrnuje mnoho dalších výzev, opakovaných dohod a odkládání práce do pozdní fáze sprintu. Dostává se do bodu, kdy původní odhady příběhů již nelze považovat za přesné a příběhy není možné v rámci sprintu uzavřít a přecházejí do dalších sprintů. V horším případě se pak situace opakuje v následných sprintech.
Čas na sebereflexi
Obvykle je těžké si to přiznat, ale produktový vlastník by si měl najít čas na zamyšlení, podívat se na vytvořené nevyřízené příběhy a případně je porovnat s vizí produktové cestovní mapy, pokud mezi těmito dvěma stále existuje nějaké rozumné spojení – pokud vůbec nějaká cestovní mapa existuje. vůbec. Pokud ne, je to první věc, kterou je třeba vyřešit. Někdy je řešením přiznat, že produktový vlastník je příliš daleko od týmu a příliš daleko od vlastního cíle.
V takovém případě je třeba řešit část týmu s produktovým vlastníkem. Když už nic jiného, přivést do týmu solidního obchodního analytika orientovaného spíše na obsah týmu než na obchodní obsah (protože v tomto případě již máme produktového vlastníka) by mohlo být vhodnou možností, a to i za cenu zvýšené celkové náklady týmu.
Testování procesů bez pevné časové osy
Co když se testovací aktivity neřídí konkrétním harmonogramem ve scrum sprintu?
Na první pohled to může vypadat jako něco dobrého, co chceme pro agilní / scrum tým. Flexibilita je vždy vítána a zní dobře, když je prezentována venku.
Moje zkušenost ukazuje, že výsledkem této svobody je spíše chaos než flexibilita. Neznamená to, že řešením by mělo být vytváření „vodopádů uvnitř sprintu“ s vyhrazenými testovacími fázemi, které následují těsně po dokončení vývoje. V tomto případě to není v žádném případě správný přístup. Více si o tom můžete přečíst v mých příspěvcích o strategii testování scrumu a životním cyklu agilního testování.
Stále můžeme povolit určitou flexibilitu a zvolit plán testování tak, jak to vypadá nejvhodnější pro aktuální vývojový tým a dané vlastnosti produktu, který tým dodává. Existují však dva hlavní cíle, kterých by mělo být touto volbou dosaženo:
Pokud budou tyto podmínky splněny, tým se přirozeně přizpůsobí procesu montáže a harmonogram dodávek nebude ovlivněn neplánovanými prodlouženými testovacími aktivitami.
Nakonec je nejdůležitější spolehlivé a předvídatelné uvolnění sprintu, což mě přivádí k poslednímu bodu tohoto blogu.
Nedefinovaný proces vydání
Tohle je samozřejmá věc pro každý scrum tým. Ale kupodivu je to také obvykle jeden z nejvíce podceňovaných procesů.
Velmi často scrumový tým řekne, že uvolnění bude po každém sprintu, ale není to podloženo solidním procesem. To, co se pak stane, je ve skutečnosti spousta chaotických, nepředvídatelných aktivit, které se objeví během doby vydání. Najednou jsou všichni lidé zaneprázdněni „úkoly uvolnění“ a nikdo se nedokáže soustředit na pokračování ve vývoji nových příběhů sprintů. Metriky sprintu jsou vypnuté a uvolnění vypadá z pohledu 3. osoby (obvykle klienta) jako náhodná, nepředvídatelná aktivita.
Lidé se tak soustředí na nevyřízené položky, obsah sprintu, vývoj, testování a nakonec předvádění výsledků, že zapomínají, že jakmile s tím vším skončí, další sprint již probíhá a oni už ztrácejí čas.
Hledáte dobrý čas na uvolnění
Kdy přesně by tedy měl tým provést skutečné vydání do produkce? Jediná důležitá věc, na které nakonec záleží.
Odpověď na tuto otázku sedí v procesu, za předpokladu, že nějakou máte. Záleží na:
- složitost obsahu, který tým produkuje ve sprintech,
- trvání sprintu,
- počet ovlivněných součástí v systému
- počet lidí, kteří používají a požadují změny,
měl by být zaveden proces opakovaného uvolňování a v budoucnu by se měl dodržovat. Přesná pravidla procesu lze opět flexibilně definovat. Ale stejně jako u testovacích aktivit je to skalopevný zvyk, který je předvídatelný a naplánovaný na konkrétní dny v budoucnosti, takže je to něco, na co se lze spolehnout a na co odkazovat.
Možnosti Vybrat
Možnými formami takového procesu mohou být následující nebo jiné:
- 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 mít žádný obsah z úplně posledního sprintu, ale bude obsahovat příběhy z předchozích 2 sprintů.
- Poslední sprint před vydáním je vždy věnován testování obsahu z předchozích dvou sprintů.
- To neznamená, že vývoj během „testovacího sprintu“ bude zastaven; pouze říká, že obsah vyvinutý v tomto testovacím sprintu ještě nebude zahrnut do příští verze.
- Pokud již existuje dostatek automatických testovacích aktivit, snažte se provést uvolnění po skončení každého sprintu. Pak to musí být velmi přísný proces s oddanými lidmi zaměřenými na těch pár dní na 100 %. Stále by to nemělo nijak ovlivnit zbytek vývojového týmu.
- Můžete si také vybrat vydání jednou za měsíc nebo jednou za N měsíců, hlavně pokud to bude z pohledu koncových uživatelů v pořádku. To zvýší úsilí na straně testování pro každý sprint (protože obsah bude pro každou verzi větší). Ale na druhou stranu to bude znamenat menší množství opakovaných činností v průběhu času, což v tomto případě může mít pro tým výhody. Výsledkem je, že může týmu umožnit vytvářet více nových funkcí mezi vydáními, přestože funkce ve skutečnosti přijdou do výroby s pomalejší kadencí.
Ale jak již bylo několikrát řečeno, není tak důležité, který z těchto procesů bude vybrán. Mnohem důležitější je, jak dobře se tým pak tohoto procesu bude držet a udělá z něj tvrdý zvyk.
Můžete si také přečíst tohoto průvodce procesem a postupy správy vydání.