Agilní vývoj: Scrum

disk vývoj development

Po minulém úvodu, kde jsme si představili agilní metodiky a techniky obecněji, nastal čas podívat se na pravděpodobně nejznámější metodiku agilního programování, která nese název Scrum. Kdo je Scrum Master? Kdo jsou kuřata a kdo prasata? A proč? Vše se dozvíte v dnešním pokračování.

Seriál: Agilní vývoj (3 díly)

  1. Agilní vývoj: Úvod 11.12.2009
  2. Agilní vývoj: Scrum 18.12.2009
  3. Agilní vývoj: Getting Real 23.12.2009

Tato pravděpodobně nejznámější agilní metodika se hodí do týmů od čtyř do patnácti lidí. V ideálním případě by měli být na jednom místě (v jedné místnosti), ale vyskytují se i případy, kdy se Scrum provozuje napříč světem. Samotná metodiky se rozšířila na začátku devadesátých let a u jejího vzniku stáli Ken Schwaber a Jeff Sutherland, kteří základně nastavili délku iterace na 30 dní a zavedli backlog a další artefakty, které budou zmíněny dále v textu.

Role účastníků Scrumu

Ve Scrumu figurují dvě skupiny. tzv. Pigs a Chickens. Toto rozdělení vyplývá z povídky o praseti a kuřeti. Rozdíl mezi prasetem a kuřetem na projektu, do kterého vkládá prase maso a kuře vejce je v tom, že prase je “zapojeno”, zatímco kuřete se problém “pouze týká”. Proto je i ve Scrumu zvykem rozdělovat zúčastněné osoby do těchto skupin:

  • tzv. Pigs (osoby, které přímo souvisejí s vývojem aplikace)
  • tzv. Chickens (uživatelé produktu, manažeři, kteří přímo nezodpovídají za vývoj)

Scrumtoon
(Vztah prasat a kuřat názorně. Zdroj: Implementingscrum­.com)

Mezi Pigs patří tyto role:

  • Product Owner je osoba, která zodpovídá za priority, za to, co se bude v příštím sprintu
    implementovat a určuje implementační detaily.
  • Scrum Master pracuje jako ten, kdo má programátory odstínit od okolního světa. Řídí
    vývojáře, ale zároveň se stará o to, aby jim fungovaly počítače, měli dostupný software, který potřebují, řeší spory apod. Scrum Master a manažer se mohou krýt, zároveň může být Scrum Master i analytik. Je ale zakázáno, aby byl Scrum Master zároveň programátor, v takovou chvíli by nebyl schopen odfiltrovávat programátory od rušivých vlivů – byl by sám zranitelný. Pro tuto roli se jednoznačně hodí Project Manager.

Mezi Chickens patří následující role:

  • Stakeholders – lidé od zákazníka, testeři, připomínky zvenčí
  • Managers – tedy osoby, které pomáhají nastavit prostředí, ale nejsou ani vývojáři, ani Product
    Owneři, ani Scrum Masteři

Při Scrumu je užitečná (není to bezpodmínečně nutné, ale tento postup patří k oblíbeným) přítomnost zákazníka při vývoji. Pak se zákazník účastní diskuzí o vývoji, odpovídá průběžně na otázky a pomáhá tak vyvíjet skutečně užitečný produkt.

Workflow celého projektu

Zahájení nového projektu začíná vizí výsledku. Hledá se výčet vlastností, které má systém obsahovat, dané vlastnosti se odhadují, sepisují se takzvané User Stories (případy použití systému). Této fázi se říká Release Planning.

Ukázka User Story

Jako uživatel CMS
- Můžu nahrávat fotografie.
- Nahrané fotografie můžu oříznout.
- Do fotografie můžu vložit vodoznak.
- Po provedení ořezu a vodoznaku se fotografie zobrazí.

Všechny takto sepsané User Stories se sepíší pod sebe do takzvaného Product Backlogu. Product Backlog tedy obsahuje všechny scénáře, které systém zahrnuje. Následně se Product Backlog seřadí podle priority (tuto činnost provádí Product Owner). Jednotlivým úkolům se přiřadí časové náročnosti (často se používá bezrozměrná jednotka, tzv. body). To proto, že na začátku projektu není známa rychlost týmu. Do prvního sprintu se pokusí programátoři odhadnout, kolik úkolů dovedou z product backlogu stihnout během jedné iterace (tzv. sprintu). Úkoly se odebírají od nejdůležitějších. První jednu až dvě iterace se vývojáři samozřejmě netrefí – není totiž známa rychlost týmu.

Ještě před zahájení normálního vývoje v iteracích proběhne tzv. nultá iterace. V té se tým zaměří na prvotní implementaci nějakého triviálního úkolu, na kterém bude dále pokračovat vývoj. Nultá  iterace nebývá podmínkou, vždy je ale nutná nějaká příprava týmu, probíhají případná školení, volí se nutní lidé do týmu, vybírá se vhodná platforma apod.

Zajímá vás Zend Framework nebo unit testování? Chcete se dozvědět víc? Autor článku Jiří Knesl pořádá školení na tato témata. Více informací naleznete na stránce školení Zend Frameworku.

Workflow jedné iterace

Projekt byl rozčleněn do jednotlivých User Stories, bylo zvoleno, které User Stories jsou předmětem sprintu a byl stanoven termín dokončení. Tento termín je označen jako Time Box. Do konce Time Boxu musí být požadované vlastnosti implementovány. Odhady se stanovují tak, aby byla práce dokončena přesně v den odevzdání, tedy nenechávají se ani rezervy, ani se nečeká rychlejší práce. Tento postup vyplývá z myšlenky “dáte-li týmu jakýkoliv termín, tým čas vždy celý vyčerpá.”

