ScrumBan pro malé a střední firmy

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

ScrumBan pro malé a střední firmy

Diplomová práce

Andrey Chekhlov

Brno, jaro 2014

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracovala samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používala nebo z nich cˇ erpala, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj. Brno, 26. kvˇetna 2014 Andrey Chekhlov

Vedoucí práce: RNDr. Jaroslav Ráˇcek, Ph.D. i

Podˇekování Chtˇel bych podˇekovat vedoucímu mé diplomové práce RNDr. Jaroslavu Ráˇckovi, Ph.D. za vstˇrícný pˇrístup, rady a za cˇ as, který mi vˇenoval.

ii

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

iii

Klíˇcová slova Agilní metodiky, scrum, kanban, scrumban, malé a stˇrední firmy

iv

Obsah 1 2 3

4

5

6

7

8

Úvod . . . . . . . . . . . . . . . . . . . . . . . Agilní metodiky vývoje softwaru . . . . . . Scrum . . . . . . . . . . . . . . . . . . . . . . . 3.1 Scrum role . . . . . . . . . . . . . . . . . 3.2 Scrum artefakty . . . . . . . . . . . . . . 3.3 Scrum cˇ innosti . . . . . . . . . . . . . . . 3.4 Scrum deska . . . . . . . . . . . . . . . . Kanban . . . . . . . . . . . . . . . . . . . . . . 4.1 Základní principy kanbanu . . . . . . . 4.2 Základní praktiky kanbanu . . . . . . . 4.3 Deska kanban . . . . . . . . . . . . . . . 4.4 Kanban vs. scrum . . . . . . . . . . . . . Scrumban . . . . . . . . . . . . . . . . . . . . 5.1 Principy scrumbanu . . . . . . . . . . . 5.2 Kanban vs. ScrumBan vs. Scrum . . . . Malé a stˇrední firmy . . . . . . . . . . . . . . 6.1 Podnikové rˇ ízení . . . . . . . . . . . . . 6.2 Organizaˇcní struktura . . . . . . . . . . 6.3 Výhody MSP . . . . . . . . . . . . . . . . 6.4 Nevýhody MSP . . . . . . . . . . . . . . Návrh metodiky pro malou firmu . . . . . . 7.1 Popis metodiky . . . . . . . . . . . . . . 7.2 Nástroje pro práci s metodikou . . . . . 7.3 Formuláˇre pro jednotlivé fáze metodiky Nasazení metodiky . . . . . . . . . . . . . . . 8.1 Popis projektu . . . . . . . . . . . . . . . 8.2 Pˇredstavení spoleˇcnosti . . . . . . . . . 8.3 Sestavení backlogu . . . . . . . . . . . . 8.4 První iterace . . . . . . . . . . . . . . . . 8.4.1 Plánovací schuze ˚ . . . . . . . . . 8.4.2 Den první . . . . . . . . . . . . . 8.4.3 Den druhý . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 4 7 7 10 13 16 18 18 19 19 21 24 25 26 28 29 30 31 31 32 32 41 44 48 48 48 49 49 50 50 51 1

8.4.4 Den tˇretí . . . . . 8.4.5 Den cˇ tvrtý . . . . 8.4.6 Den pátý . . . . . 8.4.7 Review mítink . . 8.5 Druhá iterace . . . . . . 8.5.1 Plánovací schuze ˚ 8.6 Výsledek nasazení . . . 9 Zhodnocení . . . . . . . . . . 10 Závˇer . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

53 53 55 55 56 56 57 58 60

2

Kapitola 1

Úvod ˇ Malé a stˇrední podniky (MSP) jsou podstatnou souˇcástí ekonomiky Ceské republiky. Nezastupitelnou rolí MSP je poskytování šance pro svobodné uplatnˇení obˇcanu˚ k samostatné realizaci lidí v produktivním procesu. Lidé v tˇechto podnicích jsou nuceni k zodpovˇednosti, protože jakýkoliv omyl pro nˇe muže ˚ znamenat konec a dusledky ˚ neúspˇechu nesou osobnˇe. Flexibilita, neboli schopnost rychle se pˇrizpusobovat ˚ mˇenícím se skuteˇcnostem, je jedním z nejcennˇejších charakteristických znaku˚ malých a stˇredních podniku. ˚ Neustálé trendy globalizace se promítají také do ekonomického sektoru a dochází ke vzniku a rozvoji multinárodních korporací a rˇ etˇezcu. ˚ Malé a stˇrední podniky pusobí ˚ proti tomuto posilování monopolních tendencí. Díky své rychlé adaptaci na mˇenící se prostˇredí a potˇreby zákazníka jsou malé podniky nositeli nesˇcetných drobných inovací. MSP také dokážou pusobit ˚ v okrajových oblastech trhu, které jsou pro vˇetší podniky ménˇe atraktivní. Tato diplomová práce je zamˇerˇ ena na analýzu použitelnosti agilních metodik projektového rˇ ízení pro stˇrední a malé IT firmy. Cílem je nasadit vhodnou metodiku ve vybrané firmˇe a provést analýzu její pˇrinosu pro daný podnik. Práce je cˇ lenˇena do nˇekolika tématických cˇ ástí. Nejprve obsahuje úvod do agilních metodik projektového rˇ ízení, pˇredstavuje popis vybraných metodik a zabývá se charakteristikou a specifikou malých a stˇredních firem. V dalších cˇ ástech se pˇrivádí návrh metodiky pro malou IT firmu a její demonstraˇcní nasazení.

3

Kapitola 2

Agilní metodiky vývoje softwaru Agilní metoda vývoje software pˇrišla jako pˇrirozená reakce na pˇresun software z velkých výpoˇcetních center do každé firmy a každému na stul. ˚ Místo velkých týmu˚ se objevilo nesˇcíslnˇe malých skupinek, zkušenosti i opensource kód se zaˇcal po internetu vymˇenovat ˇ dˇríve netušeným zpusobem ˚ a to pˇrineslo i zmˇenu myšlení. Základem agilního pˇrístupu je úzká spolupráce programátoru˚ s cílovými uživateli systému. Dotaženo do extrému, uživatelé se na vývoji pˇrímo podílejí, protože jako souˇcást vývojového týmu programátorum ˚ poskytují okamžitou zpˇetnou vazbu a spolupracují pˇri všech fázích vývoje. V rámci rˇ ízení projektu je hlavní zmˇenou pˇrístupu ochota kdykoli pˇristoupit na zmˇenu zadání a rˇ ešení pˇredˇelat, když se objeví nový nápad, jak problém rˇ ešit a jak potˇreby klienta naplnit. Vše pomˇernˇe pˇeknˇe popisuje Manifest agilního programování [15]. Základní hodnoty agilního vývoje software: •

jednotlivci a interakce pˇred procesy a nástroji;

•

fungující software pˇred vyˇcerpávající dokumentací;

•

spolupráce se zákazníkem pˇred vyjednáváním o smlouvˇe;

•

reagování na zmˇeny pˇred dodržováním plánu.

Je nutné si uvˇedomit, že doslovné pˇrijetí tˇechto hodnot je cˇ astým problémem. Nemusíte to chápat ve smyslu, že agilní metodiky vubec ˚ nepotˇrebují tvoˇrit dokumentaci. Je tˇreba stále poˇcítat s nutností vykonávat cˇ innosti, které se týkají pravé cˇ ástí tˇechto bodu, ˚ i když v mnohdy znaˇcnˇe omezené míˇre. Dvanáct principu˚ agilního vývoje softwaru [15]. 1.

Naší nejvyšší prioritou je vyhovˇet zákazníkovi cˇ asným a prubˇ ˚ ežným dodáváním hodnotného softwaru. 4

2. A GILNÍ METODIKY VÝVOJE SOFTWARU 2.

Vítáme zmˇeny v požadavcích, a to i v pozdˇejších fázích vývoje.

3.

Agilní procesy podporují zmˇeny vedoucí ke zvýšení konkurenceschopnosti zákazníka. Dodáváme fungující software v intervalech týdnu˚ až mˇesícu, ˚ s preferencí kratší periody.

4.

Lidé z byznysu a vývoje musí spolupracovat dennˇe po celou dobu projektu.

5.

Budujeme projekty kolem motivovaných jednotlivcu. ˚ Vytváˇríme jim prostˇredí, podporujeme jejich potˇreby a duvˇ ˚ erˇ ujeme, že odvedou dobrou práci.

6.

Nejúˇcinnˇejším a nejefektnˇejším zpusobem ˚ sdˇelování informací vývojovému týmu z vnˇejšku i uvnitˇr nˇej je osobní konverzace.

7.

Hlavním mˇerˇ ítkem pokroku je fungující software.

8.

Agilní procesy podporují udržitelný rozvoj. Sponzoˇri, vývojáˇri i uživatelé by mˇeli být schopni udržet stálé tempo trvale.

9.

Agilitu zvyšuje neustálá pozornost vˇenovaná technické výjimeˇcnosti a dobrému designu.

10.

Jednoduchost – umˇení maximalizovat množství nevykonané práce – je klíˇcová.

11.

Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmu. ˚

12.

Tým se pravidelnˇe zamýšlí nad tím, jak se stát efektivnˇejším, a následnˇe koriguje a pˇrizpusobuje ˚ své chování a zvyklosti.

Obrázek 2.1: Tradiˇcní vs. agilní metodiky Z principu˚ agility je zˇrejmý odklon od principu˚ tradiˇcních metodik. Du˚ raz je kladen na spokojenost zákazníka a to hlavnˇe tím, že nemusí dlouho 5

2. A GILNÍ METODIKY VÝVOJE SOFTWARU cˇ ekat na výsledky, ty jsou mu dodávány v prubˇ ˚ ehu nˇekolika prvních iterací. Bˇehem dalších fází vývoje díky neustálé spolupráci managementu se zákazníkem a reakci na zmˇeny v požadavcích se zvyšuje stupenˇ spokojenosti s tím, že finální produkt bude souhlasnˇe pˇrijat. Pro tradiˇcní metodiky platí : Implementujeme pro dnešek, navrhujeme pro zítršek. Pro agilní metodiky platí : Implementujeme pro dnešek, navrhujeme pro úspˇešnou implementaci.

6

Kapitola 3

Scrum Co to je scrum? Scrum to není zkratka, to je termín z ragby, který znamená boj kolem míˇcu. Sám termín je možné urˇcit jako metodologie projektového rˇ ízení, která je založena na principech time managementu. Hlavní specifiˇcností je zapojení do procesu všech úˇcastníku, ˚ pˇriˇcemž každý úˇcastní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ˇejších metodologií a to je hlavnˇe díky své jednoduchosti. Jednoduše rˇ eˇceno scrum je to 3 role, 4 nebo více artefakty a 4 nebo více cˇ 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

3. S CRUM

Obrázek 3.2: Základ Scrumu [8]

