Scrum | Zuzi's Blog o Agilu a Scrumu

Agile Riga Day

Rok se s rokem sešel, a tak jsem se zase objevila na Agile Riga Day, příjemné jednodenní konferenci v Lotyšsku. Letos se organizátorům podařilo zdvojnásobit počet účastníků, a rozrostli se na tři tracky. K tomu jsem ještě měla jednodenní workshop, “Starting Scrum“, takový den plný her, simulací a diskuzí. Bylo zajímavé, že slečny převládaly, ostatně i na konferenci den poté jich bylo výrazně více, než bývá v Evropě zvykem. Ale přeci jen méně než na Agile India. Překvapilo mě i to, jak rádi si analytici, kterých jsem na workshopy několik měla, hráli. U nás mám s analytiky spíše opačnou zkušenost.

Riga a vlastně i Lotyšsko má jedno další specifikum. Je hodně navázané na Skandinávii, takže mám pocit, že jsem byla jedním z mála lidí co nebyli z pobaltsko-skandinávské oblasti. Převládali Švédové, Norové, Estonci. O čem se hovořilo? O tom jak psát dobrý kód, jak dělat refactoring, jak naložit se starým legacy kódem, jestli dělat test driven development, nebo pair programming… výborný workshop na toto téma vedl Johannes Brodwall – Extreme Startup. Moc se mi to líbilo. Už dlouho jsem neviděla na konferenci pair programming v praxi. Bylo zajímavé to sledovat.

Hodně se diskutovaly odhady. Vlastně, začali jsme s tím tématem už den před konferencí v místním baru. K pochopení základního problému s odhady je nutné si uvědomit rozpor mez i tím, co odhady jsou – tedy nepřesná predikce budoucnosti – nijak exaktně přesná být z principu věci ani nemůže, od toho je to odhad. A jistá představa managerů některých firem, že odhad musí být naprosto přesný. A když k tomu dodáme nepříjemný pocit členů některých týmů, že jsou tlačeni do něčeho, co není možné dodat – tedy do stoprocentně přesného odhadu, máme tu problém, který se dá dlouho do noci vášnivě diskutovat. Obzvláště když jeden z diskutujících má ráno na dané téma keynote kde v podstatě říká, že odhady v bodech jsou stejně tak špatné, a nepřesné, že zrovna tak můžeme každý Sprint jen počítat dokončené a nedokončené User Story a odhady nedělat vůbec. Příště o tom třeba napíšu víc.

Dalším tématem, které mě zaujalo, byla myšlenka, že na to, abyste změnili svět, třeba na agilní, je třeba si uvědomit že “nemusíte systém řídit, stačí s ním umět tančit“. Možná že to je jedna z věcí, které musí umět každý Scrum Master, a asi nejen on. Nestačí vědět, jak okolní svět funguje, musíte vyvinout něco, co se bude chovat jako virus. A takový virus potom do okolního, neagilního, světa pustit.

Abych to shrnula, myslím, že všechny praktické sessions pro programátory a testery se osvědčili, a že mám zase pár dalších kontaktů a nápadů na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Konference Agile India 2012

Kolik z vás navštívilo konferenci zaměřenou na agilní metody v zahraničí, a kolik z vás v Indii? Cestuji ráda, takže se to zdálo být jako dobrý nápad. Navíc, chystala jsem se do blízké oblasti na dovolenou, tak proč ne 🙂

Jestli byste čekali, že Bangalore – Mekka IT outsourcingu – bude podobné moderním asijským městům jako Singapore, Kuala nebo Bangkok, tak to ani nápad. Žádná wifi, přelidněné město, všude smetiště a špína. Prostě Indie. Říkala jsem si tedy, že na konferenci uvidím ty IT odborníky, kterých má být Bangalore plné, a že třeba pochopím, proč si velké firmy vybrali pro outsourcing zrovna Indii. Myslím však, že to ani firmy samy nechápou. Jistě, je tu nízká cena. Ale ta je draze vykoupená nízkou kvalitou služeb a ohromným overheadem spojeným s řízením takto distribuovaného projektu.

Takže o čem se přednášelo? Základy, které i v zemích kde se s agilními metodami začíná už dávno znají. Tedy nic, co by stálo za zmínku. Témata, která se řešila, už byla zajímavější. Třeba že Indie je země s nejvyšším indexem “vzdálenosti od zákazníka” – tedy laicky řečeno, na zákazníka kašlou. A taky distribuované týmy a kulturní rozdíly. Zajímavé bylo, že Indové jsou přesvědčeni, že zákazník, když s nimi chce spolupracovat, se jim musí plně přizpůsobit. Třeba není vhodné od nich očekávat, že vám řeknou, jak se věci mají. Budou kývat hlavami, a to, že projekt má problém, se nedozvíte. Když na to jeden ze speakerů narazil, dostal udivenou odpověď z publika, že to je přeci v pořádku, oni si to mezi sebou poví, ale někomu cizímu, to přeci neřeknou. Další z legračních situací popisoval jiný speaker. Proškolili indickou firmu na Scrum, vše se zdálo být v pohodě, ale jen do té chvíle, než představili nové role. A kdy nový Scrum Master říká že se mu Scrum líbí, že mu rozumí, ale jestli si může dál říkat project manager, že by tím že je teď jen Scrum Master utrpěl jeho status a jak by pak před kolegy a rodinou doma vypadal…

