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.

Inovace bez legrace aneb máme se snažit vymýšlet něco nového a nebo jenom přebírat dané

Dneska se snad poprvé pustím do polemického příspěvku, který na první pohled je o vývoji softwaru ryze okrajově, ale mám takový pocit, že musím ...

Jaká je motivace pro tento příspěvek. Nejprve jsem si přečetl Lukášův Jak nepsat framework, který ve mě zanechal jistou pachuť, ale nevyprovokoval mě k ničemu, ještě jsem nevěděl ...

Pak se mi dostaly do ruky hodnocení prezentací pořádaných na MFF od studentů, kteří je shlédli. A to mě nakoplo, protože jedno hodnocení mé přednášky bylo:

Co se tématu týče, tak na mě to působilo dojmem, že pan Mareš přistupuje k Softwarovému inženýrství dost osobitým způsobem. Přišlo mi, že přednášejícímu je upřímně jedno, jak to či ono realizují v kvalitních společnostech typu NASA, DoD a podobně. Dokonce mi přišlo, že jeho postoj je, že on sám je opravdu chytrý a že to co vymysleli pánové stavějící rakety dvacet let před ním, nestojí za to řešit. Tedy že to všechno on sám už vymyslel a prověřil praxí.

Bezpochyby toto hodnocení ukazuje, že nejsem výborný prezentátor, spíše podprůměrný, protože pokud má přednáška na někom zanechala tento dojem, pak jsem to nezvládl. Naopak myslím, že podporuji iterativní způsob vývoje SW, který se osvědčil právě v NASA a v DoD (Department of Defence) již před více než 30 lety a favorizují iterativní způsoby vývoje na úkor vodopádu (konkrétně favorizuji Scrum).

Ale o tom také nechci psát. Co mají tedy tyto příspěvky společného? Otázku: Máme vymýšlet (vyvíjet) něco vlastního nebo jenom přebírat již existující?

Já si myslím, že není problém vymýšlet něco nového, zkoušet zda to funguje, to je naprosto v pořádku a znamená to MOŽNÝ pokrok. Takže není chyba, pokud někdo napíše vlastní framework nebo vymyslí vlastní způsob práce, to je naprosto v pořádku. Otázkou je, zda je tak geniální, že vymyslí něco prospěšného i pro ostatní a nebo zda to je nějaký nesmysl, který funguje pouze pro jeho zvrácený případ.

Chybná je jiná věc. Chybné je neumět si přiznat, že jsem udělal chybu a držet se dál toho nesmyslu co jsem vymyslel ... a v ideálním případě komplikovat život mnoha dalším lidem. Není špatně vyvinout vlastní framework, pokud se mi podaří někoho přesvědčit, že to je dobrý krok a dostanu na to peníze (nebo to udělám ve svém volném čase). Špatné je, pokud od začátku tvrdím, že se to povede a bude to úspěch a pokud nakonec, když se to nepovede, tak to nepřiznám.

Težko bychom, pokud by se nenašli dostateční "šílenci", dneska měli Hibernate, Spring, Groovy, Tapestry atd. Ovšem kolik je těch projektů, které se nezrealizují a nebo neprosadí? Podstatně více, to je nutno si přiznat. Ale vždyť sama evoluce se řídí přístupem "pokus vs. omyl", úspěšné přežije na úkor neúspěšného, takže proč ne my.

Takže nebojme se vymýšlet nové věci, ale buďme soudní a silní si přiznat, že se nám to nepovedlo. V ideálním případě je veledůležité zpublikovat svůj neúspěch stejně jako (možná víc než) úspěch, aby se i ostatní mohli poučit z naší chyby ...