Přejít k navigační liště

Zdroják » Různé » Agilní vývoj: Scrum

Agilní vývoj: Scrum

Články Různé

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

Nálepky:

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.

Komentáře

Subscribe
Upozornit na
guest
15 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
bzuK

Fandím, tleskám, tisknu!

Dundee5

Supr článek. Díky, Jirko!

dc

Vybrony clanok, len priznam sa nic zasa take objavne mi nedal. Je to pre mna akurat taky trochu iny pohlad a inak pomenovane tie iste veci. Osobne si myslim ze kazdy vyvojar a sw project manager, mozno aj nevedomky, k niecomu podobnemu v praxi dospel a dopracoval sa (mozno mierne ine ale podobny princip). Je fajn ze je to spisane a ze zacinajuci team sa moze z toho poucit (aj ked asi kazdy si peklo terminov a odovzdavania musi prejist sam a popalit sa :-)) ale v konecnom dosledku to je stale len teoria.

Osobne ja som narazal vzdy na dva problemy a myslim ze tie budu v kazdom systeme a koli nim aj ma velka vecsina projektov problem s casom.Ten prvy, ktory tu bol aj popisany ale tazko sa v praxi dosahuje je zakazanie zmien zadania po starte vyvoja. A druhy moznost povedzme tych 6 hodin v kuse pracovat a sustredit sa bez vyrusovania a vytrhavania od prace.

Asi bude tazke zmenit zauzivany postoj ze sw je predsa „soft“ tak sa moze menit hoci kedy aj pocas vyvoja a v hocijakom rozsahu s predstavou ze to nejak zasadne neovplivni cas vyvoja.

xx

V článku říkáte, že je třeba odhadnout čas. Nicméně, co když je součástí aplikace i nějaký složitější problém, se kterým jsme se setkali poprvé a řešení bude třeba vymyslet (nevíme, jak dlouho to bude trvat), jak v takovém případě odhadnout čas.

Například děláme aplikaci pro přípravu rozvrhů do školy. Zadá se, jaké předměty je třeba rozvrhnout, jaké třídy jsou k dispozici + další omezení jako, kdo kdy z učitelů má čas a aplikace vygeneruje rozvrh. Navrhnout uživatelské rozhraní je docela snadné, jádrem programu je ovšem plánovací algoritmus a nikdo neví, jak dlouho bude trvat ho naprogramovat, aby dával slušné výsledky.

Co v podobných případech napsat jako odhad času?

Jiří Knesl

K problému s odhadováním

1) odhadování se často řeší pomocí tzv. „planning pokeru“. Jednotliví členové týmu odhadují náročnost kroků nutných k implementaci. Pokud se někdo příliš odchýlí, zjištuje se, proč to odhadl tolik odlišně.

2) ve Scrumu dostáváte z backlogu úkoly, které často trvají třeba 4 hodiny, 6 hodin, málokdy přes 12 hodin. Pokud nejste schopni rozepsat implementaci takového algoritmu na úkoly po (dejme tomu) 6 hodinách, nemáte dostatečnou analýzu a nemůžete správně odhadnout čas.

3) Příprava rozvrhů skutečně není jednoduchý algoritmus. Může se tedy i stát, že čas přesáhne víc než 1 iteraci. Přes tuto iteraci byste časový odhad stejně neprovedli.

4) První 2 iterace je běžné, že se časové odhady úplně ustřelí, než se zjistí skutečná velocity týmu, pak už je odhadování přesnější.


V případě vaší firmy bych zvolil zkrácené iterace (třeba 1–2 týdny) a pokusil bych se sepsat product backlog po malých krocích (kratších než 1 člověkoden). Rychle zjistíte velocity, naučíte se odhadovat krátké kroky a předběžný časový odhad.

Problémem je ale dotlačit zákazníka (je-li to pro 1 zákazníka na míru), aby byl ochoten odhadovat, fakturovat a pracovat v krátkých iteracích.

xx

Díky za odpověď a těším se na další díl seriálu.

.mx.
Martin Malý

Příště prosím uveďte takto stručnou odpověď alespoň nějakým úvodem – např. že „k odhadu času lze použít nástroj Planning Poker“. Takto to vypadá jako spamový komentář.

fredy

dobry clanocek, dik.
Existuju nejaka metodika, ked pracujem na projekte sam?
Tiez by som v tom chcel mat poriadok a prehlad, takisto chcem pracovat co najefektivnejsie, nerobit nic zbytocne, dodat produkt vcas apod.

Jiří Knesl

Já sám na svou organizaci používám Getting Things Done a několik agilních technik. Hodně inspirace jsem nasbíral v Getting Real (o kterém vyjde něco příští týden).

Vyzkoušejte, třeba to bude fungovat i u Vás. Každý člověk má ale jiné potřeby.

fredy

Dakujem, GTD sa snazim s vacsim ci mensim uspechom pouzivat :-)
Tesim sa na ten Getting Real, snad ma to posunie zase o krok dalej…

metak

A systemove ukoly, ktore se netykaji uzivatelskych funkcii ako napriklad tvorba databazy,tvorba Data Access vrstvy a rozne architektonicke ukony sa ties radia medzi user stories ?

Jiří Knesl

Je to individuální. Obecně by vám to asi nikdo nezakázal, v praxi se toto asi nestane. Už proto, že samotný DAL nezvyšuje business-hodnotu.

Respektive určí se user-stories a kroky, které jsou nutné k jejich implementaci. Tedy např.vytváření DAL musí být nutné pro nějaký user-story (a to bude téměř stoprocentně). Takže se vytváření DAL dostane do project backlogu jako jedna z podmínek implementace jiných vlastností.

Změny v architektuře se vejdou do fáze refaktoring a jako takové by se měly provádět na konci každé iterace (pokud je stará arch.nevyhovující).

pho

Jakym zpusobem a v jake fazi se rozbijeji user stories na jednotlive tasky a kdo hodnoti jejich narocnost?

pht

Pokud chapu dobre tak chcete delit story na tasky (nebo pod-story). Da se to delat pred zacatkem iterace, nebo i v prubehu, dulezite je obeznameni zadavatele (zakaznik, nebo nekdo v jeho roli). S tim, ze obvykle pod-story/task sam o sobe neprinasi prodatelnou hodnotu, a mel byste byt schopen nejakou jejich mnozinu mit hotovou do konce iterace.

Narocnost stanovuje vzdy implementator (tedy vyvojar). Muze se klidne stat, ze soucet odhadu novych ukolu nesedi s puvodnim. Byl to jen odhad a ten se prave upresnil.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.