Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Diplomová práce Vývoj a provoz sociální sítě Agilní business analýza Bc. Štefan Pinďák Vedoucí práce: Ing. Jiří Chludil 9. května 2014

4

5 Poděkování Chtěl bych poděkovat vedoucímu práce Ing. Jiřímu Chludilovi za čas věnovaný konzultacím a cenné rady při psaní této práce. Velké díky patří Bc. Andree Batelkové a mému bratru Jiřímu Pinďákovi za korekturu textu práce. Největší poděkování pak náleží mým kolegům Bc. Martinu Humeníkovi a Bc. Lukáši Jeschke za společnou práci na tomto diplomovém projektu.

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 9. května

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Štefan Pinďák. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Pinďák, Štefan. Vývoj a provoz sociální sítě Agilní business analýza. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

9 Abstrakt Cílem práce je popsat, jak se agilní business analýza vytváří, jak ji udržovat za běhu projektu aktuální a kohezní. Pro dosažení tohoto cíle bylo použito skutečného projektu Redesign sociální sítě pro firmu S.I.C. spol. s.r.o. Agilní business analýza přináší jednoduchý přístup k zákazníkovým cílům a potřebám. Na rozdíl od tradiční analýzy je v duchu agilních metodik připravena pružně reagovat na změnu. V rámci práce byl v kooperaci se zadavatelem analyzován cílový produkt software a bylo vytvořeno několik analytických dokumentů. Vznikl dokument Vision Board popisující vizi a kontext projektu. Pro analýzu cílové skupiny uživatelů a zainteresovaných stran (stakeholderů) produktu byla použita technika Person a jako výstup vznikl dokument Persony. K analýze funkčních a nefunkčních požadavků byla použita metoda User Story. User stories byly souhrnně zpracovány v dokumentu Product Backlog popisující požadavky na software a stanovující rozsah projektu. Práce popisuje tvorbu výše zmíněných dokumentů, poukazuje na problémy a dává doporučení pro tvorbu agilní analýzy a práci s ní v rámci projektu. Součástí práce je také srovnání předností a slabin agilní analýzy proti analýze tradičními metodami. Klíčová slova Agilní metody, Business analýza ix

10 Abstract The goal of this thesis is to describe the agile business analysis creation process with focus on keeping the analysis documentation actual and cohesive. The agile business analysis process will be examined in the project of the Social network redesign for company S.I.C., Ltd. The agile business analysis brings easy approach to customers goals and needs in comparison to traditional methods. The agile business analysis is ready to respond to the customer need for change as well as the agile methodology itself. Several documents analysing target product software have been created during the project: Vision Board, Personas and Product Backlog. The Vision Board describes the project vision and its context. The Personas technique has been used to analyse users and stakeholders. The document Personas has been created as the result. The User Story method has been used to analyse functional and nonfunctional product requirements. User stories have been documented in the Product Backlog. Gathering all the requirements Product Backlog states the project scope. The thesis describes creation of these documents. It points out problems raised and suggests how to do agile business analysis in a project. The thesis summaries agile business analysis advantages and disadvantages in comparison to the traditional business analysis methods. Keywords Agile methods, Business analysis x

11 Obsah Úvod 1 Agilní business analýza Webové seznamovací portály jako sociální sítě Líbímseti.cz Popis, konkretizace cíle Rozbor zadání Co není součástí práce Rozdělení odpovědnosti na projektu Analýza a návrh O business analýze Návrh zpracování business analýzy As Is analýza Realizace Jak probíhal projekt Zhodnocení business analýzy Jak udržovat artefakty aktuální Závěr 75 Přínos práce Co mi práce dala Splnění zadání práce Literatura 79 A Seznam použitých zkratek 87 B Obsah přiloženého CD 89 xi

12

13 Seznam obrázků 1.1 Rozdělení odpovědnosti na projektu Waterfall model Scrum model Agilní vs Waterfall trojimperativ Zvolená struktura Vision Board Formát persony Ukázka persony Finální Vision Board Výsledná verze primární persony Výsledná podoba Person Wireframe Seznámení Vision Board verze Vision Board verze Vision Board verze Vision Board verze Vision Board verze Persony verze Persony verze Persony verze Persony verze xiii

14

15 Seznam tabulek 2.1 Řízení rozsahu na tradičním a agilním projektu xv

16

17 Úvod Tato část práce popisuje důvody pro tvorbu této závěrečné práce. Popisuje vnitřní a vnější podněty, které vedly k volbě daného tématu práce, podává základní informace o projektu, v jehož rámci byla práce vypracovávána, a uvádí čtenáře do širšího kontextu celé problematiky. Agilní business analýza Kvalitní business analýza je klíčová pro běh projektu. Jak říká guru business analýzy Karl E. Weigers: And remember that without high quality requirements, software is like a box of chocolates: you never know what you re going to get. [1] ( Pamatuj, že bez kvalitních požadavků je software jako bonboniéra: nikdy nevíš, co ochutnáš. ) Více, než třetina problémů na projektech jsou spojeny se špatně provedenou analýzou a vleklými požadavky[2]. Špatná analýza znesnadňuje návrh, implementaci, testování i další aktivity na projektu. Přesto je tomuto tématu věnována jen malá část výuky na naší fakultě. O toto téma se již dlouhodobě zajímám a tak bych jej rád přiblížil prostřednictvím této práce a získal další cenné a praktické zkušenosti. V tradičních metodách jsou vytvářeny rozsáhlé dokumenty business analýzy. Někdy těchto dokumentů může být opravdu hodně[3], to ale nemusí být pravidlem. Často analytik pracuje nezávisle na vývojářích či dokonce business analýzu a implementaci vytváří jiné týmy či firmy. Kvůli tomu bylo potřebné vytvoření důkladné (a rozsáhlé) dokumentace v počáteční fázi před zahájením návrhu a implementace. Tomuto předávání velké dokumentace mnozí říkají throwing papers over the wall[4] symbolizující oddělenost jednotlivých týmů stejně, jako oddělení ve velkých firmách. Agilní business analýza se z velké části zpracovává také v počáteční fázi projektu. Avšak je připravena, stejně jako agilní metodiky celkově, na změnu, jak se mění zákazníkovi potřeby a upřesňují se jednotlivé požadavky. Díky 1

18 Úvod iterativnímu přístupu není třeba specifikovat celý produkt dopředu, ale mít upřesněny jen ty části, které se budou vyvíjet v další iteraci. Agilní analýza vychází z předpokladu, že důležité věci jsou zjevné na začátku, anebo se časem samy přihlásí o slovo. Důležité požadavky zákazník zmíní i několikrát za sebou. Analýzy se účastní také členové týmu[5] a tak dochází k lepšímu porozumění mezi oběma stranami a lepším výsledkům vývojáři chápou postoj zákazníka a nevidí analýzu a požadavky poprvé. Agilní analýza vsází na jednoduchost. Zákazník ani tým nemá problém se čtením sáhodlouhé dokumentace, a tak je dosaženo vzájemného pochopení. Cílem této práce je přiblížit proces business analýzy jako takové a její důležitost. Především agilní business analýzu a ukázat její přínosy, výhody a nevýhody a porovnat tento přístup s tradičními metodami v kontextu skutečného projektu. Tradičními metodami jsem se zabýval v mé bakalářské práci[6], kde byla analýza vytvářena také na reálném projektu. Díky tomu budu moci v této práci poskytnout relevantní srovnání. Webové seznamovací portály jako sociální sítě Tato práce se bude zabývat webovými seznamovacími portály (dále jen seznamkami), jakožto jedněmi z nejstarších[7] a nejrozšířenějších sociálních sítí[8]. Konkrétně webovým seznamovacím portálem Líbímseti.cz, pro jehož redesign bude v rámci této práce vytvářena business analýza. Člověk je tvor společenský a tak potřebuje mít kolem sebe společnost dalších lidí, nejlépe svého partnera. Hledání životního partnera se tak stává pro mnohé těžkým úkolem plným zklamání. Zejména pro ty, kteří nemají tolik štěstí, vznikly právě seznamky. Internetové sociální sítě, určené k poznávání dalších lidí s hlavním cílem pomoci uživatelům najít si svůj protějšek člověka, s kterým budou moci strávit zbytek života a prožít spolu dobré i zlé. Tak už v počátcích internetu tyto služby našly své místo na webových stránkách[7]. Dlouhá léta popularita seznamek výrazně rostla a jejich účel se rozšířil nejen na hledání partnera, ale i hledání přátel a k zábavě. Po nástupu Facebooku a dalších sociálních sítí zaměřených na sdílení informací(twitter, Instagram apod.) počet uživatelů některých seznamek, zejména těch, které byly využívány pro komunikaci s přáteli, k diskusím či zábavě (hraní her) opadl. Již nebyl důvod komunikovat s přáteli na seznamce, když k tomu sloužil Facebook, který byl pro to daleko lépe uzpůsoben. Facebook přišel brzy i s dalšími možnostmi zábavy (hry atd.), a tak již spousta uživatelů neměla důvod tuto stránku opouštět kvůli své staré seznamce. Ač by se zdálo, že s příchodem Facebooku a dalších velkých sociálních sítí seznamky upadnou v zapomnění a možná i zaniknou, opak je pravdou[8]. Počet uživatelů seznamek v roce 2008 v USA byl tři miliony, v roce 2013 již 2

19 Líbímseti.cz 10% populace, počet uživatelů sociálních sítí naproti tomu 60%[9]. Čím více je doba uspěchaná a svět virtuální, tím více roste počet lidí, kteří se seznamují online. Počet uživatelů seznamek stoupá a nic nenasvědčuje tomu, že by se tento trend měl změnit. Více a více lidí tak nachází svého životního partnera právě přes seznamky[10]. Jedním z přínosů této práce je tak šťastnější život lidí, kteří si díky výstupům této práce snáze najdou svého vysněného partnera. Líbímseti.cz Webový seznamovací portál Líbímseti.cz[11] (dále jen Líbímseti), uživateli často označován Líbko byl a stále je jedna z největších seznamek u nás. V roce 2002 jej založil Oldřich Neuberger[12]. Postupem času se původně seznamka začala rozšiřovat v sociální síť přibývaly další funkcionality (chat, diskuse, místnosti), které posouvaly původní účel dále k širšímu spektru uživatelů. V roce 2008 na vrcholu své slávy mělo Líbímseti již uživatelů[13]. V té době také došlo k prolomení zabezpečení služby a hacker se tak dostal k zamčeným fotkám uživatelů, což byla samozřejmě zpráva pro seriózní noviny i pro bulvár[14]. S příchodem Facebooku však začal zájem o Líbímseti upadat a Líbímseti se začalo pomalu vracet ke své původní ideji seznamce. Tak přibyly další pokročilejší seznamovací funkce. V roce 2010 jej původní majitelé prodali[12] a jejím majitelem je nyní firma S.I.C. spol., s.r.o. Vývoj Líbímseti se od té doby příliš neposunul a tak služba začala po technologické a zejména uživatelské stránce zastarávat. Nyní je cílem firmy S.I.C. službu přebudovat na novější technologie a přizpůsobit ji aktuálním požadavkům uživatelů a trhu. Mým cílem je, co nejlépe uchopit potřeby webového portálu Líbímseti, zanalyzovat je a přispět tak k naplnění cílů zadavatele a větší uživatelské přívětivosti software, a také k lepší udržovatelnosti firmou S.I.C. Dobře zpracovanou analýzou chci také dát jasnou představu vývojářům, co je třeba vytvořit a tím zajistit naplnění výše zmíněných cílů. 3

20

21 Kapitola 1 Popis, konkretizace cíle 1.1 Rozbor zadání Zpracujte business analýzu projektu Vývoj a provoz sociální sítě agilním způsobem. V kooperaci se zadavatelem vytvořte tyto artefakty: Vision Board, Persony, Product Backlog. Cílem tohoto bodu je zpracovat agilní business analýzu jako takovou a v součinnosti se zadavatelem vytvořit výše zmíněné artefakty. Agilní vývoj přistupuje k analýze odlišným způsobem než tradiční metody (Waterfall apod). Stejně, jako se dynamicky vyvíjí agilní projekt, se i rychle mění popis cílů a potřeb zákazníka business analýza. Ačkoli i pro agilní projekty lze použít standardní formáty analýzy (hůře už standardní přístup k její tvorbě), v práci se zaměřím na obvyklý přístup k analýze v agilním světě a to podle metodiky Scrum jakožto hlavního představitele agilního přístupu. Dokumenty by ve shodě s agilními principy měly být jednoduché a výstižné, aby motivovaly ke čtení, ne od něj neodrazovaly, a dávaly jasnou představu o tom, co má být vytvořeno, jak zákazníkovi, tak vývojářům. Výstupy práce budou tyto: 1. Vision Board krátký popis vize projektu, obsahující zejména prohlášení vize. Vision Board stručně a jasně popisuje cíle a přínosy projektu, jeho kontext, zainteresované strany a cílovou skupinu uživatelů. 5

22 1. Popis, konkretizace cíle 2. Persony Persony 1 slouží k popisu uživatelů cílového produktu. Jejich cílem je zachytit uživatele z více pohledů. Popisují vzorce jejich chování, technické dovednosti spojené s možným užíváním produktu a jejich motivaci a zájem o výslednou funkcionalitu či nefunkční parametry. Popis by opět měl být velmi stručný a výstižný. 3. Product Backlog soupis funkčních a nefunkčních požadavků. Skládá se z tzv. User stories uživatelských příběhů. Každá user story popisuje jeden požadavek funkční či nefunkční. Jde o jednoduchou větu, která jasně říká: Kdo může či nemůže něco vykonat a jaký je business přínos tohoto požadavku. User stories jsou doprovázeny také tzv. akceptačními kritérii dalšími parametry požadavku resp. informacemi o tom, jak poznáme, že je daný požadavek správně implementován. Ke specifikovaným user stories připravím i testovací scénáře pro ověření korektní implementace požadavku vývojáři. Výstupy budou vytvářeny na základě schůzek se zákazníkem, diskusemi s vývojáři a specifik business domény seznamek tak, aby bylo dosaženo co nejlepšího výsledku Popište a demonstrujte jak udržovat artefakty během běhu projektu aktuální. Výstupy agilní business analýzy jsou stejně dynamické, jako vznikající produkt. Požadavky se přidávají, někdy i odebírají. Mění se a nejvíce se mění jejich priorita. Dokumentaci analýzy je třeba držet aktuální, aby bylo jasné, co bude implementováno. Zákazník i vývojový tým by měli mít vždy aktuální obrázek. Popíši, jak se dokumenty mění, jak vypadá celý proces změny, jak je udržovat aktuální a jaké kroky je vhodné provést pro co nejhladší průběh změn. Popis doplním textovými a grafickými ukázkami Ověřte artefakty pomocí tzv. nejlepších praktik (best practicies) a kontrolních seznamů (checklistů). Analýzu je velmi dobré komunikovat se zákazníkem i vývojovým týmem, aby bylo zaručeno společné porozumění. Dokumenty je však vhodné zkontrolovat i jiným způsobem. K tomuto účelu použiji checklisty (kontrolní seznamy) a best practicies (nejlepší praktiky). Checklisty popisují, co mají jednotlivé dokumenty obsahovat, jaká má a nemá být jejich struktura. Poskytují seznam nejčastějších chyb, kterých je 1 Jsou-li v textu práce uvedeny Persony (s velkým P), jedná se o označení dokumentu, jeli použito slovo persona (či persony), mám tím na mysli zachycení konkrétního typu uživatele či zainteresované osoby ve formátu persony, např. jak uvádí Roman Pichler zde[15]. 6

