Je Scrum správná cesta?

MetodikaAgilní metodiky, těžké metodiky nebo selský rozum. Všechny přístupy mají něco společného - naplánovat, řídit a úspěšně dokončit projekt. Nezáleží tolik na samotné metodice, ale na tom, jak silný se nám podaří sestavit tým. A právě na to se zaměřuje tento článek.

 

Odpověď na otázku jak co nejlépe optimalizovat procesy v rámci softwarového vývoje trápí nejednoho manažera. Ačkoliv je každý projekt unikátní ve smyslu jeho cíle, času, zdrojů, apod., obecná pravidla a postupy která vedou k jeho dokončení jsou vždy stejná. Ty jsou popsány v metodikách a metodických rámcích, kterými jsem se zabýval v jednom z předešlých článků).

V počátcích softwarového vývoje převládaly především tzv. těžké metodiky. Postupy, role a zodpovědnosti byly přesně dány. V centru pozornosti byl realizační tým, resp. dodavatel a samotní programátoři  v kontaktu se zákazníkem tak často nebyli. Proto většina požadavků byla formulována na začátku projektu a jeho rozsah, cena i čas byly většinou fixní.

 

IT je ale tak dynamické odvětví, že vypracovat detailní plán netriviálního projektu a identifikovat všechna rizika na začátku není prakticky možné. Velkou výhodou je, pokud má realizační tým minulé zkušenosti s něčím podobným. Na druhou stranu se ale mohou změnit technologie a ne vše bude zcela relevantní. SW projekty tedy bylo potřeba začít řídit trochu jinak.

 

Místo plánování na měsíce nebo dokonce roky dopředu, se začíná prosazovat iterativní vývoj. To znamená, že se plánuje jen na krátký časový úsek (iteraci), na jejímž konci je spustitelný kód, který zákazník může využít pro svoje potřeby. Jedná se tedy o malé funkční přírůstky, které lze poměrně detailně specifikovat. Zákazník je ostatně ten, kdo je do vývoje zapojen po celou dobu a díky jeho neustálé zpětné vazbě se pořadí priorit v projektu mění. Popsaný koncept je vlastní tzv. Agilním metodikám, kde nejznámější a nejpoužívanější z nich je Scrum (viz. 10th State of Agile - Version one).

Scrum - tým, který nepotřebuje manažera

Scrum je populární především díky svojí jednoduchosti. Scrum neříká, jaké role musí být na projektu zastoupeny. Místo toho klade velký důraz na tým jako celek. Podle teorie zde nejsou žádní programátoři, žádní testeři, žádní architekti, atd… všichni by měli být schopni se navzájem doplnit a zastoupit se v rámci projektu. Jediná role navíc, je tzv. Product Owner (zákaznik) a Scrum Master (spíše mentor týmu, než projektový manažer).

 

Ve Scrumu by teoreticky neměl být nikdo, kdo týmu říká, jak a co má dělat. Jakákoli práce se plánuje na základě diskuze s Product Ownerem. Z té se vyvodí závěry, zda je možné implementovat požadovanou funkcionalitu v daném rozsahu a kdy k tomu dojde. Není zde žádná autorita, která by na tým tlačila ve smyslu používání určitých nástrojů a technologií, případně dodržování různých postupů, apod..(pokud to samozřejmě nevyžaduje přímo zákazník). To vše je najednou jen na samotných členech týmu, jak se k tomu postaví a udělají maximum, aby byl projekt úspěšný.

Scrum je jako podnikání, ale je to pro každého?

PodnikatelPřirovnat Scrum k podnikání jsem nevybral náhodou. Od členů týmu se totiž prakticky vyžaduje podobný styl uvažování jaký by měl mít podnikatel. Podle průzkumu společnosti Ernst & Young převládá názor, že podnikatel musí mít především vizi, vášeň, zaujetí pro věc (73%) a tah na branku (64%). Dále následují novátorství, schopnost jít do rizika, či proaktivita a zaměření na zákazníka. Člověk se tedy musí umět pro věc nadchnout a investovat do toho spoustu úsilí. Podnikání ale není jednoduché. Například jenom podle vládní agentury Small Business Administration, 60% firem v USA nepřežije prvních pět let. Další odhady předvídají konec až 80% startupů během prvních 10 let.

 

Scrum je založen do určité míry právě na stejných principech jako provozování firmy, a to klade nemalé nároky na lidi.