Vlastník produktu Vlastník produktu je to reprezentant strany zákazníka a cˇ lovˇek odpovˇedný za vývoj produktu. Vlastník produktu je jediný koneˇcný bod rozhodnutí pro tým v projektu, a právˇe proto je to vždy jeden cˇ lovˇek a ne skupina nebo výbor. Funkce vlastníka produktu: •

je zodpovˇedny za formování vidˇení produktu;

•

rˇ ídí ROI(Return on investment);

•

rˇ ídí oˇceká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ˇedný za pˇrijetí kódu na konci každé iterace.

Scrum master Je to nejduležitˇ ˚ ejší role celé metodologie. Scrum master je zodpovˇedný za úspˇech scrumu na projektu. Scrum master je jako rozhraní mezi týmem a 8

3. S CRUM managementem. Obvykle je to projektový manager nebo team leader. Stojí za pˇripomínku to, že scrum master nerozdává úkoly týmu. V agilním vývoji tým je seberegulující a cross-funkˇcní. Základní funkce scrum masteru: •

vytváˇrí pˇrátelskou a duvˇ ˚ eryhodnou atmosféru;

•

zúˇcastnuje ˇ se mítinku˚ jako fasilitátor;

•

odstranuje ˇ pˇrekážky;

•

dˇelá viditelnými problémy a otevˇrené otázky;

•

odpovídá za dodržování postupu˚ a procesu˚ v týmu.

Scrum master provádí každodenní scrum schuze ˚ a sleduje pokrok týmu pomocí zvolených artefaktu, ˚ oznaˇcuje status všech úkolu˚ bˇehem sptintu. Scrum master muže ˚ pomáhat vlastníkovi produktu vytváˇret backlog pro tým. Scrum tým V scrumu tým je seberegulující, sebevedoucí a cross-funkˇcní. Tým je zodpovˇedný pˇred vlastníkem produktu za splnˇení všech úkolu˚ na sprint. Práce týmu je hodnocená jako práce jediné skupiny. Pˇrínos jednotlivých cˇ lenu˚ projektového týmu není nijak hodnocen kvuli ˚ tomu, že to pokazí seberegulaci v týmu. Funkce projektového týmu: •

je zodpovˇedný za ocenˇení backlogu;

•

rozhoduje o designu a implementaci;

•

pozoruje svuj ˚ pokrok(spolu se scrum masterem);

•

je zodpovˇedný pˇred vlastníkem produktu za výsledek.

Velikost týmu je omezena velikostí skupiny lidí, kteˇrí jsou schopní efektivnˇe spolupracovat. Typické týmy jsou o 7( ±2) lidech. Skládjí se z lidí s ruznými ˚ zruˇcnostmi. Všichni cˇ lenové scrum týmu jsou v nˇekteré míˇre vývojaˇri, analytici, testeˇri. Scrum tým je schopen se sebeorganizovat pro práci nad konkrétním úkolem bˇehem projektu, což dovoluje rychlé reagovat na ruzné ˚ typy úkolu. ˚

9

3. S CRUM

3.2

Scrum artefakty

Nejpouživanˇejšími artefakty scrumu jsou: •

produktový backlog (Product backlog);

•

backlog sprintu (Sprint backlog);

•

burndown chart;

•

seznam pˇrekážek (impediment list).

Produktový Backlog Produktový backlog je prioritizovaný seznam všeho, co muže ˚ být potˇreba v produktu a je jediným zdrojem požadavku˚ na jakoukoliv zmˇenu v produktu. Vlastník produktu je zodpovˇedný za obsah, dostupnost a prioritizaci backlogu. Scrum master, tým a všechny zúˇcastnˇené strany spolupracují pro vytváˇrení nejvíce úplného produktového backlogu. Práce nad backlogem produktu neznamená, že scrum tým nemuže ˚ vytváˇret a používat jiné artefakty. Pˇríkladem jiných artefaktu˚ muže ˚ být seznam ruzných ˚ rolí uživatelu˚ (user stories), popis workflow apod. Tyto artefakty nenahrazují produktový backlog a jen doplnují ˇ a upˇresnují ˇ jeho obsah. Vlastník produktu používá produktový backlog bˇehem plánování sprintu, aby mohl vysvˇetlit týmu klíˇcové body. Pak tým vybírá položky, které muže ˚ udˇelat za jeden sprint.

Obrázek 3.3: Pˇríklad produktového backlogu ve scrumu [9] 10

3. S CRUM Každý backlog produkru ve scrumu má urˇcité vlasnosti, kretými se liši od obyˇcejné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ˇrazené podle priority.

•

Všechny položky jsou ohodnocené.

•

Produktový backlog je živý dokument. Muže ˚ se mˇenit bˇehem projektu.

Backlog sprintu Backlog sprintu je výstupem sprint planning schuze. ˚ Je to v podstatˇe seznam vybraných z produktoého backlogu položek, které je tˇreba dokoncˇ it bˇehem sprintu. Po ukonˇcení sprintu tento seznam úkolu˚ je dodán jako jediný pˇrírustek ˚ funkˇcnosti. Na rozdíl od produktového backlogu úkoly v sprint backlogu jsou cˇ asovˇe omezené. Scrum tým je zodpovˇedný za dodržování termínu sprintu. Backlog sprintu ukazuje všechnu práci, kterou si vývojový tým vytýcˇ il jako nezbytnou ke splnˇení cíle daného sprintu. Sprint backlog se bˇehem sprintu mˇení; vývojový tým ho upravuje po celou dobu sprintu. Tyto úpravy jsou potˇrebné proto, že vývojový tým bˇehem sprintu získává více poznatku˚ o tom, co je potˇreba ke splnˇení cíle sprintu.

Obrázek 3.4: Pˇríklad backlogu sprintu ve scrumu[10] 11

3. S CRUM

Burndown chart Burndown chart je graf, který ukazuje kolik práce bylo udˇeláno za urˇcitý cˇ as. Je to jeden z duležitých ˚ ukazatelu, ˚ zda vývoj produktu probíhá tak, jak má. Na ose x je zobrazen cˇ as a na ose y souˇcet bodu˚ jednotlivých úkolu˚ bud’ ve sprintu nebo celého produktu. Mezi poˇctem bodu˚ a poˇctem dní obsažených ve sprintu je rovná cˇ ára, která pˇredstavuje ideální výkonnost.

Obrázek 3.5: Burndown chart [11] Pokud tým pracuje pˇríliš rychle, scrum master muže ˚ pˇridát další úkoly z produkt backlogu do sprint backlogu. Pokud je tým pˇríliš pomalý, rˇ eší scrum master duvody, ˚ proˇc se nedaˇrí pracovat se stanovenou rychlostí. Nelze-li zrychlit, scrum master pˇresune úkoly zpˇet ze sprint backlogu do produkt backlogu tak, aby rychlost práce vycházela pˇresnˇe na termín sprintu. Tyto pˇresuny nesmí dˇelat nikdo jiný – zejména ne vlastník produktu. Seznam pˇrekážek Pˇrekážka (anglicky impediment) je to cokoli co zdržuje, rozptyluje, pˇrerušuje tým nebo jednotlivého cˇ lena týmu od plnˇení aktivit zajišt’ujících dosažení cíle sprintu. Pˇrekažky se dˇelí na: •

personální(personal impediment);

•

týmové(team impediment); 12

3. S CRUM •

organizaˇcní(organizational impediment).

Ve scrumu pˇrekážky jsou velice duležité. ˚ Probrání a odstranˇení tˇechto problému˚ zlepši produktivitu. Každá pˇrekážka má životní cyklus uvedený na obrázku 3.6.

Obrázek 3.6: Životní cyklus pˇrekážky Scrum master je zodpovˇedný za odstranˇení pˇrekážek. Bˇehem scrum tréninku musí seznámit tým s ruznými ˚ druhy pˇrekážek a pomoct najít vlastní zpusob ˚ jejích odstranˇení. Obvykle je pro pˇrekážky urˇcené speciální místo na scrum desce.

Obrázek 3.7: Forma pro zaznamenání pˇrekážek

3.3

Scrum cˇ innosti

Základními scrum cˇ innostmi jsou: •

product backlog refinement;

•

sprint planning;

•

daily scrum; 13

3. S CRUM •

sprint review;

•

sprint retrospective.

Product backlog refinement Vzhledem k tomu, že položky v backlogu produktu jsou docela velké, zahrnují v sobˇe množství funkˇcnosti a protože myšlenky pˇricházejí a odcházejí a priority se mˇení, product backlog refinement je pokraˇcující cˇ innost v rámci celého scrum projektu. Tato cˇ innost zahrnuje, ale není omezena na: •

Dodržovat poˇradí v backlogu produktu.

•

Smazání nebo snížení úrovnˇe pro položku, která už není tak duležitá. ˚

•

Doplnˇení nebo zvýšení úrovnˇe pro položku, která vzniká nebo se stává duležitˇ ˚ ejší.

•

Rozdˇelování položek na menší cˇ ásti.

•

Ocenování ˇ položek.

Jedním z klíˇcových pˇrínosu˚ této cˇ innosti je pˇríprava na budoucí sprinty. Backlog refinement vˇenuje zvláštní pozornost pˇrípravˇe položek, které pˇricházejí k realizaci. Plánování sprintu Každý sprint se zaˇcíná se schuzky, ˚ která se jménuje sprint planning. Bˇehem tohoto setkání scrum tým spolupracuje nad volbou prací na budoucí sprint. Setkání sprint planning se úˇcastní celý tým. Spolu s vlastníkem produktu tým diskutuje o každé položce produktového backlogu, aby dospˇeli k její lepšímu spoleˇcnému chápání a tomu, co je nutné pro úspˇešné dokoncˇ ení prácí nad ní. Všechny schuzky ˚ scrumu jsou cˇ asovˇe omezené. Doporucˇ ená doba pro setkání sprint planning je dvˇe hodiny nebo ménˇe za týden trvajícího sprintu. Vzhledem k tomu, že schuzka ˚ je cˇ asovˇe omezená, úspˇech jednání sprint planning silnˇe záleží na kvalitˇe pruchodu ˚ produktovým backlogem. To je duvod, ˚ proˇc produkt backlog refinement je duležitá ˚ scrum cˇ innost. Ve scrumu se schuzka ˚ sprint planning skládá ze dvou epat: 1.

Zjistit jaká práce bude dokonˇcena bˇehem sprintu.

2.

Zjistit jak bude táto práce provédena. 14

