Využití agilního přístupu v oblasti Business Intelligence

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Využití agilního přístupu v oblasti Business Intelligence Bakalářská práce Autor: Studijní obor: PhDr. Hana Božková Informační technologie a management Vedoucí práce: doc. Ing. Alena Buchalcevová, Ph.D. Praha 2017

2 Prohlášení Prohlašuji, že jsem bakalářskou práci zpracovala samostatně a v seznamu uvedla veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámena se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze, dne 26. června 2017 PhDr. Hana Božková

3 Poděkování Děkuji vedoucí své diplomové práce doc. Ing. Aleně Buchalcevové, Ph.D., za odborné vedení práce, cenné rady a za čas, který mi v průběhu zpracování práce věnovala. Osobní poděkování patří mým nejbližším za jejich podporu během studia.

4 Anotace Bakalářská práce se zabývá analýzou možnosti využití vybraných metodik agilního vývoje (Scrum, Extrémní programování (XP), Kanban, ScrumBan, Lean Software Development) v Business Intelligence (BI) v bankovním prostředí. Součástí práce je i návrh metodiky zavedení agilního vývoje. Klíčová slova agilní metodiky vývoje, Business Intelligence, bankovní prostředí, metodika zavedení. Annotation The bachelor thesis is focused on the analysis of selected agility development methods (Scrum, Extreme Programming (XP), Kanban, ScrumBan, Lean Software Development) in Business Intelligence (BI) in the banking environment. Part of the thesis is also a proposal of the methodology of transition to agile development. Key words agile development methodology, Business Intelligence, banking environment, transition methodology.

5 Obsah 1 Úvod Téma práce Cíl práce a vlastní přínos Struktura práce Použitá terminologie Komentovaná rešerše zdrojů Úvod do problematiky BI vývoje v bankovnictví Bankovnictví Business Intelligence Kimballův přístup Inmonův přístup Přírůstkový přístup REAL přístup Shrnutí kapitoly Modely životního cyklu vývoje softwaru Vodopádový model Agilní model Shrnutí kapitoly Metodiky vývoje softwaru Rigorózní (těžké) metodiky Agilní (lehké) metodiky Scrum Extrémní programování (XP) Kanban

6 5.2.4 ScrumBan Lean Software Development (LSD) Shrnutí kapitoly Analýza možnosti využití agilního konceptu Specifika prostředí banky Specifika vývoje BI řešení Analýza možnosti využití metodik agilního vývoje v oblasti BI v bankovnictví Analýza možnosti využití metodiky Scrum Analýza možnosti využití metodiky Extrémní programování (XP) Analýza možnosti využití metodiky Kanban Analýza možnosti využití metodiky ScrumBan Analýza možnosti využití metodiky Lean Software Development (LSD) Shrnutí kapitoly Návrh metodiky pro zavedení agilního vývoje Předpoklady a omezení zavedení agilní metodiky Metodika zavedení agilního vývoje v oblasti BI v bankovnictví Principy Procesy Praktiky Role Techniky Nástroje Produkty Shrnutí kapitoly Závěr Přínos k řešené problematice

7 8.2 Další náměty na řešení v této oblasti Seznam použité literatury Seznam obrázků Seznam tabulek

8 1 Úvod V posledních letech postupně roste popularita agilních metodik, jak ukazuje např. pravidelný průzkum State of Agile Survey (VersionOne, ). Podle posledních průzkumů z let nejsou již agilní metodiky vývoje pouze doménou startupů a malých e-shopů, stále více jsou využívány softwarovými firmami s více než 100 zaměstnanci, finančními a profesionálními institucemi s více než zaměstnanci. V praxi se využívá řada přístupů a nástrojů, mezi nejčastěji využívané patří Scrum, Extrémní programování (XP), Kanban, ScrumBan a Lean Software Development (LSD). Právě rozsah možností využití konceptu agilního vývoje, jeho relativně snadná implementace, zrychlení procesu dodávky produktu a zvýšení schopnosti řídit rychle se měnící priority, z něj dělá koncept s velkým potenciálem, a to i v komplexním prostředí bank. Také oblast Business Intelligence (BI), poskytující konsolidovaná důvěryhodná data pro podporu manažerského rozhodování (LABERGE, 2012 str. 23), tento vývoj reflektuje. Zpočátku byl silně kladen důraz zejména na zrychlení procesu rozhodování, tj. umožnění uživatelům, aby se na data v datových skladech přímo sami dotazovali. Nicméně z důvodu rostoucího tlaku na zkrácení intervalu mezi zpřístupněním dat, ať již strukturovaných či nestrukturovaných (BigData), a jejich využitím bylo záhy nutné hledat nové způsoby pro zrychlení procesu dodávky BI řešení. Aktuální vývoj konceptů agilního vývoje spočívá v dalším rozvoji škálování agilních metodik (Scrum of Scrums, Scalled Agile Framework (SAFe ), Enterprise Agile/Scrum, Agile Portfolio Management (APM ) a rozšíření hybridních metodik do oblasti řízení projektů (PMI Agile Certified Practitioner (PMI-ACP), PRINCE2 Agile ). 1.1 Téma práce Téma bakalářské práce vychází ze studia dostupných informačních pramenů a z praktické zkušenosti autorky s řízením projektů v oblasti IT/ICT a její profesní specializací na agilní vývoj v oblasti BI v bankovnictví. Práce pokrývá problematiku využití agilních metodik vývoje se zaměřením na oblast IT/ICT projektů s ohledem na specifika BI řešení. Součástí práce je rovněž návrh metodiky zavedení agilního vývoje v oblasti BI v bankovnictví. 4

9 1.2 Cíl práce a vlastní přínos Hlavním cílem práce je provedení analýzy možnosti využití konceptu agilního vývoje v bankovním prostředí v oblasti BI (viz Tabulka 1-1 cíl C4). Téma možnosti využití konceptu agilního vývoje je dále rozpracováno v podobě dílčích cílů (viz Tabulka 1-1 cíle C1-C3). Tabulka 1-1: Dílčí cíle práce a metody jejich dosažení ID CÍLE POPIS DÍLČÍHO CÍLE METODA DOSAŽENÍ CÍLE C1 C2 C3 C4 Kategorizace metodik vývoje softwaru, definice agilního vývoje a charakteristika vybraných metodik agilního vývoje Identifikace a popis specifik souvisejících s vývojem softwaru v bankovním prostředí Identifikace a popis specifik souvisejících s vývojem BI řešení Analýza možnosti využití agilních metod pro vývoj BI řešení v bankovním prostředí 1.) Studium dostupných zdrojů o dané problematice 2.) Kategorizace metodik vývoje softwaru, definice agilního vývoje, výběr metodik pro analýzu 3.) Popis vybraných metodik agilního vývoje 1.) Studium dostupných zdrojů o dané problematice 2.) Definice kritérií pro zhodnocení adresace těchto specifik agilními metodikami vývoje 1.) Studium dostupných zdrojů o dané problematice 2.) Definice kritérií pro zhodnocení adresace těchto specifik agilními metodikami vývoje 1.) Studium dostupných zdrojů o dané problematice 2.) Vyhodnocení adresace specifik vývoje BI řešení 5

10 C5 Vytvoření a popis metodiky pro zavádění konceptu agilního vývoje v oblasti BI v bankovnictví Zdroj: autorka v bankovnictví metodou analýzy výstupů C1-C3 1.) Studium dostupných zdrojů o dané problematice 2.) Specifikace návrhu metodiky pro zavedení agilního vývoje BI řešení v bankovnictví metodou syntézy výstupů C1-C4 Vlastní přínos autorky je obsahem posledního dílčího cíle (viz Tabulka 1-1 cíle C5). K jeho dosažení byly využity všechny výstupy dílčích cílů práce, tj. popis vybraných metodik, kritéria adresace specifik agilního vývoje BI řešení v bankovnictví a výstupy analýzy možnosti využití agilního vývoje. 1.3 Struktura práce Práce je členěna do kapitol, v jejichž úvodu je vždy nastíněn cíl příslušné kapitoly. Na konci kapitoly je vždy uvedeno krátké shrnutí, které komentuje výstupy cílů kapitoly. Kapitola 1 se věnuje tématu práce, formulaci cílů a metod jejich dosažení, včetně sjednocení termínů používaných v rámci této práce. Následující kapitola 2 obsahuje komentovanou rešerši hlavních informačních zdrojů k řešené problematice. V kapitole 3 je úvod do problematiky BI vývoje v bankovnictví. Kapitola 4 popisuje hlavní modely životního cyklu vývoje softwaru a následující kapitola 5 kategorizaci metodik vývoje softwaru, včetně definice agilního vývoje a charakteristiky vybraných metod agilního vývoje (Scrum, extrémní programování, Kanban, ScrumBan a Lean Software Development). Kapitola 6 se věnuje specifikům prostředí banky a vývoje BI, zejména však hlavnímu cíli této práce, analýze možnosti využití konceptu agilního vývoje v bankovním prostředí v oblasti BI. V předposlední kapitole 7 je popsán návrh metodiky pro zavedení agilního vývoje v oblasti BI v bankovnictví. Kapitola 8 obsahuje závěr práce, tj. shrnutí výsledků práce, přínosů autorky k řešené problematice a dalším námětům pro řešení v této oblasti. 6

11 1.4 Použitá terminologie V souvislosti s agilním vývojem je v odborné literatuře často uváděno a zaměňováno několik termínů, tj. metoda, metodika a rámec. Cílem této kapitoly je tuto terminologii, alespoň pro účely této práce, sjednotit. Metoda (Method) určuje, co je třeba dělat v určité fázi nebo činnosti vývoje systému; zpravidla se týká jen některého úhlu pohledu na systém. (BUCHALCEVOVÁ, 2009) [Metodický] rámec (Framework) je mnohem širší než metodika, na rozdíl od ní definuje jednotný pojmový a významový prostor a slouží jako kostra nebo vodítko k budování něčeho (například metodiky, aplikace, systému ). Rámce sjednocují pojmosloví (terminologii) a obsahují referenční modely. (Wilmington, 2016) Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoje údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. (BUCHALCEVOVÁ, 2009) V rámci této práce je dále odlišována metodika vývoje od životního cyklu. Tyto termíny jsou v odborné literatuře často zaměňovány, resp. životní cyklus je označován termínem metodika. Životní cyklus je model procesu vývoje softwaru, který definuje postup ve fázích analýza požadavků architektonický návrh detailní návrh vývoj softwaru integrace testování kvality podpora [provozu] (2013) 7

12 2 Komentovaná rešerše zdrojů Kapitola shrnuje nejvýznamnější informační zdroje, týkající se metodiky agilního vývoje datových skladů a BI řešení a tématech souvisejících s cíli práce formou komentované rešerše. Výchozím zdrojem popisujícím metodiku budování informačních systémů, který se věnuje rovněž agilním metodikám vývoje softwaru, je (BUCHALCEVOVÁ, 2009). Dalším základním pramenem, věnujícím se metodice agilního vývoje datových skladů, je (CORR, a další, 2013). Jedná se o jednu z nejuznávanějších knih o agilním vývoji v oblasti BI. Jako jediný z dostupných zdrojů přináší definici metodiky dimenzionálního modelování (BEAM*) zaměřenou na agilní vývoj datových skladů a BI řešení. Vzhledem k zadání tématu této práce posloužily tyto zdroje jako základní literatura k tématu. Základní přehled vývojových metodik specifických pro oblast datových skladů a BI podává (LABERGE, 2012). Mezi knihy, které se detailně věnují agilnímu přístupu k vývoji BI řešení, patří obě publikace Agile Data Warehousing (HUGHES, 2013), (HUGHES, 2016). Nahrazují Hughesovu první publikaci (HUGHES, 2008) z roku 2008, která popisuje možnosti využití metodiky Scrum a XP pro vývoj agilního BI. Základním pramenem pro charakteristiku metodiky Scrum bylo aktualizované vydání Scrum Guide (SCHWABER, a další, 2016) z roku 2016, pro Extrémní programování (XP) (BUCHALCEVOVÁ, 2005), Kanban (HAMMARBERG, a další, 2014), ScrumBan (REDDY, 2015) a pro Lean Software Development (ŠOCHOVÁ, a další, 2014). Dalším významným informačním zdrojem, který nepřetržitě od roku 2006 sleduje úspěšnost rigorózních a agilních metodik, jsou publikované výsledky průzkumů State of Agile Survey (VersionOne, ). Z českých zdrojů byly využity diplomové práce na obdobné téma: Specifika rozvoje datového skladu v bance (KARÁSEK, 2016), Kanban a možnosti jeho využití v bankovním prostředí (HEFNEROVÁ, 2015), ScrumBan pro malé a střední firmy (CHEKHLOV, 2014) a Moderní metodiky vedení projektů (pro implementace zakázkového SW) (ZATLOUKAL, 2014), kompilující dostupné zahraniční případové studie. Úplnný přehled všech použitých informačních zdrojů bakalářské práce poskytuje kapitola 9 Seznam použité literatury. 8

13 3 Úvod do problematiky BI vývoje v bankovnictví Cílem této kapitoly je poskytnout úvod do řešené problematiky a vysvětlit základní pojmy bankovního prostředí a Business Inteligence. Základními prameny je zákon č. 21/1992 Sb., o bankách (Česká republika) v platném znění, (NOVOTNÝ, a další, 2011) a (DEVLIN, 2013). 3.1 Bankovnictví Zákon č. 21/1992 Sb. definuje banky jako akciové společnosti se sídlem v České republice, které přijímají vklady a k výkonu činnosti mají bankovní licenci (Česká republika) Činnost bank dále podrobně upravují vyhlášky a úřední sdělení České národní banky (ČNB) (Česká národní banka) a další právní předpisy související např. s řízením finančních skupin. Termín bankovní prostředí označuje prostředí, ve kterém banky podnikají. Toto prostředí se v řadě charakteristik odlišuje od prostředí pro ostatní podnikatelské subjekty. Především se jedná o výrazně přísnější a regulovanější prostředí, které se vyznačuje specifickými riziky. Obecně se v této souvislosti hovoří o 2 typech rizik (FLEISCHMANN, 2014), a to o rizicích systémových, která mají vliv na stabilitu celého finančního sektoru, a podnikatelských rizicích, ovlivňujících pouze stabilitu jednotlivých bank (např. rizika úvěrová, operační, reputační). Součástí mezinárodních regulací v oblasti řízení rizik jsou proto požadavky na měření a sledování stanovených rizikových ukazatelů, známé jako dohody BASEL I, BASEL II a BASEL III (ROYCE, 1970), do české legislativy jsou zaváděny prostřednictvím opatření ČNB o kapitálové přiměřenosti bank (Česká národní banka, 2002). Bankovní regulace se týkají také informačních systémů banky. Kromě požadavků na archivaci informací o uskutečněných obchodech, zajištění oddělení systémů komerčního a investičního bankovnictví, na implementaci systému pro řízení, měření a sledování podnikatelských rizik, jsou kladeny vysoké požadavky také na ochranu osobních údajů a zajištění mlčenlivosti zaměstnanců, kteří s těmito údaji mohou přijít do styku. Tyto požadavky se neustále zpřísňují, podléhají ochraně podle zákona č. 101/2000 Sb. (Česká republika) a nově i požadavkům nařízení Evropské unie o ochraně osobních údajů (GDPR) (European Commission), které vstoupí v platnost

14 Obecně lze říci, že z pohledu regulátora (ČNB) je kladen důraz zejména na tyto oblasti činností IT/ICT útvarů (FLEISCHMANN, 2014 str. 39): strategie rozvoje informačních systémů, bezpečnostní zásady informačních systémů, řízení bezpečnosti informací (včetně analýzy rizik a klasifikace aktiv), řízení přístupu k informačním systémům (včetně komunikačních sítí a monitoringu), provoz informačních systémů, rozvoj informačních systémů, outsourcing a smluvní vztahy, nezávislé ujištění (audit operačního rizika a rizik IS/ICT). 3.2 Business Intelligence (NOVOTNÝ, a další, 2011 str. 19) definují Business Intelligence (BI) jako komplex přístupů a aplikací IS/ICT, které téměř výlučně podporují analytické a plánovací činnosti podniků a organizací, a jsou postaveny na principech multidienzionality a možnosti nahlížet na realitu z několika možných úhlů. Aplikace BI dle této definice pokrývají analytické a plánovací funkce většiny oblastí řízení podniku a nástroje, které k tomu BI využívá, prakticky všechny oblasti od zpracování informací mezi zdrojovými systémy až po prezentační analytickou vrstvou: dočasná uložiště dat (Data Staging Area, DST), operativní uložiště dat (Operational Data Store, ODS), transformační nástroje (Extract Transformation Load, ETL), integrační nástroje (Enterprise Application Integration, EAI), datový sklad (Data Warehouse, DWH), datová tržiště (Data Marts, DMA), OLAP (Online Analytical Processing) a ROLAP (Relational OLAP), manažerské aplikace (Executive Information System, EIS), nástroje pro dolování dat (Data Mining), nástroje pro zajištění kvality dat, nástroje pro správu metadat, analytické nástroje pro zpracování BigData a další. 10

15 Jádrem většiny BI řešení nadále však nadále zůstává datový sklad (DWH). V této souvislosti je nutné uvést, že rozhodnutí o architektuře budování DWH zásadním způsobem ovlivňuje metodiku vývoje závislých BI řešení. Mezi nejčastěji využívané je v odborné literatuře (LABERGE, 2012), (NOVOTNÝ, a další, 2011) uváděn Inmnoův (viz kapitola 3.2.2) a přírůstkový přístup (viz kapitola 3.2.3). V souvislosti s rostoucím tlakem na zpracování nestrukturovaných dat nabývají na významu také pokusy zavedení nové logické architektury (viz kapitola 3.2.4) pro BI řešení Kimballův přístup Kimball chápe datový sklad jako množinu datových tržišť, které je možné integrovat pomocí sběrnice (Bus Architecture) (LABERGE, 2012 str. 225). Typické pro tento přístup je využívání dimenzionálního datového modelu (např. BEAM*). Obrázek 1: Kimballův dimenzionální přístup (DEVLIN, 2013 str. 121) Inmonův přístup Inmon naopak doporučuje nejprve vytvořit datový sklad jako integrovanou datovou základnu a teprve následně budovat datová tržiště pro jednotlivé oblasti využití BI (Hub and Spoke 11

16 Architecture) (LABERGE, 2012 str. 188). Datový sklad založen na normalizovaném relačním datovém modelu, využití dimenzionálního modelu připouští tento přístup pouze pro tvorbu datových tržišť. Obrázek 2: Inmonův EDW přístup (DEVLIN, 2013 str. 124) Přírůstkový přístup Kombinaci obou přístupů popisuje (NOVOTNÝ, a další, 2011 str. 49) jako využití relačního modelu při tvorbě datového skladu a dimenzionálního pro datová tržiště. Jde o nejmladší a v současnosti nejčastěji využívaný přístup REAL přístup (DEVLIN, 2013) navrhuje v souvislosti s rostoucí potřebou zákazníků na analytické zpracování velkého množství nestrukturovaných dat (BigData) zavedení nové logické architektury, kterou označuje akronymem REAL 1. Tento přístup umožňuje propojení výsledků BigData analýz s daty uloženými v DWH, přičemž analýza nestrukturovaných dat probíhá mimo DWH ve specializovaném výpočetním prostředí s vysokou dostupností postaveným nad distribuovaným systémem (Hadoop). Jedná se o zcela nový a v bankovním prostředí dosud neprověřený přístup. 1 REAL (Realistic Extensible Actionable Labile) Realistic zohledňuje možnost implementace této architektury pomocí aktuálně známých technologií, Extensible představuje otevřenost pro rozšiřování funkcí a vlastností, Actionable odpovídá na požadavek jasné identifikace údajů na obecné úrovni se zachováním možnosti extrapolace do detailní úrovně a Labile vyjadřuje flexibilitu architektury vůči změnám. 12

17 3.3 Shrnutí kapitoly Obrázek 3: Devlinův REAL přístup (DEVLIN, 2013 str. 359) Bankovní prostředí se výrazně odlišuje od prostředí pro ostatní podnikatelské subjekty, je to přísnější a regulovanější prostředí, které se vyznačuje specifickými riziky. Jádrem většiny BI řešení nadále zůstává datový sklad, rozhodnutí o architektuře jeho budování proto významným způsobem ovlivňuje metodiku vývoje závislých BI řešení. 13

18 4 Modely životního cyklu vývoje softwaru Cílem kapitoly je vysvětlení hlavních modelů životního cyklu vývoje softwaru. Kromě níže uvedených existují ještě další modely (ISTQB), např. V-model, inkrementální model, RAD model, iterativní model či prototypový model. Pro účely této práce jsou popsány pouze 2 nejčastěji využívané, tj. vodopádový a agilní model vývoje. 4.1 Vodopádový model Sekvenční metodika vývoje softwaru, využívající vodopádový model životního cyklu, je stále jednou z nejpopulárnějších metodik. Royce publikoval tento model v 70. letech 20. století v článku Managing the Development of Large Software System (ROYCE, 1970). Obrázek 4: Vodopádový model (ROYCE, 1970 str. 329) Vývojový proces je rozdělen na několik fází, každá z nich staví na výstupech fáze předcházející. Velký důraz je kladen na plánování a dokumentaci. Logicky je tedy nevýhodou skutečnost, že na počátku není možné přesně specifikovat všechny požadavky zákazníka a příp. chyby zanesené na začátku projektu se tak projeví v pozdějších fázích. V 90. letech 20. století byl model v souvislosti s testováním upraven (V-model), každé vývojové fázi byl přiřazen definovaný typ testu (analýza požadavků akceptační testy, návrh systému systémové testy, návrh architektury integrační testy, detailní návrh jednotkové testy), přechod mezi jednotlivými typy testů je podmíněn úspěšným dokončením předcházející fáze vývoje. 14

19 4.2 Agilní model Agilní vývoj znamená především změnu přístupu k paradigmatu limitujících faktorů řízení projektů (viz Obrázek 5). Ústředními aktivitami agilního modelu je návrh a implementace vybraných požadavků zákazníka, a to v požadované kvalitě, termínu a nákladech. Výsledky jsou zákazníkem akceptovány během vývojového procesu. Obrázek 5: Limitující faktory projektů ve vodopádovém a agilním modelu (GERARD, 2015) Agilní metodiky mají nejvyšší přidanou hodnotu u projektů s nejasným zadáním, kdy je výhodou rychlá zpětná vazba zákazníka, schopnost a ochota ke změně i v pozdějších fázích vývoje. Pro jasné požadavky a dobře definovaný požadovaný výsledek je nejlépe využít vodopádový model. Výzkumné vývojové aktivity bez definovaných základních požadavků nevyužívají ani jednu z popisovaných metodik, ale specifické metodiky pro řízení inovací (např. TRIZ) viz Obrázek 6. Obrázek 6: Spektrum složitosti problému (MACHÁČEK, a další) 15

20 4.3 Shrnutí kapitoly Vodopádový model je stále velmi populární a používaný v rámci projektového řízení. Využití agilního modelu znamená především změnu přístupu k limitujícím faktorům řízení projektů (viz Obrázek 5), nejvyšší přidanou hodnotu má tento přístup u projektů s nejasným zadáním, kdy je výhodou rychlá zpětná vazba zákazníka, schopnost a ochota ke změně i v pozdějších fázích vývoje. 16

21 5 Metodiky vývoje softwaru Kapitola je věnována charakteristice nejvyužívanějších metodik vývoje softwaru. V odborné literatuře je popsána celá řada kategorizací metodik vývoje softwaru. Pro účely práce byla využita kategorizace, kterou uvádí (BUCHALCEVOVÁ, 2005), založená na kritériu váha metodiky. Ke srovnání bylo vybráno celkem 5 agilních metodik, označených v průzkumech State of Agile Survey (VersionOne, ) jako nejčastěji využívané. 5.1 Rigorózní (těžké) metodiky Rigorózní metodiky vývoje jsou zpravidla založeny na vodopádovém modelu životního cyklu (BUCHALCEVOVÁ, 2005 str. 22) a na důsledné analýze rizik. Jde o tzv. těžké metodiky předpokládající, že všechny požadavky je možné specifikovat předem, změnám (zejména v pozdějších fázích životního cyklu) je vhodné se vyhnout a/nebo je alespoň maximálně omezit, technické řešení požadavků je náročné a zahrnuje velké množství meziproduktů (např. modelů, technických specifikací apod.). Obecně jsou tyto metodiky hodně podrobné, obsahují definici řady procesů, rolí a podporují direktivní řízení vývoje. Mezi rigorózní metodiky byl dříve řazen např. RUP (Rational Unified Process), nicméně od roku 2003 se do metodiky postupně vkládají agilní principy a praktiky. Dnes je RUP spíše rámcem metodik, které lze používat v různých úrovních granularity a vytvořit tak jak rigorózní, tak agilní metodiku. 5.2 Agilní (lehké) metodiky Oproti tomu agilní metodiky, označované někdy také jako lehké metodiky, jsou skupinou metod původně určených pro vývoj softwaru založený na iterativním a inkrementálním vývoji. Obecně jsou zaměřeny na ty činnosti, které vytváření hodnotu pro zákazníka, a naopak eliminují činnosti, které hodnotu nepřinášejí. Umožňují tak rychlý vývoj softwaru a zároveň dokážou reagovat na změnu požadavků v průběhu celého životního cyklu. Vychází z teorie, že správnost systému lze ověřit jedině iterativní pomocí rychlého vývoje, představení inkrementu produktu zákazníkovi a následným provedením úprav na základě obdržené zpětné vazby. Techniky používané agilními metodiky se používaly již dříve, ale pojem se začal používat až v roce 2001, kdy byl publikován Manifest agilního vývoje (2001) definující základní principy agilního programování: 17

22 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. Tak jak se jednotlivé metodiky postupně vyvíjely, přebíraly vzájemně jednotlivé principy, procesy, praktiky, role, techniky, nástroje a produkty (viz Obrázek 7). Obrázek 7: Vývoj a vzájemné přebírání principů mezi metodikami vývoje (HUGHES, 2016 str. 15) Stručný přehled nejčastěji využívaných prvků agilního vývoje pro 5 vybraných metodik, které jsou předmětem analýzy možnosti využití agilních metodik (viz kapitola 6.3), poskytuje Tabulka

23 Tabulka 5-1: Přehled využívání prvků agilního vývoje Prvek agilního vývoje Scrum XP Kanban ScrumBan LSD Iterativní vývoj X X X X Timeboxing (iterace) X X Zákazník na pracovišti X X X Zásobník požadavků X X X Uživatelské příběhy (User Stories) X X X Vyhodnocení dodávky X X X Plánovací hra X X Rychlost týmu (Velocity) X X Trvání vývojového cyklu (Cycle Time) X X Diagramy toku (Burn Charts) X X X Kumulativní diagram toku (CFD) X Vizualizace postupu řešení úkolů (Board) X X X Limity rozpracovaných úloh (WIP) X X X Vizualizace postupu přidání fází a limitů X X Prototypy (Spike Solution) X X Refaktoring X X X X X Neustálé zlepšování (Kaizen) X X X Řízení toku (Pull System) X X X Plánování releasů X X Teorie front X X X Zdroj: autorka 19

24 5.2.1 Scrum Scrum je jednou z nejznámějších a dnes nejčastěji využívaných agilních metodik (VersionOne, ). Vznikl v 90. letech 20. století a je založen na teorii řízení empirických procesů, tj. rozhodování je vždy založeno na tom, co je známo. Metodika Scrumu tak umožňuje zvládnout jednoduché i složité projekty při zachování rychlé a efektivní dodávky produktů s vysokou obchodní hodnotou pro zákazníka. Při správné implementaci Scrum zviditelňuje efektivnost vývoje a metod produktového řízení. Scrum Guide TM (SCHWABER, a další, 2016) označuje Scrum jako jednoduchý, srozumitelný a extrémně obtížný pro dokonalé zvládnutí. Doporučené strategie pro úspěšnou implementaci Scrumu se liší případ od případu a jsou popsány např. ve zdrojích (KALLMAN, a další, 2014) či (ŠOCHOVÁ, a další, 2014). Principy Jednou z důležitých vlastností Scrumu je flexibilita, kdy vývojový tým může v další iteraci používat techniky a nástroje, které se mu osvědčily. Mezi základní principy, které umožňují takové řízení (COHN, 2010), patří: viditelnost aspekty procesu, které ovlivňují jeho výstup, musí být pravdivé a viditelné osobám řídícím proces, kontrola (inspekce) jednotlivé aspekty procesu musí být zdokonalovány dostatečně často tak aby byly zachyceny nepřípustné odchylky, adaptace pokud kontrolor z výsledku inspekce vyvodí, že jeden či více aspektů procesu se ocitl mimo přípustné limity a výsledný produktu tak bude neakceptovatelný, musí proces upravit co nejrychleji, aby se předešlo dalším odchylkám. Procesy Jednotlivým iteracím vývoje se ve Scrumu říká sprinty. Veškerá vývojová činnost se odehrává ve sprintech, tj. jednotně stanovených časových intervalech dodávek. Scrum definuje celkem 4 činnosti pro kontrolu a adaptaci, které jsou součástí každé iterace sprintu: 20

25 Obrázek 8: Životní cyklus vývoje ve Scrumu (Scrum.org) Plánování sprintu (Sprint Planning) - na začátku každého sprintu probíhá plánování sprintu, kdy vlastník produktu pomocí prioritizace prvků z Product Backlogu sdělí týmu, co je v daném sprintu požadováno. Tým pak po úvaze sdělí vlastníkovi produktu, kolik z požadovaných prvků stihne zpracovat v tomto sprintu. Schválením plánu začíná běžet čas daného sprintu. Denní schůzka (Daily StandUp) - jedním z nejdůležitějších a nejinovativnějších prvků Scrumu jsou denní schůzky. Každá schůzka trvá max. 15 minut a probíhá výhradně vestoje, aby se u účastníků podpořila tendence ke stručnosti vyjadřování. Každý z účastníků odpovídá na 3 otázky: Co jsem udělal včera? Co udělám dnes? Vidím nějaké překážky, které brání dalšímu postupu? a umožňuje tak včas korigovat směřování vývojových aktivit a synchronizovat vývojáře. Vyhodnocení sprintu (Sprint Review) - je určeno pro všechny zainteresované osoby, zejména však vlastníka produktu, kterému tým prezentuje dodaný inkrement produktu. Cílem je získat zpětnou vazbu od zainteresovaných osob, příp. dohodnout úpravu či změnu požadavků pro další iteraci a povzbudit přítomné v dohodě nad další prací týmu. Retrospektiva sprintu (Sprint Retrospective) - se naopak zabývá vnitřními procesy fungování Scrum týmu. Scrum Master během retrospektivy facilituje diskusi o podnětech ke zlepšení spolupráce mezi členy týmu, efektivity práce a fungování celého Scrum týmu. Praktiky Využívá většinu praktik XP (viz kapitola 5.2.2). 21

26 Role Scrum Guide TM (SCHWABER, a další, 2016) definuje, že Scrum tým se skládá z vlastníka produktu, vývojového týmu a Scrum mastera : Scrum tým je sebe organizující a multifunkční. Vlastník produktu (Product Owner) představuje zájmy zainteresovaných osob. Je zodpovědný za specifikaci požadavků, návratnost investic (ROI) a plán dodávek softwaru. Požadavky dokumentuje v Product Backlogu, průběžně určuje jejich prioritu, příp. ji přehodnocuje. Každý požadavek musí být definován formou uživatelského příběhu (User Story) a musí mít stanovena akceptační kritéria (Definition of Done). Vlastník produktu je obvykle zástupcem zákazníka, může ale jít i o člena vývojového týmu. Vývojový tým je zodpovědný za vývoj funkcionality. Tým se řídí a organizuje sám, sám také určuje, jakým způsobem bude technicky řešit požadavky klienta z Product Backlogu do použitelného inkrementu produktu. Zodpovědnost za úspěch každé iterace tak leží na celém týmu, ideální počet členů týmu je obvykle uváděn 3-9 osob. Scrum Master má na starosti samotný proces Scrumu. Školí zainteresované osoby (stakeholdery) v principech Scrumu, implementuje vhodně Scrum do kultury firmy a kontroluje dodržování pravidel a praktik Scrumu. Je to právě Scrum Master, kdo na každodenním setkání klade otázky a zajišťuje facilitaci jednání. Náplní jeho práce je především odstraňování překážek, které brání týmu v dosažení maximální efektivity. Techniky MoSCoW prioritizace slouží k seřazení požadavků do 4 kategorií podle důležitosti dodání v dané termínu: o Must have (musí být) o Should have (mělo by být) o Could have (může být) o Won t have for now (nyní nebude) Timeboxing představuje rozdělení vývoje produktu a jednotlivých událostí, které jsou jeho součástí do krátkých časových intervalů Postupné plánování (Progressive Planning) umožňuje plánovat po vrstvách (tj. release, iterace, denní plán) od high-level plánu s horizontem 3-6 měsíců po přiřazování úloh jednotlivým vývojářům. V průběhu plánovací schůzky (Planning Meeting) jsou nejprioritnější požadavky zákazníka vybrány do backlogu sprintu, ohodnotí se jejich 22

27 pracnost a příp. jsou rozděleny do jednotlivých technických úloh (Technical Stories), které je možné dokončit v rámci jedné iterace. User Stories popisuje požadavky zákazníka na produkt pomocí krátkého příběhu, dobrá user story by měla splňovat kritéria INVEST 2 Burn charty grafy zachycující trendy (burndown, burnup), ukazují postup práce o vertikální osa zobrazuje úsilí (effort), tj. množství práce, které má být vykonaná o horizontální osa zobrazuje čas, tj. počet dní či konkrétní data Nástroje Vizualizace postupu sleduje množství zbývající práce a porovnává ho s údaji z předchozích sprintů, pro posouzení, zda postup vývojových prací směřuje k dosažení cíle v požadovaném čase. K odhadování budoucího průběhu jsou využívány grafy zachycující trendy (Brun-Down, Burn-Up Charts) a další prediktivní techniky. Planning Poker sada karet slouží k relativnímu odhadování pracnosti úkolu, pro odhady je využívána upravená Fibonacciho posloupnost (hodnoty 0, ½, 1, 3, 5, 8, 13, 20, 40, 100) a karty? (nejasné zadání, pro ohodnocení je nutné zodpovědět dotazy), (úkol je příliš komplexní) a pro dlouhé schůzky káva (5 min. přestávka). Cílem hry je po diskusi v rámci ohodnocování najít shodu celého týmu. 2 Akronym INVEST (Independent Negotiable Valuable Estimable Small Testable) představuje kritéria pro požadavky, které by měly být dodávány v příštím sprintu. Ty by měly být nezávislé, mělo by být možné o nich jednat, mít obchodní hodnotu pro zákazníka, být dostatečně malé testovatelné. 23

28 Produkty Artefakty definované Scrumem jsou navržené pro zajištění max. transparentnosti informací. Produktový backlog je dle priorit seřazený seznam všech požadavků, specifikace požadavků by měla splňovat kritéria DEEP 3 a položky by měly být prioritizovány dle kritérií DIVE 4. Jednotlivé požadavky by neměly být technického charakteru a měly by být vzájemně nezávislé. Prioritizace požadavků probíhá průběžně (Product Backlog Grooming), úpravy a změny schvaluje vlastník produktu, který je zodpovědný za obsah, dostupnost a prioritizaci backlogu. Backlog sprintu je podmnožinou požadavků vybraných z produktového backlogu, které vývojový tým plánuje dodat v následujícím sprintu. Jednotlivé požadavky musí splňovat kritéria INVEST a mohou být dále rozpadnuty do jednotlivých vývojových úkolů splňujících navíc kritéria SMART 5. Součástí specifikace požadavku je i ocenění práce potřebné k dodání dané funkcionality. Backlog sprintu upravuje vývojový tým po celou dobu trvání sprintu. Tyto úpravy jsou potřebné proto, že vývojový tým během sprintu získává další informace o tom, co vše je nutné ke splnění cíle sprintu. Přírůstek (Increment) - tvoří všechny dokončené úkoly v průběhu aktuálního a všech předchozích sprintů. Na konci sprintu musí nový přírůstek splňovat podmínky definované pro akceptaci dodávky jako hotové. 3 Akronym DEEP (Detailed appropriately Estimated appropriately Emergent Prioritized as needed) představuje kritéria pro specifikaci položek v produktovém katalogu. Požadavky by měly být definovány na přiměřené úrovni podrobnosti, měla by být odhadnutelná jejich pracnost, průběžně by mělo být revidováno, aktualizováno jejich znění, doplňovány příp. změny a přehodnocována jejich priorita. 4 Akronym DIVE (Dependencies Insured against risks Business Value Estimated effort) je mnemotechnickou pomůckou pro prioritizaci požadavků. Dokonce i při pravidelné revizi mohou v backlogu zůstávat reziduální závislosti, které budou mít vliv na pořadí požadavků. Nemělo by se zapomínat na ošetření obchodních a technických rizik, vyjádření obchodní hodnoty a nacenění pracnosti vývoje. 5 Akronym SMART (Specific Measurable Achievable Relevant Time-Boxed) představuje mnemotechnickou pomůcku pro vyjádření cílů. Vývojový úkol musí být dostatečně konkrétní, měřitelný, dosažitelný, relevantní a v neposlední řadě také ohraničený v čase. 24

29 5.2.2 Extrémní programování (XP) Extrémní programování (XP) představuje vedle Scrumu a Kanbanu jednu z nejznámějších a nejvíce využívaných agilních metodik. Metodiku vymyslel v 90. letech 20. století Beck pro aplikaci výpočtu kompenzací ve mzdovém systému, řada používaných praktik je však starších. Detailnější popis metodiky viz (SOMMERVLLE, 2013). Principy XP se zaměřuje na techniky a postupy, které se osvědčily. Současně dává vývojářům možnost upravit produkt, v závislosti na zpětné vazbě zákazníka a příp. změně požadavků, i v pozdějších fázích vývoje. Jednoduchost návrh řešení je jen tak složitý, aby vyhovoval aktuálním požadavkům, řešení se vyvíjí po malých inkrementech s častou zpětnou vazbou a snaží se eliminovat chyby, změny a nepochopení požadavků zákazníka. Komunikace předpokladem spolupráce je neustálá komunikace mezi členy vývojového týmu a zákazníkem. Zpětná vazba vývoj probíhá v malých iteracích a na konci každé z nich dodává funkcí software; i v průběhu iterace tým představuje zákazníkovi implementované funkcionality a snaží se získat zpětnou vazbu tak, aby mohl dodávat co nejkvalitnější produkt dle požadavků zákazníka. Respekt základním principem je vzájemný respekt zákazníka a vývojového týmu; tým respektuje přání a potřeby zákazníka, zákazník zase jejich technické znalosti a zkušenosti. Odvaha souvisí se schopností přijmout změnu, přijmout odpovědnost za rozhodnutí, schopnost nazývat věci pravým jménem a dělat věci jinak než dosud. Procesy Zadání sběr požadavků zákazníka ve formě uživatelských příběhů (User Stories) Plánování zákazník stanoví prioritu požadavků a vybírá pro plán iterace ty, které mu přináší nejvyšší obchodní hodnotu, příp. je přidána oprava chyb u funkcionalit, které neprošly akceptačními testy. Pokud práci nelze v daném čase dokončit, vyžaduje metodika omezení rozsahu práce. Návrh tým rozdělí User Stories na jednotlivé technické úlohy, nacení je a stávají se tak součástí plánu iterace. 25

30 Programování součástí implementace musí být kromě unit testů i refaktoring, v opačném případě narůstá technický dluh a software přestane být časem udržitelný. Testování automatizace testování umožňuje vytvářet testovací scénáře na nové funkcionality ještě před jejich implementací; provedení unit testů je podmínkou nutnou, nikoliv však postačující pro vydání releasu. Dodávka a akceptace pokud dodávka splňuje všechna akceptační kritéria, zákazník ji musí převzít. Obrázek 9: Životní cyklus vývoje v XP (SOMMERVLLE, 2013 str. 70) Praktiky 12 základních praktik XP cílí zejména na vývojáře a testery. Většinu z nich dnes využívají i další metodiky agilního vývoje. Plánovací hra zákazník ve spolupráci s vývojovým týmem vytvoří prioritizovaný seznam požadavků (User Stories), jednotlivé požadavky zařadí do plánu iterací vývoje. Zákazník na pracovišti zákazník sedí společně s vývojovým týmem a je mu k dispozici k příp. konzultacím, což podporuje intenzivní komunikaci. Časté releasy nejdříve se vyvíjí min. užitečná sada funkcí, která poskytuje zákazníkovi max. obchodní hodnotu; releasy následují rychle po sobě a inkrementálně doplňují další funkce dle zákazníkem stanovené priority požadavků. Společný cíl pro podporu komunikace je definován tzv. společný příběh (System Metaphore), který vzájemně spojuje požadavky zákazníka a určuje priority požadavků pro implementaci. Párové programování (Pair Programming) nad jedním zdrojovým kódem pracují společně 2 programátoři, první píše kód, druhý přemýšlí, kontroluje, přichází s nápady. Programátoři si role v páru střídají a vzájemně komunikují své záměry a postřehy, vzniká tak rychlá zpětná vazba. 26

31 Sdílený kód (Collective Code Ownership) společné vlastnictví zdrojového kódu softwaru. Standardy kódu nutné sjednocení standardů pro zdrojový kód, aby byl kdokoliv schopný efektivně pracovat s kódem druhého (tj. nemělo by být poznat, kdo psal, kterou část kódu). Dodržování tohoto principu je nutné pro párové programování a pro refaktoring. Udržitelné tempo (Sustainable Pace) - pokud jsou programátoři unavení, pak dělají více chyb a produkují špatný kód; proto nejsou povolené žádné přesčasy Kontinuální integrace (Continual Integration) - metodika podporuje integraci nových funkcí co možná nejčastěji, po přidání jsou okamžitě spuštěny testy a je možné ověřit, zda něco nefunguje. Technický dluh představuje doporučení vždy zvolit nejjednodušší řešení a případné změny a/nebo komplexnější kód (pokud bude nezbytný) implementovat později Refaktoring kódu (Continuous Refactoring) - čištění zdrojového kódu a odstraňování vzniklého technického dluhu. TDD (Test Driven Development) někdy označovaný jako jednotkové testování celého kódu. Spočívá v tom, že nejdříve připravíme test obsahující akceptační kritéria, teprve pak píšeme vlastní kód programu. Role Vývojový tým je multifunkční tým složený z vývojářů a testerů Zákazník představuje koncové uživatele softwaru, současně musí mít schopnost a pravomoc definovat požadavky, stanovovat priority. Techniky Review technika někdy označovaná jako kontrola 4 očí v podstatě říká, že cokoliv děláte, měl by zkontrolovat ještě někdo jiný. User Stories popisuje požadavky zákazníka na produkt pomocí krátkého příběhu, vyznačují se zejména menší mírou detailu a zaměřením na potřeby zákazníka Nástroje CRC karty (Class, Responsibility, Collaboration) jsou nástrojem pro návrh objektověorientovaného softwaru. S jejich pomocí tým prochází jednotlivé scénáře a snaží se definovat, jaké se budou v systému vyskytovat třídy a jak budou interagovat. Spike Solutions prototypy nebo testy architektury, technologií a návrhu pro oblasti, které se zdají být z nějakého důvodu jako rizikové 27

32 Produkty Release softwaru uvolnění publikace nové verze obsahující přidané a/nebo upravené funkcionality na základě požadavků zákazníka Kanban (ŠOCHOVÁ, a další, 2014 str. 105) uvádí, že Kanban byl původně určen pro řízení počtu lidí v chrámu. Známější je jeho využití ve strojírenské výrobě, dnes je však metodika využívaná i mimo tuto oblast (HAMMARBERG, a další, 2014). Podoba i účel metodiky v oblasti softwarového vývoje liší od podoby Kanbanu ve výrobě. V oblasti výroby se jedná o objednávání materiálu při poklesu úrovně zásob na určité předem stanovené množství. U softwarového vývoje jde především o nastavení limitů rozpracovaných úkolů. Principy Vizualizace práce vizualizace postupu práce je neustále dostupná všem členům týmu, zajišťuje přehled postupu práce na jednotlivých úkolech, prostředek pro komunikaci a nástroj pro identifikaci problémových oblastí. Omezování rozpracovaných úkolů nastavení limitů pro rozpracované úkoly (WIP) zajišťuje plynulost toku práce a omezuje potencionální zdroje plýtvání. Vyrovnaný hodnotový tok důsledné uplatňování principu tahu (Pull System), kdy práci na novém úkolu je možné začít až poté, co se pro něj uvolní kapacita v rámci limitu rozpracovaných úkolů, zajišťuje plynulý tok práce a snazší identifikaci problémů. Neustálé zlepšování (Kaizen) pravidelné sledování produktivity týmu, ať už z hlediska rychlosti či kvality dodaného softwaru, a plynulosti hodnotového toku umožňuje další rozvoj a úpravu nastavených procesů. Procesy Životní cyklus vývoje v Kanbanu vychází z neustálého průtoku požadavků ze vstupu na výstup (označovaný jako Pipeline Delivery ), na rozdíl od Scrumu či XP tedy neomezuje dodávku softwaru žádnými iteracemi a svým charakterem odpovídá spíše metodice pro provoz a údržbu softwaru. Při úspěšné implementaci se proto podle (ŠOCHOVÁ, a další, 2014 str. 105) jen zřídka používá čistý Kanban, vždy jde o nějaké rozšíření Kanbanu či kombinaci s jinou agilní metodikou (viz např. kapitola 6.3.4). 28

33 Obrázek 10: Životní cyklus vývoje v Kanbanu (ContinuousAgile.com) Metodika Kanbanu rozeznává celkem 7 procesů pro získávání zpětné vazby a podporu kontinuálního zlepšování (REDDY, 2015 stránky 6-18): Plánování releasu / dodávky (Release / Delivery Planning) Denní schůzka (Team StandUp) probíhá formou diskuse nad postupem práce nad jednotlivými úkoly a identifikací úzkého hrdla (problému). Schůzka k doplnění / schválení požadavků (Replenishment / Commitment Meeting) Vyhodnocení dodávky služeb (Service Delivery Review) je zaměřená na diskusi mezi seniorním manažerem a zástupcem provozu o akceptačních kritériích a jejich dopadu na zákazníkem očekávané termíny dodávek jednotlivých funkcionalit. Současně poskytuje prostor k diskusi o mitigaci rizik a změnách v návrhu softwaru, doporučená frekvence je jednou týdně. Vyhodnocení provozu (Opeation Review) představuje systémový pohled na provozní statistiky výsledků práce vývojových týmů. Při měsíční frekvenci schůzek je dostatek času a údajů pro analýzu trendů a finančních dopadů. Vyhodnocení rizik (Risk Review) - doporučena je měsíční frekvence Vyhodnocení strategie (Strategy Review) probíhá kvartálně za účasti vedoucích pracovníků a zástupců útvarů strategického plánování, prodeje, marketingu, správy portfolia, řízení rizik, poskytování služeb a péče o zákazníky. Cílem schůzky je zhodnocení aktuální situace na trhu, strategické pozice organizace, úspěšnosti strategie go-to-market, ukazatelů výkonnosti (KPI) apod. 29

34 Praktiky Vizualizace procesu prostřednictvím Kanban nástěnky, umožňuje vizualizaci postupu práce a identifikaci úzkého hrdla (problému). Definice hotovo pro každý stav procesu pokud toto kritérium není naplněno, položka nemůže být přetažena do dalšího stavu procesu, Stanovení limitů max. počtu rozpracovaných úkolů (WIP) umožňuje odhalit malé problémy vývojového procesu a okamžitě je řešit. Řízení toku (Pull System) důsledné uplatňování principu tahu, kdy práci na novém úkolu je možné začít až poté, co se pro něj uvolní kapacita v rámci limitu rozpracovaných úkolů, zajišťuje plynulý tok práce a snazší identifikaci problémových oblastí. Vytvářet otevřené politiky Vytvořit mechanismy vyhodnocení / zpětné vazby na úrovni pracovního postupu, dodávky softwaru a na jednotlivých úrovních organizace. Zlepšit spolupráci pomocí modelových experimentů Role Na rozdíl od Scrumu nemá předepsané žádné role. Techniky JIT (Just-In-Time) umožňuje vyrábět pouze potřebné produkty v požadovaném množství v nezbytně nutném čase. Důsledná aplikace této techniky zajišťuje eliminaci všech druhů ztrát v průběhu celého vývojového procesu. Měření času průchodu (Cycle Time) Namísto měření rychlosti týmu využívá Kanban jako metriku dobu potřebná k dokončení úkolu měřená od okamžiku zahájení po dokončení práce na úkolu. Kumulativní diagramy toku (CFD) grafy zachycující počet rozpracovaných úkolů po jednotlivých krocích životního cyklu vývoje. Překrývání CFD a diagramů toku (Burn-Up Chart) je vizualizační technika pro sledování postupu práce v kontextu releasu nebo sprintu. Integrací těchto dvou grafů získává ScrumBan tým dodatečné informace, které mohou podstatně rozšířit jeho možnosti řízení dodávek funkcionalit a očekávání zákazníka (dodací lhůta jednotlivých funkcionalit, rychlost a efektivita dodávky, celková doba trvání dodávky). 30

35 Nastavení metrik pro ohodnocení kvality dodávky slouží např. ke sledování počtu funkcionalit dodaných ve snížené kvalitě, generování seznamu problémů a jejich dopadů, úspěšnosti releasů při dodávání plánovaných funkcionalit apod. Nastavení metrik pro ohodnocení rizik umožňuje rizika kvantifikovat a v čase sledovat stupeň jejich snížení a/nebo zamezení riziku. Další informaci poskytuje např. vizualizace potenciálních dopadů rizik v jednotlivých iteracích vývoje. Nástroje Kanban lístek obsahuje User Story a příp. další relevantní informace o požadavku Kanban nástěnka je nejpoužívanějším nástrojem Kanbanu, umožňuje vizualizaci postupu práce a identifikaci úzkého hrdla (problému). Produkty Release softwaru uvolnění publikace nové verze obsahující přidané a/nebo upravené funkcionality na základě požadavků zákazníka ScrumBan ScrumBan představuje kombinací obou nejpoužívanějších metodik, Scrumu a Kanbanu. Někteří autoři, jako např. (REDDY, 2015) označují ScrumBan spíše za proces přechodu mezi oběma metodikami než za metodiku vývoje. Implementace ScrumBanu může tedy vypadat např. jako plnohodnotný Scrum, uvnitř kterého se využívají techniky Kanbanu. Principy Z Kanbanu (REDDY, 2015 stránky 6-18) přebírá ScrumBan 4 principy či doporučené způsoby myšlení: s tím co děláš, začni ihned, respektuj současný proces, role, odpovědnosti a terminologii, nové příležitosti je možné objevit implementací vývoje formou malých inkrementálních evolučních změn, povzbuzuj jednání vedení na všech úrovních organizace. Procesy ScrumBan přejímá všech 7 procesů Kanbanu (viz kapitola 5.2.3) pro získávání zpětné vazby a podporu kontinuálního zlepšování (REDDY, 2015 stránky 6-18): 31

36 Obrázek 11: Životní cyklus vývoje ve ScrumBanu (ContinuousAgile.com) Plánování releasu / dodávky (Release / Delivery Planning) Denní schůzka (Team StandUp) Schůzka k doplnění / schválení požadavků (Replenishment / Commitment Meeting) Vyhodnocení dodávky služeb (Service Delivery Review) Vyhodnocení provozu (Opeation Review) Vyhodnocení rizik (Risk Review) Vyhodnocení strategie (Strategy Review) Praktiky Z Kanbanu (viz kapitola 5.2.3) přebírá pro svoje účely ScrumBan těchto 6 praktik formou obecných doporučení pro vytváření detailních praktik: Vizualizace procesu Nastavení limitů rozpracovaných úkolů (WIP) Řízení toku (Pull System) Vytvářet otevřené politiky Vytvořit mechanismy vyhodnocení / zpětné vazby Zlepšit spolupráci pomocí modelových experimentů Role ScrumBan nedefinuje žádné specifické role, jednotliví členové týmu zastávají ty role, které jim byly přiděleny. 32

37 Techniky Z Kanbanu (viz kapitola 5.2.3) přebírá pro svoje účely ScrumBan 2 techniky, a navíc definuje nové techniky určené pro práci s prioritizovaným zásobníkem požadavků: JIT (Just-In-Time) Měření času průchodu (Cycle Time) Třídění položek zásobníku je součástí prioritizace požadavků zásobníku v souvislosti připravovaným releasem. Do horní části zásobníku se po zmrazení přijímání práce na nových požadavcích přesouvají zpět všechny úkoly, které pravděpodobně nebudou dokončeny do vydání releasu. Zmrazení přijímání požadavků na nové funkcionality slouží ke stabilizaci releasu, funkcionality, které se nestihnou dokončit do vydání releasu jsou vráceny zpět do zásobníku a kapacita vývojového týmu je alokovaná na dokončení rozpracovaných úkolů. Nástroje Z Kanbanu (viz kapitola 5.2.3) přebírá pro svoje účely ScrumBan oba nástroje pro vizualizaci. Kanban lístek Kanban nástěnka Produkty Release softwaru uvolnění publikace nové verze obsahující přidané a/nebo upravené funkcionality na základě požadavků zákazníka Lean Software Development (LSD) Autorem metodiky Lean Software Development (LSD) je Robert Charette. Metodika původně pochází ze strojírenství a je aplikací principů známých jako Lean Manufacturing a Total Quality Management na vývoj softwaru. Vytvořila ji firma Toyota po 2. světové válce ve snaze v maximální míře uspokojit požadavky zákazníka vyráběním pouze požadované funkcionality (tzv. štíhlá výroba ). Principy (POPPENDIECK, a další, 2003) uvádí těchto 7 základních principů LSD: Odstraňte vše, co nepřináší hodnotu představuje odstranění všeho zbytečného, co v průběhu vývoje vzniká, nepřináší obchodní hodnotu, a co může snížit efektivitu a zvýšit 33

38 výrobní náklady. Současně se snaží rozpoznávat neefektivní procesy, odstraňovat zdroje plýtvání a snižovat plýtvání s ohledem na zachování kvality softwaru. Zlepšete se a učte se již v průběhu práce obdobně jako v Kanbanu (viz kapitola 5.2.3) je zdůrazněn proces učení se ze zkušeností a neustálé zlepšování procesů. Rozhodujte se co nejpozději rychlé rozhodování co možná nejpozději, kdy je k dispozici více informací pro kvalifikované rozhodnutí Dodávejte práci, jak nejrychleji to jde vývoj probíhá formou krátkých iterací s důrazem na zpětnou vazbu od zákazníka a zachování integrity produktu i vývojového procesu (důraz je kladen zejména na testování a refaktoring). Dejte týmu důvěru a zodpovědnost posílení odpovědnosti týmu zvyšuje jeho motivaci. Vytvářejte integritní software zajistí to jeho užitečnost v průběhu času. Integritní systém má koherentní architekturu, dosahuje vysokého stupně použitelnosti a vhodnosti pro daný účel, je udržovatelný, adaptabilní a rozšiřitelný. Zaměřte se na celkový výsledek jednotlivé chyby nejsou podstatné, pokud se z nich poučíme; důraz je kladen především na kvalitu a celkovou udržitelnost systému, neměl by být zvyšován technický dluh. Procesy Nejsou definovány žádné specifické procesy. Praktiky Nejsou definovány žádné specifické praktiky. Role LSD nedefinuje žádné specifické role, jednotliví členové týmu zastávají ty role, které jim byly přiděleny. Techniky Nejsou definovány žádné specifické techniky. Nástroje (POPPENDIECK, a další, 2003) uvádí těchto 22 nástrojů, které podporují Principy LSD: Naučte se rozlišovat odpad vše, co zákazníkovi nepřináší obchodní hodnotu, nebo existuje způsob, jak danou funkcionalitu dodat bez toho, je odpad. Pokud aplikujeme tento 34

39 přístup na Royceho definici, že "[zatímco] je zapotřebí dalších dodatečných vývojových kroků, žádný z nich nepřispívá přímo ke konečnému produktu jako analýza a kódování a všechny přispívají k vývojovým nákladům." (ROYCE, 1970 str. 1), lze všechny kroky vodopádového modelu, kromě analýzy a kódování, označit za odpad. Mapování hodnotového toku zachycuje průměrnou dobu nutnou pro dodání požadavku zákazníka od jeho zadání do nasazení funkcionality. Zpětná vazba slouží k validaci správnosti pochopení požadavků zákazníka vývojovým týmem, doporučena je např. tvorba prototypů již v počáteční fázi vývoje. Iterace obdobně jako v ostatních agilních metodikách představuje pevný krátký časový rámec, během kterého je dodáván užitečný přírůstek softwaru (inkrement). Synchronizace iterace jsou plánovány výběrem funkcí, které jsou pro zákazníky důležité, a pokud se vývoj rozděluje mezi více týmů, je nutné zajistit synchronizaci jejich práce. Ta je zásadní pro každý komplexní vývojový proces. Souběžný vývoj je založený na detailním řízení návrhu a závislostí; řešení je rozděleno mezi několik týmů, které pracují paralelně na detailu konkrétní funkcionality, a společně konvergují k řešení požadavku zákazníka. Zvažování alternativ předpokládá odkládání nevratných rozhodnutí do té doby, dokud není vyřešena nejistota. Poslední možný okamžik na jedné straně LSD povzbuzuje vývojáře, aby zahájili vývoj co nejdříve (tj. v době kdy jsou požadavky známy pouze částečně) a v krátkých iteracích získávali zpětnou vazbu od zákazníka, zásadní rozhodnutí o návrhu řešení však má tým odkládat do posledního možného okamžiku. Ten je definován jako okamžik, kdy odkládání rozhodnutí vylučuje významnou alternativu (POPPENDIECK, a další, 2003 str. 65) Rozhodování je založeno na několika strategiích řešení problémů: 1) postup od obecného ke konkrétnímu, 2) rozhodování na základě intuice, přizpůsobení návrhových vzorů a využívání zkušenosti týmu vývojářů, 3) využití dekompozice a detailní analýzy, pokud se protistrana není schopna rozhodovat na základě intuice, 4) předem nastavit soubor hodnot a jednoduchých pravidel pro řešení problémů. Systém tahu (Pull System) přebírá Principy vyrovnaného hodnotového toku z Kanbanu (viz kapitola 5.2.3) Teorie front je uplatněním matematických postupů pro řešení procesů čekání a obsluhy, že způsobem, jak zvýšit propustnost, je opakovaně hledat překážku, která zpomaluje průtok 35

40 a opravit ji, dokud se nezvýší využití oblastí, které nejsou zúžené. (POPPENDIECK, a další, 2003 str. 85) Cena zpoždění při rozhodování o přidání dalšího zdroje či nákupu nového nástroje by měly být založeny nejen na nákladech na pořízení nového aktiva, ale také nákladech na zpoždění dodávek. Sebeurčení při rychlém vývoji není čas na neustálé čekání na schválení nadřízenou autoritou, každý tým si proto může nastavit vlastní pracovní postupy a koordinovat nastavení standardů s ostatními týmy, které vykonávají obdobný typ práce. Motivace pozornost je věnována pracovnímu prostředí, jasné komunikaci cíle projektu a odstraňování organizačních překážek, což naplňuje tým závazkem za dodávané výsledky. Vedení předpokládá každodenní spolupráci vývojového týmu jak se zástupcem klienta, který má jasnou vizi produktu, tak s vedoucím vývojového týmu, který rozumí požadavkům zákazníka i navrhovanému řešení. Expertíza představuje požadavek na kontinuální rozvoj expertních znalostí všech členů vývojového týmu. Vnímání integrity představuje požadavek na řízení požadavků během celého vývojového procesu, řešení příp. problémů lze především úzkou spoluprací se zástupcem klienta, ustanovením vedoucího vývojového týmu, pro modelování využívat jazyk, který je srozumitelný oběma stranám, a řešení dodávat po malých inkrementech, které projdou validací ze strany koncových uživatelů. Konceptuální integrita znamená, že jednotlivé komponenty systému spolupracují a systém funguje jako celek. Architektura návrhu by proto měla zajišťovat rovnováhu mezi flexibilitou, udržovatelností, efektivitou a schopností systému reagovat na požadavky. Refaktoring přebírá Praktikyu průběžného refaktoring kódu z XP (viz kapitola 5.2.2) Testování z XP (viz kapitola 5.2.2) přebírá praktiku TDD, na základě výsledků testů je následně upravována dokumentace. Měření sledována je rychlost týmu, kvalita dodávek a čas průchodu, výsledky jsou prezentovány např. formou diagramů toku (Burn Charts). Smlouvy pro zohlednění jiného stylu práce nabízí LSD využít alternativní koncepty uzavírání smluv s dodavateli, zohledňující zejména tyto aspekty: 1) flexibilní rozsah dodávky, 2) sekvenční dodávku inkrementů systémů, 3) spravedlivé sdílení dopadů, pokud se skutečné náklady výrazně liší (v obou směrech) od původních odhadů projektu. 36

41 Produkty Inkrement užitečný přírůstek softwaru, který prošel celým životním cyklem vývoje. Je velmi podobný prototypu s tím rozdílem, že v tomto případě jde o funkční část konečného produktu. Tento přírůstek se v dalších iteracích vývoje může dále rozvíjet, ale představuje již funkční, otestovaný a integrovaný zdrojový kód. 5.3 Shrnutí kapitoly Metodiky vývoje softwaru lze v zásadě rozdělit na tzv. rigorózní těžké metodiky založené na vodopádovém modelu životního cyklu, které předpokládají, že všechny požadavky zákazníka je možné specifikovat předem. A na agilní lehké metodiky, založené na iterativním a inkrementálním vývoji umožňujícím rychlý vývoj softwaru a rychlou reakci na změnu požadavků zákazníka v průběhu celého životního cyklu vývoje. Tyto metodiky definují místo podrobných procesů spíše principy a praktiky. 37

42 6 Analýza možnosti využití agilního konceptu V této kapitole je uveden podrobnější rozbor možností využití konceptu agilního vývoje v bankovním prostředí v oblasti BI. Nejprve jsou uvedena specifika bankovního prostředí a dále specifika vývoje BI v bance. Na základě uvedených kritérií je následně zkoumána vazba mezi vybranými koncepty agilního vývoje a možností jejich aplikace na tuto oblast vývoje v bankovním prostředí. Vstupem pro analýzu je charakteristika vybraných agilních metodik vývoje (viz kapitola 5.2) a východiska pro identifikaci specifik vývoje BI řešení v bankovním prostředí (viz kapitola 3). 6.1 Specifika prostředí banky Bankovní prostředí bylo detailněji představeno v kapitole 3.1. Obecně lze říci, že se jedná o výrazně přísnější a regulovanější prostředí, které klade vysoké požadavky na zabezpečení bezpečnosti IT/ICT systémů, kvalifikovanost a profesionalitu zaměstnanců. Zákonné požadavky (Česká republika) a požadavky regulátora (ČNB) (Česká republika) tak nutně ovlivňují i požadavky kladené na metodiku vývoje (viz kapitola 3.1). Tabulka 6-1: Specifika prostředí banky a metriky jejich splnění ID NÁZEV KRITÉRIA POPIS KRITÉRIA METRIKA SPLNĚNÍ A-1 Oddělení neslučitelných funkcí (FLEISCHMANN, 2014 str. 39), (Česká republika str. 16) Vývoj informačních systémů je zajišťován odděleně od provozu těchto systémů Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje umožňující oddělení vývoje a provozu A-2 Rozvoj informačních systémů v souladu se strategií rozvoje (FLEISCHMANN, 2014 str. 39) Jsou stanoveny odpovědnosti za plnění strategie informačních systémů a se strategií jsou seznámeni příslušní pracovníci Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro zajištění vazby na strategické plánování 38

43 A-3 Zajištění bezpečnosti informačních systémů (Česká republika str. 150) Implementace bezpečnostních požadavků stanovených bezpečnostními zásadami a navazujícími předpisy Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro zajištění důvěrnosti, integrity a dostupnosti informací. A-4 Adekvátní testování změn (Česká republika str. 151) Zajištění testování změn systémů a řízení jejich uvolňování do provozu Jsou definovány principy, procesy, praktiky, techniky role a/nebo nástroje pro zajištění testování a řízení uvolňování změn do provozu A-5 Účast koncových uživatelů a subjektu odpovědného za bezpečnost IT/ICT (FLEISCHMANN, 2014 str. 39), (Česká republika str. 151) Dostatečná účast koncových uživatelů a subjektu zodpovědného za bezpečnost IT/ICT na vývoji a testování změn informačních systémů Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro zajištění dostatečné alokace zákazníka, příp. dalších zainteresovaných osob A-6 Zajištění kontroly externích dodavatelů (FLEISCHMANN, 2014 str. 39), (Česká republika str. 150) Zavedení postupů řízení a kontroly dodavatelů v případě dodavatelského způsobu vývoje (outsourcingu) Zdroj: autorka Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro řízení vývoje, zajištění kontroly kvality dodávek a reporting 39

44 Tabulka 6-1 popisuje specifické požadavky kladené na IT/ICT vývoj v prostředí banky včetně metrik jejich splnění, které budou zohledněny v analýze možnosti využití agilního vývoje (viz kapitola 6.3). 6.2 Specifika vývoje BI řešení Kapitola 3.2 se věnuje podrobnějšímu popisu oblasti BI a představuje hlavní architektonické přístupy k budování DWH. Možnosti využití agilních metodik pro vývoj datových skladů a BI řešení závisí na zvolené architektuře (viz kapitoly až 3.2.4) a charakteru požadavků zákazníka. Na rozdíl od frond-endových aplikací totiž BI řešení prochází přes několik odlišných architektonických vrstev (od extrakce zdrojových dat až po prezentační analytickou vrstvou), z nichž každá má svoje specifické požadavky a závislosti na kvalitě dat. (HUGHES, 2016 str. 86) uvádí hlavní problémové oblasti spojené s datovou integrací, které je nutné ošetřit při agilním vývoji DWH řešení. Tyto problémy jsou specifické pro oblast BI a byly proto převzaty jako kritéria adresace specifik vývoje BI řešení (viz kapitola 6.3). Tabulka 6-2: Specifika vývoje BI řešení a metriky jejich splnění ID NÁZEV KRITÉRIA POPIS KRITÉRIA METRIKA SPLNĚNÍ B-1 Rozsah datové integrace požadavků je příliš velký a dodávka řešení přesahuje stanovenou délku iterace (HUGHES, 2016 str. 86) Požadavky zákazníka na datovou integraci jsou příliš velké, aby je vývojáři stihli dokončit za 1-2 týdny Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro dekompozici požadavků zákazníka B-2 Absence specifických znalostí / dovedností snižuje rychlost týmu a plynulost hodnotového toku (HUGHES, 2016 str. 86) Řada dovedností / znalostí, které tým potřebuje, není dostatečně rozšířených, takže vývojáři nejsou sami schopni vyřešit všechny problémy, na které při vývoji řešení narazí Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro pokrytí všech oblastí vývoje BI řešení B-3 Ocenění pracnosti a stanovení termínů Před zahájením analýzy je náročné stanovit fixní termíny Jsou definovány principy, procesy, 40

45 dodání některých požadavků není možné bez analýzy datové kvality zdrojových dat (HUGHES, 2016 str. 86) dodání zákazníky požadovaných funkcionalit a celkovou cenu BI řešení praktiky, techniky, role a/nebo nástroje pro plánování a reporting B-4 Zajištění dostatečné alokace zákazníka (HUGHES, 2016 str. 86) Žádný zákazník nemá dostatečnou volnou kapacitu pro alokaci na projektech, aby se mohl stát skutečným partnerem vývojového týmu Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro zajištění participace zástupce zákazníka na vývoji řešení B-5 Náročnost datové integrace přes více architektonických vrstev s odlišnými požadavky a závislostí na datové kvalitě zdrojů (HUGHES, 2016 str. 86) Vývoj BI řešení vyžaduje podrobnější návrh, než umožňuje např. přidání plánovací iterace před zahájení vývojových prací Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro vytvoření návrhu BI řešení před zahájením vývoje B-6 Rozsah analýzy a návrhu řešení požadavků je příliš velký a přesahuje stanovenou délku iterace (HUGHES, 2016 str. 86) Analýza a návrh řešení jednotlivých požadavků může být pracnější (a tedy trvat déle) než 1 iterace Jsou definovány principy, procesy, praktiky, techniky, role a/nebo nástroje pro zajištění plynulé návaznosti analýzy, návrhu a vývoje BI řešení B-7 Multitasking snižuje plynulost hodnotového Vývojáři mají tendenci zahájit práci na více úkolech Jsou definovány principy, procesy, praktiky, techniky, 41

46 toku (HUGHES, 2016 str. 86) najednou, což ztěžuje pravidelnou analýzu závislostí Zdroj: autorka role a/nebo nástroje pro zajištění plynulého toku práce v průběhu celého životního cyklu vývoje Tabulka 6-2 popisuje hlavní specifika vývoje datových skladů a BI řešení včetně metrik jejich splnění, které budou zohledněny v analýze možnosti využití agilního vývoje (viz kapitola 6.3). 6.3 Analýza možnosti využití metodik agilního vývoje v oblasti BI v bankovnictví Cílem této kapitoly je vlastní analýza možnosti využití vybraných metodik agilního vývoje v oblasti BI v bankovnictví. Kapitoly 6.3.1, 6.3.2, 6.3.3, a obsahují vyhodnocení adresace specifik vývoje BI řešení (viz Tabulka 6-2) v oblasti bankovnictví (viz Tabulka 6-1) Analýza možnosti využití metodiky Scrum V odborné literatuře je Scrum jako metodika pro vývoj datových skladů a BI řešení často doporučován. Hughes popisuje využití Scrumu pro agilní vývoj BI řešení ve svých publikacích (HUGHES, 2013), (HUGHES, 2016) a (HUGHES, 2008), publikované výsledky BI projektů ve významných amerických telekomunikačních firmách z roku 2008 ukazují na cca % zrychlení vývoje při významném zlepšení datové kvality. Naplnění specifických požadavků pro vývoj BI řešení v bankovním prostředí popisuje Tabulka 6-3. Je možné konstatovat, že kromě požadavku na oddělení neslučitelných funkcí, který Scrum jako metodika vývoje neřeší a který lze ošetřit interními předpisy banky, adresuje metodika Scrum všechna definovaná specifika (viz kapitoly 6.1 a 6.2). Pro zajištění plynulého toku práce doporučuje navíc (HUGHES, 2016) zavedení specifických rolí pro BI vývojový tým (architekt projektu, datový modelář, systémový analytik, systémový tester a Proxy Product Owner), úpravu procesu důslednou aplikací Paretova pravidla 6 (80/20) 6 Paretovo pravidlo (80/20) říká, že 20 % příčin způsobuje 80 % výsledků. Pro plánování a řízení vývoje je tedy důležité soustředit se především na kritických 20 %, které způsobují 80 % možných efektů. 42

47 pro úroveň detailu specifikace požadavků, přidání technik (WIP) a procesů Kanbanu (Pipeline Delivery), změnu účelu -1. a 0. iterace, zavedení dvoukolového testování a automatizaci integračních testů. Tabulka 6-3: Scrum naplnění požadavků na agilní vývoj BI řešení v bankách ID NÁZEV KRITÉRIA SPLNĚNÍ METRIKY A-1 Oddělení neslučitelných funkcí NE Scrum je vývojová metodika, zajištění oddělení vývoje, provozu a bezpečnosti IS/ICT řeší interní předpisy banky A-2 Rozvoj informačních systémů v souladu se strategií rozvoje A-3 Zajištění bezpečnosti informačních systémů viz Procesy vyhodnocení sprintu a Role vlastníka produktu (kapitola 5.2.1) viz Techniky dekompozice User Stories (kapitola 5.2.1) A-4 Adekvátní testování změn viz Principy adaptace (kapitola 5.2.1) A-5 Účast koncových uživatelů a subjektu odpovědného za bezpečnost IT/ICT A-6 Zajištění kontroly externích dodavatelů B-1 Rozsah datové integrace požadavků je příliš velký a dodávka řešení přesahuje stanovenou délku iterace viz Procesy vyhodnocení sprintu a Role vlastníka produktu (kapitola 5.2.1) viz Procesy denní schůzka, retrospektiva sprintu a Techniky burn charty (kapitola 5.2.1) viz Techniky postupného plánování (kapitola 5.2.1) 43

48 B-2 Absence specifických znalostí / dovedností snižuje rychlost týmu a plynulost hodnotového toku B-3 Ocenění pracnosti a stanovení termínů dodání některých požadavků není možné bez analýzy datové kvality zdrojových dat B-4 Zajištění dostatečné alokace zákazníka B-5 Náročnost datové integrace přes více architektonických vrstev s odlišnými požadavky a závislostí na datové kvalitě zdrojů B-6 Rozsah analýzy a návrhu řešení požadavků je příliš velký a přesahuje stanovenou délku iterace B-7 Multitasking snižuje plynulost hodnotového toku viz Principy adaptace (kapitola 5.2.1) viz Techniky postupného plánování (kapitola 5.2.1) viz Principy adaptace (kapitola 5.2.1) viz Principy adaptace (kapitola 5.2.1) viz Techniky dekompozice User Stories (kapitola 5.2.1) viz Procesy retrospektiva sprintu (kapitola 5.2.1) Zdroj: autorka Obecně lze tedy konstatovat, že Scrum adresuje specifické požadavky na vývoj BI řešení v bankách, a je možné jej pro agilní vývoj využít Analýza možnosti využití metodiky Extrémní programování (XP) Možnosti agilního vývoje datového skladu a BI řešení s využitím metodiky XP popisuje v dostupné literatuře pouze (HUGHES, 2008). Mezi hlavní problémy úspěšné implementace 44

49 v oblasti BI řešení patří základní teze, že jediným nezpochybnitelným zdrojem informací je zdrojový kód. Datové sklady totiž investují nemalé prostředky do vytváření metadatové vrstvy, která slouží pro ukládání obchodních i technických (transformačních) pravidel a generování DDL. BI jsou naopak blízké související praktiky jako společné kód a kontinuální refaktoring (tj. čištění zdrojového kódu a odstraňování vzniklého technického dluhu). Naplnění specifických požadavků pro vývoj BI řešení v bankovním prostředí popisuje Tabulka 6-4. Je možné konstatovat, že kromě požadavku na oddělení neslučitelných funkcí, který XP jako metodika vývoje neřeší a který lze ošetřit interními předpisy banky, adresuje XP všechna definovaná specifika (viz kapitoly 6.1 a 6.2). Tabulka 6-4: XP naplnění požadavků na agilní vývoj BI řešení v bankách ID NÁZEV KRITÉRIA SPLNĚNÍ METRIKY A-1 Oddělení neslučitelných funkcí NE XP je vývojová metodika, zajištění oddělení vývoje, provozu a bezpečnosti IS/ICT řeší interní předpisy banky A-2 Rozvoj informačních systémů v souladu se strategií rozvoje A-3 Zajištění bezpečnosti informačních systémů viz Procesy plánování a dodávka a akceptace (kapitola 5.2.2) viz Procesy dekompozice User Stories (kapitola 5.2.2) A-4 Adekvátní testování změn viz Procesy testování (kapitola 5.2.2) A-5 Účast koncových uživatelů a subjektu odpovědného za bezpečnost IT/ICT viz Praktiky zákazník na pracovišti (kapitola 5.2.2) 45

50 A-6 Zajištění kontroly externích dodavatelů B-1 Rozsah datové integrace požadavků je příliš velký a dodávka řešení přesahuje stanovenou délku iterace B-2 Absence specifických znalostí / dovedností snižuje rychlost týmu a plynulost hodnotového toku B-3 Ocenění pracnosti a stanovení termínů dodání některých požadavků není možné bez analýzy datové kvality zdrojových dat B-4 Zajištění dostatečné alokace zákazníka B-5 Náročnost datové integrace přes více architektonických vrstev s odlišnými požadavky a závislostí na datové kvalitě zdrojů B-6 Rozsah analýzy a návrhu řešení požadavků je příliš velký a přesahuje stanovenou délku iterace viz Praktiky párové programování a Techniky review (kapitola 5.2.2) viz Procesy dekompozice User Stories (kapitola 5.2.2) viz Principy komunikace a Praktiky párové programování (kapitola 5.2.2) viz Procesy plánování a dodávka a akceptace (kapitola 5.2.2) viz Praktiky zákazník na pracovišti (kapitola 5.2.2) viz Praktiky průběžná integrace a Nástroje Spike Solutions (kapitola 5.2.2) viz Procesy dekompozice User Stories (kapitola 5.2.2) 46

51 B-7 Multitasking snižuje plynulost hodnotového toku viz Praktiky párové programování (kapitola 5.2.2) Zdroj: autorka Obecně lze konstatovat, že XP je vhodnou leč ne příliš často využívanou metodikou pro agilní vývoj BI řešení v bankách. Přesto je řada praktik XP (společné vlastnictví kódu, kontinuální refaktoring, dodržení jednoduchého a srozumitelného kódu) v BI využívána i v rámci vodopádového modelu životního cyklu. Pro zajištění plynulého toku práce doporučuje (HUGHES, 2016) stejně jako u Scrumu zavedení specifických rolí pro BI vývojový tým (architekt projektu, datový modelář, systémový analytik, systémový tester a Proxy Product Owner), úpravu procesu důslednou aplikací Paretova pravidla (80/20) pro úroveň detailu specifikace požadavků, přidání technik (WIP) a procesů Kanbanu (Pipeline Delivery), změnu účelu -1. a 0. iterace, zavedení dvoukolového testování a automatizaci integračních testů Analýza možnosti využití metodiky Kanban Využití Kanbanu pro agilní vývoj řešení v bankovním prostředí popisuje pouze (HEFNEROVÁ, 2015) ve své diplomové práci. Publikované závěry případové studie ukazují na vhodnost zavedení této metodiky pro zlepšení součinnosti vývojového týmu v bankovním prostředí. Jedná se o obecný koncept, který lze aplikovat i na oblast vývoje BI řešení. Naplnění specifických požadavků pro vývoj BI řešení v bankovním prostředí popisuje Tabulka 6-5. Je možné konstatovat, že kromě požadavku na oddělení neslučitelných funkcí, který Kanban neřeší a který lze ošetřit interními předpisy banky, adresuje metodika Kanban všechna definovaná specifika (viz kapitoly 6.1 a 6.2). Tabulka 6-5: Kanban naplnění požadavků na agilní vývoj BI řešení v bankách ID NÁZEV KRITÉRIA SPLNĚNÍ METRIKY A-1 Oddělení neslučitelných funkcí NE V Kanbanu nejsou definovány role, zajištění 47

52 oddělení vývoje, provozu a bezpečnosti IS/ICT řeší interní předpisy banky A-2 Rozvoj informačních systémů v souladu se strategií rozvoje A-3 Zajištění bezpečnosti informačních systémů viz Procesy plánování releasu/dodávky a vyhodnocení strategie (kapitola 5.2.3) viz Procesy plánování releasu / dodávky a vyhodnocení dodávky služeb (kapitola 5.2.3) A-4 Adekvátní testování změn viz Praktiky neustálé zlepšování a Techniky nastavení metrik pro ohodnocení kvality dodávky (kapitola 5.2.3) A-5 Účast koncových uživatelů a subjektu odpovědného za bezpečnost IT/ICT A-6 Zajištění kontroly externích dodavatelů B-1 Rozsah datové integrace požadavků je příliš velký a dodávka řešení přesahuje stanovenou délku iterace B-2 Absence specifických znalostí / dovedností snižuje rychlost týmu a plynulost hodnotového toku viz Procesy vyhodnocení dodávky služeb, vyhodnocení provozu a vyhodnocení rizik (kapitola 5.2.3) viz Procesy vyhodnocení dodávky služeb, vyhodnocení provozu a vyhodnocení rizik (kapitola 5.2.3) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.3) viz Principy omezování rozpracovaných úkolů a vyrovnaný hodnotový tok (kapitola 5.2.3) 48

53 B-3 Ocenění pracnosti a stanovení termínů dodání některých požadavků není možné bez analýzy datové kvality zdrojových dat B-4 Zajištění dostatečné alokace zákazníka B-5 Náročnost datové integrace přes více architektonických vrstev s odlišnými požadavky a závislostí na datové kvalitě zdrojů B-6 Rozsah analýzy a návrhu řešení požadavků je příliš velký a přesahuje stanovenou délku iterace B-7 Multitasking snižuje plynulost hodnotového toku viz Principy omezování rozpracovaných úkolů a vyrovnaný hodnotový tok (kapitola 5.2.3) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.3) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.3) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.3) viz Principy omezování rozpracovaných úkolů, vyrovnaný hodnotový tok a Techniky kumulativní diagramy toku a překrývání CFD a burn-up charterů (kapitola 5.2.3) Zdroj: autorka Obdobně jako v případě Scrumu, také Kanban specifické požadavky na vývoj BI řešení v bankách naplňuje. Pro zajištění plynulého toku práce doporučuje (HUGHES, 2016) obdobně jako u Scrumu zavedení specifických rolí pro BI vývojový tým (architekt projektu, datový modelář, systémový analytik, systémový tester a Proxy Product Owner), úpravu procesu 49

54 důslednou aplikací Paretova pravidla (80/20) pro úroveň detailu specifikace požadavků, přidání technik (WIP), zavedení dvoukolového testování a automatizaci integračních testů Analýza možnosti využití metodiky ScrumBan Detailnější popis metodiky ScrumBan poskytuje (REDDY, 2015), implementaci pro malé a střední firmy pak (CHEKHLOV, 2014) ve své diplomové práci. Možnost implementace pro agilní vývoj BI řešení v dostupné literatuře popsána není, nicméně vzhledem k charakteru metodiky (tj. implementaci plnohodnotného Scrumu, uvnitř kterého se využívají techniky Kanbanu) lze využít závěry uvedené v kapitolách 0 a Tabulka 6-6: ScrumBan naplnění požadavků na agilní vývoj BI řešení v bankách ID NÁZEV KRITÉRIA SPLNĚNÍ METRIKY A-1 Oddělení neslučitelných funkcí A-2 Rozvoj informačních systémů v souladu se strategií rozvoje A-3 Zajištění bezpečnosti informačních systémů NE ScrumBan nedefinuje žádné specifické role, zajištění oddělení vývoje, provozu a bezpečnosti IS/ICT řeší interní předpisy banky viz Procesy plánování releasu/dodávky a vyhodnocení strategie (kapitola 5.2.4) viz Procesy plánování releasu / dodávky a vyhodnocení dodávky služeb (kapitola 5.2.4) A-4 Adekvátní testování změn viz Praktiky neustálé zlepšování a Techniky nastavení metrik pro ohodnocení kvality dodávky (kapitola 5.2.4) A-5 Účast koncových uživatelů a subjektu odpovědného za bezpečnost IT/ICT viz Procesy vyhodnocení dodávky služeb, 50

55 vyhodnocení provozu a vyhodnocení rizik (kapitola 5.2.4) A-6 Zajištění kontroly externích dodavatelů B-1 Rozsah datové integrace požadavků je příliš velký a dodávka řešení přesahuje stanovenou délku iterace B-2 Absence specifických znalostí / dovedností snižuje rychlost týmu a plynulost hodnotového toku B-3 Ocenění pracnosti a stanovení termínů dodání některých požadavků není možné bez analýzy datové kvality zdrojových dat B-4 Zajištění dostatečné alokace zákazníka B-5 Náročnost datové integrace přes více architektonických vrstev s odlišnými požadavky a závislostí na datové kvalitě zdrojů viz Procesy vyhodnocení dodávky služeb, vyhodnocení provozu a vyhodnocení rizik (kapitola 5.2.4) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.4) viz Principy omezování rozpracovaných úkolů a vyrovnaný hodnotový tok (kapitola 5.2.4) viz Principy omezování rozpracovaných úkolů a vyrovnaný hodnotový tok (kapitola 5.2.4) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.4) viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.4) 51

56 B-6 Rozsah analýzy a návrhu řešení požadavků je příliš velký a přesahuje stanovenou délku iterace B-7 Multitasking snižuje plynulost hodnotového toku viz Procesy plánování releasu / dodávky a schůzka k doplnění / schvalování požadavků (kapitola 5.2.4) viz Principy omezování rozpracovaných úkolů, vyrovnaný hodnotový tok a Techniky kumulativní diagramy toku a překrývání CFD a burn-up charterů (kapitola 5.2.4) Zdroj: autorka Obecně lze konstatovat, že Scrum, Kanban i kombinovaná metodika ScrumBan jsou vhodné pro agilní vývoj BI řešení v bankách Analýza možnosti využití metodiky Lean Software Development (LSD) Principy a nástroje využívané LSD popisuje (POPPENDIECK, a další, 2003), vazbu mezi Kanbanem a LSD objasňuje (REDDY, 2015) formou případových studií. Stručný úvod do aplikace LSD v oblasti Business Intelligence pak poskytuje (DINE, 2009). Tabulka 6-7: LSD naplnění požadavků na agilní vývoj BI řešení v bankách ID NÁZEV KRITÉRIA SPLNĚNÍ METRIKY A-1 Oddělení neslučitelných funkcí A-2 Rozvoj informačních systémů v souladu se strategií rozvoje NE LSD nedefinuje žádné specifické principy ani nástroje, zajištění oddělení vývoje, provozu a bezpečnosti IS/ICT řeší interní předpisy banky viz Principy vytvářejte integritní software, Nástroje vnímání integrity (kapitola 5.2.5) 52

57 A-3 Zajištění bezpečnosti informačních systémů viz Principy vytvářejte integritní software, Nástroje vnímání integrity (kapitola 5.2.5) A-4 Adekvátní testování změn viz Principy zlepšete se a učte se již v průběhu práce, Nástroje testování (kapitola 5.2.5) A-5 Účast koncových uživatelů a subjektu odpovědného za bezpečnost IT/ICT A-6 Zajištění kontroly externích dodavatelů B-1 Rozsah datové integrace požadavků je příliš velký a dodávka řešení přesahuje stanovenou délku iterace B-2 Absence specifických znalostí / dovedností snižuje rychlost týmu a plynulost hodnotového toku B-3 Ocenění pracnosti a stanovení termínů dodání některých požadavků není možné bez analýzy datové kvality zdrojových dat viz Principy zlepšete se a učte se již v průběhu práce, Nástroje zpětná vazba (kapitola 5.2.5) viz Principy zaměřte se na celkový výsledek, Nástroje měření a smlouvy (kapitola 5.2.5) viz Principy zlepšete se a učte se již v průběhu práce, Nástroje souběžný vývoj a synchronizace (kapitola 5.2.5) viz Principy dejte týmu důvěru a zodpovědnost, Nástroje expertíza (kapitola 5.2.5) viz Principy rozhodujte se co nejpozději, Nástroje poslední možný okamžik (kapitola 5.2.5) 53

58 B-4 Zajištění dostatečné alokace zákazníka B-5 Náročnost datové integrace přes více architektonických vrstev s odlišnými požadavky a závislostí na datové kvalitě zdrojů B-6 Rozsah analýzy a návrhu řešení požadavků je příliš velký a přesahuje stanovenou délku iterace B-7 Multitasking snižuje plynulost hodnotového toku viz Principy dejte týmu důvěru a zodpovědnost, Nástroje vedení (kapitola 5.2.5) viz Principy vytvářejte integritní software, Nástroje vnímání integrity a konceptuální integrita (kapitola 5.2.5) viz Principy zlepšete se a učte se již v průběhu práce, Nástroje souběžný vývoj a synchronizace (kapitola 5.2.5) viz Principy zlepšete se a učte se již v průběhu práce, Nástroje souběžný vývoj a teorie front (kapitola 5.2.5) Zdroj: autorka Obecně lze konstatovat, že LSD je pro řízení agilního vývoj BI řešení v bankách méně vhodný než ostatní porovnávané metodiky. Kromě základních principů a nástrojů nejsou definovány žádné další součásti metodiky, o ty není rozšířen ani návrh Lean BI metodiky (DINE, 2009). Nicméně řada používaných nástrojů (mapování hodnotového toku, zpětná vazba, iterace, systém tahu teorie front, refaktoring, testování) je společná i s ostatními metodikami agilního vývoje. 6.4 Shrnutí kapitoly Na základě výsledků analýzy lze říci, že všechny vybrané metodiky agilního vývoje je možné využít pro agilní vývoj BI řešení v bankovnictví s výhradou týkající se nutného ošetření oddělení vývoje, provozu a bezpečnosti IS/ICT interními předpisy banky. 54

59 Tabulka 6-8: Souhrnný přehled naplnění požadavků agilními metodikami ID Scrum XP Kanban ScrumBan LSD A-1 A-2 A-3 A-4 A-5 A-6 B-1 B-2 B-3 B-4 B-5 B-6 B-7 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Zdroj: autorka Pro zlepšení adresace specifik BI vývoje a zajištění plynulého toku práce doporučuje (HUGHES, 2016) zavedení specifických rolí pro BI vývojový tým (architekt projektu, datový modelář, systémový analytik, systémový tester a Proxy Product Owner), úpravu procesu důslednou aplikací Paretova pravidla (80/20) pro úroveň detailu specifikace požadavků, přidání technik (WIP), zavedení dvoukolového testování a automatizaci integračních testů. 55

