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: kontakt.

Aginli konsorcium Agile Eastern Europe

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.

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.

Jak fungují organizace?

Narazila jsem na jeden velmi zajímavý článek který bych Vám ráda doporučila k přečtení. James G. March na jedné ze svých přednášek v Mexicu (1982) o organizacích a o tom, co je dělá funkčními uváděl velmi pěkný příklad (On Leadership: A Short Course – Google Books ). Použil příhodu s autonehodou ve Spojených Státech a různé vzorce chování kolemjdoucích v různých státech, aby Vás donutil zamyslet se nad tím, co v organizaci máte a co byste chtěli mít. Velmi zajímavé čtení, navíc doplněné anketou.

Kde byste chtěli pracovat Vy? V ‘Iowě’?

GoogleDocs, Backlog a Burndown Graf

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.