Něco, co mě už delší dobu štve, je to, jak běžně mnozí v oboru používají termíny jako „Scrum, ale …“ v pejorativním smyslu, čímž naznačují, že týmy by se měly řídit pouze malým souborem postupů, které jsou součástí Scrumu. Skutečnost je taková, že k tomu, aby byl jakýkoli agilní tým schopen opakovaně dodávat funkční software po jakkoli dlouhou dobu, Scrum sám o sobě nestačí. Ať už si to uvědomují, nebo ne, naprostá většina týmů, které si říkají Scrum týmy, funguje jako hybrid Scrum-XP nebo hybrid Scrum-Kanban-XP, kde používají alespoň podmnožinu technických postupů, které vznikly v rámci XP.
Dovolte mi, abych na rovinu řekl, že týmy, které se řídí pouze postupy Scrum, pravděpodobně nebudou dlouhodobě úspěšné, protože alespoň podmnožina technických postupů XP je pro trvalý úspěch agilního dodavatelského týmu nezbytná.
Všiml jsem si, že není dost lidí, kteří by rozuměli tomu, co Scrum zahrnuje a nezahrnuje, takže začněme u toho.
Co je Scrum – soubor manažerských praktik
Scrum je aplikace empirického řízení procesů, což je elegantní způsob, jak říci, že bychom se měli rozhodovat na základě zkušeností, a ne na základě nějakého hypotetického souboru předpokladů, které nejsou založeny na realitě.
Zjednodušeně řečeno, Scrum se skládá z malého souboru řídicích postupů, které mají pomoci týmům efektivně spolupracovat a dodávat práci iterativním způsobem (ještě jednou zdůrazňuji – ve Scrumu nejsou žádné technické postupy).
Krátce shrňme obsah příručky Scrum:
- Existuje tým Scrum, který se skládá z vývojářů, vlastníka produktu a mistra Scrumu.
- Existují události Scrumu, které se skládají ze Sprintu, Plánování Sprintu, Denního Scrumu (alias Denního Standupu, v XP), Přezkoumání Sprintu a Retrospektivy Sprintu.
- Existují artefakty Scrumu, které se skládají z Product Backlog, Sprint Backlog a Increment, kde Increment existuje, jakmile jedna položka ze Sprint Backlog splní Definici hotového.
- Existuje Definice hotového, kde má každý Scrum tým sdílenou představu o tom, co znamená „hotový“ pro jakoukoli položku Product Backlog. Všimněte si, že na rozdíl od Akceptačních kritérií se Definice hotového uplatňuje globálně, zatímco Akceptační kritéria jsou specifická pro jednotlivé položky Produktového Backlogu.
Co Scrum není
Na rozdíl od všeobecného přesvědčení není součástí Scrumu žádná z následujících věcí:
- Uživatelské příběhy. Pracovní položky v produktovém Backlogu nebo Sprint Backlogu libovolného týmu Scrum jsou psány jako uživatelské příběhy (často ve formátu „Jako <osoba/role> chci <cíl>, aby byl <žádoucí výsledek>“), ale Scrum nepředepisuje žádnou konkrétní konstrukci nebo formát. Všimněte si, že uživatelské příběhy jsou součástí XP.
- Odhadování. Přestože naprostá většina týmů Scrum provádí odhad na určité úrovni, praxe odhadu není součástí Scrumu.
- Rychlost. Rychlost také není součástí Scrumu; pojem rychlosti projektu je součástí XP.
- Technické postupy. Jak bylo uvedeno výše, pojem technických praktik (CI, CD, párové programování, TDD atd.) ve Scrumu neexistuje. Naprostá většina technických postupů, které týmy obvykle dodržují, vznikla v rámci XP.
Co je to extrémní programování?“
Už je to více než dvacet let, co vznikl první tým pro extrémní programování (XP), který pracoval na projektu nazvaném Chrysler Comprehensive Compensation (C3). Metody, které tento tým použil, vznikly do značné míry v 80. letech minulého století, kdy Kent Beck a mnozí další experimentovali s lepšími způsoby vývoje softwaru, tj. s alternativou k „vodopádovému“ přístupu, který se do té doby stal dominantním.
Zviditelnění práce bylo vždy důležitým způsobem, jak informovat o tom, jak agilní týmy pracují. Proto jako úvod do XP doporučuji, aby každý, kdo se chce dozvědět více, dobře začal s těmito diagramy:
- Projekt extrémního programování (end-to-end diagram)
- Iterace (diagram zaměřený na to, co se děje uvnitř iterace; všimněte si, že to, co XP nazývá iterací, je koncepčně podobné tomu, co Scrum nazývá Sprintem)
- Vývoj (diagram zaměřený na interakce a činnosti při vývoji)
- Kolektivní vlastnictví kódu (diagram zaměřený na základní technické postupy)
Pozn: Vizuál, který kombinuje mnoho prvků z výše uvedených diagramů na jedné stránce, naleznete v knize Billa Wakea Přehled extrémního programování.
Další četba o XP
Pokud vás výše uvedené vizualizace zaujmou natolik, že si budete chtít o XP přečíst více, podívejte se na následující zdroje informací, které jsou uvedeny víceméně v pořadí nejkratší k přečtení > nejdelší k přečtení:
- Don Wells, Extrémní programování: jemný úvod
- Martin Fowler, BeckDesignRules (viz také Pravidla jednoduchosti Xp)
- Kent Beck, Ward Cunningham a kol., Základní postupy extrémního programování (také známé jako 12 XpXtudes)
- Don Wells, Pravidla extrémního programování
- Ward Cunningham a další,Extrémní programování (také známé jako WikiWikiWeb)
- Ron Jeffries, Co je to extrémní programování
- Kent Beck & Cynthia Andres, Extreme Programming Explained:
Další odkazy
Všechny odkazy v této části pocházejí z webových stránek XP Dona Wellse, pokud není uvedeno jinak.
- Agilní modely jsou obrazy, nikoli fotografie (všechny modely jsou špatně; některé jsou užitečné)
- Přísloví agilních procesů (slova, kterými by se měl řídit každý tým)
- Bill Wake, Arrange, Act, Assert (vzor pro psaní unit testů)
- Bill Wake, Sudoku Solver (zajímavá variace na TDD)
- Bill Wake, Testy z klobouku (kreativní přístup k psaní jednotkových testů)
- Poctivé plány (jak vypadá odhad v praxi)
- Řiďte své cíle místo činností (hlavní rozdíly mezi vodopádovým a agilním vývojem)
- Hodnoty extrémního programování (jednoduchost, Komunikace, zpětná vazba, respekt, odvaha)
- XP a databáze (vzor založený na zlatých > stříbrných > bronzových databázích )