10 ledna 2013

Spasí SCRUM Váš vývoj softwaru?



Agilní metodika SCRUM je již poměrně dlouhou dobu (asi tak dlouho, co vývoj software není považován za sériovou výrobu) velmi populární metodou v oblasti vývoje softwaru. Dokonce bych se ji nebál označit tak, jak je často vnímána mezi vývojářskou komunitou, jako určitou "trendy" metodiku, kde se "jde přímo na věc". Domnívám se, že SCRUM je mimo jiné velmi populární díky tomu, že je především jednoduchý a základní principy lze vstřebat během krátké chvilky studování. Otázkou však zůstává, proč tak často dochází k selhání použití této metodiky. Mnoho pokusů zavést SCRUM do firemního prostředí vývoje software ztroskotá a když se to nakonec nějak podaří, tak většinou až na několikátý pokus. Agilní metodika SCRUM není totiž všelékem na problémy, které se vyskytují během vývoje. Pokud se nám například na samotném začátku nedaří se zákazníkem domluvit a vyjasnit si rozsah projektu, tak použití agilního přístupu, s tím, že se rozsah nějak dospecifikuje během projektu, je většinou cesta do pekel. 

Principy metodiky SCRUM jsou skutečně triviální. Na internetu lze najít bezpočet zdrojů a mnoho knih, které velmi rychle vysvětlí základy. Jakým způsobem organizovat tým, jak rozdělit role, které schůzky naplánovat, jak mají dlouho trvat, jak definovat produkt nebo jak produkt postupně sledovat. Specifikace neobsahuje mnoho tisíc stran jak je to v případě jiných metodik vývoje, ale poměrně jednoduše a přímočaře podává recept na vývoj software. Celé se to jeví možná až příliš snadné, tak v čem je vlastně háček? 

Osobně si myslím, že zavedení a používání SCRUMu nespočívá primárně v samotném použití metodiky a jejich základních pravidel (což je dle mého názoru triviální záležitost), ale v samotné filosofii přístupu. Pokud totiž aplikujeme metodiku do prostředí, kde lidé nejsou ochotni měnit svůj způsob myšlení, firemní kultura je postavená na úplně jiných základech a není v souladu s obecnými principy SCRUMu, tak jenom těžko ve finále dosáhneme výraznějšího úspěchu. SCRUM je o lidech, o týmu a především o komunikaci. Z tohoto pohledu je zásadní a klíčová role SCRUM Mastera, což by měl být člověk, který má zkušenosti s vedením lidí, dokáže vybudovat v týmu důvěru, rozvíjí jeho kompetence tak, aby byl tým schopen sám jednat a rozhodovat, posiluje odpovědnost členů za vlastní práci, podporuje věcné konflikty a jejich řešení a hlavně podporuje komunikaci. Ve zkratce Scrum Master by měl být zkušený lídr, který dokáže vytvořit skutečný tým (dnes je týmem označováno téměř cokoliv, kde se vyskytuje nějaká skupina lidí) a soustředí se primárně na to, aby byl tým dobře "promazaný" a správně fungoval.

(Ve SCRUMu se v týmu preferuje osobní komunikace, pro ilustraci si uveďme jeden příklad. Mark Cohn, jeden z guru agilních přístupů, ve své publikaci User Stories Applied doporučuje postup, který se vztahuje k definici požadavků na produkt. User story (požadavek) musí být napsaná na lístek tak, aby během schůzek podnítila tým k diskuzi, jak user story naimplementovat, pokud žádná taková diskuze nevznikne, pak je user story zřejmě napsaná špatně - možná příliš obecně a je ji nutné přepsat a zjednodušit.)

Pokud se tedy chystáte zavést SCRUM, tak je dobré se soustředit na vhodný výběr lídra týmu (Poněkud často je volen největší expert v týmu, což nemusí být dobrá volba. Asi v tom bohužel většinou hraje roli možnost vertikálního kariérního růstu.). Dále zhodnotit současné nastavení firmy, jak jsou lidé zvyklí pracovat a přemýšlet, jaká kultura se ve firmě nosí, jak jsou zaměstnanci přístupní ke změně, jak je prostředí transparentní a důvěryhodné, či autoritativní nebo podléhá zvýšené kontrole. Co je dobré si uvědomit, že SCRUM se zpravidla podaří nasadit až na několikátý pokus, což dokládá to, že konkrétní postup metodiky můžeme uvést v život hned, ale změna přístupu a myšlení trvá chvíli déle.

(Uveďme si jeden ilustrující případ, kdy se agilní metody zaváděly do společnosti, která zaměstnávala cca tisícovku COBOL vývojářů, jejichž průměrný věk se blížil k 50 rokům a byli zvyklí pracovat jistým způsobem řadu (desítky) let. Pak přišlo rozhodnutí změnit způsob vývoje na agilní a tím pádem zrychlit dodávku software. Ve výsledku, po mnoha problémech, se musel vytvořit zcela nový postup-rámec, který specifikoval a blíže vysvětlil, kdo má co přesně dělat a tento postup se zaváděl více jak rok.)

Žádné komentáře: