Co mi přineslo WebExpo 2010 – část 1

WebExpo 2010 mělo letos oproti minulým ročníkům sekci zaměřenou na agilní metody. Když bych měla hodnotit úspěch agilní sekce, kterou jsem po programové stránce celou organizovala, myslím, že splnila má očekávání. Úroveň přednášejících byla dobrá, přednášky zajímavé a témata různorodá. Lidí přišlo hodně, něco mezi 60-100 účastníky. Tedy se zdá, že agilní metody zajímají hodně firem. Nemá smysl opakovat, co bylo na WebExpu řečeno, ale ráda bych se podělila o pár zajímavých myšlenek, které přednášky přinesly mě osobně.

Panel Discussion at WebExpo 2010 - Andrea, Lubos, Paul, Alex, Maria, Pierluigi (from the right)

Davis Hussaman mi mluvil z duše, když říkal, že Scrum není dogma. Není to žádné náboženství, které byste měli slepě následovat bez toho, aniž byste pochopili smysl Vašeho počínání. Lidé ve spoustě firem “chtějí Scrum“ ale málo z nich přemýšlí, proč ho vlastě chtějí a co je jejich cílem. A to nemluvíme ani o tom, že cíl se často někam posouvá a mění a možná právě proto jsou iterativní metody úspěšnější než ty klasické, kde všichni očekávají, že to co si jednou rozmyslíte tak bude navěky věků.

Další zajímavou myšlenkou bylo, že co neznáte, Vás bolí nejvíce. A jsme zase zpět u toho proč je vlastně Scrum iterativní. Abychom se pravidelně zastavili, udělali reflexi, něco se naučili, něco změnili, zrevidovali, jestli je cíl ještě stále tam kde si myslíme, a co se nám to vlastně děje. Protože víte-li že nestihnete projekt dodat včas již v polovině projektu, máte pořád ještě spoustu možností to napravit (přidat resourcy, omezit funkcionalitu, vyjednávat, … ). Ale zjistíte-li to až těsně před odevzdáním, máte jen velmi omezené možnosti s tím cokoli udělat.

Víte co je nejčastější metodologie řízení projektů? ‘Hope methodology‘. Všichni do jednoho nakonec jen doufají, že projekt bude úspěšný a že to nějak stihnou.

A nečekejte, že někde najdete best practices jak zavádět agilní metody. Best practices fungují na jednoduché situace jako je pečení dortu. Ale proces zavádění agilních metod je komplexní a komplikovaný. Jediné co Vám pomůže je mít vizi a jasný cíl a tuto vizi sdílet s celým týmem či firmou. Ale taková vize většině firem chybí a možná přesahuje rámec jejich myšlení. A tak se raději zaměřují na jednotlivé praktiky. Je to jako již zmíněné náboženství, kde se vize vytratila…

Ostatně když nevíte, kam směřujete, je snadné minout cíl i kdyby Váš iterativní proces byl sebelepší.

Ještě jedna větu jsem si poznamenala: Lidé nechtějí špatné produkty včas. Tedy jestli si říkáte, že dodržíte termín za každou cenu, a že to zákazník ocení, nemusí to tak být. Zákazník bude většinou radši, když dostane to, co potřebuje, i kdyby to mělo být o pár dní později. Zvláště když tuto skutečnost ví s předstihem.

Pozvánka na WebExpo 2010

Ráda bych Vám doporučila Agilní sekci na letošním WebExpu, kterou po programové stránce organizuji. Jedná se o v českých podmínkách unikátní akci, kterou by si neměl nechat ujít nikdo, kdo se o agilní metody zajímá.

Konference WebExpo 2010 v září

Třetí ročník konference WebExpo přináší novou sekci zaměřenou na agilní metody. V posledních několika letech výhody agilního přístupu oceňuje čím dál více firem a začínají být často používané i v českých společnostech. Agilní metody se zaměřují na týmovou spolupráci, zavádí efektivní procesy a posilují kvalitu produktu. Agilní sekce WebExpa je vyjímečnou příležitostí dozvědět se více o agilních metodách a vytváří unikátní platformu pro sdílení zkušeností z firem, které agilní metody úspěšně používají, s agilními metodami začínají, či o agilních procesech teprve uvažují.

