MASARYKOVA UNIVERZITA

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Systém řízení projektů v začínající servisní společnosti DIPLOMOVÁ PRÁCE Brno, podzim 2011 Bc. Tomáš Mačuga

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Zdenko Staníček, Ph.D. ii

3 iii

4 iv

5 Poděkování Chtěl bych poděkovat RNDr. Zdenko Staníčkovi, Ph.D. za vedení mé diplomové práce, dále bych rád poděkoval Nikol Kokešové za podporu a pomoc s grafickou úpravou této práce, paní Evě Kokešové za korektury, Milanu Mačugovi za konzultace a sdílení bohatých zkušeností s řízením výrobně orientované společnosti a v neposlední řadě Lukáši Smigovi za to, že mě na metodiku Kanban upozornil. v

6 Shrnutí Práce ve své teoretické části seznamuje se základními pojmy projektového řízení, standardy a metodikami. Jsou popsány jak klasické rigorózní metodiky vývoje software, tak novější agilní metodiky, kterým je věnována většina teoretické části. Díky minimálním požadavkům kladeným na organizaci je zástupce agilních metodik, metodika Kanban, vybrána jako vhodný kandidát pro řízení začínající servisně orientované společnosti. V praktické části je metodika Kanban zkombinována s přístupem k plánování projektu a toto spojení je demonstrováno na provedení projektu. Je představen a popsán postup, jak z plánů projektu nastavit prostředí pro jeho provedení. V závěru praktické části je popsána univerzálnost tohoto způsobu nejen pro řízení projektu ale také řízení procesu zpracování objednávek a řízení samotné společnosti. vi

7 Klíčová slova Kanban, agilní metodiky, 5 plánů, WBS, flow, pull systém, teorie omezení, projektové řízení vii

8 Obsah 1 Úvod Project, Program, Portfolio management Projektový management Projekt Program Portfolio Nástroje a techniky projektového managementu Trojimperativ SMART Logická rámcová matice WBS (Work Breakdown Structure) Standardy projektového řízení ICB (IPMA Competence Baseline) PMBoK (Project Management Body of Knowledge) PRINCE2 (PRojects IN Controlled Environments) ISO Rigorózní metodiky Vodopádový model životního cyklu Spirálový model životního cyklu Rational Unified Process (RUP) Agilní metodiky Agilní manifest a historie agilního přístupu Základní hodnoty agility Základní principy agilních metodik Extrémní programování (XP) Scrum Týmové role Scrum proces viii

9 5.4 Metoda Kanban Nasazení metodiky Kanban Personal Kanban Scrumban Realizace projektu Bumerangy.cz Plánování pomocí 5 plánů Strategie projektu Plán CO Plán JAK Plán S KÝM, plán KDY a plán ZA KOLIK Definice workflow a sestavení Kanban boardu Nastavení limitu WIP Měření a řízení toku Explicitní vyjádření pravidel procesu Různorodost řízených projektů a procesů Řízení multiprojektového prostředí Závěr Seznam zkratek Seznam obrázků Literatura ix

10 1 Úvod Vývoj software a jeho řízení v posledních letech prošlo mnoha změnami. Zákazníci nejsou ochotni čekat, až dodavatel vyvine komplexní řešení, které nakonec nemusí být podle jejich představ. Konkurence je silná a rychlost s jakou je organizace schopna uvádět na trh nové produkty mnohdy rozhoduje o jejich úspěchu. Zvlášť internetové projekty si již pár let nemůžou dovolit vyvíjet produkt a otálet s jeho vydáním, až když bude schopen nabídnout zákazníkovi vše, na co si vzpomene, ale potřebují produkt uvést na trh co nejrychleji a pravidelně vydávat jeho nové verze. Tato změna způsobila rozmach agilních metodik, které vycházejí vstříc potřebám inovativních firem v daleko větší míře, než jsou rigorózní metodiky zaměřené na vývoj velkých podnikových řešení schopny. Se změnou metodik vývoje přichází nutná změna ve způsobu řízení. Agilní tým, který má prostor pro vlastní rozvoj a důvěru v rozhodování, dodává mnohdy práci rychleji a hlavně ve vyšší kvalitě než direktivně řízená skupina lidí, která čeká na pokyny seshora a nemá motivaci pro vlastní iniciativu. Agilní přístup nelze aplikovat pouze na úrovni vývojových týmů, ale musí také dojít ke změně celé organizace. Top management firmy musí důvěřovat týmům, projektový manažeři zvyklí na direktivní způsob řízení musí přijmout roli pozorovatelů a hlídačů procesu. Členové týmů se musí naučit pracovat se změnami v rozhodovacím procesu a zvyknout si na větší míru autonomie, ale také na větší míru zodpovědnosti, která provází tuto formu svobody. Úlohou projektových manažerů se stává starost o dobro týmu a jeho odstiňování od každodenních problémů a požadavků trvalé organizace v průběhu vývoje. Tato změna může být do organizace zavedena revoluční cestou velkého třesku nebo plíživou cestou evoluce. Podstatná část teoretické části práce se věnuje evoluční metodě zavádění změn v organizaci, která se snaží minimalizovat rizika spojená s odmítnutím. Metoda Kanban je představena a popsána v rozsahu připravujícím podklady pro další práci s touto metodou v praktické části. Začínající společnosti málokdy praktikují některou z metodik vývoje a projektového řízení. Pokud se rozhodnou pro implementaci některé z metodik, volí většinou agilní metodiky z důvodu jejich mnohdy až minimalistických nároků na řízenou organizaci. V praktické části je metodika pro řízení společnosti malého rozsahu popsána. Použitelnost navržené metodiky je demonstrována formou ukázkového projektu, který je v souladu s metodikou naplánován a proveden. Požadavkem diplomové práce byl universalita navržené metodiky tak, ať není omezena pouze na IT projekty, která je prezentována řízením procesu zpracování objednávek. 1

11 2 Project, Program, Portfolio management 2.1 Projektový management Definice dle PMI (Project Management Institute): Uplatnění vědomostí, dovedností, nástrojů a technik na aktivity projektu za účelem dosažení projektových cílů. [1] [2] Úkolem projektového managementu není vytvoření konkrétních výstupů projektu, ale dohled nad postupem a udržování směru vývoje v souladu s plány projektu. 2.2 Projekt Projektovým řízením a projekty se zabývá větší množství organizací, přičemž každá si vytvořila vlastní definici projektu. Definice dle IPMA (International Project Management Association): Projekt je časově, nákladově a zdrojově omezený proces realizovaný za účelem vytvoření definovaných výstupů (rozsah naplnění projektových cílů) co do kvality, standardů a požadavků. [3] [4] Definice dle ISO : Projekt je jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení předem stanoveného cíle, který vyhovuje specifikovaným požadavkům, včetně omezení daných časem, náklady a zdroji. [5] Definice dle PMI: A project is a temporary endeavor undertaken to create a unique product, service, or result. [1] Volný překlad: Projekt je dočasná činnost prováděná za účelem vytvoření jedinečného produktu, služby nebo výsledku. Komentář Zdenko Staníčka k definicím projektu: Projekt je sekvence činností mající jeden začátek a jeden konec, přidělené zdroje a směřující k vytvoření určitých produktů. [5] 2

12 Projekt je speciálním případem procesu. Od běžných procesů projekty odlišuje zejména jejich jedinečnost. Každá instance projektu je jedinečná. Tento rys působí také většinu problémů při jejich řízení, resp. neřízení. Obr. 1 Projekt a složení činností, zdroj: [6] Úspěšnost projektu závisí na více kritériích než pouze dodání výstupů. Proto jsou v procesu přítomny kromě vývojových činností (vytvářejících hodnotu v projektu) také řídící, které pomáhají navigovat projekt směrem k úspěšnému ukončení. 2.3 Program Je skupina věcně souvisejících, společně řízených projektů a organizačních změn, které byly společně spuštěny za účelem dosažení cíle programu. Součástí programu mohou být i další činnosti, které nejsou přímou součástí jednotlivých projektů, které jsou do programu zahrnuty. [5] Programy organizace zavádí pro koordinaci a řízení většího množství projektů, které směřují k společnému cíli. V rámci programu jsou definovány také procesy pro řízení a sledování obchodních přínosů. Programový manažer program řídí prostřednictvím projektových manažerů projektů, které do programu spadají. Na rozdíl od projektu je cíl programu definován na vyšší úrovni detailu [7]. Lze tak řídit vývojové projekty, jenž cíl projektu vyjasněn nemají. Aby tento vývojový projekt nebyl úplnou neřízenou střelou, je k jeho řízení přistupováno jako k samostatnému projektu, jehož cílem je řízení vývojového projektu. Z jednoho projektu se tak stává soustava projektů, která je řízena jako program. 3

13 2.4 Portfolio Je soubor projektů a případně programů, které nemají společný cíl, a které byly dány dohromady za účelem řízení, kontroly, koordinace a optimalizace. Projekty a programy v portfoliu se vzájemně ovlivňují většinou pouze sdílenými zdroji a jejich časovým rámcem. [5] Portfolio se liší od programu a projektu svou kontinuálností [7]. Zatímco program i projekt mají jasně definovaný začátek a konec, portfolio není termínově omezeno. Sestavení a řízení portfolia je logickým důsledkem rozvoje projektového řízení v organizaci. Řízení portfolia zahrnuje zejména: rozhodování o zahrnutí projektu nebo programu do portfolia; promítání změn strategie a priorit společnosti do priorit a skladby projektů; optimalizaci požadavků na zdroje a průběh jejich použití; sledování, kontrola a vyhodnocování výkonnosti a efektivity projektů; dohlížení na plnění milníků a ukončování projektu; koordinace návaznosti projektů; řešení problémů a konfliktů. [7] Portfolio je nástrojem pro řízení značné části organizace, který pro svou úspěšnost mnohdy potřebuje velké množství organizačních změn a odpovídající podpůrné softwarové prostředky. 2.5 Nástroje a techniky projektového managementu V průběhu rozvoje projektového managementu se ustálila sada nástrojů a technik používaných při tvorbě plánů projektu. Výčet nezahrnuje všechny, ale pokrývá potřeby této práce Trojimperativ Původní anglický název tripleconstraint Martina Barnse [8] ustálil pro české prostředí jako trojimperativ Zdenko Staníček. Trojimperativ definuje podmínky, za kterých zainteresované strany očekávají dosažení cíle projektu. Úspěch projektu znamená splnění cíle nejen v stanoveném rozsahu (CO), ale i v plánovaném čase (KDY) a s plánovanými náklady (ZA KOLIK). V ideálním případě jsou všechny tři dimense trojimperativu nezměněny, nicméně při výskytu změn v průběhu realizace projektu je třeba těmto změnám přizpůsobit i trojimperativ. 4

14 Obr. 2 Trojimperativ, zdroj: [8] Například pokud je nutno dokončit projekt před plánovaným termínem, je třeba buď zvýšit rozpočet projektu pro zaplacení dodatečných lidských zdrojů nebo zmenšit rozsah plánované funkcionality SMART Mnemotechnická pomůcka definující vlastnosti správného cíle projektu. Cíl by měl být: Specific specifický a specifikovaný; Measurable měřitelný; Agreed akceptovaný; Realistic realistický; Timed termínovaný. [7] Takto definovaný cíl poskytuje dostatek podkladů pro validaci jeho splnění. Tato základní sada vlastností je někdy rozšiřována na SMARTi Logická rámcová matice Matice, která napomáhá vytvoření strategie projektu. Obsahuje následující seznam polí: Přínosy projektu důvod realizace projektu. Přínosů je dosahováno splněním cílů. Cíl projektu popis změny, která nastane realizací projektu [9]. Za dosažení cíle je zodpovědný projektový manažer spolu s týmem. Výstupy projektu klíčové výstupy, které určují cíl projektu. Může se jednat o meziprodukty předávané zákazníkovi při ukončení projektu. Činnosti klíčové činnosti projektu. Vstupy potřebné zdroje pro vykonání činností. Definice lidských a materiálních zdrojů. Náklady stručný rozpočet, případně zdroje pro financování nákladů. 1 Kde i znamená integrálnost cíle se strategií organizace 5

15 Ukazatele metriky z hlediska množství, jakosti a případně času. Zdroje údajů zdroje pro změření metrik. Předpoklady dosažení slouží k zamyšlení nad prostředím a okolím projektu. Ptáme se například: Co musí být splněno, abychom po splnění cíle dosáhli přínosů?. [10] Při vyplňování postupujeme následovně: Obr. 3 Logická rámcová matice, zdroj: [6] 1. Stanovení cíle projektu, sestavení trojimperativu, upřesnění vrcholu CO; 2. Určení klíčových výstupů projektu; 3. Pojmenování klíčových činností pro každý výstup alespoň jednu činnost; 4. Stanovení přínosů projektu; 5. Ověření logické správnosti projektu Zodpovězení otázek: Dosáhneme činnostmi výstupů? Splní výstupy cíl projektu? Budeme schopni dosáhnout přínosů splněním cíle? ; 6. Stanovení předpokladů; 7. Definice ukazatelů dosažení; 8. Definice zdrojů údajů; 9. Stanovení klíčových vstupů; 10. Určení finančních zdrojů; 11. Provedení celkové kontroly proveditelnosti projektu. [9] 6

16 2.5.4 WBS (Work Breakdown Structure) WBS, v češtině označováno často jako hierarchický rozklad produktů [8], je jedním ze základních přístupů k plánování projektu. Pojem Work zde v souladu s PMI je specifikací toho, CO je potřeba udělat. Popisuje a definuje celkový věcný rozsah projektu. Každá následná úroveň reprezentuje podrobnější definici produktů projektu [5]. WBS tak vyjadřuje cíl projektu a nikoliv cestu jak k němu dojít. Pro zachycení cesty k dosažení cíle je v praktické části diplomové práce uvedena vhodnější technika, stejně jako blíže předvedena WBS i s ilustrací její důležitosti pro plánování. 7

17 3 Standardy projektového řízení S rozvojem podnikání v průběhu 20. století přišla potřeba určité formalizace procesů a činností v organizacích. Mezi hlavní standardy projektového řízení patří PMBoK, ICB, PRINCE2 a do jisté míry také ISO Jako standardy projektového řízení jsou často chybně označovány metodiky a nástroje pro tvorbu software jako jsou RUP, Extremní programování nebo Scrum. Vlastní projektové řízení má širší záběr a standardy využívají metodiky pouze jako dílčí nástroje. 3.1 ICB (IPMA Competence Baseline) Standard není zaměřen na přesnou podobu definovaných procesů a jejich konkrétní aplikaci, ale na schopnosti a dovednosti kompetence projektových, programových a portfolio manažerů a členů jejich týmů. [7] IPMA (International Project Management Association) je mezinárodní organizace sdružující asociace projektových manažerů více než 50 států. Standard ICB vznikal v 60. letech na základě národních norem několika evropských států, což ovlivnilo jeho zaměření. Vzhledem k národnostním odlišnostem byl proto pojat jako přehled kompetencí a doporučených procesních kroků, které je třeba aplikovat na konkrétní situace. Důraz je tak kladen hlavně na schopnost projektového manažera vhodně aplikovat potřebné procesy a otevírá se tak možnost pro vlastní pojetí metodiky a kreativitu v jejím využívání. ICB dělí kompetence projektového řízení do tří oblastí: technické kompetence metody, techniky, nástroje; behaviorální kompetence měkké dovednosti (soft-skills); kontextové kompetence integrační a systémové znalosti a dovednosti. Každá oblast se dále rozpadá na jednotlivé elementy kompetencí. Kromě vlastního popisu elementu obsahuje metodika také nástin procesních kroků, jak daný element do organizace zavést. ICB slouží jako základní dokument, který je dále rozpracováván národními organizacemi, členy IPMA. Vznikají tak národní standardy NCB (National Competence Baseline). V České republice byl vydán Národní standard kompetencí projektového řízení, který navazuje na ICB verze 3.1 [7]. Certifikace probíhá v češtině a je rozdělena do čtyř, ne zcela hierarchických stupňů, které se odlišují zejména nároky kladenými na zkušenosti uchazečů. Zkouška se skládá z testu, řešení komplexního příkladu a pohovoru se zkoušejícími. 8

18 3.2 PMBoK (Project Management Body of Knowledge) Standard vytvořený a udržovaný sdružením PMI (Project Management Institute) vznikl v 70. letech 20. století na základě standardů americké armády. PMBoK je procesně orientovaná metodika, v níž je definováno pět hlavních rodin procesů (zahájení, plánování, koordinace, kontrola a uzavření), devět oblastí znalostí, jednotlivé procesy a jejich vzájemné vazby. Veškeré procesy a procesní toky mají definovány své vstupy, výstupy a transformace (úkony, metody, techniky). Mezi znalostní oblasti patří popisy procesů [11]: řízení koordinace a integrace projektů metodiky a techniky spojené s plánováním a realizací projektu s důrazem na provázanost jednotlivých procesů, procedur a technik v rámci projektu a na integrované řízení změn v rámci celého projektu; řízení rozsahu projektu definice pěti procesních fází stanovení rozsahu projektu; řízení času dodržení termínu ukončení projektu v rámci schváleného harmonogramu; řízení finančních toků odhady nákladů, nastavení rozpočtu projektu, kontrola finančních toků; řízení kvality plánování kvality, realizace kontrolních mechanismů, kontrola výstupu v souladu se stanovenými standardy; řízení lidských zdrojů plánování, získávání, ustavení a vedení týmu; řízení komunikace plánování komunikace, distribuce informací, reportování a monitoring stavu projektu, řízení vztahů se zadavateli; řízení projektových rizik identifikace rizik, jejich kvantitativní a kvalitativní analýza, vyhodnocení a ustanovení plánu prevence a práce s rizikem; řízení dodávek stanovení postupů pro zvládnutí řízení dodavatelských vztahů. 3.3 PRINCE2 (PRojects IN Controlled Environments) Standard byl vytvořený na základě zadání britského ministerstva průmyslu a obchodu. Rozšíření tohoto standardu napomohlo zejména jeho ustanovení jednou z nutných podmínek pro účast ve výběrových řízeních státních zakázek. Přestože standard původně vzniknul pro IT odvětví, je dnes použitelný univerzálně. Stejně jako u PMI se jedná o procesně orientovanou metodiku, zaměřuje se převážně na životní cyklus projektu. Nezabývá se tolik manažerskými dovednostmi a doporučenými technikami. Často je kombinován s metodikou řízení informatiky v organizacích ITIL (Information Technology Infrastructure Library). Z pohledu certifikace tak spíše doplňuje IPMA nebo PMI certifikáty. 9

19 3.4 ISO Mezinárodní norma pro řízení jakosti projektů. Norma je určena pro projekty všech typů, obsahuje obecné zásady a postupy. Na rozdíl od některých jiných norem ISO má tato pouze doporučující charakter a není proto zamýšlena pro účely certifikace. Norma není návodem pro řízení jednotlivých projektů, ale více se zaměřuje na procesy při řízení projektů a zvyšování jejich kvality. Obsahuje řadu strohých doporučení, jak by měla být nastavena pravidla v organizaci, která chce zvyšovat kvalitu svých projektů. 10

20 4 Rigorózní metodiky Když v 70. letech 20. století vznikl obor softwarového inženýrství, začal být čím dál více kladen důraz na řízení vývoje software. Výsledkem byla definice Vodopádového modelu životního cyklu. V průběhu dalších let se zvyšující se náročností projektů vývoje software, dochází k rozvoji dalších životních cyklů a také komplexnějších metodik vývoje. Tyto metodiky se vyznačují větším množstvím pevně definovaných procesů a fixací rozsahu funkcionality, která má být dodána. Rigorózní metodiky špatně reagují na pozdější změny rozsahu funkcionality, protože to znamená zasahovat do výsledků některé z předchozích fází a revizi všech následujících kroků. [12] Vycházejí z předpokladu, že procesy vývoje lze formalizovat a přesně popsat. Předpokládají jejich opakovatelnost. Dobře fungují v případě stabilních požadavků, které jsou hned z počátku projektu jasně definovány. Dá se říci, že jejich styl řízení je postaven na nedůvěře. Projektový manažer přímo direktivně řídí tým a určuje, kdo bude na které části projektu pracovat. [13] 4.1 Vodopádový model životního cyklu Model životního cyklu vývoje softwarového produktu, který je v dnešní době již dávno překonán. Často je využíván jako referenční model sloužící pro výuku a demonstraci základů projektového řízení. Charakteristickým znakem vodopádu je sekvenčnost jednotlivých fází. Všechny podstatné fáze: 1. Definice problému, poznání zákazníka, proniknutí do cílové oblasti, 2. Analýza a specifikace požadavků, 3. Návrh systému, 4. Implementace systému, 5. Integrace a testování systému, 6. Provoz a údržba, jsou prováděny ve stanoveném pořadí s minimálním množstvím iterací (v čistém pojetí vodopádu dokonce bez iterace) [12]. V rámci vyjmenovaných fází se lze pohybovat o jednu vpřed nebo zpět. Hlavní úskalím vodopádu je velmi dlouhá doba od začátku práce po představení produktu zákazníkovi. Při vývoji je tak obtížné reagovat na přání zákazníka, mnohdy ani nepřijdou. Při předání výsledků existuje vysoké riziko odmítnutí ze strany zákazníka pro nesplnění jeho požadavků, které se po dobu vývoje mohly razantně změnit. 11

21 4.2 Spirálový model životního cyklu Stejně jako u vodopádového modelu se nejedná o plnohodnotnou metodiku ale o životní cyklus vývoje. Spirálový model vývoje softwaru náleží do skupiny tzv. risk-driven přístupů, kdy další postup v jednotlivých fázích závisí na opakované analýze rizik. Na základě výsledků se rozhoduje o dalším směru vývoje, v krajních případech i o předčasném ukončení projektu. [12] Vývoj probíhá ve spirále od středu směrem ven. Spirála je rozdělena do kvadrantů: levý-horní stanovení cílů následné iterace, stanovení cílů, alternativ, omezujících podmínek; levý-dolní plánování dalšího postupu; pravý-horní analýza rizik směrem k následné iteraci; pravý-dolní implementace, vývoj, specifikace požadavků, testování. V úvodní fázi každého cyklu se identifikují tři základní skupiny parametrů: Cíle konkrétní části projektu, která je v daném cyklu řešena; Alternativy pro danou řešenou část; Omezující podmínky pro danou fázi projektu (cena, harmonogram, ). Obr. 4 Spirálový model, zdroj: 12

22 Každý cyklus má svůj definovaný význam: 1. Hledání globálních rizik, zpracování základního konceptu vývoje a rozhodnutí o konkrétních použitých metodách; 2. Sestavení a ověření specifikace požadavků na systém, plánování, určení cílů, alternativ a omezujících podmínek a analýza rizik; 3. Vytvoření a ověření detailního návrhu; 4. Implementace, testování a integrace. Spirálový životní cyklus se stal základem mnoha dnes existujících metodik, z rigorózních např. Rational Unified Process. 4.3 Rational Unified Process (RUP) Rozsáhlá, propracovaná, komerční, objektově orientovaná metodika vývoje software. RUP náleží do skupiny tzv. use-case-driven přístupů, kde je případ užití jakožto základní element definován jako posloupnost akcí prováděných systémem či uvnitř systému, která poskytuje určitou hodnotu uživateli systému (v nejobecnějším smyslu) [12]. Vývoj prostřednictvím RUP probíhá v iteracích, kde každá iterace se člení na čtyři fáze: zahájení definice účelu, rozsahu projektu a jeho obchodní kontext; projektování analýza potřeb projektu a zákazníka, definice základů architektury; realizace vývoj designu aplikace a tvorba zdrojových kódů; předání předání zákazníkovi, nebo do další fáze projektu. Metodika definuje 6 základních obecných praktik: iterativní vývoj software vychází ze Spirálového životního cyklu, průběžně se snaží detekovat rizika, lépe pracuje se správou změn; správa a řízení požadavků reakce na zákazníkovu neschopnost popsat dostatečně podrobně své potřeby; použití komponentové architektury metodická, systematická cesta návrhu, vývoje a ověření správnosti architektury skrze šablony, architektonické styly a pravidla designu; vizuální modelování software použití jazyka UML znamená zjednodušení komunikace v týmu, zlepšení konzistence projektu a vyšší pravděpodobnost správného uchopení řešeného systému; průběžné zajišťování a ověřování kvality daleko úspornější je přijít na problémy ve fázi návrhu než měnit již implementovaný systém; 13

