ScrumBan pro malé a střední firmy

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY ScrumBan pro malé a střední firmy Diplomová práce Andrey Chekhlov Brno, jaro 2014

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Brno, 26. května 2014 Andrey Chekhlov Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D. i

3 Poděkování Chtěl bych poděkovat vedoucímu mé diplomové práce RNDr. Jaroslavu Ráčkovi, Ph.D. za vstřícný přístup, rady a za čas, který mi věnoval. ii

4 Shrnutí Práce popisuje principy agilního vývoje softwaru a uvádí jejich výhody oproti rigoróznímu přístupu. Zaměřuje se zejména na metodiky Scrum, Kanban a ScrumBan. Na základě analýzy malých a středních firem byla vybrána vhodná metodika pro jejich IT projekty. V praktické části je přiveden podrobný popis nasazení této metodiky. iii

5 Klíčová slova Agilní metodiky, scrum, kanban, scrumban, malé a střední firmy iv

6 Obsah 1 Úvod Agilní metodiky vývoje softwaru Scrum Scrum role Scrum artefakty Scrum činnosti Scrum deska Kanban Základní principy kanbanu Základní praktiky kanbanu Deska kanban Kanban vs. scrum Scrumban Principy scrumbanu Kanban vs. ScrumBan vs. Scrum Malé a střední firmy Podnikové řízení Organizační struktura Výhody MSP Nevýhody MSP Návrh metodiky pro malou firmu Popis metodiky Nástroje pro práci s metodikou Formuláře pro jednotlivé fáze metodiky Nasazení metodiky Popis projektu Představení společnosti Sestavení backlogu První iterace Plánovací schůze Den první Den druhý

7 8.4.4 Den třetí Den čtvrtý Den pátý Review mítink Druhá iterace Plánovací schůze Výsledek nasazení Zhodnocení Závěr

8 Kapitola 1 Úvod Malé a střední podniky (MSP) jsou podstatnou součástí ekonomiky České republiky. Nezastupitelnou rolí MSP je poskytování šance pro svobodné uplatnění občanů k samostatné realizaci lidí v produktivním procesu. Lidé v těchto podnicích jsou nuceni k zodpovědnosti, protože jakýkoliv omyl pro ně může znamenat konec a důsledky neúspěchu nesou osobně. Flexibilita, neboli schopnost rychle se přizpůsobovat měnícím se skutečnostem, je jedním z nejcennějších charakteristických znaků malých a středních podniků. Neustálé trendy globalizace se promítají také do ekonomického sektoru a dochází ke vzniku a rozvoji multinárodních korporací a řetězců. Malé a střední podniky působí proti tomuto posilování monopolních tendencí. Díky své rychlé adaptaci na měnící se prostředí a potřeby zákazníka jsou malé podniky nositeli nesčetných drobných inovací. MSP také dokážou působit v okrajových oblastech trhu, které jsou pro větší podniky méně atraktivní. Tato diplomová práce je zaměřena na analýzu použitelnosti agilních metodik projektového řízení pro střední a malé IT firmy. Cílem je nasadit vhodnou metodiku ve vybrané firmě a provést analýzu její přinosu pro daný podnik. Práce je členěna do několika tématických částí. Nejprve obsahuje úvod do agilních metodik projektového řízení, představuje popis vybraných metodik a zabývá se charakteristikou a specifikou malých a středních firem. V dalších částech se přivádí návrh metodiky pro malou IT firmu a její demonstrační nasazení. 3

9 Kapitola 2 Agilní metodiky vývoje softwaru Agilní metoda vývoje software přišla jako přirozená reakce na přesun software z velkých výpočetních center do každé firmy a každému na stůl. Místo velkých týmů se objevilo nesčíslně malých skupinek, zkušenosti i opensource kód se začal po internetu vyměňovat dříve netušeným způsobem a to přineslo i změnu myšlení. Základem agilního přístupu je úzká spolupráce programátorů s cílovými uživateli systému. Dotaženo do extrému, uživatelé se na vývoji přímo podílejí, protože jako součást vývojového týmu programátorům poskytují okamžitou zpětnou vazbu a spolupracují při všech fázích vývoje. V rámci řízení projektu je hlavní změnou přístupu ochota kdykoli přistoupit na změnu zadání a řešení předělat, když se objeví nový nápad, jak problém řešit a jak potřeby klienta naplnit. Vše poměrně pěkně popisuje Manifest agilního programování [15]. Základní hodnoty agilního vývoje software: jednotlivci a interakce před procesy a nástroji; fungující software před vyčerpávající dokumentací; spolupráce se zákazníkem před vyjednáváním o smlouvě; reagování na změny před dodržováním plánu. Je nutné si uvědomit, že doslovné přijetí těchto hodnot je častým problémem. Nemusíte to chápat ve smyslu, že agilní metodiky vůbec nepotřebují tvořit dokumentaci. Je třeba stále počítat s nutností vykonávat činnosti, které se týkají pravé částí těchto bodů, i když v mnohdy značně omezené míře. Dvanáct principů agilního vývoje softwaru [15]. 1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru. 4

10 2. AGILNÍ METODIKY VÝVOJE SOFTWARU 2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. 3. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody. 4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu. 5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci. 6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. 7. Hlavním měřítkem pokroku je fungující software. 8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale. 9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. 10. Jednoduchost umění maximalizovat množství nevykonané práce je klíčová. 11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. 12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti. Obrázek 2.1: Tradiční vs. agilní metodiky Z principů agility je zřejmý odklon od principů tradičních metodik. Důraz je kladen na spokojenost zákazníka a to hlavně tím, že nemusí dlouho 5

11 2. AGILNÍ METODIKY VÝVOJE SOFTWARU čekat na výsledky, ty jsou mu dodávány v průběhu několika prvních iterací. Během dalších fází vývoje díky neustálé spolupráci managementu se zákazníkem a reakci na změny v požadavcích se zvyšuje stupeň spokojenosti s tím, že finální produkt bude souhlasně přijat. Pro tradiční metodiky platí : Implementujeme pro dnešek, navrhujeme pro zítršek. Pro agilní metodiky platí : Implementujeme pro dnešek, navrhujeme pro úspěšnou implementaci. 6

12 Kapitola 3 Scrum Co to je scrum? Scrum to není zkratka, to je termín z ragby, který znamená boj kolem míču. Sám termín je možné určit jako metodologie projektového řízení, která je založena na principech time managementu. Hlavní specifičností je zapojení do procesu všech účastníků, přičemž každý účastník má svou roli. Základ je ten, že ne jenom tým pracuje nad úkolem, ale všichni, kdo má zájem o dosažení cíle. Obrázek 3.1: Popularita agilních metodik Scrum je jedna z nejpoužívanějších metodologií a to je hlavně díky své jednoduchosti. Jednoduše řečeno scrum je to 3 role, 4 nebo více artefakty a 4 nebo více činnosti. 3.1 Scrum role V metodologii scrum jsou jenom 3 základní role: Vlastník produktu(product owner) Scrum master Tým(Team) 7

13 3. SCRUM Obrázek 3.2: Základ Scrumu [8] Vlastník produktu Vlastník produktu je to reprezentant strany zákazníka a člověk odpovědný za vývoj produktu. Vlastník produktu je jediný konečný bod rozhodnutí pro tým v projektu, a právě proto je to vždy jeden člověk a ne skupina nebo výbor. Funkce vlastníka produktu: je zodpovědny za formování vidění produktu; řídí ROI(Return on investment); řídí očekávání zákazníka a všech zainteresovaných stran; koordinuje a prioritizuje Backlog produktu; poskytuje týmu srozumitelné a testovatelné požadavky; spolupracuje s týmem a zákazníkem; je zodpovědný za přijetí kódu na konci každé iterace. Scrum master Je to nejdůležitější role celé metodologie. Scrum master je zodpovědný za úspěch scrumu na projektu. Scrum master je jako rozhraní mezi týmem a 8

14 3. SCRUM managementem. Obvykle je to projektový manager nebo team leader. Stojí za připomínku to, že scrum master nerozdává úkoly týmu. V agilním vývoji tým je seberegulující a cross-funkční. Základní funkce scrum masteru: vytváří přátelskou a důvěryhodnou atmosféru; zúčastňuje se mítinků jako fasilitátor; odstraňuje překážky; dělá viditelnými problémy a otevřené otázky; odpovídá za dodržování postupů a procesů v týmu. Scrum master provádí každodenní scrum schůze a sleduje pokrok týmu pomocí zvolených artefaktů, označuje status všech úkolů během sptintu. Scrum master může pomáhat vlastníkovi produktu vytvářet backlog pro tým. Scrum tým V scrumu tým je seberegulující, sebevedoucí a cross-funkční. Tým je zodpovědný před vlastníkem produktu za splnění všech úkolů na sprint. Práce týmu je hodnocená jako práce jediné skupiny. Přínos jednotlivých členů projektového týmu není nijak hodnocen kvůli tomu, že to pokazí seberegulaci v týmu. Funkce projektového týmu: je zodpovědný za ocenění backlogu; rozhoduje o designu a implementaci; pozoruje svůj pokrok(spolu se scrum masterem); je zodpovědný před vlastníkem produktu za výsledek. Velikost týmu je omezena velikostí skupiny lidí, kteří jsou schopní efektivně spolupracovat. Typické týmy jsou o 7( ±2) lidech. Skládjí se z lidí s různými zručnostmi. Všichni členové scrum týmu jsou v některé míře vývojaři, analytici, testeři. Scrum tým je schopen se sebeorganizovat pro práci nad konkrétním úkolem během projektu, což dovoluje rychlé reagovat na různé typy úkolů. 9

15 3. SCRUM 3.2 Scrum artefakty Nejpouživanějšími artefakty scrumu jsou: produktový backlog (Product backlog); backlog sprintu (Sprint backlog); burndown chart; seznam překážek (impediment list). Produktový Backlog Produktový backlog je prioritizovaný seznam všeho, co může být potřeba v produktu a je jediným zdrojem požadavků na jakoukoliv změnu v produktu. Vlastník produktu je zodpovědný za obsah, dostupnost a prioritizaci backlogu. Scrum master, tým a všechny zúčastněné strany spolupracují pro vytváření nejvíce úplného produktového backlogu. Práce nad backlogem produktu neznamená, že scrum tým nemůže vytvářet a používat jiné artefakty. Příkladem jiných artefaktů může být seznam různých rolí uživatelů (user stories), popis workflow apod. Tyto artefakty nenahrazují produktový backlog a jen doplňují a upřesňují jeho obsah. Vlastník produktu používá produktový backlog během plánování sprintu, aby mohl vysvětlit týmu klíčové body. Pak tým vybírá položky, které může udělat za jeden sprint. Obrázek 3.3: Příklad produktového backlogu ve scrumu [9] 10

16 3. SCRUM Každý backlog produkru ve scrumu má určité vlasnosti, kretými se liši od obyčejného to-do seznamu: Každá položka v produktovém backlogu má cenu pro zákazníka. Položky v produktovém backlogu jsou seřazené podle priority. Všechny položky jsou ohodnocené. Produktový backlog je živý dokument. Může se měnit během projektu. Backlog sprintu Backlog sprintu je výstupem sprint planning schůze. Je to v podstatě seznam vybraných z produktoého backlogu položek, které je třeba dokončit během sprintu. Po ukončení sprintu tento seznam úkolů je dodán jako jediný přírůstek funkčnosti. Na rozdíl od produktového backlogu úkoly v sprint backlogu jsou časově omezené. Scrum tým je zodpovědný za dodržování termínu sprintu. Backlog sprintu ukazuje všechnu práci, kterou si vývojový tým vytýčil jako nezbytnou ke splnění cíle daného sprintu. Sprint backlog se během sprintu mění; vývojový tým ho upravuje po celou dobu sprintu. Tyto úpravy jsou potřebné proto, že vývojový tým během sprintu získává více poznatků o tom, co je potřeba ke splnění cíle sprintu. Obrázek 3.4: Příklad backlogu sprintu ve scrumu[10] 11

17 3. SCRUM Burndown chart Burndown chart je graf, který ukazuje kolik práce bylo uděláno za určitý čas. Je to jeden z důležitých ukazatelů, zda vývoj produktu probíhá tak, jak má. Na ose x je zobrazen čas a na ose y součet bodů jednotlivých úkolů bud ve sprintu nebo celého produktu. Mezi počtem bodů a počtem dní obsažených ve sprintu je rovná čára, která představuje ideální výkonnost. Obrázek 3.5: Burndown chart [11] Pokud tým pracuje příliš rychle, scrum master může přidát další úkoly z produkt backlogu do sprint backlogu. Pokud je tým příliš pomalý, řeší scrum master důvody, proč se nedaří pracovat se stanovenou rychlostí. Nelze-li zrychlit, scrum master přesune úkoly zpět ze sprint backlogu do produkt backlogu tak, aby rychlost práce vycházela přesně na termín sprintu. Tyto přesuny nesmí dělat nikdo jiný zejména ne vlastník produktu. Seznam překážek Překážka (anglicky impediment) je to cokoli co zdržuje, rozptyluje, přerušuje tým nebo jednotlivého člena týmu od plnění aktivit zajišt ujících dosažení cíle sprintu. Překažky se dělí na: personální(personal impediment); týmové(team impediment); 12

18 3. SCRUM organizační(organizational impediment). Ve scrumu překážky jsou velice důležité. Probrání a odstranění těchto problémů zlepši produktivitu. Každá překážka má životní cyklus uvedený na obrázku 3.6. Obrázek 3.6: Životní cyklus překážky Scrum master je zodpovědný za odstranění překážek. Během scrum tréninku musí seznámit tým s různými druhy překážek a pomoct najít vlastní způsob jejích odstranění. Obvykle je pro překážky určené speciální místo na scrum desce. Obrázek 3.7: Forma pro zaznamenání překážek 3.3 Scrum činnosti Základními scrum činnostmi jsou: product backlog refinement; sprint planning; daily scrum; 13

19 3. SCRUM sprint review; sprint retrospective. Product backlog refinement Vzhledem k tomu, že položky v backlogu produktu jsou docela velké, zahrnují v sobě množství funkčnosti a protože myšlenky přicházejí a odcházejí a priority se mění, product backlog refinement je pokračující činnost v rámci celého scrum projektu. Tato činnost zahrnuje, ale není omezena na: Dodržovat pořadí v backlogu produktu. Smazání nebo snížení úrovně pro položku, která už není tak důležitá. Doplnění nebo zvýšení úrovně pro položku, která vzniká nebo se stává důležitější. Rozdělování položek na menší části. Oceňování položek. Jedním z klíčových přínosů této činnosti je příprava na budoucí sprinty. Backlog refinement věnuje zvláštní pozornost přípravě položek, které přicházejí k realizaci. Plánování sprintu Každý sprint se začíná se schůzky, která se jménuje sprint planning. Během tohoto setkání scrum tým spolupracuje nad volbou prací na budoucí sprint. Setkání sprint planning se účastní celý tým. Spolu s vlastníkem produktu tým diskutuje o každé položce produktového backlogu, aby dospěli k její lepšímu společnému chápání a tomu, co je nutné pro úspěšné dokončení prácí nad ní. Všechny schůzky scrumu jsou časově omezené. Doporučená doba pro setkání sprint planning je dvě hodiny nebo méně za týden trvajícího sprintu. Vzhledem k tomu, že schůzka je časově omezená, úspěch jednání sprint planning silně záleží na kvalitě průchodu produktovým backlogem. To je důvod, proč produkt backlog refinement je důležitá scrum činnost. Ve scrumu se schůzka sprint planning skládá ze dvou epat: 1. Zjistit jaká práce bude dokončena během sprintu. 2. Zjistit jak bude táto práce provédena. 14

20 3. SCRUM Část první: Jakou práci budeme dělat? V první části jednání vlastník produktu prezentuje prioritizovaný produktový backlog týmu, a celý scrum tým spolupracuje nad pochopením toho, co všechno je třeba udělat. Počet položek backlogu produktu, které budou zvoleny na sprint je závislý jenom na vývojovem týmu. Při rozhodování, kolik si položek vybrat tým bere na vědomí současný stav produktového incrementu, minulou výkonnost týmu, současnou kapacitu týmu apod. Vývojový tým sám rozhoduje kolik si vzít práce. Ani vlastník produktu, ani žádné jiné agentury nemůžou nařídit více práce na tým. Často, ale ne vždy, ve sprintu je uveden cíl, který se jménuje sprint goal. Táto praxe se pomáhá více zaměřit na podstatu věcí a nesáhat do detailů, které mohou být zbytečné pro dosážení cíle. Část druhá: Jak bude práce provédena? Ve druhé části setkání tým rozhoduje jak vyrobit další produktový increment. Dělají se design a plánování, aby všichni byli přesvědčeni o dokončení prácí během sprintu. Práce, kterou je třeba udělat co nejdříve je rozdělena do jednotek délky jedného dne nebo méně. Práce, která bude provéděna později, může být ponechána ve větších celcích. Rozhodování o tom, jak dělat práci, je v kompetenci týmu, stejně jako rozhodování o tom, co udělat, je odpovědností vlastníka produktu. Vlastník produktu se může zúčastnit této části jednání s cílem odpovidání na otázky a řešení nedorozumění. V každém případě je třeba, aby byl snadno dostupný. Daily scrum Scrum tým je seberegulující. Tým používá schůzky daily scrum, aby se zajistilo, že jsou na dobré cestě k dosažení cíle sprintu. Setkání se koná ve stejnou dobu a ve stejnem místě každý den. Každý člen týmu poskytuje tři kousky informací: Co jsem dokázal od našeho posledního daily scrumu. Co mám v plánu udělat do dalšího daily scrumu. Co zdržuje můj pokrok. Během daily scrum schůzky může být krátká řada specifikovaných otázek a odpovědí, ale není tam žádná diskuse. Nicméně tým se může sejít hned po setkání daily scrum a propracovat případné problémy. 15

21 3. SCRUM Daily scrum to není výkaz pro vedení společnosti, ani pro vlastníka produktu, ani pro scrum mastera. Jedná se o komunikační setkání v rámci týmu, aby bylo zajištěno, že jsou všichni na správné cestě. Pouze členové týmu, včetně scrum mastera a vlastníka produktu, hovoří během tohoto setkání. Ostatní zúčastněné strany mohou přijít a poslouchat. Daily scrum je klíčovým prvkem scrumu, který se řídí transparentnosti, důvěrou a lepším výkonem. Všechny schůzky daily scrum jsou časově omezené. Doporučená doba trvání je patnáct minut. Sprint review Na konci sprintu tým a zúčastněné strany přezkoumají jeho výstup. Doporučená doba pro sprint review je jedna hodina. Ústředním bodem diskuse je produktový increment dokončený v průběhu sprintu. Jedná se o neformální setkání, aby se podívali na to, kde jsme, a spolupracovali na tom, jak bychom mohli jít dál. Každý se může zúčastnit schůze sprint review. Samozřejmě, že vlastník produktu dělá konečné rozhodnutí o budoucnosti a aktualizuje backlog produktu podle potřeby. Tým musí najít svůj vlastní způsob, jak dělat sprint review. Demonstrace produktového incrementu je celkový pohled. Tým se diskutuje nad tím, co pozorovali během sprintu, jaké kdo měl nápady, podrobně zkoumá backlog produktu a mluví o možném termínu dokončení dalšího sprintu. Sprint review dává každému přehled o současném produktovém incrementu. V tomto případě je běžné provádět aktualizaci backlogu produktu jako součást schůze sprint review. Sprint retrospective Na konci každého sprintu scrum tým se schází na sprint retrospective. Cílem je zhodnotit, jak to dopadlo s ohledem na proces, vztahy mezi lidmi a nástroji. Tým zjistí co je dobře a co není dobře, vypracuje plán na zlepšení v budoucnosti. Doporučená doba trvání pro sprint retrospective je jedna hodina. Scrum tým zlepšuje svůj vlastní proces, který vždy zůstává v rámci týmu. 3.4 Scrum deska Při používaní scrumu děláme sprint backlog viditelným rozmíštěním ho na scrum desce, příklad které je uveden na obrázku 3.8. Každý řádek na scrum desce představuje jednu user story. Každá karta 16

22 3. SCRUM Obrázek 3.8: Příklad scrum desky reprezentuje jeden z úkolu, na které jsou rozděleny položky backlogu produktu zvolené týmem na daný sprint. Sloupce jdou zleva doprava. Story: Popis příběhu uživatele (user story) ( "Jako uživatel chceme... ") uvedený na tomto řádku. To Do: Místo startu každé karty v dánem sprintu. Work In Process: V tomto spoupci jsou karty nad kterými ted pracují programátoři. Do sloupce WIP kartu přenáší programátor, který se rozhodne pracovat nad tímto úkolem. Obvykle se to stává během daily scrum schůze. To Verify: Množina úkolů, které popisují testovací případy. Done: Množina úkolů, práce nad kterými je ukončena. Tyto karty se odstraňují na konci sprintu. Je možné odstranit některé karty i během sprintu, pokud máme jich na desce příliš mnoho. 17

