Proč?

Než se ke změně metodiky rozhodnete, měli byste si nejdříve položit otázku, proč chcete tuto změnu učinit. V čem současná metodika nevyhovuje? Je to proto, že firma vyrostla a organizačně není schopna beze změny obsloužit další vývoj? Nebo se produkt generačně posunul tak, že je potřeba se soustředit na jiné jeho aspekty? Anebo současná metodika nefunguje hlavně kvůli tomu, že ji tým nepřijal za vlastní, nerozumí jí a snaží se jenom naplnit byrokracii s metodikou spojenou? Protože, jestli právě tohle je váš případ (a přiznání tohoto stavu je často velmi těžké a bolestné), tak výměna metodiky je to poslední, co byste měli řešit.

Výběr metodiky

Došli jste k rozhodnutí, že potřebujete změnit či vylepšit vaši současnou projektovou metodiku. Nepodlehněte však klamu a nadšení a nevybírejte podle toho, jak je který „buzzword“ právě populární. Místo toho si klaďte nepříjemné otázky. Je zvolená metodika vhodná pro váš produkt? Pro vaše klienty? Pro váš tým? Máte zdroje na pokrytí vybrané metodiky?

Dnes je zvláště u webových aplikací hodně populární metodika Scrum. Všechno co si o Scrumu přečtete, zní atraktivně. Ale zkusili jste si do důsledku promyslet, jak na metodiku Scrum zareaguje váš klient? Když použiji velkou hyperbolu, tak mu vlastně použitím této metodiky říkáte – nevíme úplně přesně, co za produkt v daném termínu dostanete, ale bude super a bude se vám líbit. Pokud pojedeme na stejné vlně. A to chce hodně osvíceného klienta, který vám bude hodně věřit. Říkejte mi škarohlíd, ale mnohem pravděpodobnější scénář je, že váš pokus o implementaci Scrumu skončí tak, že všude budete říkat, jak úspěšně používáte metodiku Scrum, ale de facto jenom přejmenujete projektového manažera na „scrum mastera“, pojedete na „milestony“, které budete zvát „iterace“ a ráno si uděláte „stand-up“. Což nemusí být nutně špatně, může vám to vyhovovat, ale se Scrumem to nebude mít mnoho společného. Ale mnohem pravděpodobnější je, že se nikam neposunete a mnoho problému nevyřešíte.
 

Ztraceno v překladu

Osobně příliš nevěřím univerzálním pravdám a dokonalým implementacím všespásných metodik. Co považuji za důležité, je neztratit v překladu několik jednoduchých imperativů:

Software development lifecycle

Ať už zvolíte jakýkoliv způsob řízení, nesmíte za žádnou cenu ztratit ze zřetele, že musíte metodicky pokrýt celý životní cyklus vývoje. Nejde jenom o to, něco včas vyvinout, stihnout to otestovat a nasadit. Vaše přemýšlení musí odrážet fakt, že dokud váš produkt nepřestanou používat vaši klienti, tak s ním musíte počítat.
 

Plnohodnotný vývojový iterativní cyklus

Komunikace

Jedním z pozitivních jevů správně implementované metodiky je nastavení shodných očekávání. V každém okamžiku vývoje či správy projektu musí být zřejmý stav věcí současných i budoucích. Každému. Pokud to tak není, jde o selhání implementace. A nejde jenom o běžící projekty. Jde i o projekty které nejsou aktuálně podporované, nebo které nemají přidělené zdroje. Velmi silným a důležitým komunikačním prvkem (jak interním, tak externím) v rámci metodiky je SLA/OLA.
 

I takto může vypadat validní vývojový cyklus projektu, kdy potenciální produktové požadavky a non-critical bugy padají rovnou do „černé díry“. Je to v pořádku, ale všichni zúčastnění o tom musí vědět a musí být známý proces, kterým lze tuto situaci změnit

Omnipotence

Nesnažte se pokrýt metodikou vše. Vždy musí zůstat prostor na improvizaci. Realita vám dá pocítit, jak mocnou, rozeklanou a nevypočitatelnou silou je. Cílem není promyslet do největšího detailu úplně vše nebo objevit všezahrnující workflow a tím celý proces nechat zahynout potupnou smrtí molocha, který byl tak velký, že nebyl sám schopný se pohnout. Cílem je neřešit výjimku z procesu každý den pětkrát, ale v klidu a metodicky se popasovat s neočekávaným dvakrát do měsíce.

