Team vyhrává když táhne za jeden provaz

Po svém posledním příspěvku o scrumu jsem měl v hlavě, že napíšu ještě jeden příspěvek, abych se vyjádřil jasně, proč považuji scrum za to nejlepší v metodikách vývoje. Je to právě jeho orientace na team a ne na jednotlivce. Na samoorganizující team (tj. organizace není určena z venku).

Ale pak jsem si poslech czpodcast č. 39 - Operations a Devops (hostem byl Radim Marek z Gooddata) a ten mé myšlenky posunul trochu jiným směrem. Omlouvám se, že podcasty poslouchám v opačném pořadí než vznikaly a navíc hodně zpětně, že si většina již nepamatuje co se v nich řešilo.

Nejprve se pochválím. Praktikujeme cosi podobného jako Devops a myslím, že se nám to osvědčilo. Vždy, když píšu v aplikaci logovací string, tak přemýšlím k čemu jej použiju a co chci, aby v něm bylo za informace. Kontakt se zákazníkem mi pomáhá přemýšlet o našem produktu v kontextu zákazníka nikoliv v mém.

Co mě ale vybudilo napsat tento článeček. Opět zaznělo něco co mi přijde logické. Tj. splynutí developerů a QA. A kritika byla, proč by měl drahý developer dělat testování, když tester je levnější. Argumentace Radima Marka byla do jisté míry správná, developer, který umí napsat automatický test a zárověn udělat performace testování je jistě lepší než ten co to neumí.

Ale proč nad tím přemýšlet na úrovni jednotlivých vývojářů a ne na urovni teamu (jediný důvod, kterému rozumím je ohodnocení členů teamu - výplata se dává jednotlivcům - ale koneckonců proč ji nedat teamu a nechat na něm její rozdělení mezi jeho členy - třeba by to fungovalo). Vývojář sám nic neudělá, team zvládne víc. Je důležité mít schopný team, který je složen tak, aby zvládl analýzu, návrh, vývoj i testování (v celé jeho šíři). Proč je to lepší? Team je na jedné lodi a táhne za jeden provaz. Nepřehazuje si horkou bramboru.

Pokud jeden člen neví jak dál s úkolem, který řeší, zeptá se kolegy, který to již dělal, nebo je zkušenější. Nikomu to nevadí, protože aktivita je stále vynaložena na úkol, který řeší celý team. Tj. je to aktivita pro dobro všech. Navíc se lidé vzájemně vzdělávají a roste jejich kvalita. Pokud ovšem sleduji, úkoluji jednotlivé vývojáře, dříve nebo později (čas je dán okamžikem, kdy se toto sledování využije k represivním krokům) přestane být pro jednotlivce zajímavé spolupracovat, protože neřeší to co mají, ale dělají něco co nemají (pomáhají kolegovi).

Pro mě je to celkem stejné jako rozdělení firmy na oddělení. Funguje to dokud jsou všichni na jedné lodi. Jakmile jsou oddělení dostatečně velká, že si zavedou samostatná účetnictví a "přefakturovávají" si vzájemnou práci, pak je spolupráce ta tam.

Závěrem. Scrum nabízí pohled na vývoj SW skrze team. Samoorganizující team, který je silně kooperující. To je prostředí, kde vznikají rychle dobré věci. V konkurenčním prostředí se rozvoj zpomaluje, protože se všichni ohlíží na konkurenci. Na vývoj SW už dávno nestačí jeden člověk je jich potřeba víc. Takže chceme, aby spolupracovali a ne si konkurovali.

PS. Teda to je pěkná všehochuť, snad z toho někdo něco pochopí ...

Neoprávněná kritika Scrumu v czpodcastu č.46: Kanban agilní vývoj

Poslouchám nyní zpětně czpodcast a při poslechu 46. dílu s názven "Kanban agilní vývoj" zazněla, dle mého soudu, neoprávněná kritika na adresu scrumu.

Na úvod je nutné si otevřeně říci, že scrum není pro každého. Splnit podmínky pro vývoj pomocí scrumu není úplně triviální, ale pokud se to povede ovoce přinese. Druhá, velmi důležitá věc, je najít kvalitní zdroj, odkud vědomosti čerpat. Existuje spousta knih o scrumu, které jsou zavádějící a nebo špatné. V ideálním případě je vhodný konzultant, který nám poradí, jak scrum správně implementovat v našem konkrétním prostředí. Já žádného dobrého českého konzultanta neznám (rozuměj nemám jej prověřeného), ale účastnil jsem se školení na ScrumMastera s Borisem Glogerem, který mě jednoznačně přesvědčil, že tím schopným konzultantem. Svému řemeslu i scrumu perfektně rozumí.

A nyní již k obsahu podcastu. Prvním jasným signálem, proč scrum nemůže v GoodData fungovat je oddělení QA od vývoje. Scrum si vynucuje existenci tzv. universálních týmů. Tj. z týmu co sprint vypadne funkční plně otestovaný produkt doplněný o nové položky z backlogu. Pokud máme oddělené QA od vývoje, pak z týmu vypadne cosi, ale není to funkční produkt. Kde je probém? Myslím, že si Jaroslav odpověděl sám. Není známa velocita teamu. Team sice doplní produkt o položky (featury) v obtížnosti např. 100, ale v další iteraci je opravuje a spadne mu velocita na 60. Proto musí být universální teamy, aby to co je jejich výsledkem bylo funkční a plně otestované a vědělo se přesně jakou mají velocitu (ta se po několika prvních iteracích ustálí). Velocita pak pomáhá předpovídat, kolik team udělá položek backlogu za definovaný čas.