23 Kapitola 4 Kanban Kanban je to technika pro vizualizaci, plánování a provedení práce. Za první oficiální použití Kanbanu lze považovat práci Taiichi Ohno ve firmě Toyota [1]. On potřeboval způsob rychle komunikace mezi pracovníky, aby mohly zjistit kolik se děje práce, v jakém je stavu, a jak se práce provádí. Jeho cílem bylo, aby pracovní procesy byly transparentní - což znamená, že ne jen manažeři vědí co se "opravdu"děje. Termín Kanban můžeme doslovně přeložit jako Kan - viditelný, vizuální, a Ban karta, deska. Továrny Toyota používají karty kanban, aby nedošlo k přetížení skladů a pracovních míst vytvořených předem částí. Technika kanban se ve vývoji softwaru snaží skoro o totéž. Celý systém řízení vývoje je postaven kolem vizualizace průběhu práce, omezení paralelních činností ("limit kanban", běžněji se lze asi setkat se zkratkou WIP neboli Work In Progress) a sledování doby nutné ke splnění jednotlivých požadavků ve snaze optimalizovat pracovní proces. Metodika kanban v agilním vývoji vede ke globálnímu odstoupení od velkého množství praktik, které jsou považovány za užitečné. Implementace kanbanu se muže lišit podle aktuální potřeby. 4.1 Základní principy kanbanu Začněte s tím, co děláte ted Thechnika kanban nepředepisuje konkrétní sadu rolí nebo procesních kroků. Metodika kanban se začíná z rolí a procesů, které máte, a stimuluje průběžné, přírůstkové a evoluční změny ve vášem systému. Kanban je thechnika řízení změn, není tam žádná taková věc jako proces, kanban vývoj softwaru nebo projektové řízení kanban. Souhlas s evolučními změnami Tým musí souhlasit s tím, že kontinuální, postupné a evoluční změny je 18

24 4. KANBAN to způsob, jak zlepšit stávající systém. Rozsáhlé změny se mohou zdát efektivnějšími, ale mají vyšší poruchovost kvůli odporu a strachu v organizaci. Respektujte aktuální proces, role, odpovědnosti V týmu můžou existovat obavy před budoucími změnami. Je nutné s tím počítat a zbavit se nežadoucího strachu. Také je pravděpodobné, že organizace má v současné době některé prvky, které dobře fungují a stojí za zachování. Tím, že souhlasíme respektovat stávající role, odpovědnosti a pracovní zařazení můžeme eliminovat počáteční obavy. To by nám mělo umožnit získat širší podporu iniciativy zavedení kanbanu. Vedení na všech úrovních Mělo by být podporováno vedení na všech úrovních organizace od jednotlivých přispěvatelů do vrcholového managementu. 4.2 Základní praktiky kanbanu Vizualizace toku práce Tok práce (workflow) je ve své podstatě neviditelný. Vizualizace workflow je jádrem pochopení toho, jak práce prochází. Bez pochopení pracovních postupů je těžko dělat správné změny. Známým způsobem vizualizace workflow je použití karet a desky se sloupci. Každý sloupec představuje jednotlivý stav nebo krok ve workflow. Omezení work in progress Je třeba určit možný počet nedokončených úkolů v každé fázi procesu. Jak říká David J. Anderson v [5] : "As we all know, there really is no such thing as multi-tasking in the office; what we do is frequent task switching". Přepínání kontextu nemá žádný pozitivní efekt. Kanban se k němu staví negativně a otevřeně říká: nastavte explicitní limit, kolik úkolů může být v daném stavu workflow. 4.3 Deska kanban Tým používá pro práci Kanban-desku. Tato deska může vypadat jak na obrázku 4.1. Sloupce jdou zleva doprava. Cíle projektu: Volitelný, ale užitečný sloupec. Zde si můžeme uvést cíle 19

25 4. KANBAN Obrázek 4.1: Deska kanban [13] projektu na vysoké úrovni, aby tým viděl a věděl co se po nich všechno chce. Například "Zvýšení rychlosti o 20%" nebo "Přidat podporu pro systém Windows 8". Fronta úloh: Zde jsou uloženy úkoly, které jsou připravené k provedení. Vždy do vykonání jde úloha s nejvyšší prioritou a její karta se přesune do dalšího sloupce. Propracování designu: Tento a další sloupce až do "Dokončeno"se mohou střídat, protože tým rozhodne přes jaké kroky musí projít úkol, než přijde do stavu "Hotovo". Například, tento sloupec může obsahovat problémy, pro které návrh kódu nebo rozhraní není zatím jasný. Když je diskuse dokončena, úkol se přesune do dalšího sloupce. Vývoj: Zde úkol visí až do vývoje funkcí, které mají být dokončeny. Po dokončení se přesune do dalšího sloupce. Nebo, v případě když architektura není pravdivá, nebo není přesná - úkol se může vrátit do předchozího sloupce. Testování: Úkol je v tomto sloupci dokud se testuje. Pokud jsou nalezeny chyby - vrací se ve vývoj. Pokud ne - postupuje dál. Deployment: Každý projekt má svůj deployment. Někdy to znamená dát novou verzi na server, a někdy jenom dát kód do úložiště. Dokončeno: Sem se nálepka dostane pouze tehdy, když budou dokon- 20

26 4. KANBAN čeny všechny práce nad úkolem. V každé práci jsou případy naléhavých úkolů. Plánované nebo ne, ale jsou to té, kteřé potřebujeme udělat právě ted. Pro takové úkoly může být zavedeno zvláštní místo na desce (na obrázku označené jako "expedite"). Expedite může obsahovat jenom jeden naléhavý úkol a práce nad nim se musí začít okamžitě, aby byla dokončena co nejdříve. Pokud vznikne další úkol, který bychom mohli odnést do expedite, musí byt přidán do fronty úloh. Ale nejdůležitějšími na desce jsou čísla pod každým sloupcem. To je počet úkolů, které mohou být současně v těchto sloupcích. Tato čísla jsou zvolena experimentálně a závisejí na počtu vývojářů v týmu. 4.4 Kanban vs. scrum Kanban se liší od scrumu především zaměřením na úkol. Je-li základní orientace scrum týmu je úspěšná realizace sprintů, pak na prvním místě kanbanu je úkol. Nejsou žádné sprinty, tým pracuje nad úkolem od začátku až do konce. Deployment a prezentace se provádí jenom kdy úkol je hotový. Tým nemusí odhadovat čas potřebný pro dokončení úkolu, protože to nemá smysl a je téměř na začátku vždy chybný. Pokud manažer věří, že tým úkol splní, tak proč by měl odhadovat čas? Úloha manažera je vytvořit frontu prioritizovaných úkolů, a úloha týmu je vykonat co nejvíce úkolů z této fronty. A je to všechno. Kontrola není nutná. Vše, co potřebujeme od manažera je aby přidával úkoly do fronty nebo měnil jejich prioritu. To je to, jak se řídí projekt. Scrum Jsou povinné časově omezené iteraci. Tým se zavazuje provedení konkrétní nožství práce za iteraci. Produktivita je hlavni metrikou plánování a zlepšení procesů. Kanban Časově omezené iteraci nejsou povinné. Jsou možné samostatné rytmy pro plánování, deployment a zlepšení procesů. Závazky jsou volitelné. Hlavni metrikou plánování a zlepšení procesů je čaš vykonaní úkolu. Cross-funkční týmy jsou povinné. Nejsou povinné cross-funkční týmy. Jsou povolený úzképrofilové týmy. 21