Jak tedy chcete v tomto kastovním systému zavádět agilní metody založené na týmové spolupráci, zapojení zákazníka a transparentní komunikaci? Jak chcete dosáhnout self-organized týmu? Těžko. Někdo to na konferenci pěkně shrnul na twitteru: “Outsorcing v Indii je levná možnost jak nechat zkrachovat svůj produkt”. A asi s ním musím souhlasit. Ostatně většina firem už na to přišla také a tak Indii svěřuje v podstatě dva typy projektů. Výběhový SW, který sice musí udržovat, ale nejradši by se ho zbavili, a testování. Ostatně spousta firem netestuje vůbec, tak proč to nedat levně do Indie. I to má však jeden háček. Tím prvním můžete současné klienty odradit a přijít tak o více peněz, než by se z ceny outsourcingu původně zdálo. A co se kvality týče, jak chcete nechat testovat produkt lidem, kteří žijí v souvislém smetišti. Tester musí být precizní, vidět i drobné nesrovnalosti… A to lidé v Indii obvykle nevidí. Prostředí deformuje. Ostatně i mě po třech týdnech v Indii přišlo, že je tam uklizeno víc, než když jsme přijela… Na všechno si člověk zvykne.

Asi nejlepší byla přednáška o distribuovaných týmech kde Alexey Krivitsky pěkně popisoval jak se s takovým prostředím vypořádat. Doufám, že se nám podaří ho nalákat na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Motivace

Jak efektivně motivovat zaměstnance? Je to jedna z nejčastějších otázek které dostávám hned po tom jak implementovat Scrum. Dobrý Scrum Master by měl umět tým motivovat. Být dobrým koučem. Takže jak na to? Určitě nepotřebujete žádný budget. To že peníze nejsou motivačním faktorem ale demotivačním – tedy ať přidáváte jakkoli, radost z vyšší mzdy či prémie vydrží tak týden. Pak zajdete na večeři, jedete na dovolenou a zas je to všechno jako dřív. Čím více dostanete, tím dříve si přijdete pro další. Ale dostáváte-li méně, než byste vzhledem k tomu co děláte měli, nebo než nutně potřebujete, za poměrně krátkou chvíli jste silně demotivováni. Takže řekněme, že plat je fér. Co ty nejlepší lidi vlastně v týmu drží a neodejdou ani za lepší plat jinam? Obava ze změny? Možná. Ale to nestačí. Dobrý kolektiv, smysluplná práce, pocit že to co děláte je potřeba, a že to má význam. A že to děláte dobře.

Tohle všechno samozřejmě není primární starostí Scrum Mastera. Má kolem sebe pár pomocníků.
Začněme tím co je starostí Product Ownera. Dodávat vaší práci smysl. Product Owner je vlastníkem produktu, potažmo product backlogu a ten musí tým nadchnout, aby ve svém počínání viděl smysl. Customer demo vám v tom jistě pomůže. Pochvala od zákazníka nikdy není k zahození. Pocit, že to co píšete někoho opravdu zajímá. A že to potřebuje. Takže by se dalo říct že Scrum proces vám s motivací také výrazně pomůže. Jestli tahle složka motivace nefunguje, jako Scrum Master to budete nejdříve muset spravit. Jinak práce bude těžko někoho bavit a těžko z kohokoli v týmu dostanete nějaké větší nasazení. Naopak uslyšíte samé výmluvy na okolí.

Takže produktu rozumíme, dává nám smysl, práce tým baví. Co zbývá? Scrum Master pomáhá odstraňovat překážky, tu šílenou práci co vás dřív obtěžovala… Občas pomůže moderovat diskusi, řeší problémy. To ale není vše. Měl by i lidi rozvíjet…

A tady začíná problém. Ve Scrumu by se dalo často říct, že tým je tak dobrý jak dobrého má Scrum Mastera. Scrum Master musí být v jistém smyslu i dobrý manager. Takový, co jednotlivým lidem v týmu věří, že dokáží být výjimeční a pomáhá jim stanovovat si takové cíle, aby byly náročné ale splnitelné. Aby tým pracoval nejlépe, jak umí. Špatný Scrum Master si jen stěžuje, že jednotliví členové nemají potřebné skilly, a že by se to museli učit. A na to že není čas. Dobrý Scrum Master ví, že tým to dokáže. Z hloubi duše jim věří a tým to někde uvnitř pozná. Aniž by taková informace byla kdy vyřčena nahlas. Jen tým pracující pod takovým Scrum Masterem může být ve skutečnosti úspěšný.

