Agile | Zuzi's Blog o Agilu a Scrumu

Co si představíte pod slovem “Agilní”?

Něco divného? Nového? Neznámého? Něco těžko definovatelného, asi jako tahle frogfish?

Nebo se již agilní metody staly nedílnou součástí nejen vašich projektů, ale i života?
Co to tedy znamená být agilní? Dynamický, flexibilní, rychlý, mít schopnost reagovat na změnu, komunikovat se zákazníkem, ptát se po jeho potřebách. Pracovat jen na tom co přináší hodnotu. V krátkých cyklech. Učit se. Zlepšovat se. Měnit se, atd..

Co bychom si měli uvědomit, než s agilními metodami vůbec začneme? Každá změna je náročná a zrovna tak změna z klasických metod řízení projektů na agilní metody. Každá změna s sebou přinese spoustu problémů, které budeme muset překonat. Vyřešit. Proto musíte dopředu vědět, kde máte problém a co od přechodu na agilní metody očekáváte.

Zkuste si odpovědět na následující otázky:
Jak vnímáte vy, sami za sebe, následující parametry vašeho procesu? Jak byste ohodnotili současný stav? Na stupnici 1-10, kde 1 je “hrůza“ a 10 je úplně “super“.

Kvalita
Efektivita
Flexibilita
Předvídatelnost
Týmová spolupráce

Hodnota je jen Váš pocit, to jak to vidíte Vy. Vaši kolegové to mohou vidět jinak.

A teď to zkuste ještě jednou, ale zamyslete se, kde byste chtěli být.
Když si hodnoty dáte vedle sebe, v zápětí uvidíte, proč a jestli byste se vůbec do zavádění agilních metod měli pouštět. Věřím, že ano. Ale aby takový proces mohl být úspěšný, musíte vědět, co od něj očekáváte, co by Vám měl přinést.

Podle toho co budete od agilních metod očekávat, budete teprve sami či spolu s agilním koučem sestavovat Váš agilní proces, ať už to bude více Scrum, Kanban, či ExtremeProgramming.

Burndown grafy

Sice už jsem tu párkrát o burndown grafech psala, ale nedávno jsem rozšířila a opravila původní template, a nakonec, opakování je matka moudrosti, tak ho tu popíšu ještě jednou.

Microsoft Excel Scrum Burndown template najdete zde.

A teď k popisu jednotlivých záložek. Na prvním obrázku je reprezentace product backlogu. V levé části jsou definovány jednotlivé Super User Story a User Story, spolu s ohodnocením. V pravé části je zaznamenán progress na konkrétní User Story v daném Sprintu.

V další záložce se vlastně všechna data počítají. Jediné co musíte udělat je každý Sprint vyplnit aktuální hodnoty do sloupce C a D – Data from Backlog (Points Remaining Velocity a Actual Points Complete). Zároveň před začátkem projektu nastavit očekávanou rychlost týmu a buffer / očekávaný přírůstek bodů za sprint – sloupce K a L (Plan: Planned Velocity a Planned New Points (Buffer)). Chcete-li sledovat i jak se Vám posouvá datum konce projektu, vyplňte si na začátku projektu i v Planned Date sekci sloupec F (Target Date) a každý Sprint aktuální predikci v Planned Date sekci sloupec E (Projected Completion Date). Všechno ostatní se počítá a kreslí za Vás.

A následují grafy. První z nich sleduje plánovanou rychlost týmu a porovnává ji s aktuálními hodnotami, kterých tým byl schopen dosáhnout.

Další graf zobrazuje klasický burndown graf rozšířený o predikce kdy očekáváme, že bude projekt hotový. V jednoduchosti řečeno, pokud se pohybujete mezi tečkovanými čárami, běží vše podle očekávání.

Poslední graf který v souboru najdete Vám ukazuje jak se v čase měnilo předpokládané ukončení projektu.

Agile Lean Europe network – ALE

