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.