Studie dále uvádí i prvních pět důvodů pro úspěch IT projektů:
• Zapojení uživatele
• Podpora Executive manamentu
• Jasné business cíle
• Optimalizace funkcionality
• Agilní procesy

Pro firmy uvažující o přechodu na agilní metody bych ráda zmínila i Standish Group CHAOS studii z roku 2012, která porovnává úspěšnost IT projektů řízených tradičními metodami s agilními. Výsledky jsou opravdu překvapivě dobré ve prospěch Agilních metod.

Zpráva dále doporučuje Agilní metody jako “univerzální řešení nízké úspěšnosti softwarových projektů”. Projekty, na kterých jsou nasazeny Agilní procesy, mají třikrát vyšší úspěšnost než projekty řízené klasickým waterfallem. Zároveň výrazně nižší procento agilních projektů končí později a přesáhne stanovený budget.

Můžeme diskutovat o tom, proč taková data byla naměřena a čím to přesně je, nicméně pro všechny agilní nadšence, kteří hledají nějaký důkaz proč agilní metody ve firmách alespoň zkusit, to může postačit jako vhodný argument pro podporu pilotního projektu. Zbytek už bude na vás a vašich schopnostech. A já věřím, že se agilní metody osvědčí i u vás.

- omezit rozpracovanou práci – work in progress
- minimalizovat čas průchodu – lead time
- vizualizovat progress

Tedy aplikováno na sw vývoj – udělejte si hodně přehlednou tabuli, připravte kartičky s jednotlivými úkoly, rozdělte proces na jednotlivé fáze – pro začátek stačí “Backlog / In progress / Done” a omezte, kolik lístečků může být najednou v jednotlivých sloupcích. Když už kvůli limitu nemůžete přidat další lístek, musíte nejprve dokončit některý z rozpracovaných. Zdá se to být snadné, ale ne tak úplně. Např. stanovování limitů front je poměrně věda.

Kanban sám o sobě není proces, proces z něj teprve musíte udělat vy. Je to trochu náročnější než u Scrumu, který vás hodně při implementaci vede, ale zase na druhou stranu, ve Scrumu či XP se můžete inspirovat. V úspěšných implementacích to nikdy nebude jen Kanban, vždy to bude Kanban a něco k tomu.

Nejznámější Lean firma je určitě Toyota. Tam vyvinuli proces řízení výroby, odlišný od běžných procesů kdy vyrábíme kdykoli a cokoli na sklad. Řídí výrobu systémem tahu, kde vyrábíme příslušný díl, až když je potřeba.

Jak takový princip použít ve firmách kdy žádné fyzické díly nevyrábíme? Tak se třeba podívejme na standardní vývojový proces – waterfall. Nejprve uděláme na sklad analýzu, pak kód, a pak testy. A čekáme, že to je tak v pořádku a že všechny díly jsou kvalitní (tedy že design už se nezmění, v kódu se nenajde chyba, a že zákazník to tak opravdu chce). A stejně jako ve výrobě se nám děje, že jednotlivé věci musíme předělat, opravit, zahodit. Někdy i celou krabici dílů se stejnou chybou (někdy i celou rozsáhlou funkcionalitu).

Jak na to? V kostce, omezte ‘work in progress‘ a soustřeďte se na to, abyste jednotlivé požadavky protlačili systémem co nejrychleji. Implementujte systém tahu a nezačínejte s analýzou, dokud nemáte prioritní požadavek od zákazníka. A dokud nemáte zpětnou vazbu, že předchozí požadavek byl akceptován.

A aby to bylo více uchopitelné, Lean Software Development je založen na následujících principech:

Odstraňte vše, co nepřináší hodnotu – tedy zbavte se odpadu. Pracovat na něčem co se ve finále vyhodí je škoda času, když se vám podaří tento čas investovat do věcí, co mají smysl, budete jistě efektivnější.

Zlepšujte se a učte se již v průběhu – když jen slepě vykonáváte předpisy a sledujete procesy, může se stát, že stejnou chybu opakujete pořád dokola a ‘odpad’ se vám tedy na konci projektu nahromadí víc, než byste si přáli. Pravidelná zpětná vazba vám pomůže se soustředit jen na to, na čem záleží.

Rozhodujte se co nejpozději – čím později rozhodnutí padne, tím více máte informací. Takže jsme zase zpět u myšlenky, že nemá smysl vyrábět zásoby na sklad jen proto, že zrovna máte volnou linku nebo programátory.

Dodávejte práci, jak nejrychleji to jde – čím dříve něco dokončíte, tím dříve dostanete zpětnou vazbu, kterou můžete hned v další iteraci zohlednit.

Dejte týmu důvěru a zodpovědnost – a budete mít mnohem motivovanější tým, než když se budete držet tradičních top-down struktur.

Zaměřte se na celkový dojem – produkt není jen software. Dbejte na kvalitu a celkovou udržitelnost systému, nevytvářejte technický dluh.

Zaměřte se na celkový výsledek – jednotlivé chyby a selhání nejsou podstatné, pakliže se z nich poučíte. “Think big, act small, fail fast; learn rapidly” – tedy Přemýšlejte dopředu, začněte u malých věcí, ty vyhodnoťte a rychle se z nich poučte. Jen tak zajistíte, že výsledný produkt bude úspěšný.

Metoda, která vám radí jak na to je Kanban. Ale o tom zase příště.

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.

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.

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

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

Diskuze probíhají na lokální úrovni a následně budou pokračovat na konferenci XP 2011 v Madridu začátkem května, kde proběhne world café session zaměřená na prezentaci cílů ALE network.
Zapojit do diskuse o cílech ALE network se můžete na následujících dvou akcích Agilní Asociace: Workshop v Plzni a open café v Praze.

A protože do Madridu se za agilní komunitu chystáme, určitě o tom po návratu něco napíšu.

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.

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.