Další akcí evropského rozměru je určitě Agile Lean Europe network – ALE. ALE dal dohromady Jurgen Appelo, našel zástupce z jednotlivých Evropských zemí a inicioval diskusi na otázky zaměřené na lepší spolupráci jednotlivých komunit v rámci Evropy. Co by mohlo být lokální agilní komunitě užitečné, jak může naopak lokální agilní komunita pomoci ostatním zemím, jak nejlépe pravidelně sdílet znalosti a zkušenosti a kontakty, jak rozšiřovat agilní sítě a plně využívat i znalosti a zkušenosti evropské agilní komunity, a jak nastartovat proces zlepšování prostředí a procesů v SW firmách.

Diskuze probíhají na lokální úrovni a následně budou pokračovat na konferenci XP 2011 v Madridu začátkem května, kde proběhne world café session zaměřená na prezentaci cílů ALE network.
Zapojit do diskuse o cílech ALE network se můžete na následujících dvou akcích Agilní Asociace: Workshop v Plzni a open café v Praze.

A protože do Madridu se za agilní komunitu chystáme, určitě o tom po návratu něco napíšu.

Agile testing days

Nedávno mě kontaktovali pořadatelé konference Agile Testing Days v Německu, a nabídli mi stát se ambasadorem konference. Takze Agile Testing days bude další konference na kterou se letos chystám, a z které se podělím o novinky agilního světa. Zatím to vypadá jako fajn akce. Téma je “Interactive Contribution” a v programu je spousta zajímavých přednášek.

Rychlým pohledem mě zaujala keynote talk Esther Derby: “People and Patterns”, a přednáška od Markuse Gaertnera: “I don’t want to be called Q any more! – Agile Quality Assistance”.

Konference se koná 14-17. listopadu 2011 v Dorint Hotel Sanssouci Potsdam (kousek od Berlína).

No, a kdybyste uvažovali o účasti, tohle je promo na jeden z mnoha tutoriálů (by Lisa Crispin). Usuďte sami.

Agilní praktiky XP – Coding Standard

K čemu je takový coding standard dobrý? Tak rozhodně usnadňuje orientaci v rozsáhlých projektech. Říká, jak by měl být kód formátovaný, jak strukturovaný, jaké konstrukty použít a jakým se vyhnout, ae i jakou použít jmennou konvenci. Je to stejný styl pro všechny.

Chcete-li nechat více lidí pracovat na sdíleném kódu, je to v podstatě nutná podmínka. Standardy v rámci prostředí a nástrojů se také hodí. Používáte-li stejné nástroje, je přechod lidí mezi týmy snazší. Stejně tak, máte-li jednotný coding standard, usnadníte spolupráci v rámci týmu i celé firmy a vlastně se výrazně usnadní i celý review proces.

Ne – certifikační kurz na Scrum proces?

Krize je pomalu za námi, firmy začínají zase investovat do vývoje nových funkcionalit a produktů a přemýšlí jak být rychlejší, flexibilnější, efektivnější. Jak být lepší než konkurence. A najdou agilní metody a Scrum proces. Ty organizovanější přijdou na to, že potřebují certifikaci, aby jim to opravdu šlo. Co je tedy certifikace v podání Scrum Aliance? Ty, co by čekali nějakou zkoušku či test, musím zklamat. Nic takového certifikace neobsahuje.

Na trhu jsou obecně k dispozici dva kurzy – Certified Scrum Master kurz CSM a Certified Scrum Product Owner kurz CSPO. Oba jsou velmi drahé. Důvodem je to, že takový kurz smí školit jen Certifikovaný trenér, a těch je vzhledem k procesu definovanému Scrum Aliancí relativně málo, a to i v celosvětovém měřítku. Důvodem je starost Scrum Aliance o kvalitu trenérů. Neříkám, že tito trenéři nejsou dobří, jen říkám, že i skvělého (necertifikovaného) trenéra z USA/EU seženete za polovic.

Absolvovala jsem CSPO, a určitě jsem se hodně dozvěděla. A určitě to mělo nějaký přínos. Očekávat ale, že tím že necháte přecertifikovat Scrum Mastera a Product Ownera zajistíte, že budou schopni zavést Scrum, je poněkud přehnané. Oba certifikační kurzy jsou jen dvoudenní kurzy, kde se účastníci něco dozvědí. O certifikaci jejich opravdových znalostí a schopností však nemůže být ani zmínka.