23 1.2. Co není součástí práce třeba se vyvarovat. Best practicies zase popisují, jak by měly být dokumenty vytvářeny, dávají rady pro vhodnou strukturu a postupy, které je vhodné dodržet. Ze získaných zdrojů vytvořím kompilací své vlastní kontrolní seznamy, dle kterých budu artefakty verifikovat Zhodnoťte přínos agilní business analýzy pro implementaci Vašeho projektu. Zhodnoťte její výhody a nevýhody proti tradiční business analýze v kontextu Vašeho projektu. Zhodnotím přínos agilní business analýzy pro projekt Vývoj a provoz sociální sítě, pro nějž byla analýza vytvářena. Poukážu na pozitiva a výhody i překážky a problémy, které se vyskytly na tomto projektu, a které se mohou vyskytnout také na jiných projektech. Porovnám výhody a nevýhody agilního přístupu oproti tradičním metodám. Nejdříve provedu srovnání v kontextu našeho projektu, poté uvedu některá doporučení pro ostatní projekty. Tradiční metodou je zde myšlena business analýza u Waterfall řízení projektu, jakožto nejčastějšího způsobu řízení projektu. Jako vstup pro srovnání s tradiční metodou mi bude sloužit především má bakalářská práce[6], kde jsem vytvářel business analýzu tradičním způsobem a použitá literatura Z čeho budu vycházet Pro tvorbu této práce budu vycházet z praktických zkušeností nabytých na zmíněném projektu. Využiji také mých předchozích zkušeností zejména z projektu, na němž jsem vytvářel svou bakalářskou práci[6], jejíž součástí bylo zpracování business analýzy tradičním způsobem. 1.2 Co není součástí práce V návaznosti na business analýzu a pochopení souvislostí budou uvedeny souvislosti s agilním vedením projektu. I ve srovnání s tradičním přístupem. Součástí zadání práce však není vedení projektu agilním způsobem. Ačkoli způsob tvorby business analýzy velmi závisí na způsobu vedení projektu a naší snahou bylo vést projekt spíše agilním, než tradiční způsobem, není cílem této práce vést projekt agilně, zkoumat agilní řízení projektu jako takové a porovnávat jej s tradičním. Daná srovnání budou vztažena zejména k business analýze, která je cílem práce. 1.3 Rozdělení odpovědnosti na projektu Jak již říká předposlední věta zadání, tato práce je součástí týmového projektu tří studentů. V této části proto popíši základní rozdělení kompetencí v rámci diplomového týmu, jak ukazuje obrázek

24 1. Popis, konkretizace cíle Obrázek 1.1: Rozdělení odpovědnosti na projektu Jak lze vidět z obrázku, zodpovědnosti za jednotlivé výstupy byly víceméně oddělené, avšak v oblasti verifikace výstupů jsme využili výhod týmové práce. Vzájemně si pomohli zajistit větší kvalitu našich výstupů. Na obrázku je zachycena role zadavatele, kterým je zástupce společnosti S.I.C. pro komunikaci s naším týmem programátor Michal Maněna (dále se v textu objevuje výhradně jako zadavatel) Štefan Pinďák autor práce Zastával jsem funkci analytika a vedoucího týmu. Mou zodpovědností bylo zpracování business analýzy na základě požadavků zadavatele a vedení týmu. Často jsem sloužil jako prostředník pro komunikaci se zadavatelem nebo s vedoucím práce. Mojí prací bylo zjednodušeně odstraňovat překážky ve vývoji a poskytovat všem zainteresovaným stranám jasnou představu o stavu projektu. Výstupy mé práce byly tyto: 8 1. Vision Board reprezentující vizi a celkový kontext projektu,

25 1.3. Rozdělení odpovědnosti na projektu 2. Persony reprezentující hlavní zainteresované strany (stakeholdery) a uživatelské skupiny, 3. Produkt Backlog zpracované funkční a nefunkční požadavky, 4. Testovací scénáře pro ověření splnění požadavků. Pro verifikaci mých výstupů mi sloužily schůzky se zadavatelem a se členy týmu. Dále jsem prováděl review kódu mých kolegů, předakceptační testování a připravoval uživatelské akceptační testování (UAT) Martin Humeník Martin Humeník zastával funkci programátora. Starostí Martina Humeníka byly části aplikace týkající se uživatelské komunikace zejména v souvislosti se zprovozněním Jabberu. Tedy chat, skupinová konverzace, hromadné diskuse aj. Dále také řešil přihlášení pomocí údajů služby Facebook. Velkým přínosem pro tým byla také jeho znalost Gitu, tak pro nás bylo snazší začít s tímto nástrojem správně pracovat. Společně s Lukášem odvedli velkou práci tvorbou prototypů při analýze proveditelnosti. Hlavními výstupy jeho práce bylo vytvoření následující funkcionality Líbímseti: 1. Registrace a přihlášení na Líbímseti standardním způsobem, 2. Registrace a přihlášení na Líbímseti pomocí údajů Facebook, 3. Chat, 4. Místnosti víceuživatelský chat, 5. Diskuse diskuse nad společným tématem či otázkou, 6. Seznámení spolupráce na funkcionalitě přidání do přátel, odebrání z přátel. K těmto výstupům zpracovával na základě analýzy wireframy ukázky rozložení uživatelského rozhraní. Na závěr zpracoval grafiku i kódově v CSS. V rámci vývoje použil a zprovoznil tyto technologie: 1. JAXL PHP knihovna pro komunikaci s Jabber serverem, 2. Converse.js IM klient ve webové stránce, 3. XMPP Prebind for PHP knihovna, pro vytváření Jabber session na straně webového serveru. Pro analýzu proveditelnosti za použití prototypů vytvořil, ověřil: 9

26 1. Popis, konkretizace cíle 1. RPC (Remote procedure call) klienta, 2. Databázový model pro testovací data k prototypům. K nastavení a chodu vývojového prostředí přispěl: 1. Zaučením práce s verzovacím systémem Git řešením problémů. 2. Vytvořením a konfigurací vývojového prostředí na serveru Lukáš Jeschke Lukáš Jeschke zastával také funkci programátora. Lukáš Jeschke měl na zodpovědnost zejména funkcionalitu spojenou se seznámením uživatelů, tedy to, proč uživatelé v konečném důsledku na seznamky chodí. Dále zprovoznil přihlášení na Líbímseti pomocí údajů Google a MojeID[76]. Nemalou částí jeho práce byla také analýza proveditelnosti. Hlavními výstupy jeho práce byla tato funkcionalita: 1. Registrace a přihlášení na Líbímseti pomocí údajů Google, 2. Registrace a přihlášení na Líbímseti pomocí identifikátoru MojeID, 3. Profil část Líbímseti zabývající možností prezentace uživatele skrz jeho profil a interakcí s uživateli (právě přes profil), ohodnocení aj, 4. Seznámení implementace seznámení pro tři druhy seznámení: vážný vztah, flirt, přátelství, seznámení s jinými uživateli na základě kritérií, automatické filtrování a upřednostňování uživatelů apod. K těmto výstupům zpracovával na základě analýzy wireframy ukázky rozložení uživatelského rozhraní. Na závěr zpracoval grafiku i kódově v CSS. V rámci vývoje použil a zprovoznil tyto technologie: 1. MojeID univerzální identifikátor používaný pro přihlášení a registrace. Pro analýzu proveditelnosti za použití prototypů vytvořil, ověřil: 1. Routování různých funkcionalit (služeb) Líbímseti na různé porty, 2. Databázový model část pro testování udržitelnosti cookies za použití routování, 3. Session handler ověření udržení session za použití routování. K nastavení a chodu vývojového prostředí přispěl: 1. Vytvořením a konfigurací vývojového prostředí na serveru pomoc Martinu Humeníkovi. 10

27 Kapitola 2 Analýza a návrh Tato část se zabývá analytickou činností, která předcházela realizační části práce. Vysvětlím, jaký je účel, cíle a přínosy business analýzy. Jak se liší tradiční a agilní přístup k analýze. Bude zde popsáno, jakým způsobem byly zvoleny různé přístupy k tvorbě agilní business analýzy, jako i volba vhodné struktury výstupů a způsoby jejich ověření. Z těchto analytických vstupů budou vyvozeny závěry a návrhová rozhodnutí pro realizaci této práce. Součástí bude i business analýza domény seznamek. Kde bude popsána situace na trhu, obchodní modely, motivace uživatelů seznamek a vzorce jejich chování. 2.1 O business analýze V této části bych rád popsal, co to business analýza je, čím se zabývá a jaké jsou její cíle a přínosy. Popíši také business analýzu v kontextu celého projektu a provedu úvodní srovnání tradičního a agilního přístupu k analýze Účel business analýzy Business analýza je disciplína softwarového inženýrství, která se zabývá zachycením potřeb a cílů zákazníka a návrhu řešení, které by pomohlo jejich uspokojení. Business analýza se vyskytuje jako vstup pro plánování, návrh, realizaci, testování (a další disciplíny) i v dalších odvětvích. Je klíčová pro odhadnutí rozsahu (pracnosti), naplánovaní celého projektu a řízení rozsahu projektu tzv. scope managementu. Samotná business analýza je velmi široký pojem. V této práci se budu věnovat především projektové analýze softwarového produktu. Její cíle jsou (vycházeno z[3]): 11

28 2. Analýza a návrh 1. Zachycení stávajícího stavu: stávajícího řešení jeho výhod a nevýhod, aktuálních potřeb plynoucích ze stavu stávajícího řešení. 2. Zachycení stávajících a budoucích potřeb a cílů vycházejících z: aktuálního stavu trhu, aktuálního stav firmy, oddělení či produktu, pro jehož podporu je projekt realizován, cílů a strategie firmy, oddělení či produktu. 3. Popis cílové skupiny uživatelů a stakeholderů: profitujících z daného projektu (užívající produkt či jeho výstupy), majících vliv na výsledné řešení. 4. Popis konečných požadavků na produkt: Funkčních které říkají, co by měl daný produkt umět, dělat. Nefunkčních které říkají, jak by to měl dělat. Uživatelské rozhraní jak budou vypadat jednotlivé obrazovky, jaké zde budou grafické prvky... Bezpečnostních ověřování uživatelů, různé úrovně přístupu... Výkonnostních rychlost odezvy, počet současně pracujících uživatelů... Internacionalizačních v jakých jazycích bude systém komunikovat s uživatelem... Zotavení co se má stát v případě pádu funkce, systému... Zálohování jaká data se mají zálohovat,... Kvalitativních dokumentace návrhu, kódu, projektového řízení, přenositelnost, dostupnost... Aj. Pro splnění těchto cílů, zejména posledního, by zpracované informace měly být[16]: 12 Kohezní dokumentovat jeden produkt. Kompletní měly obsahovat všechny relevantní informace. Konzistentní požadavky by měly být v souladu a neměly si protiřečit nebo popisovat oba to samé.

29 2.1. O business analýze Správné protože chyby v požadavcích vedou k chybám v software. Dosažitelné každý požadavek by měl být implementační v daném rozpočtu, infrastruktuře, čase a zdrojích. Upravovatelné související požadavky by měly být zaznamenány společně, dokumenty by měly být logicky uspořádány, aby bylo možno je snáze upravovat. Jednoznačné požadavek může být interpretován pouze jedním způsobem. Testovatelné musí existovat způsob, jak ověřit, že byl požadavek splněn. Z toho vyplývá, že by měly být srozumitelné zákazníkovi i vývojářům. Tento stav je nezbytný i pro zachycení uživatelů produktu. Pro zaznamenání stávajícího stavu a cílů produktu je žádaný, avšak vyžaduje po vývojářích, aby rozuměli businessu zákazníka, což není vždy dobře dosažitelné. Měl by být pochopitelný alespoň pro zákazníka, analytika a projektového manažera. Business analýza, zejména pak specifikace požadavků je klíčová pro každý projekt. Specifikace je důležitá pro různé zainteresované strany, aby věděly[16]: Manažer projektu jaký je rozsah projektu, co musí splnit a dodat, co už je mimo rozsah a je to požadavek na změnu, a aby mohl celý projekt naplánovat Zákazník co si objednal a měl o tom potvrzení. Architekt jaké funkční a nefunkční požadavky musí v návrhu uspokojit, jakým směrem se může projekt vyvíjet. Vývojář co a jak vyvíjet. Tester co a jak testovat. Údržbář jakých požadavků se chyba nebo změna týká, apod. A další (integrátor systému, budoucí analytici,... ). Samotná business analýza není jednoduchý proces. Skládá se z těchto činností: Shromažďování schůzky se zákazníkem, jednání, průzkumy atd. Analýza promýšlení, vymýšlení, debaty atd. 13

30 2. Analýza a návrh Specifikace dekompozice, zápis faktů či požadavků atd. Verifikace čtení textu, schůzky, jednání, boje o rozsah, kontrola atd. Tyto činnosti neprobíhají striktně za sebou v tomto pořadí, ale prolínají se v čase, zdrojích (lidech,... ) i cílech, které sledují Business analýza a její zpracování v tradičním a agilním řízení projektu Pro lepší pochopení, proč se agilní business analýza zpracovává daným způsobem, je vhodné popsat rozdíly mezi zpracováním business analýzy v tradičním a agilním řízením projektu. Popis se bude týkat zejména softwarových projektů. Je třeba si uvědomit, že jak tradiční, tak agilní metody se používají nejen pro řízení softwarových projektů, ale i v dalších oblastech Tradiční řízení V klasickém pojetí projektového řízení (Waterfallu, ale i jiných příbuzných metodikách) vede projekt a projektový tým projektový manažer, tedy jedna osoba. Vývoj probíhá tak, že jednotlivé činnosti softwarového inženýrství následují za sebou podobně jako vodopád, jak jde vidět z obrázku 2.1. Výstup předcházející činnosti je vstupem následující. V tradičním Waterfallu byly i jednotlivé role (analytik, vývojář, tester,... ) striktně odděleny, to ale v praxi není příliš možné, zejména s přihlédnutím k velikosti týmů[17]. Občas se však stává, že jednotlivé fáze provádí jiné firmy či týmy (např. jiná firma provádí analýzu či testování). Dokonce se stává, že roli business analytika zastává projektový manažer, ať už z důvodu nedostatku lidských zdrojů, nebo opomenutí důležitosti této činnosti[2]. Výstup analýzy je tedy vstupem pro návrh, výstup návrhu pro implementaci atd. Jelikož návrat není příliš možný (v originálním pojetí Waterfallu nebyl ani uvažován jednotlivé fáze byly ukončeny a už se k nim nebylo možné vracet), bylo třeba každou část řádně zdokumentovat. V tradičních metodách reprezentovaných nejvíce Waterfallem[18], V-modelem a RUP jsou vytvářeny rozsáhlé dokumenty business analýzy. Někdy těchto dokumentů může být opravdu hodně[3], ale není to pravidlem (naopak se často kvůli úspoře některé analýzy či dokumenty nedělají nebo nedělají tak důkladně). Většinou existuje dokument zachycující analýzu stávajícího stavu. Dokumenty zpracovávající vizi, potřeby a cíle mohou být různé a liší se jak v účelu (a obsahu), tak v rozsahu. Může být zpracován samostatný dokument vize, nebo vision and scope dokument[19], dokument business požadavků aj. Uživatelé a stakeholdeři a jejich popis se prolíná jednotlivými dokumenty, kde 14

