Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ostatni:scrum [2023/03/18 23:27]
tomas
ostatni:scrum [2023/03/19 08:53] (current)
tomas
Line 6: Line 6:
 ====== Agile ====== ====== Agile ======
 Agile je jeden project management metodologie, podobně jako waterfall model. Umožňuje měnící se požadavky, časté dodávky, iterativní a inkrementální přístup.\\ Agile je jeden project management metodologie, podobně jako waterfall model. Umožňuje měnící se požadavky, časté dodávky, iterativní a inkrementální přístup.\\
-Waterfall - (inicializace, planování, provádění, monitorování a kntrola, uzavírání) změny drahé, musí se zmrazit požadavky, komplexní vše naplánovat, mění se technologie, těžké získat dohodu. Agilni metodologie: Scrum, Extrémní programování, Crystal, FDD, DSDM, AUP, ScrumBan...+Waterfall - (inicializace, planování, provádění, monitorování a kntrola, uzavírání) změny drahé, musí se zmrazit požadavky, komplexní vše naplánovat, mění se technologie, těžké získat dohodu. Agilni metodologie: Scrum, Extrémní programování, Crystal, FDD, DSDM, AUP Agile Unified Process, ScrumBan...
  
 XP Extreme Programming - Test driven development, Refactoring, Pair programming, Simple design, Collective Code Ownership, Soding standards, Continuous integration, System metaphor, Sustainable pace, Whole team, Planning games, Small releases, Onsite customer, Energized team (chodit domů včas, ...), Informative workspace. Jestli je něco z toho dobré, tak to děláme vždy. XP tým zahrnuje zákazníky, vývojáře a testery, independent, selforganizing, multifunctional. Types of customers: Product managers, Domain experts, Interaction Designers, business analysts. Cross platform skills, 4-10 členů týmu, Testeři nemají specialní roli, 1 tester na 6 vývojářá XP Extreme Programming - Test driven development, Refactoring, Pair programming, Simple design, Collective Code Ownership, Soding standards, Continuous integration, System metaphor, Sustainable pace, Whole team, Planning games, Small releases, Onsite customer, Energized team (chodit domů včas, ...), Informative workspace. Jestli je něco z toho dobré, tak to děláme vždy. XP tým zahrnuje zákazníky, vývojáře a testery, independent, selforganizing, multifunctional. Types of customers: Product managers, Domain experts, Interaction Designers, business analysts. Cross platform skills, 4-10 členů týmu, Testeři nemají specialní roli, 1 tester na 6 vývojářá
Line 12: Line 12:
 Crystal - Frequent delivery, Reflective improvement, Osmotic communication, distribuční listy kam chodí komunikace, access to expert users. Crystal - Frequent delivery, Reflective improvement, Osmotic communication, distribuční listy kam chodí komunikace, access to expert users.
  
-DSDM - Dynamic Systems Develepment Method - www.agilebusioness.com. Principy: User involvments, Requirements evolve and timeboxed, Early delivery, Follow80-20 role delivered only 80%, nothing is built perfectly first time. Planning philosophy: Daný čas a cena, zákazník si vybírá naimplementované věci.\\+DSDM - Dynamic Systems Develepment Method - www.agilebusioness.com. Principy: User involvments, Requirements evolve and timeboxed, Early delivery, Follow80-20 rule - 80% hodnoty z 20% práce, nothing is built perfectly first time. Planning philosophy: Daný čas a cena, zákazník si vybírá naimplementované věci.\\
 Timeboxing in MoSCoW prioritization - Time limit is fixed, tasks are fit into timebox (day, week, release). Must Should, Could Won't done now. Every timebox we decide what is M, S, C, W. Must<50%, Couls 10-20% Timeboxing in MoSCoW prioritization - Time limit is fixed, tasks are fit into timebox (day, week, release). Must Should, Could Won't done now. Every timebox we decide what is M, S, C, W. Must<50%, Couls 10-20%
  
Line 37: Line 37:
   - neustálé zlepšování a učení   - neustálé zlepšování a učení
  