27 Úkoly by měli být rozděleny do menších části, aby býli ukončene během sprintu. Jsou povinné burndown diagramy. 4. KANBAN Nejsou přesně stanovené velikosti úkolů. Diagramy nejsou povinné. WIP omezená nepřímo(za sprint). WIP omezená přímo(po statusech). Je povinné oceňování úkolů. Oceňování úkolů je nepovinné. Není možné přidat úkol do Je možné přidavat nové úkoly. sprintu. Za sprint backlog je zodpovědný jeden tým. Kanban deska může být spolupoužívaná několika týmy. Předepsané 3 role. Role nejsou předepsané Scrum deska se očišt uje mezi Kanban deska je neměnná. sprinty. Je povinný prioritizovaný product Prioritizace není povinná. backlog. Hlavními odpovědmi na otázky "Proč to funguje?"pro scrum a kanban jsou: Proč funguje scrum? Cross-funkční tým Časové omezení Proč funguje kanban? Omezení WIP Viditelnost procesu pro všechny Řízený workflow Scrum je velice pěkná a jednoduchá metodologie, ale bohužel ve své čisté formě je užitečná jenom ve fázi programování. Problém je v tom, že scrum nemá specializaci, tým je cross-funkční. Představíme si firmu, kde jsou následující role: analytik; návrhář; inženýrský psycholog (věnuje se interview, testování použitelnosti, výběru kontrolní skupiny apod.); projektant uživatelských rozhraní; grafický designér; 22

28 4. KANBAN programátor; tester; projektový manažer. Zjevně specializace je. Možná všichni rozumí v grafickem designu, ale opačným směrem to nefunguje. Když programátor může se pustit do designu, to grafický designér nepůjde programovat. V týmu programátorů scrum dobře funguje, protože je tam vlastník produktu, který někde bere požadavky, ví proč jeden požadavek má vyšší prioritu apod. Vzhledem ke struktuře náše firmy můžeme říct, že před programováním je tam docela velký kus práce jako sběr a analýza požadavků, design a návrh UI. Je to celý samostatný proces, který trvá skoro stejně s programováním, a který také je třeba řídit. Ale scrum nedává k tomu žádné instrumenty. Toto se donucuje týmy obracet k různým modifikacím scrumu, jednou z kterých je scrumban. 23

29 Kapitola 5 Scrumban Scrumban je to plnohodnotný scrum, uvnitř kterého se používá thechnika kanbanu. Formule scrumbanu je scrumban = scrum + kanban. Používejte normativní povahu scrumu, aby být agilními. Používejte kanban, aby neustále zlepšovat svůj proces. Scrumban je to pull-based systém, kde tým méně pracuje nad plánováním práce, která již byla akceptována během planning schůze, a více se věnuje práci nad backlogem. Setkání scrumu (plánování, hodnocení, retrospektiva) můžou a musí probíhat i nadále, ale nepříliš často. Kdy uvažovat o scrumbanu? Projekty údržby. Event-driven práce. Help desk/support. Hardening/packaging fáze. Projekty s častými a nečekanými příběhy uživatele nebo programovými chybami. Tým zaměřen na vývoj nových produktů. Pokud scrum je podroben pochybnosti kvůli otázkám workflow, zdrojů a procesů. 24

30 5. SCRUMBAN 5.1 Principy scrumbanu Omezení WIP Ve scrumu množství práce, která momentálně probíhá, je omezené délkou sprintu. Scrumban omezuje práci pomocí omezení WIP ve sloupcích, stejně jako kanban. Hlavní cíl scrumbanu je posunovat karty na pracovní desce zleva doprava. Je-li počet karet v jednem sloupci někdy přesáhne maximum, celý tým by měl jít do tohoto úkolu a pomoct posunout kartu dál. To by se mělo stát bez ohledu na to, jakou funkční roli má člen týmu. Plánovací schůze Ty by měly probíhat tak často, jak je potřeba. Pokud tým není schopen pravidelně vytáhnout úkoly z vrcholu backlogu při jejich normálním tempu, plánovací schůzka je povinná. Recenzní schůze Kontrola práce s klienty a zákazníky je to jediný způsob, jak vývojový tým může získat zpětnou vazbu nutnou pro správné pochopeni toho, nad čím pracují. Klienti dávají přednost pravidelným schůzím. Retrospektivní setkání Ty se mohou měnit, ale obecné pravidlo je držet retrospektivu po každé revizi. To je nejužitečnější část agilního procesu a musíme tomu věnovat pozornost. Standupy Pro scrumban nejužitečněiším formátem standupu je zaměření na toku karet na desce. Vzor ze scrumu (co jsem dělal včera /co budu dělat dnes / jaké mám problémy) může být převedeny na katry. Skupina karet se pohybuje po každém sloupci. Každá karta se stručně popisuje a zjišt uje se, co je nezbytné pro její pohyb směrem doprava na desce. To poskytuje mnohem větší pochopení týmu a informuje každého o významných architektonických a designových rozhodnutích. Metriky Místo metriky velocity užitečnou scrumban metrikou je cycle time. To je doba, potřebná k dokončení práci nad úkolem v jedne kartě, která je měřena od okamžiku, kdy se poprvé začala (doba průchodu desky kartou). V průběhu času se může provést statistická analýza všech karet v rámci projektu. Tím se získá průměrný cycle time a směrodatná odchylka. To může 25

31 5. SCRUMBAN být užitečný plánovací nástroj na makroúrovni (sečíst počet karet a vynásobit průměrným cycle time). 5.2 Kanban vs. ScrumBan vs. Scrum Na základě praktik, které se používají ve scrumu, kanbanu a scrumbanu vytvoříme srovnatelné tabulky těchto metodik [14]. Kanban Role Žádné předepsané role Každodenní Žádné schůze schůze ScrumBan Tým + potřebné role Zajistit následnou práci na požadavcích, snížit dobu nečinnosti členů týmu. Můžou být použity pro plánování vyplnění sloupců desky Můžou být provedeny jako potřebné pro zlepšení procesu a šíření znalostí Recenzní a Nejsou předepsané retrospektivní schůze Workflow Kontinuální Stejný jako u Kanbanu. Jen se přidává limit ve sloupcech desky, aby se tažný proces stal pohodlnějším Tabulka 5.1: Rozdíly kanbanu a scrumbanu Scrum Scrumban Deska / Artefakty deska, backlogy, burndown diagramy jen deska Ceremonie každodenní scrum, Každodenní scrum (plánování, plánování sprintů, revize a retrospektiva revize sprintů, retrispektiva dle potřeb) sprintů Iterace ano (sprinty) ne (kontinuální tok) Ocenění ano ne (podobné velikosti) Týmy musí být crossfunkční mohou být specializované Role vlastník produktu, tým + potřebné role scrum master, tým 26

32 5. SCRUMBAN Týmová práce koaborativní dle potřeby shlukující se pro dosažení cílů úkolu WIP kontrolován obsahem sprintu kontrolován stavem pracovního toku Změny musí čekát na příští sprint přidávají se dle potřeb na desku (to do) Backlog produktu seznam prioritních a jen v časových kartách oceněnych případů Překážky řeší se okamžitě vyhýbají se Tabulka 5.2: Rozdíly scrumu a scrumbanu 27

33 Kapitola 6 Malé a střední firmy Podle posudku EU [6] podnik je považován za malý nebo střední ("MSP", anglicky SME - Small and Medium Enterprise) vzhledem k následujícím faktorům: počet zaměstnanců; roční obrat nebo bilanční suma. Kategorie Počet zaměstnanců Roční obrat(eur) Bilanční suma(eur) firmy Střední < m 43 m Malá <50 10 m 10 m Mikro <10 2 m 2 m Tabulka 6.1: Kategorie firem podle EU [7] Tato tabulka je platná pouze pro soukromé firmy. Pokud je firma součástí větší skupiny firem, je nutné zapojit do výpočtu počet zaměstnanců/roční obrat/bilanční sumu této skupiny. Je nutno poznamenat, že i když dodržování počtu pracovníků je povinné, malý nebo střední podnik si může vybrat strop týkající se obratu nebo bilanční sumy. Nemusí splnit oba stropy a může jeden z nich překročit, aniž ztratí své postavení [6]. Počet zaměstnanců je rozhodujícím počátečním kritériem k určení, do které kategorie podnik patří. Vztahuje se na osoby s plným pracovním úvazkem, částečným pracovním úvazkem a sezónní pracovníky a zahrnuje: zaměstnance; osoby pracující pro podnik v podřízeném postavení, které jsou považovány za zaměstnance v souladu s vnitrostátním právem; vlastníky, kteří řídí společnost; 28

34 6. MALÉ A STŘEDNÍ FIRMY společníky zapojené do běžné činnosti podniku, kteří využívají finančních výhod plynoucích z podniku. Učni a studenti, kteří jsou zapojeni do odborné přípravy na základě smlouvy o učňovském nebo odborném vzdělávání, se nezahrnují do počtu zaměstnanců. Roční obrat se určuje výpočtem příjmů, které podnik získal během daného roku z prodeje a ze služeb po odečtení vyplacených slev. Obrat by neměl zahrnovat daň z přidané hodnoty (DPH) ani jiné nepřímé daně. Bilanční suma roční rozvahy se vztahuje k hodnotě hlavních aktiv společnosti [7]. 6.1 Podnikové řízení Podnikové řízení [21] je rozsáhlou kategorií zahrnující organizování, plánování, personalistiku, vedení a kontrolu dílčích podnikových činností na jednotlivých úrovních tak, aby podnik dosahoval stanovených cílů. Podstatou je optimální skloubení všech těchto činností. Nositeli řízení jsou bud sami vlastníci, nebo speciální orgány vytvořené vlastníky a vlastníkům zodpovědné, konkrétně podnikový management. Úrovně řízení dělíme na vrcholovou, střední a operativní. 1. Na vrcholové úrovni má řízení strategický charakter, stanovuje základní směřování podniku, jeho koncepci. Na strategické řízení navazují nižší úrovně řízení. 2. Střední management realizuje taktické řízení, stanovuje konkrétní postupy a prostředky vedoucí k realizaci podnikové strategie, zde jsou mnohem intenzivněji sledovány kvantitativní cíle. 3. Na nejnižší úrovni je řízení operativní, které představuje konkrétní a detailní řízení vybrané oblasti v krátkém časovém horizontu. Řízení podniku představuje velice složitý a komplexní proces vyplývající ze skutečnosti, že podnik sám o sobě je velmi složitý organismus. Jeho jednotlivé články, zabývající se různými činnostmi, nemohou účinně fungovat bez určité koordinace a vzájemné propojenosti. Všechny činnosti v podniku musí být vzájemně propojeny. Řízení malé firmy je specifické v mnoha ohledech. Vzhledem k malému počtu zaměstnanců i vedoucích pracovníků například dochází k soustředění řady funkcí do kompetence několika málo pracovníků, často je to jeden až dva lidé. V malých firmách také obvykle převládá operativní řízení 29

35 6. MALÉ A STŘEDNÍ FIRMY nad strategickým, přičemž naprosto převažuje ústní komunikace nad psanou. Práce se mezi zaměstnance rozděluje za chodu a spíše spontánně, jakékoli rozhodnutí vychází obvykle z aktuálního rozpoložení podnikatele či vedoucího pracovníka. Řízení střední firmy má obdobně jako u malé firmy svá specifika. Firma má již více zaměstnanců i vedoucích pracovníků, kteří již nedělají "vše", ale více se specializují na jednotlivé podnikatelské činnosti. Vedle operativního řízení se klade stále větší důraz i na řízení strategické. Obvykle již existuje alespoň základní řídicí dokumentace. 6.2 Organizační struktura V každém podniku, ve kterém pracuje více než jeden pracovník, vzniká potřeba specializace, koordinace a vytváření útvarů. Specializace umožňuje konkrétnímu pracovníkovi soustředit se pouze na daný proces, což má za následek zvyšování produktivity práce a možnost kontroly jeho práce. Tvorba nejlepší organizační struktury pro podnik nemá žádná závazná pravidla, každý podnik má jinou organizační strategii a proto mohou mít jinak podobné podniky jinou organizační strukturu. Malé a střední podniky zpravidla mají jednoduchou organizační strukturu s menším počtem úrovní vedení, než ve velkých firmach. Struktura MSP se skládá z funkčně specializovaných organizačních jednotek, které mají odpovědnost a pravomoc k plnění dané funkce. Je to hlavně způsobeno malým počtem zaměstnanců a množství firemních proseců. To znamená, že MSP nemají mnoho lidí pro jednotlivé řídící činnosti, a že na řídící pracovníky jsou kladeny vysoké odborné i časové nároky. Příklad jednoduché organizační struktury malé IT firmy je uveden na obrázku 6.1. Obrázek 6.1: Jednoduchá organizační struktura 30

36 6. MALÉ A STŘEDNÍ FIRMY 6.3 Výhody MSP Díky omezenosti kapitálových zdrojů malých a středních podniků mají tyto podniky možnost pružně reagovat na změny, např. na výkyvy trhu. Tato výhoda je dána tím, že MSP nejsou zužovány rozsáhlým investičním majetkem, a tudíž mají možnosti produkčního využití. Malé a střední podniky tedy nevyžadují takové velké zásahy do výrobní základny při případných změnách ve výrobním programu. Malé a střední podniky musí vyvíjet jistou inovační kreativitu k nutnému přežití na trhu.v těchto podnicích je značně více prostoru pro individuální iniciativu a současně méně omezujících organizačních podmínek. V malých a středních podnicích jsou také manažeři k inovovaným oblastem mnohem blíže, a tím jsou do těchto inovací více zainteresováni [16]. U malých a středních podniků je většinou pouze menší okruh vlastníků než u velkých podniků a také se tito vlastníci obvykle účastní ve výkonném řízení podniku. To dává předpoklad pro rychlejší přijímání podnikatelských rozhodnutí u malých a středních podniků než u velkých podniků. 6.4 Nevýhody MSP Velkým omezením pro MSP je horší dostupnost k úvěrům a tím menší finanční síla, což může být bariérou k dalšímu rozvoji podniku, které bez dostupnosti úvěru nemohou realizovat podnikové cíle a inovační záměry. Nedostatek kapitálového zázemí v MSP a současná nutnost přežít v tvrdé konkurenci má za následek vyšší intenzitu práce a méně příznivé pracovní podmínky. Majitel malého, popřípadě středního podniku je většinou také vrcholovým manažerem tohoto podniku. Cíle podniku jsou bezprostředně v jeho zájmu, a tudíž ho vytyčený cíl vede k maximálnímu pracovnímu nasazení a totéž samozřejmě vyžaduje i po svých zaměstnancích. Omezené možnosti získávání výhod z rozsahu produkce vycházejí z nízké koncentrace menších příležitostí ve shromažd ování výroby. Malé a střední podniky mohou odebírat potřebný materiál na výrobu pouze v menším množství než velké podniky, a uniká jim tak sleva a výhodnější dodací podmínky, které jsou většinou poskytovány při dodávkách ve velkém množství. Pro malé a střední podniky je obtížnější ovlivňovat své potenciální zákazníky, protože disponují omezenými prostředky na propagaci a reklamu, což dále způsobuje bariéry k růstu obratu a k zvyšování velikosti podniku. MSP svou produkci proto mohou umíst ovat hlavně na segmentech lokálních trhů. 31

37 Kapitola 7 Návrh metodiky pro malou firmu V dnešní době popularita agilních metodik vývoje software neustále roste. Podle každoročního statistického průzkumu "State of Agile Development"[17] mezi hlavními kritérii přechodu společností do agilních metodik patří následující: zvýšení produktivity; zlepšení kvality; viditelnost situace v projektu; snížení rizika; zjednodušení procesů; snížení nákladů na projekty; lepší udržovatelnost projektů v budoucnu; zlepšení morálky týmu; někdy i organizace distribuovaného týmu. Každá agilní metodika představuje sebou seznam roli, artefaktu a direktiv. Problém je v tom, že těžko si představit situaci, kdy budeme mít dvě různé firmy se stejnými vnitřními procesy. Proto pro úspěšné nasazení každá společnost musí provest určité změny jak v organizaci své práci tak i ve zvolené metodice. 7.1 Popis metodiky Představíme si malou IT firmu, která úspěšně pracuje s použitím scrumu. To znamená, že tým je schopen doručovat fungující a otestováný software na konci každého sprintu. Rychlost vývoje je udržitelná, mezí členy týmu je 32

38 7. NÁVRH METODIKY PRO MALOU FIRMU skvělá spolupráce a žádný pocit promarněného času na okrajích. Hlavním úkolem retrospektiv je nacházet a odstraňovat překážky. V tomto případě je těžko říct, že změna metodologie může způsobit růst produktivity týmu. Spíš je třeba hledat možnosti vně týmu. Ale většina týmů nejsou takové. Mají problémy se sprinty, user stories unikají, software není vždy fungující a otestováný. Diskuse na retrospektivním mítinku jde hlavně o tom jak správně spočítat velocity a kolik % času alokovat na překvapení, odhad nepřesnosti a podobné problémy. Pro malou firmu to znamená, že riziko krachu je velké a je třeba provádět změny. Scrumbun může být tou metodologií, která pomůže vyjít na cestu vylepšování. Jak už bylo řečeno v kapilole 4, scrumban představuje aplikaci praktik kanbanu na scrum. Tato aplikace má 2 základní principy: 1. Začináme s tím, co děláme ted. V případě scrumu to znamená, že se na začátku zůstanou všechny role, artifakty, ceremonie a retrospektivy. 2. Souhlas s evolučními změnami. Vzhledem k tomu, že se nasazení provádí v malé firmě, pravděpodobnost nacházení ve společnosti nahodilého člověka, který nerespektuje byznys cíle dané firmy, je velice malá. Jinými slovy nebude problémem adaptovat, přidat nebo odstranit některé praktiky a politiky. Po pochopení těchto principů přichází čas aplikace hlavních praktik kanbanu. Vizualizace workflow Vizualizace workflow je jednou ze základních praktik kanbanu. Scrum týmy také vizualizují workflow a tím způsobem mají viditelnost toho, že položka backlogu prošla fáze od požadavků do stavu done. Ale se práce uvnitř sprintu zůstává neviditelná. Je důležité, aby workflow do a vevnitř sprintu byl stejně viditelný, protože podle Davida J. Andersona [5] mnoho týmů mají potíže právě s tímto aspektem. Scrumban je typicky o vizualizaci toku nevyřízených položek backlogu, než jednutlivých úkolů. Úlohy jsou vytvořeny později a netečou celým workflow. Pro projekty řešené malými firmami zkusíme navrhnout počáteční desku, která je uvedená na obrázku 7.1. Sloupce zleva doprava: Backlog. V tomto sloupci se nacházejí položký, které byly vypracovány během analýzy požadavků zákazníka. 33

39 7. NÁVRH METODIKY PRO MALOU FIRMU Obrázek 7.1: Zvolená deska Priority. V tomto sloupci se nacházejí položký backlogu, které v danou chvíli mají prvořadnou prioritu. In Development. V tomto sloupci se nacházejí položký backlogu nad kterými momentálně pracují programátoři. Ready for test. V tomto sloupci se nacházejí položký, které již prošli fází programování a jsou připravene k testování. Test. V tomto sloupci se nacházejí položký backlogu nad kterými momentálně pracují testeři. Done. V tomto sloupci se nacházejí položký, práce nad kterými již byla ukončena v plné míře. Práce s deskou probíhá tak, že se nové položky přidávají do spodní časti sloupce backlog. Pohyb položek po desce prochází zleva doprava a shora dolů. Obrázek 7.2: Pohyb položek na desce V situaci, kdy se během testování odhalí chyby, kartička se ze sloupce test vrátí do horní časti sloupce priority. To znamená, že odstraňování těchto chyb bude provedeno jakmile někdo z vývojářů skonči svou práci. 34

40 7. NÁVRH METODIKY PRO MALOU FIRMU Obrázek 7.3: Pohyb chybové kartičky Omezení WIP Kdy budete mít kanban desku vizualizující workflow, dalším krokem je zavedení kanban systému. To vyžaduje omezení work in progress, které v kontextu scrumu znamená, že omezení množství položek backlogu probíhá v každém okamžiku. Podle Davida J. Andersona [5] lepším způsobem výběru počáteční hodnoty pro WIP je spustit několik iterací, aby bylo vidět kolik průměrně úkolů lze zvládnout pomocí jedne iterace. Pak musíme vypočítat velikost backlogu. Pokud tým může splnit 10 úkolů za týden, pak jeho velocity je dva úkoly denně pro současný tým. Pokud iterace trvá jeden týden, pak velikost backlogu by měla být 10. Kromě toho backlog může být rozdělen do několika sloupců, aby bylo možné vizuální stanovení priorit položek prostřednictvím sloupců. Obrázek 7.4: WIP omezení Jakmile v nějakém sloupci dosažená limita WIP, alternativou pro zahájení práce nad novou kartičkou je jít a pomáhat ostatním řešit jejich úkoly. Pomáhat je možné ve svých odborných znalostech nebo jít ve/proti směru workflow (např. vývojáři pomáhají testerům, testeři pomáhají analytikům). Zavedení omezení WIP může způsobit některé nelibosti tím, že členové týmu nevždy budou schopní dělat to, co jim vyhovuje a na co jsou zvyklí. Během analýzy těchto nelibosti najdeme cestu do zlepšení pracovního procesu a omezeni WIP už nebude takým problémem. Podle Davida J. An- 35

