Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily?

Transkript

1 Úvod do SCRUM!!

2 Co je to SCRUM! FRAMEWORK vs METODIKA Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? agilemanifesto.org

3 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.!

4 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

5 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.)

6 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

7 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

8 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á

9 ! 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!

10 Backlog!

11 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

12 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

13 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

14 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

15 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.

16 Sprint plannig! Zaměření Časový odhad Důležitost

17 Sprint plannig/sprint Backlog! Vzniká z Product backlogu výběrem user stories a stanovením jejich termínů (máme tzv. time box)

18 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

19 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

20 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ů! 45 člověko-dnů! = 40 % 50 člověko-dnů x 40 % = $ 20 story pointů na sprint$

21 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

22 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

23 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

24 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

25 Ří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

26 Burndown chart!

27 Burndown chart!

28 Sprint info! Většinou wiki, řídí a spravuje Scrum Master Nástěnka pro info se sprintem

29 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ší$

30 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???$

31 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

32 A a a! to je dnes vše...!