-Agile project management (APM)+== Agile project management (APM) ==
 Envision: product vision, project scope (requirements), project team, project approach - technika\\ Envision: product vision, project scope (requirements), project team, project approach - technika\\
 Speculate: epics - high lever requirelements, user storeies, release plan\\ Speculate: epics - high lever requirelements, user storeies, release plan\\
Line 59: Line 59:
  
 **Balances score cards**, obsahuji future orientation metrics Employee metriky, (business values delivered by scrum - saving and revenue, new features, faster delivery), excelence metrics - predictibility of time to feature, prodductivity of team, quality metrics - defects, issues, customer orientation metrics - protuct performance, uptime, satisfaction, loyality **Balances score cards**, obsahuji future orientation metrics Employee metriky, (business values delivered by scrum - saving and revenue, new features, faster delivery), excelence metrics - predictibility of time to feature, prodductivity of team, quality metrics - defects, issues, customer orientation metrics - protuct performance, uptime, satisfaction, loyality
 +
 +==== Backlog ====
 +Seznam pracovních úkolů pro projekt, tým, produkt, sprint. Typy úkolů:
 +  * user story - dává hodnotu, user perspective
 +  * Epic - velké user story na několik sprintu, upravidla obsahuje několik storek
 +  * Feature - jedinečná vlastnost, která se dodá do produktu - jedna nebo více storek
 +  * úkoly na adresování rizik (SPIKE story)
 +  * Bug - úkoly na opravy chyb
 +  * Task
  
 ==== User story ==== ==== User story ====
-benefit for user or stakeholder+User storka je popis požadavků z uživatelské perspektivy. Přináší benefit pro uřivatele nebo investora.\\ 
-INVEST model k popsání User story - Independent, Negotiables, Valuable, Estimable, Small, Testable + 
-Independent na ostatních user story, Negotiable - dobře popsané, Valuable - hodnota pro business, Estimable - dost informací potřebných k udělání, Small dost malé na dodělaní ve sprintu+INVEST model k popsání User story - Independent, Negotiables, Valuable, Estimable, Small, Testable.\\ 
 +Independent na ostatních user story, Negotiable - dobře popsané, Valuable - hodnota pro business, Estimable - dost informací potřebných k udělání, Small dost malé na dodělaní ve sprintu, Testable - acceptance test
  
 Story card: Nadpis, kód, popis kdo co chce a proč, acceptance criteria, priorita Story card: Nadpis, kód, popis kdo co chce a proč, acceptance criteria, priorita
  
 Acceptance criteria od PO. Jak se to chová za kterých podmínek - funkční, nebo nefunkční kriteria (bezpečnost, rychlost) Acceptance criteria od PO. Jak se to chová za kterých podmínek - funkční, nebo nefunkční kriteria (bezpečnost, rychlost)
- 
-==== Backlog ==== 
-  - Epics, stories, features 
-  - Epic velke user story, které může obsahovat více storek 
-  - Feature - unikatní funkcionality - jeno nebo více storek 
-  - úkoly na adresování rizik (SPIKE story) 
-  - úkoly na opravy chyb 
- 
-Backlog: 
-  * user story - dává hodnotu, user perspective 
-  * Epic - velké user story na několik sprintu, obsahuje několik storek 
-  * Feature - jedinečná vlastnost, která se dodá do produktu 
-  * Task 
- 
  
 Charakteristika úkolů v backlogu - DEEP: Charakteristika úkolů v backlogu - DEEP:
-  Detailed properly +  Detailed properly 
-  Estimated +  Estimated 
-  Emergent +  Emergent 
-  Prioritized+  Prioritized
  
 Rozdělění storek na měnší: Rozdělění storek na měnší:
-  Operational boundaries: create, retrieve, update, delete +  Operational boundaries: create, retrieve, update, delete 
-  data boundaries: uživatel, produkt, ...  +  data boundaries: uživatel, produkt, ...  
-  Separate exceptions +  Separate exceptions 
-  Research vs implementation +  Research vs implementation 
-  separate non functional requirements: performace, scalability, security+  separate non functional requirements: performace, scalability, security
  
 Story mapping: minimally marketable feature - zobrazení klíčových aktivit jako diagram Story mapping: minimally marketable feature - zobrazení klíčových aktivit jako diagram
