Differences

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

--- ostatni:scrum [2023/03/18 23:36]
tomas
+++ ostatni:scrum [2023/03/19 08:53] (current)
tomas
@@ Line 37: / Line 37: @@
   - 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\\
 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
+==== 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 ====
-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
 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:
-  - Detailed properly
+  * Detailed properly
-  - Estimated
+  * Estimated
-  - Emergent
+  * Emergent
-  - Prioritized
+  * Prioritized
 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
@@ 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)
+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
 small
@@ Line 113: / Line 129: @@
 linear or fibonaci, if betveen, then higher
-Ideal time - absolutni cas na storku - lisi se clovek od cloveka, lepe 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 =====
@@ Line 132: / Line 151: @@
 ===== 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éno, role, učel co chce udělat, jeho běžné činnosti
+== 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.\\
-Story
+== Retrospective ==
-INVEST - independent na jiných věcech, Negotiale (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 sebe, ne 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
@@ 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
 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)
@@ Line 192: / Line 189: @@
 Nico Nico calendar - feeling of every of team - smaily per user and day
-Measure just what matter,
-focus on trends and forecasts, not only values
+  * Měříme jen podstatné věci
-focus on team metrics
+  * Zaměřujeme se na trendy a předpovědi, ne jen na hodnoty
-measires for improvement, not punish
+  * zaměření na týmové metriky
+  * měříme pro zlepšování, ne pro trestání
 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í

Tomas Lipensky - vedomostni koutek

Page Tools

Site Tools

User Tools

Differences