31 2.1. O business analýze Obrázek 2.1: Vývojový model Waterfall převzato z[18] jsou popsáni postupně k většímu a většímu detailu. Pro popis funkčních požadavků se používá Use Case dokument a pro popis všech požadavků na produkt potom specifikace požadavků (SRS). Někdy (a ne výjimečně) se vytváří pouze jeden dokument specifikace požadavků, kde jsou většinou alespoň základním způsobem popsány všechny výše zmíněné záležitosti. Dokumenty jsou v drtivé většině strukturované vhodně doplněné obrázky či diagramy (například UML). Analýzu nejčastěji vytváří jeden analytik, z důvodů konzistence a koheze, ale v případě velkých projektů je obvykle analytiků více. Jak jsem již uvedl, často analytik pracuje nezávisle na vývojářích či dokonce analýzu a implementaci vytváří jiné týmy či firmy. Proto je potřebné vytvoření důkladné (a rozsáhlé) dokumentace v úvodní fázi projektu před zahájením návrhu a implementace. Předávání velké dokumentace mnozí říkají házení papírů přes zeď symbolizující oddělenost týmů. V návaznosti na firemní či týmové zvyklosti probíhá verifikace analýzy se zákazníkem a probíhá, nebo neprobíhá, také se členy vývojového týmu, nejčastěji s architektem či jinou osobou, která má celistvý pohled na projekt (a produkt). Někdy bývá analýza zkontrolována jiným analytikem záleží na zvyklostech firmy, aktuálních možnostech a senioritě analytika zpracovávající 15

32 2. Analýza a návrh analýzu. Samotný analytik si pak vytvořené dokumenty může ověřit pomocí nejlepších praktik (best practicies) a kontrolních seznamů (checklistů), kterých bylo pro účely tradiční analýzy dostatečné vytvořeno množství. Na začátku se vytváří rozsáhlá analýza, kterou je poté možno předat architektům a návrhářům. Nejdříve se provádí analýzy stávajícího stavu, potřeb a cílů, poté cílové skupiny a nakonec požadavků na systém. Je třeba říci, že tyto analýzy nemusí striktně následovat, většinou jsou však uvažovány a zpracovávány v tomto pořadí. Požadavky na produktu by měly zpracovávány až jako poslední jelikož vychází z předešlých analýz. Analýzy jsou provedeny do té míry, aby nezůstaly pokud možno žádné otevřené body či nejasnosti, to platí zejména pro zpracování požadavků. Pokud je zde nějaká nejasnost či informace ještě není známa, je označena jako TBD (To Be Determinated k budoucímu upřesnění). TBD nesmí být příliš velké či rizikové pro produkt, aby nehrozil nárůst rozsahu. Informace a vstupy pro business analytika jsou nejčastěji schůzky se zákazníkem. Bývá také používáno dotazování cílových uživatelů či informací o aktuálním postavení firmy či produktu a stavu trhu. Jakmile je hotová analýza je možné začít projekt plánovat, navrhovat a posléze implementovat. Některé projekty se plánují již před fází analýzy a to proto, že je již podána nabídka, ve které jsou uvedeny omezující podmínky, které se snaží vymezit možný rozsah projektu již na začátku. Analytik i projektový manažer mají většinou složitější práci. Analytik musí hlídat již při analýze rozsah a projektový manažer plánovat bez přesných požadavků. Smluvní prostředí, zejména velkých společností, často vede k tomuto modelu. Waterfall se nejčastěji používá u projektů s pevnou cenou a pevným termínem (FTFP), tento typ kontraktu totiž říká: Dodejte nám to, co chceme, za tuto cenu, nejpozději do tohoto data. Tento typ smlouvy je nejčastější a zejména velcí zákazníci požadují dodávku tímto způsobem. Práce analytika odevzdáním analýzy většinou nekončí. Analýza také slouží jako podklad pro testování, zejména akceptační. Může být také k dispozici členům projektového týmu pro případné objasnění nejasností. Je však k dispozici také zákazníkovi pro upřesnění TBD bodů a pro případnou dokumentaci požadavků na změnu do analytických dokumentů. Analýza v mnoha případech nebývá finální, ale může se měnit. Nejvíce se mění pochopitelně funkční a nefunkční požadavky na produkt, méně často již cílová skupina nebo popis cílů a potřeb, i to je však možné. Změna v obecnější analýze se pak promítne i do detailnější analýzy. Změna v definici cílů a potřeb se promítne často do cílové skupiny, ale vždy do požadavků. Modifikace či přidání další cílové skupiny uživatelů nebo stakeholderů se projeví na změně požadavků na produkt. Každá takováto změna požadavků vede (nebo by měla vést) ke změnovému řízení specifikaci změny, ocenění implementace, schválení či neschválení zákazníkem a případné implementaci dodavatelem. 16

33 2.1. O business analýze Agilní řízení Agilní metodiky jsou poměrně mladý způsob vedení projektu a většina z nich není příliš dobře zdokumentována. Nejlépe se informace dají najít o metodě Scrum, kterou především se tato práce zabývá, ale i zde se některé zdroje a lidé Scrum praktikující rozcházejí v některých záležitostech. Jejich popularita však každým rokem roste a tak přibývá informací i týmů implementujících Agile. Přestože jsou mladé, vykazují agilní metody cenné úspěchy ve srovnání s tradičními metodami je mnohem více projektů vedených agilně úspěšných, než je tomu v případě projektů řízených klasicky[20]. Na jejich konci je tak daleko častěji spokojený zákazník. Pro dobré pochopení principů agilního vývoje uvedu na začátku Manifest Agilního vývoje software (dále Agilní manifest). Objevujeme lepší způsoby vývoje software tím, že jej tvoříme a pomáháme při jeho tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám: 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 Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. [21] Tento manifest sepsali průkopníci agilního vývoje a spolu s dvanácti principy říká jeho hlavní myšlenku. Agilní vývoj staví na výše zmíněných principech, avšak je třeba říct, že hodnoty uvedené vpravo nezavrhuje a měli bychom si být také vědomi jejich ceny. V některých případech se ve snaze vyzdvihnout hodnoty vlevo zapomíná na ty tradiční vpravo (např. na dokumentaci návrhu a požadavků) a to může vést k problémům. Agilní přístupy se na rozdíl od Waterfallu odráží od samoorganizovaných týmů, kde hlavní osoba Scrum Master je spíše facilitátor a coach, než vedoucí či manažer[22]. Role členů týmu (programátor, tester,... ) se mohou měnit dle aktuální potřeby. Je velký důraz na univerzálnost[23]. Některé týmy, ale zachovávají role členů víceméně stejné po celou dobu. Je velmi důležité, aby agilní tým fungoval co nejdelší dobu ve stejném složení, tak může efektivita v průběhu projektu stoupat. U Waterafallu je to také ideální stav, ale brání tomu fakt, že v jednotlivých fázích často pracují jiní lidé, anebo jsou v průběhu projektu různé požadavky na lidské zdroje a tak jsou lidé realokováni. Dalším pilířem je iterativní přístup k tvorbě produktu. Produkt je dodáván v krátkých iteracích sprintech, většinou délky dvou až čtyř týdnů. Délka sprintu bývá v průběhu projektu stejná. Scrum tedy ukotví ve sprintu čas 17

34 2. Analýza a návrh dodávky a zdroje i obsah dodávky ve Sprint Backlogu. Obsah dodávky se však mění v průběhu projektu, zatímco čas a zdroje zůstávají povětšinou stejné. Před každým sprintem jsou zafixovány požadavky, které se budou implementovat. Tyto požadavky mají nejvyšší prioritu a během běhu sprintu nesmějí být měněny. Pokud je vyžadována nějaká úprava, změna či dodatek, je zdokumentován a případně implementován v dalších sprintech. Agilní metody tedy odpovídají vstřícně na změnu a zároveň se snaží udržet jasný a stejný rozsah toho, co má být implementováno ve sprintu, aby se vytvořilo dobré prostředí pro kvalitní návrh a rychlou implementaci. Každý sprint obsahuje všechny činnosti tak, jako Waterfall: analýzu, plánování, návrh, implementaci, testování, nasazení. Na konci každého sprintu probíhá zhodnocení sprintu a retrospektiva vzájemná zpětná vazba členů týmu. Aby byla po každém sprintu dodána fungující aplikace a náklady na nasazení byly co nejnižší, je snahou zavést systém kontinuální dodávky (tzv. continous delivery), jehož předpokladem je kontinuální integrace (tzv. continous integration). V tomto ohledu tak dochází k velké automatizaci. Je třeba říci, že tyto snahy se objevují i u tradičních způsobů vedení projektu, u agilních jsou však velmi podstatnou částí. Na závěr sprintu jsou vždy zákazníkovi demonstrovány implementované části a jsou zároveň zákazníkem akceptovány (či neakceptovány). Demonstrovány jsou pouze implementované požadavky, může jich být tedy méně, než bylo v plánu, ale také více, pokud si tým vede nad plán a rozhodne se vzít navíc další požadavky, dle priority. Každý den sprintu se konají tzv. Daily Scrums, tedy 15 minutová každodenní setkání, kde si členové týmu vzájemně sdělují, co je uděláno, na čem pracují a kde a proč se práce zastavila či vznikly problémy. Všichni členové týmu jsou tak dobře informováni o postupu prací na projektu a kdo v daný čas má co na starosti. Cílem na agilním projektu je pocit kolektivního vlastnictví kódu a vzájemné sdílení informací. Jsou používány skupinové techniky práce jako párové programování (pair programming), kolektivní inspekce kódu aj. Pro dobrou informovanost slouží Scrum board tabule, na které lze vidět stav jednotlivých user stories (požadavků) v průběhu sprintu. Oblíbené jsou pro tento účel lepící papírky. Základní projektové dokumenty Vision Board a Persony by také měli být umístěny tak, aby je měl každý ihned na očích. Agilní metodiky hodně vsází na psanou podobu, ne na elektronickou, v průběhu projektu ale přichází potřeba začít jednotlivé dokumenty a postup projektu dokumentovat i elektronicky pro zpětné zhodnocení a další zlepšování projektu i dalších projektů. Na agilních projektech se na začátku provádí větší analýza. Cílem však není upřesnit a zafixovat všechny záležitosti a požadavky. Na začátku se zjistí vize, cíle a potřeby produktu, identifikují se cílové skupiny a klíčové požadavky na produkt[5]. Identifikuje se tedy první sada požadavků, ty hlavní více, vedlejší s menší přesností (budou upřesněny později) a ujasní se počáteční priority 18

35 2.1. O business analýze jednotlivých požadavků. Po této iniciální fázi, které se někdy říká nultý sprint, nebo pre-sprint se podchytí hlavní myšlenka projektu a první požadavky, na kterých lze dále stavět a vývojový tým zatím připraví vše nutné pro vývoj. Za tvorbu agilní business analýzy je zodpovědná nejčastěji také jedna osoba, jak tomu je v tradičních metodách. Ať už je to Product Owner, nebo Scrum Master v různých týmech se definice těchto rolí velmi liší. Měl by to být Product Owner, který tráví 1/3 času se zákazníkem a upřesňuje potřeby, cíle, cílové uživatele a požadavky a další 2/3 s týmem, kterému je k dispozici pro upřesnění nejasností, vysvětlení požadavků či přípravě testů. V některých případech tuto roli zastává Scrum Master, buď z důvodu velikosti týmu, zvyklostí či ochotného zákazníka, který je hodně dostupný a funguje tak částečně jako Product Owner. Sběr, upřesňování a dekompozice požadavků se však děje za účasti celého týmu a pochopitelně zákazníka. Takto se snaží předcházet nejasnostem a nepochopení. Využívá se prototypování, zejména grafického rozhraní (GUI) někdy i za běhu implementace daného požadavku, aby se docílilo spokojenosti zákazníka a omezilo riziko přepracování, nebude-li zákazník implementovaný požadavek akceptovat. Zdroje informací jsou pro agilního analytika podobné jak pro toho klasického. Je to především zákazník, informace z dotazování a analýz cílových uživatelů, informace o stávajícím stavu a další data a statistiky. Jako dokumentace potřeb, cílů a kontextu celého produktu je používána Vision Board, pro zachycení cílové skupiny uživatelů, případně i stakeholderů Persony[5] a pro zachycení funkčních i nefunkčních požadavků na produkt user stories, které jsou souhrnně shromažďovány v Product Backlogu, který nám udává potenciální rozsah projektu. Používán je také Product Canvas, který říká celkově o čem je produkt a je jakýmsi rozpracováním Vision Board, Person i user stories[24] a Business Model Canvas[25] vycházející z Vision Board[26] popisující obchodní strategii produktu. Vision Board, Persony i Product Canvas a Business Model Canvas bývají krátké dokumenty. Product Backlog bývá rozsáhlejší. Používám zde slova dokument, často však za běhu projektu můžou být jednotlivé artefakty (zejména Vision Board, Persony a Product Canvas) reprezentovány tabulí umístěnou v místnosti vývojářů s popsanými lepícími lístečky. Cílem je, aby dokumenty podávaly jasně a stručně potřebné informace neodrazovaly od čtení zákazníka ani členy týmu. Agilní business analýza se sice z velké části zpracovává v počáteční fázi projektu. Avšak je připravena, stejně jako agilní metodiky celkově, pružně reagovat na změnu, jak se mění zákazníkovy potřeby a upřesňují se jednotlivé požadavky. Díky iterativnímu přístupu není třeba specifikovat všechny požadavky dopředu, ale mít upřesněny jen ty, které se budou vyvíjet v další iteraci. Agilní analýza vychází z předpokladu, že důležité věci jsou zjevné na začátku anebo se časem samy přihlásí o slovo. Důležité požadavky zákazník zmíní i několikrát za sebou[5]. Analytické práce se tak provádí plnou měrou za běhu 19

36 2. Analýza a návrh Obrázek 2.2: Vývojový model Scrum převzato z[29] celého projektu. Jiný způsob vedení projektu a především dodávky produktu zákazníkovi vyžaduje odlišný typ kontraktu a placení. Cenový model by neměl být FTFP, protože vkládá příliš velké riziko na dodavatele a vede tak k nevstřícnému postoji ke změnám, což popírá hned dvě zásady Agilního manifestu a brání tak využití výhod agilního přístupu[27]. Další používaný model je čas a materiál (TM). Tento model je výhodný pro dodavatele, pro zákazníka však skýtá riziko. Zákazník nemá jistotu dodávky a ve výsledku model nenutí dodavatele komunikovat se zákazníkem a odpovídat na jeho měnící se požadavky. Někteří jej ale úspěšně využívají ku prospěchu obou stran, z českých dodavatelů např. Etnetera[28]. Někteří doporučují model platby za story points body, kterými jsou ohodnoceny jednotlivé user stories a které vyjadřují jejich pracnost. V tomto modelu zákazník platí za požadavky, které na konci sprintu akceptuje. Dodavatel zase dostává peníze za implementované požadavky, s kterými je spokojen zákazník. Celý model vede k užší komunikaci, lepší reakci na aktuální požadavky a změny, dodávání vyšší business hodnoty a spokojenosti dodavatele a především zákazníka. Na závěr je vhodné říci, že firemní kultura dodavatele i odběratele a specifika každého projektu či jeho dohodnutého cenového modelu nutí k přizpůsobení agilní metody okolnostem, tzv. tailoring. Snažíme se přizpůsobit agilní metodu aktuální situaci za zachování co největšího množství výhod agilního přístupu Řízení rozsahu Nejvíce je rozdíl mezi tradičním a agilním řízením projektu zřejmý na procesu řízení rozsahu, tzv. Scope Managementu. Rozdíly jsou velmi dobře popsány 20

37 2.2. Návrh zpracování business analýzy Obrázek 2.3: Agilní vs Waterfall trojimperativ převzato z[30] v tomto článku[30]. Zde uvedu pouze hlavní myšlenky. Jak jsem již naznačil Waterfall fixuje rozsah projektu (viz obrázek 2.3), čas a zdroje se mohou měnit. Vstupem pro řízení rozsahu je právě business analýza, která říká, jaké části mají být implementovány, dále také nabídka s omezujícími podmínkami (zejména pokud je smlouva podepsána ještě před analýzou). Agilní přístup naproti tomu zafixuje čas a zdroje a to, co se v průběhu může měnit je obsah dodávky, tedy rozsah. Dodávka se mění dle aktuálních priorit pro každý sprint může dojít k opětovné prioritizaci Product Backlogu a jeho doplnění (přidání user stories) či úpravě a tím i zařazení jiných požadavků do sprintu, než bylo předpokládáno na začátku projektu či dokonce před předcházejícím sprintem. Tabulka 2.1 ukazuje hlavní rozdíly v řízení rozsahu na tradičním (pro projektového manažera) a agilním projektu (pro Scrum Mastera či podobnou roli)[30]. 2.2 Návrh zpracování business analýzy Způsob vedení projektu Na začátku popíši, jaký styl práce na projektu jsme si vybrali, od tohoto faktu se velmi odráží zpracování business analýzy. 21

38 2. Analýza a návrh Waterfall Připravte plán řízení rozsahu. Připravte Prohlášení rozsahu projektu. Vytvořte hierarchickou strukturu prací (WBS). Používejte systém pro řízení změn a pokuste se tak předejít nárůstu rozsahu. Řiďte plnění jednotlivých úkolů a tak předcházejte nebo napravujte zvyšování rozsahu na úrovni jednotlivých úkolů Řízení rozsahu Agile Ujistěte se, že tým chápe vývojový framework a proces zvoleného agilního přístupu. Facilitujte/veďte plánovací schůzky k vizi, velké dodávce (release), iteraci, dennímu setkání (Daily Scrum) a zajistěte, aby byly neformálně dokumentované plány dobře viditelné všem zainteresovaným osobám. Facilitujte/veďte plánovací schůzky tak, aby tým mohl vytvořit plán, který ukazuje rozdělení práce napříč několika iteracemi. Product Backlog patří zákazníkovi změny v něm se dějí na jeho podnět a s jeho souhlasem. Pokud je třeba, připomeňte zákazníkovi, že během sprintu nejsou povoleny změny v požadavcích a rozsahu, který má být dodán. Nechte členy týmu organizovat si své denní úkoly a facilitujte konverzace se zákazníkem, aby se předešlo zbytečné práci navíc nebo tzv. gold platingu (zbytečnému vyšperkování požadavku). Tabulka 2.1: Řízení rozsahu na tradičním a agilním projektu Jako způsob dodávky naší práce jsme zvolili a na začátku také dohodli se zadavatelem (zaměstnancem firmy S.I.C., spol. s.r.o.) model podobný Story Point modelu popisovanému dříve. Vývoj a dodávky měly probíhat v iteracích. Konkrétní podoba měla být tato: Před začátkem iterace se zadavatelem dohodneme, jaké požadavky jsou prioritní, a přesně je specifikujeme. Jako tým potom odhadneme náročnost požadavků a rozhodneme se, jaké množství pracnosti jsme schopni implementovat a na základě toho vybereme požadavky s nejvyšší prioritou a navrhneme jejich implementaci zadavateli. Na společné schůzce se potom dohodneme, jaké požadavky se skutečně budou implementovat. Měly by to být požadavky specifikované, ale nemusí to být nutně ty, které navrhl tým. Měly by se vlézt do rozsahu, který akceptuje tým, a tým by s nimi měl souhlasit. Zadavatel požadavky ocení dle odhadnuté pracnosti 22

39 2.2. Návrh zpracování business analýzy a vlastní potřeby požadavku. Během samotné iterace se požadavky na iteraci nebudou moci měnit. Během iterace budeme konzultovat vyvíjené řešení, problémy a nejasnosti se zadavatelem. Stejně tak budeme případně upřesňovat některé požadavky, u kterých se objeví nejasnost či nepřesnost. Tomuto jsme se chtěli vyhnout dobrou analýzou požadavků předem, protože upřesňování často vede k nárůstu rozsahu a přidávání funkcionalit, které nejsou nutné. Za běhu iterace bylo v plánu specifikovat požadavky, které měly být potenciálně implementovány v dalších iteracích. Na konci iterace měly být implementované požadavky prezentovány a akceptovány či neakceptovány zadavatelem. A na základě toho uplatněn dohodnutý model ocenění naší práce. Před koncem iterace už měly probíhat debaty o iteraci další, upřesňování požadavků a následné ocenění. Po prezentaci výstupů iterace mělo ihned dojít k domluvě na požadavcích implementovaných v iteraci další atd. dokola, jak jsem již popsal. Pro zmíněný model jsme se rozhodli z několika důvodů. Prvním důvodem byl fakt, že původní očekávání byla taková, že se dohodneme na rozsahu, který implementujeme a na základě toho dostaneme případnou odměnu. Požadavky však nebyly detailně zpracovány a dozvěděli jsme se, že se nejspíše budou měnit. V tomto momentě jsme nechtěli riskovat obrovský nárůst rozsahu upřesňováním, měněním či přidáváním požadavků. Z naší strany by tak mohlo dojít k extrémní vytíženosti, přes kterou bychom nebyli schopni implementovat smluvené požadavky. Firma by zase nedostala to, co očekávala a navíc jako tým bychom nebyli ochotni ke změnám, když byl domluven rozsah. Obě dvě strany by tedy na tomto modelu tratily. Výše zmíněným modelem jsme se plánovali vyhnout změnovému řízení, které je vždy určitým způsobem soubojem mezi zákazníkem a dodavatelem o to, co bylo v domluveném rozsahu a co už ne. Druhým důvodem byl pocit, že očekávání firmy jsou velmi velká a naše možnosti, zejména časové, nejsou takové. Chtěli jsme tedy zafixovat náš čas, který tomu budeme věnovat tím, že se budeme vždy zavazovat pouze k následující iteraci, čímž budeme moci zlepšovat naše plánování a odhady, a zároveň neustálou diskusí a předváděním výsledků (hlavně na konci iterací) dát zadavateli jasnou představu, co může očekávat Způsob zpracování business analýzy Zvolený způsob zpracování business analýzy velmi vycházel z vybraného vývojového modelu. Na začátku jsem plánoval zpracovat první verze dokumentů (Vision Board, Person a Product Backlogu) a dále je na základě získaných informací upřesňovat a upravovat tak, aby byly pokud možno v každém okamžiku aktuální. Nejdříve jsem tedy chtěl zachytit kontext projektu a poté i cílové skupiny a začít zpracovávat jednotlivé požadavky. 23

40 2. Analýza a návrh Zároveň jsem se rozhodl na začátku zpracovat vlastní analýzu stávajícího stavu (As Is analýzu) trhu jeho stav a aktuální situaci Líbímseti. Tato analýza mi měla sloužit jako zdroj informací pro lepší pochopení celé problematiky a lepší diskusi se zadavatelem o potřebách a požadavcích na produkt. Analýzu jsem plánoval provádět kontinuálně se zaměřením na aktuálně implementované požadavky v dané iteraci, u kterých se objeví nebo zjistím nějaké nesrovnalosti či otevřené body. Tyto požadavky bylo nutné upřesnit co nejdříve, aby nestál vývoj. Další v pořadí, co se priority týče, bylo třeba ujasnit požadavky, které se měly potenciálně implementovat v další iteraci na základě priorit daných zadavatelem a množství zadavatelem poskytnutých informací. Cílem bylo tyto požadavky upřesnit tak, aby mohl tým dobře odhadnout pracnost požadavku a abych usnadnil debatu iterace se zadavatelem o jejich prioritě a zařazení do další iterace. Tímto jsem chtěl dosáhnout stavu, kdy nebude třeba více upřesňovat aktuálně implementované požadavky, protože už budou dobře specifikovány. Jako poslední jsem chtěl specifikovat požadavky, jejichž priorita se nezdála tak velká, nebo nebyly zatím příliš přesné informace od zadavatele. Výstupy mé analýzy měly být dokumenty, uvedené v prvním bodě zadání, tedy: Vision Board popisující kontext produktu, Persony charakterizující cílové uživatele a Product Backlog zahrnující funkční i nefunkční požadavky na produkt. Jako výstup byla plánována také výše zmíněná As Is analýza. Zdroje informací, které jsem plánoval využít, měly být: schůzky a informace od zákazníka, a dále informace získané při tvorbě As Is analýzy a další informace zjištěné především z internetu o Líbímseti a seznamkách obecně. Dotazování cílových uživatelů jsem neplánoval použít především z důvodu utajení celého projektu, které bylo požadováno zadavatelem, a také z důvodu velké pracnosti. Výstupy měly být verifikovány na společných schůzkách se zadavatelem a na schůzkách s týmem. Takto jsem chtěl zajistit oboustranné pochopení. Průběžně jsem chtěl zmíněné artefakty kontrolovat sám pomocí checklistů a best practicies, které naleznu na internetu nebo v jiné literatuře, od lidí z praxe. Celkově jsem se snažil o KISS (Keep It Simple, Stupid) přístup. Tedy dělat věci jednoduché pro všechny strany a nedělat je zbytečně složitě. Jednoduchost a nenáročnost před složitostí a rozsáhlými analýzami sloužícími k získání informací preferují i někteří lidé z praxe[5] S výše zmíněným souvisí to, že jsem chtěl business analýzu zpracovávat jazykem zákazníkova businessu. Jak radí mnozí tradiční a agilní analytici, manažeři či Scrum Masteři[31][32][33][34]. Plánoval jsem tedy jazyk jednotlivých artefaktů, zejména Vision Board a Persony přizpůsobit jazyku zadavatele tedy použít podobné výrazy, jaké používá zákazník, klidně i více lidové, avšak při zachování pochopitelnosti a jednoznačnosti dokumentů. 24

41 2.2. Návrh zpracování business analýzy Také jsem chtěl, aby byly artefakty snadno zapamatovatelné a využít pro to jednoduchých grafických prvků (obrázků charakterizující oblasti produktu či jednotlivé persony). Mojí snahou bylo, aby se zadavatel i vývojáři nedívali na dokumenty jako na nudný technický text, snadno se četly a byly dobře srozumitelné oběma stranám. Dokumenty jsem chtěl vytvořit velikostí odpovídající našemu projektu, jak radí[35]. Nechtěl jsem zpracovávat příliš rozsáhlou dokumentaci, která by nebyla využita, ale zároveň nevytvořit dokumenty nedostačující svým detailem našim potřebám. Schůzek se zadavatelem jsme se plánovali účastnit všichni a já toho chtěl využít pro lepší pochopení zpracovávané business analýzy a zejména požadavků jak zákazníkem, tak členy týmu a dřívější identifikaci sporných míst Vision Board V této části popíši, jak jsem se rozhodl zpracovat artefakt Vision Board popisující kontext projektu. Vision Board poskytuje zainteresovaným stranám projektu, především zákazníkovi celistvý pohled na vytvářený produkt celý kontext, hlavní cíle a způsoby jejich naplnění. Vytváří tak základ, proti kterému mohou být validovány všechny další výstupy analýzy a vytvářený produkt Struktura dokumentu Jako strukturu dokumentu jsem si zvolil tento rámec[26] prezentovaný Romanem Pichlerem. Viz přiložený obrázek 2.4. Tuto strukturu používají i mnozí další lidé v praxi, např. Radek Matěj[5]. Zvolená struktura Vision Board obsahuje tyto části: Prohlášení vize (Vision Statement) Prohlášení v jedné větě shrnuje, co má být vytvořeno a za jakým účelem. Cílová skupina (Target Group) V této části jsou uvedeny hlavní uživatelské skupiny produktu a také ostatní zainteresované strany, zejména stakeholdeři zákazníka. Potřeby (Needs) Shrnují hlavní potřeby vyplívající z aktuálního stavu a cílů firmy a projektu. Měly by popisovat potřeby uživatelů i dalších stakeholderů, především zákazníka. Produkt (Product) V této části jsou vyzdvihnuty hlavní funkce a rysy nového řešení. Doporučuje se jejich počet udržet mezi třemi až pěti, abychom se zaměřili na ty opravdu podstatné. Celkově u Vision Board se doporučuje v každé části popsat jen pár hlavních věcí, abychom zahrnuli to důležité a neuváděli informace, které nejsou klíčové. 25

42 2. Analýza a návrh Obrázek 2.4: Zvolená struktura Vision Board převzato z[26] Hodnota (Value) Říká, co produkt přinese zákazníkovi jak z něj bude zákazník profitovat přímo (zisk) i nepřímo (úspora) a jiné formy profitu (např. zvýšení prestiže). Celý dokument jsem plánoval udržet ve velikosti do jedné strany formátu A4 a tím zajistit jeho stručnost a výřečnost Způsob tvorby Jak jsem zmínil, měl jsem v plánu už na začátku vytvořit iniciální verzi Product Backlogu z informací, které mi poskytne zadavatel. Dále jsem chtěl artefakt upravovat na základě informací získaných od zadavatele, zejména na společných schůzkách, a z poznatků získaných z mnou provedené As Is analýzy, která mi v tomto ohledu měla sloužit jak k zisku informací, tak k lepší komunikaci mezi mnou a zadavatelem. Dokument jsem chtěl průběžně upravovat a verifikovat se zákazníkem a týmem na základě výše zmíněného a také pomocí best practicies a checklistů Verifikace Dokument jsem tedy plánoval verifikovat na společných schůzkách se zadavatelem i týmem. Jednak se ujišťovat, že správně chápu myšlenky zadavatele, a také kontrolovat podobu a obsah celého dokumentu, zda obsahuje vše podstatné. Pro vlastní kontrolu jsem plánoval použít checklisty a best practicies, které sesbírám z publikací a především internetu, vytvořené lidmi praktikujícími Scrum či jinou agilní metodiku. Některé firmy vytvářejí vlastní checklisty na 26

43 2.2. Návrh zpracování business analýzy základě svých zkušeností (ty bývají ale hůře dostupné). Tyto kontrolní seznamy a nejlepší praktiky mi měli dát informaci, zda vytvářím dokumenty správně, a že jejich obsah je takový, jaký by měl být. Na rozdíl od tradičních metod, které fungují o poznání déle, nebylo snadné sehnat konkrétní Vision Board checklist či best practicies, proto jsem se rozhodl vycházet především z těchto zdrojů[36][26][37], které uvádějí vhodné praktiky pro tvorbu tohoto dokumentu a podávají informace o tom, jaký má být obsah, jakou má mít formu atd. Pro sestavení jsem použil také další články pojednávající o tvorbě Vision Board a agilní analýzy vůbec. Na základě toho jsem kompilací vytvořil vlastní checklist, který je k dispozici jako příloha práce na CD Persony V této části popíši, jak jsem plánoval zpracovat dokument Persony charakterizující hlavní uživatelské skupiny produktu. Persony dávají zainteresovaným osobám, zejména zákazníkovi a vývojovému týmu, dobrou představu o tom, kdo jsou cíloví uživatelé produktu (zachycení jako jednotlivé persony). Pomáhají při návrhu uživatelského rozhraní a jeho validaci a verifikaci a snižují náklady na useability testování Struktura dokumentu Co se týče struktury Person lze najít mnoho zdrojů, kde se doporučovaná struktura dokumentu či jednotlivých person liší někdy méně, někdy více. Strukturu person jsem chtěl udělat jednoduchou. Pro vytvoření mé struktury jsem vycházel ze zpracování Person prezentovaných Radkem Matějem na přednášce o Product Ownershipu[5], struktura i požadované informace zvolené struktury jsou velmi podobné formátu prezentovaného Romanem Pichlerem[15]. Viz obrázek 2.5. Persony jsem tedy chtěl mít jednoduché, pochopitelné a dobře zapamatovatelné pro zadavatele i pro tým. Mnou vytvořené persony měly obsahovat tyto informace o uživatelských skupinách: Potřeby a důvody pro užívání produktu. Způsob užívání produktu. Jak se uživatel této skupiny bude chtít k produktu dostat. Každou z těchto informací jsem chtěl zachytit maximálně několika krátkými větami či odrážkami. Jednotlivé persony jsem plánoval vizualizovat, jak mnozí doporučují[15] doplnit fotkou či obrázkem personu výstižně charakterizující, pro lepší zapamatování (jako například persona na obrázku 2.6). 27

44 2. Analýza a návrh Obrázek 2.5: Formát persony dle Romana Pichlera převzato z[15] Obrázek 2.6: Jednoduchý příklad persony dle Romana Pichlera převzato z[15] Měl jsem v úmyslu velikost dokumentu udržet do rozsahu jedné strany A4 a tím udržet dokument krátký a jednoduchý na pochopení Způsob tvorby Hlavně kvůli utajení celého projektu a také z důvodu velké pracnosti jsem se rozhodl nedotazovat cílové uživatele, jak je při tvorbě Person časté, ale vycházet především z informací získaných od zadavatele. Dalším zdrojem mi měla být provedená As Is analýza a další informace především z internetu. Chtěl jsem udělat spíše odlehčené persony[38][5], než dělat detailní UX analýzy cílové skupiny. Persony jsem chtěl zpracovat spíše netechnickým způsobem, byl jsem si však vědom možnosti, že tým nemusí na takto zpracované 28

45 2.2. Návrh zpracování business analýzy persony pozitivně reagovat, jak uvádí[39]. V tomto případě bych jednotlivé persony upravil do techničtější podoby srozumitelné pro programátory. V Personách jsem plánoval zachytit hlavní uživatelské skupiny budoucího řešení. Zprvu jsem plánoval vytvořit personu jen jednu, potom jsem ale naznal, že uživatelských typů nového řešení může být více a rozhodl jsem se person vytvořit čtyři až šest. Nechtěl jsem překročit symbolické číslo deseti person, protože by se dle mého stal dokument těžkopádným a také bych se zabýval spíše detaily jednotlivých person, než hlavními společnými rysy uživatelů. Chtěl jsem se tedy zaměřit na hlavní uživatelské skupiny budoucího řešení, ne na všechny. Jak uvádí[38], chtěl jsem se zaměřit především na motivaci uživatelů pro užívání cílového produktu. Plánoval jsem na začátku zpracovat iniciální verzi Person a dále ji upravovat díky nově nabitým informacím a na základě provedených kontrol. Dokument jsem měl v úmyslu verifikovat se zadavatelem na společných schůzkách, s týmem na schůzích týmu a pomocí best practicies a checklistů Verifikace Artefakt jsem plánoval verifikovat stejnými metodami jako Vision Board, tedy na schůzkách se zákazníkem, s týmem a pomocí best practicies a checklistů. Stejně jako v případě Vision Board nebylo lehké najít konkrétní checklist či soubor nejlepších praktik. Rozhodl jsem se tedy opět kompilací vytvořit svůj vlastní checklist z informací získaných z článků lidí z praxe[40][38][39][15], kde uvádějí své rady, vhodné praktiky, nebezpečí a chyby při tvorbě person obecně. Checklist je k nalezení jako příloha práce na CD Product Backlog Zde uvedu, jak jsem plánoval zpracovat artefakt Product Backlog popisující požadavky na produkt. Product Backlog dokumentuje všechny požadavky na výsledné řešení a dává tak zákazníkovi a vývojovému týmu informaci o tom, co je právě této iteraci vyvíjeno i co by mohlo být implementováno v budoucnu Struktura dokumentu Pro zdokumentování jednotlivých požadavků jsem plánoval použít strukturu user stories, ačkoli to není jediný způsob zachycení požadavků v agilním světě. Mohou to být také třeba use casy (tzv. případy užití), jak uvádí např.[41]. Nebo lze user stories upřesnit použitím use casů či features a přiblížit je tak programátorům, jak popisuje[42]. Jako formát user stories jsem zvolil nejpoužívanější strukturu, jak ji představuje např. Courtney Johnston[43]. Takto zpracované user story se skládá ze tří částí: 29

46 2. Analýza a návrh Jako <uživatelská role> (As an <actor>) chci <vykonat nějakou akci> (I want <action>), abych <dosáhl nějakého benefitu> (So that <achievement>). User story takto popisuje, kdo chce jakou funkci nebo vlastnost produktu a proč ji chce, co mu to přinese, tedy business opodstatnění celého požadavku. Výsledná user story tak může vypadat například takto: Jako uživatel Flickru chci mít možnost nastavit různé úrovně přístupu k mým fotkám, abych měl pod kontrolou, s kým své fotky sdílím. [43] Do kolonky pro uživatelskou roli jsem plánoval použít roli uživatele produktu či některou z privilegovaných rolí zákazníka, která měla zajišťovat provoz produktu (např. administrátor). Chtěl jsem tedy výše zmíněnou strukturu využít pro snazší zpracování user stories, avšak nechtěl jsem se jí vázat za každou cenu, protože by to mohlo vést k slepému používání formule, místo správnému zpracování požadavku, jak uvádí například Steve Ropa[44]. Pomocí této struktury jsem chtěl zachytit nejen funkční, ale i nefunkční požadavky na vytvářený produkt, jak je ukázáno například zde[45]. Nefunkční požadavek popsaný pomocí user story by tak mohl vypadat například takto: Jako operátor call centra chci dokončit alespoň 12 rezervací za hodinu ve špičce, abych minimalizoval čas čekání zákazníka. [45] Nefunkční požadavky platné pro každý požadavek se pak měly promítnout do tzv. Constraints, čili omezení kladených na implementaci celého produktu. Všechny constraints pak byly součástí definice implementovaného požadavku (Definition of Done DoD). User stories jsem plánoval seskupit do větších celků epiců[46], které shromažďují user stories z podobné kategorie (např. epic Profil), abych tak usnadnil orientaci v celém dokumentu a umožnil snazší pochopení dané user story v kontextu celého epicu. Epicy tak měli zastřešovat požadavky ze stejné kategorie, čili popisující nějakou větší funkcionalitu nebo vlastnost produktu. Zvolený template jsem plánoval použít i pro zachycení velkých chyb odhalených během vývoje, abychom je mohli dále zařadit do plánu dalších iterací podle kritičnosti chyby. Tento postup doporučuje Bradley[47]. Jelikož samotný template pro user story nijak neřeší další atributy, které by požadavek měl splňovat, chtěl jsem každý požadavek doplnit akceptačními kritérii, jak popisuje například Courtney Johnston[43]. Akceptační kritéria měly být stručné informace o tom, co musí daný požadavek splňovat, aby mohl být považován za implementovaný a akceptovatelný. Pro user story Jako uživatel se chci přihlásit do systému, abych mohl provádět akce příslušející pouze mé osobě by mohla akceptační kritéria znít takto: Uživatel musí zadat správnou kombinaci uživatelského jména a hesla nebo Po 3 neúspěšných pokusech o přihlášení bude účet příslušný danému přihlašovacímu jménu na 10 minut zablokován a až poté budou umožněny další 3 pokusy o přihlášení. 30

47 2.2. Návrh zpracování business analýzy Požadavky jsem plánoval doplnit návrhy GUI pomocí wireframů a tím popsat grafické rozhraní vyvíjeného produktu. K výsledné struktuře user story jsem plánoval přidat ještě testovací scénář pro ověření správnosti implementace požadavku. Výsledná struktura mého Product Backlogu, resp. každá user story tak byla: ID umělý unikátní a neměnný identifikátor každá user story. Měl být vytvářen dle pořadí, v jakém byly požadavky zapracovávány, a měl sloužit pro zpětné dohledání požadavku, pokud se bude měnit jeho popis, požadavek se bude štěpit atd. Typ požadavku příznak, zda je požadavek funkční nebo nefunkční či bug, aby se mezi požadavky snadněji orientovalo. Epic epic daného user story, tj. do jaké skupiny požadavků patří. Jako uživatelská role uživatele, který chce vykonat danou funkci nebo profituje z dané vlastnosti systému. Chci popsáno výše. Abych již vysvětleno. Priorita priorita požadavku od 1 (vysoká) do 3 (nízká). Story points odhadnutá velikost požadavku. Pracnost pracnost v člověko-hodinách na základě odhadnuté velikosti požadavku a převodního poměru mezi story points a člověko-hodinami. Status stav, v kterém se daný požadavek nachází: Not specified user story ještě nebylo dostatečně upřesněno, New user story je specifikováno, Open user story bylo zařazeno do plánu aktuální iterace, Working na user story se aktuálně pracuje, Closed user story bylo implementováno, Duplicated příznak, že user story bylo zrušeno na základě obsahového konfliktu s jiným. Poznámka. Test case testovací scénáře pro dané user story. Akceptační kritéria 1-n viz popis výše. 31

48 2. Analýza a návrh V této struktuře měl být zdokumentován každý požadavek na produkt, který budeme implementovat. Celý Product Backlog jsem plánoval zdokumentovat v tabulkovém editoru, konkrétně MS Excel, a tím se vyhnout učení s jiným nástrojem, který by se navíc museli naučit používat i zadavatel a vývojáři Způsob tvorby Požadavky jsem plánoval začít zpracovávat po uchopení kontextu projektu a cílové skupiny uživatelů, tedy po zpracování iniciální verze Vision Board a Product Backlogu. Jako hlavní zdroj pro zachycení požadavků mi měly být schůzky se zadavatelem. Témata k diskusi měla vycházet zejména z informací z Vision Board, hlavně z cílů produktu a potřeb uživatelů a z popisu cílové skupiny uživatelů produktu, jejich potřeb a způsobu, jakým plánují produkt užívat (zachyceném v Personách) i z informací získaných jiným způsobem zejména z webu, a cenným podkladem pro vzájemnou diskusi mi měla být As Is analýza, jejímž vytvořením jsem chtěl získat lepší pohled na celou problematiku a funkcionalitu či jiné možnosti, které nabízí konkurence. Product Backlog a jednotlivé požadavky jsem plánoval validovat vůči informacím zachyceným ve Vision Board i Personách, zda jsou s nimi jednotlivé user stories ve shodě. Artefakt jsem chtěl začít zpracovávat až po zachycení kontextu projektu a hlavních uživatelských skupin. Tedy po zpracování iniciální verze Vision Board a Person. Dokument jsem plánoval průběžně upravovat, jakmile přibudou nové požadavky, požadavky se změní, některé budou odstraněny jako již nepotřebné, anebo se změní jejich priorita. Důkladně specifikovány měly být všechny požadavky, o kterých se mělo rozhodnout, zda budou v další iteraci implementovány, aby je tým mohl odhadnout a mohly být oceněny zadavatelem. Potom mohlo být na společné schůzce s ním rozhodnuto, které z nich budou zařazeny do plánu následující iterace. Do Product Backlogu jsem plánoval dávat i velké odhalené chyby, jak radí Bradley[47]. Bugy týkající se právě implementovaných user stories, jejichž oprava by trvala maximálně desítky minut, jsme plánovali opravit ihned a nikde nedokumentovat, větší bugy v aktuálně implementovaných požadavcích potom zařadit do plánu aktuální iterace. Prioritu při upřesňování před výše zmíněnými požadavky měly mít požadavky právě implementované, ty jsem chtěl v případě vzniklých nejasností, upřesnit co nejdříve, aby vývojáři nemuseli čekat. User stories jsem chtěl prioritizovat v souladu s cíly a potřebami nového řešení a názory a postojem zadavatele, abychom se zaměřili na hlavní části 32

49 2.3. As Is analýza produktu, a ne na ty méně podstatné a přinesli tak zadavateli větší business hodnotu. Zároveň se zpracováním funkčních i nefunkčních požadavků pomocí user stories jsem plánoval prototypovat GUI za použití wireframů a tím upřesnit, jak má daný požadavek vypadat po grafické stránce. Artefakt jsem chtěl průběžně kontrolovat na společných schůzkách se zadavatelem, týmem a pomocí best practicies a checklistů a na základě těchto kontrol jej upravovat a uchovávat aktuální Verifikace Jednotlivé user stories i celý dokument jsem chtěl kontrolovat podobně jako Product Backlog a Persony, tedy verifikovat jej na společných schůzkách se zadavatelem a ujišťovat se, že správně chápeme své myšlenky a interpretace požadavků, a také ověřovat jeho obsah a formální stránku. Tím jsem chtěl docílit vzájemného pochopení se zadavatelem, že souhlasí s tím, jaké požadavky a jak jsou popsány. Stejným způsobem jsem chtěl artefakt průběžně kontrolovat s týmem na týmových schůzkách, abych věděl, že vývojáři dobře chápou, co má být vytvořeno a nevznikla tak nedorozumění. Průběžně jsem dokument chtěl verifikovat také pomocí best practicies a checklistů od lidí praktikujících Scrum či jinou příbuznou metodiku, které naleznu na webu nebo v jiné publikaci. Pro ověření Product Backlog a user stories jsem našel podstatně více materiálů, než pro předešlé dva dokumenty. Kompilací především z těchto[4][48] a dalších zdrojů[49][50][43][34][45][51][47] popisujících best practicies a uvádějících kontrolní seznamy, jsem sestavil svůj vlastní checklist. Checklist je k dispozici jako příloha práce na CD. 2.3 As Is analýza Účel Analýza stávajícího stavu webového seznamovacího portálu Líbímseti.cz (dále Líbímseti). Cílem této analýzy je čtenáře blíže uvést do problematiky seznamovacího průmyslu se zaměřením na český trh a aktuální stav Líbímseti na tomto trhu. Bude uvedeno, jak se Líbímseti vede na trhu v porovnání s ostatními seznamkami. Jaké služby Líbímseti nabízí svým uživatelům v porovnání s dalšími seznamkami a jak je jich využíváno. Provedená analýza potom může sloužit jako zdroj informací pro budoucí zlepšení služeb Líbímseti. 33

50 2. Analýza a návrh Způsob zpracování Analýza bude provedena na základě statistik a informací získaných z webových stránek. Pro srovnání Líbímseti s jinými seznamkami budou využity stránky seznamovacích portálů a další informace a statistiky dostupné na webu. Pro účely As Is analýzy nebude prováděn detailní průzkum trhu ani důkladné porovnání funkcionalit Líbímseti s konkurenčními portály. Snahou je přinést základní srovnání a uvést podobnosti a odlišnosti ve funkcionalitě, vlastnostech i obchodním modelu Líbímseti a ostatních seznamek. Pro analýzu nebudou využita konkrétní data o užívání Líbímseti, protože je zadavatel z interních důvodů nemůže poskytnout Historie seznamek Lidé se seznamují od počátků lidského pokolení. Seznamují se prakticky kdekoli. Nejčastěji má toto seznamování sexuální podtext cílem je najít svého partnera. Navazujeme tedy vztahy profesní (myšleno pracovní i jakékoli jiné úřední a oficiální jednání), přátelské a partnerské. Partnerské vztahy bychom mohli dělit na závazné a nezávazné. Zde se budu zabývat především seznamováním s cílem nalezení partnera či přátel. Lidé od nedávna pro seznámení dělají speciální úkony. Pořádají akce (oslavy, plesy,... ). Později se seznamují pomocí médií. V roce 1690 začali ve Velké Británii působit manželské agentury, které na základě žádosti a platby dotyčného muže vytiskly inzeráty, které se potom dostávaly skrze noviny k ženám. Na začátku osmnáctého století byly tyto agentury velmi výnosným podnikáním[52]. Protože být po jednadvaceti letech svobodný bylo tehdy ostudou. Být takzvaně single není ani v dnešní společnosti, zejména ne v té české[53], nijak zakořeněno. Proto se vzrůstajícím věkem roste i touha po nalezení životního partnera. Ve zmíněné době sloužily personální oddíly novin i jako způsob, jak najít kýženého milence nebo milenku pro homosexuály[52]. Seznamování pomocí inzerátů v novinách bylo používané i během dalších století. Situace se velmi změnila po příchodu a prosazení internetu. Už v počátcích internetu si našly seznamovací portály své místo na webových stránkách[7]. Prvními internetovou seznamkou se stal v roce 1994 kiss.com a v roce 1995 vznikla druhá seznamka match.com[7]. Některé seznamovací portály, například české Líbímseti či Lidé.cz[54], nabízely i funkce pro komunikaci uživatelů za jiným účelem, než seznámení například různé diskuse aj. Takto se účel některých seznamek rozšířil z původní seznamky na sociální síť. Sociální sítě mají na internetu mírně delší historii, než seznamky. Prvními sociálními sítěmi byly The WELL (rok vzniku 1985), Thegloge.com a Geocities (1994)[55]. 34

51 2.3. As Is analýza Popularita seznamek dlouhá léta výrazně rostla[9]. S příchodem Facebooku a ostatních novodobých sociálních sítí (Twitter, Google+, Instagram aj.) popularita některých seznamek, které byly výrazně zaměřeny jako sociální sítě, poklesla[8]. Ač se mohlo by se zdát, že seznamky upadnou v zapomnění, opak je pravdou. Počet uživatelů využívajících služeb internetových seznamek stále narůstá[8][9]. Počet uživatelů seznamek v roce 2008 v USA byl tři miliony, v roce 2013 již 10% populace, počet uživatelů sociálních sítí naproti tomu 60%[9]. Čím více je doba uspěchaná a svět virtuální, tím více roste počet lidí, kteří se seznamují online. Počet uživatelů seznamek stoupá a nic nenasvědčuje tomu, že by se tento trend měl změnit. Více a více lidí tak nachází svého životního partnera právě přes seznamky[10]. Začátky seznamování byly ve znamení hledání životního partnera. Brzy se začalo seznamovacích služeb využívat i pro méně vážná seznámení, či jen za účelem sexu. Tento stav trvá na seznamkách dodnes. Postupem času se začínají objevovat seznamky zaměřené čistě na vážné seznámení, například edarling[56] nebo Seznamka Harmonie[57]. Reflektují fakt, že lidé, usilovně hledající životního partnera, nechtějí být obtěžováni uživateli s jinými úmysly. Přibývají také seznamky zaměřené na užší skupinu uživatelů například Seznamka pro postižené[58] nebo seznamka na pro věřící[59] Uživatelé Průměrný věk u uživatelů seznamek u nás je let[53], ale to může být dáno také tím, že někteří uživatelé (zejména ženy) svůj věk úmyslně zkreslují[60][10]. Průměrný věk uživatelů se stále zvyšuje[61] a přibývají i senioři, kteří začínají být důležitým segmentem trhu[61]. Seznamky jsou pouze prostředek k seznámení, samy nic zaručit nemohou, mohou uživatelům jen pomoci při výběru vašeho partnera, kamaráda,... Jsou dobrý sluha, ale mohou být zlý pán. Seznamky už daly dohromady milióny lidí[9]. Většina žen hledá na seznamkách vážný vztah. Většina mužů flirt[62]. Stává se tak, že někteří muži se chovají jinak než obvykle, a žena se nechá oklamat[63]. Žena je zklamaná, muž si zapíše další úspěch. Některé seznamky se tomuto brání ověřováním uživatelů (ověřený uživatel je považován za důvěryhodného), nebo vzkazy uživatelů o nevhodném chování jiných uživatelů jako například Seznamka Harmonie[64]. Seznamka seznámení pouze zprostředkuje, první rande je již ale na uživatelích. Při internetové komunikaci často dochází k idealizaci svého protějšku, což pak může vést k velkým zklamáním. Zejména zjistí-li uživatel, že dotyčný neuvedl pravdivé informace (například fotku)[63]. 35