Line 104: Line 100:
 Prioritizace - value risk matrix - 1) high risk, high value, 2) low rirsk, high value 3) low value low risk (do or not to do) low risk, low value, Kano model : Mandatory, linear - story které udělají zákazníka spokojeným, Exciters, delighters - zákazník neočekává. Value score - poměr mezi ziskem a pokutou. priorita=hodnota/(cena*riziko) Prioritizace - value risk matrix - 1) high risk, high value, 2) low rirsk, high value 3) low value low risk (do or not to do) low risk, low value, Kano model : Mandatory, linear - story které udělají zákazníka spokojeným, Exciters, delighters - zákazník neočekává. Value score - poměr mezi ziskem a pokutou. priorita=hodnota/(cena*riziko)
  
 +User persona - Hypotetický uživatel - umožnuje se vcítit do uživatele. Jméno, role, učel co chce udělat, jeho běžné činnosti
  
  
-Estimace+User story format: Co kdeo chce, co chce udělat a proč, detaily, acceptance criteria 
 +As a accountant, I waould like accoubt screen to be simple that I do not have to scroll up and down 
 + 
 +Definition of Done - obecne pravidlo, co platí pro všechny user story (plně implementováno, otestovano, bez otevřených defektů, automatické testy, bezpečné a rychlé, dokumentace …) 
 + 
 +Definition of Ready - pravidla pro to, že jsme připraveni pracovat na storce - rozumíme? Máme akceptační kritéria? Máme na to dost lidí/času? Jsou vyřešené závislosti? Ohodnotili jsme úkol? non-functional požadavky jsou definované? 
 +Acceptance criteria - pro story 
 + 
 +Minimaly marketable feature mmf 
 + 
 +== Hodnota user story == 
 +Business value: New revenue, incremental revenue, retained revenue (aby neodešli), operational efficiency — top priority 
 + 
 +Benefit cost analysis 
 +Payback period - za kolik let se investice vrati: 100000 investice, 25000 naklady, 4 roky navrat 
 +Returnon investment 25k/100k=0.25 
 +Net present value npv 
 +Internal rate of value irr 
 + 
 +== Estimace ==
 Storypoints - univerzální, nezávislé na člověku Storypoints - univerzální, nezávislé na člověku
 1 small 1 small
Line 113: Line 129:
 linear or fibonaci, if betveen, then higher linear or fibonaci, if betveen, then higher
  
-Ideal time absolutni cas na storku - lisi se clovek od clovekalepe se vysvetli mimo tym+Metoda estimace: Affinity estimation vytřídíme všechny story cards od nejmenších po největšípotom podobné storky ohodnotíme pomocí fibbonaciho posloupností, nebo t-shirt velikostí (S, M, L, ...) - relativní velikostí
  
 +Planning poker, read story point, than discuss, than every choose size, than discussion, than agreement on size www.planningpoker.com
 +fun, involves all, effective, discuss risks
  
 +Ideal time - absolutni cas na storku - lisi se clovek od cloveka, lepe se vysvetli mimo tym
  
 ===== Role ===== ===== Role =====
Line 132: Line 151:
  
 ===== Ceremonie ===== ===== Ceremonie =====