Během dvou dnů přednášek promluví deset zahraničních odborníků z praxe, přednášky budou zaměřeny jak pro začátečníky tak i pro pokročilé, budou zaměřené na konkrétní agilní praktiky používané vývojáři, testery a teamleadery, ale zhodnotí i význam agilních metod pro managery firem. Program doplňují i dvě panelové diskuze, které jsou výbornou příležitostí konfrontovat vaše zkušenosti s odborníky z českých i zahraničních společností.

Čtvrtek je tradičně vyhražen praktickým půldenním workshopům, kde si můžete vyzkoušet Theory of Constraints spolu s Pierluigi Pugliese, který tento workshop povede. Pierluigi začínal jako programátor v telco sektoru, postupně přešel do role teamleadera a dnes se primárně věnuje konzultacím v různých firmách, kde pomáhá se zaváděním agilních metod. Pierluigi je původem z Itálie a dnes žije v Německu. Kromě již zmíněného workshopu bude mít i přednášku na téma Soft Skill Essentials for Software Craftsmen.

Dalším z pozvaných speakerů je charismatický David Hussman z Minnaepolis, USA, který agilní sekci konference v pátek zahajuje. David je jeden z nejlepších odborníků na agilní metody, organizuje lokální agilní komunitu v USA, pomáhá různým firmám v nasazování efektivních agilních procesů. S důrazem na pochopení aktuální situace daného projektu se vyhýbá obecným a universálním řešením, která jsou často doporučována. David pracuje v těsné spolupráci se softwarovými týmy, vývojáři, teatery i teamleadery. Jeho přednáška Products and People over Process and Dogma je ideálním tématem k zamyšlení nad smyslem agilních metod. Jak David říká v úvodu přednášky – čím dál tím více lidí tráví čas diskuzemi o tom, co to znamená agilní, místo toho aby jednoduše začaly agilní praktiky používat.

Další z přednášek je o tom, jak správně dělat retrospektivu. Jestli se rozhodnete s agilními metodami v praxi začít, retrospektiva by měla být první metodou, kterou do svého týmu zavedete. O problémech retrospektivy bude mluvit belgičan Yves Hanoulle, který je zkušeným agile coachem a jeho přednáška How to make your retrospectives the heart of your agile proces by Vám rozhodně neměla uniknout.

Mezi dalšími pozvanými odborníky je v německu žijící Boris Gloger, kerý kromě plánovaného workshopu bude mluvit v přednášce Scrum for Executives – Six Secrets for Success with Scrum o tom, jak používat Scrum v různých prostředích. Ital Andrea Provaglio se ve své přednášce Beyond Agile podělí o zkušenosti se zaváděním Scrumu. Nenechte si ujít ukázku, jak prodávat agile, kterou bude prezentovat Američan žijící v Polsku Paul Klipp ve své přednášce Selling Agile. O své zkušenosti z praxe se s vámi podělí i Maria Diaconu a Alex Bolboaca z Rumunska v přednášce Software Development = Learning.

Z českých speakerů představí Tomáš Pergler praktickou studii z firmy Seznam.cz, kde se podělí o zkušenosti Seznamu se Scrumem – A Year with Scrum in Seznam.cz. Dalším z českých speakerů je Luboš Král, který se v přednášce Agile acceptance and implementation by East and Western mindsets zaměří na otázky spojené s nasazováním agilních metod v multikulturním prostředí, jak převzaté techniky fungují v české kultuře, co se osvědčilo a co je naopak nutné změnit. Na ukázkách z praxe poukáže na hlavní rozdíly mezi agilními přístupy a klasickými metodami.

Konferenci doplňují dvě panelové diskuze, kde první je zaměřená na Agile z pohledu managementu. Podíváme-li se na největší překážky v zavádění agilních metod, nepochopení managementu bude jednou z nejčastějších příčin jejich neúspěšného nasazení. Pojďme se tedy společně s managery předních českých firem podívat na agilní metody z pohledu jejich managemetu. Diskutovat budou Zuzana Šochová (Managing Director, Lotofidea), Vlastimil Pečínka (R&D Director, Seznam.cz), Jan Bezdíček (Director, Rockwell Automation), Pavel Šuk (Vice President, Kerio Technologies), Martin Rýzl (Software Engineering Manager, Sun Microsystems).

Budete-li mít i po všech vyslechnutých přednáškách nějaké dotazy, panelová diskuze Everything you’ve ever wanted to know about agile methods je ideálním místem pro jejich zodpovězení. Všichni přednášející agilní sekce Vám budou plně k dispozici. Takže přijďte a zeptejte se na vše, co jste kdy chtěli vědět o agilních metodách.

