Agile | Zuzi's Blog o Agilu a Scrumu

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.

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.

Scrum proces není všemocný

Scrum proces se zdá být jednoduchou náplastí na všechny problémy. Nefunguje Vám tým? Začněte používat Scrum. Jste zahlceni byrokracií, Scrum Vás jí zbaví. Máte málo kvalitní kód, a pořád něco předěláváte? Netestujete? Zákazník není spokojen s tím, co dostal? Scrum má řešení. Tak se pojďme podívat, jak modelové firmy Scrum proces nasazují.

1. Technokrat s.r.o

Ředitel pověří někoho ze zkušenějších teamleaderů či vývojářů v týmu aby zjistili, o co jde. Ten si udělá research. Možná si koupí knihu, ale internet většinou stačí. Všechno umíme a víme, tak začneme. Scrum meeting (daily standup) je zdánlivě jednoduchý a chcete-li dělat Scrum, tak ho prostě musíte mít. Zároveň je ale třeba hledat tool, protože kartičky se používaly maximálně před sto lety. Čím složitější tool je, tím více možností má, ty všechny by se nám mohly hodit. A výsledek je, že tým brblá, že je to všechno k ničemu, proč tráví denně hodinu na meetingu který nic nepřináší, že své práce má dost. Toolu nikdo nerozumí, a Scrum metodě také ne. Navíc produktivita výrazně klesla a zákazník se také netváří nadšeně. Zeptáte-li se na Scrum metodu, dozvíte se, že Scrum my známe a děláme, ale my jsme v tom a tom jiní a pro nás se Scrum proces nehodí a nejde vlastně použít.

2. Developper s.r.o

Vývojáři o Agilních metodách nebo Scrumu nebo XP zaslechli někde od jiných týmů. A líbí se jim to. Nikdo by jim přeci nerozkazoval, nikdo by jim neříkal, co mají dělat a jak. Plánuje přeci tým, a to jsou oni. Cool. Tak začnou jednotlivé praktiky dělat. Většinou to selže v napojení na management. Někdy už na úrovni teamleadera, někdy až u top managementu. Spousta managerů v Čechách je ze staré školy. Bojí se dát své pseudozodpovědnosti na ostatní. Bojí se, že by někdo mohl vědět, co a jak dělají. A co se chystají dělat. A že by vše neměli pevně v rukou. A tak je lepší praktiky Scrumu omezit, okleštit nebo zakázat. Ale ne přímo, oni dělají Scrum, ale vidíte, dali jsme jim šanci, a ono to mělo takové problémy…

3. Korporát a.s.

Scrum proces a agilní metody používají velké firmy okolo nás. Měli bychom ho zkusit. Pošleme týmy na kurzy, project managery na certifikaci Scrum Mastera, a změníme procesy. Týmy tedy začnou, a až do prvního většího problému vše funguje. Pak ovšem project manager zapomene, že má jinou roli, a že jako Scrum Master nesmí měnit plán, nesmí rozhodovat za tým, a rychle se vrátí k osvědčeným metodám řízení projektů, na které byl zvyklý. A celá firma prochází deziluzí. Dalo by se říci, že devět z deseti project managerů se na Scrum Mastery nikdy nepodaří přeučit.

Existují i úspěšné firmy. Velké i malé. Ty většinou pochopili, že Agilní metody a Scrum představují změnu myšlení a přináší změnu kultury firmy. Investovali do kurzů, našli si interního či externího kouče aby jim s transformací pomohl. Vědí, proč změnu chtějí a co od ní očekávají. A vědí, že změna je náročná a vyžaduje hodně každodenní práce na každé úrovni. Taková změna nejde nařídit zhora, ani partyzánsky vybudovat odspodu. Musí propojit celou firmu. Stojí hodně energie. Ale výsledek pak stojí za to.

Co mi přineslo WebExpo 2010 – část 3

WebExpo, tedy agilní sekce konference o které teď volně píšu zážitky, mi přineslo i překvapení, že někteří z přednášejících berou agilní praktiky velmi striktně. Třeba Boris říkal, že ScrumMastera prostě musíte mít na full time na projektu. Zdůvodnění dávalo smysl, říkal, že ScrumMaster zefektivní tým o více jak 100% a tedy se ta investice hned zaplatí. Ovšem jeho odpověď na otázku co dělat když mám malý tým – radil, že mám dva týmy pracující pro různé zákazníky spojit do jednoho – mi už úplně realistická nepřipadala. Působilo to hodně procesně orientované, bez ohledu na realitu. Ideální svět neexistuje. Je dobré znát ideální řešení, ale je dobré ho i upravit když toto ideální řešení z nějakého důvodu nelze použít. Asi mi byl bližší přístup Davida, který říkal, že když praktikujete stand-up meeting, rozumíte jeho cílům, víte jak se má dělat, ale nepřináší vám očekávanou hodnotu, tak je pro Vás možná lepší ho nedělat vůbec, protože třeba není pro Vás.

Odhlédneme-li od spíše filozofické diskuze jestli se musíme spíše my přizpůsobit praktikám, či raděj přizpůsobit praktiky, Boris vysvětloval poměrně často zmiňovaný problém co dělat s tím, že některé úlohy potřebují nejprve strategicky rozmyslet a teprve potom se můžou implementovat. Následující obrázek ukazuje, jak se na danou problematiku můžete dívat z pohledu velocity. Jednou z možností je samozřejmě ohodnotit i tyto strategické práce, ale na druhou stranu, to že jeden den rozmýšlíte co dál, nemá pro zákazníka žádnou konkrétní prezentovatelnou hodnotu. A tedy je těžké to nějak ohodnotit. Proto mě zaujal princip navržený Borisem, který doporučoval počítat jen hodnotu pro features (zelená) a nikoli hodnotu kterou jsme věnovali strategickému rozvažování co a jak dál. Následující obrázek ukazuje, co mám na mysli.

Na závěr dodávám, že se chystám na Borisem vedený certifikační kurz CPO – tedy Certified Product Owner, a jsem tedy docela zvědavá, co mi takový kurz přinese. Ale o tom zase příště.