Na závěr doporučím jeden článek. Není sice o Scrumu, ale myslím, že dobrý Scrum Master musí vytvářet takový “pygmalion”.

Několik důvodů proč rozdělit User Story

Důvodů proč rozdělit UserStory může být hned několik.
Ten nejčastější je, že je moc velká a nevejde se do Sprintu. A protože základem Scrum procesu je pravidlo že tým vybere co během Sprintu dokončí a to na konci prezentuje zákazníkovi na customer demu, takovým UserStory které by dokončit nešly se musíme vyvarovat. Jak UserStory dělit? Po menších funkcionalitách. Nikdo neříká že takto rozdělěnou UserStory si zákazník musí nutně chtít koupit, ale jen že mu musí přinášet hodnotu. A ta je třeba i v tom, že si představí, co vlastně od dané funkčnosti chce. Tedy např. pakliže chce fakturace, asi si nekoupí jen readonly seznam faktur, ale bude je chtít i vytvářet a tisknout a filtrovat… ale jako mezivýsledek po prvním Sprintu mu hodnotu přinese i jen obyčejný seznam.

Druhým důvodem je různá priorita jednotlivých funkčních celků. Ono je to jedno spojeno s druhým. Když je UserStory moc velká, tak se obvykle Product Owner ptá, co jí dělá tak náročnou a komplexní. A přijde se obvykle na to, že udělat seznam faktur je snadné, ale tým ještě nikdy nedělal print preview a daná komponenta ho neumí a tedy je to pro ně náročné. Ono ale obvykle ne všechno je nutné a ne všechno stojí za tu cenu, kterou to má. A může se stát, že možnost print preview pro zákazníka vlastně nemá takovou priorotu a že ji odloží, na čas, či úplně.

Scrum vám umožňuje funkcionalitu řídit. Tím že složité celky musíte rozpadnout na menší kusy aby je tým stihnul v rámci Sprintu vás nutí přemýšlet o tom, jestli opravdu všechny drobné funkcionality potřebujete a jestli estimate odpovídá ceně, kterou jsme ochotni za očekávanou business value dané funkcionality v UserStory zaplatit.

Kdo píše User Story? A kdo tasky?

A jako pokračování v mém miniseriálu o agilních metodách, Scrum procesu a konkrétně User Stories je odpověď na otázku kdo píše User Story?

Tak jako obvykle, navrhnout User Story může kdokoliv. Libovolný člen týmu, vývojář, tester. Nicméně Scrum zavádí roli Product Ownera, který je za celý backlog a User Story v něm zodpovědný. A proto je Product Owner ten, kdo User Story nakonec do backlogu akceptuje, a přiřadí jí v závislosti na business value prioritu. Product Owner je tedy ve Scrumu často ten, co User Story definuje, následně je ale diskutuje jak s produktovým týmem tak se Scrum týmem který jednotlivé User Story ohodnocuje.

A kdy se mají jednotlivé User Story rozdělit na tasky/úlohy? Idealně během planningu, maximálně první den Sprintu. Když to uděláte později či vůbec, riskujete, že většina členů týmu nebude vědět, z čeho se jednotlivé User Story sestávají, co nám jako týmu ještě chybí dokončit a jak jsme daleko.

Co je task? Task neboli úloha je nějaká jednotlivost, která se musí udělat, aby User Story přinášela očekávanou hodnotu. Tedy pro User Story “jako manažer, chci mít evidenci zaměstnanců, abych měl rychlý přehled o všech lidech ve firmě i detailu konkrétních pracovníků.” to může být např. založení tabulky a číselníků, zobrazení dat z db na obrazovku v browsu, filtrace, zobrazení jedné detailní položky zaměstnance, grafický design obrazovek, test. Každá úloha by neměla být delší, než řekněme dva dny a kratší než půl den už je možná zbytečný detail, nicméně může mít smysl si i takovou úlohu zaznamenat, abychom na ni nezapomněli. V průměru by každá úloha měla být tak asi na den práce, což nám pak usnadňuje denní standup meeting, kde je pak snazší definovat, co opravdu dokončíme.

Na začátku jsme psala, že za User Story je zodpovědný Product Owner, potom za rozpad těchto User Story na tasky / úlohy je naopak zodpovědný tým a jsou tu jen pro interní potřeby týmu. Aby všichni věděli jak daleko ještě jsou od cíle a to i bez složitého ohodnocování jednotlivých úloh a kreslení Sprint Burndownu. Vše je pak na první pohled vidět z tabule – Scrum Boardu.

Super User Story, User Story a Epics

Jak už jsem psala v minulém příspěvku, User Story musí vytvářet obrázek, být nezávislá, popsatelná, přinášet hodnotu, ohodnotitelná, malá a testovatelná – tedy v originále: Independent, Negotiable, Valuable, Estimatable, Small, Testable requirement (zkráceně “INVEST”). Tedy něco, do čeho chcete investovat úsilí a potažmo peníze. Po té co se pokusíte User Story takto definovat, často zjistíte, že potřebujete ještě něco co je širší, co vám drží globální kontext a jednotlivé User Story pohromadě.

