Úspěšnost agilních projektů

Pro firmy, které s agilním vývojem nemají praktické zkušenosti, je jednou z nejdůležitějších otázek jak jsou agilní projekty úspěšné. První, na co si musíme odpovědět je úspěšnost IT projektů obecně. Jaká je? A jak se vlastně pozná úspěšný projekt? Když se nad takovou otázkou zamyslíte, zjistíte, že jde o projekt který je dodán včas, v rámci budgetu a s očekávanou funkcionalitou. Jaké procento úspěšnosti byste očekávali?
Standish CHAOS study dělá již pár let výzkum, jehož výsledky nejsou nijak povzbudivé – pouze cca 30% projektů končí úspěšně. Ostatně posuďte sami:

Success of IT projects

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.

Agile vs. Waterfall Projects success

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.

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

Nedávno jsem narazila na zajímavý článek od Roberta C. MartinaWhat 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.

Waterfall, RUP nebo Agile?

Začínáte projekt a nevíte kterou metodu zvolit? Zkusím se podívat na jednotlivé metody detailněji. Tradiční Waterfall vypadá ideálně. Nejprve si navrhnete, co budete dělat, pak řeknete jak, pak to uděláte, otestujete. Ideální. Snadné. Jen bohužel realita je vždy jiná. Výsledek ukážete zákazníkovi, a on se zatváří zklamaně, řekne, že tohle si nepředstavoval, či že tohle nikdy nechtěl a ať to předěláte. Vás pak na jedné straně čeká dlouhý refactoring a předělávání, a k tomu zákazník, který je nervózní že aplikaci stále nemá. Na druhé straně jsou dlouhé diskuze se zákazníkem, že v jeho původních požadavcích to bylo jinak či nebylo vůbec. A že tento refactoring musí zaplatit extra. Nic neobvyklého, a nic co by se jen blížilo spokojenosti na obou stranách.

Proto vznikl Rational Unified Process (RUP), který si uvědomuje, že není možné celou aplikaci napsat v jednom sekvenčním procesu – ostatně stejně se tak nikdy v reálu nedělo – a že jednotlivé fáze jsou více či méně přítomny periodicky v průběhu celého procesu. RUP se dá v podstatě považovat za pokus přiblížit Waterfall reálnému světu. Pokus to byl dobrý, nicméně spokojenosti zákazníka moc nepřispěl. Návrh vede často k velice komplexní a náročné architektuře, která ztěžuje případný refactoring. Navíc jednotlivé fáze jsou extrémně detailně specifikované, tedy libovolné změna vyžaduje i dlouhý čas na přepsání všech modelů a diagramů.

Asi nikoho nepřekvapí, že budu na tomto místě doporučovat agilní metody. Na rozdíl od předchozí metody, která vsadila na dobrý návrh, jsou agilní metody orientovány na změnu. Návrh by měl být co nejjednodušší, iterace dostatečně krátké, aby se omezilo riziko refactoringu. Navíc zákazník, který vidí každé dva týdny jednu feature a může se k ní přímo vyjádřit, je potom v daleko horší situaci když na konci projektu chce něco jinak. Agilní metody omezují návrh a dokumentaci na nutné minimum, nicméně na druhé straně zapojují testování hned na začátek návrhu (TDD), zavádí automatické testování a kontinuální integraci. Agilní metody jsou navíc založené na spolupráci, a to jak v rámci týmu tak i externě se zákazníkem, což je činí o dost efektivnější.

Na závěr přidávám krátkou tabulku s porovnáním jednotlivých metod:

 

Waterfall

RUP

Agile

 

Sekvenční

Inkrementální

Iterativní

 

Jasně definované requirementy.

Počítá s mírnou změnou requirementů.

Requirementy se konzultují se zákazníkem v průběhu.

 

Specifikace se nemění

Specifikace se nemění v rámci inkrementu.

Specifikace se nemění v rámci sprintu.

 

Jednotlivé fáze (analýza, design, testování, …) jsou oddělené a sekvenční.

Jednotlivé fáze (analýza, design, testování, …) jsou oddělené, ale běží paralelně.

Nerozděluje projekt na jednotlivé fáze. Každá úloha obsahuje všechny fáze (analýza, design, testování, …).

 

Striktně definovaný proces, který nepočítá s žádnou změnou.

Složitý, use-case driven, architecture-centric proces. 

Metodologie založená na rychlé reakci na změnu a spolupráci (interní i externí).

 

Jednotlivé fáze jsou zdokumentované

Snaha mít vše do detailu zdokumentované. 

Dokumentace jen v nejnutnější míře, jednoduchý designe, hlavní metrikou je spokojenost zákazníka.

R

I

Z

I

K

A

·         Nespokojenost zákazníka (něco jiného než chtěl)

·         Dlouhý refactoring

·         Nepřesné odhady

·         Příliš složitá a náročná architektura

·         Dlouhý refactoring

·         Nepřesné odhady

·         Náročný na komunikaci a kooperaci

·         Musí odpovídat firemní kultuře

P

O

U

Ž

I

T

Í

Jasně definovaný a dobře specifikovaný projekt kdy změna je vysoce nepravděpodobná. Zákazník musí perfektně vědět, co chce dopředu. Náročný na zkušenosti jednotlivých engineerů.

Komplexní systémy vyžadující detailní dokumentaci a náročnou architekturu. Změna požadavků je nepravděpodobná. Náročný na zkušenosti jednotlivých engineerů.

Projekt pro běžné zákazníky co často úplně přesně nevědí, co chtějí. Požadavky se mohou měnit v rámci projektu. Cílem je spokojený zákazník. Střední nároky na zkušenosti týmu.