Agilní přístup se definoval relativně nedávno (Agilní manifest vznikl v roce 2001) a Scrum je na vzestupu teprve několik let. Nejedná se ale zase až o takovou novinku. Kdo zná např. princip samosprávných dílen Tomáše Bati, nachází zde určitou paralelu. Dílny v jeho podání představovaly víceméně samostatný celek v rámci firmy. Měly vlastní hospodaření a odměňování zaměstnanců záviselo na jejich výkonnosti. Každý se tak přímo podílel na zisku společnosti, což do určité míry vedlo ke zvýšení motivace lidí a nakonec i ke kvalitní práci. Systém jako celek podporoval podnikatelského ducha u všech zaměstnanců, ale nejvíce zainteresován byl vedoucí dílny, který měl zodpovědnost za práci, zisk i ztrátu oddělení. Řadoví dělníci toho na samotném procesu nemohli zase až tolik ovlivnit.

Zaměstnanec není podnikatel a naopak

Scrum jde trochu jinou cestou. Aktivní přístup k řešení problémů a optimalizaci procesů od jednotlivých “řadových” členů přímo vyžaduje. Otázkou je, jak moc je to pro jednotlivé lidi vhodné. Pokud budeme vycházet z toho, že se důraz klade na samo-organizující se týmy a ve spoustě faktorů nacházíme shodu právě s podnikáním, tak na základě předložených statistik je zřejmé, že ne každý na to má.

 

Za podnikáním stojí především přání být vlastním pánem, resp. osobní nezávislost. Dále hraje roli svoboda volby místa a doby práce, případně vyhlídka na lepší příjem nebo využití obchodní příležitosti (1). Aby se podnikatel stal úspěšným, tak se nemůže soustředit jen hlavní předmět podnikání, ale musí být schopný pokrýt i jiné oblasti s tím sice zdánlivě nesouvisející, ale neméně důležité.

 

Zaměstnanec má ale trochu jiný pohled. Představte si, že jste expert v určitém oboru a chcete se neustále zlepšovat. Samozřejmě, že bez určitého nadhledu, bez porozumění jiným souvisejícím oblastem to nikdy nepůjde a bude vám něco chybět. Ale pořád se jedná o ryze profesní stránku, de facto takovou škatulku. Cílem Scrumu je ale tuto škatulku rozbít v zájmu zlepšení všech procesů v projektu. Najednou je běžný zaměstnanec postaven před podobný úkol jako podnikatel - měl by se na produkt či službu dívat z pohledu byznysu a analyzovat zákaznické požadavky do té míry, aby byl schopný přijít s nápady jak pomoci Product Ownerovi s jednotlivými use casy, apod. Zkrátka každý v týmu by najednou měl mít představu o tom, proč dělá to, co dělá a jaký to bude mít efekt pro zákazníka. Otázkou je, zda je reálné to očekávat od všech v týmu.

 

Dovolím si tedy upozornit na jednu věc, kterou si možná málokdo uvědomuje. Pokud vycházíme z toho, že agilní metodiky a zvlášť Scrum staví na podobných principech jako soukromé podnikání, tak musíme vzít nutně do úvahy rozhodování a zodpovědnost. Podnikatel je plně zodpovědný za to, co dělá a hlavně musí zkoušet a vymýšlet kroky, které povedou k úspěchu. Sám si musí hledat zákazníky a udržet si ty stávající.

 

pcZaměstnanec má narozdíl od podnikatele vše již dané od svého zaměstnavatele (bavíme se stále čistě jen o softwarovém vývoji, tedy o programátorech, UX/UI designerech, testerech, apod.). Takový člověk se tedy soustředí výhradně na svoje expertní znalosti - na to, jak splnit zadání co nejlépe. Nemusí se starat o samotný byznys, resp. o to jakými argumenty přesvědčit stávající nebo budoucí zákazníky ke koupi/upgradu vyvíjeného produktu a nemusí se vlastně starat ani o ostatní procesy ve firmě jako takové.

 

Ačkoliv většina dotázaných v různých průzkumech (2,3) uvádí, že Agile je vhodný pro jejich práci a zaznamenali zlepšení v různých oblastech, je zde i nemalé procento těch, kteří s tím tak úplně nesouhlasí. A aby firma byla úspěšná, je třeba brát i tyto hlasy vážně.


Tento článek nemá za cíl rozebírat důvody, proč tomu tak je. To by bylo nutné se zeptat přímo konkrétních lidí. Spíše než to má ale upozornit na skutečnost, že implementace jen jedné metodiky, resp. metodického rámce nemusí být vždy ta správná cesta. Každý projekt, každý člověk a každý tým je jiný a právě z toho důvodu je potřeba hledat víc možných řešení. Metodiky či metodické rámce by si navzájem neměly konkurovat, ale právě naopak - mají se co nejvíce doplňovat.

 

Zdroje:

1 http://ec.europa.eu/public_opinion/flash/fl_283_en.pdf

2 http://research.microsoft.com/en-us/um/redmond/groups/hip/papers/agiledevatms.pdf

3 http://stateofagile.versionone.com/

 

 

Share

Počítač ENIAC z roku 1946
IBM PC z roku 1981
Datacentrum - "skladiště" cloudových služeb