-Backlog Refinement/Grooming detailní dolaďování věcí v backlogu: prioritizace, estimace, popis, klasifikace do Epiku/featur\\ +== Backlog Refinement/Grooming == 
-Sprint Planning - závazek na dodán, cíl sprintu určuje PO, tým si rozdělí úkoly pro sprint a mezi sebou. Objem úkolů buď podle historické výkonnosti týmu (velocity-driven approach), nebo jak se tým dohodne a zaváže (commitment-driven approach). Tým se musí shodnout a pochopit úkoly a akceptační kritéria. Pokud si tým bere moc, nebo málo, SM chce zdůvodnění. Musí se respektovat dovolená a svátky\\ +detailní dolaďování věcí v backlogu: prioritizace, estimace, popis, klasifikace do Epiku/featur\\
-Daily stand-up/daily scrum - Tým + SM. Co se stalo včera, co se bude dělat dnes, co je za problémy. Neslouží k micromanagementu, mělo by být hodnotné pro všechny sdílet i poslouchat\\ +
-Sprint Review/Demo - tým, SM, PO, mohou být akcionáři či jiná audience. Cíl je prezentovat produkt sprintu, získat odezvu a případně přidat nové úkoly do backlogu. Výsledek musí být příjmán pozitivně, stejně tak zpětná vazba. Nemá se moc diskutovat nové řešení, ale očekáváni.\\ +
-Retrospective - tým + SM - zviditelnit problémy a najít cestu, jak to dělat lépe. Tým by měl vzít zlepšení pro sebe, ne jen obviňovat. Příležitost i k oslavám.\\+
  
 +== Sprint Planning ==
 +závazek na dodán, cíl sprintu určuje PO, tým si rozdělí úkoly pro sprint a mezi sebou. Objem úkolů buď podle historické výkonnosti týmu (velocity-driven approach), nebo jak se tým dohodne a zaváže (commitment-driven approach). Tým se musí shodnout a pochopit úkoly a akceptační kritéria. Pokud si tým bere moc, nebo málo, SM chce zdůvodnění. Musí se respektovat dovolená a svátky
  
 +== Daily stand-up/daily scrum ==
 +Tým + SM. Co se stalo včera, co se bude dělat dnes, co je za problémy. Neslouží k micromanagementu, mělo by být hodnotné pro všechny sdílet i poslouchat\\
  
-User persona - Hypotetický uživatel - umožnuje se vcítit do uživatele. Jménoroleučel co chce udělatjeho běžné činnosti+== Sprint Review/Demo == 
 +týmSMPO, mohou být akcionáři či jiná audience. Cíl je prezentovat produkt sprintu, získat odezvu a případně přidat nové úkoly do backlogu. Výsledek musí být příjmán pozitivně, stejně tak zpětná vazba. Nemá se moc diskutovat nové řešení, ale očekáváni.\\
  
-Story +== Retrospective == 
-INVEST independent na jiných věcechNegotiale (need, not solution), Valuable - hodnota popsaná ve story, Estimable, Small, Testable - acceptance test+tým + SM zviditelnit problémy a najít cestu, jak to dělat lépe. Tým by měl vzít zlepšení pro sebene jen obviňovat. Příležitost i k oslavám.\\
  
-User story format: Co kdeo chce, co chce udělat a proč, detaily, acceptance criteria 
-As a accountant, I waould like accoubt screen to be simple that I do not have to scroll up and down 
  
-Definition of Done - obecne pravidlo, co platí pro všechny user story (plně implementováno, otestovano, bez otevřených defektů, automatické testy, bezpečné a rychlé, dokumentace …) 
- 
-Definition of Ready - pravidla pro to, že jsme připraveni pracovat na storce - rozumíme? Máme akceptační kritéria? Máme na to dost lidí/času? Jsou vyřešené závislosti? Ohodnotili jsme úkol? non-functional požadavky jsou definované? 
-Acceptance criteria - pro story 
- 
-Minimaly marketable feature mmf 
- 
-Business value: New revenue, incremental revenue, retained revenue (aby neodešli), operational efficiency — top priority 
- 
-Benefit cost analysis 
-Payback period - za kolik let se investice vrati: 100000 investice, 25000 naklady, 4 roky navrat 
-Returnon investment 25k/100k=0.25 
-Net present value npv 
-Internal rate of value irr 
- 
- 
- 
-Story card - popis, estimace, priorita 
- 
-Affinity estimation - sort all storycards from smallest to biggest, then estimate by fibbonaci, or t-shirt size - relative  
-sizes 
- 
-Planning poker, read story point, than discuss, than every choose size, than discussion, than agreement on size www.planningpoker.com 
-fun, involves all, effective, discuss risks 
  
 Velocity and planning - velocity - productivity of the team - work done in a sprint in story points, average value for past sprints Velocity and planning - velocity - productivity of the team - work done in a sprint in story points, average value for past sprints