K dispozici jsou dva koncepty. První se na User Story dívá jako na entitu, která jde v podstatě donekonečna škálovat a zavádí tak pojem Super User Story – např. Jedu na výlet do Evropy – nebo jen do Německa – nebo jen do Berlína – nebo chci navštívit Berlínské Egyptské museum. Je to takový strom vnořených User Story. Samozřejmě že když to takto rozdrobíme, budou se nám jednotlivé User Story (listy toho stromu) samostatně jen velice špatně prodávat jako super zájezd. Ale na druhou stranu, asi si umíte představit zájezd jen s památkami bez jídla a zájezd all inclusive. A s vaším produktem je to podobné. Také obvykle existuje funkcionalita, kterou můžete oželet a která vlastně není tak prioritní.

Druhý koncept zavádí pojem Epics, kde Epics je něco co jednotlivé User Story zastřešuje – tedy taková souhrnná Super User Story. Epics se ovšem již nepíše ve formátu ‘jako uživatel, chci funkcionalitu, abych dostal business value‘, ale zároveň se jako takový nedá naplánovat do sprintu a ani nechat reálně týmem ohodnotit. Na to je v něm skrytá moc velká dávka nejistoty.

Obě varianty jsou v podstatě podobné, a pomáhají vám udělat si představu o backlogu, ujasnit si co má jakou prioritu a kde je jaká přidaná hodnota.

Proč píšeme User Story?

Proč v agilních a Scrum týmech píšeme User Story a proč nestačí jen tasky s popisem co se má udělat? K čemu je, že se držíme formátu „Jako Uživatel, chci Funkcionalitu abych dostal Business Value“? Není to zbytečné pořád dokola opakovat slovíčka ‘Jako’, ‘chci’ a ‘abych’? Může se to tak zdát. Pojďme se na to ale podívat od začátku.

User Story vám říká nejen, co chcete dělat, ale i pro koho a hlavně proč. User Story má vytvářet obrázek, popisuje příběh. Lidský mozek vnímá obrázky a příběhy daleko snadněji než technický popis v bodech. Zkuste si teď porovnat jeden příklad z praxe:

1. US: „Kontaktní formulář“ (jaký jste si představili?)
2. US: „Jako administrátor chci kontaktní formulář, abych se včas dozvěděl o chybách systému“.

Jsem si téměř jistá, že když jste to četli, šlo o dvě různé věci. Myslíte si, že je to z kontextu firmy a produktu jasné? Ne vždy. Většinou je to jasné pouze Product Ownerům, ti mají v hlavách obrázky, jak přesně se má systém chovat a jak má vypadat. Ti jsou součástí příběhu zákazníka, ale v User Stories jde o to, aby ten obrázek, co mají v hlavě, sdělili ostatním tak, aby ho ani oni nikdy nezapomněli. A aby se i oni stali jeho součástí.

User Story by měla být jednoznačně popsatelná, vytvářet obrázek, nezávislá, přinášet hodnotu, a také malá. Je-li User Story příliš velká je většinou těžké říct co je jejím obsahem a co už ne, a je tak pro tým neuchopitelná. A jak se pozná, že je User Story hotová? Od toho jsou tu akceptační kritéria.

User Story můžete samozřejmě dělit na menší User Story, pořád ale musí přinášet nějakou hodnotu. Nejsou to technologické aspekty problému. Díváme se na ní z pohledu businessu, z pohledu uživatelů. Techlologie přichází na řadu až při rozpadu User Stories na jednotlivé tásky.

A na závěr tu mám pár příkladů pro elektronickou půjčovnu domácích zvířat:

Jako rodič si chci půjčit zvíře aby moje děti věděli, jaké to je se o nějaké zvíře starat, než si ho koupíme.

Jako rodič si chci přečíst maximum informací o bezpečnosti a vhodnosti jednotlivých zvířat abych si mohl vybrat vhodné zvíře pro své dítě.

Jako příbuzný chci mít možnost koupit upomínkový předmět s fotkou půjčeného zvířete, abych měl pro děti dárek.

Jako dítě si chci vybrat z obrázků, které zvíře si půjčíme, aby se mi líbilo.

Jako dítě chci mít přístup k deníku svého zvířere, abych věděl co se s ním stalo když jsme ho vrátili.
A tak dál…

Jednotlivé User Stories mají různou hodnotu, různou náročnost. Ne všechny jsou kritické pro produkt, ne všechny se vyplatí implementovat. Ale o tom zase příště. Děkuji Daniele a Vojtovi za příklad 🙂

Pozvánka na konferenci Agile Prague 2011

Jak asi jako čtenáři tohoto blogu víte, pořádám v září konferenci zaměřenou na agilní metody. A protože jsem přes víkend napsala takovou pěknou pozvánku, přišlo mi škoda se o ni s vámi nepodělit. 🙂

Konference Agile Prague 2011