Konference WebExpo se koná již tradičně na půdě ČZU v Praze, tentokrát již 23-25.9. Více informací se dočtete na každý den aktualizovaných stránkách WebExpa.

Scrum hra

Plánujete školení Scrum metody a přemýšlíte, jak nejlépe zajistit aby si účastníci co nejvíce zapamatovali? Kolikrát jste se vrátili z kurzu a školení, nadšeni jaké to bylo zajímavé, a už po několika dnech jste vlastně nevěděli, o čem to bylo. Říká se, že lidé se nejvíce učí z vlastní zkušenosti a prožitku. Testy na toto téma uvádějí, že si člověk zapamatuje jen přibližně 20 % z toho, co slyší, a pouhých 30 % z toho co si přečte nebo je mu názorně ukazováno. Ale již 50 % informací si zapamatuje, pokud má možnost nabízené informace vidět i slyšet. Kolem 70 % informací si pak člověk zapamatuje, když má možnost něco vidět, poslouchat a následně o tom navíc hovořit. Pokud k těmto třem činnostem přiřadíme ještě možnost aktivního vykonání, získáváme až 90 % šanci si dané informace zapamatovat [Soňa Hermochová, Teambuilding; Grada, 2006]. Tedy chcete-li naučit někoho Scrum, musíte mu vysvětlit jak na to, ale to nestačí. Aby to celé mělo smysl, musí si účastníci Scrum vyzkoušet na vlastní kůži a zpětně zhodnotit jak jim to šlo, co bylo dobré a co by měli naopak příště vylepšit.

Her se dá hrát mnoho, mohou být různě složité a komplexní, ale v podstatě jde o to, vyzkoušet si pár základních principů – Plánování, týmovou spolupráci, komunikaci se zákazníkem, reakci na změnu. A retrospektivu. Jednou z možných her zaměřených na prožitek ze Scrum procesu jsme navrhli s Petrem Olmerem stavbu železnice. Základem je postavit železniční spojení mezi městy USA a dovést zákazníka kam potřebuje/chce. Produkt backlogem je vyhlášen cíl spojit města A, B a C. Tým si zvolí ScrumMastera a hra může začít. Každý sprint si tým po diskuzi se zákazníkem naplánuje Sprint Backlog v závislosti na daných prioritách. Pak si každý člen vytáhne kartičky určující jeho rychlost, a případnou změnu celkových bodů. Tyto individuální rychlosti se sečtou a tým prezentuje, kolik železnice postavil. Cílem je mít funkční produkt a spokojeného zákazníka.

Potřebujete:

  • Mapu USA s před vyznačenou trasou – my jsme zvolili tuhle. Za jednu user story se považuje dokončení úseku z jednoho města do druhého (města jsou označena čísly). Stavba jednoho lomeného úseku trati odpovídá 4 bodům.
  • Lepítka na jednotlivé user story v backlogu.
  • Tabuli rozdělenou na tři části: Backlog | In Progress | Done.
  • Kartičky s rychlostí, které byl daný člen týmu schopen dosáhnout, které můžou vypadat třeba takto:
    • Proslýchá se, že nejpracovitější dělník dostane prémii, zkusím pracovat víc – 10
    • Odbory prosadily kratší pracovní týden – 5b
    • Je Den Železničářů, v poledne se jde do hospody – 4b
    • Včera pršelo, vypili jsme moc rumu – 3b

    Ale také třeba takto:

    • Měřiči špatně vykolíkovali trasu: +5b nová úloha: bourání špatně postaveného úseku – 3b
    • Vichřice povalila stoletý dub: +10b nová úloha: odstranění stromu – 0b
    • V tomto případě se do backlogu přidá nová úloha, která se musí z odpracovaných bodů dokončit jako první a pak je teprve možné pracovat dál na naplánovaných úlohách.

  • Větší hodiny měřící délku Sprintu, my jsme zvolili:
    • 5min – pre-planning & planning – tým na tabuli naplánuje user stories pro daný sprint
    • 5min – vyhodnocení & customer demo – každý člen týmu si vylosuje kartičku s rychlostí a podmínkami ve kterých daný sprint pracoval, Scrum Master je zodpovědný za zpracování výsledků a zorganizování customer dema.

    Nestihne-li tým všechny úkony včas (plán, vyhodnocení, customer demo, …), nejsou mu jinak hotové úseky uznány.

  • Zákazníka – toho budete pravděpodobně hrát Vy – který může:
    • Chtít vidět další města
    • Změnit svá přání

    Je už jen na týmu a jeho vyjednávacích a prezentačních schopnostech, aby zákazníka uspokojil, či mu vysvětlil, že daný požadavek na změnu nestihne.

