Agile | Zuzi's Blog o Agilu a Scrumu

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.

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 5

Paul se věnoval tomu, jak prodávat Agile. Je dobré si uvědomit, jak se cítí project manager, jak obchodník a jak zákazník? Co jsou jejich cíle? Co potřebují a proč? Např. u Waterfallu se projektový manager cítí přinejmenším do poloviny projektu skvěle. Ano, na začátku stálo hodně úsilí vše rozmyslet a rozplánovat. Ale teď už jedeme podle plánu. A skvěle to jde. A i kdyby, na konci projektu je ohromný buffer – víte, jak se jmenuje? Testování. Vše je přeci dobře vymyšleno, programátoři píší dobrý kód, tak k čemu by nám u takto dobrého kódu vlastně to testování bylo? V nejhorším se koupí na sobotu pizza a uděláme velký testovací den. A na konci projektu? Uff, to jsme rádi, že je to za námi… Hlavně žádná reflexe, už na to nechceme ani pomyslet. Tohle všechno agilní metody mění.

Chcete-li být úspěšní ve vysvětlování agilních metod, naslouchejte zákazníkovi, ukažte, že rozumíte jeho problémům a potřebám a že jsou pro Vás opravdu důležité. Dokažte jim, že víte co je pro ně důležité. Většina zákazníků bude ráda s někým takovým spolupracovat.

Co se týče kontraktu, stačí vám jedna stránka. Co je na ní obsahově? Definované dvě smluvní strany a cena za dodávané služby. V několika velmi stručných větách ošetřuje kvalitu a podmínky kontraktu, vlastnictví a případné změny kontraktu. Je to hodně inspirativní. Zvláště pracujete-li pro velké korporace či znáte jejich smlouvy.

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

Andrea začal svoji přednášku prohlášením: It’s not a technology which makes a difference. Tedy že technologie Vám k úspěchu nepomůže. Potřebujete něco víc. Leadership.

Zamyslete se nad tím v kolika případech manageri okolo vás používají jen tyto dva základní nástroje: Hůl a mrkev. Všechny bonusy jsou o tomto principu. A funguje to? Jen v krizových situacích. Ale většina firem není 100% času v krizové situaci, nebo by alespoň neměli být. A nic jiného z oblasti řízení lidí a motivace neznají.

Andrea měl výbornou hru kdy nechal účastníky zažít, jak se manageri většinou chovají, a jaké to má následky. Co se stane, když je někdo ze systému náhle odebrán, a teď se všichni tváří, že ten člověk nikdy ani neexistoval (Týna v tomto případě z ničeho nic odjela do Dánska a nový manager přišel a nikdo nevěděl proč). Myslím, že se to musí zažít. Dobré na tom je to, že i když nový leader je slabý a vlastně ani leaderem není, systém si najde neformálního leadera a vše funguje dál. Jen ne tak dobře. I pro nového leadera navázat na existenci předchozího leadera a třeba i věci změnit, než se tvářit že ten před ním nikdy neexistoval. Dejte si fotku týmu na nástěnku ke kávovaru a až se někdo zeptá kdo to je, je snadné odpovědět to je Týna, Týna je teď v Dánsku ale předtím to byla naše managerka. Konzistence týmu není narušena. A vše funguje dál.

Na závěr ještě vzpomenu Andreovu radu, že nemůžete úspěšně nasadit Scrum ve firmě kde chybí leadership. Všechnoživé je vždy samoorganizující se. Jen se to často organizuje jinak, než bychom to rádi viděli. Co je tedy největším problémem obecně? “Overusing technical mind“…