První mezinárodní konference zaměřená na agilní metody řízení proběhne ve dnech 29. – 30. září v Praze v konferenčním centru CITY na Pankráci. Přijďte se dozvědět něco nového. Buďte s námi agilní.

Co si představíte pod slovem 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 sebe i svoje procesy… Je to pro vás něco nového? Nebo se již staly agilní metody nedílnou součástí nejen vašich projektů, ale i života? Ať již odpovíte na tuto otázku jakkoliv, konference Agile Prague je událostí, kterou byste rozhodně neměli minout.

Konference proběhne ve dvou dnech a dvou paralelně běžících sekcích, během nichž se vám představí 28 přednášejících z různých koutů světa, kteří se s vámi podělí o své zkušenosti s agilními metodami, Scrum Procesem, Extrémním programováním či Kanbanem.

Přemýšlíte, pro koho je konference vhodná? Pro vývojáře, testery, team leadery, managery, ředitele, majitele firem. Pro všechny, kteří se chtějí dozvědět něco nového. Pro všechny, kteří chtějí být efektivnější, flexibilnější, mít spokojené zákazníky, a v neposlední řadě chtějí, aby práce byla i zábava.

Začínáte? Říkáte si, co to vlastně ty agilní metody jsou, a jestli by vám to nemohlo něco přinést u vás ve firmě? Přijďte si poslechnout zkušenosti z firem, které v posledním roce na agilní metody přešly. V praktických case-studies se s vámi podělí o své zkušenosti. Co očekávali, co se jim povedlo, ale i co bylo těžší, než si mysleli, či co se jim stále nedaří. Zajímá vás, proč firma LMC začala se Scrum procesem a jak se změnili jako celá firma? Proč se rozhodli být agilní? Ondřej Mysliveček se s Vámi podělí o své zkušenosti z této změny. Nebo chcete vědět, jak se mění velká korporace jako T-Mobile, a co je k takové změně vedlo? Jindřich Otčenášek má s touto změnou čerstvé zkušenosti.

Jste součástí agilního týmu? Popovídejte si s J. B. Rainsbergerem (Canada) a určitě nevynechte jeho key-note přednášku, kterou uvádí slovy: “Každý měsíc se mě někdo ptá, jak přesvědčím svého managera, aby mi dovolili refactoring”. Pokračovat můžete přednáškou představující praktický úvod do Kanbanu, který uvede Joakim Sundén (Švédsko), poslechnout si, jak naložit s agilními metodami v oblasti UX, kde se o zkušenosti z Keria podělí Petr Douša, či se jít podívat na přednášku Tomáše Perglera jak se Scrumem naložili v Seznam.cz, nebo Pavla Teichmana na jeho zkušenosti z Pojišťovny DIRECT.

Pracujete pro státní instituce a nevíte jak, a jestli vůbec je možné agilní metody použít? Využijte jedinečnou možnost si poslechnout, jak s prostředím Evropské Komise, která si s ničím nezadá s českými státními institucemi, naložil Andrej Zachar (Simpleway) a Sjerk Van Riel z Belgie, nebo jak Pat Guariglia z USA nasadil Agile a Scrum do New York State Government Agency.

Jste Scrum Master nebo Product Owner? Nevynechte možnost poslechnout si zkušenosti jiných Scrum Masterů a Product Ownerů. Poslechněte si, proč Alan Bustamante považuje Agile jako “nejlepší způsob jak získat ze softwarových projektů nejvyšší hodnotu“, nebo si zahrajte na Scrum a postavte si s Thorstenem Kalninem letiště z Lega.

Vedete více týmů? Chtěli byste, aby byly efektivnější a motivovanější? Přijďte si poslechnout přednášku, kde Ola Ellnestam (Švédsko) bude mluvit o tom, co to znamená být agilní, Andrea Provaglio (Itálie) vysvětlí jak docílit samoorganizujícího (self-organized) se týmu a Chris Matts (Velká Británie) se zaměří na business analýzu v agilních týmech. Nakonec vám Alan Brown (Španělsko) z IBM poradí jak odolat tlaku na dokončení všeho ještě rychleji a levněji než doposud.

Vlastníte nebo řídíte firmu? Vidíte, jak se svět zrychluje, je dynamičtější a klade na Vás čím dál tím vyšší nároky? Máte strach, že neudržíte krok s konkurencí? Přijďte se podívat, co vám agilní metody mohou přinést, jak agilní metody komunikovat, jak je nasadit. Začít můžete hned na naší první key-note přednášce – Christopher Avery (USA) – Your Agile Leadership Gift. Určitě budete souhlasit, že komunikace je čím dál tím důležitější. A to jak v rámci týmu, tak i externě se zákazníkem, businessem či managery. Jak v praxi komunikovat si vyzkoušíte na interaktivní přednášce Zuzany Šochové a Eduarda Kunce.