Jednotlivé User Stories, vlastnosti, které se mají implementovat, se přesunuly z Project Backlogu do tzv. Sprint Backlogu, seznamu kroků aktuální iterace. Zákazníkovi není za žádnou cenu umožněno změnit zadání. Změny jsou možné pouze v čase mezi iteracemi. Existují týmy, které Product Ownerovi dovolí vyměnit úkol ve Sprint Backlogu za jiný s identickou obtížností. Motiv toho, že není dovoleno měnit zadání za běhu je naprosto klíčovou podmínkou Scrumu. Programátor se jen díky tomu může soustředit na svou práci, na dosahování cílů a odevzdávání práce v termínu.

Pokud existuje nutnost práce i na jiných projektech, je možné to řešit tak, že se vyhradí například 6 hodin denně pro práci na sprintu a 2 hodiny na práci na jiných úkolech. Nezasahování do vyhrazeného času vývojáře, vedou k tomu, že lze velmi zpřesnit časové odhady toho, co vývojář
stihne, jaká je jeho aktuální rychlost a zda situace nasvědčuje tomu, že své úkoly stihne odevzdat do konce sprintu.

Další podmínkou agilních metodik (a tedy i Scrumu) je zákaz práce přesčas. Odpočinutý zaměstnanec pracuje lépe, dělá méně chyb a dokáže se snáze soustředit na svou práci. Více se k tématu vyjadřuje Ronald E. Jeffries.

Každodenním (většinou ranním) rituálem je tzv. Daily Scrum. Při něm se všichni členové týmu velmi kráce (často i ve stoje) sejdou se Scrum Masterem, popíšou, co dělali včera, co budou dělat dnes a zda jim něco brání v práci. Setkání se může zúčastnit více lidí (třeba Product Owner), není jim ale dovoleno mluvit – to smí pouze tým a Scrum Master. Jak sprint pokračuje, ubývají úkoly ve Sprint Backlogu. Podle toho, co zbývá, se kreslí takzvaný Burndown Chart.

Scrum ilustrace

V tomto ukázkovém Burndown Chartu bylo dodrženo naprosto přesně zadání a tým celou dobu pracoval tak, jak se od něj očekávalo. Takový Burndown Chart ale nebývá obvyklý. Většinou dochází v průběhu práce k různým odchylkám, některé úkoly se daří řešit rychleji, jiné pomaleji.

Ukažme si burndown chart, kdy se nejdříve pracovalo rychleji, pak ale došlo k výraznějšímu zpomalení a tým nestihl odevzdat práci tak, jak očekával:

Scrum ilustrace

Většinou se burndown chart zobrazuje ve 2D, ale klíčový je pouze pro určení, jak rychle se vyvíjí. Je z něho patrné, zda je potřeba upravit Project Backlog, nebo zda nastaly nějaké problémy. Lépe je to vidět na následujícím grafu (zdroj: Wikipedia)

Scrum ilustrace

Takovou situaci by měl Scrum Master řešit tak, že vypočítá, jaká je rychlost (Velocity) týmu, dále by pak vrátil některé úkoly ze Sprint Backlogu do Project Backlogu tak, aby byly na konci hotovy všechny úkoly.

Pokud tým pokračuje příliš rychle, přidá Scrum Master další úkoly z Product Backlogu do Sprint Backlogu. Pokud je tým příliš pomalý, řeší Scrum Master důvody, proč se nedaří pracovat stanovenou rychlostí. Nelze-li zrychlit, Scrum Master přesune úkoly zpět ze Sprint Backlogu do Product Backlogu tak, aby rychlost práce vycházela přesně na termín Sprintu. Tyto přesuny nesmí dělat nikdo jiný – zejména ne Product Owner, tedy zákazník!

Po dokončení sprintu se předvádí produkt klientovi. Vlastnosti, které se nestihly dokončit, jsou skryty, klient tedy uvidí pouze dokončenou práci. Na jejím základě se rozhodne, co se bude dělat dál. Klient ví, které úkoly se nestihly a může se rozhodnout, zda se dokončí (což se stává většinou, protože tyto úkoly bývají obvykle rozpracovány a jejich opuštění by znamenalo smazat práci na nich strávenou).

Příští pokračování se bude zabývat metodikou Getting Real, která do agilního programování tak úplně nepatří, ale své místo v tomto miniseriálu rozhodně má, už jen proto, že se věnuje práci v malých týmech, a bude tedy mnohým čtenářům Zdrojáku bližší. Zároveň si probereme některé agilní techniky.

Jiří Knesl se zabývá hlavně Scrumem a správným vývojem software (prevence chyb, vyšší produktivita).

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 15

Přehled komentářů

bzuK Fandím, tleskám, ...
Dundee5 Díky
dc fajn
xx Odhad času pro složitější problémy
Jiří Knesl Re: Odhad času pro složitější problémy
xx Re: Odhad času pro složitější problémy
.mx. Re: Odhad času pro složitější problémy
Martin Malý Re: Odhad času pro složitější problémy
fredy pekne
Jiří Knesl Re: pekne
fredy Re: pekne
metak User Stories
Jiří Knesl Re: User Stories
pho Rozbijeni user stories na tasky
pht Re: Rozbijeni user stories na tasky
Zdroj: https://www.zdrojak.cz/?p=3138