zuzi | Zuzi's Blog o Agilu a Scrumu

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 🙂

Jak uspořádat konferenci

Někdy před třemi lety jsem dostala nápad, že psát blog o agilních metodách nestačí a že by to chtělo uspořádat konferenci. A přivést ty všechny zajímavé lidi, které jsem na různých konferencích slyšela, do České Republiky a uspořádat podobnou akci v Praze. Trvalo mi to déle než jsem čekala, ale myslím že, to bylo ku prospěchy věci. A hned v začátku musím říct, že konference se povedla, a předčila mé očekávání.

S kým pořádat konferenci?

S lidmi co mají nejen stejný cil /propagovat agilní metody/ ale i se mi s nimi dobře spolupracuje. Je to hodně práce, hodně času, který do toho budete muset dát. Řádově víc, než jsem si kdy uměla představit. A takový čas musíte trávit s lidmi, se kterými je vám dobře, kteří mají stejný přístup k životu, stejné hodnoty. Kteří vás podpoří a pomůžou vám z toho udělat lepší akci, než byste dokázali sami.
To se mi hned napodruhé podařilo najít a konference mohla vzniknout, takže oběma svým společníkům tímto děkuji. 🙂

Program

Konference je o programu, takže ty tři roky byly ku prospěchu, hlavně co se týče speakerů. Většinu lidí jsem znala osobně a slyšela je mluvit, na zbytek jsme dostali doporučení. Zajímavé bylo, že stačí pár dobrých jmen a ostatní se přihlásí sami.

Kdybych to měla zhodnotit, myslím, že výběr byl v pořádku. Někteří speakeři byli hodnoceni dobře nebo neutrálně, někteří naopak rozdělovali publikum na nadšené zastánce, kteří přednášku hodnotili jako nejlepší a extrémně přínosnou, tak i na odpůrce kterým nic nedala a byla pro ně ztrátou času. Důvody pro to byly různé – ať už korporát vs. menší firmy, nebo úroveň znalosti a zkušenosti – a to buď prílišné ‘omílání známých pravd’ či nepochopení advanced taku těmi co začínají.

Jednu věc bylo nutné si uvědomit hned v začátku. Nepořádám akci pro sebe, ale pro hodně různorodou skupinu lidí. Vývojáře, testery, analytiky a architekty. Managery a diectory. Scrum mastery a product ownery. Lidi co se agilním metodám věnují několik let a scrum či kanban zaváděli v mnoha týmech. Pro týmy co právě začínají, ale i pro lidi co o agilních metodách ještě neslyšeli. A teď jak má vypadat program? Hlavně různorodě. A to se myslím povedlo.

Prostor

Tak tady je asi místo pro zlepšení. Bylo dobře, že byl prostor relativně kompaktní. Že to nebylo roztahané a lidi nebloudili nekonečnými chodbami. Ale až budu hledat místo příště, chtěla bych, aby hlavní prostor šel rozdělit v průběhu na dvě stejně velké části. Takhle byl jeden prostor kromě keynotes pocitově prázdný a ten malý často praskal ve švech.

Catering

Ukázalo se, že spousta účastníků hodnotila konferenci podle kvality cateringu 🙂 a v tom nás Troja catering nezklamal. Jídla bylo dost, chutnalo účastníkům i mě, příjemná obsluha, takže je ráda komukoli doporučím a doufám, že se domluvíme zase příští rok.

Lidi

Líbilo se mi, že všichni měli visačky napsané z obou stran, a že jméno účastníků bylo větším písmem než příjmení a firma. Naopak se mi nelíbilo, že to v tiskárně špatně ořízli. A taky musíme do příště vyřešit co se změnami a přihláškami na poslední chvíli.
Chtěli jsme, aby se účastníci mohli volně dávat do řeči s lidmi, které neznají, sdíleli si svoje zkušenosti a zážitky, radili si navzájem. Částečně to zafungovalo, ale příští rok to musíme posílit. Nicméně openspace prostor fungoval.
Jedno z dobrých doporučení bylo udělat s každým speakerem plánovanou openspace diskusi po jeho přednášce, protože ne vždy se dostalo na všechny a ne všichni se odvážili oslovit speakery v prostoru konference venue.

