Posledních několik let se stále častěji setkávám s nejrůznější formou implementací agilních metodik v softwarovém vývoji. Vzduchem létají už suverénně pojmy jako user stories, scrum, team velocity, story points a další. V některých firmách začínají převládat tabule poseté barevnými papírky nad technickými diagramy a kalendáře vývojářů se plní stand-upy, groomingy a dalšími ceremoniemi.
Opravdu to pomáhá být týmům efektivnější a odvádět lepší práci nebo je to jen dobře znějící metodika zneužitá managery k řízení týmu?
Odpověď na takovou otázku samozřejmě není jednoznačná. Co tedy vnímám jako největší problémy?
Agile jako řešení problémů s waterfallem
Vývoj software dělám už více jak deset let a nikdy jsem se nesetkal s učebnicovým waterfallem. Ve všech projektech, jsme si zvolili postupy, co nám dávají smysl. Často tím přibližují projekt k agilním principům. Jistě jsem se mnohokrát zmýlil a projekt prostě neodhadl správně, ale to je součást procesu získávání zkušeností.
Pokud ale někdo bude tvrdit, že například implementací SCRUM metodiky vyřešíte všemožné problémy vašeho týmu, je možné, že půjdete s kanónem na vrabce a týmu tím nepomůžete nebo právě naopak.
Agilní frameworky jako bedny s nářadím
Agilní frameworky beru jako hotové bedny s nářadím. Preferuji vybrat si z ní pouze nástroje, které dávají smysl týmu, projektu a především firmě nebo zákazníkovi.
Vhodné postupy při plánování, odhadech a sledování práce se mohou různit podle velikosti týmu, zkušeností, rolí v týmu, typu projektu, fáze projektu, rozsahu zadání, komplexností, stylu práce týmu a dalších měřítek.
Určitě budu chtít řídit jinak například 5 zkušených vývojářů při návrhu dalšího back-end systému a jinak 2 front-end juniory pracující na malém statickém webu.
Zkušenosti metodika nenahradí
Nechcete dodávat vše najednou? Rozdělte si projekt na milníky nebo pravidelné sprinty.
Nevíte, co řeší kolegové? Začněte se pravidelně potkávat.
Nesedí odhady? Poraďte se o nich s ostatními.
Nechcete na začátku přesně odhadovat celý projekt, protože nikdo nezná detaily? Dejte odhady v rozsahu a uveďte míru nejistoty a přemýšlejte, jaké rizikové části je třeba vyjasnit první.
Nejsou ze zadání jasné dopady na ostatní procesy a systémy? Vzneste riziko a udělejte změnovou analýzu.
Ať si zvolíte jakékoliv postupy, musí dávat smysl. Přemýšlejte hlavou a dejte přednost zkušenostem a argumentům, než dogmatickému dodržování frameworku, co slibuje jen samé výhody.
User stories a posedlost sprinty
Agilní vývoj využívá hojně pro popis úkolů formu user stories. Což je jeden ze způsobů, jak analyzovat funkcionalitu. Obvykle z pohledu uživatele popisuje, co má nového systém umět.
Několikrát jsem se setkal s přístupem, kdy se jiný způsob zadání setkával s odporem, protože to “smrdí waterfallem”. Reálně to dopadá tak, že user stories jsou jen kontejnerem na libovolné zadání úkolů nejrůznějších typů.
Postupné dodávky, průběžná dema a pevná délka sprintů mají často smysl – neviděl bych to ale jako dogma. Snaha vejít se do sprintů s user stories je podle mě na většině projektů spíš na škodu. Pokud mám úkol na měsíc (který může být pro přehlednost rozpadnutý na menší úkoly), tak se nebudu snažit z něj za každou cenu udělat dvě user stories a nebudu nutit vývojáře, aby stihl první user story do konce prvního sprintu. To je jen onanie pro hezčí graf a oblbování zákazníka nesmyslným demem.
Bohužel jsem se setkal i se situací, kdy vývojář byl oceňovaný za dodržení sprintu víc, než za kvalitu práce – a to i když kvalita práce ovlivnila rychlost dodání celku.
Také bych si nedělal hlavu ze zasahování do scopu během sprintu. Nechci a nemůžu se omezovat na sprint jako na neměnnou jednotku – musím řešit důležité úkoly jak přichází a zároveň průběžně pracovat na těch dlouhodobých.
Ceremonie
Ceremonie kolem agilního vývoje – někdy smysl dávají, jindy jsou ztrátou času. U mě v týmu jsem třeba zrušil standupy a nebudu do nich vývojáře nutit, pokud se mezi sebou dohodnou sami a nechtějí to po mě – ačkoliv to není univerzální řešení pro všechny.
V týmu jsem zastáncem transparentnosti, ale ne vždy považuju za nutné několikrát za sprint svolávat ceremonie a probírat vše hromadně. Snažím se omezit ceremonie na maximálně hodinu na týden, kde si s týmem prolétneme, co se aktuálně děje. Opět i zde můžou různé okolnosti vyžadovat různou společnou časovou investici.
Kolik času zabere story point?
Story pointy možná někomu vyhovují, ale seniorní vývojář podle mě musí umět odhadovat na počet dnů (MD) s případným rozpadem na menší části a uvedením nějaké míry nejistoty. Schovávat se za story pointy je z mnoha ohledů taktické, ale stejně přijde otázka: A kdy to tedy bude hotové?
Závěr
Předchozí řádky berte s rezervou, úmyslně v některých bodech zjednodušuji a přeháním. Nejsem odpůrcem agility týmu – jen považuji za nešťastné, jak je mnohdy implementována.