Když nás někdo kolem roku 2010 koupil velký korporát, začali do nás hustit Agile a Scrum. Ze začátku mě to opravdu nadchlo. Byla to totiž obrovská úleva a pokrok oproti předchozímu vodopádu a chaosu v úkolech. Ty byly vedeny po různých Wordech a Excelech, emailech a poznámkách. A navíc, člověku nikdo pořádně neoponoval ohledně stavu projektu, dohledat, kolik toho ještě chybí dodělat bylo prakticky nemožné a podle toho vypadaly výsledky …
Jenže po pár letech zkušeností jsem vystřízlivěl, viz dále, a moje zkušenosti mě vedly k parafrázi na vtip – projektový manager je člověk, který si myslí, že devět žen porodí dítě za měsíc. Agilní manager si myslí, že první měsíc se porodí jedna ručička, druhý měsíc druhá, třetí měsíc nožička atd…
A pořád si myslím, že agilně letadlovou loď nepostavíte…
Nástroje
Nástroje typu Jira byly pro mě tehdy velkou novinkou. Najednou člověk věděl a viděl, co má dělat, co dělají ostatní, jak to na sebe navazuje atd. A když se to propojilo na gitem, tak se daly sledovat požadavky až na úroveň zdrojového kódu. Tyhle nástroje nemají s agile a scrumem přímou spojitost a jejich použití je možné samozřejmě i v rámci vodopádu i chaosu. Ale v Agilu dávají o to větší smysl, byť vedou i k odvrácené straně, na kterou jsem narazil poměrně brzo.
Šlo třeba o mikromanagement v tascích jdoucí na úroveň jednotek hodin, kdy režie zabírala více času než realizace a z programátorů se stávaly nemyslící lopaty. Asi to dává smysl u úplných juniorů/absolventů a je to nutné u přeučených horníků, ale normálně beru jako minimální granularitu pracnosti úkolu cca den. Taky došlo na „soutěž“, kdo bude mít více splněných tasků, což je přímý důsledek předchozího bodu. Nejdříve si rozsekám jeden denní úkol na šest hodinových a pak si ještě budu stěžovat, že management tasků mi zabral dvě hodiny… Nebo jsem viděl manažera hodnotícího průběh projektu podle složitosti „kolejí“ větví v Gitu. A zažil jsem různé fancy grafy a vizualizace umně maskující, že nestíháme…
Ale více chci psát o vlastním procesu, o agile a scrumu…
Procesy
Jak jsem již uvedl, myšlenka agile a scrumu mě od začátku opravdu nadchla. Ten kolektivní přístup byl/je super, člověk na to není sám. Jenže po dvou dnech plánování čtrnáctidenního sprintu, který se stejně po týdnu rozpadne, už to tak super není. Zvlášť, když se dokola řeší to stejné. Nebo se sice nestíhá, ale místo kódění musíme mít retrospektivu, protože je to v brožuře. Už potřetí si během ní řekneme, že nestíháme, nadefinujeme Action Pointy ale protože nestíháme, tak nemáme čas je splnit. A tak si dáme Action Point – splnit Action Pointy z minulé retrospektivy…
Nebo takový Planning Poker. Opět skvělá myšlenka, protože se tím utříbí myšlenky a zadání, které může každý chápat jinak. Takže když někdo řekl pracnost 1 a druhý 20, bylo jasné, že je něco špatně. Ale když v třetím kole jeden řekl 11 a druhý 13 a scrum master pořád trval na tom, že se musíme shodnout… A po další půlhodině debat jsme se shodli, že když to bude programovat Franta, tak platí Frantův odhad. A taky se klidně stalo, že se všichni sice shodli na 2, ale každý to chápal úplně jinak, takže realita byla 20, protože každý měl pravdu, akorát se ty pracnosti sečetly…
Vystřízlivění – role
Co mi ale vadilo mnohem víc a je podle mě principiální, tak jsou role a zodpovědnosti.
Tak za prvé, měli jsme třeba heterogenní teamy, takže jsem tam byl třeba já, jako Senior Database Developer a k tomu tři Junior Javascript Developeři. Jenže z pohledu Scrumu jsme byly všichni Team membeři a ti se dále nijak nerozlišují a mají stejnou roli. Takže jsem musel opakovaně vysvětlovat a obhajovat, že vytvořit několik DB tabulek není práce na hodinu ale na dva dny, protože to jsou tabulky, indexy, primární a cizí klíče atd. Nebo taky na týden, protože se musí nejdřív rozmyslet logický a fyzický datový model, protože vazby 1:n nebo n:m zásadně ovlivňují datový model. Výsledkem je hromada sql skriptů a když to člověk potřebuje spouštět opakovaně, tak taky musí dropnout databázi atd… Ano, dneska už máme (automatizační) nástroje od liquibase po docker, ale pořád je to nějaká netriviální práce. A taky jsem musel obtížně vysvětlovat, že je blbost dělat co DB tabulka to Jira task. Atd…
Vystřízlivění – alibismus místo zodpovědnosti
A hlavně, za druhé, v Agile/Scrumu má zodpovědnost team. To zní úžasně, jako že všichni jsou zodpovědní za výsledek. Mnohem častěji jsem ale zažil to, že se team membeři schovávali za team – to jsem nebyl já, to rozhodl team, já jsem říkal, že je to špatně, ale oni mě přehlasovali, atd… Takže místo kolektivní zodpovědnosti jsme skončili u alibismu. Což vyvrcholilo ve chvíli, kdy se poměrně vysoký manager od zákazníka zeptal – a kdo tohle rozhodl? A někdo (z teamu) odpověděl – team se rozhodl… Pohled manažera říkal v tu chvíli vše. Zvlášť, když nikdo z teamu neměl koule na to vysvětlit a obhájit ono rozhodnutí… Onoseto, samoseto …
Prostě tu zodpovědnost vůči uživateli a zákazníkovi někdo mít musí. Nejen funkčně ale i technologicky. Jenže scrum zná jen Product Ownera, Scrum Mastera a Team membery. Zodpovědnost by měl mít asi Product Owner ale (a to jsem zažil cca 10 projektů) ten v lepším případě věděl, co chce uživatel ale rozhodně nechápal věci jako product backlog a kontinuitu dodávek. A do toho ho mátli něčím, jako je MVP; jako nezlobte se na mě, ale prázdná aplikace, do které se přihlásím je možná MVP (za mě ne), ale nebudu ji ukazovat businessu…
Scrum master fungoval spíše jako dohled nad tím, co se děje, prostě lepší sekretářka, a nikdy pořádně nevěděl, vo co go… A je to za mě i celkem správně, to je jeho role, on není zodpovědný za řešení jako takové. Takže tu zodpovědnost nakonec měl (neformálně) některý team member, který to prostě vzal na sebe. Protože mu ten projekt nebyl lhostejný a měl k němu nějakou (osobní) vazbu. Vždy to ale bylo jeho rozhodnutí, ne rozhodnutí vedení. Jenže formálně byl řadový team member, takže neměl páku na zbytek teamu, takže to často spíše nefungovalo…
Agile je cajk, co Kanban místo Scrumu?
Je možné, že Agile je OK, ale problém je ve Scrumu, možná místo toho použít Kanban, říkali jsme si. No, zní to super, na boardu hned vidíme, co se děje, celý team dělá jednu/dvě věci, na kterou se soustředí. Ale jen do chvíle, než vám někdo řekne, že jste sice DB vývojář s desetiletou praxí optimalizace dotazů, jediný v celém korporátu, ale je potřeba namlátit CSS styly, protože tenhle ticket je ve skluzu. Ona by to sice zvládla i uklízečka, ale OK, pro jednou to člověk udělá, zvlášť když patří mezi ty, kterým na tom projektu záleží. Ale když to dělá opakovaně, tak začne pochybovat o smysluplnosti… Protože náklady, protože kvalifikace, protože … atd. Nejsem člověk, který by byl přesvědčený o své nadřazenosti a považoval některé práce za podřadné … ale musí to dávat celkově smysl.
Závěr
Tyhle a další zkušenosti vedly k mému postupnému vystřízlivění. Možná je to tím, že jsme dělali Scrum špatně. Možná se pohybuju ve velmi specifické doméně, nevím… Každopádně … dnes vlastně nevím, jak správně a efektivně řídit vývoj SW…
Ale opakuji … myslím si, že agilně letadlovou loď nepostavíte…