Dalším problém, který byl zmíněn je vynucování si, aby univerzální teamy nebyly moc veliké, řádově deset členů (i méně). Pokud máme vývojářů víc, pak je rozdělíme do více teamů a je samozřejmě možné udělat, aby pracovali "skoro" nad jedním backlogem.

V podcastu zaznělo, cosi o zarovnávání položek do sprintu a výběr menších položek z backlogu "mimo" prioritu. První jsem slyšel prvně až v podcastu a druhé je naprosto špatně! Team si na začátku sprintu z backlogu vybírá, striktně podle pořadí v jakém jsou uvedeny, položky, které bude realizovat. Chybou je mít položky tak velké, že např. zvolím první, druhou už zvolit nemohu, protože bych ji nestihl, ale první mě zaměstná pouze na 2/3 sprintu. Nikde ovšem není řečeno, že pokud má team velocitu 30, pak si musí vybrat položky v úhrnné složitosti 30, může si zvolit stejně dobře 27, jako 31.

V neposlední řadě zaznělo, že se jim v GoodData položky špatně odhadují, protože dělají nové věci a u nich člověk nikdy neví. Může to být do jisté míry pravda, ale co je na scrumu kouzelné je to, že u položek v backlogu se neodhaduje jejich pracnost, ale pouze jejich složitost a to ještě poměrově mezi sebou. Používá se k tomu technika planning poker, kdy jednotlivý členové ohodnocují položky složitostí pomocí kartiček s hodnotami 1, 2, 3, 5, 8, 13, 20, 40, 100. Na této technice je úžasné, že porovnat dvě věci mezi sebou a říci, která je složitejší a jak moc nám jde velmi dobře a jsme až překvapivě hodně přesní (na rozdíl v odhadování kolik to zabere času).

Z mého pohledu je závěr spíš, že scrum v GoodData neměli vůbec používat a navíc jej používali špatně a proto jim nefungoval. Tedy jednoznačně není chyba na jeho straně. Osobně se domnívám, že scrum je nejlepší metodika, kterou máme v současnosti k dispozici, ale bohužel, není pro každého.

Byl jsem na Scrum Master Training

A stal jsem se certifikovaným Scrum Masterem.

O tom, ale nechci psát, chci psát o tom jak moc bylo toto školení prospěšné a co vše mi přineslo. Školení vedl Boris Gloger, který se ukázal jako perfektní přednášející. Přednášenou oblast dokonale zná, nejenom z již uskutečněných školení, ale i z praxe. Navíc jeho skušenosti se zaváděním Scrumu byly hodně veliké, takže na jakoukoliv otázku byl velmi promptně připraven odpovědět a vždy si věděl rady. Opravdu perfektní školitel.

Školení bylo dvoudenní a konalo se na jihu Čech. Provedlo nás postupně všemi částmi Scrumu, které se Scrum Mastera týkají, o všem jsme si příjemně popovídali a řadu věcí jsme si díky šikovně vybraným cvičením i vyzkoušeli.

Co si ze školení odnáším? Především jde o to, že Scrum Master ze mě zatím nebude, protože vývoj softwaru mám moc rád a hodně těžko bych se bez něj obcházel. A Boris striktně nedoporučuje, aby Scrum Master byl zároveň vývojářem, protože Scrum Master má za úkol podporovat a chránit team před okolními vlivy a to by zároveň jako vývojář nemohl dělat na 100%.

Dále jsem si odnesl velmi důležitou část Scrumu a to: čím více jsou lidé z teamu zatáhnuti do možnosti určovat si práci, rozhodovat o ní jak ji udělají a kolik ji udělají (kolik stihnou udělat za následující sprint), pak se o to více snaží, aby to co slíbili také zvládli. Pokud to rozhodne někdo za ně, pak nebojují za svou čest, ale za čest někoho jiného a to se bojuje podstatně laxněji.

To jsou hlavní poznání, které mi školení přineslo. Pak jsem si ještě odnesl pár drobností: neohodnocovat požadavky (Story) pomocí člověkodnů, ale pomocí bodů (díky tomu, že se určí kolik bodů je schopen team zvládnout za jeden sprint, ví se kolik udělá požadavků), skvělá je metodika ohodnocování složitosti požadavků (opět to dělá team pomocí Planning Pokeru), team v jeden okamžik vždy pracuje na jednom požadavku (aby byl software co nejméně rozvrtaný a aby si vzájemně pomohl, protože chce mít požadavek co nejdříve hotový) atd.

Vřele všem podobné školení doporučuji, i když nehodláte být Scrum Master, ani nehodláte vyvíjet software podle Scrumu. Proč? Protože chytrých nápadů je ve Scrumu spousta a spousta se jich dá použít.