Máte-li pocit, že nevíte na koho z necertifikovaných trenérů a koučů se obrátit, a chtěli byste raději někoho z USA/EU, ráda vám někoho doporučím. Za stejný budget dostanete víc, než certifikací. A nakonec trváte-li na certifikaci, i mezi těmito trenéry jsou velké rozdíly.

No a pro ty, co nesměřují ani k certifikaci, ani nemíří do ciziny, můžu nabídnout své zcela obyčejné české kurzy Scrum procesu a agilních metod, na kterých se dozvíte vše, co potřebujete vědět o agilních metodách a Scrum procesu 🙂

Agilní praktiky XP – Jednoduchý design

V úvodním příspěvku o agilní metodě Extreme Programmingu jsem uváděla čtyři základní hodnoty: jednoduchost, komunikace, zpětná vazba, odvaha. Těchto základních hodnot se dociluje pomocí několika základních praktik.

Držte jednoduchý design, protože nikdy nevíte, co zákazník opravdu bude chtít. Tak proč dělat obecné robustní architektury kterým pak skoro nikdo nerozumí a tak je veškerý refactoring přinejmenším složitý. Rozmyslete si, čím trávíte svůj čas. Spíše než věnovat čas obecnému designu, je lepší přijmout, že požadavky se mění každý den, a uzpůsobit svůj proces tak, aby byl flexibilní a dobře reagoval na změny. Jednoduchou a lehkou konstrukci můžete snadno přestavět. A není to složité. Stojí to trochu času navíc, ale o hodně méně než předělávat něco, co by se dalo přirovnat ke kusu železobetonu. A právě o tom je agilní programování.

Asi budete všichni souhlasit s prohlášením, že zákazník neví, co chce. Ano většinou to ani sám zákazník neví. A zjišťuje to až v průběhu procesu. A právě proto většina klasických metod selhává. Počítají totiž s tím, že co jsme si na začátku domluvili (a dali do smlouvy), platí na věky. A tak jim nic nebrání v generování složitých a do detailu promyšlených řešení, která ale nikdo nepotřebuje ani nechce. Jen o tom z pohledu zákazník nikdo nepřemýšlí. Proto přeci máme detailní smlouvy. A bohužel, proto máme tolik nespokojených zákazníků a tolik neúspěšných projektů.

Agilní vývoj aneb jak na Extreme Programming (XP)

Oblíbenou metodou agilního vývoje softwaru je i Extreme Programming (XP). Na rozdíl od Scrum procesu, XP je více zaměřeno na jednotlivé praktiky než na konkrétní proces. Míří přímo na vývojáře a testery, a proto je často vnímáno více jako soubor praktik agilního vývoje či agilního developmentu, než metoda řízení projektů. Jednotlivé praktiky se velice často používají i v rámci Scrum procesu.

Takže o čem je vlastně Extreme Programming? XP říká, že když je něco dobré, tak proč to nedělat pořád. A proč nedělat jenom to. Jednoduchý princip. Dělejte jen to, co se Vám osvědčilo. Nic převratného v tom není. Ostatně kdo by chtěl opakovat pořád stejné chyby. XP dále aplikuje tyto čtyři hodnoty: jednoduchost, komunikace, zpětná vazba, odvaha.

Dělejte jen na věcech, na kterých opravdu záleží. Každý den. Bez vyjímek. Nevymýšlejte složité designy a architektury, nepište věci, které nikdo nepotřebuje. Uvedu příklad. Když si zákazník u Vás objedná koloběžku, Váš tým specialistů se obvykle usnese, že ‘To už známe, on zákazník vždy chce koloběžku, pak si ji zkusí, zjistí, že nemá rovnováhu a my to pak předěláváme na tříkolku.‘ A tak se vytvoří silný ‘core‘, tedy ‘podvozek‘ tak, aby z toho šlo snadno udělat cokoliv se dvěma a více koly. Jak to obvykle dopadne? Zákazník si z toho objedná třeba ultralight, a ten těžký podvozek nás pak celý projekt potáhne k zemi.