23 řízení změn změny je třeba řešit systematicky a organizovaně, zákazník tak pravděpodobně dostane výstup dle jeho představ. Oproti agilním metodikám se jedná o poměrně těžkou metodiku, která obsahuje více než 120 nařízení, kterými by se měla organizace řídit, pokud chce prohlásit, že má implementovánu metodiku Rational Unified Process. 14

24 5 Agilní metodiky Agilita je především o schopnosti reagovat na změny [14]. Agilní metodiky se snaží od rigorózních přístupů odlišit především tím, že se změnami počítají a vše jim podřizují. Nenajdeme v nich přesné plány od začátku do konce projektu ale spíše odhady, kam se má projekt dostat a popis chtěného cílového stavu. Jedná se o změnu oproti trojimperativu rigorózních metodik, kde naplánování projektu znamená co nejpřesnější určení všech jeho vrcholů s důrazem na funkcionalitu, čímž často docházelo k přesáhnutí rozpočtu i termínu. Agilní metodiky používají upravený trojimperativ, fixují čas a zdroje vyhrazené pro projekt, ale funkcionalita je předmětem dalšího plánování [15]. Přesnější plány jsou tvořeny s výhledem na několik týdnů, obvykle odpovídají dvěma až třem iteracím. Přesné plánování v delších horizontech by bylo plýtváním, protože jednak je časově náročnější a obvykle nezůstane beze změny. Pravidelnost plánování a kratší interval, který musí být naplánován, výrazně zkracuje a zlevňuje celý proces řízení. Aby se o metodice dalo prohlásit, že je agilní, měla by splňovat tzv. agilní pyramidu (někdy též agilní ledovec). Příměr k ledovci více odpovídá realitě. Vrcholek ledovce nad hladinou by se dal přirovnat k aktivitám a procesům metodiky. Ty se metodika od metodiky liší. Důležité je, aby stavěly všechny na společných hodnotách (viz. Manifest agilního vývoje) a principech (viz. Základní principy agilních metodik) [14]. 5.1 Agilní manifest a historie agilního přístupu Jako mnoho dalších přístupů v IT také agilní metodiky mají své kořeny v průmyslové výrobě. Po 2. světové válce v roce 1949 v Japonsku Toyota zavádí svůj Toyota Production System (TPS) rozvíjející dále například techniku Just-In-Time, která se stává základem pro Lean Production (tzv. štíhlou výrobu). Ústřední myšlenkou štíhlé výroby je minimalizace výroby na sklad. Produkuje se tak přesně tolik, kolik vyžaduje další krok výrobního postupu. Nástroji štíhlé výroby jsou v TPS například kanban system (signalizace možnosti vyrábět prostřednictvím plastikových karet, kterých je v oběhu omezený počet) a Kaizen (důraz kladený na neustálý rozvoj znalostí a schopností pracovníků ve výrobním procesu). [14] Na základě zkušeností a pozorování firem řízených v souladu s principy štíhlé výroby sepisují v roce 1986 Hirotaka Takeuchi a Ikujiro Nonaka článek The New Product Development Game [16]. Definují šest principů úspěšných společností, které dávají základ novému směru Lean Development Production. 15

25 Tyto principy jsou: vestavěná nestabilita, sebe-organizující týmy, překrývající se vývojové fáze, multilearning dvě dimenze učení: napříč úrovněmi (jednotlivec, skupina, organizace) a napříč oblastmi (studium mimo vlastní specializaci, odpovídá pojmu T-Shaped osobnosti), minimální řízení (ze strany vedoucího týmu), předávání znalostí a jejich sdílení. [16] V roce 1990 na základě práce Takeuchiho a Nonaky začínají Ken Schwaber, Jeff Sutherland a mnoho dalších nezávisle na sobě experimentovat s využitím naznačených principů v řízení projektů. Roky 1995 a 1996 jsou hlavním obdobím rozmachu nových agilních metodik, jako jsou Scrum, Feature-driven Development, Extrémní programování (XP), Crystal Clear a další. V průběhu roku 2000 vyšlo několik článků odkazujících na tzv. lehké metodiky. V září toho roku Bob Martin přišel s myšlenkou uspořádání konference, kdy se všichni přívrženci lehkých metodik sejdou na jednom místě. Konečně února 2001 bylo uspořádáno setkání 17ti lidí s cílem pojmenovat společné charakteristiky všech jejich metodik. Po dlouhých diskuzích se shodli na dokumentu nazvaném Manifest agilního vývoje software. Manifest vyjmenovává čtyři základní hodnoty, ze kterých agilní metodiky vycházejí. Na základě těchto hodnot je dále rozvedeno dvanáct principů agility [14] Základní hodnoty agility V manifestu [17] se autoři shodli na následujících hodnotách, které mají metodiky považované za agilní společné: 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. Častým problémem je nepochopení těchto hodnot, resp. doslovné přijetí výše vyjmenovaných bodů ve smyslu V agilních metodikách není třeba vůbec tvořit dokumentaci. Ačkoliv je důraz kladen vždy na levé strany položek manifestu, je třeba stále počítat s nutností vykonávat činnosti spojené s pravou částí, i když v mnohdy značně omezené míře. 16

26 5.1.2 Základní principy agilních metodik Ve většině principů lze najít inspiraci článkem Takeuchiho a Nonaky hlavně v aspektech sebeorganizujících týmů, trvalého zlepšování a práce se změnami v projektu. 12 principů Agilního manifestu: Naší největší prioritou je uspokojení zákazníka prostřednictvím včasného a trvalého dodávání hodnotného software. Vítáme měnící se požadavky, dokonce i v pozdních fázích vývoje. Agilní procesy využívají změnu pro dosažení zákazníkovi konkurenční výhody. Dodávat fungující software často, od intervalu několika týdnů do několika měsíců, s cílem časový interval zkracovat. Vývojáři a obchodní oddělení musí spolupracovat na denní bázi v průběhu celého projektu. Na projektech zaměstnejte motivované jedince. Vytvořte jim prostředí a podmínky podporující jejich potřeby a důvěřujte jim, že práci úspěšně dokončí. Nejúčinnější a nejefektivnější způsob předání informací vývojovému týmu a jejich sdílení uvnitř týmu je přímá (face-to-face) komunikace. Pracující software je hlavním ukazatelem postupu vývoje. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři a uživatelé by měli být schopni udržovat konstantní tempo rozvoje do nekonečna. Trvalá pozornost věnovaná zlepšování technické úrovně a kvality návrhu aplikací zlepšuje agilitu. Jednoduchost umění maximalizace množství práce, kterou není třeba udělat je základ. Nejlepší architektury, požadavky a návrhy vznikají v sebe-organizujících týmech. V pravidelných intervalech tým přemítá, jak se stát daleko efektivnějším. Na základě nápadů a zkušeností ze schůzky upravuje a nastavuje své fungování. [17] Z principů agility je zřejmý odklon od principů rigorózních metodik. Důraz je kladen na tým a úkolem středního managementu je upuštění od direktivního způsobu řízení a poskytnutí prostoru týmu pro řešení každodenních problémů ve vlastní režii. Projektový manažer se tak může soustředit na vlastní řízení projektu, sledování okolí a širšího kontextu. Zákazník už nemusí rok čekat na první výsledky, ty jsou mu dodávány v průběhu několika prvních iterací. S postupem času, zákazníkovou zpětnou vazbou a změnami jeho preferencí týkajících se funkcionality výsledného produktu, je stále upřesňován směr dalšího vývoje, což snižuje míru rizika nepřijetí finální dodávky zákazníkem. Vývoj tak odpovídá více realitě, kdy zákazník dopředu přesně netuší, co konkrétně by mělo být výsledkem, ale má pouze hrubou představu, která je postupem času upřesňována. 17

27 Principy také poukazují na omezení agilních metodik. Ze sociologického hlediska musí mít týmy omezenou velikost 5-9 členů. Pod 5 členů se špatně dosahuje cross-functional složení týmu, nad 9 členů začíná sebe-organizace týmu vykazovat zvýšené časové nároky (prodlužování denních schůzek) a postupně se snižuje efektivita přímé komunikace. 5.2 Extrémní programování (XP) XP je jedna z neoblíbenějších agilních metodik. Porovnáním Agilního manifestu a XP lze najít přímou inspiraci. Metodika staví na hodnotách (jednoduchost, komunikace, zpětná vazba, odvaha) a pravidlech, které se týkají jednotlivých oblastí (plánování, řízení, návrh, kódování, testování). Kent Beck ve své knize [18], popisuje 12 principů, kterými by se měly týmy praktikující XP řídit: Plánovací hra rychlé určení rozsahu další verze na začátku každého cyklu. Účastní se jí všechny zainteresované strany. Zástupce zákazníka určuje rozsah byznys požadavků v součinnosti s týmem, který odhaduje jejich časovou náročnost a proveditelnost. Pokud plán neodpovídá realitě, je upraven; Malé dodávky vydávání nových verzí v krátkých cyklech i po přidání jednoduché funkcionality; Metafory celý vývoj je veden pomocí jednoduchého sdíleného příběhu popisujícího, jak celý systém funguje. Metafory pomáhají sjednotit slovník vývojového týmu a zákazníka, který nemá obvykle potřebný technický vhled; Jednoduchý návrh systém by měl být navržený co nejjednodušeji vzhledem k aktuální situaci. Pokud není rozšiřitelnost jasným požadavkem zákazníka, programátor nesmí komplikovat návrh vlastními spekulacemi; Testování programátoři průběžně píšou jednotkové testy. Jejich splnění je nutným předpokladem dalšího vývoje. Zákazníci pomocí vlastních akceptačních testů demonstrují úspěšné dokončení konkrétní vlastnosti; Refactoring restrukturalizace kódu s cílem odstranění duplicit, zlepšení komunikace, zjednodušení nebo přidání flexibility. Refactoring nemá vliv na chování systému; Párové programování dva programátoři u jednoho počítače. Jeden programuje, druhý vznáší dotazy, které mají odhalit dopady práce prvního na funkcionalitu, bezpečnost, optimalizace atd.; Společné vlastnictví kódu celý tým je zodpovědný za zdrojový kód. Pro zajištění této zodpovědnosti má každý člen týmu právo zasahovat do cizích souborů se zdrojovým kódem; Průběžná integrace vždy s dokončením nějaké části funkcionality je třeba tuto část integrovat do celku a nechat proběhnout všechny testy pro kontrolu integrity; 40 hodinový týden je důležité nastavit pravidla pro přesčasy. Nikdy by neměly nastat dva týdny přesčasů po sobě; 18

28 Přítomnost zákazníka je důležité mít v týmu pracovníka vyhrazeného zákazníkem, který bude dostupný k zodpovídání dotazů; Štábní kultura jako nutná podmínka společného vlastnictví kódu je třeba se při programování řídit pravidly zápisu kódu. Většina principů se stala obecně uznávanými přístupy, které dále přejímají další metodiky. Například párové programování, pravidelné vydávání nových verzí, zapojení zástupce zákazníka do projektu. 5.3 Scrum Původ názvu lze dohledat v článku [16], kde Takeuchi a Nonaka popisují proces prováděný cross-functional týmem napříč několika překrývajícími se fázemi. Tento proces nazvali jako holistic nebo rugby přístup. Myšlenky se ujalo několik autorů, kteří ji dále v průběhu 90. let rozvíjeli až do současné podoby. Od rugby přístupu už není daleko k Scrumu (skrumáž, mlýnice), jakožto jedné ze silně týmově orientovaných činností v rugby. [12] Scrum byl prvně oficiálně představen širšímu publiku v roce 1995 na konferenci OOPSLA 95 autory Jeffem Sutherlandem a Kenem Schwaberem. V roce 2001 vychází kniha Agile Software Development with Scrum, která jako první přináší ucelený popis jeho zavádění do organizace. Nasazování probíhá často formou revoluce, kdy víceméně ze dne na den organizace převezme principy a proces Scrumu a začne se jimi řídit. Ve větších organizacích je Scrum nasazen v podobě pilotního projektu. Ať už přichází změna zdola-nahoru (tým chce zavést agilní přístup do své práce) nebo shora-dolů (vedení společnosti se rozhodne o zavedení agilní metodiky), vždy se Scrum zavádí metodou Velkého třesku. [14] To s sebou nese značné riziko odmítnutí změny, případně přímo aktivního odporu a bránění změně stejně, a mnohdy ze stejných důvodů, jako při zavádění velkých podnikových informačních systému. V případě prosazování změny týmem může nasazení komplikovat management, který neprojeví dostatek důvěry v sebe-organizující povahu týmu, čímž ve velké míře omezí přínosy této metodiky. Kromě zvýšené důvěry v tým je třeba nastavit vnitrofiremní politiku, která bude chránit celistvost týmu po celou dobu existence projektu. Pokud změnu prosazuje management, může kromě vlastního odmítnutí agilních hodnot a principu dojít i k situaci (hlavně u nezkušenějších týmů), kdy členové nezvládnou velké množství volnosti a zodpovědnosti, a nepodaří se tak nastartovat sebe-organizování týmu. V takovém případě se doporučuje organizacím využít služeb agilního kouče, který se přímo specializuje na problémy týmu spojené s adopcí agilních hodnot a principů. I přes výše zmíněné problémy se za více než 16 let své existence Scrum stal nejčastěji nasazovanou agilní metodikou. V roce 2010 [19] používalo Scrum nebo některý z jeho hybridů 19

29 (kombinace s extrémním programováním, principy Kanbanu, ) 78% oslovených společností hlásících se k dodržování agilních principů. Obr. 5 Zastoupení jednotlivých agilních metodik v organizacích, zdroj: [19] Jako většina agilních metodik je Scrum z procesního hlediska spíše framework. Definuje: 1 Scrum proces; 3 fáze Předehra, Hra a Dohra; 3 týmové role Tým, Scrum master, Product owner; 4 artefakty Product Backlog, Sprint Backlog, Product Burndown Chart, Sprint Burndown Chart; 5 typů schůzek Sprint Planning, Estimation, Daily Stand-Up, Review, Retrospective. [14] Vzhledem k tomu že nepředepisuje žádné konkrétní přístupy, je velmi často kombinovaný s ostatními agilními metodikami, např. s extrémním programováním (párové programování, psaní jednotkových testů, ) nebo Kanbanem (vizualizace workflow, omezování počtu work-inprogress, v některých případech zrušení iterací, pak už se ale nedá mluvit o použitém přístupu jako o Scrumu). 20

30 5.3.1 Týmové role Tým Agilní metodiky předpokládají sestavování cross-functional týmů. Tedy takové složení týmu, ve kterém jsou zastoupeny všechny profese, které pro daný projekt jsou potřeba. Je prospěšné ovlivnit jeho složení tak, aby kromě zastoupení všech profesí byly znalosti členů v souladu s konceptem T-shaped profesionálů a zvyšovaly tím vzájemnou zastupitelnost v týmu. Dá se říci, že součástí týmu by měli být také cross-functional lidé. Tým ve Scrumu lze přirovnat k malé obchodní jednotce. Vytváří produkt, sám sebe organizuje a je posuzován jako celek. Je důležité, aby členové měli vhled nejen do technické povahy projektu, ale byli také schopni posoudit jeho ekonomický kontext. Tým není pouhá skupina jednotlivců, musí vzniknout, tzn. projít všemi fázemi formování týmu, jak je např. popsal Bruce W. Tuckman v roce Formování týmu probíhá ve fázích [20]: Formování (forming) vzájemné poznávání členů týmu, seznámení s cíli a postupné začínání práce na úkolech. Je užitečné seznámit členy týmu s konceptem formování, aby si byli vědomi, co se děje a z jakého důvodu; Bouření (storming) probíhá ujasňování problémů, které má tým řešit. Dochází k vyjasňování názorů a profilování jednotlivých členů. Nezvládnutí této fáze má často za následek snížení motivace a vytvoření špatné atmosféry v týmu. Úspěšnost lze podpořit využitím externího kouče, který na tým dohlíží a radí jak se v určitých situacích zachovat; Normování (norming) každý člen přijímá svou roli v týmu, obrušují se hrany a dochází k sjednocení postojů a postupů, jak dosáhnout stanoveného cíle; Provádění (performing) práce týmu je sladěna a jsou vytvořeny podmínky pro sebeorganizování. Členové týmu jsou připraveni převzít větší zodpovědnost a zvládnout rozhodování bez podpory vedení. Pokud v průběhu některé z pozdějších fází dojde k větší změně ve složení týmu, jako je odchod důležitých členů nebo příchod většího množství nových, tým se obvykle vrací do první nebo druhé fáze a celý cyklus se opakuje. Trvalé je pouze pořadí fází, jejich délka je proměnlivá a záleží na zkušenostech členů týmu, za jak dlouho a zda vůbec se podaří dosáhnout prováděcí fáze. Z tohoto důvodu je nesmírně důležitá role Scrum mastera v týmu. V případě požadavků liniového manažera, který potřebuje vrátit člena svého oddělení z fungujícího týmu, je na Scrum masterovi, aby situaci vyřešil a tým ponechal beze změny. 21

31 Scrum master Jeho hlavní odpovědností je plynulost Scrum procesu, které dosahuje zlepšováním produktivity týmu prostřednictvím metod leadershipu, koučování a moderování. V průběhu sprintu odstiňuje tým od běžných požadavků trvalé organizace tak, ať mají jeho členové podmínky vhodné pro splnění svého závazku, který na začátku každého sprintu dali držiteli role Product owner. Scrum master není projektovým manažerem, protože tým se organizuje sám. Stejně tak není ani tím, kdo rozhoduje, neboť všechna rozhodnutí jsou v režii týmu. [14] Jedná se o pozici, pro kterou je třeba plno-časově vyhradit zaměstnance. Není možné střídání kontextů, kdy po část dne zaměstnanec vystupuje jako člen vývojového týmu a v určitou hodinu nebo dle potřeby týmu by se stával Scrum masterem. Tomuto křížení rolí je třeba se důsledně vyhnout, protože každá z nich má odlišné povinnosti a odpovědnosti. Při zavádění Scrumu do organizace poměrně často role Scrum mastera připadne právě původnímu projektovému manažerovi týmu. Ten může způsobit velké množství problémů svou neschopností přepnout se z direktivního stylu řízení na model, kdy je jeho úloha víceméně podpůrná. Uplatňování direktivního přístupu k řízení týmu může poškozovat a zpomalovat adopci agilních přístupů. Product owner Product owner by měl být ideálně dodán zákazníkem, nejčastěji se jedná o člena marketingového oddělení. Definuje vizi, kterou sdílí s týmem a neustále udržuje aktuální. Sestavuje seznam požadavků kladených na výsledný produkt, na jehož základě vznikne Product backlog. Jeho hlavní zodpovědností je správa Product backlogu, určování priorit jednotlivých položek a připisování nových požadavků vynořujících se v průběhu vývoje. Jeho obsah může úplně změnit tak, aby odpovídal aktuálním požadavkům trhu, neboť je zodpovědný za ziskovost výsledného produktu. [14] U menších projektů zákazník obvykle nechce s projektem spojovat další náklady, ať už své časové nebo mzdové na roli Product Ownera. Proto je na straně dodavatele vybrán zaměstnanec (Proxy Product Owner), který se detailně obeznámí se záměrem zákazníka a poté odhaduje, jaký další směr vývoje bude pro zákazníka nejlepší. 22

32 5.3.2 Scrum proces Scrum definuje pouze jeden proces, který určuje celý životní cyklus projektu. Je zaměřený na dělení práce na časově omezené opakované iterace s cílem dodávat zákazníkovi použitelné části systému tak, jak předepisuje Agilní manifest. Dělí se do tří cyklicky se opakujících po sobě jdoucích fází předehra, hra, dohra. Obr. 6 Schéma metodiky Scrum, zdroj: překresleno autorem, inspirace [14] 23

33 Release planning Na začátku projektu přichází Product owner s mnohdy nejasnou vizí finálního produktu. Vize je upřesňována prostřednictvím user stories, propozic, které popisují funkcionalitu a její přínos pro konkrétní typ uživatele. User stories mají ustálenou formu: Jako <typ uživatele> chci <funkcionalitu>, která < pro mě má smysl/je mým cílem/přináší mi hodnotu>. [14] Každá user story má v kontextu co nejrychlejšího dodání systému a jeho uvedení na trh svou prioritu, dle které je zařazena do Product backlogu (PB). Takto seřazený seznam je rozdělen na jednotlivé verze, kdy vydání verze obvykle trvá 3-4 iterace (sprinty). Tým může dávat vlastníkovi PB návrhy na změnu priority jednotlivých user stories, nicméně konečné slovo má Product owner. Sprint planning Plánování konkrétního sprintu probíhá na základě prioritizace PB. Tým musí ohodnotit jednotlivé user stories z hlediska jejich komplexnosti (Estimation). K tomu se využívá tzv. Plánovací hra, mnohdy označovaná jako Plánovací poker. Jedná se o techniku používanou také v metodice Extrémního programování. Ve stručnosti, každý člen týmu má balíček karet, jejichž hodnoty dodržují určitou posloupnost (např. 1, 2, 3, 5, 8, 13, 21, 40, 100). Scrum master představí úkol. Každý člen týmu odhadne náročnost úkolu (náročnost z hlediska komplexity úkolu nikoliv časovou náročnost) a přiřadí mu kartu s odpovídající hodnotou. Po vyložení karet na stůl Scrum master osloví členy, kteří ohodnotili úkol nejnižší a nejvyšší hodnotou, ať vysvětlí své důvody. Po diskuzi probíhá další kolo. Hra končí, když se tým jednohlasně shodne na jednom čísle. Stejný postup se opakuje, dokud nejsou ohodnoceny všechny úkoly. Časová náročnost naplánování jednotlivého úkolu je v řádu minut. Alternativou může být Magické odhadování (Magic estimation) [21]. Vycházejme z předpokladu, že všechny úkoly jsou napsány na lepících lístcích. Na tabuli se nalepí lístky popsané hodnotami posloupnosti stejně jako u Plánovací hry. Postupuje se v několika krocích: 1) Úkoly k naplánování se rozdělí mezi členy týmu, kteří své lístky nalepí pod hodnotu, o níž si myslí, že nejlépe vystihuje náročnost úkolu. 2) Po přiřazení úkolů pod konkrétní hodnoty se členové zaměří na všechny nalepené lístky na tabuli a pokud jsou jiného názoru, mohou lístek přesunout. 24

34 3) Ve velmi krátké době (řádově jednotky minut) je většina odhadů ustálena. Pokud na tabuli zbývá pár lístků, u kterých se tým neshodne, lze je dořešit pomocí Plánovací hry. Takto lze výrazně urychlit plánování, i když přesnost odhadů bude o něco nižší než u odhadů získaných pomocí Plánovací hry. Důležitou podmínkou je zachování mlčení v prvních dvou krocích. Diskutovat o náročnosti lze až ve třetím kroku. Po odhadnutí dostatečného množství user stories je stanoven cíl sprintu a na základě znalosti výkonu (velocity) týmu vybrán určitý počet položek PB, které se tým zaváže pro splnění cíle dodat. Tyto položky jsou dále rozpracovány na detailnější úroveň konkrétních úkolů, které se zapíšou do Sprint backlogu (SB). V průběhu iterace se obsah SB nemění, zůstávají na něm přesně ty úkoly, k nimž se tým zavázal. V prvních několika iteracích, kdy tým prochází formovacími fázemi a výkon ještě není přesně změřen, je vhodné vybírat spíše menší počet položek, pro větší pravděpodobnost splnění závazku. S postupným získáváním zkušeností se zrychluje práce týmu a s ní přímo úměrně i jeho výkon. Cíl sprintu je výsledkem vyjednávání mezi týmem a Product ownerem a měl by být vytvořen v souladu s technikou SMART, tj. měl by být specifický, měřitelný, dosažitelný, reálný a časově ohraničený. Příkladem takového cíle může být dohoda, že V příští verzi budeme schopni zpracovat 3 více požadavků za stejný čas oproti verzi předchozí. Production Po definici jednotlivých úkolů je vše připraveno pro vlastní vývojovou činnost týmu. Iterace většinou trvá 2-4 týdny. Scrum nepředepisuje metodu vývoje, je na týmu, jak k vývoji přistoupí. Obvykle adoptuje myšlenky z Extrémního programování. V průběhu sprintu se konají pravidelná každodenní setkání (Daily Stand-up nebo též Daily Scrum), kterých se účastní pouze členové týmu. Každý z nich odpovídá na tři jednoduché konkrétní otázky: Co jsi dělal včera? Co budeš dělat dneska? Potýkáš se s nějakým problémem? [14] Je na Scrum masterovi jakožto moderátorovi získat od členů týmu tyto informace. Dochází ke sdílení informací, sledování posunu v rámci sprintu a případným diskuzím nad problémy, kterým tým při vývoji čelí. Pokud se jedná o problém, jehož neřešením by mohlo být ohroženo splnění závazku, tým by mu měl věnovat přednostní pozornost a vyřešit jej. 25

35 Je opravdu důležité, aby setkání probíhala pravidelně ve stejný čas, protože to podporuje disciplinu v týmu. Jak už z názvu vyplývá, probíhají ve stoje, což pomáhá udržovat pozornost. Je vhodné začínat touto schůzkou den, např. pravidelně v 9:00. Délka by neměla přesahovat doporučovaných 15 minut. Scrum má v tomto problém s home office přístupem k práci, který lze řešit pomocí moderních komunikačních metod, nicméně až 60% komunikace probíhá nonverbálně. Absence této složky komunikace může činit problém např. ve vzájemném pochopení mezi takto dislokovanými členy týmu. Průběh sprintu Scrum master měří prostřednictvím grafu Sprint Burndown Chart. Tento graf je vytvořen na základě počátečního stavu Sprint backlogu a je aktualizován každodenně po skončení Daily Scrumu. Lze z něj vyčíst, zda dochází ke zpoždění oproti plánu, jestli existuje riziko nesplnění závazku a kolik práce zbývá do konce sprintu. Review Review je formální uzavření sprintu, kde tým Product ownerovi prezentuje demo dokončené funkcionality. Na jejím základě Product owner validuje, že výsledek sprintu odpovídá jeho představám o směřování vývoje produktu. Doporučovaná délka review obvykle odpovídá délce sprintu, tzn. pokud sprint trvá 2 týdny, review by mělo trvat 2 hodiny. Na začátku sprintu se vývojový tým zavázal k dosažení určitého cíle. Product owner v této fázi potvrzuje, zda z jeho pohledu byl nebo nebyl cíl splněn. Po akceptaci výstupu tým diskutuje o dalším směru vývoje produktu, je aktualizován obsah Product Backlogu a aktualizován Product Burndown Chart, který stejně jako graf ukazující stav sprintu reflektuje celkový stav rozpracovanosti výsledného produktu. Pokud již v průběhu sprintu je tým přesvědčen, že není v jeho silách splnit cíl, Scrum vyžaduje, aby na to Product ownera upozornil. Hotová funkcionalita je integrována k již hotovým částem kódu. Retrospective Diskuze, která je moderovaná Scrum masterem, kde tým probírá události předchozího sprintu hlavně v otázkách: Čeho jsme dosáhli? Co bychom udělali jinak? Co jsme se naučili? Co je naší největší překážkou? Co chceme, aby se zlepšilo? [14] 26

36 Zodpovědnost za realizaci nápadů, pro které je nutné změnit fungování organizace, má Scrum master. Na začátku diskuze je dobré připomenout předchozí připomínky a zrevidovat, zda se podařilo dosáhnout změny. Pokud organizace na připomínky týmu nebude reagovat, je reálné riziko, že retrospektiva přestane plnit svůj účel. Členové týmu budou předpokládat, že jejich názor nikoho nezajímá a hrozí, že tým ztratí zájem o další rozvoj. Fáze Celý takto představený proces se dělí na tři fáze. Předmětem Předehry je plánování a příprava na projekt. Ve fázi Hra probíhá vlastní implementace. Dohra zahrnuje přípravy na vydání, finální otestování, spuštění a případně nastartování projektu údržby produktu. 5.4 Metoda Kanban Metodika se svým názvem odvolává na jednu ze součástí Toyota Production System (TPS), který zaujal už Takeuchiho a Nonaku. Jak uvádí Donald Reinertsen v předmluvě knihy [22], počátky lze dají vysledovat do roku 2003, kdy její tvůrce David J. Anderson vydává knihu Agile management for Software Engineering: Applying Theory of Constaints for Business Results. Dalším rozvojem a aplikací jím navržených postupů ověřoval funkčnost svých teorií v praxi, například v jednom z vývojových týmů společnosti Microsoft v roce 2004, kde implementoval řešení odpovídající Goldrattovu Drum-Buffer-Rope. Díky tomuto řešení s minimální mírou odporu vůči změně stoupla trojnásobně produktivita týmu, o 90% se snížila doba zpoždění (lead time) a o 98% se zlepšila předvídatelnost, viz 4. kapitola [22]. Na základě výsledků z Microsoftu se ho Reinertsen, jeden z průkopníků Lean přístupu v IT, snažil přesvědčit, že má všechny znalosti a zkušenosti pro implementaci kanban systému a v říjnu 2003 mu napsal: Jednou z největších slabin TOC je podcenění důležitosti velikosti dávky. Pokud je tvou hlavní prioritou hledat a redukovat omezení, pravděpodobně řešíš špatný problém [22] Reinertsen byl přesvědčen, že úspěch TPS neplynul z hledání a eliminace úzkých míst, ale právě ze snižování velikosti jednotlivých dávek a variability pro snížení velikosti zásob rozpracovaných úkolů (work-in-progress - WIP). V září 2006 ve společnosti Corbis poprvé Anderson plně implementoval kanban systém. 27

37 Názvosloví spojené s metodou Kanban: kanban v originálním TPS označuje plastikovou kartu. Počet těchto karet v oběhu je omezený, což přirozeně nastavuje limit pro počet work-in-progress. V IT mají nejčastěji podobu lepících lístků; kanban system pull systém, jehož produkce se řídí podle množství kanban štítků v oběhu. Pokud jsou všechny přiřazeny ke konkrétním WIP, nemůže začít produkce dalších zásob na sklad; Kanban metoda (dále Kanban) metoda evolučního přístupu k dosažení změny, která využívá kanban system, vizualizaci a další nástroje pro urychlení uvedení myšlenek štíhlé výroby do technologických a IT firem. Kanban není metodikou ve správném slova smyslu, ale prostředkem, jehož účelem je nenásilné zavedení a přijetí změny prostřednictvím dodržování několika jednoduchých principů. Podobně jako Scrum potřebuje jeho zavedení podporu na všech úrovních trvalé organizace, nicméně změna probíhá evolučně a nesetkává se tak s přirozeným odporem zejména u členů týmu. Stejně jako Drum-Buffer-Rope i Kanban je implementací pull systému. U tradičních push systémů je produkce dopředu rozplánována a každé stanoviště produkuje nezávisle na aktuální potřebě svého okolí. Produkce tak není posuzována z hlediska potřeby, ale z hlediska plánu. Takto tlačí (odtud anglické push ) své výstupy dalším stanovištím. V pull systémech (systémech založených na tahu), které jsou v souladu s filozofií štíhlé výroby, je produkce spuštěna, pouze pokud je v procesu prostor s ní dále pracovat. Horní tok nezačne produkovat dříve, než si dolní tok o produkci řekne. Tato signalizace je jedním z účelů kanbanu v TPS. Produktivita dolního toku reguluje produktivitu horního toku. Produkce na sklad je považována za plýtvání, které je třeba omezovat. V IT se pull systémy vážou především k stylu řízení lidí. Pracovníkům tak není direktivně určováno manažerem, kdy na konkrétním úkolu budou pracovat, ale počítají se sebeorganizovaností týmu i jeho členů. Ti si z množiny připravených úkolů vyberou sami konkrétní, na kterém dále pracují. Přijetí agilních a Lean (štíhlých) principů do organizace se Kanban snaží podpořit pomocí pěti základních nástrojů: 1. Vizualizace workflow, 2. Limitování work-in-progress, 3. Měření a řízení toku (flow), 4. Explicitní vyjádření pravidel procesu, 5. Využívání modelů k rozpoznávání příležitostí k zlepšení. 28

38 V širším pojetí je efektivita a optimální fungování organizace dále podpořeno: typy úkolů, měřením kadence, třídami služeb, reportováním managementu a provozními revizemi. Vizualizace workflow Pro vizualizaci se nejčastěji používá běžná bílá tabule, na které je rozkresleno workflow projektu a jednoduchým způsobem zachycen aktuální stav jeho rozpracovanosti. Tabule se dělí na jednotlivé sloupce, které odpovídají konkrétním činnostem, kterými úkol musí projít, než je dokončen. Tato tabule se označuje jako Kanban board a v její jednoduchosti je největší přínos. Nicméně je vhodné ji doplnit také o elektronickou podporu, která bude například poskytovat podrobnější informace o konkrétním úkolu. Obr. 7 Kanban board, zdroj: Převedení úkolu z nehmatatelné podoby do podoby lístku nalepeného na tabuli umožňuje členům týmu vidět úkol v rámci kontextu ostatních úkolů, jejich stavu a priority. Vizualizace minimalizuje náklady spojené s udržováním konzistentního vnímání stavu projektu mezi členy týmu. Obsah kanbanu by měl poskytovat dostatek informací pro sebe-organizaci týmu a umožňovat přijímání rozhodnutí. Limitování WIP Vizualizace workflow prostřednictvím tabule ještě sama o sobě neznamená aplikaci Kanbanu, je třeba nastavit omezení na množství work-in-progress. Omezení množství WIP má dva hlavní přínosy. Snižuje nadměrný multitasking, který snižuje produktivitu pracovníků a poskytuje projektovému manažerovi způsob, jak ochránit tým před přetěžováním nadměrným množstvím úkolů ze strany potřeb trvalé organizace. Je chybou uvažovat o výkonu týmu jako o kapacitě, která má charakter spíše prostorový, ale je třeba jej chápat jako propustnost. 29

39 Dynamiku týmu lze přirovnat k provozu na dálnici. Od cca 65% zaplnění kapacity se na dálnici začnou objevovat zácpy, které zpomalují provoz natolik, že při 100% zaplnění se provoz zastaví úplně. Potom se ale nejedná o dálnici, ale parkoviště [23]. Pokud nelimitujeme počet WIP ve snaze dosáhnout co největšího využití kapacity, nutnost multitaskingu nakonec prudce sníží produktivitu. Průzkumem provedeným v roce 2009 na dvou skupinách lidí, kdy jedna byla považována za singletasking jedince a druhá byla složená z lidí využívající multitasking, bylo prokázáno, že ačkoliv jsou lidé schopni vnímat více podnětů najednou, nejsou schopni filtrovat irelevantní informace a dochází tak k zahlcení a snížení jejich efektivity a produktivity [24]. Problémy způsobované multitaskingem lze demonstrovat pomocí simulační hry The Multitasking Name Game Henrika Kniberga [25]. Úkol zní jednoduše: Odhadněte, jak dlouho trvá napsání jména. Pokud se skupina shodne například na odhadu 4 vteřiny, lze z toho odvodit, že napsání pěti jmen zabere 20 vteřin. Hru hraje skupina šesti lidí, kdy jeden člen je vývojář a zbytek jsou zákazníci, kteří si chtějí nechat napsat jméno. Vývojář jako jediný umí psát, zákazníci umí své jméno pouze vyslovit a hláskovat. Hra se hraje na dvě kola. V prvním kole musí zákazník ctít politiku firmy: zákazníka nesmí nechat čekat a premisu: co dřív začne, to dřív skončí. Ukázka multitaskingu v jeho nejčistší podobě. Místo očekávaných 4 vteřin trvá napsání jednoho jména nejčastěji 40 vteřin a 5 jmen 60 vteřin. Tento přístup vykazuje kromě problémů spojených s přepínáním kontextů (vývojář se vždy musí soustředit na jiné jméno) také zvýšenou potřebu komunikace (obvykle se s každou změnou zákazníka musí vývojář znovu zeptat na jeho jméno). Ve druhém kole dostane vývojář za úkol limitovat počet rozpracovaných položek na pouhou jednu. Věnuje se každému zákazníkovi postupně, nepřepíná tudíž kontexty a také potřeba komunikace je daleko menší (vždy se ptá jen jednou každého zákazníka). Výsledky již odpovídají původním odhadům, jméno trvá napsat nejčastěji 5 vteřin, 5 jmen 30 vteřin. Ještě důležitější než snížení času potřebného pro obsloužení všech zákazníků je snížení doby zpoždění jednotlivých projektů. V praxi to tak znamená, že omezením množství rozpracovaných úkolů lze několikanásobně zkrátit čas potřebný pro uvedení nových vlastností produktu na trh. U komplexnějších úkolů by zkrácení doby zpoždění bylo ještě markantnější. Informace o limitu je viditelně zapsána na Kanban boardu. Zavedenou konvencí je zapisování WIP limitu vedle názvu sloupce, který popisuje činnost. Vyjadřuje tak, kolik kanbanů může být v danou chvíli v konkrétním sloupci. Za žádných okolností nesmí být tento limit překročen. V případě, že nastavené limity neodpovídají, je na projektovém manažerovi a týmu, aby došli ke shodě a limit přizpůsobili stávajícím podmínkám. 30

40 Obr. 8 Zápis WIP limitu na Kanban board Kanban se snaží podporovat neustálé zlepšování (v terminologii TPS Kanbanu označováno jako Kaizen). Nastavením optimálních požadavků na průtok tak vznikne prostor pro vývoj členů týmu, tak jak naznačili Nonaka s Takeuchim. Kaizen je podporován prováděním retrospektiv. Tým se většinou pravidelně schází s cílem probrat zkušenosti z doby mezi jednotlivými retrospektivami. Stejně jako s oddělením plánování, ani retrospektivy nejsou vázány na žádnou iteraci vývoje. Pokud je aktuální problém, který se kupříkladu opakuje a pravidelně způsobuje zahlcení úzkého místa, je vhodné provést retrospektivu ad hoc a problém systematicky vyřešit. Cílem není poskytnout týmu prostor, který by mohl být vlivem Parkinsonova zákona vyčerpán 2 nebo díky Syndromu líného studenta promrhán 3, ale poskytuje týmu mimo jiné přirozený nárazník proti výskytu Murphyho zákona [26]. V souladu s určitým odklonem od direktivních forem řízení směrem k sebe-řídícím týmům si vedení firem začalo uvědomovat, že stabilní tým je lepší než vysoká fluktuace zaměstnanců. Vysoké pracovní nasazení není trvale udržitelná strategie a tak se méně vytěžovaný tým z dlouhodobého hlediska jeví jako ekonomicky výhodnější než stálé obměny členů týmu z důvodu jejich vyhoření. Souvislost to má také s fázemi formování týmu popsanými výše. Měření a řízení toku Stav tabule je vynikajícím zdrojem informací nejen o aktuálním dění, ale indikuje možné problémy již v jejich počátcích. Pokud se někde začne hromadit větší množství lístků, jejichž pozice se dlouhodoběji nemění, indikuje to např. zahlcení úzkého místa, které je potřeba řešit. Lze takto také odhalit pracovníka, který svou nečinností dostává tým do potíží. Tím, že stav je viditelný všem, je pro členy týmu přirozenější jej i společně vyřešit. Jakmile se vyskytne 2 pracovník nemá definovanou časovou náročnost úkolu a zbytek týmu má o jeho práci jasný přehled 3 není určen termín ukončení činnosti, pracovník si úkol vybírá sám 31

41 problém, který zastaví tok úkolů, všude kromě úzkého místa se uvolní pracovní kapacity, které lze využít k odstranění problému. Výkonnost procesu v Kanbanu je měřena pomocí Cumulative Flow Diagramu (CFD). Zachycuje průchod úkolů procesem v čase. Pokud některá složka grafu roste, zatímco následující zůstává neměnná nebo roste daleko pomaleji, může to znamenat zahlcení systému a projektový manažer by měl zpozornět. Tato forma vizualizace s dostatečným předstihem indikuje možný výskyt úzkého místa a zastavení projektu z důvodu zahlcení. [27] Obr. 9 Cumulative Flow Diagram Například Scrum staví na časově ohraničených iteracích, kdy díky znalosti rychlosti (velocity) týmu lze odhadnout, kolik toho je schopen za danou iteraci udělat. Výkonnost týmu je vizualizovaná prostřednictvím sprint, resp. product burndown chart. Na rozdíl od burndown chartu nabízí CFD pohled na kompletní workflow a výkon týmu v každém kroku vývoje. Burndown chart pouze shrnuje obecný výkon týmu během sprintu a neukazuje tak možná úzká místa a příležitosti pro zlepšení týmu. Zástupce byznysu v zásadě nezajímá, kolik jsme toho schopni udělat, ale jak rychle lze produkt uvést na trh [28]. Metriky Kanbanu proto stojí na měření doby zpoždění, která vyjadřuje odhad, jak dlouho nám bude trvat vytvoření a uvedení konkrétní vlastnosti produktu na trh. Pro získání podpory je důležité dodat správná data správným lidem. 32

42 CFD poskytuje podklady pro vyjednávání o respektování limitování WIP. Je z něj na první pohled zřejmé, že omezení množství rozpracovaných úkolů výrazně zvýší kadenci, s jakou je tým schopný nové funkce produktu dodávat. [27] Obr. 6 a obr. 7 tento fakt ilustrují. Při 68 WIP v 9. týdnu trvalo vytvoření jednotlivého úkolu v průměru 21 týdnů. Omezení WIP na 22 a méně od 26. týdne snížilo čas potřebný pro vytvoření jednotlivého úkolu na průměrně 7 týdnů. Obr. 10 Srovnání závislosti limitování WIP a doby zpoždění V tomto případě se díky omezení WIP dařilo dodávat na trh novinky 3krát rychleji, což umožnilo, aby produkt začal vydělávat daleko dříve. Zejména v situaci, kdy si je organizace vědoma, že i konkurence pracuje na obdobném produktu, může rychlost uvádění novinek na trh znamenat kritickou konkurenční výhodu, která nakonec rozhodne o přijetí nebo odmítnutí produktu trhem. Prvotní nastavení limitu WIP jednotlivým částem workflow je často založeno na hrubém odhadu, protože na počátku žádná tvrdá data neexistují. Pro člověka je přirozené zvládnout 2-3 věci souběžně, aniž by pociťoval problémy spojené s multitaskingem. Pokud máme 3 vývojáře, pak kroku Vývoj je bezpečné pro začátek nastavit limit WIP na hodnotu 6 položek. S největší pravděpodobností nebudou hodnoty systému zprvu nastaveny optimálně, ale v souladu s agilními hodnotami je i toto předmětem neustálé změny, se kterou je třeba počítat a přizpůsobit se jí. 33

43 Explicitní vyjádření pravidel procesu Kanban si velmi zakládá na vizualizaci a internalizaci informací pro jejich co nejjednodušší zpřístupnění týmu za účelem dosažení transparentnosti. Příkladem této vizualizace je indikace limitu WIP na Kanban boardu. Překračováním limitu WIP by docházelo ke zkreslování výsledků CFD a projektový manažer by měl značně ztížené podmínky pro udržování trvalého zlepšování organizace. Ve Scrumu lze říci, že do určité míry je rytmus týmu stanoven iteracemi. V Kanbanu vývoj probíhá kontinuálně, je proto důležité nastavit jinou formu pravidelnosti v týmu. Lze se inspirovat Scrumem a jeho pravidelnými denními schůzkami. V týmu tak dochází ke zlepšení komunikace a sdílení informací o stavu projektu. Podobně lze převzít také pořádání retrospektiv pro dosažení trvalého zlepšování týmu. Všem členům týmu by měl být jasný důvod a přínos konání těchto schůzek. Pro některé kroky je vhodné vytvořit definici dokončeného úkolu (DoD Definition of Done). Jedná se o explicitní vyjádření podmínek, za nichž je možno daný úkol považovat za splněný a může dojít k jeho předávce. Stejně jako pro ostatní agilní metodiky, je i pro Kanban důležitý konsensus s okolím projektu. Musí být jasně vyjednány podmínky na vstupu i výstupu workflow. Pokud si projektový manažer nedokáže zajistit pravidelné plánování práce nebo dodávání vstupů pro svůj tým, může docházet k problémům s plynulostí procesu. Využívání modelů k rozpoznávání příležitostí k zlepšení Nepotřebnost zavádění dalších forem micro-management pro sledování výkonnosti týmu je pozitivním přínosem měření prostřednictvím CFD. Na první pohled lze odhalit problémy i úzká místa a využít pak Teorii omezení (TOC) Dr. Eli Goldratta a dle jím navržených pěti kroků se s úzkým místem vypořádat. Díky jejich viditelnosti tak není nutné na problémy nahlížet jako na rizika, ale lze je akceptovat a brát jako příležitosti ke zlepšení. Ze zkušeností autora Kanbanu vyplývá, že délka doby zpoždění má velký dopad na kvalitu produktu [22]. Čím kratší tato doba je, čím menšímu množství úkolů je věnována pozornost, tím větší kvalitu výsledný produkt vykazuje. Je to logické, protože například programátor nemusí přepínat svůj kontext mezi několika různorodými projekty, je lépe soustředěný a pracuje rychleji. Dalším modelem, se kterým Kanban přirozeně pracuje je Demingův PDCA cyklus. V souladu s ním je zanalyzováno workflow projektu (Plan), provedeno první nastavení limitu WIP (Do), jsou měřeny výsledky (Check) a systém je přizpůsoben zjištěním (Act). Je úkolem projektového manažera neustále kontrolovat výsledky a snažit se o co nejoptimálnější fungování celku. 34

44 Vzhledem k tomu, že Kanban je metoda zavedení změny do prostředí s již existujícími procesy, které probíhají a které mají být optimalizovány, může být vhodnější použití zjednodušeného Demingova cyklu vytvořeného Johnem Seddonem. Skládá se pouze ze tří kroků: Check zkontroluj stávající proces; Plan naplánuj změnu; Do prověď plán. Po provedení plánu se cyklus opakuje a stávající proces je opět posuzován, zda funguje optimálně. Pokud ano, přejde se k hledání dalšího problému, který je vhodné optimalizovat. Obr. 11 Srovnání Demingova a Seddonova cyklu, zdroj: [29] Svou roli hraje eliminace Zeigarnikova efektu, který říká, že lidé si zapamatují nedokončené nebo přerušené úkoly až s 90% pravděpodobností na úkor dokončených [23]. Lidský mozek potřebuje považovat věci za ukončené, přemíra neuzavřených nebo nedokončených věcí, kterými se mozek zabývá, snižuje koncentraci, demotivuje a může vést ke ztrátě pracovníka z důvodu ztráty smyslu práce. 35

45 5.4.1 Nasazení metodiky Kanban Anderson v knize [22] popisuje postup, který vyvinul při zavádění Kanbanu v již existujících týmech. Málokdy má projektový manažer pověřený zlepšením fungování týmu možnost ovlivnit složení týmu dle jeho představ a musí být schopen pracovat s dostupnými zdroji. Recept na úspěch se skládá z celkem šesti principů, které je třeba splnit: 1. Zaměření na kvalitu, 2. Redukce množství Work-in-progress, 3. Časté dodávky, 4. Vyvážení nároků proti výkonnosti, 5. Prioritizace, 6. Odstranění zdrojů variability pro zvýšení předpověditelnosti. Na počátku zavádění Kanbanu je podstatné zasahovat co nejméně do činností pracovníků, hlavní je vyjednání podmínek, které metodika pro své hladké fungování potřebuje. Vizualizace napomáhá přesvědčování okolí, že změna je nutná a má svůj smysl. Podle Andersona by měl vývoj týmu adoptujícího agilní a lean principy prostřednictvím Kanbanu být přibližně následující: 1. Tým se musí naučit produkovat kvalitní kód, protože opakované chyby v software jsou jedním největších zdrojů plýtvání, se kterým se lze při vývoji setkat. 2. Redukcí množství WIP dosáhne tým zkrácení doby zpoždění a může díky tomu vydávat nové verze daleko častěji. K vybudování důvěry mezi dodavatelem a odběratelem přispěje spíše pravidelné dokazování spolehlivosti než velká dodávka po delším časovém období. 3. Vyvážení množství požadavků vzhledem k výkonnosti týmů a nastavení limitu WIP umožní vytvoření prostoru pro průběžné zlepšování týmu. 4. Po úspěšném zvládnutí předchozích kroků je pozornost zaměřena mimo tým. Kanban se snaží zkrátit čas potřebný pro uvedení produktu na trh. Tento čas výrazně ovlivňuje nastavení priorit vývoje. Je potřeba optimalizovat nastavení priorit tak, aby upřednostňovaly požadavky přinášející hodnotu. Přístupy pro zavádění metodik Scrum a Kanban jsou naprosto rozdílné. Pro přijetí Scrumu je nezbytně nutné, aby organizace změnila své fungování revolučně, prakticky ze dne na den, dle požadavků metodiky. To s sebou nutně nese riziko odmítnutí změny, případně aktivního odporu vůči změně. Implementace Kanbanu má evoluční charakter, proto rizikem není v takové míře odmítnutí změny nebo různé formy odporu, ale spíše nepřipravenost organizace. Článek [30] popisuje dva případy nasazení Kanbanu v týmech poskytujících podporu pro podnikový informační systém SAP. V první společnosti, která měla jasně definované procesy, bylo nasazení úspěšné. Díky měření toku měl projektový manažer k dispozici dostatek tvrdých 36

46 dat pro podložení svých tvrzení při vyjednávání s top managementem. V top managementu byli zastoupeni lidé, kteří byli obeznámeni s principy štíhlé výroby a dokázali dohlédnout důsledků nasazení požadovaných změn. Podařilo se dosáhnout pravidelnosti v plánování, konzistentní a rozumnou velikost dávek nových požadavků a změny přístupu k validaci dodané funkcionality na straně odběratele. Díky změnám dosáhli mnohem stabilnějších výstupů, zvýšení efektivity a snížení WIP. Druhá společnost byla obdobné velikosti, ve stejném odvětví, opět se jednalo o podporu IS SAP. Hlavním rozdílem byla absence definovaných procesů a postupů pro zadávání požadavků na změny. V důsledku tak nebyl projektový manažer schopen ovlivnit velikost dávek s požadavky a také velikost jednotlivých požadavků. Vyskytovaly se převážně dva extrémy. Požadavky, které bylo vhodné řešit samostatným projektem a velmi malé požadavky, jejichž vyřízení trvalo v řádu hodin. Malé požadavky pak tým mnohdy řešil mimo Kanban board, nebyly tak zachyceny metrikami a neřídily se nastavenými limity pro WIP. Pokud byly zachyceny formou kanbanu, nedostaly většinou dostatečnou prioritu, což postupem času způsobilo, že z nedůležitých požadavků se staly vysoce prioritní. Častý výskyt vysoce prioritních požadavků, které je třeba provést, rozbíjí workflow a snižuje celkový výkon týmu. Kanban není ani konkrétní metodikou životního cyklu vývoje software, ani přístupem k řízení projektů. Vyžaduje přítomnost procesů, které se díky dodržování principů Kanbanu mohou postupně vyvíjet. Hlavně v případě větších společností s hlubší organizační strukturou, kdy projektový manažer často nemá pravomoci přímého vlivu na okolí svého projektu, lze vysledovat požadavky, které Kanban na řízenou organizaci klade. Tým se může snažit o změnu vývoje software v souladu s principy Kanbanu a Lean sebevíce, ale úspěchu dosáhnou pouze tehdy, pokud jsou členové organizace ochotní přijmout požadované změny. Pokud nemá organizace své procesy pevně zakotveny, je třeba je před nasazením Kanbanu definovat Personal Kanban Jak z názvu vyplývá, jedná se o přístup, který využívá jednoduchosti Kanbanu pro zvýšení osobní produktivity. Personal Kanban se řídí pouze dvěma pravidly: vizualizace práce, omezení WIP. Vizualizace poskytuje jednotlivci přesné informace o jeho situaci. Co má před sebou (cíle a nadcházející úkoly), aktuální stav (na čem zrovna pracuje) a do určité míry také historii (přehled již ukončených úkolů). Omezení WIP chrání jednotlivce před syndromem vyhoření a umožňuje mu vyhradit si čas pro osobní rozvoj. 37

47 Kanban board je oproti plnohodnotnému Kanbanu notně zjednodušený. V základu má pouze tři sloupce: Ready přehled věcí, které čekají na zpracování; Doing aktuálně rozpracované úkoly; Done dokončené úkoly. Nejedná se o žádné dogma, každý si volí složení tabule dle vlastních potřeb. Tato metodika pomáhá úkoly přesunout z paměti na lepící lístek, člověk tak potom na své úkoly nemusí myslet a volnou kapacitu může věnovat práci. Podobně jako tým, také jednotlivec profituje z trvalého rozvoje. Pravidelné retrospektivy pomáhají v ujasnění silných stránek, identifikaci úkolů vhodných k delegování nebo adeptů na zlepšení např. prostřednictvím školení, workshopů nebo změn způsobu práce. Pro více informací o této metodice doporučuji přečíst knihu autorů Jima Bensona a Tonianne DeMaria Barry nazvanou Personal Kanban: Mapping Work Navigating Life [23] Scrumban Metodika určená zejména týmům praktikujícím Scrum, nehledě na to, zda jde o tým, který zavedl Scrum úspěšně nebo těmi neúspěšnými. Stejně jako Kanban i Scrumban přistupuje k zavedení změny evolučně. Přístup je podobný jako u zavádění Kanbanu, nastavení limitu multitaskingu jednotlivce má za účel nastavení kontroly množství WIP v oběhu. Tabule ve Scrumu je nejčastěji rozdělena na kroky To do -> Prováděno (4) -> Hotovo. Vynásobením limitu počtem pracovníků získáme limit pro krok Prováděno. Stále ještě se nejedná o plnohodnotný pull systém. Tento limit je uveden v závorce. Úkoly jsou odebírány a plněny bez omezení (kromě omezení multitaskingu). Když si tým zvykne nepřekračovat svůj WIP limit, může být vytvořeno plnohodnotné workflow, které bude vyjadřovat průchod úkolu. Řekněme Backlog -> Připraveno (2) -> Specifikace (2) -> Vytvoření (2) -> Hotovo. Každý úkol bude procházet postupně jednotlivými stavy. Toto rozdělení již podporuje užívání specializace pracovníků. Pokud má někdo lepší předpoklady pro provádění specifikací, pravděpodobně bude celý proces vykazovat lepší výkonnost, pokud se jí bude věnovat. Díky rozpadnutí celé činnosti na jednotlivé kroky, lze mluvit o toku (flow), který je řízen pull systémem. Přidáním sloupce Připraveno se podařilo oddělit proces prioritizace od procesu přiřazení. Kdyby zde sloupec nebyl, před každým započetím úkolu by se musela znovu provést prioritizace celého Backlogu. Při měření výkonnosti již není dostačující vizualizace Burndown 38

48 chartem, ale lze využít daleko informačně bohatší CFD. To umožní měření doby zpoždění a množství WIP v oběhu. Povolením specializace pro jednotlivé kroky je třeba definovat pravidla předávek a definovat podmínky splnění (Definion-of-Done). Postupně s dalšími kroky se mění priorita týmu z dodržení svého závazku vůči Product Ownerovi na dodržení stabilní doby zpoždění, oddělení intervalu plánování úkolů pro Sprint backlog až k úplnému zrušení časově omezených iterací. Pro více informací o této metodice doporučuji přečíst knihu autora této metodiky Corey Ladase nazvanou Scrumban - Essays on Kanban Systems for Lean Software Development [31]. 39

49 6 Realizace projektu Bumerangy.cz Předchozí kapitola naznačila nutnost splnění základních požadavků před nasazením Kanbanu. Jako podklad jsem si vybral přístup popsaný Zdenko Staníčkem a Josefem Hajkrem v dokumentu Řízení projektů zavádění IS do organizací TUTORIAL [6]. Pro plánování projektu jsem využil Logickou rámcovou matici pro určení strategie projektu a 5 plánů pro naplánování postupu dosažení výstupů projektu. Na provedení a trvalé zlepšování týmu při práci na projektu jsem dohlížel v souladu s principy Kanbanu. O úloze projektového manažera při řízení projektu lze v tomto případě mluvit pouze okrajově, protože tým si úkoly řídil sám, projektový manažer tak hlavně sledoval průběh a zasáhnul by v případě problémů. V praktické části představím, jak z pěti plánů nastavit projekt řízený Kanbanem. Nasazování Kanbanu na zelené louce není obvyklým přístupem. Kanban jakožto katalyzátor změn v organizaci přináší nejlepší výsledky právě při optimalizaci již zavedených procesů. Nicméně dle mého názoru není ani tolik důležité výchozí nastavení organizace jako spíše konsenzus a respektování smluvených pravidel a omezení. Vizualizace workflow a omezení WIP se ukázaly přínosné samy o sobě bez ohledu na to, zda se jimi řídil webdesignér nebo vývojář. 6.1 Plánování pomocí 5 plánů Při plánování projektu je třeba zodpovědět ty správné otázky. V dokumentu [6] je představeno také pořadí, ve kterém si tyto otázky pokládat. Samotné otázky, které zároveň určují jména jednotlivých plánů, jsou samy o sobě dostatečně výmluvné: 1. CO je třeba vytvořit; 2. JAK se k tomu dojde; 3. S KÝM budeme projekt řešit; 4. KDY projekt začneme a dokončíme; 5. ZA KOLIK projekt provedeme. [6] Odpovědi na tyto otázky pomohou s vytvořením základních plánů. Plány tvoří dostatek podkladů pro sestavení Kanban boardu a jeho prvotní nastavení. Otázky je vhodné si pokládat v naznačeném pořadí, případně mezi plány iterovat. Těžko lze plánovat termíny, když neexistuje ustálená představa o předmětu projektu a jeho výstupech. Podoba otázek s trojimperativem není náhodná. Plánováním pomocí 5 plánů vytvoříme takový trojimperativ, který je postavený na přijatelných základech a jehož dodržení bude reálné. 40