3. S CRUM ˇ Cást první: Jakou práci budeme dˇelat? V první cˇ á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ˇreba udˇelat. Poˇcet položek backlogu produktu, které budou zvoleny na sprint je závislý jenom na vývojovem týmu. Pˇri rozhodování, kolik si položek vybrat tým bere na vˇedomí souˇcasný stav produktového incrementu, minulou výkonnost týmu, souˇcasnou 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 nemužou ˚ naˇrídit více práce na tým. ˇ Casto, 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ˇerˇ it na podstatu vˇecí a nesáhat do detailu, ˚ které mohou být zbyteˇcné pro dosážení cíle. ˇ Cást druhá: Jak bude práce provédena? Ve druhé cˇ ásti setkání tým rozhoduje jak vyrobit další produktový increment. Dˇelají se design a plánování, aby všichni byli pˇresvˇedˇceni o dokonˇcení prácí bˇehem sprintu. Práce, kterou je tˇreba udˇelat co nejdˇríve je rozdˇelena do jednotek délky jedného dne nebo ménˇe. Práce, která bude provédˇena pozdˇeji, muže ˚ být ponechána ve vˇetších celcích. Rozhodování o tom, jak dˇelat práci, je v kompetenci týmu, stejnˇe jako rozhodování o tom, co udˇelat, je odpovˇedností vlastníka produktu. Vlastník produktu se muže ˚ zúˇcastnit této cˇ ásti jednání s cílem odpovidání na otázky a rˇ ešení nedorozumˇení. V každém pˇrípadˇe je tˇreba, aby byl snadno dostupný. Daily scrum Scrum tým je seberegulující. Tým používá schuzky ˚ daily scrum, aby se zajistilo, že jsou na dobré cestˇe k dosažení cíle sprintu. Setkání se koná ve stejnou dobu a ve stejnem místˇe každý den. Každý cˇ len týmu poskytuje tˇri kousky informací: •

Co jsem dokázal od našeho posledního daily scrumu.

•

Co mám v plánu udˇelat do dalšího daily scrumu.

•

Co zdržuje muj ˚ pokrok.

Bˇehem daily scrum schuzky ˚ muže ˚ být krátká rˇ ada specifikovaných otázek a odpovˇedí, ale není tam žádná diskuse. Nicménˇe tým se muže ˚ sejít hned po setkání daily scrum a propracovat pˇrípadné problémy. 15

3. S CRUM Daily scrum to není výkaz pro vedení spoleˇcnosti, ani pro vlastníka produktu, ani pro scrum mastera. Jedná se o komunikaˇcní setkání v rámci týmu, aby bylo zajištˇeno, že jsou všichni na správné cestˇe. Pouze cˇ lenové týmu, vˇcetnˇe scrum mastera a vlastníka produktu, hovoˇrí bˇehem tohoto setkání. Ostatní zúˇcastnˇené strany mohou pˇrijít a poslouchat. Daily scrum je klíˇcovým prvkem scrumu, který se rˇ ídí transparentnosti, duvˇ ˚ erou a lepším výkonem. Všechny schuzky ˚ daily scrum jsou cˇ asovˇe omezené. Doporuˇcená doba trvání je patnáct minut. Sprint review Na konci sprintu tým a zúˇcastnˇené strany pˇrezkoumají jeho výstup. Doporuˇcená doba pro sprint review je jedna hodina. Ústˇredním bodem diskuse je produktový increment dokonˇcený v pru˚ bˇehu 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 muže ˚ zúˇcastnit schuze ˚ sprint review. Samozˇrejmˇe, že vlastník produktu dˇelá koneˇcné rozhodnutí o budoucnosti a aktualizuje backlog produktu podle potˇreby. Tým musí najít svuj ˚ vlastní zpusob, ˚ jak dˇelat sprint review. Demonstrace produktového incrementu je celkový pohled. Tým se diskutuje nad tím, co pozorovali bˇehem sprintu, jaké kdo mˇel nápady, podrobnˇe zkoumá backlog produktu a mluví o možném termínu dokonˇcení dalšího sprintu. Sprint review dává každému pˇrehled o souˇcasném produktovém incrementu. V tomto pˇrípadˇe je bˇežné provádˇet aktualizaci backlogu produktu jako soucˇ ást schuze ˚ 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ˇre a co není dobˇre, vypracuje plán na zlepšení v budoucnosti. Doporuˇcená doba trvání pro sprint retrospective je jedna hodina. Scrum tým zlepšuje svuj ˚ vlastní proces, který vždy zustává ˚ v rámci týmu.

3.4

Scrum deska

Pˇri používaní scrumu dˇeláme sprint backlog viditelným rozmíštˇením ho na scrum desce, pˇríklad které je uveden na obrázku 3.8. Každý rˇ ádek na scrum desce pˇredstavuje jednu user story. Každá karta 16

3. S CRUM

Obrázek 3.8: Pˇríklad scrum desky reprezentuje jeden z úkolu, na které jsou rozdˇeleny položky backlogu produktu zvolené týmem na daný sprint. Sloupce jdou zleva doprava. Story: Popis pˇríbˇehu uživatele (user story) ( "Jako uživatel chceme ... ") uvedený na tomto rˇ á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ˇri. Do sloupce WIP kartu pˇrenáší programátor, který se rozhodne pracovat nad tímto úkolem. Obvykle se to stává bˇehem daily scrum schuze. ˚ To Verify: Množina úkolu, ˚ které popisují testovací pˇrípady. Done: Množina úkolu, ˚ práce nad kterými je ukonˇcena. Tyto karty se odstranují ˇ na konci sprintu. Je možné odstranit nˇekteré karty i bˇehem sprintu, pokud máme jich na desce pˇríliš mnoho.

17

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ˇe Toyota [1]. On potˇreboval zpusob ˚ rychle komunikace mezi pracovníky, aby mohly zjistit kolik se dˇeje 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ˇri vˇedí co se "opravdu"dˇeje. Termín Kanban mužeme ˚ doslovnˇe pˇreložit jako Kan - viditelný, vizuální, a Ban – karta, deska. Továrny Toyota používají karty kanban, aby nedošlo k pˇretížení skladu˚ a pracovních míst vytvoˇrených pˇredem cˇ ástí. Technika kanban se ve vývoji softwaru snaží skoro o totéž. Celý systém rˇ ízení vývoje je postaven kolem vizualizace prubˇ ˚ ehu práce, omezení paralelních cˇ inností ("limit kanban", bˇežnˇeji se lze asi setkat se zkratkou WIP neboli Work In Progress) a sledování doby nutné ke splnˇení jednotlivých požadavku˚ 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ˇcné. Implementace kanbanu se muže lišit podle aktuální potˇreby.

4.1

Základní principy kanbanu

Zaˇcnˇete s tím, co dˇeláte ted’ Thechnika kanban nepˇredepisuje konkrétní sadu rolí nebo procesních kroku. ˚ Metodika kanban se zaˇcíná z rolí a procesu, ˚ které máte, a stimuluje prubˇ ˚ ežné, pˇrírustkové ˚ a evoluˇcní zmˇeny ve vášem systému. Kanban je thechnika rˇ ízení zmˇen, není tam žádná taková vˇec jako proces, kanban vývoj softwaru nebo projektové rˇ ízení kanban. Souhlas s evoluˇcními zmˇenami Tým musí souhlasit s tím, že kontinuální, postupné a evoluˇcní zmˇeny je 18

4. K ANBAN to zpusob, ˚ jak zlepšit stávající systém. Rozsáhlé zmˇeny se mohou zdát efektivnˇejšími, ale mají vyšší poruchovost kvuli ˚ odporu a strachu v organizaci. Respektujte aktuální proces, role, odpovˇednosti V týmu mužou ˚ existovat obavy pˇred budoucími zmˇenami. Je nutné s tím poˇcítat a zbavit se nežadoucího strachu. Také je pravdˇepodobné, že organizace má v souˇcasné dobˇe nˇekteré prvky, které dobˇre fungují a stojí za zachování. Tím, že souhlasíme respektovat stávající role, odpovˇednosti a pracovní zaˇrazení mužeme ˚ eliminovat poˇcáteˇcní obavy. To by nám mˇelo umožnit získat širší podporu iniciativy zavedení kanbanu. Vedení na všech úrovních Mˇelo by být podporováno vedení na všech úrovních organizace od jednotlivých pˇrispˇevatelu˚ do vrcholového managementu.

4.2

Základní praktiky kanbanu

Vizualizace toku práce Tok práce (workflow) je ve své podstatˇe neviditelný. Vizualizace workflow je jádrem pochopení toho, jak práce prochází. Bez pochopení pracovních postupu˚ je tˇežko dˇelat správné zmˇeny. Známým zpusobem ˚ vizualizace workflow je použití karet a desky se sloupci. Každý sloupec pˇredstavuje jednotlivý stav nebo krok ve workflow. Omezení work in progress Je tˇreba urˇcit možný poˇcet nedokonˇcených úkolu˚ v každé fázi procesu. Jak rˇ í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ˇrepínání kontextu nemá žádný pozitivní efekt. Kanban se k nˇemu staví negativnˇe a otevˇrenˇe rˇ íká: nastavte explicitní limit, kolik úkolu˚ muže ˚ být v daném stavu workflow.

4.3

Deska kanban

Tým používá pro práci Kanban-desku. Tato deska muže ˚ vypadat jak na obrázku 4.1. Sloupce jdou zleva doprava. Cíle projektu: Volitelný, ale užiteˇcný sloupec. Zde si mužeme ˚ uvést cíle 19

4. K ANBAN

Obrázek 4.1: Deska kanban [13]

projektu na vysoké úrovni, aby tým vidˇel a vˇedˇel co se po nich všechno chce. Napˇríklad "Zvýšení rychlosti o 20%" nebo "Pˇridat podporu pro systém Windows 8". Fronta úloh: Zde jsou uloženy úkoly, které jsou pˇripravené k provedení. Vždy do vykonání jde úloha s nejvyšší prioritou a její karta se pˇresune do dalšího sloupce. Propracování designu: Tento a další sloupce až do "Dokonˇceno"se mohou stˇrídat, protože tým rozhodne pˇres jaké kroky musí projít úkol, než pˇrijde do stavu "Hotovo". Napˇríklad, tento sloupec muže ˚ obsahovat problémy, pro které návrh kódu nebo rozhraní není zatím jasný. Když je diskuse dokonˇcena, úkol se pˇresune do dalšího sloupce. Vývoj: Zde úkol visí až do vývoje funkcí, které mají být dokonˇceny. Po dokonˇcení se pˇresune do dalšího sloupce. Nebo, v pˇrípadˇe když architektura není pravdivá, nebo není pˇresná - úkol se muže ˚ vrátit do pˇredchozí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á svuj ˚ deployment. Nˇekdy to znamená dát novou verzi na server, a nˇekdy jenom dát kód do úložištˇe. Dokonˇceno: Sem se nálepka dostane pouze tehdy, když budou dokon20

4. K ANBAN cˇ eny všechny práce nad úkolem. V každé práci jsou pˇrípady naléhavých úkolu. ˚ Plánované nebo ne, ale jsou to té, kteˇré potˇrebujeme udˇelat právˇe ted’. Pro takové úkoly muže ˚ být zavedeno zvláštní místo na desce (na obrázku oznaˇcené jako "expedite"). Expedite muže ˚ obsahovat jenom jeden naléhavý úkol a práce nad nim se musí zaˇcít okamžitˇe, aby byla dokonˇcena co nejdˇríve. Pokud vznikne další úkol, který bychom mohli odnést do expedite, musí byt pˇridán do fronty úloh. Ale nejduležitˇ ˚ ejšími na desce jsou cˇ ísla pod každým sloupcem. To je pocˇ et úkolu, ˚ které mohou být souˇcasnˇe v tˇechto sloupcích. Tato cˇ ísla jsou zvolena experimentálnˇe a závisejí na poˇctu vývojáˇru˚ v týmu.

4.4

Kanban vs. scrum

Kanban se liší od scrumu pˇredevším zamˇerˇ ením na úkol. Je-li základní orientace scrum týmu je úspˇešná realizace sprintu, ˚ pak na prvním místˇe kanbanu je úkol. Nejsou žádné sprinty, tým pracuje nad úkolem od zaˇcátku až do konce. Deployment a prezentace se provádí jenom kdy úkol je hotový. Tým nemusí odhadovat cˇ as potˇrebný pro dokonˇcení úkolu, protože to nemá smysl a je témˇerˇ na zaˇcátku vždy chybný. Pokud manažer vˇerˇ í, že tým úkol splní, tak proˇc by mˇel odhadovat cˇ as? Úloha manažera je vytvoˇrit frontu prioritizovaných úkolu, ˚ a úloha týmu je vykonat co nejvíce úkolu˚ z této fronty. A je to všechno. Kontrola není nutná. Vše, co potˇrebujeme od manažera je aby pˇridával úkoly do fronty nebo mˇenil jejich prioritu. To je to, jak se rˇ ídí projekt. Scrum Jsou povinné cˇ asovˇe 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í procesu. ˚ Cross-funkˇcní týmy jsou povinné.

Kanban ˇ Casovˇ e omezené iteraci nejsou povinné. Jsou možné samostatné rytmy pro plánování, deployment a zlepšení procesu. ˚ Závazky jsou volitelné. Hlavni metrikou plánování a zlepšení procesu˚ je cˇ aš vykonaní úkolu. Nejsou povinné cross-funkˇcní týmy. Jsou povolený úzképrofilové týmy.

21

4. K ANBAN Úkoly by mˇeli být rozdˇeleny do menších cˇ ásti, aby býli ukonˇcene bˇehem sprintu. Jsou povinné burndown diagramy. WIP omezená nepˇrímo(za sprint). Je povinné ocenování ˇ úkolu. ˚ Není možné pˇridat úkol do sprintu. Za sprint backlog je zodpovˇedný jeden tým. Pˇredepsané 3 role. Scrum deska se oˇcišt’uje mezi sprinty. Je povinný prioritizovaný product backlog.

Nejsou pˇresnˇe stanovené velikosti úkolu. ˚ Diagramy nejsou povinné. WIP omezená pˇrímo(po statusech). Ocenování ˇ úkolu˚ je nepovinné. Je možné pˇridavat nové úkoly. Kanban deska muže ˚ být spolupoužívaná nˇekolika týmy. Role nejsou pˇredepsané Kanban deska je nemˇenná. Prioritizace není povinná.

Hlavními odpovˇedmi na otázky "Proˇc to funguje?"pro scrum a kanban jsou: Proˇc funguje scrum? Cross-funkˇcní tým ˇ Casové omezení

Proˇc funguje kanban? Omezení WIP Viditelnost procesu pro všechny ˇ Rízený workflow

Scrum je velice pˇekná a jednoduchá metodologie, ale bohužel ve své cˇ isté formˇe je užiteˇcná jenom ve fázi programování. Problém je v tom, že scrum nemá specializaci, tým je cross-funkˇcní. Pˇredstavíme si firmu, kde jsou následující role: •

analytik;

•

návrháˇr;

•

inženýrský psycholog (vˇenuje se interview, testování použitelnosti, výbˇeru kontrolní skupiny apod.);

•

projektant uživatelských rozhraní;

•

grafický designér; 22

4. K ANBAN •

programátor;

•

tester;

•

projektový manažer.

Zjevnˇe specializace je. Možná všichni rozumí v grafickem designu, ale opaˇcným smˇerem to nefunguje. Když programátor muže ˚ se pustit do designu, to grafický designér nepujde ˚ programovat. V týmu programátoru˚ scrum dobˇre funguje, protože je tam vlastník produktu, který nˇekde bere požadavky, ví proˇc jeden požadavek má vyšší prioritu apod. Vzhledem ke struktuˇre náše firmy mužeme ˚ rˇ íct, že pˇred programováním je tam docela velký kus práce jako sbˇer a analýza požadavku, ˚ design a návrh UI. Je to celý samostatný proces, který trvá skoro stejnˇe s programováním, a který také je tˇreba rˇ ídit. Ale scrum nedává k tomu žádné instrumenty. Toto se donucuje týmy obracet k ruzným ˚ modifikacím scrumu, jednou z kterých je scrumban.

23

Kapitola 5

Scrumban Scrumban je to plnohodnotný scrum, uvnitˇr 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 svuj ˚ proces.

Scrumban je to pull-based systém, kde tým ménˇe pracuje nad plánováním práce, která již byla akceptována bˇehem planning schuze, ˚ a více se vˇenuje práci nad backlogem. Setkání scrumu (plánování, hodnocení, retrospektiva) mužou ˚ a musí probíhat i nadále, ale nepˇríliš cˇ asto. Kdy uvažovat o scrumbanu? •

Projekty údržby.

•

Event-driven práce.

•

Help desk/support.

•

Hardening/packaging fáze.

•

Projekty s cˇ astými a neˇcekanými pˇríbˇehy uživatele nebo programovými chybami.

•

Tým zamˇerˇ en na vývoj nových produktu. ˚

•

Pokud scrum je podroben pochybnosti kvuli ˚ otázkám workflow, zdroju˚ a procesu. ˚

24

5. S CRUMBAN

5.1

Principy scrumbanu

Omezení WIP Ve scrumu množství práce, která momentálnˇe probíhá, je omezené délkou sprintu. Scrumban omezuje práci pomocí omezení WIP ve sloupcích, stejnˇe jako kanban. Hlavní cíl scrumbanu je posunovat karty na pracovní desce zleva doprava. Je-li poˇcet karet v jednem sloupci nˇekdy pˇresáhne maximum, celý tým by mˇel jít do tohoto úkolu a pomoct posunout kartu dál. To by se mˇelo stát bez ohledu na to, jakou funkˇcní roli má cˇ len týmu. Plánovací schuze ˚ Ty by mˇely probíhat tak cˇ asto, jak je potˇreba. Pokud tým není schopen pravidelnˇe vytáhnout úkoly z vrcholu backlogu pˇri jejich normálním tempu, plánovací schuzka ˚ je povinná. Recenzní schuze ˚ Kontrola práce s klienty a zákazníky je to jediný zpusob, ˚ jak vývojový tým muže ˚ získat zpˇetnou vazbu nutnou pro správné pochopeni toho, nad cˇ ím pracují. Klienti dávají pˇrednost pravidelným schuzím. ˚ Retrospektivní setkání Ty se mohou mˇenit, ale obecné pravidlo je držet retrospektivu po každé revizi. To je nejužiteˇcnˇejší cˇ ást agilního procesu a musíme tomu vˇenovat pozornost. Standupy Pro scrumban nejužiteˇcnˇeiším formátem standupu je zamˇerˇ ení na toku karet na desce. Vzor ze scrumu (co jsem dˇelal vˇcera /co budu dˇelat dnes / jaké mám problémy) muže ˚ být pˇrevedeny na katry. Skupina karet se pohybuje po každém sloupci. Každá karta se struˇcnˇe popisuje a zjišt’uje se, co je nezbytné pro její pohyb smˇerem doprava na desce. To poskytuje mnohem vˇetší 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ˇcnou scrumban metrikou je cycle time. To je doba, potˇrebná k dokonˇcení práci nad úkolem v jedne kartˇe, která je mˇerˇ ena od okamžiku, kdy se poprvé zaˇcala (doba pruchodu ˚ desky kartou). V prubˇ ˚ ehu cˇ asu se muže ˚ provést statistická analýza všech karet v rámci projektu. Tím se získá prumˇ ˚ erný cycle time a smˇerodatná odchylka. To muže ˚ 25

5. S CRUMBAN být užiteˇcný plánovací nástroj na makroúrovni (seˇcíst poˇcet karet a vynásobit prumˇ ˚ erným cycle time).

5.2

Kanban vs. ScrumBan vs. Scrum

Na základˇe praktik, které se používají ve scrumu, kanbanu a scrumbanu vytvoˇríme srovnatelné tabulky tˇechto metodik [14]. Kanban Žádné pˇredepsané role Žádné schuze ˚

Role Každodenní schuze ˚

Recenzní a retrospektivní schuze ˚ Workflow

Nejsou pˇredepsané

Kontinuální

ScrumBan Tým + potˇrebné role Zajistit následnou práci na požadavcích, snížit dobu necˇ innosti cˇ lenu˚ týmu. Mužou ˚ být použity pro plánování vyplnˇení sloupcu˚ desky Mužou ˚ být provedeny jako potˇrebné pro zlepšení procesu a šíˇrení znalostí Stejný jako u Kanbanu. Jen se pˇridává limit ve sloupcech desky, aby se tažný proces stal pohodlnˇejším

Tabulka 5.1: Rozdíly kanbanu a scrumbanu

Deska / Artefakty Ceremonie

Iterace Ocenˇení Týmy Role

Scrum deska, backlogy, burndown diagramy každodenní scrum, plánování sprintu, ˚ revize sprintu, ˚ retrispektiva sprintu˚ ano (sprinty) ano musí být crossfunkˇcní vlastník produktu, scrum master, tým

Scrumban jen deska Každodenní scrum (plánování, revize a retrospektiva dle potˇreb) ne (kontinuální tok) ne (podobné velikosti) mohou být specializované tým + potˇrebné role

26

5. S CRUMBAN Týmová práce WIP Zmˇeny Backlog produktu Pˇrekážky

koaborativní dle potˇreby úkolu kontrolován obsahem sprintu musí cˇ ekát na pˇríští sprint seznam prioritních a ocenˇenych pˇrípadu˚ rˇ eší se okamžitˇe

shlukující se pro dosažení cílu˚ kontrolován stavem pracovního toku pˇridávají se dle potˇreb na desku (to do) jen v cˇ asových kartách vyhýbají se

Tabulka 5.2: Rozdíly scrumu a scrumbanu

27

Kapitola 6

Malé a stˇrední firmy Podle posudku EU [6] podnik je považován za malý nebo stˇrední ("MSP", anglicky SME - Small and Medium Enterprise) vzhledem k následujícím faktorum: ˚ •

poˇcet zamˇestnancu; ˚

•

roˇcní obrat nebo bilanˇcní suma. Kategorie Poˇcet zamˇestnancu˚ firmy Stˇrední <250 Malá <50 Mikro <10

Roˇcní obrat(EUR)

Bilanˇcní suma(EUR)

≤ 50 m ≤ 10 m ≤2m

≤ 43 m ≤ 10 m ≤2m

Tabulka 6.1: Kategorie firem podle EU [7] Tato tabulka je platná pouze pro soukromé firmy. Pokud je firma soucˇ ástí vˇetší skupiny firem, je nutné zapojit do výpoˇctu poˇcet zamˇestnancu/roˇ ˚ cní obrat/bilanˇcní sumu této skupiny. Je nutno poznamenat, že i když dodržování poˇctu pracovníku˚ je povinné, malý nebo stˇrední podnik si muže ˚ vybrat strop týkající se obratu nebo bilanˇcní sumy. Nemusí splnit oba stropy a muže ˚ jeden z nich pˇrekroˇcit, aniž ztratí své postavení [6]. Poˇcet zamˇestnancu˚ je rozhodujícím poˇcáteˇcním kritériem k urˇcení, do které kategorie podnik patˇrí. Vztahuje se na osoby s plným pracovním úvazkem, cˇ ásteˇcným pracovním úvazkem a sezónní pracovníky a zahrnuje: •

zamˇestnance;

•

osoby pracující pro podnik v podˇrízeném postavení, které jsou považovány za zamˇestnance v souladu s vnitrostátním právem;

•

vlastníky, kteˇrí rˇ ídí spoleˇcnost; 28

ˇ 6. M ALÉ A ST REDNÍ FIRMY

•

spoleˇcníky zapojené do bˇežné cˇ innosti podniku, kteˇrí využívají finanˇcních výhod plynoucích z podniku.

Uˇcni a studenti, kteˇrí jsou zapojeni do odborné pˇrípravy na základˇe smlouvy o uˇcnovském ˇ nebo odborném vzdˇelávání, se nezahrnují do poˇctu zamˇestnancu. ˚ Roˇcní obrat se urˇcuje výpoˇctem pˇríjmu, ˚ které podnik získal bˇehem daného roku z prodeje a ze služeb po odeˇctení vyplacených slev. Obrat by nemˇel zahrnovat danˇ z pˇridané hodnoty (DPH) ani jiné nepˇrímé danˇe. Bilanˇcní suma roˇcní rozvahy se vztahuje k hodnotˇe hlavních aktiv spoleˇcnosti [7].

6.1

Podnikové rˇízení

Podnikové rˇ ízení [21] je rozsáhlou kategorií zahrnující organizování, plánování, personalistiku, vedení a kontrolu dílˇcích podnikových cˇ inností na jednotlivých úrovních tak, aby podnik dosahoval stanovených cílu. ˚ Podstatou je optimální skloubení všech tˇechto cˇ inností. Nositeli rˇ ízení jsou bud’ sami vlastníci, nebo speciální orgány vytvoˇrené vlastníky a vlastníkum ˚ zodpovˇedné, konkrétnˇe podnikový management. Úrovnˇe rˇ ízení dˇelíme na vrcholovou, stˇrední a operativní. 1.

Na vrcholové úrovni má rˇ ízení strategický charakter, stanovuje základní smˇerˇ ování podniku, jeho koncepci. Na strategické rˇ ízení navazují nižší úrovnˇe rˇ ízení.

2.

Stˇrední management realizuje taktické rˇ ízení, stanovuje konkrétní postupy a prostˇredky vedoucí k realizaci podnikové strategie, zde jsou mnohem intenzivnˇeji sledovány kvantitativní cíle.

3.

Na nejnižší úrovni je rˇ ízení operativní, které pˇredstavuje konkrétní a detailní rˇ ízení vybrané oblasti v krátkém cˇ asovém horizontu.

ˇ Rízení podniku pˇredstavuje velice složitý a komplexní proces vyplývající ze skuteˇcnosti, že podnik sám o sobˇe je velmi složitý organismus. Jeho jednotlivé cˇ lánky, zabývající se ruznými ˚ cˇ innostmi, nemohou úˇcinnˇe fungovat bez urˇcité koordinace a vzájemné propojenosti. Všechny cˇ innosti v podniku musí být vzájemnˇe propojeny. ˇ Rízení malé firmy je specifické v mnoha ohledech. Vzhledem k malému poˇctu zamˇestnancu˚ i vedoucích pracovníku˚ napˇríklad dochází k soustˇredˇení rˇ ady funkcí do kompetence nˇekolika málo pracovníku, ˚ cˇ asto je to jeden až dva lidé. V malých firmách také obvykle pˇrevládá operativní rˇ ízení 29


nad strategickým, pˇriˇcemž naprosto pˇrevažuje ústní komunikace nad psanou. Práce se mezi zamˇestnance rozdˇeluje za chodu a spíše spontánnˇe, jakékoli rozhodnutí vychází obvykle z aktuálního rozpoložení podnikatele cˇ i vedoucího pracovníka. ˇ Rízení stˇrední firmy má obdobnˇe jako u malé firmy svá specifika. Firma má již více zamˇestnancu˚ i vedoucích pracovníku, ˚ kteˇrí již nedˇelají "vše", ale více se specializují na jednotlivé podnikatelské cˇ innosti. Vedle operativního rˇ ízení se klade stále vˇetší duraz ˚ i na rˇ ízení strategické. Obvykle již existuje alesponˇ základní rˇ ídicí dokumentace.

6.2

Organizaˇcní struktura

V každém podniku, ve kterém pracuje více než jeden pracovník, vzniká potˇreba specializace, koordinace a vytváˇrení útvaru. ˚ Specializace umožnuje ˇ konkrétnímu pracovníkovi soustˇredit 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ˇcní struktury pro podnik nemá žádná závazná pravidla, každý podnik má jinou organizaˇcní strategii a proto mohou mít jinak podobné podniky jinou organizaˇcní strukturu. Malé a stˇrední podniky zpravidla mají jednoduchou organizaˇcní strukturu s menším poˇctem úrovní vedení, než ve velkých firmach. Struktura MSP se skládá z funkˇcnˇe specializovaných organizaˇcních jednotek, které mají odpovˇednost a pravomoc k plnˇení dané funkce. Je to hlavnˇe zpuso˚ beno malým poˇctem zamˇestnancu˚ a množství firemních prosecu. ˚ To znamená, že MSP nemají mnoho lidí pro jednotlivé rˇ ídící cˇ innosti, a že na rˇ ídící pracovníky jsou kladeny vysoké odborné i cˇ asové nároky. Pˇríklad jednoduché organizaˇcní struktury malé IT firmy je uveden na obrázku 6.1.

Obrázek 6.1: Jednoduchá organizaˇcní struktura

30


6.3

Výhody MSP

Díky omezenosti kapitálových zdroju˚ malých a stˇredních podniku˚ mají tyto podniky možnost pružnˇe reagovat na zmˇeny, napˇr. na výkyvy trhu. Tato výhoda je dána tím, že MSP nejsou zužovány rozsáhlým investiˇcním majetkem, a tudíž mají možnosti produkˇcního využití. Malé a stˇrední podniky tedy nevyžadují takové velké zásahy do výrobní základny pˇri pˇrípadných zmˇenách ve výrobním programu. Malé a stˇrední podniky musí vyvíjet jistou inovaˇcní kreativitu k nutnému pˇrežití na trhu.V tˇechto podnicích je znaˇcnˇe více prostoru pro individuální iniciativu a souˇcasnˇe ménˇe omezujících organizaˇcních podmínek. V malých a stˇredních podnicích jsou také manažeˇri k inovovaným oblastem mnohem blíže, a tím jsou do tˇechto inovací více zainteresováni [16]. U malých a stˇredních podniku˚ je vˇetšinou pouze menší okruh vlastníku˚ než u velkých podniku˚ a také se tito vlastníci obvykle úˇcastní ve výkonném rˇ ízení podniku. To dává pˇredpoklad pro rychlejší pˇrijímání podnikatelských rozhodnutí u malých a stˇredních podniku˚ než u velkých podniku. ˚

6.4

Nevýhody MSP

Velkým omezením pro MSP je horší dostupnost k úvˇerum ˚ a tím menší finanˇcní síla, což muže ˚ být bariérou k dalšímu rozvoji podniku, které bez dostupnosti úvˇeru nemohou realizovat podnikové cíle a inovaˇcní zámˇery. Nedostatek kapitálového zázemí v MSP a souˇcasná nutnost pˇrežít v tvrdé konkurenci má za následek vyšší intenzitu práce a ménˇe pˇríznivé pracovní podmínky. Majitel malého, popˇrípadˇe stˇredního podniku je vˇetšinou také vrcholovým manažerem tohoto podniku. Cíle podniku jsou bezprostˇrednˇe v jeho zájmu, a tudíž ho vytyˇcený cíl vede k maximálnímu pracovnímu nasazení a totéž samozˇrejmˇe vyžaduje i po svých zamˇestnancích. Omezené možnosti získávání výhod z rozsahu produkce vycházejí z nízké koncentrace menších pˇríležitostí ve shromažd’ování výroby. Malé a stˇrední podniky mohou odebírat potˇrebný materiál na výrobu pouze v menším množství než velké podniky, a uniká jim tak sleva a výhodnˇejší dodací podmínky, které jsou vˇetšinou poskytovány pˇri dodávkách ve velkém množství. Pro malé a stˇrední podniky je obtížnˇejší ovlivnovat ˇ své potenciální zákazníky, protože disponují omezenými prostˇredky na propagaci a reklamu, což dále zpusobuje ˚ bariéry k rustu ˚ obratu a k zvyšování velikosti podniku. MSP svou produkci proto mohou umíst’ovat hlavnˇe na segmentech lokálních trhu. ˚ 31

Kapitola 7

Návrh metodiky pro malou firmu V dnešní dobˇe popularita agilních metodik vývoje software neustále roste. Podle každoroˇcního statistického pruzkumu ˚ "State of Agile Development"[17] mezi hlavními kritérii pˇrechodu spoleˇcností do agilních metodik patˇrí následující: •

zvýšení produktivity;

•

zlepšení kvality;

•

viditelnost situace v projektu;

•

snížení rizika;

•

zjednodušení procesu; ˚

•

snížení nákladu˚ na projekty;

•

lepší udržovatelnost projektu˚ v budoucnu;

•

zlepšení morálky týmu;

•

nˇekdy i organizace distribuovaného týmu.

Každá agilní metodika pˇredstavuje sebou seznam roli, artefaktu a direktiv. Problém je v tom, že tˇežko si pˇredstavit situaci, kdy budeme mít dvˇe ruzné ˚ firmy se stejnými vnitˇrními procesy. Proto pro úspˇešné nasazení každá spoleˇcnost musí provest urˇcité zmˇeny jak v organizaci své práci tak i ve zvolené metodice.

7.1

Popis metodiky

Pˇredstavíme si malou IT firmu, která úspˇešnˇe pracuje s použitím scrumu. To znamená, že tým je schopen doruˇcovat fungující a otestováný software na konci každého sprintu. Rychlost vývoje je udržitelná, mezí cˇ leny týmu je 32

7. N ÁVRH METODIKY PRO MALOU FIRMU skvˇelá spolupráce a žádný pocit promarnˇeného cˇ asu na okrajích. Hlavním úkolem retrospektiv je nacházet a odstranovat ˇ pˇrekážky. V tomto pˇrípadˇe je tˇežko rˇ íct, že zmˇena metodologie muže ˚ zpusobit ˚ rust ˚ produktivity týmu. Spíš je tˇreba hledat možnosti vnˇe týmu. Ale vˇetšina týmu˚ 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ˇe o tom jak správnˇe spoˇcítat velocity a kolik % cˇ asu alokovat na pˇrekvapení, odhad nepˇresnosti a podobné problémy. Pro malou firmu to znamená, že riziko krachu je velké a je tˇreba provádˇet zmˇeny. Scrumbun muže ˚ být tou metodologií, která pomuže ˚ vyjít na cestu vylepšování. Jak už bylo rˇ eˇceno v kapilole 4, scrumban pˇredstavuje aplikaci praktik kanbanu na scrum. Tato aplikace má 2 základní principy: 1.

Zaˇcináme s tím, co dˇeláme ted’. V pˇrípadˇe scrumu to znamená, že se na zaˇcátku zustanou ˚ všechny role, artifakty, ceremonie a retrospektivy.

2.

Souhlas s evoluˇcními zmˇenami. Vzhledem k tomu, že se nasazení provádí v malé firmˇe, pravdˇepodobnost nacházení ve spoleˇcnosti nahodilého cˇ lovˇeka, který nerespektuje byznys cíle dané firmy, je velice malá. Jinými slovy nebude problémem adaptovat, pˇridat nebo odstranit nˇekteré praktiky a politiky.

Po pochopení tˇechto principu˚ pˇrichází cˇ 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 zpusobem ˚ mají viditelnost toho, že položka backlogu prošla fáze od požadavku˚ do stavu done. Ale se práce uvnitˇr sprintu zustává ˚ neviditelná. Je duležité, ˚ aby workflow do a vevnitˇr sprintu byl stejnˇe viditelný, protože podle Davida J. Andersona [5] mnoho týmu˚ mají potíže právˇe s tímto aspektem. Scrumban je typicky o vizualizaci toku nevyˇrízených položek backlogu, než jednutlivých úkolu. ˚ Úlohy jsou vytvoˇreny pozdˇeji a neteˇcou celým workflow. Pro projekty rˇ ešené malými firmami zkusíme navrhnout poˇcáteˇcní 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ˇehem analýzy požadavku˚ zákazníka. 33

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ˇradnou prioritu. In Development. V tomto sloupci se nacházejí položký backlogu nad kterými momentálnˇe pracují programátoˇri. Ready for test. V tomto sloupci se nacházejí položký, které již prošli fází programování a jsou pˇripravene k testování. Test. V tomto sloupci se nacházejí položký backlogu nad kterými momentálnˇe pracují testeˇri. Done. V tomto sloupci se nacházejí položký, práce nad kterými již byla ukonˇcena v plné míˇre. Práce s deskou probíhá tak, že se nové položky pˇridávají do spodní cˇ asti sloupce backlog. Pohyb položek po desce prochází zleva doprava a shora dolu. ˚

Obrázek 7.2: Pohyb položek na desce V situaci, kdy se bˇehem testování odhalí chyby, kartiˇcka se ze sloupce test vrátí do horní cˇ asti sloupce priority. To znamená, že odstranování ˇ tˇechto chyb bude provedeno jakmile nˇekdo z vývojáˇru˚ skonˇci svou práci.

34


Obrázek 7.3: Pohyb chybové kartiˇcky

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 zpusobem ˚ výbˇeru poˇcáteˇcní hodnoty pro WIP je spustit nˇekolik iterací, aby bylo vidˇet kolik prumˇ ˚ ernˇe úkolu˚ lze zvládnout pomocí jedne iterace. Pak musíme vypoˇcítat velikost backlogu. Pokud tým muže ˚ splnit 10 úkolu˚ za týden, pak jeho velocity je dva úkoly dennˇe pro souˇcasný tým. Pokud iterace trvá jeden týden, pak velikost backlogu by mˇela být 10. Kromˇe toho backlog muže ˚ být rozdˇelen do nˇekolika sloupcu, ˚ aby bylo možné vizuální stanovení priorit položek prostˇrednictvím sloupcu. ˚

Obrázek 7.4: WIP omezení Jakmile v nˇejakém sloupci dosažená limita WIP, alternativou pro zahájení práce nad novou kartiˇckou je jít a pomáhat ostatním rˇ ešit jejich úkoly. Pomáhat je možné ve svých odborných znalostech nebo jít ve/proti smˇeru workflow (napˇr. vývojáˇri pomáhají testerum, ˚ testeˇri pomáhají analytikum). ˚ Zavedení omezení WIP muže ˚ zpusobit ˚ nˇekteré nelibosti tím, že cˇ lenové týmu nevždy budou schopní dˇelat to, co jim vyhovuje a na co jsou zvyklí. Bˇehem analýzy tˇechto nelibosti najdeme cestu do zlepšení pracovního procesu a omezeni WIP už nebude takým problémem. Podle Davida J. An35

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 zpusob, ˚ jak odstranit strach pˇred omezením WIP. V pru˚ bˇehu práce se týmové schopnosti zlepší a omezení WIP muže ˚ být utaženo, aby ještˇe více zlepšit spolupráci. Omezení WIP je skvˇelý zpusob ˚ jak rˇ ídit skuteˇcnou souˇcinnost na úrovni týmu. Metriky a správa workflow Než se dostat do výkonnostních ukazatelu˚ týmu je tˇreba mít jistotu toho, že náš systém pracuje správnˇe. Nejzákladnˇejší metrikou, která toto ukazuje, je sledování WIP v každé fázi workflow. Pro tyto úˇcely se bˇežnˇe používá cumulative flow diagram neboli burnup chart.

Obrázek 7.5: Cumulative flow diagram Dalšími metrikami, které již pˇrímo ukazují produktivitu týmu jsou lead time a cycle time. Mˇerˇ ení cˇ asu lead time se zaˇcíná, kdy je podána žádost na vypracování úkolu, a konˇcí pˇri jeho dodání. Doba cycle time se zaˇcíná, kdy je zahájena práce nad úkolem, a konˇcí, kdy položka je pˇripravená k dodání. Doba cycle time je vˇetší metrikou zpusobilosti ˚ procesu. Lead time je to, co vidí zákazník.

36


Obrázek 7.6: Znázornˇení lead time a cycle time

Obrázek 7.7: Pˇríklad lead time a cycle time diagramu˚ Udˇelat politiky procesu explicitními Nˇekteré scrum týmy dˇelají své týmové pravidla explicitními. Jedná se o podobný pˇrístup. Rozdíl je v tom, že musíme udˇelat explicitním celý proces.

Obrázek 7.8: Explicitní politiky ve scrumu Samoorganizující se tým nemuže ˚ fungovat, pokud nemá spoleˇcné chápání toho, jak se práce provádí. Explicitní politiky pomáhají neustálemu vylepšování workflow. Udˇelat proces viditelným je možné pomocí diskuse o tom "proˇc dˇelat vˇeci tímto zpusobem". ˚ Tyto diskuse je tˇreba provádˇet bˇehem plánovacích nebo reprospektivních schuzí. ˚ 37


Zlepšení spolupráce Ve chvílí, kdy náš proces zaˇcne normálnˇe fungovat, je tˇreba se dívat na retrospektivy jako na místo pro navrhování experimentu. ˚ Musíme vyhodnotit všechný nápady na to, jakým zpusobem ˚ je možné vylepšit celý proces nebo nˇejakou jeho cˇ ást, pˇrípadnˇe vyzkoušet nˇeco a na další retrospektivˇe pˇrezkoumat výsledky a rozhodnout, zda další kolo experimentování je nutné nebo zda je možné nasadit zmˇenu jako standardní provozní politiku. Backlog produktu Backlog je to seznam funkcí, které jsou urˇcené k poskytování uživatelum ˚ vyvinutého systému. Sestavení základního backlogu je duležitou ˚ etapou. Jedním ze zpusob ˚ u˚ jak vytvoˇrit backlog produktu muž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ˇrímo psát backlog jako seznam požadavku. ˚ 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 muže ˚ používat pro sestavení požadavku˚ na systém v malé firmˇe. Každá položka obsahuje tuto informaci: •

ID. Zadává poˇradí položek.

•

Name. Kratký a maximálnˇe jednoduchý název budoucí funkce.

•

User Story. Podrobný popis. Fráze podle šablony "Jako chci , která/aby <má cíl/hodnoty/znamená>."

•

Priority. Urˇcuje, jak velká je užiteˇcnost této funkce. Jakým zpusobem ˚ 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ž 15. 38

7. N ÁVRH METODIKY PRO MALOU FIRMU •

Story points. Jelikož vývojový tým má zkušenosti se scrumem, ocenˇení složitosti bylo zvoleno ve formátu story points. Vˇetšina programátoru˚ cˇ asto chápe story points ve smyslu cˇ lovˇekohodin, ale jak rˇ íká ve svém blogu Mike Cohn [18] není pˇrímá závislost mezi story points a cˇ asem. Proto, jestli je to pohodlné pro tým, to je možné nechat tento zpusob ˚ ocenˇení.

•

Definition of done. Seznam vlastností, které bude mít dokonˇcená položka. Nˇekdy obsahuje jednoduchý testový scénáˇr, který popisuje triviální posloupnost kroku˚ které musí vyplnit uživatel v triviálním pˇrípadˇe.

•

Notes. Pˇrípadné komentáˇre.

Mítinky Metodologie scrumbun pˇredepisuje provedení mítinku˚ stejných s mítinky scrumu, ale ty musí víc záležet na kontextu. Plánovací schuze ˚ Pro malou firmu naplánujeme každotýdenní mítink, bˇehem kterého bude naplánována pˇríští iterace a ocenˇená minulá. Program schuze ˚ bude vypadat takto: •

Obnovení grafu˚ a desky.

•

Pˇredled minulého týdne. Co se stálo? Proˇc? Co je tˇreba udˇelat pro zlepšení situace.

•

Zmˇena omezení WIP (když je to tˇreba).

•

Rozdˇelení položek backlogu na úkoly a ohodnocení nových user stories. Rozdˇelení položek backlogu se bude provádˇet na úkoly maximalního objemu 6.5 sp.

