21. března 2011

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.

7 komentářů:

Anonymní řekl(a)...

Scrum je nejlepsi metodika vyvoje, ale GoodData by ji nemeli pouzivat... a duvody?

Jira řekl(a)...

Proč? Protože nesplňují všechny požadavky nutné pro to moci scrum nasadit tak, aby fungoval. Věc, kterou by museli změnit je QA oddělení rozpustit do vývojových teamů a je otázka, zda toto chtějí udělat. Všechno ostatní jsou chyby, které se dají odstranit ...

Anonymní řekl(a)...

Poker IMO skutecne nepomaha s vecmi, kde clovek _nevi_, jako treba "vem tuhle novou technologii, tenhle novy algoritmus a udelej s nim tuhle novou vec". Tam IMO skutecne plati interval 5-100...aspon takova je moje zkusenost.

Jira řekl(a)...

Pak se ovšem bavíme o prototypingu a to je jiný šálek kávy. Ten se v podstatě integruje tak jako změna infrastruktury. Tj. team má svaté právo, které mu nikdo nemůže vzít a to je kdykoliv se rozhodnout, že je potřeba něco změnit. Z backlogu si vezme méně práce a jisté penzum své práce věnuje na změnu infrastruktury (nebo fixování bugů). podobně se to řeší s prototypováním ...

Myslím, že je lepší si technologii ošahat na nějakém prototypu, případně v hackathonu a pak ji teprve použít v produktu ...

filemon řekl(a)...

ad prototypovani: Na to se presne IMO Scrum vubec nehodi. Scrum funguje dobre pri usazene architekture/typizovane aplikaci, kdy se vicemene soustredim pouze na business logiku.

Kanban zkousime v JetMinds taky a Scrum mi proti nemu prijde jako waterfall (no flame, waterfall nemusi byt nutne zlo jak ostatne ve zminenem podcastu take padlo).

Jira řekl(a)...

filemone to budeme muset probrat osobně, protože mě to absolutně není jasný, proč by na to scrum nešel použít, já to tam nevidím. A tady akorát na sebe budeme házet tuny slov a nic z toho ....

Jira řekl(a)...

Ještě jedna věc mě napadla ... na Kanbanu se mi nelíbí orientace na jednotlivce. Na scrumu se mi líbí orientace na team. Team si rozhodne, co a jak uděla, team se zaváže, že to udělá, team to otestuje ...

Já v tom cítím obrovský rozdíl, není potřeba mít super lidi co zvládnou všechno (od návrhu po deployment), ale stačí mít super teamy ...