zuzi | Zuzi's Blog o Agilu a Scrumu

Používáte Test Driven Development (TDD)?

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:
připravit testy

pak testy spustíte…
sputit testy

a teprve když jsou všechny v pořádku, dáte auto zákazníkovi…
hotový výrobek

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.

Open space diskuze na WebExpu: Vše, co jste kdy chtěli vědět o agilních metodách…

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

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.

Scrum process under specific extremely short conditions

View more documents from agileee.

Jak začít pracovat Agilně (Agile Adoption Survey) 2009

Protože více hlav více ví a protože potřrebuji data pro svou disertační práci, chtěla bych všechny poprosit o vyplnění dotazníku zaměřeného na Vaše zkušenosti se zaváděním a používáním agilních metod. Výsledky zveřejním na tomto blogu začátkem roku 2010. Diky za spolupráci!

Výsledky se dočtete tady.

Please help me to get data on agile adoptin process. The results will be used in my dissertation thesis and will be published on this blog at the beginning of 2010. Thanks!

Dotazník Jak začít pracovat Agilně (Agile Adoption Survey) 2009

The results can be found here.

Waterfall, RUP nebo Agile?

Začínáte projekt a nevíte kterou metodu zvolit? Zkusím se podívat na jednotlivé metody detailněji. Tradiční Waterfall vypadá ideálně. Nejprve si navrhnete, co budete dělat, pak řeknete jak, pak to uděláte, otestujete. Ideální. Snadné. Jen bohužel realita je vždy jiná. Výsledek ukážete zákazníkovi, a on se zatváří zklamaně, řekne, že tohle si nepředstavoval, či že tohle nikdy nechtěl a ať to předěláte. Vás pak na jedné straně čeká dlouhý refactoring a předělávání, a k tomu zákazník, který je nervózní že aplikaci stále nemá. Na druhé straně jsou dlouhé diskuze se zákazníkem, že v jeho původních požadavcích to bylo jinak či nebylo vůbec. A že tento refactoring musí zaplatit extra. Nic neobvyklého, a nic co by se jen blížilo spokojenosti na obou stranách.

Proto vznikl Rational Unified Process (RUP), který si uvědomuje, že není možné celou aplikaci napsat v jednom sekvenčním procesu – ostatně stejně se tak nikdy v reálu nedělo – a že jednotlivé fáze jsou více či méně přítomny periodicky v průběhu celého procesu. RUP se dá v podstatě považovat za pokus přiblížit Waterfall reálnému světu. Pokus to byl dobrý, nicméně spokojenosti zákazníka moc nepřispěl. Návrh vede často k velice komplexní a náročné architektuře, která ztěžuje případný refactoring. Navíc jednotlivé fáze jsou extrémně detailně specifikované, tedy libovolné změna vyžaduje i dlouhý čas na přepsání všech modelů a diagramů.

Asi nikoho nepřekvapí, že budu na tomto místě doporučovat agilní metody. Na rozdíl od předchozí metody, která vsadila na dobrý návrh, jsou agilní metody orientovány na změnu. Návrh by měl být co nejjednodušší, iterace dostatečně krátké, aby se omezilo riziko refactoringu. Navíc zákazník, který vidí každé dva týdny jednu feature a může se k ní přímo vyjádřit, je potom v daleko horší situaci když na konci projektu chce něco jinak. Agilní metody omezují návrh a dokumentaci na nutné minimum, nicméně na druhé straně zapojují testování hned na začátek návrhu (TDD), zavádí automatické testování a kontinuální integraci. Agilní metody jsou navíc založené na spolupráci, a to jak v rámci týmu tak i externě se zákazníkem, což je činí o dost efektivnější.

Na závěr přidávám krátkou tabulku s porovnáním jednotlivých metod:

	Waterfall	RUP	Agile
	Sekvenční	Inkrementální	Iterativní
	Jasně definované requirementy.	Počítá s mírnou změnou requirementů.	Requirementy se konzultují se zákazníkem v průběhu.
	Specifikace se nemění	Specifikace se nemění v rámci inkrementu.	Specifikace se nemění v rámci sprintu.
	Jednotlivé fáze (analýza, design, testování, …) jsou oddělené a sekvenční.	Jednotlivé fáze (analýza, design, testování, …) jsou oddělené, ale běží paralelně.	Nerozděluje projekt na jednotlivé fáze. Každá úloha obsahuje všechny fáze (analýza, design, testování, …).
	Striktně definovaný proces, který nepočítá s žádnou změnou.	Složitý, use-case driven, architecture-centric proces.	Metodologie založená na rychlé reakci na změnu a spolupráci (interní i externí).
	Jednotlivé fáze jsou zdokumentované	Snaha mít vše do detailu zdokumentované.	Dokumentace jen v nejnutnější míře, jednoduchý designe, hlavní metrikou je spokojenost zákazníka.
R I Z I K A	· Nespokojenost zákazníka (něco jiného než chtěl) · Dlouhý refactoring · Nepřesné odhady	· Příliš složitá a náročná architektura · Dlouhý refactoring · Nepřesné odhady	· Náročný na komunikaci a kooperaci · Musí odpovídat firemní kultuře
P O U Ž I T Í	Jasně definovaný a dobře specifikovaný projekt kdy změna je vysoce nepravděpodobná. Zákazník musí perfektně vědět, co chce dopředu. Náročný na zkušenosti jednotlivých engineerů.	Komplexní systémy vyžadující detailní dokumentaci a náročnou architekturu. Změna požadavků je nepravděpodobná. Náročný na zkušenosti jednotlivých engineerů.	Projekt pro běžné zákazníky co často úplně přesně nevědí, co chtějí. Požadavky se mohou měnit v rámci projektu. Cílem je spokojený zákazník. Střední nároky na zkušenosti týmu.

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.

Konference Agile Eastern Europe

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.
Agileee Speaker

KDE:
Kyiv (Kiev), Ukrajina

KDY:
18-19 Září 2009 (Pá-So)

Rádi Vám pomůžeme s organizací a cestou na konferenci.

Možnost skupinové slevy (od 10 lidí);
Letenky, doprava z letiště, rezervace ubytování

Kontakt: .

Agile Eastern Europe Conference

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 – neformální setkání příznivců agilních metod

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.

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.