Line 183: Line 178:
 determine High level business goals —> decide epics, storeies -> estimate user stories, ->iteration size -> estimate velocity, -> prioritize -> select stories to iterations and release date determine High level business goals —> decide epics, storeies -> estimate user stories, ->iteration size -> estimate velocity, -> prioritize -> select stories to iterations and release date
 Common failure - use sprints for specific activities, not for deliverables -> schedule risks, longer go from idea to feature Common failure - use sprints for specific activities, not for deliverables -> schedule risks, longer go from idea to feature
 +
 +==== Měření, budíky stavu vývoje ====
  
 Burn down and burn up charts (information radiators) Burn down and burn up charts (information radiators)
Line 192: Line 189:
 Nico Nico calendar - feeling of every of team - smaily per user and day Nico Nico calendar - feeling of every of team - smaily per user and day
  
-Measure just what matter, + 
-focus on trends and forecastsnot only values +  * Měříme jen podstatné věci 
-focus on team metrics +  * Zaměřujeme se na trendy a předpovědine jen na hodnoty 
-measires for improvementnot punish+  * zaměření na týmové metriky 
 +  * měříme pro zlepšováníne pro trestání
  
 Other information radiators: Other information radiators:
Line 202: Line 200:
  
  
-User story -requirements from use perspective +==== Velké projekty ==== 
-Epic large user story which cannot be delivered in singe spring+  omezit velikost backlogu na 150, víc detailu ke storkám dříve 
 +  - používat Epiks a Themes 
 +  - Product line owner nad PO, Chief product owner 
 +  - one backlog per product, týmy mají jen view na svoje 
 + 
 +Scrum-of-scrums 
 + 
 +Standup zástupců jednotlivých týmu, nemusí být denně, probírají sezávislosti, problémy, co se dělalo před mítingem a do dalšího mítingu 
 + 
 +Plannig practices 
 + 
 +  - pravidla pro estimaci, aby všichni měli podobné estimace 
 +  - kick-of meeting - zástupci různých týmů 
 +  - look-ahead plan - přemýšlet víc plánů dopředu, hledat závislosti 
 +  - feeding buffer - extra dny mezi závislosti, sdílení lidí - lepší spolupráce a sdílení expertýzy. 
 +  - Establish integration teams - poskytují integrační nástroje, automatické testy ... 
 + 
 +FDD Feature Driven Development 
 + 
 +Scaling Framework 
 + 
 +Scaled Agile Framework SAFe - practices for scaled scrum. scaledagile.com 
 + 
 +Team level 
 +Program level 
 +Portfolio level 
 + 
 +Large Scale Scrum LeSS 
 + 
 +www.less.works Principes: 
 + 
 +  - Transparency 
 +  - More with Less 
 +  - Whole product focus 
 +  - Customer centric 
 +  - CI 
 +  - Lean thinking 
 +  - System Thinking 
 +  - Queue theory 
 + 
 +Scrum@Scale 
 + 
 +Disciplined Agile 
 + 
 +Nexus - skupiny týmů 
 + 
 +www.scrum.org 
 + 
 +== Geograficky distribuované týmy == 
 +  * důležitost komunikace 
 +  * vybírat časy vhodné skrz časové zóny, klidně zdvojit mítingy 
 +  * komunikace audiovizuální 
 +  * potřeba dát důvěru 
 +  * občas potřeba vidět se fyzicky 
 + 
 +==== Vhodnost Scrumu ==== 
 +  * Malé projekty 
 +  * Projekty, kde je více alternativ, kde se zkoumají možnosti 
 +  * Projeky, kde se mění často požadavky 
 +  * Projekty, kde se setkaváme se zákazníky 
 +  * Kde jsou potřeba ekonomické dodávky 
 +  * požadavky na časté dodávání, například změny postupů atd. 
 + 
 +Co ovlivňuje použití Scrumu: 
 +  * Vyspělost orgranizace na vysokou úroveň spolupráce 
 +  * Podpora pro měnící se plánování 
 +  * Ochota organizaci dát týmům autonomii 
 +  * Podpora managementu a zákazníka 
 + 
 +==== Nástroje ==== 
 +== Porject management nástroje == 
 +  * Práce s backlogem 
 +  * tvoření releasu 
 +  * přiřazení úkolů lidem 
 +  * grafy a budíky 
 +  * Editace statusů 
 +  * Práce se storkama 
 +  * Práce s hierarchií 
 + 
 +== Inženýrské nástroje == 
 +  * Automatizační nástroje 
 +  * testovací nástroje 
 +  * CI CD 
 +  * Validace kvality 
 + 
 +== Testy == 
 +Testovací pyramida: doporučené hodnoty 80% unit testy, 15% end-to-end testy, 5% UI testy 
 + 
 +==== Agile transformace ==== 
 +  * Malý expriment : malé riziko, lze vybrat vhodný projekt (malý nezíská důvěru, velký může ztratit důvěru a trpělivost. Ideální: z 2/3 největší, nejůležitější, nejdelší, nejbohatší), garantuje brzký úspěch, redukuje nechuť. Ideální zvolit více pilotů a mít realistické očekávání 
 +  * Všichni do toho : rychlejší transformace, menší cena, vzájemné učení 
 + 
 +== Vzory adopce == 
 +  * public display - velká ochota organizace, versus tajný - pokud je silná resistence 
 +  * Split-and-seed uspěšný tym se rozdělí a realokují se lidi do ostatních týmů - agenti, rychlejší šíření 
 +  * Grow-and-split rozdělí se úspěšný tým na 2, hlubší šíření 
 +  * Technická adopce od prvního dne, nebo po krocích (když je resistence) 
 + 
 +== Tým == 
 +  * evangelisti 
 +  * optimisti 
 +  * otevření skeptici 
 + 
 +== Iterativnost a inkremence == 
 +přidávat postupně. Backlog pro transformaci, sponzor by měl věřit v Agile a být trpělivý, transformační komise Enterprise Transition Comitee, která řídí transformaci a identifikuje rizika 
 + 
 +== Improvement comitee == 
 +Skupina zaměřená na zlopšování, např. automatické testování 
 +Expectation up-front - nesmí být moc malé ani moc velké očekávání. 
 +  * Pocity týmu: moc času na schůzkách. Časem se naučí vést mítingy efektivněji 
 +  * Testeři : proč testovat opětovně nedokončenou práci? 
 +  * Hvězdy nechtějí ztratit slávu 
 +  * Procesně orientovaní: Méně dokumentace a formálnosti v procesech 
 +  * Zákazník: proč trávit tolik času s týmem? 
 + 
 +Kulturní změny: 
 +  * zmenšit specializaci 
 +  * přiměřené výzvy 
 +  * sdílení znalostí a profesní růst 
 +  * čas na vzdělávání 
 + Vítat rozdílnost 
 + 
 +Typy lidí: 
 +  * konzervativní - prospěšní v plánování - vidí rizika 
 +  * pragmatici - umí dělat kompromisy a zklidňovat konflikty 
 +  * optimisti - šíří chuť do změn 
 + 
 +== Řízení neochoty == 
 +  - sabotéři - aktivní, nemají rádi scrum - potřeba jednat pevně, sdílet úspěchy, když nepomůže  přesun 
 +  - Skeptici - pasivní, nemají rádi scrum - dodat data 
 +  - nasledovníci - pasivní, nemají rádi změny - dodat data a adresovat  jejich obavy 
 +  - Diletanti - aktivní, nemají rádi změny pokud se jim věnuje, mohou být podporovatelé
  
 +Časté chyby:
 +  * nedostatečné vysvětlení z managementu
 +  * málo spolupráce
 +  * příliš velké očekávání od investoru
 +  * Překážky
 +  * nedostatečné věnování se dokončování
 +  * příliž ambicí, nebo žádné ambice si brát úkoly
 +  * špatně popsané úkoly
 +  * špatná kvalita
  
 +Kulturní změny:
 +  * lidi musí cítit zodpovědnost za týmové cíle
 +  * vyzdvihovat jinakost v týmu
 +  * Self-organization, důvěra v rozhodnutí
 +  * potřeba stanovit hranice kompetenci
 +  * potřeba diskuzí
  
 +Maturity model\\
 +  * hodnocení, různé modely: Harman, Thoughtworks,  Cape management
 +  * vytvoření KPA (metrik) pro sledování
 +  * plán na zlepšení
 +  * implementace zlepšování