Legrace

I u takovéto akce musíte hlavně bavit. My si vymysleli originální design ZEP´s agilního hrnku, který je obalen černou tabulí na kterou můžete psát křídou, a ten jsme občas odložili v prostorách konference a čekali, až si jej najdou zájemci. Několika z vás jsme na hrnek napsali vzkaz křídou. Ostatní vzkazy jsou již na vás. 🙂

Cíl

A ještě co jsem si od toho slibovala? Že taková akce přivede k agilním metodám lidi, co by na běžné opencafé které pravidelně pořádáme nepřišli, lidi co o agilních metodách do té doby nic moc nevěděli, pomůže těm, co s nimi začínají si ověřit, že jsou na správné cestě a že problémy, jimž čelí se stávají i ostatním, anebo pomůže rozšířit obzory těm, co už se v agilním světě dlouho pohybují a dodá jim dostatek nových podnětů jak dál. A to se myslím ve všech třech aspektech povedlo.

Čekali jsme 100-200 lidí. Na začátku jsme si říkali, že jestli přijde 100, bude to úspěch. A byl to opravdu pěkný pocit, vidět všechny ty, co přišli na zahájení, mít plný sál pro 200 účastníků. Konferenci podpořilo hodně firem, děkujeme, bez vaší podpory bychom to nedokázali. A trochu statistiky na závěr, celkově se na konferenci registrovalo 206 účastníků. 10% bylo ze zahraničí. Děkujeme, že jste přišli a doufáme, že se vám akce líbila.

Máte-li jakékoli náměty na zlepšení, napište mi je do komentářů.

A protože akce byla úspěšná, těšíme se na vás zase příští rok. Agile Prague 2012 bude v Praze, na přelomu září a října 2012.

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.

Překlad Agilního Manifestu

Jednou z mých aktivit z poslední doby byla i spoupráce na oficiálním překladu Agilního Manifestu (po dokončení a schválení bude dostupný na stránkách www.agilemanifesto.org). Překlad již prošel diskuzí a review v užší skupině a je tedy nejvyšší čas podělit se s ním s českou agilní komunitou k dalšímu připomínkování.

Přečtěte si k čemu jsme se nakonec přiklonili, komentáře a návrhy jsou vítány.

Agilní manifest najdete na adrese: http://agilemanifesto.org/iso/cs/manifesto.html

Pro diskusi nad překladem prosím využijte veřejnou skupinu na Google Group určenou k diskuzi překladatelů: http://groups.google.com/group/agile-manifesto-translation/browse_thread/thread/3f4ae29650b04c93.

Děkuji všem za pomoc a nápady.

A jak vypadá současná verze překladu Agilního manifestu?

Manifest Agilního vývoje software

Objevujeme lepší způsoby vývoje software tím,
že jej tvoříme a pomáháme při jeho tvorbě ostatním.
Při této práci jsme dospěli k těmto hodnotám:

Jednotlivci a interakce před procesy a nástroji
Fungující software před vyčerpávající dokumentací
Spolupráce se zákazníkem před vyjednáváním o smlouvě
Reagování na změny před dodržováním plánu

Jakkoliv jsou body napravo hodnotné,
bodů nalevo si ceníme více.

Principy stojící za Agilním Manifestem

Řídíme se těmito principy:

Naší nejvyšší prioritou je vyhovět zákazníkovi častým
a průběžným dodáváním hodnotného softwaru.

Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje.
Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.

Dodáváme fungující software v intervalech týdnů až měsíců,
s preferencí kratší periody.

Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.

Budujeme projekty kolem motivovaných jednotlivců.
Vytváříme jim prostředí, podporujeme jejich potřeby
a důvěřujeme, že odvedou dobrou práci.

Nejúčinnějším a nejefektnějším způsobem sdělování informací
vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.

Hlavním měřítkem pokroku je fungující software.

Agilní procesy podporují udržitelný rozvoj.
Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.

Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.

Jednoduchost–umění maximalizovat množství nevykonané práce–je klíčová.

Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.

Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším,
a následně koriguje a přizpůsobuje své chování a zvyklosti.

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.

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?

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.

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.