Jste Agilní? A jen se chcete posunout trochu dál? Něco se dozvědět? Máte pocit, že Vám možná něco uteklo, nebo že potřebujete pár nových nápadů? Zapojte se do open-space diskuse, podělte se s námi o krátký lightning talk, nebo volně diskutujte s přednášejícími i účastníky v příjemných prostorách konferenčního centra na Pankráci.

Jsme rádi, že v rámci aktivit Agilní Asociace spolu s partnery můžeme agilní komunitě v Čechách přinést akci světového formátu. Akci, která pomůže širokému spektru firem být úspěšnější, akci, na kterou se budete těšit zase příští rok.

Těšíme se na setkání s Vámi.

Tým Agile Prague Conference

http://agileprague.com

Co zabilo Vodopád, může zabít i Agile

Nedávno jsem narazila na zajímavý článek od Roberta C. Martina – What Killed Waterfall could Kill Agile.

Dobře napsaný článek pojednává o tom, co se stane, když ve svém procesu a kultuře oddělíme pravomoc a zodpovědnost a umožníme vzniknout tzv. elitám, které sice rozhodují, ale zodpovědnost za neúspěch hází na jiné. A to se přesně stalo ve Waterfallu. A překvapivě, přesně stejný model se dere na světlo světa i v současném Scrum procesu: Role Scrum Mastera se najednou považuje za tak důležitou, že vyžaduje získání certifikátu. Jestliže váš Scrum tým nemá Certifikovaného Scrum Mastera, pak s vámi musí být něco špatně. Ale když Scrum tým má úspěch, pak je to CSM, kdo vykročí a obdrží ocenění (samozřejmě za tým). Ale co se stane, když Scrum tým neuspěje? Je to CSM, kdo přijme odpovědnost? Vraťte se zpět ke kořenům agilních metod a Scrum procesu a zjistíte že Scrum Master je kouč a neřídí projekt. Opravdoví kouči nejsou projektovými manažery ani vedoucími týmů. Role kouče je připomínat týmu dodržování procesu, a připomínat všem jejich přijatý závazek.

Na to abyste byli agilní, úspěšně nasadili Scrum proces, XP, nebo Kanban ve vaší firmě, nepotřebujete žádné certifikace. Je to škoda peněz. Agilní komunita disponuje zkušenými kvalitními kouči a trenéry, kteří vám za poloviční a nižší ceny proškolí tým přinejmenším stejně dobře jako drazí certifikovaní trenéři. Tím spíš že pro získání CSM / CSPO nemusíte prokázat žádné znalosti ani zkušenosti (srovnejte si to s PMBOK, ITIL, apod.), jde jen o inkasování vysoké částky za kus papíru. Ano, a dobrý kurz k tomu…. Ale ten jde přeci ve stejné kvalitě sehnat i za menší náklady.

Bez ohledu na to co si myslíte o Scrum certifikacích, myslím, že článek stojí za přečtení, s milým svolením autora vám přináším jeho překlad 🙂

Co zabilo Vodopád, může zabít i Agile.

Robert C. Martin

20. listopadu 2010

V roce 1970 napsal softwarový inženýr Dr. Winston W. Royce svůj klíčový článek nazvaný Řízení vývoje velkých softwarových systémů. Tento článek popisoval softwarový proces, o kterém si Royce myslel, že je vhodný pro rozsáhlé systémy. Jako vývojář v leteckém průmyslu byl k tomu velice kvalifikovaný.

Článek začínal vytvořením „slaměného panáka“ (anglicky straw-man, což je metoda podsunutého argumentu tzv. logického klamu – pozn. překl.). Popsal tento jednoduchý naivní proces a prohlásil ho za „grandiózní“. Zobrazil ho jednoduchým diagramem na úvodních stránkách svého článku. Potom tento „grandiózní“ proces metodicky rozcupoval. Nakonec Royce navrhl mnohem propracovanější a hluboce promyšlený přístup, zatímco se čtenář chichotal nad hloupostí „grandiózního“ modelu.

Royceův článek se stal okamžitě hitem. Byl citován v mnoha dalších článcích včetně několika velmi důležitých procesních dokumentů na začátku sedmdesátých let minulého století. Jeden z nejvlivnějších byl DOD2167, dokument, který popisoval procesy vývoje softwaru pro americké ministerstvo obrany. Royceovi se nadšeně aplaudovalo a začalo se mu říkat otec DOD procesu.

Byl v tom ale jeden háček. Proces, který DOD2167 používal, byl Royceův „slaměný panák“! Zdá se, že autoři DOD2167 vůbec nedočetli Royceův článek, protože použili ten „grandiózní“ naivní proces, kterému se Royceův článek tak vysmíval. Ke své velké zlosti se Dr. Winston W. Royce proslavil jako otec metody Vodopádu.

Ačkoliv Royce láteřil a bojoval proti tomu, lavina už byla spuštěná. Sněhová koule se stále se zvětšovala, jak se valila po horách softwarových společností a průmyslových zemí. Rok za rokem vodopád získával na popularitě a jeho otci nezbývalo nic jiného než žasnout nad spravedlností vesmíru a pochybovat o tom, zda je na Zemi inteligentní život.

