Přečtěte si co je nového v agilním světě, která témata jsou pro mě zajímavá.
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.
Agilní metody už jsem si vyzkoušela na všech možných projektech, některé zákazníky jsme scrum naučili a oni ho přijali za svojí metodu vývoje. Takže co dál? Proč je vlastně scrum proces tak úspěšný? Rozhodně to není zavedením agilních praktik samo o sobě. Párové programování, Backlog a Burndown vám možná pomůžou ale ta zásadní změna se děje na úrovni firemní kultury. Mění celé prostředí a vnímání reality zaměstnanci. Ti se stávají více zapojeni do procesu a zainteresováni na výsledku. Má to něco společného s motivací ale je to možná více o převzetí zodpovědnosti a zároveň osobním rozvoji. Můžete stokrát používat všechny agilní metody, ale když nemáte agilní kulturu, efekt bude přinejmenším sporný.
Jak tedy agilní kultura vypadá? Tak určitě vyžaduje zapojení lidí do procesu, iniciativu, tedy vysokou motivaci. Dalo by se říci, že na stupnici podle Maslowa budou lidé hodně vysoko, až v posledním stupni pyramidy, kde klíčovou hodnotou je realizování osobního potenciálu, naplnění a osobního rozvoje. Mezi důležité vlastnosti bude patřit samostatnost, odpovědnost, ale i sebevědomí. Přechod od direktivní kultury je jistě náročný, ale nikoliv nemožný. Když jsem přemýšlela jak naší firemní kulturu, která by rozhodně mohla být považována za agilní, ještě posílit, napadlo mě, že vlastně ideálním nástrojem bude coaching.
Coaching je vlastně o zvyšování úrovně vědomí. Mělo by nás vhodně kladenými otázkami donutit zamyslet se nad danou věcí a už jen tím že se na danou oblast soustředíme, dokážeme často problém odstranit. Krásně je to vidět ve sportu. Absolvovala jsem nedávno coachovací hodinu tenisu a musím říci, že to skvěle funguje. Rozhovor typu: “Jak se ti hraje? No bolí mě trochu ruka, mám pocit, že se nemůžu pořádně napřáhnout. A kde přesně tě bolí? No v zápěstí, takhle… A co by šlo udělat, aby se to zlepšilo? Šla by třeba chytit jinak raketa? Možná takhle… Je to lepší? Jo…. “ výborně fungoval. Zkuste si ho porovnat s klasickou výukou kde je trenér v roli člověka, co neustále opravuje chyby a říká vám, že raketu držíte špatně, že se musíte dívat na míč a dávat rychlé rány. Asi bych skončila s tím, že k tenisu nemám vlohy.
Takže zpět k otázce jak posílit agilní kulturu? Proč tedy nezkusit coaching. Dobrým začátkem by tedy mohl být model GROW (Goal, Reality, Options, What/When/Who/Will), tedy identifikace cílů a to jak krátkodobých tak dlouhodobých, popis aktuálního vnímání reality, brainstorming možností co s tím dělat a na závěr plán co se má kdy a kdo udělat a jaká je vůle to dokončit.
To zní jako dobrý plán, o jeho realizaci ale zase příště.
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.
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.
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. |
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.
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.