41 7. NÁVRH METODIKY PRO MALOU FIRMU dersona [5] použití technik, jako jsou acceptance test-driven development (ATDD), snížení velikosti tým / (velikost backlogu), cross- školení a jiné lze považovat za způsob, jak odstranit strach před omezením WIP. V průběhu práce se týmové schopnosti zlepší a omezení WIP může být utaženo, aby ještě více zlepšit spolupráci. Omezení WIP je skvělý způsob jak řídit skutečnou součinnost na úrovni týmu. Metriky a správa workflow Než se dostat do výkonnostních ukazatelů týmu je třeba mít jistotu toho, že náš systém pracuje správně. Nejzákladnější metrikou, která toto ukazuje, je sledování WIP v každé fázi workflow. Pro tyto účely se běžně používá cumulative flow diagram neboli burnup chart. Obrázek 7.5: Cumulative flow diagram Dalšími metrikami, které již přímo ukazují produktivitu týmu jsou lead time a cycle time. Měření času lead time se začíná, kdy je podána žádost na vypracování úkolu, a končí při jeho dodání. Doba cycle time se začíná, kdy je zahájena práce nad úkolem, a končí, kdy položka je připravená k dodání. Doba cycle time je větší metrikou způsobilosti procesu. Lead time je to, co vidí zákazník. 36

42 7. NÁVRH METODIKY PRO MALOU FIRMU Obrázek 7.6: Znázornění lead time a cycle time Obrázek 7.7: Příklad lead time a cycle time diagramů Udělat politiky procesu explicitními Některé scrum týmy dělají své týmové pravidla explicitními. Jedná se o podobný přístup. Rozdíl je v tom, že musíme udělat explicitním celý proces. Obrázek 7.8: Explicitní politiky ve scrumu Samoorganizující se tým nemůže fungovat, pokud nemá společné chápání toho, jak se práce provádí. Explicitní politiky pomáhají neustálemu vylepšování workflow. Udělat proces viditelným je možné pomocí diskuse o tom "proč dělat věci tímto způsobem". Tyto diskuse je třeba provádět během plánovacích nebo reprospektivních schůzí. 37

43 7. NÁVRH METODIKY PRO MALOU FIRMU Zlepšení spolupráce Ve chvílí, kdy náš proces začne normálně fungovat, je třeba se dívat na retrospektivy jako na místo pro navrhování experimentů. Musíme vyhodnotit všechný nápady na to, jakým způsobem je možné vylepšit celý proces nebo nějakou jeho část, případně vyzkoušet něco a na další retrospektivě přezkoumat výsledky a rozhodnout, zda další kolo experimentování je nutné nebo zda je možné nasadit změnu jako standardní provozní politiku. Backlog produktu Backlog je to seznam funkcí, které jsou určené k poskytování uživatelům vyvinutého systému. Sestavení základního backlogu je důležitou etapou. Jedním ze způsobů jak vytvořit backlog produktu může být kreslení use case diagramu UML [22], a pak backlog je to seznam všech funkcí z tohoto use case. Nebo je možné přímo psát backlog jako seznam požadavků. Položkami backlogu obvykle jsou user stories. Obrázek 7.9: Zvolená varianta backlogu Na obrázku 7.9 je uvedena varianta backlogu, která se může používat pro sestavení požadavků na systém v malé firmě. Každá položka obsahuje tuto informaci: ID. Zadává pořadí položek. Name. Kratký a maximálně jednoduchý název budoucí funkce. User Story. Podrobný popis. Fráze podle šablony "Jako <uživatelská role> chci <fukncionalita>, která/aby <má cíl/hodnoty/znamená>." Priority. Určuje, jak velká je užitečnost této funkce. Jakým způsobem stanovit prioritu rozhoduje tým. Jednou z variant je zvolit hodnoty v rozsahu 0 až 20. Jestli úkol je naléhavý, pak dostane prioritu 15 až 20. Když jsou to plány do budoucna nebo experimentální, pak dostanou prioritu 0 až 5. Všechný ostatní leží v rozmezí 5 až

44 7. NÁVRH METODIKY PRO MALOU FIRMU Story points. Jelikož vývojový tým má zkušenosti se scrumem, ocenění složitosti bylo zvoleno ve formátu story points. Většina programátorů často chápe story points ve smyslu člověkohodin, ale jak říká ve svém blogu Mike Cohn [18] není přímá závislost mezi story points a časem. Proto, jestli je to pohodlné pro tým, to je možné nechat tento způsob ocenění. Definition of done. Seznam vlastností, které bude mít dokončená položka. Někdy obsahuje jednoduchý testový scénář, který popisuje triviální posloupnost kroků které musí vyplnit uživatel v triviálním případě. Notes. Případné komentáře. Mítinky Metodologie scrumbun předepisuje provedení mítinků stejných s mítinky scrumu, ale ty musí víc záležet na kontextu. Plánovací schůze Pro malou firmu naplánujeme každotýdenní mítink, během kterého bude naplánována příští iterace a oceněná minulá. Program schůze bude vypadat takto: Obnovení grafů a desky. Předled minulého týdne. Co se stálo? Proč? Co je třeba udělat pro zlepšení situace. Změna omezení WIP (když je to třeba). Rozdělení položek backlogu na úkoly a ohodnocení nových user stories. Rozdělení položek backlogu se bude provádět na úkoly maximalního objemu 6.5 sp. Review meetings Přezkoumání práce s klienty a zákazníky je to jediný způsob, kterým vývojový tým může získat zpětnou vazbu, nutnou pro správnou adaptaci toho, nad čím pracují. Review mítink budeme provádět jakmile je hotova část práce, která již může být nasazena. 39

45 7. NÁVRH METODIKY PRO MALOU FIRMU Standup meetings Ve scrumu se standup mítink provádí po jednoduché šabloně, kdy během 15 minut každý člen týmu říká, co dělal včera, co bude dělat dnes a co mu překáží. Pro scrumban efektivnější bude převést tuto šablonu na workflow. Kdy tým prochází po jednotlivých sloupcích a stručně diskutuje nad tím, co je třeba udělat, aby mohli posunout kartičku doprava. V malé firmě standup schůze bude mít za úkol odhalení problémů a formování společného chápání toho, co dělají ostatní členové týmu. Struktura týmu Obvykle vývojový tým má organizační strukturu blízkou struktuře uvedené v kapilole 4.4. Analytici. Návrháři. Inženýrský psycholog(věnuje se interview, testování použitelnosti, výběru kontrolní skupiny apod.) Projektanti uživatelských rozhraní. Grafický designér(vykonává všechný grafické úlohy na projektu). Programátoři. Testeři. Projektový manažer. Vzhledem k tomu, že máme malou firmu, některé role budou sdružené. Struktura vývojového týmu malé společnosti má následující role: projektový manažer/ analytik/ návrhář; programátoř/ projektant uživatelských rozhraní/ grafický designér; tester. 40

46 7.2 Nástroje pro práci s metodikou 7. NÁVRH METODIKY PRO MALOU FIRMU Návrhnutou metodiku se dá provozovat, i když máte jen propisku, pár papírů a něco, na co můžete nalepovat lístečky. Rozebereme si tři možnosti. Jedna z nich je čistě papírová a lehce se používá v prostředí malé firmy. Ostatní dva nástroje jsou vhodné pro distribuované týmy a pro ty, kdo chce pracovat s mnoha úkoly. Tyto nástroje s některou mírou omezení mohou být použity na projektech malých firem. Tabule a nálepky Vytvoříme klasickou kanban desku s nálepkami a k tomu opravdu stačí bílá deska, nálepky a pár popisovačů. Obrázek 7.10: Kanban deska Kanban tool Kanban Tool [19] je vizuální aplikace vyvinutá v Polsku firmou Shore Labs, která slouží pro správu projektů na základě kanbanu a pomáhá vizualizaci toku práci, sledování průběhu projektu a provedení analýzy. 41