V polovině devadesátých let ovládl vodopád svět softwaru. Odvětví softwarového inženýrství jím bylo definováno stejně jako dokumentace analýz a návrhů, která se očekávala od Architektů, Návrhářů a Analytiků. Programování byl pouhý detail – nejméně důležitá část procesu. Pokud jste napsali svou dokumentaci dobře, a nakreslili jste všechny potřebné diagramy, pak jste jednali správně. Byli jste inženýři. Programování mohlo být ponecháno těm nemytým přisluhovačům ve sklepě.

Tento přístup vytvářel rozkol v technické komunitě. Byli zde elitní Architekti, Návrháři a Systémoví analytici, kteří prováděli opravdové inženýrství tím, že uspokojovali první dvě fáze vodopádu. A pak tu byli ti bručouni, kteří ve skutečnosti museli zajistit, aby nakonec vše fungovalo. Když měl projekt skluz, byli to bručouni, kteří pracovali přesčas. Když se projekt nepovedl, byli to bručouni, kteří za to mohli.

Tohle bylo úžasné pro elitní Architekty, Návrháře a Analytiky! Kdo by nechtěl takové místo? Máte oprávnění všechno určovat a žádnou zodpovědnost za to, že to bude doopravdy fungovat. Můžete mít vysoké platy, respekt svých kolegů a závist ostatních. A skoro nijak nemůžete chybit. Když se něco špatného stane, vždycky to můžete svést na programátory.

Ano, tohle je trochu přehnané, ale jenom o maličko. Postoje elitářství byly velice opravdové. Ti, kteří uměli analyzovat a navrhovat, byli považováni za příliš cenné, aby se věnovali pouhému programování. Programování se stalo sirotkem Softwarového inženýrství.

V roce 1998 se ve stavbě vodopádu začaly objevovat trhliny. Programátoři ze všech stran začali odmítat elitářství Architektů, Analytiků a Návrhářů. Začali si stěžovat na neohebnost a váhu vodopádového pláště, který museli nosit. Beedle, Devos, Schwaber a Sutherland publikovali své klíčové články o Scrumu a Kent Beck vytvořil hnutí kolem eXtreme Programming (XP).

Scrum roztrhal vodopád na cáry. Než aby se trávily měsíce či roky vytvářením stohů dokumentace v postupných fázích, Scrum navrhl, aby tým vývojářů pracoval v krátkých třicetidenních [1] cyklech na implementaci hlavních činností programu. Scrum navrhl, že vývojové týmy by se měly dohodnout kdy a zda vůbec nějaký dokument je zapotřebí. Scrum odstranil důraz na dokumenty a artefakty a přesunul ho rovnou na fungování programu a na rozhodovací sílu týmu. Scrum rozbil monopol na rozhodování držený elitami a vložil ho do rukou vývojového týmu.

XP to dovedl ještě dále tím, že zdůraznil samotný akt programování a že prohlásil, že důležitý je programový kód. XP je integrací Scrumu se sadou inženýrských disciplin. Tyto inženýrské discipliny mají obrovský účinek!

Scrum je proces, který probíhá na denní bázi. Poskytuje rámec, který popisuje, jak bude váš den vypadat, ale neříká nic o tom, jak byste měli pracovat v jednotlivých hodinách a minutách toho dne. XP je proces, který probíhá na minutové bázi. Inženýrské discipliny procesu XP vyplní váš den. XP poskytuje vodítko pro vytváření každé jednotlivé řádky programového kódu. Poskytuje rámec, v jehož působnosti lze dělat programátorská a návrhářská rozhodnutí.

Scrum je subjektivní proces: vládne tým. Není tu žádné objektivní měřítko úspěchu nebo kvality, či dokonce ukončení procesu. Záleží na týmu, aby definoval tyto věci. Inženýrské disciplíny XP přidávají Scrumu některá objektivní měřítka. XP definuje návrh a kvalitu programového kódu, a poskytuje návod, jak toho dosáhnout. XP definuje význam slova hotovo, a jak lze měřit, co se udělalo.

V roce 2001 softwarová komunita bzučela revolučními myšlenkami. Byl napsán dokument Agile Manifesto, který se stal ústředním bodem tohoto energického, nadšeného a rostoucího hnutí. Samotná definice Softwarového inženýrství byla podrobena kritice, a tato kritika byla úspěšná.

Elitářství zplozené Vodopádem bylo napadeno. Ani Scrum, ani XP neměli žádnou roli pro elitáře, kteří si osobovali pravomoc bez toho, aby převzali zodpovědnost. Ve Scrumu je vláda týmu silnější než vláda Architekta a Návrháře. Přispění se vítá, ale ne vždy se nutně přijme.

XP to dotáhlo ještě dále. Jestliže chcete přispět do XP týmu, jste vítán. Ale za svůj příspěvek nesete explicitní zodpovědnost. Pro Architekty a Návrháře to znamenalo napsat nějaký programový kód. Pro Analytiky to znamenalo napsat testy. Každý z týmu měl zodpovědnost za to, aby věci fungovaly.