Cílem, jak jsem psala nahoře je mít funkční produkt a spokojeného zákazníka. Hodnotí se tedy, jestli byl tým schopen dokončit úlohy v backlogu a jestli je zákazník spokojen s výsledkem.

Celkem jsme hráli na 6 Sprintů, tedy celá hra vyjde na hodinu. Před hrou budete potřebovat cca 15 minut na vysvětlení a cca 15 minut na organizaci týmu a vytvoření úvodního backlogu. Po hře cca 30 minut na prezentaci celkových výsledků jednotlivých týmů a retrospektivu.

Na závěr přikládám prezentaci ke hře. Jestli budete mít jakékoli dotazy, náměty pro zlepšení, nebo zkušenosti, dejte vědět.

Retrospektiva – kolečko

Jednou z nejdůležitějších agilních praktik je retrospektiva. Cílem je zapojit tým do rozhodování o procesu, nechat je vyjádřit svůj názor, ale hlavně poslouchat se navzájem a pochopit, že ne každý se dívá na věc stejně. Retrospektivou se učíme a uvědomujeme si, co jsme dělali dobře a co ne. Ideální frekvence je po každém sprintu, aby se problémy zbytečně neprohlubovaly a tým měl pravidelnou a častou možnost zhodnotit, jak sprint probíhal z pohledu každého člena.

Jak retrospektiva vypadá? Možností je několik, ale začneme tou nejjednodušší. Tou je takzvané kolečko kdy všichni členové týmu odpoví na dvě základní otázky:

  • Co se mi líbilo, co co jsme dělali dobře a chtěli bychom v tom pokračovat
  • Co se mi nelíbilo a chtěli bychom to změnit

Nezapomeňte, že retrospektiva je o pocitech, jak jsem to viděl já, co jsem si myslel, jak jsem se cítil. Pocit je osobní, neklade si nároky na to být universální pravdou.

V dobře fungujícím týmu se vám může lehce stát, že nikdo v týmu nemá pocit žádných problémů a že tým subjektivně funguje dobře. Potom se popsaný framework rozšiřuje o další oblast:

  • Co by se mohlo vylepšit nebo zefektivnit

Ideální tým ani proces neexistuje, vždy se dá něco najít, jen je to občas těžké si uvědomit.

Začnete-li s retrospektivou, tým začne přemýšlet o věcech jinak, jednotlivý členové budou mít pocit, že má smysl promluvit a zapojit se. Přestanou být pasivními členy čekajícími na úkoly. A jste zase o krůček blíže k vysněnému ‘self-organized‘ týmu.

Posílení týmu – ‘self-organized‘ tým

Jedním z často skloňovaných výrazů je ‘self-organized‘ tým. Týmy přecházející na agilní metody často začínají ranním Scrum meetingem, jako první zaváděnou praktikou. Jistě pomůže při sdílení informací a posílí týmovou spolupráci, ale nedá sám o sobě jednotlivým lidem pocit, že i na jejich názoru záleží, a že je tedy jen na nich, jak si vše zorganizují. K tomu, aby tým byl opravdu zapojen do procesů, je třeba dát všem prostor se k procesu vyjádřit a ovlivnit ho. Proto je důležité dělat retrospektivu. Dalo by se říci, že vlastně nemusíte ani vymýšlet žádný do detailu zpracovaný proces, stačí začít s retrospektivami a proces odpovídající vašemu prostředí vznikne za pomoci lidí v týmu sám. A jako všechno to, kde se sami podílíte na rozhodnutí, je i takto vzniklý proces stabilnější, robustnější a efektivnější.

Retrospektiva vás donutí zastavit se a podívat se co jste dělali dobře, a co špatně. A tedy dává prostor ke zlepšení, vytváří podmínky ke změnám, a posiluje proces učení se z toho, co se stalo. Měla by proto probíhat pravidelně, po každém Sprintu. Každý by měl dostat prostor vyjádřit své pocity, jak to vnímal on sám, co se mu líbilo a co by naopak změnil či vylepšil. Nastaví se tak týmu zrcadlo, kde je najednou vidět, co funguje dobře a co ne. A aby jako takové zrcadlo fungovalo, musí mít jednotliví členové stejnou možnost svoje pocity prezentovat. Aniž by je někdo hned opravoval, že nemají pravdu a že s nimi nesouhlasí. Jsou to přeci pocity konkrétního člověka, ne univerzální pravda. A vnímat věci jinak má každý právo.

