Přečtěte si co je nového v agilním světě, která témata jsou pro mě zajímavá.
Vše co jste chtěli vědět o Agilních metodách
Před casem jsem publikovala anketu Agile Adoption Survey 2009, a nastal čas pro vyhodnocení. Anketa byla součástí mé disertační práce, takže vyhodnocení je tentokrát v angličtině.
Výsledky jsou publikovány včetně detailní sumarizace doporučení a zkušeností jednotlivých respondentů, takže doufám, že budou pro Vás užitečné.
Podrobnosti se dočtete tady.
Jedním z předběžných výsledků ankety (Dotazník Jak začít pracovat Agilně (Agile Adoption Survey) 2009) který je vidět již v průběhu je, že většina lidí považuje Test Driven development (TDD) za příliš složitý na nasazení, jen čtvrtina lidí ho opravdu používá, ale skoro polovina si myslí, že je to užitečná agilní metoda. Proč tomu tak je?
Zkuste si představit třeba automobil, který by někdo vyráběl stejně, jako je píše software. Prostě by se navrhnul, poskládal dohromady, a někdo s dělníků by na půl oka zkouknul, že to vypadá jako automobil. V lepším případě by motor vypadl až někde cestou, dveře by nešly zevnitř otevřít a nádrž na benzín by byla shodou náhod hermeticky uzavřená. O bezpečnosti jízdy ani nemluvě.
Než takový automobil pustíte na silnici…
nejdříve připravíte testy, třeba tento:
pak testy spustíte…
a teprve když jsou všechny v pořádku, dáte auto zákazníkovi…
Takže proč když to můžeme dělat při výrobě automobilu, neděláme to při výrobě software? Myslím, že je to jen zvyk. U softwaru totiž většinou nic moc nehrozí. To že programy nefungují, už jsme si přeci zvykli.
Ale i tak, Test Driven Development (TDD) rozhodně stojí za zamyšlení. Odhlédneme-li od spokojenosti zákazníka, je tu i spousta interních aspektů. Např. máte-li kód plně automaticky testován, snižujete riziko refactoringu a případné chyby, které způsobíte v jiných částech aplikace, najdete hned a sami. A na tom že každý systém jednou potřebuje třeba jen drobný refactoring se asi shodneme. Myslím, že investice do testů na začátku se Vám vrátí velmi brzy.
Proč to tedy nezkusit… Mimochodem, víte, jak se pozná, že už jste opravdu v Test Driven Developmet světě? Než upravíte nějakou funkcionalitu, nejdříve ‘rozbijete‘ test (tedy upravíte ho podle nových požadavků, a spustíte) a teprve až test neprojde, opravíte funkcionalitu tak, aby všechny testy byly v pořádku. Je to jiné, zdá se to být zvláštní, ale funguje to.
Ráda bych Vás pozvala na WebExpo 2009, kde pořádáme s Agilním konsorciem open space diskuzi:
Vše, co jste kdy chtěli vědět o agilních metodách*
Přijďte se něco dozvědět o agilních metodách, popovídat si, zapojit se do diskuze.
A máte-li již teď nějaké otázky, stačí je přidat jako komentář pod článek. Rádi odpovíme.
Diskuze se bude konat v sobotu 17. října 2009 od 14:15 v prostorách konání konference WebExpo (viz letáčky na místě). A povídat si s vámi budu já, tedy Zuzi Šochová (CERTICON), Petr Olmer (GoodData) a Andrej Zachar (SimpleWay).
___
* ale báli jste se zeptat
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.
Rada bych Vás pozvala na Konferenci Agile Eastern Europe. Konference vytváří otevřenou platformu pro výměnu zkušeností s Agilními metodami nejen v rámci východní Evropy. Mezi pozvanými speakery jsou specialisté z celého světa, na bližší informace se podívejte na stránky Agileee.org.
KDE:
Kyiv (Kiev), Ukrajina
KDY:
18-19 Září 2009 (Pá-So)
Rádi Vám pomůžeme s organizací a cestou na konferenci.
Kontakt: 
.
|
|
WHERE:
Kyiv (Kiev), Ukraine
WHEN:
18-19 Sep 2009 (Fri-Sat)
The conference mission is to setup a collaborative environment for professionals in the Software Development domain to share their experience on applying Agile practices and techniques that foster efficiency.
The conference is to bring together specialists from the Eastern European countries who are interested to learn from each other’s experience in adopting Agile since we have a lot in common due to our economical and geopolitical situation.
The conference welcomes guests (attendees and speakers) from all around the World since we would like to demonstrate our hospitality in exchange to the experience that the Western countries have obtained over the last decade in the field of Agile Software Development.
Agilia je neformální setkání příznivců agilních metod které pořádáme pod hlavočkou Agilního konsorcia každou druhou středu v měsíci. Potkáte různé lidi kteří se zajímají o nejrůznější agilní metody. Lidi z různých firem, různých prostředí.
Agilia se obvykle koná v nekuřácké kavárně Al Cafetero. Přijďte a vezměte s sebou i své kolegy a kamarády!
Program:
18:30 – 19:00 seznamování se
19:00 – 19:10 krátká prezentace na předem zveřejněné téma
19:10 – 21:30 diskuse a volná zábava
Date: každá druhá středa v měsíci
Time: 6:30pm – 9:30pm
Location: Al Cafetero
Street: Blanická 24
City/Town: Praha, Czech Republic
Více informací a detailní program najdete na stránkách Agilního konsorcia či LinkedIn.
Přijďte se podívat a podělte se s námi o Vaše zkušenosti.
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í…
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ší.
Více informací na stránkách Agilního konsorcia.
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.
O tom k čemu využít Burndown graf už jsme psala v minulém příspěvku. Template pro Microsoft Excel je k dispozici také. Nicméně takový Excel se špatně sdílí mezi distribuovanými týmy. Jednou z možností je použití nějakého komplexního online systému, ale to s sebou obvykle nese další výdaje na licence a často i omezení Vašeho procesu.
Dobrým řešením je použít GoogleDocs. Tady je jako public příklad, jak by mohl Burndown vypadat (http://spreadsheets.google.com/ccc?key=p8oML5C9M–uwofmhl1npew).
První list obsahuje Produkt Backlog. Každý Sprint se zaloguje kolik bodů se udělalo, a kolik ještě zbývá.
Tyto hodnoty je následně nutné přenést do oranžově orámované části. Zbytek už se dopočítá automaticky.
Velocity Graf je prvním ze série grafů. Červená oblast zobrazuje počet bodů, které by tým měl stihnout za jeden dané Sprinty. Modrá křivka odpovídá aktuálním výsledkům.
Dalším grafem je tradiční Burndown Graf, který modře zobrazuje, kolik bodů ještě zbývá, oranžově kolik se již dokončilo a červeně případné změny bodového hodnocení (viz řádky 10, 11 v Backlogu).
Poslední graf zobrazuje Burndown z pohledu očekávaného dokončení projektu. Modrá křivka zobrazuje aktuální počet bodů, co zbývá dokončit, červená je potom projekcí ukončení projektu. Obecně se dá říct, že pokud je modrá a červená křivka uvnitř oranžové a zelené oblasti, očekávaný konec projektu je stále v rámci projekt bufferu a vše je v pořádku.