Review meetings Pˇrezkoumání práce s klienty a zákazníky je to jediný zpusob, ˚ kterým vývojový tým muže ˚ získat zpˇetnou vazbu, nutnou pro správnou adaptaci toho, nad cˇ ím pracují. Review mítink budeme provádˇet jakmile je hotova cˇ ást práce, která již muže ˚ být nasazena.

39


Standup meetings Ve scrumu se standup mítink provádí po jednoduché šablonˇe, kdy bˇehem 15 minut každý cˇ len týmu rˇ íká, co dˇelal vˇcera, co bude dˇelat dnes a co mu pˇrekáží. Pro scrumban efektivnˇejší bude pˇrevést tuto šablonu na workflow. Kdy tým prochází po jednotlivých sloupcích a struˇcnˇe diskutuje nad tím, co je tˇreba udˇelat, aby mohli posunout kartiˇcku doprava. V malé firmˇe standup schuze ˚ bude mít za úkol odhalení problému˚ a formování spoleˇcného chápání toho, co dˇelají ostatní cˇ lenové týmu. Struktura týmu Obvykle vývojový tým má organizaˇcní strukturu blízkou struktuˇre uvedené v kapilole 4.4. •

Analytici.

•

Návrháˇri.

•

Inženýrský psycholog(vˇenuje se interview, testování použitelnosti, výbˇeru kontrolní skupiny apod.)

•

Projektanti uživatelských rozhraní.

•

Grafický designér(vykonává všechný grafické úlohy na projektu).

•

Programátoˇri.

•

Testeˇri.

•

Projektový manažer.

Vzhledem k tomu, že máme malou firmu, nˇekteré role budou sdružené. Struktura vývojového týmu malé spoleˇcnosti má následující role: •

projektový manažer/ analytik/ návrháˇr;

•

programátoˇr/ projektant uživatelských rozhraní/ grafický designér;

•

tester. 40


7.2

Nástroje pro práci s metodikou

Návrhnutou metodiku se dá provozovat, i když máte jen propisku, pár papíru˚ a nˇeco, na co mužete ˚ nalepovat lísteˇcky. Rozebereme si tˇri možnosti. Jedna z nich je cˇ istˇe papírová a lehce se používá v prostˇredí 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ˇekterou mírou omezení mohou být použity na projektech malých firem. Tabule a nálepky Vytvoˇríme klasickou kanban desku s nálepkami a k tomu opravdu staˇcí bílá deska, nálepky a pár popisovaˇcu. ˚

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 projektu˚ na základˇe kanbanu a pomáhá vizualizaci toku práci, sledování prubˇ ˚ ehu projektu a provedení analýzy.

41


Obrázek 7.11: Aplikace kanban tool Kanban tool poskytuje výkonné on-line kanban desky, rychlé analýzy s bohatými funkcemi realného cˇ asu pro týmovou spolupráci. Tento nástroj perfektnˇe funguje ve vývoji softwaru a je urˇcen pro scrum a kanban týmy, které chtˇejí pˇredstavit svou práci na kanban desce. Zkušební verze tohoto nástroje byla použita bˇehem této diplomové práce. JIRA JIRA [20] je softwarový nástroj vyvíjený spoleˇcností Atlassian. JIRA podporuje a usnadnuje ˇ proces rˇ ízení projektu˚ a požadavku, ˚ nabízí flexibilní a uživatelské nástroje pro rˇ ízení a sledování pracovníku˚ pˇri výkonu plnˇení úkolu. ˚ JIRA je orientován na podporu dosažení oˇcekávaného výkonu na projektu. Charakteristiky a hlavní výhody jsou následující. •

Podpora projektového rˇ ízení (interní a externí rˇ ízení požadavku˚ a úkolu). ˚

•

Workflow management.

•

Neustále dostupné informace pro tým pˇres webové rozhraní.

•

Sledování a vyhodnocování kapacit.

•

Prukazná ˚ historie projektové komunikace.

•

Podpora pro klientský servis a helpdesk.

•

Sdílení komunikace, informací a dokumentu˚ v týmu. 42

7. N ÁVRH METODIKY PRO MALOU FIRMU •

Reporty, statistiky, historie evidence.

•

Sledování stavu projektu a rˇ ešení požadavku˚ zákazníkem.

•

Úkoly podle priorit, termínu˚ dokonˇcení.

•

Plnotextové vyhledávání, silné filtrovací nástroje.

•

Projektové statistiky.

Obrázek 7.12: Snímek cˇ ásti oficiální webové stránky projektu JIRA

43


7.3

Formuláˇre pro jednotlivé fáze metodiky

V této kapitole jsou uvedeny formuláˇre pro dokumentaci v jednotlivých fázích metodiky. Bˇehem zahájení nového projektu bude vyplnˇen formuláˇr, který je uveden na obrázku 7.13.

Obrázek 7.13: Formuláˇr pro požadavky zákazníka V tomto formuláˇri zákazník detailnˇe popíše projekt a vyplní konkrétní funkˇcní požadavky. V moment analýzy požadavku˚ bude sestaven produktový backlog. Odpovídající formuláˇr je uveden na obrázku 7.14.

44


Obrázek 7.14: Formuláˇr pro sestavení backlogu produktu Po zahájení fáze vývoje bˇehem každé plánovací schuze ˚ bude sestaven backlog iterace. Odpovídající formuláˇr je uveden na obrázku 7.15.

Obrázek 7.15: Formuláˇr pro sestavení backlogu iterace 45

7. N ÁVRH METODIKY PRO MALOU FIRMU Abychom mˇeli jistotu, že každá položka backlogu iterace je hotová a muže ˚ být pˇredána zákazníkovi musí projit urˇcité testy. Formuláˇr pro sestavení protokolu testování je uveden na obrázku 7.16.

Obrázek 7.16: Formuláˇr pro protokol testování V momentˇe, kdy nˇejaká cˇ ást funkcionality muže ˚ být pˇredána zákazníkovi, bude vyplnˇen protokol pˇredání. Odpovídající formuláˇr je uveden na obrázku 7.17.

46


Obrázek 7.17: Formuláˇr pro protokol pˇredání

47

Kapitola 8

Nasazení metodiky Tato a následující kapitoly se budou zabývat pˇredstavením možného praktického používání navržené metodiky na projektu v malé IT firmˇe.

8.1

Popis projektu

Jako zákazníka uvažujeme spoleˇcnost, která se zabývá výrobou a provozem fotokabin. Cílem projektu je vyrobit software, který bude nasazen na namontovaný zákazníkem v fotokabinˇe hardware. Daný software by mˇel mít následující vlastnosti: •

podporovat kamery rodiny Canon DSLR a standardní webkamery;

•

fotografovat a natáˇcet video;

•

mít možnost sdílení pˇres Facebook, Email, Twitter, Instagram;

•

umožnovat ˇ výbˇer formátu tisku;

•

umožnovat ˇ použití filtru˚ (Black&White, Sepia, Vintage apod.);

•

vytváˇret GIF animaci;

•

možnost fotit v režimu "green screen"a používat podklad z kolekcí;

•

vytváˇret koláže;

•

umožnovat ˇ placení v hotovosti a pomocí kreditní karty.

8.2

Pˇredstavení spoleˇcnosti

Pˇredstavíme si malou IT firmu o 10 zamˇestnancích, která se zabývá vývojem webových stránek, aplikací, e-shopu˚ apod. Necht’ spoleˇcnost už nˇekolik let úˇcinnˇe pusobí ˚ v daném segmentu trhu. Pro své minulé projekty spoleˇcnost používala metodiku scrum. 48

8. N ASAZENÍ METODIKY

Projektový tým této spoleˇcnosti se skládá z 8 lidí: •

2 analytici/ návrháˇri. Jeden ze kterých je rˇ editelem spoleˇcnosti a proto pusobí ˚ na projektech jenom na 30% úvazku;

•

4 programátoˇri, nˇekteré z nich mají dovednosti grafického designeru;

•

2 testeˇri, které mají menší zkušenosti s programováním.

8.3

Sestavení backlogu

Po dokonˇcení analýzy požadavku˚ zázazníka byl vytvoˇren prvotní backlog produktu.

Obrázek 8.1: Prvotní backlog

8.4

První iterace

První iterace vývoje byla provedena jako pilotní. Délka iterace byla zvolena na 5 dní a za hlavní úkol mˇela zjistit produktivitu týmu a nastavit správné hodnoty WIP. Start první iterace byl zaplánován 03.02.2014. 49

8. N ASAZENÍ METODIKY 8.4.1 Plánovací schuze ˚ Bˇehem plánovacího mítinku byly rozdˇeleny 2 položky backlogu s nejvyšší prioritou. Jelikož tým chápal story points jako cˇ lovˇekohodiny objem práce na jednu kartiˇcku byl zvolen ve výši maximálnˇe 6.5 sp. Položka interface se rozpadla na 8 jednotlivých úkolu˚ delky 7, 7, 6, 6, 6, 6, 6, 6 sp. Položka foto na 5 úkolu˚ delky 6 sp každý. Puvodní ˚ omezení WIP byly zvoleny následujícím zpusobem: ˚ •

pro seznam To Do - 10. Pro sloupec priority 5 - souhlasnˇe poˇctu programátoru; ˚

•

pro WIP - 9. Deska v moment zahájení iterace je uvedena na obrázku 8.2.

Obrázek 8.2: Deska na startu 1. iterace 03.02.14

8.4.2 Den první Standup mítink Bˇehem prvního standupu tým struˇcnˇe posoudil co je tˇreba udˇelat nad každým z úkolu. ˚ Analytici a tým se pˇrisvˇedˇcili o tom, že všichni chápou 50

8. N ASAZENÍ METODIKY cíl a svou cˇ ást práce. Programátoˇri si vzali úkoly podle vlastních priorit. Jelikož testeˇri zatím nemˇeli práce, šli dopomáhat programátorum. ˚ Popis prvního dne Bˇehem prvního dne vývoje tˇri programátoˇri spolu s testery dokázali dokonˇcit práci nad svými kartiˇckami. Tudíž 2 kartiˇcky pˇrešli do sloupce Test a ještˇe 1 do sloupce Ready for test. Tˇri programátoˇri vzali do rozpracování 3 zbývající nálepky. Deska na konci prvního dne je pˇrivedena na obrázku 8.3.

Obrázek 8.3: Deska na konci 1. dne

8.4.3 Den druhý Standup mítink Bˇehem standupu tým probral situaci na desce. Do backlogu byly pˇridány 3 zbývající nálepky v rámci user story foto. Deska po druhém standupu je pˇrivedena na obrázku 8.4.

51


