Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SCRUM_v2.5

144 views

Published on

  • Be the first to comment

  • Be the first to like this

SCRUM_v2.5

  1. 1. SCRUM Procesy, entity, User Stories a jak Vám to pomůže fungovat efektivněji copyleftCEREBRA, 2016
  2. 2. Agenda • „Agile“ o O čem to celé je • SCRUM o Artefakty o Role o Procesy • User Stories o Co to je o I.N.V.E.S.T. o US vs UC o Odhady o Metodiky
  3. 3. Agile • Lightweightprocess framework pro agilní řízení • Mindset  • Agile Manifesto: o Individualsand interactionsoverprocesses andtools o Workingsoftwareover comprehensivedocumentation o Customercollaboration over contractnegotiation o Responding tochangeover followinga plan o http://agilemanifesto.org/iso/cs/– zejména12 přikázání • Proč Agile? (2014 State Of Agile – Survey- http://www.cerebra.cz/clanky-stav-agile-2014.html)
  4. 4. • Kanban • SCRUM • FDD – FeatureDriven Development • Lean • TDD – Test Driven Development • JIT • … Agilnímetodiky a praktiky
  5. 5. Cynefin • Na jaképroblémy se hodíSCRUM? • Cynefin ©Cynefin framework by Dave Snowden
  6. 6. SCRUM • Vychází z empirickéhoprocesu
  7. 7. SCRUM • Cyklický KANBAN ;-) ToDo Req 12 Req 14 Req 8 Req 5 WIP Req 4 Req 6 Req 9 Done Req 1 Req 2 Req 3 Req 7 Req 10
  8. 8. SCRUM
  9. 9. ProductBacklog Sprintready Releaseready TBS Priorita& granularita ©http://macaubas.com
  10. 10. ProductBacklog – D.E.E.P. • Detailedappropriately • Emergent • Estimated(remainingeffort) • Prioritized
  11. 11. ProductBacklog ©www.romanpichler.com
  12. 12. SprintBacklog • Zodpovědnost DEV Teamu • User Stories z PBL si členovéteamu sami řadí do SprintBL (dlepriorit a toho, co zvládnou) • Sprint PlanningMeeting (SP1) • Sprint Goal,Forecast
  13. 13. SprintBurndownChart ©www.romanpichler.com • ZodpovědnostDEV • User Stories z PBL si členové teamu samiřadído SprintBL • SprintPlanningMeeting • SprintGoal
  14. 14. SCRUM Roles • ProductOwner o Definuje produkt, prioritizuje úkoly, definuje milníky ascope o Je zodpovědný za výsledný projekt (přidanou hodnotu) • SCRUM Master o Je zodpovědný za procesy SCRUMu, coaching teamu a PO o Odstraňuje překážky procesů, podporuje kooperaci teamu • DEV TEAM o Samoorganizující, určuje pracnost úkolů, určuje si sám cozvládne o Zodpovědný za inkrement produktu – výsledek sprintu
  15. 15. SCRUM Roles Responsibility Product Owner DEV Team SCRUM Master Scope (release) (sprint) Time (release) (sprint) Costs Communication (sprintreport) Risks QA (scope) (testing) (proces) Transfer rolí klasickéhomanagementu
  16. 16. Plánování • Releaseplanning oPlánmilníku oHrubý seznampožadovaných featur oOdhad počtu sprintů • Sprint planning oGoal / Forecast oTeam commitment oDetailníseznamUS s relevantnímiodhady • Rozpad na tasky(je li třeba)
  17. 17. SCRUMMeetings Backlog Grooming ©derailleurconsulting.com
  18. 18. SCRUM Meetings • Sprint Planning • Sprint Goal and Forecast, upřesněnístories, revize odhadů, rozpad na tasky • DailySCRUM • Denníplán, akutníproblémy • Sprint Review • Vyhodnocení cílů sprintu – DEMO, naplněníGoals, Forecast • Retrospective • Product Backlog Grooming • Údržba PBL,odhady, upřesnění stories
  19. 19. SprintPlanningMeeting • Team, PO, SM, případnědoménoví experti • Cílem je stanovit Sprint Goal (a forecast) • Výsledek: oPO víco na konci sprintu dostane oDEV Team ví co má dělat • Podmínky: oPO připravil Stories v BL a prioritizoval je oTeam (s PO) US odhadl (Backlog Grooming)
  20. 20. SprintPlanningMeeting- průběh • Team postupně odebírá položky z PBL o Diskutuje je s PO o Dekomponuje na tasky o Odhaduje náročnost tasků(US) o Zařazuje taskydo SBL • Iterativněse opakuje dokud nenívyčerpaná kapacita teamu o Resp. VELOCITY – stanovená na základěpředchozích sprintů • Často SP1 a SP2
  21. 21. Sprint Planning - Special Tasks • TechnicalUser Stories – typicky např. „zprovoznění TST prostředí“ – úkoly CFG Managementu • Educational tasks – např. školení, tech. hodinky atd. • Analytical tasks /Research– někdy je nutný cílený výzkum pro pochopení dalšíhoúseku vývoje
  22. 22. STORY POINTS • Odhady náročnosti prací • Story Point oBezrozměrné číslo oJe relativní oVyjadřuje náročnost dané feature/ US / tasku oVýhody: • Rychlost odhadu –odhad je jednodušší • Nezatížené „buffery“ • Relativní odhady jsou pro lidi bližší
  23. 23. STORY POINTS – jak na to? • Triangulace– „tahlefeaturejesložitější než tamta(2SP), ale jednodušší než jiná (5SP) => náročnost 3SP • Analogie • Expertníznalost • Odhad nemusíbýt „přesný“ - je to jenodhad  o Ve výsledku se kladné a záporné „nepřesnosti“ vyrovnají o Trocha úsilípřinese dostatečnou přesnost, další úsilíodhad již příliš nezlepší • Odhady určujeteam, nikdo jiný!
  24. 24. Planning Poker • Iterativníodhad v teamu(„moudrost davu“) • Pevné měřítko – karty pro agilníplánování 0 – ½ – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100 • Typicky stačíke konsenzu2 - 3 iterace • Musí být přítomen PO kvůli otázkám a upřesněním featur • Výhody: o Nenímanipulováno dominantními členy teamu o Podporuje komunikaci(v rámci teamu a s PO) o Eliminujerůzné vnímání časové náročnosti úkolu o Team si odhaduje sám, nikdonic nediktuje – motivační faktor
  25. 25. Daily SCRUM • SM,Team (případně další, ale nemluví) • 3 otázky – odpovídá každý členteamu o Co jsem dokončil od minulého DS? o Co dokončím do dalšího DS? o Jaké mám problémy / překážky? • Updatuje se burndownchart(pokud se takneděje automatickyv SW) • do 15 minut, standup – mluví jenčlenové teamu o případné diskuse až po DS
  26. 26. • Pravidlo č. 1
  27. 27. SprintReview • SM, Team, PO • Prezentace DEMA („potentialyshippableproduct“) • PO akceptuje, neboodmítne výsledek a dává feedback • Revize SprintGoal+ Forecast • Stakeholdeřividí DEMO • Revize burndown chartu+ kalkulaceVELOCITY • Retrospektiva – ideálněpo každém sprintu!
  28. 28. Sprints&Velocity scrum.jeffsutherland.com
  29. 29. Sprints&Velocity • Velocity = SUMASP hotových featur/US/tasků oNehotové tasky se vrací do BL • Př. Release scope: 100SP (estimated)Velocity:25 Sprintsrequired: 4 • Scopesprintuje fixní (a je jasnýgoala forecast) • Na konci sprintuje „potentially shippableproduct“ (a.k.a. DEMO)
  30. 30. Plánování &Kapacita • „Časová“ kapacita člena teamu: oCelková: 100% (fulltime, „FT“) oPlánovatelná:80% oSCRUMoverhead (meetingy): 10% oLookahead / preparation (BL grooming): 10% oOperativa – support: 10% oReálnákapacitanakreativnípráci(plněníscope):50% oOvšem meetingy, BL grooming atd. jsou „chtěné“ činnosti, ne „slack“! Bez nich nelze efektivně plnit scope.
  31. 31. Retrospective • SM,Team • Lessons Learned • How to do better nexttime - KAIZEN • SprintWeather • Solve Conflicts • Correct dysfunctionalbehavior • Weatherforecast • ROTI • (nemusíbýt po každém sprintu)
  32. 32. USER STORIES Já, jakožto <Typ uživatele>, bychchtěl, aby <Feature> tak, že <Business value>. Např: Já, jako administrátorDBS bych chtěl, abych mohl hromadně měnit konfiguraciuživatelůsystému ajejichoprávněníkpřístupudoDB tak,aby systémpřevzal hodnotyzkonfiguračníšablony(CSV),alezachovalsi informaciohistorickémnastaveníadatuzměn. Totomiumožníprovádět hromadné změny rychleji.
  33. 33. Příkladz praxe
  34. 34. USER STORIES • V přirozeném jazyku popsaný požadavek • Kdo – uživatelská role z pohledu businessu (Dispečer kamionové dopravy, knihař, …) oRole podporují „hmatatelnost“ • US oproti UC lépe znázorňují jak SW pomůže řešit reálný problém • Co – business scénář, nedefinice technolog.postupu řešení • Proč/Jak– co je benefitemfeature, přidanou hodnotou
  35. 35. USER STORIES • Krátké.Nejlépe do dvou vět. o „Placeholder“ pro pozdější komunikaci • Nemusí pokrývat všechny detaily, neníto dokumentace • Popisujípřínos nové featuryproprodukt o Jednoznačná přidaná hodnota • Popisujíakceptační kritéria o Výchozí bod pro akceptační testy (ATDD) • Mohou popisovat omezení (constraints) • Vertikální(napříč technolog. vrstvami aplikace)
  36. 36. USER STORIES [ID xxx-yyy] [TitleXYZ] Size: N As <User> I can <Feature/Function>so that<Business Value> AcceptanceCriteria <User> can [operate/use] <Feature> so that [output]is [visible/complete/…]. Notes: Constraints: i.e.Doesit needenhanced security? Textfieldhas toallow only numbers
  37. 37. US - I.N.V.E.S.T. • Independent • Negotiable • Valuable • Estimable • Sized appropriately • Testable
  38. 38. US - I.N.V.E.S.T. • Independent o Umožnívyhnoutseproblémůmpřiprioritizacia odhadech • Negotiable o Vyřešitelné,schůdné o Jasnáakceptačníkritéria • Valuable o Představujípřidanouhodnotuz hlediskabusinessu • Estimable o Majíodhadnutelnounáročnost o Jasnáakceptačníkritéria
  39. 39. US - I.N.V.E.S.T. • Sizedappropriately o US musí mít správnou granularitu: rozpad ->snazší odhady o Epics, velké US -se zvyšující se prioritou se rozpadnou na menší US • Testable o Testovatelné o Musí být jasnáakceptačníkritéria o ATDD • Performance, Stress, Failover testy mohou být samostatné US
  40. 40. US -Akceptační kritéria • <User> can [operate/use]<Feature> so that [output]is [visible/complete/…] • Umožní posoudit,zda je story implementovánatak, jak PO/ zákazník očekává • Binárníkritériapro akceptaciUS jako„hotové“ • Vodítkopro tvorbu akceptačníchtestů oZákladní/kritické testy mohou být sepsány rovnou u US • Podchycujímožné nejasnostive formálním zadáníUS
  41. 41. US -Akceptační kritéria • Co neníAK o Omezujícípodmínky („vstupnesmí povolit nečíselnýznak“) o If-Then statement o Popisjakprovést test
  42. 42. US vsUCvsDoc. • US vs UC oUC je detailnější oUS se snáze dekomponují oUS neníforma detailnídokumentace • US vs Dokumentace oUS není/ nenahrazujedokumentaci oDokumentaceje tak jako takpotřeba
  43. 43. Rozdělování USER STORIES • Proč rozdělovat US: o Odhad přesahuje možnosti jednoho sprintu o Rozsah US neumožňuje odhad – příliš mnoho nejasností • Po funkčníchcelcích (jednotlivé části CRUD např.) • Po datech („Zákazník,lokace,zakázky,…“) • Po rolích • KomplexníUS: o Story 1 – průzkum o Story 2 – implementace featur/-y
  44. 44. USER STORIES – časté chyby • Popisúkolu/řešení, ne businessscénář • Horizontální rozdělenívelkých stories na menší • Závisející/provázanéstories • Přílišdetailní –„goldplating“ • Špatněprioritizované • Obsahujídetailní popisyUI • Chyby v Akceptačníchkritériích
  45. 45. scRUM@cerebra.cz CEREBRA s.r.o. www.cerebra.cz Pickova 1486/2 Praha Zbraslav 15600 IČO:27538702 Dejte si s námi SC

×