60 7 Návrh metodiky pro zavedení agilního vývoje Cílem kapitoly je návrh metodiky zavedení agilního vývoje v oblasti BI v bankovnictví. Tato problematika není dosud v odborné literatuře dostatečně popsána. Mezi hlavní informační prameny patří (COHN, 2010), (HUGHES, 2013) a (HUGHES, 2016), popis vybraných metodik (viz kapitola 5.2), kritéria adresace specifik agilního vývoje BI řešení v bankovnictví (viz kapitoly 6.1 a 6.2) a výstupy analýzy možnosti využití agilního vývoje (viz kapitola 6.3). S ohledem na stanovený rozsah bakalářské práce není součástí této práce ověření správnosti návrhu metodiky, např. formou případové studie. 7.1 Předpoklady a omezení zavedení agilní metodiky Úspěšné zavedení agilní metodiky vývoje umožňuje bankám dostát neustále se zvyšujícím nárokům na rychlost dodávek a na vytvoření kultury, která se bude schopna rychle přizpůsobit neustále se měnícím podmínkám. Přechod organizace z tradičního přístupu k agilnímu vývoji však není jednoduchý. Nejde totiž jen o formální změnu, ale o změnu myšlení, kultury, procesů a často i změnu organizační struktury. Obecně platí, že tento přechod je procesem min. na 5-7 let. To je zčásti způsobeno tím, že organizace potřebuje čas pro adaptaci svých procesů na agilní metodiku vývoje. Přestože neexistují přesná pravidla pro rozhodování, zda daná organizace je již připravena k přechodu na agilní vývoj, z určitých signálů lze tuto připravenost dovodit: 1.) Vedoucí pracovníci cítí potřebu změny Úspěšná implementace metodiky agilního vývoje bude mít významný vliv na nastavené procesy a organizaci provozu IS/ICT. Pravděpodobně se také změní systém měření výkonnosti a odměňování vývojového týmu, včetně změny procesů a kultury organizace. 2.) Zákazníci volají po zkrácení času řešení svých požadavků Výsledky přechodu na agilní vývoje jsou také patrné ve zkrácení času vývoje, zaměření se na skutečně přínosné aktivity, zrychlení odstranění chyb a zvýšení kvality BI dodávek. 3.) Vývojové týmy hledají cestu ke zvýšení úspěšnosti projektů Celkovým zjednodušením vykonávaných činností, jasně vymezenou prací a systematickým zlepšováním nastavených procesů umožňuje agilní vývoj efektivnější využívání nákladů. Největším přínosem je prohloubení vzájemné důvěry a intenzivní spolupráce se zákazníky, inkrementální vývoj a častá zpětná vazba umožňuje včas odvracet a korigovat problémy. 56

61 Agilní vývoj by měl být vždy zaváděn jako veřejně oznámený přechod a řízen formou projektu či programu. Aby byl vůbec možný, je však nezbytně nutná vysoká úroveň podpory ze strany vrcholového vedení a výkonného managementu organizace. Bez oficiální podpory managementu, finančních prostředků a schválení (vývojáři absolvují školení, zpomalí se tempo vývoje) nelze metodiku agilního vývoje zavést. Také proto řadí podporu managementu (Executive Management Support) Standish Group na 1. místo mezi faktory úspěchu projektů (Standish Group, 2013 str. 4). Tuto skutečnost zdůrazňuje také to, že angažovanost uživatelů (User Involvement) a jasné obchodní cíle (Clear Business Objectives) jsou ve všech průzkumech od roku 2012 uváděny jako méně závažné faktory úspěchu. (COHN, 2010 str. 43) uvádí 2 typy zavádění změny, a to buď pomocí "shora-dolů", anebo "zdola-nahoru" přístupu. Nejrychlejší změnu představuje přístup shora-dolů (Go-All-In), jedná se zpravidla o strategické rozhodnutí vrcholového managementu. Typická jsou jednorázová školení výkonného managementu a vývojového týmu, často s využitím služeb konzultačních firem. Tento přístup předchází problémům spojeným s paralelním fungováním agilních a tradičních týmů, může také zamezit odporu těch, kdo mají zájem na zachování statusu quo. Levnějším, méně stresujícím a rizikovým přístupem ke změně je naopak postup zdolanahoru (Start Small). Při vhodném výběru pilotních projektů a strategii změny nevyžaduje náhlou reorganizaci a zajišťuje dřívější dosahování úspěchů, které lze využít k další propagaci agilního vývoje v rámci organizace. S ohledem na výsledky analýzy adresace specifik agilního vývoje BI řešení v bankách a výše uvedenou charakteristiku obou přístupů využívá navrhovaná metodika zavádění agilního vývoje přístup zdola-nahoru (Start Small). 7.2 Metodika zavedení agilního vývoje v oblasti BI v bankovnictví V této podkapitole je uveden návrh metodiky zavedení agilního vývoje ve struktuře kopírující popis agilních metodik vývoje v kapitole Principy Všechny aktivity související s přechodem organizace na agilní metodiku vývoje by měly být prováděny formou projektu a/nebo programu. Podle (KALLMAN, a další, 2014 str. 233) by každý jednotlivý projekt a/nebo program měl být spojen s celkovou vizí organizace (na úrovni portfolia) a alespoň jednou z klíčových strategií (na úrovni programu) viz Obrázek

62 Obrázek 12: Vazba mezi projekty / programy, strategií a vizí organizace (KALLMAN, a další, 2014 str. 233) Hlavní principy metodiky lze rozdělit do 3 základních oblastí: Zaměřte se na intenzivní spolupráci se zákazníkem Největším přínosem agilního vývoje je prohloubení komunikace a vzájemné důvěry se zákazníkem. Agilní metodika vývoje umožňuje zaměřit se na činnosti, které vytvářejí nejvyšší hodnotu pro zákazníka, zrychlení procesu vývoje a zároveň rychlou reakci na změnu požadavků v průběhu celého životního cyklu. Poskytujte vedení průběžné zdůvodnění projektu Každý projekt musí mít jasné zdůvodnění svého smyslu (Business Case) a to po celou dobu životního cyklu projektu. U agilního vývoje je možné návratnost investice sledovat po jednotlivých iteracích nebo krocích postupného zavádění agilní metodiky vývoje, např. formou diagramu toku dodávané obchodní hodnoty pro zákazníka. Nezapomínejte na kontinuální zlepšování procesu agilního vývoje Při plánovaní a řízení projektu je nutné využívat zkušenosti z jednotlivých iterací. Hughesova agilní metodika vývoje DWH (HUGHES, 2016) se skládá z několika kroků, z nichž každý postupně zavádí jednotlivé principy, procesy, praktiky, techniky a nástroje, adresující specifika agilního vývoje BI řešení (viz kapitola 6.2). Současně je nutné tyto zkušenosti průběžně zaznamenávat, učit se z nich a předávat je dál. 58

63 7.2.2 Procesy Před zahájením projektu změny je nutné nejprve provést 3 aktivity, které jsou důležité pro úspěšnou implementaci metodiky vývoje: 1) volba strategie přechodu, 2) ověření konceptu na pilotním projektu/programu, 3) postupné rozšiřování metodiky agilního vývoje. 1) Volba strategie přechodu Představuje naplánování aktivit přechodu s ohledem na specifika dané organizace. Projekt musí zajistit zahájení a řízení těchto úkolů: o Analýza požadavků na změny Cílem této analýzy je pochopení informačních potřeb managementu v závislosti na procesech rozhodování. Součástí analýzy je také struktura a frekvence požadavků zákazníků na BI řešení. Na rozdíl od většiny IT projektů je totiž vysoký počet požadovaných změn kladným signálem, dokazuje správné zaměření DWH a užitečnost poskytovaných BI služeb pro zákazníky. o Analýza expertních znalostí týmu Zmapování expertních znalostí týmu poskytuje úplný soupis dostupných zdrojů včetně identifikace klíčových zdrojů. Jedním ze specifik vývoje BI řešení je totiž to, že řada potřebných dovedností a technologických znalostí není dostatečně rozšířených. Výsledky poskytují vodítko pro správné nastavení rolí a zajištění podpory pro rozvoj multifunkčnosti vývojového týmu. o Předběžný návrh procesu vývoje a předávky do provozu Existují diskuse ohledně aplikovatelnosti a vhodnosti agilního vývoje ve velkých organizacích. Jasné oddělení vývoje a provozu je jedním z regulatorních požadavků, které neadresuje žádná z agilních metodik, proto je nutné předem navrhnout, prodiskutovat a schválit koncept procesu vývoje a provozu BI řešení, příp. zajistit jejich ošetření interními předpisy banky. 2) Ověření konceptu na pilotním projektu / programu Zavádění agilního vývoje by mělo začít pilotním projektem. Pro jeho správný výběr je vhodné provést SWOT analýzu (viz Tabulka 7-1) zohledňující tato 2 kritéria: o Akceptovatelný stupeň rizika zahrnuje jak obtížnost řešené problematiky, tak politickou citlivost řešené oblasti. o Šance na úspěch klade důraz na obchodní hodnotu řešení, nevhodný je např. prototyp řešení, jehož akceptaci lze ze strany zákazníka odmítnout. 59

64 MÍRA RIZIKA 3) Postupné rozšiřování agilního vývoje Po nasazení a stabilizaci pilotního projektu je možné postupně pokračovat dalšími projekty s využitím Praktiky pro rozšiřování agilního vývoje (viz kapitola 7.2.3) dokud nejsou pokryty všechny projekty/programy v portfoliu. Dalším krokem maturity agilních procesů je koordinace práce mezi více agilními týmy (např. Scrum-of-Scrums) a agilní řízení projektového portfolia (např. SAFe ). Tabulka 7-1: SWOT analýza pro výběr vhodného pilotního projektu NEVHODNÝ PROJEKT vysoká rizika nízká šance úspěchu KANDIDÁT KANDIDÁT vysoká rizika velká šance na úspěch IDEÁLNÍ PROJEKT nízká rizika nízká šance úspěchu 60 nízká rizika velká šance na úspěch PRAVDĚPODOBNOST ÚSPĚCHU Zdroj: autorka Vlastní proces přechodu BI vývojového týmu na agilní metodiku vývoje DWH, kterou popisuje (HUGHES, 2016), lze rozdělit do 7 kroků s 15 až 28 iteracemi a max. délkou trvání 60 týdnů (HUGHES, 2013 str. 304). Celkový počet iterací a časová náročnost závisí na velikosti vývojového týmu a požadované rychlosti přechodu. S ohledem na specifika agilního vývoje BI řešení v bankovnictví (viz kapitola 6.1 a 6.2) se jedná nejprve o přijetí zvolené metodiky agilního vývoje ((HUGHES, 2013) preferuje Scrum) a následně postupné přejímání jednotlivých principů, procesů, praktik, technik a nástrojů, převzatých z metodik Scrum (viz kapitola 5.2.1), Kanban (viz kapitola 5.2.3) a Extrémní programování (XP) (viz kapitola 5.2.2) 1.) Scrum: timeboxing a relativní odhadování pracnosti Snadným a rychlým způsobem přechodu je zavedení 2-3týdenních iterací pro dodávky řešení a přechod na relativní odhady pracnosti (Story Points). 2.) Kanban: neustálý tok požadavků ze vstupu na výstup Zavedení průběžného zpracování požadavků (Pipeline Delivery) pro jednotlivé kroky životního cyklu vývoje BI řešení adresuje jedno ze specifik BI, že Dokonce i pro jednotlivé User Stories může být analýza a návrh řešení pracnější (a tedy trvat déle) než 1 iterace. (Tabulka 6-2, ID B-6)

65 Obrázek 13: Proces průběžného zpracování BI požadavků (HUGHES, 2013 str. 275) 3.) Extrémní programování (XP): technické úkoly (Developer Stories) a odhady celkové pracnosti Při obecném zadání požadavků (formou User Stories) je vzhledem ke komplexitě BI řešení obtížné stanovit fixní termíny dodání zákazníky požadovaných funkcionalit a celkovou cenu BI řešení. (Tabulka 6-2, ID B-3). Řešením je buď věnovat -1. iteraci před zahájením plánování (0. iterace) nacenění všech aktuálně známých požadavků., toto období je označováno jako počáteční fáze (HUGHES, 2013 str. 276). Nebo zavést dvoukolový proces pro validaci specifikace zadání formou prototypů. 4.) Extrémní programování (XP): správa dat pro vývoj a testy řízený vývoj (TDD) Pro zajištění dodržení termínů je nutné předem zavést akceptační kritéria a klasifikaci chyb. Obecně lze říci, že málo závažné chyby lze akceptovat v následující iteraci formou technologického dluhu (viz Praktiky XP, kapitola 5.2.2), středně závažné chyby vyžadující úpravu datové struktury a/nebo mapování je vhodné vrátit do zásobníku požadavků a upravené řešení dodat se zpožděním cca 2 iterací. Chyby závažné, kdy je nutná změna konceptuálního návrhu nebo nový datový zdroj, je doporučeno vrátit do kroku analýzy a návrhu řešení, dodávka řešení se v tomto případě opozdí o cca 3 iterace (viz Obrázek 14). 5.) Extrémní programování (XP): automatizované a kontinuální integrační testy Představují jeden z nejvýznamnějších kroků transformace. Podmínkou nutnou nikoliv však postačující je zavedení testy řízeného vývoje (viz Praktiky, kapitola 5.2.2) pro jednotkové testy, dále by každá iterace měla projít integračními a regresními testy. 61