Tedy jen tak, že budete komunikovat se zákazníkem, abyste věděli, co potřebuje, a následně budete dělat jen věci, která jsou opravdu potřeba, a až tehdy když jsou potřeba, zajistíte, že zákazník dostane to, co opravdu potřebuje. A dostanete to rychle. Abyste byli v tomto procesu úspěšní, musíte umět naslouchat a učit se ze svých chyb. Učit se, co jste dělali dobře a pak už dělat jen to co se Vám osvědčilo. Jen tak budete efektivní a lepší než konkurence.

Retrospektiva – Časová osa

V předchozích příspěvcích jsem doporučovala retrospektivu jako zcela zásadní praktiku agilních metod a Scrum procesu. Ideální je začít retrospektivu kolečkem, kde každý člen týmu identifikuje co se mu líbilo a co ne. Když už vás tento formát omrzí, můžete posílit vnímání reality tzv. hvězdou. Obě tyto metody nechávaly popis situací a pocitů až na retrospektivní meeting. Další metodou je časová osa, která dává možnost pojmenovat pozitivní i negativní události už v průběhu Sprintu.

Připravte si následující časovou osu a barevná lepítka a nechte tým zapisovat jejich pocity hned, jakmile daná situace nastane. Na retrospektivu potom dostanete podobnou časovou osu s událostmi, tak jak je jednotliví členové týmu zaznamenali. Červené lístečky hodnotil pisatel jako negativní, zelené jako pozitivní, oranžové jako něco mezi, co ale stojí za zmínku. Zároveň se dá říci, že čím výš je kartička umístěná, tím důležitější je. Ale ostatně stanovte si na to vlastní pravidla tak, aby tým bavilo kartičky vymýšlet a lepit na časovou osu.

Na začátku retrospektivy nechte každého člena týmu udělat tečku pro každou kartičku, aby se mohl vyjádřit, jak danou událost viděl on.

Následně projdete jednotlivé události a jako u kolečka nezapomeňte, že retrospektiva funguje jen tehdy, když jako její výsledek jsou akce, dohody a pravidla. Retrospektiva musí měnit zaběhnuté procesy, musí dát lidem možnost se poučit z toho, co fungovalo i z toho co se úplně nepovedlo. Scrum proces zavádí retrospektivu jednou za Sprint, a věřte, že to není ztráta času.

Časová osa má mnoho výhod. Obvykle odbourává formalismus, retrospektiva je zábavnější. Část kartiček na tabuli bude určitě jen pro zasmání. A o to možná jde. Vzpomenout si i na drobnosti které nemají žádný zásadní vliv na projekt, ale stmelují tým dohromady. Retrospektiva tím dostává větší dynamiku a je snazší zapojit všechny členy týmu.

Retrospektiva – Hvězda

Jak již jsem psala, retrospektiva je asi nejdůležitější praktikou agilních metod a nedílnou součástí Scrum procesu. Protože, aniž byste se učili a vylepšovali a upravovali Váš proces, nikdy nebudete dostatečně agilní, ale ani efektivní, kvalitní a úspěšní. Při retrospektivě si uvědomíte, co jste dělali dobře a co ne. Co je třeba změnit a co naopak dělat i příště.

Další možnost jak dělat retrospektivu je takzvaná hvězda. Když už Vám základní framework tzv. kolečka přijde moc nudný, nechte lidi napsat jejich pocity na lístečky a ty následně umístit do kategorií dle následujícího obrázku: Stop Doing, Less Of, Keep Doing, More Of, Start Doing.

I taková jednoduchá klasifikace občerství retrospektivu. Donutí všechny jít více do detailu a opravdu se zamyslet nad tím, co bychom chtěli začít dělat, co naopak dělat nechceme vůbec, co omezíme, co posílíme a v čem budeme pokračovat.

Nezapomeňte, jsou to pocity jednotlivých lidí a jako k takovým by se k nim také mělo přistupovat. Nikdo si nečiní nárok na universální pravdu. Všichni mají stejné právo se vyjádřit. A jenom tím, že se naučíte si vzájemně naslouchat, se stanete efektivnějšími. Zmizí zbytečné problémy a nedorozumění. A práce Vás bude více bavit. Retrospektiva musí vést k akcím, pravidlům, změnám. Nenechte ji tedy jen tak rozplynout do ztracena.