Prvky scrumu

Chris Sims je americký spisovatel a kouč, specializující se na agilní metodiky a vedení týmů. Je autorem knihy Prvky scrumu (The Elements of Scrum), která se stala bestsellerem v oblasti projektového řízení.

Chris má více než 20 let zkušeností v oblasti vývoje softwaru a vedení týmů, a pracoval pro řadu významných společností včetně Microsoftu a IBM. Je také členem Scrum Alliance, organizace zaměřené na podporu a rozvoj agilních metodik.

Chris se věnuje také psaní a vzdělávání, a pravidelně přispívá do odborných časopisů a blogů.

Buďte přizpůsobiví a lépe pracujte díky scrumu

Myslíte si, že máte nejlepší metodu pro organizaci projektu? Je to klasický omyl, zejména v oblasti vývoje softwaru. Každý tým má své vlastní preference a představy: návrháři to chtějí tak, programátoři jinak – a v tom chaosu zůstává klient stranou.

Hlavní je, že při vývoji skvělých softwarových produktů neexistuje žádný pevně stanovený postup, žádná dokonalá cesta od A do Z. Existuje však několik triků, které vás dovedou co nejblíže k dokonalosti.

Dnešní týmy musí být flexibilní a agilní, připravené přizpůsobovat se momentálním nápadům a výzvám, které jim vstoupí do cesty. Musíte si vytvořit plán, pak ho zahodit a za pochodu vytvářet další, přičemž nesmíte ztrácet ze zřetele konečný cíl.

Jak to udělat? Zahoďte ty staré jednotvárné modely a přijměte scrum – agilní, flexibilní systém, který promění způsob vašeho myšlení a revolučně změní váš vývojový proces.

Tradiční systémy vývoje softwaru jsou neflexibilní a hrozí u nich překračování nákladů

Tradice mohou mít své kouzlo, ale pokud jde o vývoj technologií, mají jen málo příznivců. Technologie je třeba neustále aktualizovat, aby zůstaly relevantní; ve skutečnosti je aktuálnost zásadní nejen pro technologie, ale také pro procesy používané k jejich vytváření.

Jeden ze systémů vývoje se nazývá vodopádová metoda, což je proces vývoje softwaru od dokončení k zahájení. V takovém systému softwarový tým obvykle zkompletuje požadavky, vytvoří návrh, napíše kód, otestuje a pak dodá hotový produkt.

Aspekt „od dokončení k zahájení“ je v tomto procesu klíčový. Činnost A musí být dokončena předtím, než se začne pracovat na činnosti B. Například nelze začít testovat návrh, dokud není dokončeno kódování.

Proč mají lidé a organizace tuto metodu rádi?

Oddělením jednotlivých kroků vývoje se usnadňuje vytváření harmonogramu a plánování. Manažeři často dávají přednost vodopádovému přístupu, protože věří, že jim umožňuje větší přesnost při vytváření harmonogramu a přidělování rozpočtů.

Vodopádová metoda však není příliš spolehlivá. Software je často příliš složitý produkt na to, aby byl plně navržen před zahájením vývoje. Pokud tedy požadujete dokonale navržený produkt, zůstane vám jen malý prostor pro změny během vývoje.

I když je tedy možné, aby dokonalý návrh plynule přešel do dokonalého vývojového procesu, obvykle k tomu dochází pouze v případě, že vyrábíte statický objekt, jako je například automobil. V tomto příkladu byste navrhli každý prvek automobilu a pak se při výrobě do písmene řídili těmito pokyny pro návrh.

Naproti tomu vývoj softwaru je prostě příliš složitý.

Takže i když návrháři mohou přijít s něčím, co považují za dokonalý produkt, při aplikaci návrhů určitě nastanou komplikace. Čísla hovoří jasnou řečí: pouze 16 % projektů prováděných vodopádovou metodou dodrží termíny dokončení, zatímco 31 % je zrušeno a 53 % překročí rozpočet!

Jak se takovému úskalí vyhnout u vlastních projektů? Přečtěte si to v dalších kapitolách.

Rozdíl mezi agilním a vodopádovým procesem je plné integraci součástí procesu

Na rychlém a často nepředvídatelném technologickém trhu musíte být flexibilní, abyste mohli rychle přizpůsobit svůj vývojový proces. To znamená zabránit tomu, aby jeden prvek projektu zdržoval jiný.

Jak ale udržet vývojový vlak v pohybu?

Zvolíte agilní proces – strategii vývoje, která přijímá změny jako příležitost k růstu.

Agilní týmy pracují do značné míry stejným způsobem jako týmy využívající vodopádový proces: shromažďují požadavky, vytvářejí návrhy, píší kód, testují a dodávají produkt. Nedělají však to, že by čekaly na úplné dokončení každého kroku, než začnou s dalším.

Místo toho agilní týmy pracují na každém kroku procesu po malých kouscích a dodávají klientovi části produktu. Tento proces tým opakuje stále dokola, dokud není produkt dokončen. Tento cyklus se nazývá iterace.

