Agilní bullshit

Tomáš Jecha, MVP, MCSD       21.02.2019             2423 zobrazení

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.

 

hodnocení článku

0       Hodnotit mohou jen registrované uživatelé.

 

Nový příspěvek

 

Příspěvky zaslané pod tento článek se neobjeví hned, ale až po schválení administrátorem.

úpadek původních myšlenek agilního vývoje

Bohužel z toho mám ten samý pocit. Nejvíce mi však vadí, že na původních hodnotách, které agilní vývoj představoval v 50 - 70 letech se v novodobém pojetí prakticky nic nedochovalo a všichni tlačí agilní vývoj do různých frameworků, namísto toho aby se soustředili na disciplínu, pečlivost a vzdělání lidí.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jak reprezentativní je tento "typický obraz" agile implementace

Z kolika projeků vychází tento obraz? Pokud je to z nějakého většího vzorku, pak je to značně depresivní.

By mě zajímalo zda se se stejnou mírou nepochopení přistupuje i k dalším "trendům" jako TDD, DevOps, ...

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Z kolika? Odhadem jsem měl možnost za poslední roky vidět více do cca 10+ týmů používající agilní metodiky. U ostatních týmu je to z doslechu. Ono to není ale černobílé. Někde je agilní transformace opravdu užitečná. Jinde to vyloženě vývojáře brzdí a hází jim klacky pod nohy. A jsou určitě týmy, které jsou na metodiku tak zvyklí, že by jim jiný způsob práce nevyhovoval.

TDD je obvykle rozhodnutí architektů nebo vývojářů jako reakci na konkrétní problémy - pokud zjistí, že to nenaplnilo očekávání, tak se obvykle nic neděje a jen se přestane dodržovat. DevOps může být bullshitováno konzultanty, ale v žádném týmu jsem ze špatného uchopení DevOps pachuť neměl. Problém s agilní transformací je, když je do firmy prodán managerům jako způsob řízení týmů. Je pak v zájmu agilních koučů a scrum masterů, aby nikdo neměl pocit, že by to šlo bez nich nebo že to neudělali dobře. Rozhodně tím nechci hanit ty, kteří dělají jejich práci skvěle - neplatí to v žádném případě o všech.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Martin

Agilní přístup k vývoji neimplikuje nic z toho, co mu vytýkáte jako jeho nedostatky. A těch zjednodušení a zkratek je tu tolik, že se v podstatě s ničím z uvedeného nedá polemizovat.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Já nevytýkám nic agilnímu vývoji, ale typickému obrazu jeho implementace.

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

Příspěvky zaslané pod tento článek se neobjeví hned, ale až po schválení administrátorem.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback