Tag: Waterfall

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.