Aby byla retrospektiva funkční, musí vždy, bez vyjímky, na identifikované problémy následovat akce, která se pokusí problém minimalizovat či odstranit. Řešením může být jak změna identifikovaného procesu, tak i vysvětlení proč takový je. Na spoustu problémů může tým již během retrospektivy pomocí brainstormingu navrhnout řešení, na složitější problémy si můžete vzít čas na rozmyšlenou. Ale něco by se mělo stát a při příští retrospektivě by se mělo vyhodnotit, jestli akce pomohla, či ne. Čím více zapojíte tým do navrhování řešení, tím rychleji se problémy spraví. Tým ví obvykle nejlépe sám, co mu chybí, co je dobré, a co ne.

Extreme Scrum přednáška na Agileee

První ročník konference Agile Eastern Europe 2009 v Kievě je za námi. Agileee měla dobrou atmosféru a spoustu velmi zajímavých lidí. Mám-li vybrat top 2 přednášející, určitě by to byli J.B.Rainsberger se svojí přednáškou “An Introduction to Agile Through the Theory of Constraints” a David Hussman s přednáškou “Agile Journeys: How Did We Get Here and Where are We Going?”. Budete-li mít někde možnost si je poslechnout, určitě to stojí za to.

Moje přednáška je ke shlédnutí níže. Pojednává o speciální case study kdy byl použit Scrum v extrámním prostředí kde se projekty počítají na hodiny. Řešením specifické situace bylo nasazení Scrum metody a půldenního sprintu. Výsledky byly velmi pozitivní.

Část case study byla také publikována na konferenci SoMeT, 8th International Conference on Software Methodologies, Tools and Techniques.

Dva druhy lidí…

Z pohledu managementu jsou jen dva druhy lidí. Jeden, který by se dal charakterizovat slovy ‘co neměřím, to neřídím‘, a pak ti, co se více než na nějaké striktní procesy a čísla spoléhají na svojí intuici a selský rozum. Skupiny jsou to zcela disjunktní, a přesto že spolu mluví, jen velmi těžko si opravdu rozumí. Žijí v odlišném světě. Někde tady se podle mého soudu nachází základní problém zavádění agilních metod řízení.

Např. Scrum je založený na týmové spolupráci, týmové zodpovědnosti, a týmovém rozhodování. Zkuste tedy vysvětlit klasickému managerovi ze staré školy, že zodpovědnost za projekt má tým. On přeci musí mít jednoho člověka. Tomu odpovědnost naloží a ostatní ignoruje. Další obtíž nastane, když se tým rozhodne něco změnit. Vše přeci musí být popsáno procesy a ty se nejenže nemění, ale musí se i dodržovat… Po čase skončíte tak, že děláte (Agilní) interface dovnitř týmu a (klasický procesní) interface svému managerovi. A to samozřejmě bude funkční jen z poloviny. Agilní kultura se tak nevytvoří. A je otázka, jestli to pak celé nebude na úrovni isolovaných praktik, jako když např. místo komplexního systému testování zavedete unit testy. To je sice samo o sobě super, produkt bude trochu lépe otestovaný, ale asi to nezaručí tu pravou kvalitu.

Jak tedy přesvědčit managery co nikdy nic jiného nezažili, že Agilní metody mohou fungovat dříve, než vás utlučou svými formálními performance measurementy? A jde to vůbec? Nebo takové metody a kultura funguje jen ve firmách s opravdovými leadery, co upřednostňují dlouhodobý cíl před krátkodobým ziskem? Na závěr, k těm procesům, si neodpustím otázku. Máte ve firmě ISO? A pomáhá vám nějak v tom být lepší, kvalitnější a úspěšnější?

Paradoxně mám pocit, že se všude mluví o tom, jak přesvědčit zákazníka. Pro většinu firem ale musí být daleko těžší přesvědčit svoje vlastní lidi. Myslím, že přesvědčit zákazníka je o mnoho snazší, než si získat podporu formalistů a striktně procesně založených lidí.

Zajímal by mě Váš názor a zkušenosti. Takže prosím o diskuzi, ať už tady veřejně, nebo emailem.