Vývojová prostředí

Je krásné si v hrubých rysech načrtnout základy pro tzv. continuos integration (inherentní část přemýšlení v rámci SDLC). Nadefinovat odpovědnosti za jednotlivá prostředí, kdo kam může, jakým způsobem se bude testovat a dělat deployment. Pro vývojáře, QA, projektového a produktového manažera – jsou tato „virtuální“ prostředí nesmírně důležitým pracovním prostorem. Proto je potřeba myslet na to, aby se snadno vytvářela, na požadavky se nečekalo, byla dostatečně výkonná a celý systém práci usnadňoval a nepřekážel.

Nadefinovat si dokonalé workflow se spoustou prostředí, a pak je mít improvizovaná, na poddimenzovaném hardwaru či nedostatečně organizovaná vytvoří více problémů, než jich vyřeší. Naopak dobře vyřešený vývojový prostor nejenom zlepší kvalitu řady objektivních faktorů, ale signifikantně zlepšuje i percepci vývojářů a jejich subjektivní vztah k pracovnímu prostředí.
 

Schéma jednotlivých vývojových prostředí společně s náčrtem odpovědností a přístupových práv

Plaťte zaměstnance za to, v čem jsou nejlepší

Dokonalý proces, který bude mít pod kontrolou každý aspekt a fázi vývoje, avšak seniornímu vývojáři sebere polovinu jeho „expertní“ kapacity, minimálně plýtvá prostředky, o možných problémech s motivací nemluvě. Ujasněte si popis všech rolí v celém vývojovém cyklu a optimalizujte jejich participaci. Není a priory špatné používat pro projektové plánování Excel a Googlesheet. Špatné je, když u jeho vyplňování tráví vývojáři dvacet procent své kapacity a projektový manažer se musí na den zavřít do zasedačky, aby dokázal vyrobit aktuální status report. Soustřeďte se na co nejjednodušší pohled na problém. Programátor má programovat, a ne schůzovat. Senior programátor má programovat a ručit za technickou kvalitu nějakého většího celku, a ne kontrolovat, jak programátoři vyplňují status report. Projektový manažer má řídit projekt, a ne být byrokratem první třídy.

Implementace

Vybrat, upravit či vymyslet projektovou metodiku je jedna věc. Ta snazší. Implementovat projektovou metodiku je úkol olbřímích rozměrů. Stávající stav má netriviální hybnost a často jenom vybojovat prostor pro úvahy o změně není triviální manažerská rozcvička. Implementace je potom o postupném prorůstání nových idejí do reálného světa vašeho R&D oddělení. Snažit se o komplexní změnu ze dne na den je pošetilé a odsouzené k neúspěchu.

Top down

Jedním z největších úkolů při změně metodiky je komunikace. Každý člen týmu musí vzít metodiku za svou. Musí ji pochopit. A musí ji akceptovat. To znamená jediné: mít správnou komunikační strategii a vysvětlovat a vysvětlovat. A vysvětlovat. Nicméně na konci musí být schovaný diktátor, který ve správný okamžik přijde a řekne: tak to bude! Projektová metodika nemůže fungovat na bázi dobrovolnosti. Správně odměřené zrnko autokracie je nezbytnou a klíčovou součásti každé implementace.

Nástroje

Zaměstnancům je samozřejmě nutné dát do ruky nástroje, které jim umožní plnit jejich úkoly. A to něco stojí. Už jen pro vytvoření pre-produkčního prostředí je potřeba nejenom hardware, na kterém poběží, ale i softwarové licence. A pak i někoho, kdo se o prostředí bude starat. Tím vším však značně rostou operativní náklady, a tak se při nerozumné volbě podpůrného softwaru a dalších nástrojů může stát, že z toho, co vypadalo na papíře dokonale, se vyvinul komplexní a drahý problém, na který se jen těžko budou shánět finance.

Naděje

Ani úspěšná implementace projektové metodiky vás nezbaví všech problémů. Když budete dobří, tak vám signifikantní počet problémů ušetří. Největším úspěchem bude, že o problémech budete vědět. Nejenom vy, ale celý tým. A budete vědět, jak dobří jste. Nebo také nejste.

Petr Chlumský
Autor působí ve společnosti Arbes Technologies.