Chvíli to vypadalo, jako že elitářství Softwarového Inženýrství umírá, že pravomoc a zodpovědnost byly spolu svázány už navždy. Ale elitářství je těžké zabít. Kdykoliv oloupíš Petra, abys zaplatil Pavlovi, můžeš si být jist, že Pavlovo rozhořčení bude menší než Petrovo.

Jak XP, tak Scrum definovali roli kouče. Jeho odpovědností je hájení procesu. Kouč připomíná všem jejich přijatý závazek vůči disciplině a vůči procesu. Když hrozí termíny, a zákazníci se zlobí, je to kouč, který připomíná týmu, že nejlepší cestou, jak splnit termín a uklidnit manažery je dodržování discipliny. Ve Scrumu se tato role nazývá „Scrum Master“.

XP definovalo roli kouče zcela neformálně. Role se bude stěhovat mezi jednotlivými členy týmu. Jeden měsíc to bude Pepa, příští třeba Jana. Není to funkce a neplynou z ní žádné pravomoci. Žádná rozhodnutí se nedělají a žádné donucování není dovoleno. Kouč má pravomoc připomenout, nikoliv nařizovat.

Ve Scrumu se však přihodilo něco odlišného …

Úplně první kurz pro Certifikované Scrum Master se vyučoval ve Vernon Hills, Illinois. Ken Schwaber mě zavolal a požádal mne, jestli nemám učebnu, kterou by mohl použít. Řekl jsem mu, že budu nesmírně potěšen tím, že mohu být hostitelem jeho kurzu. On laskavě dovolil řadě lidí, kteří pro mne v té době pracovali, aby se zdarma účastnili a stali se CSM.

Upřímně řečeno, myslel jsem si, že ta myšlenka je poněkud pošetilá. Nemyslel jsem si, že by tisíce lidí stálo ve frontě, aby dostali svůj certifikát. Podcenil jsem však vábidlo elitářství. Nenapadlo mne, že tento speciální tréninkový kurz doplněný termínem Certifikovaný Scrum Master se stane klínem vraženým do spojení mezi pravomocí a odpovědností.

Kdo byli ti, kteří stáli ve frontě na svůj CSM kurz? Byli to členové Scrum týmů, kteří chtěli pomoci svému týmu? Byli to programátoři a testeři? Ano, jistě byli někteří CSM, kteří pocházeli z existujících týmů. Ale převážná většina CSM má za sebou řízení projektů. V podstatě připojili CSM ke svému PMBOK (Project Management Body of Knowledge, mezinárodně uznávaný titul projektového manažera – pozn. překl.).

Tohle nebylo nikdy záměrem. Role kouče byla mírně připomínat proces a disciplinu. Kouč nikdy neměl řídit projekt nebo plánovat! Ve skutečnosti tyto dvě role by měly být v protikladu! Role projektového manažera je připomínat týmu termín a snažit se je přimět k takovým změnám, aby termín mohl být splněn. Role kouče je připomínat týmu dodržování procesu.

Opravdoví XP kouči nejsou projektovými manažery ani vedoucími týmů. Nevedou tým k úspěchu, a nemohou si přičíst zásluhy za případný úspěch. Ve skutečnosti je jejich role považována za doplňkovou, protože zralé týmy pravděpodobně nebudou potřebovat časté připomínání. Ale CSM často přejímají roli vedoucího týmu. Je na ně nahlíženo jako na kritickou komponentu týmu, bez které by tým nemohl pracovat. V XP toho tým bez kouče moc nedosáhne, ale Scrum tým bez Scrum Mastera je oxymóron (protimluv – pozn. překl.).

Ano, role Scrum Mastera se považuje za tak důležitou, že vyžaduje získání certifikátu. Jestliže váš Scrum tým nemá Certifikovaného Scrum Mastera, pak s vámi musí být něco špatně.

Když Scrum tým má úspěch, pak je to CSM, kdo vykročí a obdrží ocenění (samozřejmě za tým). Ale co se stane, když Scrum tým neuspěje? Je to CSM, kdo vykročí a probodne se svým mečem? Přijme CSM rány biče a bude chránit svůj tým?

Elitářství je tu zpět, a stále roste. Je k dispozici stále více kurzů s certifikáty, a uvažuje se dokonce i o dalších vizích. Jiné školící společnosti nabízejí své vlastní certifikace. Konec konců, vábnička elitářství vydělává veliké peníze. Sněhová koule se valí dolů po svahu a stává se větší a větší s každou otočkou.

A když přijde revoluce …?

Doufám jen, že až Scrum půjde ke dnu, nevezme s sebou celé hnutí Agile.

[1] V současné době jsou běžnější dva týdny místo 30 dní. Scrumové a XP týmy zjistily, že za měsíc se toho může hodně zkazit.

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

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.