Zavádíme Agilní metody agilně

Jistě jste si už mnohokrát zkusili zavádět v praxi nějaké novinky. Obvyklý postup je začít prezentací, ukázat o čem nový způsob práce je, co jsou jeho výhody, jaká jsou očekávání. Začnete-li takto ‘po staru‘ prezentovat Agilní metody, pravděpodobně se dočkáte spousty připomínek, že metody jsou moc americké, ve vašem případě z nejrůznějších důvodů nevhodné, přinesou spousty overheadu a sníží efektivitu. Proto se mě osvědčilo zavádět Agilní metody ‘agilně‘, tedy po částech a takříkajíc plíživě.

Základ je nikomu v týmu neříkat, že od teď nastane změna a bude se pracovat jinak. Lidé obecně změnu nemají rádi. Naopak. Vše je při starém, jen zavedeme každý den krátký meeting. Začneme neformálně, nějakou historkou, statusem projektu (stejně si všichni stěžují, že chtějí vědět co se děje) a postupně se začneme ptát jednotlivých lidí na to, co dělali včera a budou dělat dnes… zní to povědomě? Asi ano. A máme Scrum či Stand-up meeting tak jak má být. Tým si pozvolna zvykne, a ani mu to nepřijde. Vcelku snadný začátek.

K tomu aby se opravdu začalo plánovat v bodech sice nějaké vysvětlování potřebujete, ale když už umíte pěkně Scrum meetingy, znáte status jednotlivých úloh a i to jak vám jdou od ruky, máte pro to informace, co potřebujete. Mě se osvědčilo koncept seznamu úloh (nemusíte mu hned říkat backlog) vysvětlit, vysvětlit že ohodnocení odpovídá náročnosti a že ho budeme dělat v bodech. Pak už stačí nechat odhadovat úlohy jednotlivé členy týmu, klidně v hodinách, ale toto ohodnocení hned převádět na body. Složitější celky odhadnete sami. Po čase, kdy budete body vysvětlovat na konkrétních úlohách lidé koncept vstřebají a budou ho umět sami používat.

Dalším krokem je vytvořit plán na nějaké iterace (sprinty), ze začátku ho uděláte vy, později jeho vytváření delegujete na tým. A rovnou jim můžete dát burndown na nástěnku. Když budete mít týmů víc a podpoříte soutěživost, o pozornost máte postaráno. Někde během tohoto procesu zavedete prezentace zákazníkovi (customer demo) a začnete se ho ptát na zpětnou vazbu a priority. A to už máme v podstatě celý Scrum proces, aniž by o tom někdo věděl. A když už vám to tak pěkně funguje, můžete metody pojmenovat a dopilovat jejich formu.

Hledáte-li rady jak začít s Agilními metodami, většinou začínají komplexní teorií, kterou stejně tým bez vyzkoušení nepochopí a hlavně všemi metodami najednou (neboť jinak by to přeci nebylo dost agilní, to by nebyl ten pravý Scrum proces). Výše zmíněný postup je jen alternativou, která vám umožní dělat změnu procesu, aniž by to bylo vnímáno jako změna procesu. Jsou to jen takové drobné novinky, takové malé vrtochy našeho projekt managera, to přejde, chvíli budeme chodit na meetingy a on se třeba unaví…

Workshop agilního řízení a metodiky SCRUM

Ráda bych Vás pozvala na workshop agilního řízení a metodiky SCRUM. Workshop pořádáme spolu s Petrem Olmerem, pod záštitou Sun Microsystems a Agilního konsorcia. Kurz je plánován pro začátečníky a mírně pokročilé projektové manažery, produktové manažery, technické ředitele, analytiky, informační architekty a další.

Program kurzu

  • 9:00 – 10:00 Úvod, co jsou agilní metody, proč zavádět Scrum proces, základní terminologie
  • 10:00 – 10:15 Coffee break
  • 10:15 – 11:30 Sprint cyklus, plánování, odhady, ohodnocení úloh, burndowns
  • 11 :30 – 11:45 Vysvětlení Scrum hry
  • 11:45 – 12:45 Přestávka na oběd
  • 12:45 – 13:45 Scrum hra
  • 13:45 – 14:45 Retrospektiva
  • 14:45 – 15:00 Coffee break
  • 15:00 – 16:00 Agilita a psychologie

Více informací na stránkách Agilního konsorcia.

Scrum v extrémních podmínkách

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.