Obrázek 8.4: Deska na startu 2. dne Popis druhého dne Bˇehem druhého vývojového dne úkol Interface 2 prošel všechny testovací pˇrípady a byl pˇrenesen do sloupce done. V úkole Interface 4 byly odhaleny chyby a tato nálepka se pˇresunula zpátky do sloupce Priority. Programátoˇri dokonˇcili práci nad úkoly Interface 5 a Interface 3. Tím pádem se chybová kartiˇcka pˇresunula do sloupce In Development a nad úkoly Interface 1 a Interface 5 zaˇcínají pracovat testeˇri spolu se svobodným programátorem. Deska na konci druhého dne je pˇrivedena na obrázku 8.5.


52

8. N ASAZENÍ METODIKY 8.4.4 Den tˇretí Standup mítink Bˇehem standupu tým probral situaci na desce. Kvuli ˚ tomu, že všechny kartiˇcky z user story Interface již jsou v práci, spoleˇcnˇe bylo rˇ ešeno pˇristoupit k práci nad user story Foto. Deska po tˇretím standupu je pˇrivedena na obrázku 8.6.

Obrázek 8.6: Deska na startu 3. dne

Popis tˇretího dne Bˇehem tˇretího vývojového dne úkoly Interface 1 a Interface 5 pˇrešli do stavu Done. Vývojáˇri skonˇcili prácí nad úkoly Interface 4, 6 a 7. Kartiˇcky Interface 3 a Interface 4 pˇrešli do sloupce Test. Tˇri programátoˇri zaˇcali pracovat na úkolech nové user story. Pátý vývojáˇr šel na pomoc testerum ˚ kvuli ˚ tomu, aby nedopustit zdržení ve fázi testování. Deska na konci tˇretího dne je pˇrivedena na obrázku 8.7. 8.4.5 Den cˇ tvrtý Standup mítink Bˇehem standupu tým probral situaci na desce. Kvuli ˚ tomu, že se blíží konec iterace bylo rˇ ešeno víc nevytahovat úkoly z backlogu a soustˇredit se na dokonˇcení prácí na úkolech, které jsou ve fázi vypracování. To znamená, že jakmile programátoˇri skonˇcí svou práci, pak jdou pomáhat testerum. ˚ 53



Popis cˇ tvrtého dne Bˇehem cˇ tvrtého vývojového dne se skonˇcila práce nad úkoly Interface 8, Foto 1 a Foto 2. V úkolu Interface 3 se odhalila závažná chyba. Nálepka Interface 4 prošla testovácími pˇrípady. Do sloupce Test byly pˇrenesene kartiˇcky Interface 6 a 7. Deska na konci cˇ tvrtého dne je pˇrivedena na obrázku 8.8.


54

8. N ASAZENÍ METODIKY 8.4.6 Den pátý

Standup mítink Bˇehem standupu tým probral situaci na desce. Kvuli ˚ tomu, že to byl poslední den iterace, bylo rˇ ešeno dokonˇcit maximální možné množství úkolu. ˚ To znamená pomahát testerum ˚ v jejích práci. Popis pátého dne Bˇehem posledního dne iterace byly opraveny chyby a znovu provedeny testy na úkolu Interface 3. Skonˇcil se vývoj zadání Foto 3. Nálepky Interface 6 a 7 byly pˇrevedeny do sloupce Done. Bohužel se nepodaˇrilo provest Interface 8 pˇres vše testovácí pˇrípady. Deska na konci první iterace je pˇrivedena na obrázku 8.9.

Obrázek 8.9: Deska na konci 1. iterace

8.4.7 Review mítink Na základˇe provedené iterace zákazníkovi byla pˇredána kostra systému skoro v plnˇe míˇre. Nevýznamné pˇripomínky zákazníka byly vyhodnoceny a budou opraveny bˇehem následující iterace. 55


8.5

Druhá iterace

8.5.1 Plánovací schuze ˚ Bˇehem plánovacího mítinku probˇehla represpektiva první iterace. Byl pˇredstaven cumulative flow diagram první iterace. Jako slabina provedené iterace byl ukázán problém s testováním. Pro usnadnˇení práce testeru˚ prošly zmˇeny v omezeních WIP - pro spoupec In Development bylo zadáno omezení v 4 soubˇežné úkoly. Toto by mˇelo podporovat spolupráce vývojáˇru˚ a testeru. ˚ Výkonnost týmu sestavila 7 nálepek, které dohromady dávají 43sp. Jelikož se žádný zásadní problém neobjevil, stejná produktivita je oˇcekávaná i v následujících iteracích.

Obrázek 8.10: Cumulative flow diagram první iterace

Pro provedení druhé iterace položka backlogu Kontrola byla rozdˇelena na 6 úkolu˚ s objemy 6, 6, 6, 6, 6 a 5 sp. Deska na startu druhé iteraci je pˇrivedena na obrázku 8.11. 56


Obrázek 8.11: Deska na startu druhé iteraci

8.6

Výsledek nasazení

Jelikož jde o demonstraˇcní nasazení návrhnuté metodiky budeme pˇredpokládat, že zainteresovaný v úspˇechu tým malé IT firmy dokáže držet tempo vyvoje 43 story points za jednu iteraci. Celkem náš backlog má 322 sp, což znamená, že týmu je na to tˇreba 7.49 týdnu˚ neboli kolem 38 pracovních dní. Ještˇe zhruba 7 dní budou vˇenovány kontrole se zákazníkem. To znamená, že na vývojovou cˇ ást potˇrebujeme 45 dnu. ˚

57

Kapitola 9

Zhodnocení Pro porovnání situace ve firmˇe pˇred a po nasazení metodiky vytvoˇríme Ganttuv ˚ diagram, demonstrující realizaci stejného projektu metodikou scrum. Jelikož firma má za sebou docela hodnˇe projektu, ˚ které byly provedené metodikou scrum, výkonnost týmu je známá. Délka sprintu cˇ íní 14 dní, což je skoro nejpopulárnˇejší výbˇer vˇetšin týmu. ˚

Obrázek 9.1: Ganttuv ˚ diagram pro metodiku scrum Z Ganttuvá ˚ diagramu je vidˇet, že oˇcekávaná délka vývojové cˇ ásti stejného projektu cˇ íní skoro 51 den. Což znamená, že použití navržené metodiky muže ˚ zvýšit produktivitu týmu malé firmy. Samozˇrejmˇe úspˇech zavedení nové metodologie není garantován a záleží na mnoha faktorech. •

Obava nových vˇecí.

•

Spolupráce v rámci týmu. 58

9. Z HODNOCENÍ •

Nálada týmu. Každý cˇ len týmu musí opravdu fandit své práci a snažit se pˇrispˇet valnou mˇeru do spoleˇcného úspˇechu.

•

Mangement musí být blíž k týmu a podporovat veškeré iniciativy cˇ lenu˚ týmu.

59

Kapitola 10

Závˇer Cílem této práce bylo popsat souˇcasnou situaci v oblasti využívání agilních metodik pro SW projekty. Duraz ˚ byl kladen na metodiky Scrum, Kanban a ScrumBan. Pro pochopení všech detailu˚ tˇechto metodik bylo tˇreba nastudovat dostateˇcné množství literatury. Jelikož na moment zaˇcátku práce nad diplomkou už jsem o Scrumu nˇeco vˇedˇel, zaˇcal jsem z nˇeho. Když jsem pˇrešel do Kanbanu a ScrumBanu velkým pˇrekvapením pro mˇe bylo cˇ tení diskusí o použitelnosti tˇechto metodik pro rˇ ízení SW projektu, ˚ kde kdysi fanoušci Scrumu, kteˇrí zkusili nasadit Kanban nebo ScrumBan ve svých firmách nechápali proˇc to neudˇelali dˇrív. V práci jsem poskytl podrobný popis principu˚ Scrumu, Kanbanu a ScrumBanu. Tyto metodiky byly zkombinované v jednu, která podle mého názoru nejvíce vyhovuje potˇrebám malých IT firem. Ukázal jsem nasazení této metodiky do týmu typické malé firmy. Výsledný text tak muže ˚ posloužit jako inspirace vysokoproduktivním týmum, ˚ které hledají zpusob ˚ dalšího rozvoje, jelikož obsahuje popis kroku˚ nutných pro nasazení.

60

Literatura [1]

Taiichi

Ohno.

Toyota

Production

System:

Beyond

Large-Scale

Production, 1988, ISBN-10: 0915299143 [2]

Henrik Kniberg, Mattias Skarin. Kanban and Scrum - making the most of both. Lulu.com. 2009. ISBN: 978-0-557-13832-6

[3]

Masaaki Imai. Kaizen: The Key To Japan's Competitive Success. McGraw-Hill/Irwin. 1986, ISBN-10: 007554332X.

[4]

Henrik Kniberg. Scrum and XP from the Trenches . How we do Scrum. Lulu.com. 2007, ISBN: 978-1-4303-2264-1

[5]

David J. Anderson, Donald G Reinertsen. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. 2010, ISBN-10: 0984521402

[6]

Official Journal of the European Union, Commission Recommendation of 6 May 2003 concerning the definition of micro, small and mediumsized enterprises. Available from: http://goo.gl/fDOQfw

[7]

European Commission. The new SME definition. User guide and model declaration. Available from: http://goo.gl/KRbSrR

61

[8]

Intro to Agile Scrum method of project management. Available from: http://goo.gl/GAJfqH

[9]

International Scrum Institute. The Scrum Product Backlog. Available from: http://goo.gl/VY8uGh

[10]

Mountain Goat Software. Sprint Backlog. 2012. Available from: http://goo.gl/w0Imdp

[11]

Microsoft Developer Network. Sprint Burndown (Scrum). Available from: http://goo.gl/8cVZkL

[12]

Mountain Goat Software. Scrum Task Board. 2012. Available from: http://goo.gl/ZxczEC

[13]

Jeff Patton: Kanban Development Oversimplified. 2009. Available from: http://goo.gl/VB5vHu

[14]

Savita Pahuja: What is Scrumban? AgileIQ Blog, 2012, Available from: http://goo.gl/6uTx3b

[15]

Manifest Agilního vývoje software. Available from: http://agilemanifesto.org/iso/cs/

[16]

Antonín Malach. a kolektiv: Jak podnikat po vstupu do EU. Grada. 2004.

[17]

VersionOne. State of Agile Survey 2013. Available from: http://goo.gl/UJ43ZL

62

[18]

Mike Cohn. How Do Story Points Relate to Hours? 2009. Available from: http://goo.gl/CGAvw7

[19]

Oficiální webová stranka projektu Kanban Tool. Available from: http://kanbantool.com/

[20]

Wikipedie. JIRA. Available from: http://cs.wikipedia.org/wiki/JIRA

[21]

Tomáš Vildomec, B.A. Diplomová práce „Strategická analýza podniku.“ 2010.

[22]

G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language User Guide, 2nd Edition. Addison-Wesley Professional, 2005.

63

ScrumBan pro malé a střední firmy

Recommend Documents