Proč firmy přechází na agilní metody a Scrum?

Co vede v současnosti firmy k zavádění agilních metod? Já jsem si vždycky myslela, že to bude efektivita, týmová spolupráce a větší zastupitelnost, že firmy nebudou se svým současným procesem spokojeni… Možná. Ale za poslední rok jsem narazila spíše na firmy, které říkaly, že jejich současné procesy jsou dobré, lidi práce baví, výsledek je kvalitní a efektivní jsou dost, i zákazník je s výsledkem spokojený.

rychlé procesy jsou agilní

Ptáte se, kde je tedy problém? Také mě to zajímalo a tak jsem se zeptala. A zjistila, že doposud jim jejich striktní těžké procesy vyhovovaly, ale teď se svět změnil. Všechno je rychlejší, dynamičtější, každý očekává všechno hned. Nikdo nechce čekat rok, rok a půl, než dostane funkcionalitu, kterou potřebuje. Ostatně podívejte se, jaký jsme měli před rokem mobilní telefon a jaký máte dneska. Můj super nový iPhone4 už je skoro zastaralý a to ho nemám ani půl roku. Trh zrychlil. A tak nemáte komfort toho vše si do detailu rozmyslet, předat, zaprotokolovat, udělat analýzu, popsat UML diagramy, rozmyslet třídy, rozkreslit chování, popsat GUI, nakódovat, otestovat, opravit, předat, upravit aby se to dalo používat, opravit … a mít čas si v klidu užít dobrý pocit ze skvěle odvedené práce.

Firmy se v podstatě dělí na dvě skupiny, jedna chce agilní metody protože jejich zákazníci chtějí funkcionalitu hned, ikdyž po menších kouscích, tak googlují a najdou Scrum. Druzí mají strach, že jejich konkurence bude po krizi, kdy nikdo moc do vývoje neinvestoval, rychlejší a tak zase googlují a najdou Scrum. Někeří jsou tak daleko, že Scrum s plánem releasu je moc svazuje a přijdou na to, že chtějí radši Kanban a že funkcionalitu nepotřebují plánovat dopředu ani na úrovni backlogu. Ale to už je jiná story.

Není to pěkné vidět konzervativní velké korporace z bankovního světa, pojišťovny, telekomunikační operátory, velké mezinárodní společnosti jak najednou říkají my chceme přejít na agilní metody? Na druhou stranu, tyto velké korporáty jsou většinou v přechodu na agilní metody a Scrum proces úspěšnější než malé firmičky. Nevzdají se tak snadno. Není to jejich první změna. A vědí, že žádná změna není snadná, a žádná změna není zadarmo. Že je bude stát spoustu úsilí firmu změnit.

Mám je ráda, je s nimi legrace, nutí mě to přemýšlet, ale hlavně, na konci je odměna ve formě fungujícího agilního týmu. Což je zdaleka nejlepší motivace, kterou agilní kouč může dostat.

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?

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

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.

Co bychom si měli uvědomit, než s agilními metodami začneme?

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.

backlog-representation

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.

burndown-data

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.

burndown-velocity-rychlost-graf

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í.

burndown-graf

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

burndown-project-completion-date

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 🙂

Agilní praktiky XP – Kolektivní vlastnictví kódu

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.

Agile and Coding standard

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 role
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.
Product Owner role
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ý.

Workshop - přijďte si zkusit Scrum proces

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í.

Jednoduchý design

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.

Ultralight design - Extreme Programming (XP)

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.