52 2. Analýza a návrh Čím více někoho na seznamce známe, tím je pro nás méně přitažlivý (už si jej neidealizujeme)[65]. Když člověk vyplní informace pouze obecně, často si chybějící či neúplné informace doplní druhý uživatel podvědomě tak, jak se mu hodí (tj. má rád stejné sporty jako on apod.). S idealizací mají velký problém ženy a málokdy se poučí ze zklamání[65]. Za účelem větší šance získání vysněného partnera často uživatelé úmyslně lžou. Muži lžou nejčastěji o svém věku, výšce a příjmu. Ženy zase o váze, postavě a věku[10]. Ženy svůj věk spíše snižují, jelikož nejvyšší přitažlivosti na seznamkách dosahují v 21 letech[10]. Muži zase svůj věk spíše zvyšují[60]. Lidé neví, jak oslovit svůj protějšek, časté jsou pak nudné konverzace na klasická témata neurazí, ale nezaujmou[65]. Na šest hodin chatování na seznamce připadá jedno rande[65]. Ženy neoslovují příliš muže (nechávají to na nich)[53]. Na seznamkách se chováme více povrchně, vybíráme podle kritérií a rozhraní náš výběr ještě zostřuje (např. zobrazení pouze mužů s výškou nad 175). Přitažlivost či populárnost mužů na seznamkách je dána především jejich výškou (hraje nejdůležitější roli), dále také příjmem (pro pár cm méně je třeba mít podstatně vyšší plat[65]. Muž, který měří o tři centimetry méně, než jeho sok, musí vydělávat o průměrný plat více, aby dosáhl stejné přitažlivosti na seznamce. Alespoň to vychází ze statistik amerických seznamek[65]. Přitažlivost žen je dána jejich postavou, především jejich BMI (nejlépe kolem 19), mužům na platu ženy nezáleží[65]. Důležité pro poznávání lidí nejsou tolik informace, ale společný zážitek. Pomoci může třeba i společný virtuální zážitek (virtuální procházka se svými postavami apod.)[65]. Důležitá je vždy obezřetnost. Seznamky jsou anonymní a nikdy nevíme, kdo je na druhém konci[62]. Dle statistik si 10% sexuálních násilníků z USA domlouvá setkání se svými oběťmi také na seznamkách[10]. Je tedy třeba obezřetnost, jak doporučuje například seznamka Leyter.com[66]. Častým jevem bývá také přebírání. Přes seznamku se lidé dostanou k mnoha potenciálním partnerům a tak mají i několik rande za sebou. Což místo výběru vhodného partnera vede často k opaku, jak píše Janda: Příliš velké množství potenciálních partnerů a partnerek nutí uživatele těchto služeb k tomu, že se chtějí sejít s co nejvíce lidmi v co nejkratší době. Poté vybírají a vybírají, až přeberou. [63] Postupem času se Seznamky staly cílem útočníků, kteří za účelem reklamy či jiných nekalých praktik zakládají podvodné účty a svým chování tak odrazují uživatele. Seznamka není ani špatná ani dobrá. Může pouze nevhodné chování uživatelů eliminovat. 36 Seznámit se musejí její uživatelé už napřímo.

53 2.3. As Is analýza Obchodní modely seznamek Seznamky získávají své peněžní prostředky z: Reklamy: Bannerové. Vzkazové (cílené zprávy uživatelům). Registračních poplatků uživatelů. Poplatky uživatelů za další výhody (např. uživatel zaplatí VIP členství, které jej bude upřednostňovat před ostatními v náhodném zobrazení jiných uživatelů). Poplatky uživatelů za doplňkové služby směřující k seznámení (např. Rozbor osobnosti u seznamky Laskomat.cz[67]). Poplatky za služby umožňující nějakou normálně nedostupnou funkci (prioritní vzkaz jinému uživateli apod.) Toto jsou hlavní způsoby, jakým si na sebe seznamky vydělávají Analýza seznamek Zde uvedu poznatky, společné a odlišné rysy, funkce a obchodní modely seznamek na českém trhu ve srovnání s Líbímseti. Seznamky orientované na seznamování pomocí profilu uživatelů a jejich fotek většinou nabízejí náhodné zobrazení svých uživatelů i nepřihlášenému návštěvníkovi, aby tak upoutali jeho pozornost a přiměly jej k registraci. Toto platí pro všechny níže uvedené seznamky, kde se uživatelé mohou seznamovat tímto způsobem. V českém prostředí fungují desítky (a více) seznamek. Zde uvádím příklady největších a některých dalších Badoo[68] Badoo je největší světová seznamka. Je známá pro své agresivní praktiky sloužící k získání uživatelů, zejména vykrádání poštovních schránek[69]. Seznamka je orientovaná na seznamování pomocí profilů a fotek uživatelů. Seznamka má moderní design a poskytuje mobilní aplikaci pro smartphony. Nabízí lidi na základě lokality a u nás má poměrně silnou uživatelskou základnu. Hodně uživatelů Badoo hledá nezávazný vztah. Badoo poskytuje za poplatek některé výhody, např. takzvanou Badoo plnou moc. Nabízí ověření uživatelů například pomocí údajů z účtu Facebook nebo za poplatek a tak nabízí jistou záruku věrohodnosti uživatele. 37

54 2. Analýza a návrh Elchron[70] Seznamka funguje především prostřednictvím inzerátů. Nabízí podobné kategorie inzerátů pro seznámení jako Líbímseti.cz. Lze vyhledávat i nabídky na sex a erotické inzeráty. Seznamka vydělává z bannerové reklamy na stránkách Jiskření.cz[71] Seznamka je orientovaná na seznamování pomocí profilů a fotek uživatelů. Seznamka má na svých stránkách Školu seznamování, kde dává uživatelům rady, jak zvýšit své šance a seznámit se. To považuji za užitečné vzhledem k výše zmíněnému faktu, že lidé často neumí oslovit svůj protějšek či neví, jak jej zaujmout. Jiskření.cz má poměrně jednoduchý a dobře vypadající grafický design. Seznamka vydělává z bannerové reklamy a poplatků za aktivaci plného účtu. Aktivace plného účtu lze dosáhnout i poskytnutím u pěti přátel Seznamka.cz[72] Seznamka funguje především prostřednictvím inzerátů. Nabízí podobné kategorie inzerátů pro seznámení jako Líbímseti.cz. Navíc nabízí další, méně konzervativní, seznamovací kategorie: gayové, lesbičky, bisexuálové, výměna párů aj. Dochází k postupnému propojování s Rande.cz, které je spíše orientované na seznamování pomocí profilů a fotek uživatelů. Seznamka vydělává z bannerové reklamy na stránkách Seznamka Harmonie[57] Seznamka Harmonie je doplňkovou službou webu zivotni-energie.cz. Seznamka funguje výhradně prostřednictvím inzerátů. Je určena pro duchovně založené lidi. Stránky seznamky jsou jednoduché. Design není moderní, ale ani kýčovitý SeznamkaAZ[73] Seznamka je orientovaná na seznamování pomocí profilů a fotek uživatelů, ale i inzerátů. Nabízí podobné kategorie inzerátů pro seznámení jako Líbímseti.cz. Na seznamce je hodně falešných účtů za účelem reklamy, které obtěžují uživatele. Na stránkách není žádná bannerová reklama. Seznamka vydělává z poplatků za aktivaci plného účtu. 38

55 2.3. As Is analýza Štěstí.cz[74] Štěstí.cz patří mezi největší české seznamky. Dle jejich stránek má asi uživatelů. Design seznamky hodnotím jako zastaralý a nepříliš povedený. Fotky uživatelů u zobrazení náhodného seznamu jsou příliš malé a pro lepší zobrazení je nutné na fotku kliknout a zobrazit tak profil uživatele. Seznamka vydělává z bannerové reklamy na stránkách Rande.cz[75] Seznamka je orientovaná na seznamování pomocí profilů a fotek uživatelů i pomocí inzerátů (propojením se Seznamka.cz). Rande.cz na svých stránkách uvádí, že má skoro uživatelů. Dochází k prostupnému propojení se Seznamka.cz, která je orientovaná spíše na seznámení pomocí inzerátů. Proti obvyklým kategoriím, kdy lze filtrovat, zda hledáte vážný vztah, flirt či kamarády je zde navíc kategorie pro lidi hledající sex. Na úvodní stránce je odkaz na příběhy lidí seznámených díky seznamce. To dodává seznamce věrohodnost a prestiž a podněcuje uživatele k registraci. Design stránky se jeví jako poněkud kýčovitý. Seznamka nabízí ke stažení mobilní aplikaci. Rande.cz navíc nabízí diskuse a chat pro komunikaci uživatelů Lidé.cz[54] Lidé.cz jsou jednou z největších českých seznamek a léta fungovala i jako přední česká sociální síť. Seznamka je orientovaná na seznamování pomocí profilů a fotek uživatelů. Aktuálně portál Lidé.cz migruje na novou verzi služby. Nová verze je jednodušší, než stará. Poskytuje méně funkcí a Lidé.cz se zřejmě rozhodlo zaměřit se spíše jako seznamka, než sociální sít. Možnosti diskusí a chatu zůstávají. Seznamka umožňuje sledování aktivity uživatelů jinými uživateli. Nová verze má moderní design. Zobrazených uživatelů je spíše méně a jejich fotky jsou velké. Je k dispozici i mobilní verze služby Láskomat[67] Seznamka je orientovaná na seznamování pomocí profilů a fotek uživatelů. Nabízí i kategorie pro seznámení gayů, lesbiček, či bisexuálů. Seznamka má vydařený grafický design. 39

56 2. Analýza a návrh Na stránkách není žádná bannerová reklama. Za výhody oproti běžnému účtu je nutno si připlatit. Je také možnost si připlatit za další služby, například rozbor osobnosti edarling[56] Seznamka určená pro vážné seznámení. Je známá jako seznamka pro bohaté. edarling navrhuje ideálního partnera na základě mnoha kritérií, které jsou třeba zadat již při registraci, proto zabere registrace hodně času. Design seznamky je vydařený a modrá barva pozadí působí seriózním dojmem. Na stránkách není žádná bannerová reklama. Seznamka vydělává z poplatků za aktivaci plného účtu Líbímseti.cz aktuální stav Webový seznamovací portál Líbímseti.cz byl a stále je jedna z největších seznamek u nás. Byl založen v roce 2002 Oldřichem Neubergerem[12]. Časem se seznamka začala rozšiřovat na sociální síť přibývaly další funkcionality (chat, diskuse, místnosti), které posouvaly původní účel dále k širšímu spektru uživatelů. Vrchol slávy zažilo Líbímseti v roce 2008 mělo přibližně uživatelů[13]. V té době také došlo k průniku hackera k zamčeným fotkám uživatelů[14]. S příchodem Facebooku začala popularita o Líbímseti upadat[12] a Líbímseti se začalo pomalu vracet ke svému původnímu účelu seznamce[12]. Přibyly pokročilejší seznamovací funkce. V roce 2010 jej původní majitelé prodali[12] a majitelem je nyní firma S.I.C. spol., s.r.o. Líbímseti se od té doby příliš nevyvíjelo a služba začala po technologické a uživatelské stránce zastarávat Obchodní model Líbímseti vydělává z: 40 Bannerové reklamy. Cílené reklamy (reklamních vzkazů uživateli za použití vhodného algoritmu). Akcí Líbímseti Akce se již tolik nepořádají a mají spíše cíl propagovat, než vydělávat. Poplatků uživatelů za další výhody:

57 2.3. As Is analýza VIP členství VIP členství zpřístupní další funkce a je časově omezeno. Lze jej získat buď vyplnění profilu, registrace pomocí MojeID[76] či platbou převodem nebo pomocí SMS. Kreditů Kredity si mohou koupit uživatelé pomocí SMS a poskytují jim různé výhody, například prioritní zobrazení jejich profilu v náhodných výběrech uživatelů po dobu 24 hodin. Dávají jim tak větší šanci k seznámení. Výhody jsou opět časově omezené Celkový stav služby Zde uvedu především slabé stránky Líbímseti, které by bylo vhodné v budoucnu odstranit: U služeb často chybí snadný návrat o úroveň výše. Některé funkce nejsou dávno používané. Starý a nepříliš hezký design. Zejména reklama často kazí vzhled stránky. Líbímseti nabízí hodně podobných služeb (např. diskuse a otázky). Některé informace jdoucí k uživateli jsou příliš technického rázu. Například login_hp při pokusu o vstup nepřihlášeného uživatele na službu pro přihlášené. Informace uživatel eliminován, která indikuje, že daný profil byl zrušen, také nepůsobí dobrým dojmem. Vyhledávání hledá pouze přesnou shodu (není moc inteligentní). Filtr na hlavní stránce umožňuje uživateli zobrazit uživatele hledající kamarády, vážný vztah i flirt zároveň, nebo jen některé z těchto kategorií. Myslím si, že je to dobře, protože to umožňuje sofistikovanější výběr, než u jiných seznamek. Na rozdíl od jiných seznamek Líbímseti nenabízí seznámení pro užší kategorie: věřící, handicapované, cizojazyčné. Toto však nemusí být ve shodě s jeho zaměřením či strategií. Na Líbímseti je asi dvakrát více mužů než žen (podle informace o aktuálně přihlášených uživatelích). Na stránkách je hodně falešných profilů s reklamou, což odrazuje uživatele. Je potřeba moderní mobilní verze služby. Poměrně hodně uživatelů by o ni mělo zájem a jiné seznamky ji již nabízejí. 41

58 2. Analýza a návrh Co vadí uživatelům Z diskuse uživatelů na téma Proč už na Líbko nikdo nechodí [77], která probíhala na stránkách Líbímseti je patrné, co uživatele odrazovalo a odrazuje od používání Líbímseti: Obtěžující chování některých uživatelů. Nepřehlednost stránek. Falešné profily. Úbytek uživatelů, který znamenal pro mnohé méně zábavy. Starý vzhled stránek. Složitá funkcionalita. Zastaralé funkce Jednotlivé služby Zde popíši jednotlivé služby tak, jak jsou k dispozici v aktuální verzi Líbímseti. Zaměřím se na věci, které by bylo vhodné do budoucna zlepšit. Přihlášení Při registraci je nutné opsat znak z obrázku, tedy CAPT- CHU ochranu proti falešným profilům. Při prvním přihlášení je dostupný odkaz na FAQ k různým otázkám. Odkaz ale vede na celé FAQ místo na odpověď na otázku, u níž je odkaz uveden, to by bylo vhodné změnit. Hry Líbímseti nabízí pro další zábavu uživatelů aktuálně sedm her. Bylo by vhodné z aktuálních dat zjistit, jak moc jsou hry využívány a na základě toho a nákladů spojených s poskytováním her na stránkách, buď další hry přidat nebo službu zúžit či úplně zrušit. Moje Líbímseti Na službě Moje může uživatel zobrazit základní statistiky o svém účtu. Jako například datum registrace, datum posledního přihlášení a počet přihlášení na službu. Dále může zobrazit své přátele a páry uživatele, kteří ohodnotili jeho profil, nebo on ohodnotil jejich. Služba Moje je vlastně něco jako zobrazení profilu uživatele. Uživatel zde může například nastavit vzhled Líbímseti, jaký mu vyhovuje. Uživatel je podněcován k doplnění svého profilu v případě, že některé informace o sobě nevyplnil. Je mu zde nabízena možnost zisku VIP profilu. 42

59 2.3. As Is analýza Hodnocení Zde může uživatel zobrazovat postupně profily jiných uživatelů dle upravitelného filtru a může je hodnotit jedním až deseti body. Body jsou modré, což jistě neurazí, ale možná by stálo za úvahu zvolit jinou barvu, například červenou, která by dle mého více vyjadřovala sympatie k dané osobě. Myslím, že počet desíti bodů pro hodnocení je příliš, stačilo by podle mě méně, například pět. Seznamka Služba seznamka umožňuje seznámení přes zobrazení profilů potenciálních partnerů. Případně je možné využít textové seznamky, která je dostupná i pro uživatele, kteří nemají nahranou profilovou fotku. V textové seznamce jsou nejčastěji inzeráty hledající vážné seznámení (asi 90%). Častěji muž hledá ženu, než žena muže. Druhou nejpočetnější skupinou jsou inzeráty hledající kamarády (kolem 8%). Další skupiny inzerátů již nejsou tolik výrazné. Za zmínku stojí inzeráty hledající tanečního partnera nebo partnera pro výlety či na posezení v kavárně. Uživatelé Služba zobrazuje náhodný výběr uživatelů, který je možno filtrovat. Lze také zapnout filtrování dle vzájemné shody s vaším profilem. Myslím, že zobrazovaný seznam uživatelů je poměrně dobře řešený. Zvážil bych, zda desetinné číslo informující o míře nedožitého posledního roku uživatele neudělat menší, než číslo pro zobrazení počtu dožitých let. Fotky Galerie fotek uživatelů. Je zde nabízeno poměrně hodně možností jaké fotky zobrazit. Nejvíce zobrazované, nejvíce navštěvované a nejvíce komentované aj. U každé možnosti je ještě k dispozici výběr, v jakém časovém horizontu má být zvolený výběr uplatněn: dnes, včera, poslední týden, poslední měsíc. Dle mého není nutné tak detailní výběr, ale není ani překážkou, jelikož základní nastavení filtru je pro aktuální den. Life Stránka slouží k propagacím akcí Líbímseti. Jsou zde aktuální či poslední akce a fotoreporty. Je možné přidat vlastní akci. To není v poslední době využíváno. Tipy na srazy jsou aktuálně prázdné. Odkaz soutěže vede taktéž na prázdnou stránku. V sekci kluby jsou odkazy na klub Líbímseti a další kluby, které nemají s Líbímseti nic společného. Zdá se mi vhodné omezit Life pouze na propagaci vlastních akcí Líbímseti, protože ostatní stránky nejsou prakticky využívány. Diskuze Místo k diskusím uživatelů nad společným tématem. Poměrně hojně využívané uživateli. Jsou nabízeny dva typy: diskuse a otázky, které jsou velmi podobné a liší se jen v detailech. Stálo by tedy za zvážení, zda je nesloučit dohromady. 43

60 2. Analýza a návrh Chat Neboli Místnosti umožňuje komunikovat uživatelům se společnými zájmy. Chatovací místnosti jsou rozděleny do několika kategorií. Hlavními tématy v této službě jsou sex a zábava. Hodně místností je také v kategorii Seznámení a flirt. NVideo Místo, kam uživatelé mohou nahrát svá videa. Některá videa jsou od uživatelů, jiná byla zjevně stažena z jiných stránek (např. z youtube.com). Nahráno je průměrně jedno nové video za dva dny. Je otázkou, zda by nebylo lepší videa přesunout přímo do profilu uživatele, kam lze zatím nahrávat jen fotky, nebo zda je NVideo důležitou službou a má smysl ji zachovat. Blog Zde jsou odkazy na články a weblogy uživatelů. V poslední době je služba hodně zneužívána k reklamě. Články jsou čtené, ale určitě nejde o jednu z hodně využívaných služeb na Líbímseti. Spolužáci Dnes již není služba příliš využívána, naskýtá se tedy otázka, zda ji má smysl do budoucna udržovat. Óčko flirt Óčko flirt využívá asi 500 lidí. Jde o flirt přes video, který je k dispozici jen v určitý čas. Další možnosti pro flirtování jsou buď napsání konkrétnímu uživateli, nebo chatovací místnosti vytvořené za tímto účelem 44

61 Kapitola 3 Realizace V této části popíši, jak probíhal celý projekt, především tvorba business analýzy a jejich jednotlivých dokumentů. Zhodnotím přínos business analýzy pro náš projekt v porovnání s tradičním způsobem tvorby a vyvodím závěry pro další projekty. Na závěr této části popíši a demonstruji, jak udržovat vytvářené artefakty aktuální. 3.1 Jak probíhal projekt V této části popíši, jak probíhal náš projekt a moje business analýza, kterou jsem vytvářel za jeho běhu Průběh projektu Jednou z hlavních myšlenek našeho projektu bylo přeprogramovat stávající řešení Líbímseti na nové technologie. Ze začátku se tedy hodně prototypovalo a naší snahou bylo zjistit, zda jsou dané technologie použitelné. Dle původního záměru jsme začali plánovat v iteracích a pro jednotlivé iterace odhadovat pracnost. Pro odhad pracnosti jsme na hlavně začátku zkusili použít techniku Planning poker[78], kdy členové týmu neodhadují v člověko-hodinách, ale pouze v číslech a výsledný odhad vyjde ze společné debaty. Na základě odhadnutého požadavku, který jsme zvolili jako referenční, jsme pak odhadli požadavky další. Poté jsme v člověko-hodinách odhadli referenční požadavek a zjištěným poměrem mezi story points a člověko-hodinami v našem případě jedna člověko hodina odpovídala třem story points vynásobili story points i u dalších user story a získali tak předpokládanou pracnost. Záhy se ukázalo, že nové technologie, zejména zprovoznění uživatelské komunikace přes Jabber server a ověření uživatele přes MojeID[76] nebude snadné zprovoznit. Bylo to z důvodu nezkušenosti s implementací těchto technologií a jejich špatné dokumentaci. Programátoři (Martin Humeník a Lukáš 45

62 3. Realizace Jeschke) tak dlouhou dobu pátrali po řešení problémů, které málo programátorů vyřešilo nebo své řešení nechtěli veřejně sdílet. Plánování stále pokračovalo v iteracích a byly postupně vyzkoušeny a nasazeny nové technologie, ale začínalo být zřejmé, že implementace MojeID a komunikace přes Jabber server se hodně protáhne. V závislosti na našem postupu tedy nebyl uplatněn domluvený model odměn a tato záležitost byla přesunuta až na konec projektu. Pozitivem nám byl po celou dobu projektu dobrý vztah se zadavatelem (který ve výsledku stejně nemohl přímo rozhodnout o odměně), což jistě prospělo naším diplomovým pracím, které byly (naším) primárním cílem celého projektu. Na konci projektu jsme se zaměřili na funkcionality, které nebyly brzděny postupem implementace MojeID a komunikace přes Jabber server. V této době jsme také dostali první verzi oficiální grafiky, což bylo pozitivum. Negativní bylo, že se grafika za běhu měnila a programátoři tak museli přepracovávat. Požadavky implementovali programátoři na základě mé business analýzy, zejména Product Backlogu. Backend pro komunikaci s databází byl vytvářen zadavatelem a programátoři využívali tohoto API pro svoji implementaci. V průběhu a zejména ke konci byly provedeny code review individuální statické kontroly kódu, kdy jsem hledal chyby a nejasnosti v kódu programátorů (a programátoři sobě navzájem) Více o technice code review lze najít v populární (nejen) programátorské příručce Code Complete[79], kde je také uvedeno, že tento typ kontroly kódu je účinný a zároveň má poměrně malou náročnost na zdroje (oproti dynamickému testování). Záznamy z code review jsou k nalezení jako příloha práce v CD. S použitím mnou vytvořených testovacích scénářů k jednotlivým user stories jsem provedl předakceptační testování vytvořeného řešení. Toto testování mělo za cíl ověřit implementované řešení ještě před tím, než bude podrobeno uživatelským akceptačním testům UAT. Dokumentace testování je k nalezení jako příloha práce v CD. Vytvořené testovací scénáře sloužily také jako základ pro vytvoření plánu uživatelského akceptačního testování UAT. Pro toto testování jsem připravil celkový plán testování, dotazníky a jednotlivé testovací scénáře. Testování řídili, dokumentovali a vyhodnotili oba vývojáři. Dokumentace UAT je k dispozici jako příloha práce v CD. Po odevzdání našich prací nás ještě čeká odstranění chyb nalezených UAT, dodání aktivity diagramů, které byly jedním z požadavků zadavatele, nejsou však součástí této práce, a prezentace našeho řešení zadavateli Průběh business analýzy Nedlouho po začátku projektu jsme se dozvěděli, že firma (resp. zadavatel) zpracovává svoji vlastní specifikaci. Vypadalo to, že moje práce nebude nutná ani nebude přínosem. Po domluvě s vedoucím práce a zadavatelem jsme se 46

63 3.1. Jak probíhal projekt dohodli, že mé zadání práce zůstane takové, jaké je a já se mám zaměřit na business analýzu, jak jsem plánoval. Z tohoto rozhovoru jsem počítal s tím, že naše (moje) analytické zpracování požadavků bude čistě naší záležitostí. Chtěl jsem tedy analýzu provést alespoň interně pro naše potřeby a nebude-li ze strany zadavatele zájem o důkladnější kontrolu výstupů, verifikovat dokumenty alespoň vzájemnou konverzací, při níž ověřím, jestli jsme se oba správně pochopili. Postupem času se ukázalo, že zadavatel má o dokumenty Vision Board a Persony zájem. Také měl zájem o As Is analýzu, kterou jsem zpracovával. Vision Board a Product Backlog tak byly živě diskutovány i verifikovány. Zadavatel požadoval také zpracování activity diagramů pro dokumentaci hlavních funkcionalit, tyto diagramy nejsou součástí zadání a budu zpracovávat po odevzdání této práce. V návaznosti na fakt, že zadavatel nám měl dodat svoji analýzu i návrh GUI, nepovažoval jsem za nutné v té chvíli upřesňovat grafiku. Dodanou specifikaci (a grafiku) jsem plánoval použít i jako zdroj informací pro kontext projektu a zpracování Vision Board a analýzu cílové skupiny uživatelů v Personách. Na začátku jsem se snažil podchytit hlavní myšlenky produktu a zpracoval jsem úvodní verzi Vision Board a Person. Pro lepší pochopení kontextu projektu a business domény seznamek jsem zpracoval As Is analýzu. Podklady pro její tvorbu mi byly informace od zadavatele a především informace získané z mnoha internetových zdrojů. Zpracování As Is analýzy mělo značný význam. Lépe jsem pochopil celou problematiku a byl jsem tak schopen kvalitněji posoudit některé informace a požadavky zadavatele, jako i klást otázky k účelu jednotlivých funkcí a navrhovat řešení v závislosti na cílech projektu a stávajících potřebách. Ze začátku probíhala spíše debata vývojářů se zadavatelem ohledně technologií, které bylo třeba zprovoznit a já se zatím zaměřil právě na zmíněný kontext projektu a cílovou skupinu. Po té, co jsme dostali první verzi oficiální specifikace, jsem začal blíže upřesňovat se zadavatelem uvedené požadavky a jejich priority. Dle mého názoru nebyla specifikace dostatečně detailní (uvedené požadavky nebyly popsány dostatečně) a tak bylo třeba některé věci blíže upřesnit. Na základě toho jsem začal (mým způsobem) vypracovávat a upřesňovat dané požadavky a dokumentovat je v Product Backlogu. Zároveň se ukázalo, některé požadavky nemáme implementovat nebo již neplatí (byly zadavatelem vyřazeny) či budou měněny. To vše jsem se tedy snažil zjistit a upřesnit. Dodaná specifikace zároveň (z důvodu utajení) neobsahovala bližší rozpracování celého kontextu (neobsahovala žádné) ani business cíle projektu. Tyto věci jsem tedy musel zjistit blíže specifikovat se zadavatelem. Výše zmíněné platilo i pro další verze specifikace. 47

64 3. Realizace Jelikož jsme stále nedostávali slíbený návrh grafického rozhraní, bylo třeba požadavky na rozhraní upřesnit na základě dodaných wireframů a nebo specifikovat jednotlivé grafické prvky úplně (nejčastěji na papíře). To jsme před implementací zdokumentovali do wireframů. Zpracování do wireframů prováděli programátoři na základě informací upřesněných se zadavatelem. Zpracování detailního návrhu GUI jsme neprováděli, protože s příchodem oficiální grafiky, která měla přednost, by tento návrh i implementace tohoto rozhraní musely být přepracovány. Zaměřoval jsem se především na specifikaci požadavků, které měly být implementovány v brzké době, a ostatní jsem nechával často otevřené, dokud se jejich priorita nezvýší implementováním důležitějších požadavků, nebo změnou postoje zadavatele. Občas bylo nutné upřesnit i požadavky, které byly právě implementovány, to mělo vždy nejvyšší prioritu, aby programátoři nečekali, nebo neudělali špatné rozhodnutí na základě nesprávných předpokladů. Pro business analýzu i implementaci byl slepým místem čas, kdy měla být dodána (zatím) poslední verze specifikace požadavků od firmy. Na spoustu otázek jsme dostávali odpověď, že to bude popsáno v nové specifikaci. Zaměřili jsme se tedy na zprovoznění některých nových technologií (např. session handleru) a implementaci nefunkčních požadavků, u kterých jsme předpokládali, že nebudou novou specifikací nijak dotčeny. Já se zase v analýze zaměřil na kontrolu a upřesnění kontextu projektu a cílové skupiny tedy zkontrolování, upřesnění a přidání nových informací do Vision Board a Person. Jakmile jsme dostali novou verzi specifikace, začal jsem upřesňovat a upravovat požadavky dle nově získaných informací. Právě na základě této verze specifikace, upřesňování, diskusí se zadavatelem a týmem nad uvedenými požadavky a nad požadavky, které z těchto požadavků a ze vzájemných schůzek vyplynuly, byly zpracovány poslední verze požadavků, které byly zdokumentovány v Product Backlogu. Dle této poslední verze byly požadavky implementovány či jejich implementace upravena. Po té, co nám v závěru byla dodána i první oficiální verze návrhu GUI, jsme upřesnili některé závislé požadavky, zejména týkající se funkcionality Seznámení a Profil. Tato grafika se měnila a ještě se pravděpodobně měnit bude, docházelo tak k časté úpravě požadavků, což vedlo k některým nepochopením jak se zadavatelem, tak s vývojáři při diskusi nad požadavkem, jelikož v grafice byly některé změny, některé ještě nebyly zapracovány a některé části se měli měnit, nakonec se však tyto problémy podařilo vyjasnit. V průběhu projektu byly artefakty průběžně ověřovány diskusemi se zadavatelem nad myšlenkami a informacemi v nich obsažených. Vision Board a Persony, které sloužily jak pro komunikaci ven (směrem k zadavateli), tak dovnitř (směrem k týmu) byly verifikovány po obsahové i formální stránce na společných schůzkách se zadavatelem i na schůzkách našeho týmu. Product Backlog, který sloužil pro komunikaci hlavně dovnitř, byl takto kontrolován jen s týmem. Artefakty jsem průběžně verifikoval i pomocí mnou vytvořených 48

65 3.1. Jak probíhal projekt checklistů. V návaznosti na nově získané informace a nutnost oprav po provedených verifikacích jsem dokumenty okamžitě upravoval a tak je udržoval za běhu projektu aktuální. Schůzek se zadavatelem se účastnili všichni členové týmu, což bylo ve shodě s plánovaným přístupem k analýze, a tak byly informace lépe předávány a požadavky lépe chápány všemi stranami, což pomohlo průběhu celého projektu a business analýze v lepší specifikaci požadavků a uchopení celého kontextu projektu vývojáři Vision Board Na začátku projektu byla vytvořena iniciální verze dokumentu. Tuto verzi jsem postupem času upravoval na základě diskusí se zadavatelem na společných schůzkách a vytvořené As Is analýzy. Průběžně jsem se diskusemi se zadavatelem ujišťoval, že chápeme dobře své myšlenky (hlavně ty jeho) ohledně vytvářeného produktu. Jako zdroj informací mi nepřímo sloužila také specifikace vytvářená zadavatelem. Z uvedených požadavků jsem vlastními úvahami a diskusemi se zadavatelem zjišťoval podstatu a účel (i jiné oblasti) celého produktu. Vision Board jsem verifikoval se zadavatelem na schůzkách a také s týmem, aby bylo dosaženo kýženého oboustranného pochopení. Průběžně jsem artefakt verifikoval pomocí vytvořeného checklistu. Vision Board jsem upravoval, bylo-li potřeba při změně, přidání či odebrání informací shrnujících fakta o projektu nebo na základě provedených kontrol. Dokument jsem se snažil držet rozsahově do velikosti jedné strany A4, což se dařilo až do přidání dalších oblastí (bude popsáno dále). Jazyk Vision Board jsem držel spíše formální s použitím termínů typických pro doménu seznamek a mluvu zadavatele. Pro lepší zapamatování jsem jednotlivé oblasti doplnil volně dostupnými obrázky z galerie S postupem času jsem začal pociťovat, že mnou zvolená struktura Vision Board nepokrývá zcela všechny oblasti, které bych si představoval zejména oblasti týkající se umístění produktu na trhu. Proto jsem se rozhodl artefakt rozšířit dle Romana Pichlera[80] o tyto části: Konkurence (Competition) Zde má být popsáno, jací budou největší konkurenti produktu na trhu a jaké bude mít nový produkt proti nim výhody a nevýhody. Distribuční kanály (Channels) V této části je uvedeno, jakým způsobem se koncový uživatel (či zákazník) dostane k produktu. Tedy jak bude produkt distribuován či nabízen. Zahrnuty by měly být relevantní kanály, to znamená ty, které bude zákazník chtít opravdu využívat, a kterými k němu produkt nejúčinněji dostaneme. 49

66 3. Realizace Obrázek 3.1: Výsledná verze Vision Board 50

67 3.1. Jak probíhal projekt Cena (Price) Cena říká, za co (jaké funkce, rysy či výhody) a kolik je uživatel ochoten platit. Takto Vision Board zachytila i další důležité atributy produktu a poskytla tak celistvý pohled. Na základě[5] jsem přidal do Vision Board ještě část akceptační kritéria popis, co musí být splněno, aby byl projekt považován za úspěšný a doplnil tak další důležitou informaci k pochopení celého projektu. Zároveň se ale množství informací zvětšilo a obsah dokumentu se již nevešel na jednu zamýšlenou stranu A4, ale zvětšil se díky novým oblastem na velikost A3. Stále však poskytoval celistvý a jednoduše a krátce zachycený pohled na produkt. V návaznosti na přidání nových oblastí byl rozšířen i checklist, pomocí kterého jsem dokument verifikoval. Vision Board i s novými oblastmi byla opět verifikována s týmem a zadavatelem a zkontrolována pomocí upraveného checklistu. Výslednou Vision Board můžete vidět na obrázku zde 3.1. Všechny vytvořené verze Vision Board jsou k nalezení v přiloženém CD Persony Na začátku jsem vytvořil iniciální persony z informací, které jsem měl o Líbímseti a mých předpokladů. Persony jsem vytvořil čtyři: dva muže a dvě ženy reprezentující věkové kategorie kolem osmnácti a třiceti let. Za hlavní uživatelskou skupinu jsem považoval, ve shodě s tím, jak bylo Líbímseti známé, mladší kategorii hledající partnera (na vážný vztah či flirt) a zároveň zábavu. Do dokumentu jsem doplnil informaci o hlavní cílové skupině. Po bližší diskusi se zadavatelem jsem zjistil, že hlavní cílová skupina uživatelů se má pohybovat spíše kolem třiceti let a touží po vážném vztahu, zatímco zábava na stránkách pro ně není až tak důležitá. K tomu bych rád uvedl, že dle průzkumu seznamky Leyter.com z roku 2012 o chování českých uživatelů na seznamkách, odkazovaném zde[53], se průměrný věk uživatele pohybuje mezi devatenácti a třiceti lety (což může být mírně zkreslené číslo, jelikož právě o věku, se nejčastěji lže) a dle[61] průměrný věk uživatelů stále stoupá. Úmyslem zadavatele tedy bylo zaměřit se právě na kategorii, která má být v budoucnu na seznamkách tou nejsilnější a jistým způsobem tak ustoupit z předchozího směřování Líbímseti, coby sociální sítě pro mladé lidi. V návaznosti na naší diskusi a informacích získaných z As Is analýzy jsem za další důležitou skupinu začal považovat uživatele nad padesát let, hledající typicky vážný vztah. Těchto uživatelů začalo na seznamkách hodně přibývat a dle[61] začínají mít i senioři velmi výraznou pozici na trhu seznamovacích portálů. 51

68 3. Realizace Obrázek 3.2: Výsledná verze primární persony Persony jsem upravil na základě nově získaných poznatků a rozšířil je o dvě persony reprezentující uživatele starší padesáti let. S postupem projektu a především s dalšími informacemi a požadavky jsem uznal za vhodné a rozšířil Persony o stakeholdery zákazníka, jak radí[81]. Po tomto rozšíření jsem narazil na cenný názor Romana Pichlera[15], že máme-li person více, je vhodné vybrat primární personu. Považoval jsem to za dobrý nápad vzhledem k tomu, že produkt by měl odpovídat především potřebám primární persony. Jako primární personu jsem zvolil ženu kolem třiceti let hledající vážný vztah (protože ženy hledají vážný vztah na seznamkách častěji, než muži[62]). Primární personu si můžete prohlédnout na obrázku 3.2. Přidáním zákazníkových stakeholderů se rozsah dokumentu zvětšil z jedné strany A4 na jeden a půl strany formátu A3, byla však zachována jednoduchost, celistvost a pochopitelnost celého dokumentu. Postupem času jsem s novými informacemi persony dále upravoval. Jako zdroj informací mi nepřímo posloužila také specifikace dodaná zadavatelem. Z dokumentovaných požadavků jsem se vlastními úvahami a diskusemi se zadavatelem snažil zjistit, pro koho je nový produkt určen a jaké potřeby uživatelů a zákazníka má naplnit. Persony jsem pojmenovával podobně, jako 52