Úvod do SCRUM! !
Co je to SCRUM! FRAMEWORK vs METODIKA • Ken Schwaber a Jeff Sutherland ho mají za framework • Kde hledat detaily? – agilemanifesto.org – www.mountaingoatsoftware.com/scrum
Z čeho to je...! • Vychází z OOP, nepočítá s UML • Známé objekty s jasně definovaným chováním, rozhraním a odpovědností • Za každý objekt (množinu objektů) je zodpovědný konkrétní člen týmu • Typické jsou časté revize Google, SourceForge, Nokia atd.!
Předpoklady! • Výchozí – u projektu není možné dopředu předvídat procesy analýzy, designu a vývoje
• Nemůžeme plánovat obsah sprintu, proto to ani dělat nebudeme • Na jednom projektu může pracovat i více týmů • čas dodání (ukončení) je proměnlivý stejně jako obsah
SCRUM! • Klíčové jsou denní schůzky a komunikace • Složen z iterací (tzv. sprintů) s pevnou časovou délkou (2–6 týdnů) • Předpokládá malé týmy (3-12 členů) • Různé formáty Backlogu (produktových, sprintů apod.)
Role členů ve SCRUM!
• PIGS – osoby přímo související s vývojem • CHICKENS – uživatelé produktu, manažeři, bez odpovědnosti za vývoj
V reálu...! • Product Owner PIGS • Osoba odpovídající za priority • Stanovuje obsah sprintů • Definuje implementační detaily
• Scrum Master PIGS • Hlavní komunikátor mezi vývojem a okolím • Nesmí být programátor • Může se krýt s manažerem i analytikem • Odstínit programátory od okolního světa
Ti další, kteří do toho...! • Stakeholders CHICKEN • Zákazník a jeho zástupci
• Manažeři CHICKEN • Pomáhají vytvořit a nastavit prostředí
• Role zákazníka je užitečná, ale ne bezpodmínečně nutná
Backlog! • Product Backlog – První práce na projektu – Rozdělení projektu na menší části • User stories
!
– Obsahuje všechny scénáře, co má výsledek dělat, čili co zákazník chce Uživatel nemůže provádět DDL operace!
Backlog!
Backlog! • ID – unikátní identifikátor, aby jsme mohli jendotlivé user stories libovolně přejmenovat • Název – výstižný a stručný název, 2 – 10 slov • Důležitost – určí Product Owner, 10 nebo 150 • Časová náročnost – upravená Eulerova řada 1, 3, 5, 8, 13, 20, 40, 100! • Stručný popis obsahu sprintu, user story • Poznámky
Backlog! • Stanovení náročnosti – Vycházet z předpokladu, kolik miu to zabere, když bych nedělal nic jiného
• Volitelné položky Backlogu – Track – kde se bude výsledek používat – Components – dbs, server, klient, apod. – Zadavatel – Bug tracking ID
• Backlog na business úrovni – Přiřazují se indexy, hlavní úkol Product Ownera
Backlog! • Odpovědnost za vytvoření – Product Owner • Sdílený dokument pro všechny členy – Editovatelný více lidmi – Není součástí verzování
• Zkušební vytovření Backlogu – Excel nebo nějaké To-Do – Cíl: realizovat přihlašování na web
Sprint plannig! • Kritická část, první a nejdůležitější meeting • Výstupy sprint planning! – Cíl sprintu – Lidi v týmu – Product Backlog – Datum pro demo – Definovaný čas a místo pro stand-ups
• Aktivní účast Product Ownera
Sprint plannig! • Zjistit jestli máme vše připravené a je v čem dělat Product Backlog • Sprint planning meeting – i ten se plánuje Sprint planning meeting: 13:00 – 17:00 (10 minute break each hour) • 13:00 – 13:30. Product owner představí co se bude dělat a co je cílem sprintu, shrnutí product blackolgu. Stnoví se místo, datum a čas předvedení výsledku. •13:30 – 15:00. Team sestaví časové odhady a rozdělí položky backlogu tak, aby vyhovovaly. PO upraví důležitosti v Product Backlogu, okud je to nutné. Definuje se způsob Dema pro všechny klíčové položky. •15:00 – 16:00. Team vybere user stories, které budou obsahem sprintu. Spočítají celkovou rychlost řešení pro následnou kontrolu. •16:00 – 17:00. Stanoví se místo a datum denní stand-upů. Vytipují se položky pro příští sprint – návaznosti.
Sprint plannig! Zaměření
Časový odhad
Důležitost
Sprint plannig/Sprint Backlog! •
Vzniká z Product backlogu výběrem user stories a stanovením jejich termínů (máme tzv. time box)
Time-Box! • Termín do kdy musí být naimplementovány jednotlivé části časově! • Odhady jsou naplánovány s ukončením přesně v den odevzdání! • Délka sprintu se může měnit a před prvním sprintem je tzv. nultý sprint – Není podmínkou – Úkolem je ověřit reálnost odhadu – Obsahem je triviální úkol, který se pak vyvíjí dál
Sprint plannig! • Cíl sprintu – jednoznačný, jednoduchý a odlišitelný – více teamů, více cílů, více produktů... – každý musí vědět, kam se směřuje a proč
• Stanovení rychlosti řešení sprintu – Podle citu, Podle výpočtu rychlosti
Sprint plannig! • Stanovení člověko-dnů – Jak zjistíme kolik máme člověko-dnů – Odhad rychlosti sprintu (dostupné člověko-dny) x (focus factor)! – Stanovení focus factoru (aktuální rychlost) / (dostupné člověko-dny)! ! 18 story pointů! = 40 % 45 člověko-dnů!
50 člověko-dnů x 40 % = $ 20 story pointů na sprint$
Big points! • • • • •
Krátký sprint! Krátký cyklus Časté review Uživatelský feedback Méně času na špatný vývoj Rychlejší úpravy
Dlouhý sprint! • Více času a prostoru na udělání chyb • Více času a prostoru na opravu chyb • Víc volnosti v definování potřeb týmu
Pravidla spolupráce! • Omezená doba (délka sprintu)
Kde je definovaná??! • Time-Box 1. Návrh 2. Vývoj 3. Prezentace 4. Review • Pravidelné denní stand-upy
Stand-Upy! • Proč ráno??
Je lepší se ptát co budeme dělat,! než co jsme udělali! • Pevně definovaná MAX délka – 15 min. • Vede ho Scrum Master • členové týmu řeknou co udělali včera, budou dnes, zítra a co jim brání v práci • Product Owner se může účastnit, ale nemůže mluvit
Stand-Upy! • Priority 1. Termín splnění cíle a dema 2. Seznam stories ve sprintu, schválené týmem 3. Vyplněné položky sprint backlogu 4. Spočítané odhady rychlosti sprintu 5. Stanoveno místo a čas denních stand-upů 6. Stories rozebrané na jednotlivé úkoly
Řízení sprintu! • Modrá linka představuje rychlost řešení ve sprintu • Nestandardní průběh = odchýlení od ideální linie, řeší Scrum Master • Přesuny úkolů v Product i Sprint Backlogu smí provádět pouze Scrum Master • Formy Sprint backlogu – v excelu • Automaticky generované burndown charty • Náhled, odstup
– Bug Track – Fyzická tabule – TaskManager
Burndown chart!
Burndown chart!
Sprint info! • Většinou wiki, řídí a spravuje Scrum Master • Nástěnka pro info se sprintem
Bug Track a Product Backlog! • Jak zavést bug track do plánování sprintu 1. Product Owner je začlení v rámci plánování sprintu mezi User Stories 2. Product Owner vytvoří User Stories přímo vázané na bugy (jméno_bugu-důležitost) 3. Oprava bugů se řeší mimo sprint a stanoví se čas na bug fixing 4. Zalčlenění Product Backlogu do Bug Tracku
Není stanoveno, co je lepší$
Sprint end! • Předvedení produktu zákazníkovi – Nedokončené vlastnosti skryty – Prezentujeme pouze hotové věci – Na základě prezentace se udělá review vzhledem k Backlogu i Time Boxu sprintu – Zákazník i manažeři ví, jak moc nestíháme a jak se to projeví na budgetu...
Dotazy???$
Review! • Výhody a silné stránky – Jednotlivé sprinty – pružná reakce na změny v průběhu projektu – Svoboda při hledání optimálního řešení – Vycházíz OOP – Odhad pracnosti projektu, ne času
• Nevýhody a slabé stránky – Ani ne metodika jako spíš framework – Kooperace s dalšími metodikami – Odlišné pojetí vývoje – Ne všem vyhovuje způsob práce
A a a ! to je dnes vše...!
