zuzi | Zuzi's Blog o Agilu a Scrumu

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 – Kolektivní vlastnictví kódu

Chcete-li mít tým potažmo SW firmu opravdu efektivní, musíte se řídit pravidlem, že nikdo nevlastní kód ani jeho část. Narážíte-li na námitky vývojářů že to nejde, neboť jen oni opravdu rozumí dané části aplikace a ostatní by jim to jen zkazili, není to nikterak neobvyklé. Stačí věřit tomu, že to jde a mít schopnost zavést týmové metody spolupráce. Třeba Scrum proces nebo agilní metody řízení softwaru 🙂

Abyste mi věřili, že to je možné i ve velmi složitých prostředích kritických na jakoukoli chybu, přikládám následující case study.

Case Study – “NENAHRADITELNÝ JAMES”

Prostředí
Mezinárodní firma operující v life critical oblasti, přes 50% světového trhu v daném sektoru. Vývojová centra v několika zemích.

Projekt
Migrace všech aplikací na novou platformu pro divizi A. Přes 60 aplikací, čtyři odlišné architektury. Několik sdílených knihoven a klíčových oblastí.
Současně s migrací probíhal vývoj nových funkcionalit v rámci původních aplikací na originální platformě.

Původní stav
Každá sdílená oblast měla jednoho vlastníka (skupinu vlastníků), který oblasti skvěle rozuměl, a nikdo jiný nebyl oprávněn oblast měnit.

Nejvíce kritická situace nastala v klíčové knihovně využívané všemi 60 aplikacemi. Tu měl na starosti James, který ji před mnoha lety navrhl, vymyslel, naimplementoval a celou dobu dělal všechny potřebné změny pro jednotlivé aplikační týmy.

Vzhledem k jeho unikátním znalostem a komplexitě problému bylo řešení v lokálním měřítku optimální, a jeho kapacita stačila požadavkům okolí.

Koncový stav
Po startu migrace, začal být velmi rychle James zahlcený požadavky na změnu knihovny, která byla sdílená přes nové i staré aplikace a v rámci migrace se musela výrazně měnit. Nepomohlo ani to, že některé týmy navrhovaly přímo konkrétní implementaci řešení, kterou stačilo zrevidovat a použít. Čekací doba na změnu kritickou pro migrační projekty byla několik měsíců, což ohrožovalo projekt jako celek.

Řešením byla změna přístupu k této sdílené knihovně a odstranění unikátního postavení Jamese, který už nadále nemohl knihovnu vlastnit a být jejím výhradním přispěvovatelem. Z knihovny se stal sdílený kód, ke kterému měly přístup všechny týmy. Nebyly zpočátku sice tak efektivní jako James, ale průchodnost systému jako celku se odblokovala. Změny samozřejmě probíhaly za Jamesova dohledu a podléhaly revizi Jamese i týmu architektů, aby se předešlo problémům s kvalitou.

Podobné oblasti jsou ve všech větších firmách s komplexnějším prostředím a udělat z nich sdílený kód obvykle pomůže systému jako celku.

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.

Kdo je to Scrum Master? A kdo Product Owner?

Chcete vědět co je podstatou role ScrumMaster a ProductOwner v rámci Scrum procesu? Tady je stručné shrnutí těchto rolí.

SCRUM MASTER role

ScrumMaster především:

pomáhá týmu dosáhnout jeho cílů
odstraňuje problémy
motivuje tým k lepším výsledkům
chrání tým před vnějšími vlivy, které by ho mohly odvádět od soustředěné práce na definovaném cíli

Není to teamleader v klasickém slova smyslu, ale pracuje jako mezičlánek mezi týmem a jakýmkoli rušivým elementem zvenku.

Stará se o to aby Scrum proces byl efektivní a fungoval, má na starosti jeho dodržování, ale zároveň i možnost ho změnit je-li to třeba.

ScrumMaster by měl upřednostňovat koučovací principy, podporovat tým a jednotlivce v jejich rozvoji, být komunikativní, vnímavý a utlumovat případné konflikty v rámci týmu.

ScrumMaster je ten, kdo se stará aby se “kola týmu točila” a který “zametá cestičku”, aby se týmu dobře šlo a pracovalo. ScrumMaster je součástí týmu a měl by být týmu kdykoli k dispozici. Sedí proto v jedné místnosti s týmem.

Funguje-li ScrumMaster dobře, nedá se jeho pozice chápat jako vícenáklad. To že rozpohybuje tým a zajistí tak vyšší efektivitu, kvalitu a motivaci v celkovém rozsahu ušetří vice peněz než ScrumMaster teoreticky stojí.

PRODUCT OWNER role

ProductOwner je vlastníkem produktu. Má na starosti definování vize projektu a její transparentní komunikaci týmu, zákazníkům, firmě. ProductOwner definuje priority, rozhoduje, na které funkcionalitě se bude pracovat dříve, na které později a na které vůbec. Má na starosti Business Value, a také ROI produktu.

ProductOwner je týmu pravidelně a podle potřeby k dispozici, ale na rozdíl od ScrumMastera už s týmem nesedí v jedné místnosti. Tráví dostatek času se zákazníky, aby vstřebal jejich prostředí a dokázal se vždy správně rozhodnout kde je pravá hodnota pro zákazníka.

ProductOwner neřídí jednotlivé členy týmu ani tým, nemá možnost jim přikazovat, co musí dokončit, jen stanovuje, co se má dělat a v jakém pořadí (priority).

Primárním cílem ProductOwnera je tedy porozumění produktu, zákazníkovi a definice, komunikace, a jasné vysvětlení cíle, kam jdeme, proč a jak. A to jak týmu, tak managementu a zákazníkům. Cíl musí být pro všechny stejný, jazyk, kterým ho komunikuje, bude však odlišný.

Role by neměla být kombinována s rolí ScrumMastera.

Přijďte si zkusit Scrum proces

První akce nově vzniklé Agilní Asociace je workshop: Přijďte si zkusit Scrum.

Vyzkoušejte si Scrum proces formou hry. Seznamte se s lidmi z firem co agilní medody a Scrum proces používají nebo o něm uvažují.

Kdy: Čtvrtek 10.2.2011, 16:00 – 18:00

Kde: CA Technologies CZ, s.r.o.
V Parku 2343/24,
148 00 Praha 4 – Chodov.

Vhodné jak pro ty, co už Scrum znají, tak pro ty, co se s ním teprve chtějí seznámit.

Vstup volný.

Uvažujete-li že přijdete, přihlašte se emailem na info@agilniasociace.cz, na Facebooku, nebo na LinkedIn.

Agilní Asociace je sdružení příznivců agilních metod. Cílem Agilní Asociace je zvýšit povědomí o Agilních metodách řízení, a vytvořit platformu pro sdílení informací a zkušeností z oblasti Agilních metod.

Přijďte se na naše akce podívat, staňte se našimi členy 🙂

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.