50 6.2 Strategie projektu Je nesmyslné plánovat projekt bez ustálené představy o jeho cíli a přínosech. Pro sestavení strategie projektu je vhodné využít metodu Logické rámcové matice. Týmu i projektovému manažerovi poskytuje sdílený pohled na očekávání zainteresovaných stran. Cílem projektu Bumerangy.cz vývoj bylo spustit e-shop, který pomůže zvýšit prodej bumerangů a poskytne studiu divdesign referenční nasazení e-shop řešení. Přínosy projektu: Prodej bumerangů,. Získání zakázek na základě referenčního nasazení na Cíl projektu: Provozování e-shopu Bumerangy.cz Výstupy projektu: Grafický návrh, Datový model, E-shop řešení. Ukazatele dosažení přínosů: Počet objednávek bumerangů je nenulový, Počet zakázek na vytvoření e-shop řešení získaných díky Bumerangy.cz Ukazatele dosažení cíle: Provozovaný e-shop na doméně připravený pro zakládání položek katalogu produktu a přijímání objednávek. Ukazatele dosažení výstupů: Kodér má dostatek návrhů k vytvoření šablon, Datový model poskytuje informace potřebné pro provoz e-shopu, V e-shopu lze provést objednávku. Zdroje údajů pro ukazatele: Přehled objednávek, FlexiBee účetní systém, Databáze zákazníků. Zdroje údajů pro ukazatele: Prohližeč Chrome, Zdrojové kódy, Přesunutí z vývojového serveru na produkční, Vyhodnocení realizace projektu. Zdroje údajů pro ukazatele: PSD soubory s grafickými návrhy, Databáze objednávek, Databáze zákazníků, Katalog produktů. Předpoklady dosažení přínosů: Vytvoření kvalitního datového modelu, Návrh minimalistického průchodu procesem objednávky, Propagace značky divdesign na e-shopu Bumerangy.cz. Předpoklady dosažení cíle: Hostování e-shop u kvalitního poskytovatele webhostingu, Vyhrazení lidských zdrojů pro zpracovávání objednávek a poskytování uživatelské podpory. Činnosti projektu: Tvorba wireframu, Tvorba grafického návrhu, Kódování šablon, Návrh datového modelu, Implementace a testování e-shop řešení. Potřebné vstupy/zdroje: Specifikace zadání, Informační architektura, Nabídka bumerangů, Webdesignér, Kodér, Vývojář. Hrubý rozpočet: Analýza a návrh: Kč Grafický návrh: Kč Kódování šablon: Kč Implementace a testování: Kč Celkem: Kč Tabulka 1 Logická rámcová matice projektu Bumerangy.cz vývoj Projekt neřeší plnění obsahu a nastavení procesů obsluhy e-shopu. Předpoklady dosažení výstupů: Interní projekt nebude odložen z důvodu práce na prioritnějším zákaznickém projektu. Ustálením cíle projektu byl položen základ pro vznik 5 plánů projektu. V souladu s doporučeným postupem byl jako první vytvořen plán CO. 41

51 6.3 Plán CO Plán CO představuje rozpad finálního produktu na meziprodukty, které budou v průběhu projektu vytvořeny. Plán je zachycen pomocí WBS. Na základě informací z LRM bylo rozhodnuto projekt dodat postupně ve třech vydáních: 1. Spustit informační katalog, který poskytne zákazníkům informace o sortimentu s možností objednat zasláním u se seznamem položek. Výstupem bude jak prezentační, tak administrační rozhraní. 2. Rozšířit katalog o práci s košíkem, zjednodušit objednávání pomocí dvou kroků. Rozšíření se týká také administrace, která bude podporovat práci se zákazníky, objednávkami a generování faktur. 3. Pro další rozvoj a budování komunity vytvořit obsahovou prezentační část i s rozhraním pro administrátory. Obr. 12 Plán CO ve formě WBS V takto brzké fázi je zbytečné plánovat meziprodukty příliš podrobně, protože s velkou pravděpodobností v průběhu realizace dojde ke změnám i na úrovni jednotlivých meziproduktů a příliš podrobný plán by musel být znovu přepracován. 42

52 6.4 Plán JAK Plán JAK poskytuje přehled o postupu, jakým dosáhneme stanoveného cíle. Do tohoto plánu zatím není zanášeno časové hledisko. Plán představuje vhodné podklady pro další plány, KDY a ZA KOLIK. Obr. 13 Plán JAK Jednotlivé vydání nových verzí (na Obr. 10 označené zeleně podbarvenými kroky) lze považovat za etapy. Ty za sebou následují sekvenčně a na konci každé etapy je brána, kterou buď projekt projde do další etapy, nebo je ukončen. O případném ukončení projektu rozhoduje zákazník, který posuzuje, zda jemu představená ukázka splňuje jeho požadavky. Lze tak monitorovat postup na projektu a v případě náznaků problémů jej ukončit. Každá etapa obsahuje konečný počet kroků, které jsou dále členěny na úkony. Stejně jako u plánu CO nemá ani v tomto plánu zbytečně podrobné plánování smysl. 43

53 6.5 Plán S KÝM, plán KDY a plán ZA KOLIK V rámci plánu S KÝM k jednotlivým krokům plánu JAK přiřadíme role, které se na nich budou podílet. V případě tohoto projektu se jedná o webdesignéra (DES), kodéra (COD) a vývojáře (DEV). Jednotlivé role můžeme obsadit konkrétními lidmi, minimálně bychom ale měli alespoň určit, kolik lidí pro danou roli budeme potřebovat. Osobně považuji za efektivnější nejdříve odhadnout jednotlivé činnosti z hlediska časové náročnosti, vytvořit plán ZA KOLIK. Jakmile znám odhady pracnosti, mohu lépe odhadovat termíny a tvořit plán KDY. Ušetřím si alespoň jednu iteraci plánů. Přesné odhadování pracnosti na delší časový úsek je považováno za plýtvání, proto také plány KDY i ZA KOLIK jsou ohodnoceny velmi hrubě. Odhadování pracnosti je plně v kompetencích týmu, který ve vhodný čas jednotlivé úkoly ohodnotí z hlediska komplexnosti pomocí techniky Magic estimation. Obr. 14 Plán CO rozšířený o plány KDY, S KÝM a ZA KOLIK 44

54 6.6 Definice workflow a sestavení Kanban boardu Plán JAK v kombinaci s plánem S KÝM představují základní kámen pro vizualizaci workflow. To je většinou určeno činnostmi jednotlivých rolí na projektu. V našem případě lze popsat workflow zjednodušeně jako posloupnost kroků reprezentovaných sloupci: 1. designér připraví sadu grafických návrhů sloupec Návrh; 2. kodér převede návrhy do formy šablony v jazyce HTML sloupec Kódování; 3. vývojář nasadí šablony na připravenou funkcionalitu sloupec Vývoj & nasazení. Kromě výše zmíněných sloupců, které obsahují čistě vývojové činnosti, je třeba udržovat sdílené informace o úkolech, které má tým před sebou a informace o splněných úkolech. Proto do workflow přidáme také následující tři sloupce: Backlog sloupec obsahující činnosti, které čekají na zpracování; Připraveno sloupec obsahující činnosti, které již byly ohodnoceny z hlediska komplexnosti, a které při nejbližší možné příležitosti budou zpracovány; Hotovo sloupec obsahující již dokončené činnosti. Obr. 15 Kanban board projektu Bumerangy.cz vývoj 45

55 Časově omezené iterace jsou veskrze uměle vytvořeným omezením, které má za úkol hlavně zpravidelnit činnosti v týmu, jako např. plánování dalších úkolů, validace výstupů, vydávání nových verzí, atp. Kromě mnoha výhod má dělení na iterace i své stinné stránky. Pokud je interval iterace příliš dlouhý a plánování je spojeno vždy pevně s iterací, dochází k plýtvání v podobě času spotřebovaného na tvorbu plánů, které se stávají v průběhu iterace neplatnými. Pokud je interval iterace příliš krátký, dochází k problémům s umělým dělením funkcionality do několika iterací, i když by bylo výhodnější udělat vše najednou. Kanban se snaží pravidelnosti dosahovat prostřednictvím limitování WIP a ustálením průměrné doby zpoždění. Lze tak oddělit plánování od vývoje a průběžně plánovat další práci tak, jak ji momentálně tým potřebuje. Zároveň lze pružněji reagovat na přání zákazníka, což například v případě uzavřených iterací ve Scrumu není povoleno. Plánování obsahu sloupce Backlog tak probíhá vždy, když klesne obsah sloupce pod dvě položky. V případě tak jednoduchého projektu jako je Bumerangy.cz vývoj si můžeme tento způsob ad hoc plánování dovolit. Po přidání nových úkolů se tým schází a probírá jednotlivé úkoly z hlediska jejich velikosti a případně navrhuje jejich rozpad na úkoly menší velikosti. Konzistentní velikost úkolů je pro Kanban důležitá z důvodů udržování průměrné doby zpoždění. Sloupec Připraveno je příkladem oddělení procesu plánování a prioritizace. Při odebrání položky tým vezme ze sloupce Backlog další úkoly dle aktuálního stavu a jejich předpovědi dalšího vývoje. Tyto nové úkoly jsou ohodnoceny z hlediska komplexnosti metodou Magic estimation a ve sloupci seřazeny podle jejich priority. Postupně jsou pak členy týmu odebírány a není tak třeba znovu při každém úkolu posuzovat, který úkol ze všech v Backlogu vybrat. Obsah kanbanu (lepícího lístku) musí poskytovat dostatek informací pro sebe-řízení týmu. V případě projektu Bumerangy.cz vývoj byl vývoj zároveň kromě fyzického Kanban boardu simultánně zachycován také prostřednictvím webové služby Agilezen. Hlavním účelem tohoto nástroje je poskytování podrobnějších informací ke konkrétním úkolům. Obr. 16 Sada kanbanů 46

56 V tomto projektu kanban obsahoval: ID úkolu v rámci služby Agilezen, název úkolu, zkratky kroku, kterými kanban projde. Vedle zkratky kroku, například DE pro Návrh, je zaznamenáno datum, kdy byl úkol do daného kroku posunut. Lze tak zpětně rekonstruovat průběh projektu pro potřeby retrospektivy. 6.7 Nastavení limitu WIP Na vývojových činnostech projektu se podíleli: 1 webdesignér, který v případě nutnosti mohl pomoci s kódováním; 1 kodér, který v případě nutnosti mohl pomoci s vývojem; 1 vývojář, který v případě nutnosti mohl pomoci s kódováním. Vzhledem k tomu, že ke každému sloupci vývojových činností byl přiřazen primárně právě jeden pracovník, byly sloupce Návrh, Kódování a Vývoj & nasazení ohodnoceny shodně limitem WIP hodnoty 2. Limit sloupce Připraveno byl iniciálně nastaven na hodnotu 3, nicméně v průběhu projektu se projevil tento limit jako příliš omezující a byl povýšen na hodnotu 4, protože některé úkoly neprocházely celým workflow a ze sloupce Připraveno byly posouvány do sloupce Vývoj & nasazení. 6.8 Měření a řízení toku Produktivita týmu je vizualizovaná prostřednictvím CFD. Vstupem pro tento diagram je obsah jednotlivých sloupců Kanban boardu. Diagram je pravidelně aktualizován z důvodu udržování informací o aktuálním stavu a množství WIP v oběhu. Na základě vývoje v čase se dopočítávají další metriky, kterými jsou průměrná doba zpoždění a propustnost. Obr. 17 Tabulka dat zjistitelných z Kanban boardu 47

57 Na CFD je patrný narůst propustnosti ke konci projektu. Tento jev má dvě vysvětlení, jednak může být způsoben trvalým zlepšováním a zkušenostmi členů týmu, ale v takto krátkém projektu byl způsoben spíše zmenšující se časovou náročností jednotlivých úkolů ke konci projektu, které se dařilo rychleji dokončovat. Obr. 18 CFD projektu Bumerangy.cz - vývoj Velikost týmu a nezastupitelnost jeho jednotlivých členů poukazuje na vznik několika úzkých míst. Zohledněním počtu úkolů, které jednotlivým členům připadají, dojdeme k závěru, že nejvytíženějším členem týmu byl vývojář, na kterého připadalo nejvíce samostatných úkolů. Na CFD je viditelné zpomalení procesu (označeno červenou svislou čarou), kdy došlo k následujícím událostem: Vývojář dokončil úkol Nákupní košík vytvořen a přesunul jej do sloupce Hotovo. Z důvodu větší priority vývojář začal pracovat na dvou nových úkolech ze sloupce Připraveno, místo aby přijal úkoly zpracované kodérem. Kodér měl ve frontě 2 úkoly, z nichž úkol Krok zadání údajů vytvořen splnil. Protože vývojář byl zaměstnán úkoly s vyšší prioritou a neměl ve své frontě prostor pro další úkoly, zůstaly ve frontě u kodéra. 48