Čím více chodím po firmách, tím více docházím k tomu, že existuje jasná rovnice. Čím striktněji nadefinované máte procesy, tím méně je ve firmě inovace, otevřenosti, důvěry, motivace, iniciativy, spolupráce. Lidé sedí a čekají, až dostanou úkoly. Bojí se ozvat, starají se jen o to, jak naplní metriky. Produktivita klesá, a čím více klesá produktivita, tím více metrik vzniká. Co neměřím, to neřídím.
Agilní metody to dělají jinak. Místo striktního procesu jen vymezují hřiště. Definují týmům i jednotlivcům pouze mantinely, které by se neměly překračovat. Už jen agilní manifest. Neříká takhle přesně vypadá/nevypadá dokumentace, ale “upřednostňujeme funkční produkt před vyčerpávající dokumentací“. Tedy jediné co říkáme je, že “je to o produktu, ne o dokumentaci“. A nepřímo i to, že dokumentace je důležitá, ale komunikace je důležitější. Tedy, určitě dokumentaci dělejte, ale asi není třeba ji mít sepsanou do posledního detailu, sepište jen to, co opravdu bude někdo potřebovat. Zdánlivě tedy neradí nic. Je to common sense. Selský rozum. Na ten jsme ale při našem pracovním vytížení často zapomněli. Agilní procesy nás vrací tam, kde jsme kdysi byli. Tam, kde věci fungovaly i bez detailních metrik a přesně definovaných procesů.
Jak takové metriky často vypadají? Pár historek pro příklad z poslední doby…
Počet řádek kódu. Ta patří k mým oblíbeným. Musíme přece vědět, který vývojář je lepší než ten jiný. No ne? Jak bychom to jinak zjistili? A jak bychom docílili toho, že vůbec něco dělají. Tedy důvěra: nula. Spolupráce: ani vzniknout nemůže. Protože pak bych kolegovi pomohl k lepší výplatě, což o to, ale sobě tím pádem k horší…
Počet testů, pokrytí testy. Zdánlivě smysluplná. Ale jak jistě testeři potvrdí, zcela nevypovídající. Tedy končí tunou testů. Test máme na všechno, co jde. Obzvláště na ty jednoduché věci. Tam počet přibývá nejsnáze. A protože testování nikdo kromě testerů nerozumí, jediné, co manager honí, je procento pokrytí. A má dobrý pocit, že roste. Jenže ty testy musí někdo udržovat, a to stojí energii. Zbytečně investovanou hned dvakrát. Jednou u vzniku testu, který není až tak klíčový a podruhé opakovaně při libovolné změně systému. Cílem firem, které to pochopily, již dávno není 100% pokrytí testy, ale funkční produkt. Psát jen ty testy, které mají pro nás smysl a potřebujeme je.
Počet reportovaných chyb. Zdánlivě správná metrika. Když ale přitvrdíte, a začnete ohodnocovat testery podle počtu nalezených chyb a vývojáře podle stejného počtu penalizovat, dojdete k tomu, že tyto skupiny mají zcela odlišné cíle. A to, že by spolupracovaly již v průběhu na kvalitním vyřešení User Story je v nedohlednu. Jen ať tam ty chyby udělají. Alespoň je snadno najdeme. A z druhé strany tento přístup generuje nekonečné a často úspěšné diskuse typu: “ne,ne,ne, to není chyba, tu já jako vývojář neakceptuji, to je change request, nebo chyba testu, ale rozhodně ne chyba kódu. Kdepak.“ Frustrující.
Čas na dokončení tasku. Obvyklá věc, že? Jak jinak byste věděli, jestli závazek ve Sprintu stihnete nebo ne? Potřebujete mít přeci jistotu! Ale ono to nikam nevede. Jistota je jen pofidérní. Navíc, takové výpočty stojí spoustu času, který by šel smysluplněji investovat jinak. Stačí přece práci rozdělit na menší kusy a ty přehledně zobrazit na tabuli. A vnímat funkcionalitu jako celek. Ne jako jednotlivé části. Příště o tom napíšu víc.
Sprint Burndown. Obdobně zbytečný jako reportovat čas potřebný na dokončení tasku. Když k němu přidáme tlak na to, aby vypadal “pěkně“, často dojdeme k tomu, že tým reportuje za každý den 8h*počet členů. Tolik času jsme přeci na táskách strávili, ne? Graf má krásný lineární průběh, ale vypovídající schopnost je nulová.
Velocity musí být nějaké konkrétní číslo. Třeba řekněme 22. Jinak tým funguje špatně a málo toho udělá. No tak proč ne, stačí říct a my budeme ještě lepší. Prostě jen začneme ohodnocovat User Stories jinak. Nebo rovnou celý Backlog vynásobíme 100. Jo, to že nesmíme? No tak jo, ale ono se to za nějaký čas objeví na kvalitě. Technický dluh je moc príma. Jeho odstranění je ještě dražší, než to, že si dáte pozor, aby nevznikl .
A pokračovat bychom mohli dalšími složitostmi, jako detailními výkazy o tom, co kdo přesně kterou minutu dělal, nebo kvótou na počet business bodů, které tým musí doručit. A přitom nic z toho není potřeba. Nevěříte? No těžko vás budu přesvědčovat takhle od stolu. Zkuste to. Zeptejte se firem, co to dokázaly.
Obecné doporučení je, že je dobré něco měřit, ale libovolná metrika musí být jen indikátor, ne cíl, pravidlo, modla. Nelíbí se vám velocity? Mysleli jste si, že by tým toho měl doručit více? No tak se podívejte čím to je. Najděte příčinu, ne důsledek. Libovolné tvrdé metrice se tým přizpůsobí a upraví své chování tak, aby metrika vyšla. Některé firmy je proto často mění, aby to týmy nestíhaly. Jiné pochopily, že o problémech je dobré vědět, a jsou rády, že je pomocí soft metrik vidí.
Druhá rada říká, nebabrejte se v detailech. Stojí moc energie a ztratíte se v nich. Všechno je vidět z jednoduchých trendů. Obvyklé věci se totiž dějí obvykle, výjimečné výjimečně. A na velkých číslech, jako je např. velocity za tým a sprint to vychází. I těch neobvyklostí nám za tým a Sprint přijde pokaždé stejně. Jedna User Story byla podhodnocená, jiné dvě nadhodnocené, jeden onemocněl, dalšího bolela hlava, někomu to zas výborně šlo od ruky. Tedy, když přestanete řešit detail, jako je počet hodin na tasku, ale podíváte se jen na velocity, dozvíte se z trendu přesně to, co potřebujete.
Tvrdé metriky a detailní procesy zabíjí tvořivost, inovace, náladu. Končí tak, že produktu nikdo nevěří, z těch úžasných vývojářů, analytiků a testerů, co mnohdy mají několik titulů a jsou nadprůměrně inteligentní, se stávají dělníci u pásu. Zombie bez energie. Udělejte si test. Zeptejte se vašich zaměstnanců, proč pracují. Ti, co jsou tam jen pro peníze, berou práci jen jako nutné zlo. Hlídají si spokojeného šéfa a metriky. Schovávají se za procesy. Vymlouvají se. Jak malé děti. Děláme přece přesně to, co řeknete. Tak nás nechte, a plaťte nám. My máme hypotéku. Uvidíte nás tu maximálně od devíti do pěti, a když tu není šéf, tak jen do čtyř. Přesně podle pracovní doby. Ti druzí, u těch je na prvním místě práce, která má smysl, svítí jim očička, jak tuhle říkal jeden jejich manager. Zajímají se, jsou schopni se zdravě pohádat o řešení, nebojí se říct svůj názor. Mají společný cíl. A tím není mít víc peněz. To je důsledek jejich přístupu, který zákonitě přijde. Kde byste chtěli pracovat vy?
Agile tohle prostředí mění. Mohlo by se sice změnit samo, i bez agilních přístupů, ale často je k tomu nějaký nový label potřeba. Překvapivě, velká část týmů, které dnes coachuji, řeší přesně tento problém. Výhodou je, že že změna přichází rychle. Nabaluje se to jak sněhová koule. Přitahuje to. Ale začátky jsou obvykle o to více bolestivé.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Tak pod to se podepíšu!
Naprosto přesně to je u nás. Změna na SCRUM se zrychluje. Ale některé staré zvyky a procesy stále odolávají.
Je to boj. Ale ono to půjde.
P.
Tuhle jsem nad temi metrikami taky premyslel a vzpomnel jsem si na Heisenbergovi relace neurcitosti (cim presneji zmerim polohy, tim nepresneji zmerim hybnost, nebo jeste obrazneji cim pevneji sviras castici v hrsti, tim je neklidnejsi a chova se bourliveji). Pak dava to, cos psala, jeste o chlup vetsi smysl :).
Souhlasim – uz temer rok odmitam zavadeni metrik pro mereni vykonu do projektovych teamu – jednak je to nic nerikajici a druhak je to podle selskeho rozumu deformujici. Verim tomu, ze bych jedenkrat rozdal bonusy na zaklade nejake metriky a priste by vsichni delali cokoliv pro metriky misto pro projekt a jeho dobro.
JJ, souhlas. Až na to “Uvidíte nás tu maximálně od devíti do pěti”. Tedy jsi asi myslela zákonnou pracovní dobu 8hod (tedy včetně oběda 8-17 hod)? Což je ovšem správné, přesčasy jsou známkou problémů.
Pokud jsi myslela šizení pracovní doby, tak to je na vyhazov bez debat. Ať jsou procesy jakékoliv.
Také souhlasím. S těma metrikama se musí fakt opatrně, tady určitě platí, že méně je někdy více 🙂 A největší průšvih je, když metriky vyjadřující nějakou vlastnost zdrojového kódu (LOC, coverity, atd.) se začnou aplikovat při hodnocení výkonů lidí. Jakmile lidé zjistí, že jsou hodnoceni podle nějakých metrik, tak se začne vytrácet podstata věci a začíná honba jen za lepšími čísly. Je to přirozená reakce – a každý manažer, než se pustí do takového měření by si měl toto uvědomit. Co se týče Agile, tam bych své nadšení také spíše krotil, protože už jsem byl v minulosti svědkem takového způsobu uchopení Agile, že to vlastně s Agile nemělo vůbec nic společného a zase to skončilo u honby za nicneříkajícími metrikami 🙁 Nakonec vždy skončíme u toho, že je to celé jen a jen o lidech a jaký si to udělají, takový to mají. 🙂
Tou pracovni dobou mi slo spise o pristup – odsedim si sve bez ohledu na praci. Jak rika i XP, odpocinek prinasi kvalitu, takze zadne prescasy. A tim nemyslim, ze nekdy pracujete vic, jindy naopak min. To beru za standard.
“What’s measured improves”. ― Peter F. Drucker
Souhlasím s tím, že blbé metriky jsou blbé. Nezdá se mi ale, že tím pádem žádné metriky jsou ideální. Co kdybychom dokázali najít/nadefinovat DOBRÉ metriky?
Co odpovíte panu Druckerovi?
Ja bych jen opakovala, ze pan Drucker to tak jak na me vzdy pusobil ty metriky nebral jako dogma ale indikator. A v tom to je. Navic, Drucker byt na spicce trendu v managementu v polovine minuleho stoleti. Kdy management vypadal zcela jinak. Dnes se meni styl rizeni i v tovarnach a vyrobnich halach – smerem k tymu a odklonu od procesu.. Ale o tom zase priste neco pekneho napisu 🙂
Asi cokoliv jde pouzit jak ke zlepsovani tak k terorizmu vlastnich zamestnancu. Rozhodujici je, jestli citime zodpovednost u sebe, nebo ji valime na ostatni.
Ja mam metriky celkem rad. Kdyz se pouzivaji spravne, stava se z rizeni veda nikoliv alchymie. “Spravne” pouziti je IMHO jako system vcasneho varovani, nikoliv jako vyhodnocovani produktivity.
Vyse popsane metriky lze pouzit taky napr. takto:
SLOC -> indikator kvality designu. Prilis mnoho SLOC znamena prilis mnoho prace s udrzbou. Pojdme se zamyslet, jestli neco nejde zjednodusit nebo smazat.
Test coverage -> indikator kvality designu. Pokud to nejde dobre testovat, je kod malo ohebny, dalsi feature nas pravdepodobne bude stat vice penez.
Reported bugs -> indikator rovnovahy vyroby a odchytavani chyb. Docela jednoduche – nedelejme vice problemu nez jsme schopni vyresit 🙂
Time to deliver -> indikator pruznosti procesu. Jak rychle dostaneme zpetnou vazbu a jak rychle jsme schopni se prizpusobit?
Burndown -> OK, tohle jsem nikdy nemeril, takze nemam poneti, jak to pouzit. Ja mam radeji kratsi iterace, kde lze kompletne preplanovat, nez dlouhe “sprinty” a “burndown”.
Velocity -> indikator “sustainable pace”. O tomto se da napsat asi cely referat ale v zasade: jsem schopen dlouhodobe pracovat stejnym tempem?
Nevím, jestli je to tak myšleno, ale článek mi vyznívá dost černobíle – buď tvrdé metriky, nebo “správný” agilní přístup. Myslím, že 95 % projektů je někde mezi tím.
Osobně jsem se za ta léta s “tvrdým” přístupem k metrikám nikdy nesetkal. Ani z doslechu. To používají v ňáké fabrice někde v Indii? 🙂
Nijak bych metriky (a procesy) nedémonizoval. Je to jenom nástroj, jak něčeho dosáhnout. Tvrzení, že deformují lidi, mi přijde dost silné (a ne dobře zargumentované). Já bych viděl spíš problém v tom, že lidi neumějí procesy/metriky naimplementovat a používat.
Každopádně je vidět, že téma je komentované, takže k vyprovokovalo k diskuzi. A to je dobře.
@pht krásně řečeno, vidím to stejně.
Naprosto souhlasím s @pht a @Guido. Článek mi přijde hodně černobílý, napsaný na “vlně jménem Agile” a upozorňující na stav, který se v praxi vyskytuje ojediněle. Idealizovat si pracovní morálku pracovníků (přinejmenším z dlouhodobého pohledu) a doufat, že “to bude, až to bude, však to nějak dopadne” je z druhé strany také extrém.
Ja se s tim co jsem popisovala setkavam velmi casto. Bohuzel. V Cechach a na Slovensku. Ve velkych korporatech i malych firmach…. ale to jen na okraj 🙂
Nevim jestli ma smysl opakovat znovu to co rikam – ale presne jak pisete – “lidi neumějí procesy/metriky naimplementovat a používat” – aby k necemy byly, maji je brat jako mantinely a indikatory. Ne jako tvrde a nemenne veci. 🙂 A to prave agile dela (nejenom agile samozrejme, ale o tom ostatnim svete tu vetsinou nepisu. Zameruji se na to co umim dobre a cemu rozumim – tedy na agile)
Mit vlastni nazor a stat si za nim neni cernobile :))))
Nejen metriky, ale i agile přístup jde dělat blbě 😉 Nakonec jde vždy jen o to, nevylévat s vaničkou i dítě.
Muj komentar nebyl myslen jako kritika clanku. Souhlasim i s tvrzenim, ze v nasich zemich jsou metriky plne antipatternu (ostatne jako i samotne rizeni lidi 🙂
Jenom mi proste k tem vsem “negativnim” prikladum chybely i nejake “pozitivni”.
mnojo, jak rikam, napr. velocity je vynikajicim indikatorem zdravosti tymu, spoluprace, nasazeni. Je z ni mnoho videt. Az do momentu, kdy nekdo rekne ze “velocity musi byt 60 +- 10%” …. a mame po ukazateli….