Představme si tým vyvíjející software pro úpravu fotografií. Při použití agilního procesu může tým nejprve dokončit funkci, která změní barevnou fotografii na černobílou. Tým by tuto malou funkci pošle klientovi, který by mu nabídne zpětnou vazbu. Tým pak může na základě zpětné vazby pracovat na vylepšení funkce v další iteraci.

Nemyslete si však, že agilní procesy jsou jen „mini“ vodopády; jsou to plně integrované procesy. To znamená, že agilní týmy přistupují ke každému projektu jako ke kompletnímu celku, a ne jako k odděleným částem, jak to dělají týmy pracující za použití procesu od dokončení k zahájení.

Agilní tým tak zajišťuje, že jeho návrháři a programátoři přemýšlejí o svých příspěvcích jako o vzájemně se doplňujících – místo aby mysleli pouze na „svou část“ a ignorovali zbytek.

Mezi vodopádovými a agilními procesy je ještě jeden zásadní rozdíl. Ve vodopádovém procesu klient zadá své požadavky na software při zahájení projektu a není s ním znovu konzultován, dokud není produkt dodán. Při agilním procesu však tým v průběhu procesu neustále komunikuje s klientem a umožňuje mu požadavky v průběhu procesu upravovat nebo měnit.

Čtyři základní hodnoty agility stanovují, co si zvolit jako prioritu a mít tak efektivní výsledky

Jedete po své obvyklé trase do práce, když vidíte, že křižovatku před vámi blokuje nehoda. Co uděláte? Počkáte, až se nehoda odstraní, nebo odbočíte na neznámou silnici, abyste prozkoumali, jak ji objet?

Pokud jste řekli, že odbočíte a prozkoumáte cestu, pak jste již získali jednu ze čtyř klíčových hodnot agility. Každá hodnota představuje prioritu nebo volbu mezi různými přístupy.

První hodnotou agility je upřednostnění jednotlivců a interakcí před procesy a nástroji. To znamená, že lidé zapojení do projektu jsou důležitější než proces, který projekt řídí.

V podstatě by nástroje a procesy měly sloužit lidem, nikoli naopak.

Druhou hodnotou je upřednostnit funkční software před důkladnou dokumentací. Jistě, dokumentace je důležitá, ale neměla by převyšovat samotný produkt. Pokud vás tedy tlačí čas, soustřeďte svou energii na to, abyste vytvořili skvělý produkt, a netrapte se pořizováním desítek dokumentačních fotografií.

Třetí hodnotou je upřednostnit spolupráci se zákazníkem před vyjednáváním o smlouvě. Je nezbytné, aby smluvní dohoda mezi vývojovým týmem a klientem zůstala otevřená. Jen tak si můžete být jisti, že vyrobíte a dodáte to, co zákazník skutečně chce.

Agilní týmy pořádají pravidelné schůzky a udržují otevřenou komunikaci v každé iteraci. Smlouvy jsou sice důležité, ale nezaručují, že budou dodrženy standardy kvality klienta – avšak otevřená a plynulá komunikace ano.

A konečně čtvrtá hodnota upřednostňuje reakci na změny před dodržováním plánu. Plán ukazuje, že víte, kam chcete jít a jak se tam dostat; ale pokud dojde k náhlé změně (jako třeba k té dopravní nehodě), budete muset být flexibilní i agilní, abyste se přizpůsobili a dosáhli svých cílů za pochodu.

Když se budete držet čtyř hodnot agility, budete schopni nastavit projektové priority adaptivně a zároveň efektivně.

Scrum je proces, který využívá hodnot agility a zaměřuje vývojový procesu softwaru na cíl

Nyní, když znáte hodnoty agility, budete potřebovat systém, ve kterém je budete implementovat – a právě v tom vám scrum pomůže.

Ale co přesně je „scrum“?

Scrum je proces vývoje softwaru, který uplatňuje čtyři hodnoty agility při vytváření nových produktů prostřednictvím série sprintů – přičemž každý ze sprintů obsahuje všechny kroky procesu vývoje, od zjišťování požadavků až po dodání produktu klientovi.

V rámci každého sprintu řešíte pouze malou část většího projektu, což může znamenat, že období sprintu může trvat jen týden nebo i měsíc.

Jak tedy sprint zahájit?

Každý sprint vzniká na schůzce k plánování sprintu, která se skládá ze dvou částí: v první se určí, jaké mají být výstupy sprintu, a v druhé se vymyslí, jak jich dosáhnout.

Nejprve zjistěte, co váš tým potřebuje dodat jako výsledek na konci sprintu. Tuto část vede vlastník produktu, tedy člen týmu, který na základě přání klienta rozhoduje, co a kdy bude vytvořeno.

V našem příkladu softwaru pro úpravu fotografií může vlastník produktu říci, že tento týden tým provede sprint na černobílé funkci produktu a příští týden se zaměří na jinou funkci.

Vlastník produktu je také zodpovědný za prezentaci ideálního uživatelského zážitku, kterému se říká příběh (více se o něm dozvíte v další části).

Jakmile je první část odsouhlasena, druhá část schůzky pro plánování sprintu je věnována rozhodování, jak tým dosáhne svých cílů.

Za tímto účelem si tým stanoví určité úkoly, například provedení rozhovorů s uživateli nebo testování. Je důležité, aby žádný úkol nezabral více než půl dne, takže velké úkoly by měly být rozděleny na mnoho menších.

Zkušenosti a příběhy uživatelů stojí v centru zájmu sprintů

Klíčovým aspektem každé schůzky k plánování sprintu je vymýšlení skvělého uživatelského zážitku. Jak ale scrumy tento prvek do procesu začleňují? Prostřednictvím uživatelských příběhů.

Příběhy jsou jednoduchým způsobem, jak ukázat, jak lidé produkt skutečně používají. Říká se jim uživatelské příběhy, aby tým udržel pozornost u koncového zákazníka, a ne u vlastníka produktu, designéra nebo kodéra.

Každý uživatelský příběh má tři složky: kdo je cílový uživatel, jaký je uživatelský požadavek a proč je uživatelský požadavek nezbytný.

Zde je příklad šablony příběhu: Jako (typ uživatele) chci (něco udělat), aby vznikla (nějaká hodnota). Vyplněním prázdných míst může tým přijít s následujícím: Jako uživatel chytrého telefonu s fotoaparátem chci, aby fotografie, které pořídím, byly automaticky upravovány softwarem telefonu, což mi ušetří čas.

Aby mohl tým naplánovat úspěšný sprint, musí odhadnout, jak složitý – nebo jak „velký“ – je uživatelský příběh. Čím větší příběh je, tím více času na vývoj je potřeba. Například sledování celého nákupního procesu uživatele je velký příběh, který vyžaduje měsíční sprint, zatímco vývoj nových záhlaví je malý příběh, na který potřebujete týden.

Jak tedy zjistit velikost uživatelského příběhu?

Jedním ze způsobů je zaměřit se na relativní velikost příběhu – tedy na to, jak „velký“ je ve vztahu k ostatním příběhům ve vašem projektu. Příběh je koneckonců abstraktní pojem; neexistuje způsob, kterým bychom přesně změřili, jak je „velký“.

Podívejte se tedy na své projekty a porovnejte uživatelské příběhy. Najděte, co by podle vás měl být „nejmenší“ příběh, a pak poměřte ostatní příběhy s tímto nejmenším příběhem.

Můžete dokonce vymyslet speciální systém číslování jako referenční nástroj pro váš tým, abyste rychle rozpoznali velké příběhy od těch menších. Pokud je například sprint na redesign záhlaví nejmenší na seznamu projektů, můžete sprint nákupního procesu měřit jako „čtyři redesigny záhlaví“.

K udržení agility a rychlosti reakce sprintu využijte tři typy scrumových schůzek

Váš tým tedy právě zahájil nový projekt a všichni říkají, že mají jasno v rozsahu a očekáváních, a usilovně pracují. Uplyne měsíc a vy se sejdete, abyste si navzájem vyměnili připomínky – a v tu chvíli začnou problémy.

Tři členové týmu dokončili své úkoly, dva se zasekli na hloubání o problému a nemohou ho dokončit a jeden člověk se rozhodnul změnit svůj úkol takovým způsobem, že narušil práci všech ostatních.

Zní vám to povědomě?

Metoda scrum používá tři typy schůzek, aby se podobným situacím předešlo.

Zaprvé, každodenní scrum identifikuje změny tak, jak k nim dochází „v reálném čase“. Jedná se o velmi krátkou každodenní schůzku, jejímž cílem je udržet tým na správné cestě tím, že identifikuje překážky, abyste je mohli ihned řešit.

Každodenní scrum by se měl konat každý den ve stejnou dobu – maximálně 15 minut – a měli by se ho účastnit pouze členové týmu.

Na schůzce se každý člen týmu podělí o to, čeho dosáhl předchozí den, co bude řešit dnes a pojmenuje všechny překážky, které by mohly zpomalovat pokrok.

Dalším typem schůzky je hodnocení sprintu. Ta se koná na konci každého sprintu pro klienty, kteří na ní mohou poskytnout zpětnou vazbu. Zde může váš tým ukázat klientovi svou práci; ujistěte se, že si vlastník produktu a ostatní členové týmu všímají reakcí klienta.

Reakce klienta umožní vlastníkovi produktu upravit produktový backlog – seznam položek k realizaci, které jsou seřazeny podle priority.

Poslední typ se nazývá retrospektivní schůzka. Zde se můžete s týmem ohlédnout za ukončeným sprintem a prodiskutovat, co se všichni naučili. Tato schůzka by se měla konat po hodnocení sprintu, ve stejný den, kdy je sprint dokončen.

Během této schůzky by se váš tým měl také zamyslet nad tím, jak nové poznatky uplatnit v dalším sprintu. Tým může například zjistit, že je nutné změnit proces testování, aby byl efektivnější.