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

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

Č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

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.

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 2014

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

Č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.

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

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

Obsah Úvod Agilní business analýza . . . . . . . . . . . . . . . . . . . . . . . . . Webové seznamovací portály jako sociální sítě . . . . . . . . . . . . . Líbímseti.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 3

1 Popis, konkretizace cíle 1.1 Rozbor zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Co není součástí práce . . . . . . . . . . . . . . . . . . . . . . . 1.3 Rozdělení odpovědnosti na projektu . . . . . . . . . . . . . . .

5 5 7 7

2 Analýza a návrh 11 2.1 O business analýze . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Návrh zpracování business analýzy . . . . . . . . . . . . . . . . 21 2.3 As Is analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3 Realizace 45 3.1 Jak probíhal projekt . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2 Zhodnocení business analýzy . . . . . . . . . . . . . . . . . . . 56 3.3 Jak udržovat artefakty aktuální . . . . . . . . . . . . . . . . . . 60 Závěr 75 Přínos práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Co mi práce dala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Splnění zadání práce . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Literatura

79

A Seznam použitých zkratek

87

B Obsah přiloženého CD

89

xi

Seznam obrázků 1.1

Rozdělení odpovědnosti na projektu . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6

Waterfall model . . . . . . . . . . Scrum model . . . . . . . . . . . Agilní vs Waterfall trojimperativ Zvolená struktura Vision Board . Formát persony . . . . . . . . . . Ukázka persony . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

15 20 21 26 28 28

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13

Finální Vision Board . . . . . . . Výsledná verze primární persony Výsledná podoba Person . . . . . Wireframe Seznámení . . . . . . Vision Board verze 0.9 . . . . . . Vision Board verze 1.0 . . . . . . Vision Board verze 1.1 . . . . . . Vision Board verze 1.2 . . . . . . Vision Board verze 1.3 . . . . . Persony verze 0.9 . . . . . . . . . Persony verze 1.0 . . . . . . . . . Persony verze 1.1 . . . . . . . . . Persony verze 1.2 . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

50 52 53 56 62 62 63 64 65 66 67 68 69

xiii

8

Seznam tabulek 2.1

Řízení rozsahu na tradičním a agilním projektu . . . . . . . . . . .

xv

22

Ú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

Ú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

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ž 250 000 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

Kapitola

Popis, konkretizace cíle 1.1 1.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

1

1. Popis, konkretizace cíle 2. Persony – Persony1 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.

1.1.2

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.

1.1.3

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

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.

1.1.4

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. 1.1.4.1

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 1.1. 7

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).

1.3.1

Š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: 1. Vision Board – reprezentující vizi a celkový kontext projektu, 8

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).

1.3.2

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

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.

1.3.3

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

Kapitola

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.

2.1.1

Úč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

2

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]: • 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é. 12

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

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í.

2.1.2

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. 2.1.2.1

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

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

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

2.1. O business analýze 2.1.2.2

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

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

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

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. 2.1.2.3

Ří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

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 2.2.1

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

2. Analýza a návrh Řízení rozsahu Waterfall Agile Připravte plán řízení rozsahu. Ujistěte se, že tým chápe vývojový framework a proces zvoleného agilního přístupu. Připravte Prohlášení rozsahu pro- Facilitujte/veďte plánovací schůzky jektu. 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. Vytvořte hierarchickou strukturu Facilitujte/veďte plánovací schůzky prací (WBS). tak, aby tým mohl vytvořit plán, který ukazuje rozdělení práce napříč několika iteracemi. Používejte systém pro řízení změn a Product Backlog patří zákazníkovi – pokuste se tak předejít nárůstu roz- změny v něm se dějí na jeho podnět sahu. 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. Řiďte plnění jednotlivých úkolů a Nechte členy týmu organizovat si své tak předcházejte nebo napravujte denní úkoly a facilitujte konverzace zvyšování rozsahu na úrovni jednot- se zákazníkem, aby se předešlo zbylivých úkolů teč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

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.

2.2.2

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

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

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.

2.2.3

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. 2.2.3.1

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

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. 2.2.3.2

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ů. 2.2.3.3

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

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.

2.2.4

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í. 2.2.4.1

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

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í. 2.2.4.2

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

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ů. 2.2.4.3

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.

2.2.5

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. 2.2.5.1

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

2. Analýza a návrh • Jako (As an ) • chci (I want ), • abych <dosáhl nějakého benefitu> (So that ). 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

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

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. 2.2.5.2

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

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í.

2.2.5.3

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 2.3.1

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

2. Analýza a návrh

2.3.2

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.

2.3.3

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

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 www.katolik.cz pro věřící[59].

2.3.4

Uživatelé

Průměrný věk u uživatelů seznamek u nás je 19-30 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

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. Seznámit se musejí její uživatelé už napřímo. 36

2.3. As Is analýza

2.3.5

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í.

2.3.6

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. 2.3.6.1

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

2. Analýza a návrh 2.3.6.2

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. 2.3.6.3

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 emailu pěti přátel. 2.3.6.4

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. 2.3.6.5

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ý. 2.3.6.6

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

2.3. As Is analýza 2.3.6.7

Štěstí.cz[74]

Štěstí.cz patří mezi největší české seznamky. Dle jejich stránek má asi 100 000 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. 2.3.6.8

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 400 000 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ů. 2.3.6.9

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. 2.3.6.10

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

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. 2.3.6.11

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.

2.3.7

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ě 250 000 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. 2.3.7.1

Obchodní model

Líbímseti vydělává z: • 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: 40

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é. 2.3.7.2

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

2. Analýza a návrh 2.3.7.3

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. 2.3.7.4

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 CAPTCHU – 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

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

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

Kapitola

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.

3.1.1

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

3

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.

3.1.2

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

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

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

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.

3.1.3

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 http://openclipart.org/. 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

3. Realizace

Obrázek 3.1: Výsledná verze Vision Board

50

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.

3.1.4

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

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

3.1. Jak probíhal projekt

Obrázek 3.3: Výsledná podoba Person

53

3. Realizace uživatele seznamek, tedy ne jmény, ale jejich přezdívkami, abych je více ztotožnil s projektem. Persony pro větší názornost a lepší zapamatování doplnil volně dostupnými obrázky z http://openclipart.org/. Persony jsem upravoval po získání a zapracování nových informací a také v návaznosti na provedené verifikace. Takto jsem je udržoval aktuální za běhu projektu. Persony jsem verifikoval na společných schůzkách se zadavatelem a to jak vzájemné pochopení myšlenek, tak strukturu a obsah celého dokumentu. Jejich strukturu a obsažené informace jsem kontroloval také s týmem na společných schůzkách a pomocí sestaveného checklistu. Výslednou verzi dokumentu Persony lze vidět na obrázku 3.3. Dokument můžete naléze na přiloženém CD.

3.1.5

Product Backlog

Plánovaný koncept zpracování Product Backlogu se výrazně změnil s faktem, že nám zadavatel poskytne svoji specifikaci a grafiku. V této chvíli jsem vytváření wireframů jako specifikaci GUI zavrhl a plánoval jsem diskutovat výhradně nad dodanou grafikou. Požadavky z dodané specifikace jsem chtěl přepracovat, případně upřesnit pro naše účely a zdokumentovat do struktury Product Backlogu popsané dříve. Výslednou podobu dokumentu jsem chtěl verifikovat s týmem na společných schůzkách a pomocí checklistů. Se zadavatelem jsem se plánoval pouze ujišťovat, zda oba chápeme požadavek stejným způsobem a více s ním dokument neverifikovat, jelikož o něj, dle našeho rozhovoru, nejevil zájem. Jakmile dorazila první verze specifikace od zadavatele, začal jsem zpracovávat požadavky do Product Backlogu a upřesňovat je se zadavatelem. Jak jsem se zmínil v části o průběhu celé business analýzy., dodaná specifikace obsahovala některé části, které jsme neměli implementovat nebo měli implementovat jen z části. Toto platilo také o některých požadavcích. Jelikož se oficiální specifikace neupravovala dle nových poznatků a s postupem upřesňování jednotlivých požadavků a vzniku nových, stal se Product Backlog opravdu potřebným – zejména pro vývojáře. Požadavky jsem zpracovával nejčastěji po příchodu nových verzí specifikace, protože ty nejvíce měnily, co má být obsahem projektu. Požadavky jsem se snažil upřesnit tak, abychom věděli, co budeme vyvíjet v další iteraci a dohodli se na tom se zadavatelem. Domluvy se zadavatelem nebyly tak formální, jak bylo na začátku předpokládáno, tedy nedocházelo k ocenění požadavků ze strany zadavatele, a to z již uvedených důvodů. Pokud jsme zjistili, že některý právě implantovaný požadavek není zcela jasný, snažili jsme se jej ihned upřesnit a dodatečné informace zdokumentovat v Product Backlogu. Požadavky, které nebyly tak důležité, jsem specifikoval méně nebo jejich specifikaci nechával na dobu, kdy budou profitnější poža54

3.1. Jak probíhal projekt davky implementovány (a ty méně prioritní měly přijít na řadu k implantaci) či důkladně specifikovány a teprve poté je specifikoval. Požadavky, které byly v průběhu projektu vyřazeny, jsem z Product Backlogu neodstraňoval, ale přeškrtnul jsem je, aby bylo zjevné, že již neplatí, a případně připsal důvod jejich vyřazení. User stories jsem doplňoval akceptačními kritérii pro přesnější definici požadavku. Příbuzné user stories jsem organizoval do epiců, které udávaly větší oblast implementace (např. Profil, Seznámení, Chat aj.), abych usnadnil orientaci vývojářům a zároveň propojil user stories s komplexnějšími požadavky. V průběhu projektu se ukázalo, že některé user story jsou příliš velké a měly by být rozděleny na několik menších. Bylo to z důvodu lepšího pochopení i pro lepší kontrolu postupu. Je lépe mít uzavřeny tři požadavky z deseti plánovaných, než otevřený jeden ze tří. Jednalo se například o user story zachycující požadavek na registraci uživatele. Registrace mohla být povedena buď standardním způsobem, tedy zvolením uživatelského jména (přezdívky) a hesla, nebo pomocí údajů z Facebooku, Google či identifikátoru MojeID. Požadavek jsem tak rozdělil na čtyři menší, z nichž každý dokumentoval registraci jiným způsobem. Zároveň byla zachována podstata user story a to to, že přináší přidanou hodnotu tomu, pro něž je navržena. Do kolonky Jako jsem v případě nefunkčních požadavků, z nichž profitovali především stakeholdeři firmy S.I.C. vkládal přímo název persony, u požadavků, jejichž primárním adresátem byl uživatel jsem tento postup nepoužíval, ale napsal jsem normálně: „Uživatel“. Jelikož jsme stále nedostávali grafiku, bylo třeba ujasnit grafickou podobu – alespoň základní rozvržení – některých požadavků. Tu jsme upřesňovali na základě dodaných materiálů, aktuální podoby Líbímseti a diskusí se zadavatelem. Cennými nástroji zde byla tužka a papír. Výslednou podobu potom vývojáři dokumentovali pomocí wireframů. Ke konci projektu jsem udělal ještě drobnou, ale vhodnou úpravu Product Backlogu – přidal jsem každé user story atribut grafika, kde jsem zaznamenal, kde se nalézá dokumentace grafického rozhraní user story. Po dodání první verze oficiální grafiky od zadavatele, jsme začali upřesňovat dotčené požadavky s ohledem na grafický design. Dodaná grafika hodně věcí objasnila, ale jelikož se několikrát změnila a ještě se měnit pravděpodobně bude a požadavky byly právě implementovány, bylo třeba upřesňovat více a okamžitě s dodáním nové verze. Product Backlog jsme nakonec k dokumentaci chyb nepoužili. Bylo to jak z důvodu našeho postupu, tak rozhodnutím udělat velká testování až na závěr projektu. User stories jsem průběžně na základě diskusí se zadavatelem prioritizoval a validoval oproti Vision Board a Personám jakožto stěžejním dokumentům projektu. Při vzájemných diskusích se zadavatelem jsem se ujišťoval ve vzájemném pochopení požadavků a celý dokument jsem kontroloval s týmem na schůzkách týmu. Sám jsem potom při modifikacích dokumentu verifikoval do55

3. Realizace

Obrázek 3.4: Vytvořený wireframe pro epic Seznámení

tčené požadavky pomocí vytvořeného checklistu a když již se informace moc neměnily, provedl jsem závěrečnou kontrolu celého dokumentu pomocí zmíněného checklistu. Při potřebě změn, ať již na základě nových informací či provedených kontrol jsem dokument upravovat, aby byl stále aktuální. Product Backlog i s Constraints (požadavky – omezeními, kladenými na celý produkt) a definicí implementovaného požadavku jsem zařadil do plánovacího Excel dokumentu našeho týmu pro tento projekt. Uvedený dokument SIC_diplomka_plan.xlsx je k nalezení jako příloha práce na CD. Wireframy jsou také k dispozici v přiloženém CD. Příklady některých user stories jsou uvedeny v části Realizace – Jak udržovat artefakty aktuální – Product Backlog 3.3.4.

3.2

Zhodnocení business analýzy

V této části zhodnotím přinos mnou zpracované business analýzy pro náš projekt Redesign Líbímseti. Uvedu přínosy, výhody a nevýhody zvoleného agilního způsobu proti tradičním metodám, nejprve v kontextu našeho projektu a potom dám i doporučení pro projekty další. 56

3.2. Zhodnocení business analýzy

3.2.1 3.2.1.1

Na projektu Celkově

Zpracovaná business analýza měla velký přínos pro náš tým. Bylo to především díky zpracovanému Product Backlogu. Ten dával jasnou představu, co se má vyvíjet (část user story chci a akceptační kritéria), pro koho (část user story Jako) a jaké to má opodstatnění (část user story abych). Testovací scénáře pak sloužili k verifikaci požadavků na předakceptačních a uživatelských akceptačních testech UAT. Product Backlog byl vývojáři oceňován pro své jednoduché zpracování požadavku na jednom řádku (v Excelu) a nebyl tak problém zobrazit větší množství požadavků (user stories), user story vhodně vyfiltrovat či se podívat na detail (akceptační kritéria či testovací scénář) konkrétní user story. Vision Board a Persony zase dávaly jasnou představu, proč a pro koho je požadavek tvořen a poskytovaly nadhled nad celým projektem. Díky nim bylo možné validovat jednotlivé požadavky, zda jsou relevantní a jakou mají mít prioritu. Persony sloužily také při rozhodování o výběru testerů pro UAT. Business analýza, hlavně zpracování požadavků v Product Backlogu, byla poznamenána čekáním na vstupy od zadavatele – na jeho specifikaci požadavků a grafický návrh, které měly pochopitelně přednost před naší analýzou a bylo třeba vždy naši analýzu upravit dle nových informací z těchto vstupů a následného diskutování a upřesňování se zadavatelem. Jelikož jsem business analýzu dělal agilním způsobem poprvé, je zde jistě spousta míst ke zlepšení. Je vhodné se již od začátku pečlivěji věnovat epicům jakožto větším celkům požadavků. Správnou definicí epiců a organizací user stories do nich lze Product Backlog velmi zpřehlednit, špatnou zase učinit nepřehledným. Rozřazení user stories do epiců jsem se začal věnovat až trochu později a tak jsem v průběhu několik user stories (kolem pěti) přesunul do jiných epiců, jelikož jsem poznal, že jsem je neumístil správně. Také by bylo vhodné se pečlivěji věnovat zapracováním nefunkčních požadavků ke konkrétním user stories jako akceptační kritéria, jak je například uvedeno zde[45]. Požadavek by tak byl ještě důkladněji specifikován a nebylo by třeba budoucího upřesnění při vzniklých problémech a také bylo by možno lépe odhadnout a určit jeho prioritu. Ze zkušeností z tohoto projektu vyplívá, že je téměř nutné upřesnit alespoň základní grafické prvky, i když má přijít oficiální grafika. Ujasní se tím spousta nejasností kolem implementace požadavků. Příště tomu budu věnovat jistě větší pozornost. Do budoucna bych také zvážil užší propojení person a user stories, jak radí Roman Pichler zde[15]. Místo Jako použít Jako , tedy explicitně uvést, potřeby jaké persony má primárně daný požadavek uspokojit. Tento postup by usnadnil prioritizaci požadavku na základě důležitosti persony pro projekt. Na našem projektu jsem to nechtěl v prů57

3. Realizace běhu zavádět, abych nezpůsobil zmatky, a také by to stálo nemalé množství času a analýz. Tak jsem persony použil pouze u nefunkčních požadavků pro stakeholdery firmy S.I.C. V případě netajeného projektu bych možná zvážil pro lepší identifikaci cílové skupiny pomocí person alespoň menší dotazování koncových uživatelů a důkladnější pohled na data o uživatelích, který nám nebyl z vnitřních důvodů poskytnut. Co se ukázalo jako velmi dobré, bylo rozpadnutí jednotlivých požadavků na co nejmenší user stories. Ty pak byly lépe odhadnutelné, plánovatelné i prioritizovatelné. Co se týče business analýzy jako celku: Nepředpokládejte, že co platilo, nebo je obecným míněním si musí myslet i zadavatel. Informace o projektu je třeba prodiskutovat a explicitně si potvrdit že se chápete. Ať už se týkají uchopení celého projektu nebo konkrétního atributu požadavku. Nestane se vám potom, že v průběhu projektu implementujete něco, co tak zadavatel vůbec nechtěl. V našem případě šlo o špatné uchopení cílové skupiny uživatelů a chybu v popisu Person jsme odstranili zavčasu, v pozdější fázi by podobné pochybení mohlo mít vážnější následky. 3.2.1.2

Porovnání s tradiční business analýzou

Business analýza prováděná tradičním způsobem bývá daleko rozsáhlejší, než agilně vedená business analýza. To se potvrdilo i na našem projektu. Zejména dokumentace kontextu projektu ve Vision Board a cílové skupiny uživatelů a stakeholderů v Personách byly jednoduchými a stručnými dokumenty plnící svůj účel. Zajistily dobré pochopení projektu a zadavatelových myšlenek. Product Backlog byl přínosný pro svůj jednouchý popis požadavků. Dokumenty tradiční business analýzy vypracovávané za stejným účelem, např. vision and scope dokument dokumentující vizi a rozsah projektu a specifikace požadavků (SRS) bývají mnohem rozsáhlejší dokumenty a odrazují tak zákazníka a vývojáře od čtení. Například při tvorbě SRS (tradičním způsobem) pro mou bakalářskou práci (odkaz) jsem se zadavatelem (vedoucím práce) komunikoval výhradně pomocí mapy stránek vytvářeného řešení a seznamu use casů. Celou specifikaci nechtěl zadavatel číst, jelikož byla opravdu rozsáhlá – čítala více než sto stran. Výhodou agilního přístupu je také větší zapojení členů týmu do samotné analýzy, požadavky jsou tak snadněji upřesňovány, jelikož vývojáři (či jiné role) najdou typicky další nejasnosti dosud neobjevené analytikem (Product Ownerem) a je lepší povědomí o celém kontextu projektu i jednotlivých požadavcích. Z druhé strany se mi nedařilo specifikovat některé user stories do patřičného detailu, takže potřebovaly další upřesnění. To bylo ale způsobeno spíše tím, že jsem dělal analýzu tímto způsobem poprvé a zkušenější analytik by se jistě takovýmto chybám vyvaroval. 58

3.2. Zhodnocení business analýzy Ačkoli na tomto projektu nebylo ve výsledku použito agilní dodávání výstupů, tj. kompletně akceptovatelné požadavky dodávané v iteracích, myslím si, že agilní přístup k vedení projektu a business analýze je v prostředí měnících se požadavků a priorit vhodným způsobem uchopení daného projektu. Tradiční přístup je naopak vhodný pro projekty, kde lze zachytit všechny důležité požadavky v počáteční fázi bez rizika velkých změn a implementovat potom dané řešení dle detailně provedené analýzy. Celkově tedy použití agilního přístupu k business analýze ušetřilo čas, usnadnilo komunikaci a ulehčilo změny v samotné analýze. Byla to tedy pro zpracování business analýzy správná volba, než kdybychom v tomto případě zvolili klasický přístup.

3.2.2

Doporučení pro další projekty

Na základě získaných informací a zkušeností z našeho projektu bych rád uvedl několik poznatků pro použití agilní business analýzy na projektech. Máte-li projekt FTFP, použijte Waterfall nebo jiný příbuzný model pro vedení projektu a zpracování business analýzy. Nic jiného vám konec konců nezbyde. Je-li zadání projektu nejasné nebo není zákazník schopen dobře popsat své potřeby a požadavky, zkuste mu navrhnout agilní způsob řízení jeho projektu a dobře jej s ním ujasněte, co obnáší. Chcete-li vést projekt agilně, je vhodné vést agilně i business analýzu, tradiční business analýza není uzpůsobena velkým úpravám a měnícím se požadavkům. Je třeba se zákazníkem dobře vyjasnit zamýšlený model dodávky a přizpůsobit tomu model platby či odměn za vaši práci. Výhodný model pro obě strany je Story Point model[27], výhodný pro vás, ale nevýhodný pro zákazníka bude kontrakt TM a nevhodný typ smlouvy pro vás (a ve výsledku i pro zákazníka) je FTFP, protože popírá základní principy agilního vývoje. Dobře ujasněte se zákazníkem, že rozumí agilnímu přístupu, abyste po čase, kdy se snažíte plánovat a vést projekt a business analýzu agilně, odpovídáte na změny, nenarazili na to, že zákazník si stále upravuje svůj ganttův diagram Waterfall projektu. Spousta lidí může říci, že to zní výborně a že je to skvělá myšlenka a pojďme to tak udělat, ale stejně skončíte u otázky: „A co nám za to teda dodáte?“ Pro implementaci agilního přístupu je důležitý jak zákazník, tak tým. Bez něj nikdy Agile praktikovat nemůžete. Zavedením agilního přístupu v týmu vede k vyvedení členů z konformity a požaduje univerzálnost, to někteří členové nemusí zvládnout, jak uvádí ze svých zkušeností Jaroslav Gergic[23]. V případě použití agilní business analýzy zvažte, jak budete informace a požadavky zpracovávat. V začátcích může být lepší dané artefakty (například Persony) zpracovávat více technicky a až potom, co si na ně vývojový 59

3. Realizace tým zvykne, použít graficky či textově výraznější formu a méně technické zpracování[39]. Agilní metodiky počítají s přizpůsobením podmínkám projektu, nemusíte je tedy implementovat naprosto přesně, ale lze je uzpůsobit dle svých potřeb, nezapomínejte však na jejich principy. V případě použití agilní business analýzy na klasickém projektu; lze to, ale vývojový tým nemusí být zvyklý na zpracování požadavků pomocí user stories. Potom je lepší od toho upustit, nebo user stories upřesňovat pomocí features nebo use casů[42], dle zvyklostí týmu. Celkově: volba přístupu k vedení projektu i business analýze záleží na vás, vašem týmu a zákazníkovi, jeho zvyklostech a představách. Vhodné použití vývojového modelu vám může leccos usnadnit, nevhodné naopak přitížit.

3.3

Jak udržovat artefakty aktuální

V této části popíši, co byste měli udělat proto, aby byly vytvářené artefakty po celou dobu projektu aktuální a poskytovaly tak správný pohled na vytvářené řešení.

3.3.1

Obecně

Aby byly artefakty aktuální, je třeba: • Získávat nové informace a mít k dispozici ty aktuální. • Kontrolovat zaznamenávané informace a vytvářené artefakty. • Upravovat artefakty na základě nových informací a provedených kontrol. • Verzovat artefakty. Toto jsou ve zkratce čtyři základní činnosti, bez kterých se neobejdete. Zdroje informací pro vás mohou být: • Informace od zadavatele. • Statistiky. • Analýza domény. • Analýza stávajícího stavu (As Is analýza). • Analýza koncových uživatelů. • Analýza zainteresovaných stran (stakeholderů). • A jiné. 60

3.3. Jak udržovat artefakty aktuální Získané informace je třeba promyslet, udělat si na ně vlastní názor a zkonzultovat se zadavatelem. Teprve, když jste si jistí, že jste získanou informaci dobře zpracovali a víte, jaký dopad bude mít na aktuálně zdokumentovaná fakta, můžete začít dotčené artefakty upravovat. Je vhodné, můžete-li, zanalyzovat informaci v širším kontextu, abyste věděli, jaký bude mít skutečně dopad. Netravte však analýzou dlouhé dny. Co je důležité, se časem přihlásí o slovo. Například zjistíte-li, že největší množství uživatelů se pohybuje okolo věku 55 let, proberete tuto informaci se zadavatelem a ujistíte se vzájemně, že opravdu cílí na tuto největší skupinu. Víte, že by mělo dojít k úpravě Vision Board a Person (v případě propojení jednotlivých person a user stories také k úpravě Product Backlogu). Rozhodnete, jakým způsobem budou nové informace zaneseny do těchto artefaktů, a změny zanesete. Pokud se unáhlíte a začnete dokumenty upravovat ihned, hrozí vám, že je budete upravovat několikrát a zdokumentované informace tak mohou být chaotické. Nejedná-li se o úplný začátek projektu, tedy o fázi, kdy se ještě nevyvíjí, zachováte starou verzi dokumentu a vytvoříte novou obsahující právě zdokumentované informace. Takto zajistíte zpětnou dohledatelnost informací (dokumentů), podle kterých se vyvíjelo k určitému datu. Kontrolami informací zde myslím zejména: • Diskuse se zadavatelem. • Verifikace artefaktů se zadavatelem. • Diskuse s týmem. • Verifikace artefaktů s týmem. • Kontroly artefaktů pomocí checklistů a best practicies. • Review (individuální) či inspekce (kolektivní) kontroly artefaktů jinými členy týmu. První čtyři uvedené způsoby jsou naprosto nezbytné. Kontrola vzájemného pochopení požadavku vámi, zadavatelem i týmem je naprosto klíčová pro dodání business hodnoty zákazníkovi. Pátý způsob velmi doporučuji, můžete tak odhalit mnoho chyb. Poslední způsob je velmi účinný, avšak vyžaduje minimálně jednu osobu zkušenou v agilní business analýze. Kontrolami zajistíte, že vytvářené artefakty budou obsahovat všechny potřebné informace, a jen tak, zachováte jednoduchost a přehlednost zaznamenaných informací a artefaktů jako takových. Dokumenty je vhodné verzovat v momentě větších úprav a v případě Product Backlogu také na konci iterace, aby bylo jasné a zpětně dohledatelné, jaké požadavky byly aktuální k určitému datu. Máte-li k dispozici pokročilejší 61

3. Realizace

Obrázek 3.5: Vision Board verze 0.9

Obrázek 3.6: Vision Board verze 1.0

systém pro evidenci issue (ve vašem případě user stories), lze této možnosti využít pro verzování na úrovni jednotlivých user stories. Mění-li se implementovaný požadavek, je třeba uchovat původní verzi pro vývojáře, aby věděli, co má být vyvinuto. Dále je potřeba zachytit změny. Buď do nové verze Product Backlogu, nebo umožňuje-li to váš nástroj, jako novou verzi user story. Vždy má být jasné, co se má vyvinout a o čem se bude jednat se zákazníkem. Příklady, jak se jednotlivé artefakty v průběhu času mění, a jak je udržovat aktuální jsou k dispozici v dalších podkapitolách. 62

3.3. Jak udržovat artefakty aktuální

Obrázek 3.7: Vision Board verze 1.1

3.3.2

Vision Board

Zde popíši, jak se v průběhu našeho projektu měnil artefakt Vison Board. Na začátku byla vytvořena iniciální verze 0.9, která zachycovala hlavní myšlenky produktu. Základní potřeby a cíle řešení – funkční, grafický i technologický redisign aplikace, který by zpříjemnil uživatelům její užívání. Jako cílovou kategorii uživatelů jsem zde uvedl uživatele okolo 20 let hledající vážný vztah, flirt, kamarády i zábavu, což se později ukázalo jako chybné. Do části Hodnota jsem uvedl přínosy, které bude mít náš tým z tohoto projektu, což také nebylo správně (vzhledem k zaměřenosti Vision Board na zákazníka – zadavatele), což se později ukázalo, jak popíši dále. Vstupy, z kterých jsem vycházel pro iniciální verzi Vision Board, byly získané informace o Líbímseti a jeho historii a úvodní schůzky se zadavatelem. Iniciální verzi Vision Board můžete vidět na obrázku 3.5. Po upřesnění cílové skupiny uživatelů se zadavatelem byla vytvořena verze 1.0 (jak lze vidět na obrázku 3.6), která již uváděla správnou cílovou skupinu – uživatele od 15 do 40 let hledající vážný vztah. Tato verze byla doplněna o obrázky pro lepší orientaci a zapamatování jednotlivých oddílů. Po té byla v další verzi (1.1 – viz obrázek 3.7) přidána akceptační kritéria projektu. Akceptační kritéria dávala další cenou informaci o projektu, a proto jsem je zde chtěl uvést. Akceptační kritéria byla ujasněna se zadavatelem. S postupem času jsem začal pociťovat potřebu doplnit do Vision Board oblasti týkající se umístnění produktu na trhu. Dle Romana Pichlera[80] jsem 63

3. Realizace

Obrázek 3.8: Vision Board verze 1.2

tedy přidal části: Konkurence, Distribuční kanály a Cena. Zanalyzoval jsem informace potřebné pro tyto části. K tomu mi posloužila As Is analýza a diskuse se zadavatelem. Zároveň jsem na základě kontroly pomocí checklistu přidal do oddílu Hodnota informace o tom, jakým způsobem bude z produktu profitovat zákazník. Verzi Vision Board 1.2 můžete vidět na obrázku 3.8. Taktéž jsem doplnil checklist, který mi sloužil ke kontrole Vision Board o body pro ověření nově přidaných částí. Na závěr jsem ve verzi 1.3 (jak lze vidět z obrázku 3.9) ještě doplnil další uchopené informace, které jsem probral se zadavatelem. Provedl jsem velkou kontrolu pomocí checklistu a zlepšil jsem celkový design a přehlednost dokumentu. Byly doplněny informace k částem Konkurence, kde jsem lépe srovnal bu64

3.3. Jak udržovat artefakty aktuální

Obrázek 3.9: Vision Board verze 1.3 – finální podoba

65

3. Realizace

Obrázek 3.10: Persony verze 0.9

doucí produkt s konkurenty na trhu, a cena, kde jsem přidal další body popisující, jakým způsobem bude zákazník vydělávat na budoucím řešení. Zároveň jsem z části Hodnota odstranil informace týkající se přínosu projektu pro tým a ponechal pouze ty týkající se zákazníka. Toto jsem udělal v souladu s tím, že Vision Board má být orientovaný na zákazníka. Tato úprava vycházela zejména z kontroly artefaktu pomocí checklistu. Tento Vision Board lze již považovat za finální. Měnit by se měl jen na základě změny situace na trhu či názorů zadavatele. Jak jsem právě popsal, byl Vision Board v průběhu projektu upravován dle získaných informací a kontrol. Byly řízeny jeho verze. Na ukázkách lze vidět, jak se artefakt v průběhu projektu měnil.

3.3.3

Persony

V této části popíši, jak jsem v průběhu našeho projektu upravoval dokument Persony a udržoval jej tak aktuální. 66

3.3. Jak udržovat artefakty aktuální

Obrázek 3.11: Persony verze 1.0

Na začátku jsem vytvořil úvodní verzi (0.9 – viz obrázek 3.10) dokumentu. Pro vytvoření této verze jsem vycházel z informací, které jsem měl o seznamkách, především Líbímseti a jeho směřování, a poznatků z diskusí se zadavatelem. Předpokládal jsem, že se Líbímseti bude orientovat na mladší uživatele, kteří vyhledávají vážný vztah, flirt či kamarády a také se rádi na stránkách baví. Takto bylo Líbímseti známé doposud. Vytvořil jsem tedy čtyři persony: dva muže a dvě ženy reprezentující kategorie uživatelů pod 20 let a kolem 30 let, výše zmíněných vlastností. Persony jsem doplnil obrázky pro jejich lepší charakteristiku a snadnější zapamatování. Na základě upřesnění cílové kategorie uživatelů – mezi 15 a 40 lety hledající vážný vztah – se zadavatelem jsem upravil Persony, aby reflektovaly toto nové směřování Líbímseti – směrem k seriózní seznamce. Upravil jsem tedy popis hlavní cílové kategorie a popis persony IVYS, která teď více reflektovala hlavní cílovou skupinu uživatelů. V návaznosti na informace získané ze schůzek se zadavatelem a z provedené As Is analýzy jsem dokument doplnil o dvě persony reprezentující starší uživatele, kterých na seznamkách přibývá a stávají se tak 67

3. Realizace

Obrázek 3.12: Persony verze 1.1

68

3.3. Jak udržovat artefakty aktuální

Obrázek 3.13: Persony verze 1.2 – finální podoba

69

3. Realizace důležitým segmentem trhu[61]. Dokument jsem verifikoval s týmem a pomocí vytvořeného checklistu. Takto vznikla verze 1.0 – viz obrázek 3.11. Postupem času jsem si uvědomil, že popsané persony sice popisují cílové uživatele, jejich charakteristiky a jejich důvody k využívání produktu, ale nereflektují potřeby zainteresovaných stran, konkrétně zákazníka. Přidal jsem tedy stakeholdery firmy S.I.C. a doplnil potřebné informace. Pro správné zachycení mi posloužily především informace získané od zadavatele a z provedené As Is analýzy. Vznikla verze 1.1, jak můžete vidět na obrázku 3.12. Na základě tohoto rozšíření jsem také rozšířil checklist, pomocí kterého jsem Persony kontroloval. Pro další úpravu Person a vznik verze 1.2 (viz obrázek 3.13) bylo podstatné uvědomění si důležité potřeby uživatelů, a to ochrany před nevhodným chováním. Tuto potřebu plánoval zadavatel chystaným řešením uspokojit. K relevantním personám byla tedy doplněna tato informace. Zároveň byl na základě checklistu přidány další informace o plánovaném užívaní produktu uživateli. Doplnil jsem také popis potřeb a motivaci čtyř nejmladších person reprezentujících uživatele. Na radu Romana Pichlera[15] jsem zvolil IVYS primární personou a doplnil její popis. Dokument byl zkontrolován zadavatelem a týmem. Důkladně jsem jej pak zkontroloval pomocí checklistu. Změnil jsem obrázky některých person, a celkově upravil design dokumentu. Změnil jsem také formátování. Tyto změny udělaly dokument vzhlednějším a čitelnějším, jak lze vidět na obrázku 3.13. Tyto Persony jsou zatím poslední verzí a z jejich odsouhlasení zadavatelem lze usoudit, že dobře reflektují cílovou skupinu uživatelů i zainteresovaných stran. Dokument se pochopitelně může v duchu agilních principů měnit v návaznosti na lepší identifikaci jednotlivých uživatelských skupin, změně trhu či postoje zadavatele. Takto byly Persony v průběhu našeho projektu udržovány aktuální a srozumitelné všem stranám. Byly řízeny jejich verze. Na obrázcích lze vidět, jak se tento artefakt mění.

3.3.4

Product Backlog

V této části popíši, jak se mění artefakt Product Backlog a jak jej udržovat v konzistentním a aktuálním stavu. Product Backlog se mění v návaznosti na změnách požadavků. Mění se s ohledem na: • Změnu stavu požadavku – Například je-li požadavek již implementován, jeho stav se změní z working na closed. • Změnu priority požadavku. 70

3.3. Jak udržovat artefakty aktuální • Přidáním dalšího požadavku – Záleží na velikosti či obecnosti daného požadavku. Buď bude přidán celý nový epic nebo jedno či více user stories, anebo bude pouze upraveno akceptační kritérium některé user story (ovlivňuje-li požadavek pouze některý jeho atribut). • Zrušením požadavku – Opět záleží na velikosti požadavku. Budou provedeny úpravy opačné předchozímu bodu. • Úpravou požadavku – Úprava požadavku může vést k úpravě epicu a přidání dalších user story nebo jejich úpravou. Může vést také k úpravě jedné user story nebo jen některého jeho akceptačního kritéria. Požadavkem zde myslím jakýkoli požadavek na produkt vznesený zákazníkem či jiným stakeholderem. Požadavek může být menší, než user story – popisující pouze některý jeho atribut, odpovídající user story (sem řadím i nefunkční požadavky, které mají vliv na více user stories a mají být dokumentovány jako samostatná user story), větší, než user story, stejné jako epic, ale ne větší jak epic. Protože epic reprezentuje velkou vlastnost produktu či souhrnnou funkcionalitu. Je třeba uvést, že v případě úpravy user story je třeba upravit, přidat či odebrat testovací scénáře dané user story a upravit dotčený grafický návrh. Grafický návrh je třeba stejně jako user stories verzovat, aby bylo jasné, co platilo ve které fázi projektu. S user story (či epicem), jakožto základním prvkem Product Backlogu, lze na základě výše uvedených změn požadavků, provádět následující operace: • Přidání – User story je přidáno na základě nového požadavku a je upraven dotčený grafický návrh GUI nebo vytvořen grafický návrh pokrývající potřeby nového user story. • Odebrání/smazání – User story se stane nepotřebným. Například jej již zákazník více nepotřebuje, nebo duplikuje jiné user story. Vždy je dobré zaznamenat, proč bylo dané user story odebráno a nemazat jej tak úplně (fyzicky). • Úprava – User story je třeba upravit, když se změní její status, priorita nebo je odhadnuta pracnost ve story pointech, to je zřejmé. Někdy je ale třeba změnit samotnou formuli user story například z důvodu změny cílového uživatele (část user story Jako) nebo úpravy podstaty user story (části chci či abych). Častěji však budete upravovat atributy user story, tj. přidávat, odebírat či upravovat akceptační kritéria. V návaznosti pak dojde k úpravě testovacích scénářů a dotčeného grafického návrhu. • Rozdělení – Tato operace je typická pro epic, který se časem zpřesní, a je rozdělen na více user stories. Může ale dojít i k rozdělení některé user story, protože je příliš velká a lze ji rozdělit na několik menších, 71

3. Realizace které stále splňují vlastnosti user story. Zejména to, že přináší přidanou hodnotu. Pokud toto lze, udělejte to. Dále demonstruji, příklady těchto operací s user stories na našem projektu. Na webu, kde mají spolu uživatelé interagovat či se dokonce seznamovat je předpokladem, že bude třeba nějak ověřit identitu uživatele. Pro zaznamenání požadavků spojených s tímto ověřováním vznikl epic Ověření uživatele. Z aktuálního stavu služby a prvních schůzek se zadavatelem vzešlo, že pro vykonání většinu funkcí portálu, musí být uživatel přihlášen. Aby se mohl přihlásit, musí se registrovat. Zdokumentoval jsem tedy tři user stories, ještě blíže nespecifikované: • Jako nepřihlášený uživatel se chci registrovat, abych mohl plně využívat služby Líbímseti. • Jako nepřihlášený uživatel se chci přihlásit, abych mohl plně využívat služby Líbímseti a měl jsem jistotu, že jsem to já. • Jako uživatel se chci odhlásit, abych měl jistotu, že nikdo jiný nemůže na mém počítači jednat mým jménem na Líbímseti. Dále se budu věnovat user story spojené s registrací. Následně bylo specifikováno, že registrovat se může uživatel klasicky, tj. pomocí svého uživatelského jména a hesla, pomocí údajů z Facebooku, Googlu nebo pomocí identifikátoru MojeID. Přidal jsem tedy akceptační kritérium: Uživatel se může registrovat pomocí uživatelského jména a hesla, pomocí účtu Google, FB či MojeID a akceptační kritérium: Uživatelské jméno musí být unikátní. Byl také upřesněn grafický design prvků spojených s registrací. Za nedlouho začalo být zřejmé, že user story je příliš velká, a že jak technologicky, tak z hlediska přínosu uživateli, pokrývá více případů. Rozdělil jsem ji tedy na čtyři menší user story: • Jako nepřihlášený uživatel se chci registrovat – standardním způsobem, abych mohl plně využívat služby Líbímseti. • Jako nepřihlášený uživatel se chci registrovat pomocí Google účtu, abych mohl plně využívat služby Líbímseti a usnadnil jsem si registraci použitím svých dat z Google účtu. • Jako nepřihlášený uživatel se chci registrovat pomocí Facebook účtu, abych mohl plně využívat služby Líbímseti a usnadnil jsem si registraci použitím svých dat z Facebook účtu. • Jako nepřihlášený uživatel se chci registrovat pomocí MojeID, abych mohl plně využívat služby Líbímseti a usnadnil jsem si registraci použitím svých dat z MojeID účtu. 72

3.3. Jak udržovat artefakty aktuální Jednotlivé user story jsem začal upřesňovat. Specifikoval jsem, že pro registraci musí uživatel zadat tyto údaje: uživatelské jméno a heslo, email, heslo, datum narození, okres a pohlaví. Heslo musí obsahovat malá a velká písmena a číslici, musí mít minimálně 5 znaků. Uživatel musí zadat heslo dvakrát pro kontrolu. Dále formát emailu, který uživatel uvede, musí mít standardní formát *.@*.*. Na závěr registrace musí uživatel souhlasit s provozními podmínkami Líbímseti a opsat kontrolní správně obrázek. Přidal jsem akceptační kritéria ve znění: • Uživatel musí vyplnit o sobě tyto údaje: uživatelské jméno, email, heslo, datum narození, okres, pohlaví. • Heslo musí obsahovat malá a velká písmena a číslici, heslo musí mít minimálně 5 znaků. • Uživatel musí zadat heslo 2x – pro kontrolu. • Email musí mít standardní formát: *@*.*. • Uživatel musí správně opsat kontrolní kód z obrázku. • Uživatel musí dát najevo, souhlas s provozními podmínkami. Byla upřesněna grafika pro registraci. Dále jsem pro ověření akceptačních kritérií a tak splnění tohoto user story vytvořil tyto akceptační scénáře: • Registrujte se – zadejte uživatelské jméno (nick) Karel007 a heslo "heslo". Vyplňte potřebné údaje, opište kontrolní obrázek a zaškrtněte souhlas s provozními podmínkami. [Uživatel neregistrován, vyvoláno upozornění o nedostatečné síle hesla] • Vyplňte heslo na "Heslo1"a dejte registrovat. [Uživatel registrován a přihlášen] • Odhlaste se. [Uživatel odhlášen, přesměrován na hlavní stránku] • Registrujte se – zadejte uživatelské jméno (nick) Karel007 a heslo "heslo". Vyplňte potřebné údaje, opište kontrolní obrázek a zaškrtněte souhlas s provozními podmínkami. [Uživatel neregistrován, vyvoláno upozornění, že uživatelské jméno je již obsazeno] • Upravte jména na Pepa007 a nechte některé povinné pole nevyplněno. [Uživatel neregistrován, vyvoláno upozornění, že je třeba vyplnit všechna potřebná pole] • Vyplňte všechna povinná pole a email upravte na "pepa007seznam.cz". [Uživatel neregistrován, vyvoláno upozornění, že email neodpovídá správnému formátu] 73

3. Realizace • Email upravte na "[email protected]", opište špatně kontrolní obrázek. [Uživatel neregistrován, vyvoláno upozornění, že neopsal správně obrázek] • Odškrtněte souhlas s podmínkami a opište správně kontrolní obrázek. [Uživatel neregistrován, vyvoláno upozornění, že je třeba vyjádřit souhlas s podmínkami] V hranatých závorkách jsou uvedeny předpokládané odpovědi programu. Takto jsem demonstroval případy úpravy, přidání a rozdělení požadavku. Nyní ještě uvedu příklad, kdy byl požadavek zrušen. Líbímseti aktuálně nabízí možnost diskuse v takzvaných otázkách i diskusích, které jsou si velmi podobné. Původně se počítalo s implantací jak otázek, tak diskusí. Byly tedy specifikovány tyto user stories: • Jako uživatel chci vytvořit otázku, abych zjistil odpověď a názory na otázku, kterou nevím/mě zajímá. • Jako uživatel chci vytvořit diskusi, abych diskutoval nad zajímavým tématem. Postupem času jsme se zadavatelem došli k závěru, že funkcionalita otázek i diskusí je velmi podobná a bylo by lepší je sloučit dohromady a ponechat název Diskuse, který lépe charakterizuje význam této funkcionality. User story Jako uživatel chci vytvořit otázku, abych zjistil odpověď a názory na otázku, kterou nevím/mě zajímá, bylo zrušeno, a zůstalo pouze user story Jako uživatel chci vytvořit diskusi, abych diskutoval nad zajímavým tématem. Je třeba připomenout, že user stories se mění s také ohledem na provedené kontroly. Jde o kontroly se zákazníkem, týmem, vlastní kontroly pomocí checklistů a případné inspekce či review Product Backlogu jinými členy týmu. Následně prováděné operace s user stories jsou stejné, jak uvádím výše.

74

Závěr Přínos práce Závěrem bych rád shrnul přínosy mé práce. 1. Zachycení přínosu a potřeb pro redesign služby Líbímseti – V analýze stávajícího stavu (As Is analýze 2.3) jsem zachytil stávající stav služby a trhu a z něj vyplývající potřeby pro další rozvoj. V dokumentu Vision Board jsem popsal vytvářený produkt, jeho přínosy a cíle a v dokumentu Persony jsem identifikoval a popsal cílovou skupinu uživatelů a zainteresovaných stran vytvářeného produktu. 2. Zachycení požadavků na službu – V dokumentu Persony jsem zachytil cílové uživatele a zainteresované strany produktu a jejich hlavní požadavky a v dokumentu Product Backlog jsem provedl detailně analýzu požadavků. 3. Implementace a otestování nové funkcionality a nefunkčních požadavků Líbímseti – Na základě mé business analýzy, zejména Person a Product Backlogu byly mými kolegy Martinem Humeníkem a Lukášem Jeschke v rámci jejich diplomových prací[82][83], implementovány nové funkcionality a dalších nefunkční požadavky na provoz služby Líbímseti, které byly také pomocí mnou vytvořených testovacích scénářů otestovány. Toto je popsáno především v částech Realizace – Jak probíhal projekt – Průběh projektu 3.1.1 a Realizace – Zhodnocení business analýzy – Na projektu 3.2.1. Tyto implementované části budou nasazeny, až bude dokončena implementace dalších funkčních a nefunkčních požadavků. 4. Přiblížení problematiky agilní, ale i tradiční, business analýzy – Práce popisuje v části Analýza a návrh – O business analýze 2.1 proces zpracování business analýzy agilním způsobem i tradičními metodami a blíže tak seznamuje čtenáře s touto problematikou. 75

Závěr 5. Doporučení pro tvorbu agilní i tradiční business analýzy – Práce popisuje agilní i tradiční přístup k business analýze a její tvorbě viz Analýza a návrh – O business analýze 2.1. Potom porovnává jejich přínosy a nevýhody v kontextu skutečného projektu s doporučeními platnými i pro další projekty viz Realizace – Zhodnocení business analýzy 3.2.

Co mi práce dala Práce mi dala hlavně cennou zkušenost s reálným projektem z, pro mě zcela nové, business domény webových seznamovacích portálů. Seznámil jsem se tak s tímto rostoucím segmentem trhu a získal cenné informace o různých taktikách a obchodních modelech. Rozšířil jsem také své znalosti z oblasti business analýzy – jak agilní, tak také tradiční. Avšak především jsem si vyzkoušel, co obnáší tvorba agilní business analýzy, a že v prostředí orientovaném tradičním způsobem, je třeba agilní přístup uzpůsobit konkrétním podmínkám. Práce pro mě byla velkým přínosem.

Splnění zadání práce Zde bych rád v krátkosti shrnul splnění zadání práce.

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. Zmíněné artefakty byly v kooperaci se zadavatelem a s využitím dalších zdrojů informací vytvořeny, jak popisuji v části Realizace – Jak probíhal projekt 3.1. Byly verifikovány se zadavatelem a také pomocí nejlepších praktik a kontrolních seznamů, jak je popsáno v částech Realizace – Jak probíhal projekt 3.1 a Realizace – Jak udržovat artefakty aktuální 3.3.

Popište a demonstrujte jak udržovat artefakty během běhu projektu aktuální. Zmíněné artefakty byly verifikovány pomocí nejlepších praktik a kontrolních seznamů, jak je popsáno v částech Realizace – Jak probíhal projekt 3.1 a Realizace – Jak udržovat artefakty aktuální 3.3. V části Realizace – Jak probíhal 76

Splnění zadání práce projekt 3.1 jsem také uvedl, jak byly artefakty udržovány aktuální za běhu projektu a v části textu Realizace – Jak udržovat artefakty aktuální 3.3 je popsáno a demonstrováno, jak spravovat dané artefakty, aby byly živé, korektní a aktuální, a měli jsme tak k dispozici vždy správné informace.

Ověřte artefakty pomocí tzv. nejlepších praktik (best practicies) a kontrolních seznamů (checklistů). Artefakty byly ověřeny pomocí nejlepších praktik a kontrolních seznamů, jak jsem popsal v částech Realizace – Jak probíhal projekt 3.1 a Realizace – Jak udržovat artefakty aktuální 3.3. Jak jsem tyto nejlepší praktiky a kontrolní seznamy sestavil, je popsáno v částech Analýza a návrh – Návrh zpracování business analýzy – Vision Board – Verifikace 2.2.3.3, Analýza a návrh – Návrh zpracování business analýzy – Persony – Verifikace 2.2.4.3 a Analýza a návrh – Návrh zpracování business analýzy – Product Backlog – Verifikace 2.2.5.3.

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. Přínos agilní business analýzy v kontextu našeho projektu jsem zhodnotil v kapitole Realizace – Zhodnocení – Na projektu 3.2.1, kde jsem také uvedl výhody a nevýhody, které mělo její použití na tomto projektu proti tradičnímu způsobu. V následující části Realizace – Zhodnocení – Doporučení pro další projekty 3.2.2 uvádím přínosy a zápory použití agilní a tradiční business analýzy na jiných projektech a uvádím další doporučení a varování.

77

Literatura [1]

Wiegers, K. E.: Writing Quality Requirements. 1999, [cit. 201404-19]. Dostupné z: http://static.squarespace.com/static/ 50c9c50fe4b0a97682fac903/t/50feb37ce4b000014e7f1191/ 1358869372660/Karl%20Wiegers%20Writing%20High%20Quality% 20Requirements-1.pdf

[2]

smart-BA: Benefits of Business Analysis. 2008, [cit. 201404-19]. Dostupné z: http://www.smart-ba.com/articles/ Benefits_of_Business_Analysis.pdf

[3]

Korban, S.: The Structure of Business Analysis Documents. 2012, [cit. 2014-04-28]. Dostupné z: http://www.batimes.com/articles/thestructure-of-business-analysis-documents.html

[4]

Bradley, C.: User Story Traps. 2011, [cit. 2014-04-25]. Dostupné z: http: //scrumcrazy.wordpress.com/2011/01/05/user-story-traps/

[5]

Matěj, R.: Product Ownership Workshop. 2013, ČVUT v Praze, Fakulta informačních technologií, Přednáška MI-AIT.

[6]

Pinďák, Š.: BOZP portál – Vedení studentského týmu a specifikace požadavků při jeho tvorbě. Bakalářská práce, ČVUT v Praze, Fakulta informačních technologií, 2012.

[7]

Brainz.org: History of Online Dating. 2010, [cit. 2014-04-21]. Dostupné z: http://brainz.org/history-online-dating/

[8]

Neuberger, O.: Světové seznamky v roce 2013. 2013, [cit. 2014-04-12]. Dostupné z: http://www.neuberger.cz/2013/seznamky-ve-svete/

[9]

eSilverStrike Consulting Inc.: Online Dating Statistics & Facts. 2014, [cit. 2014-04-25]. Dostupné z: http://www.datingsitesreviews.com/ staticpages/index.php?page=Online-Dating-Industry-FactsStatistics 79

Literatura [10] Statistic Brain: Online Dating Statistics. 2014, [cit. 2014-04-25]. Dostupné z: http://www.statisticbrain.com/online-dating-statistics/ [11] Líbímseti.cz: Líbímseti.cz. [cit. 2014-04-25]. Dostupné z: http:// libimseti.cz/ [12] Neuberger, O.: Tečka za Líbímseti. 2011, [cit. 2014-04-12]. Dostupné z: http://www.neuberger.cz/2013/seznamky-ve-svete/ [13] Vyleťal, M.: Líbiseti víc Olda Neuberger než Mark Zuckerberg? 2011, [cit. 2014-04-27]. Dostupné z: http://www.lupa.cz/clanky/libiseti-vicolda-neuberger-nez-mark-zuckerberg/ [14] Blesk: Líbímseti.cz: Jsou intimní fotky v bezpečí? 2008, [cit. 2014-04-27]. Dostupné z: http://www.blesk.cz/clanek/zpravy-udalosti-domaci/ 102284/libimseti-cz-jsou-intimni-fotky-v-bezpeci.html [15] Pichler, R.: 10 Persona Tips for Agile Product Management. 2013, [cit. 2014-04-28]. Dostupné z: http://www.romanpichler.com/blog/10persona-tips-agile-product-management/#.U16o2kO8qgY [16] IIBA: A Guide to the Business Analysis Body of Knowledge, 2 edition. International Institute of Business Analysis, 2009, ISBN 0981129218. [17] TechRepublic: Understanding the pros and cons of the Waterfall Model of software development. 2006, [cit. 2014-0419]. Dostupné z: http://archive.today/20130102112959/ http://articles.techrepublic.com.com/5100-10878_116118423.html?part=rss&tag=feed&subj=tr [18] The Smart Method Limited: The Waterfall Development Methodology. 2011, [cit. 2014-04-28]. Dostupné z: http://www.learnaccessvba.com/ application_development/waterfall_method.htm [19] Bednar, L.: Comments on "Vision and Scope"Documents. 2001, [cit. 2014-04-21]. Dostupné z: http://www.nw-datacentric.com/about/methods/software_devel/wk_examples/ vision_and_scope_weigers.pdf [20] The Standish Group: Chaos Manifesto 2012. 2012, [cit. 201404-12]. Dostupné z: http://versionone.com/assets/img/files/ CHAOSManifesto2012.pdf [21] Manifest Agilního vývoje software. 2001, [cit. 2014-04-12]. Dostupné z: http://agilemanifesto.org/iso/cs/ 80

Literatura [22] Hunton, S.: A Scrum Master Is Not a Project Manager by Another Name. 2012, [cit. 2014-04-25]. Dostupné z: http: //www.scrumalliance.org/community/articles/2012/august/ascrum-master-is-not-a-project-manager-by-another [23] Gergic, J.: The GoodData Story - why we transitioned from the traditional model of having separate teams. 2013, ČVUT v Praze, Fakulta informačních technologií, Přednáška MI-AIT. [24] Pichler, R.: Introduction to the Product Canvas. 2013, [cit. 201404-25]. Dostupné z: http://www.slideshare.net/romanpichler/ introduction-to-the-product-canvas [25] The Business Model Canvas. [cit. 2014-04-29]. Dostupné z: http://www.businessmodelgeneration.com/downloads/ business_model_canvas_poster.pdf [26] Pichler, R.: The Product Vision Board. 2011, [cit. 2014-04-12]. Dostupné z: http://agile.dzone.com/news/product-vision-board [27] Gumma, P.: Agile Contracting: A Story-Point Billing Model. 2013, [cit. 2014-04-21]. Dostupné z: http://www.scrumalliance.org/community/ articles/2013/2013-april/agile-contracting-a-story-pointbilling-model [28] Hraše, Z.: Agilní řízení v dodavatelsko odběratelských vztazích. ČVUT v Praze, Fakulta informačních technologií, Přednáška MI-AIT. [29] Bestoutcome: An Introduction to Scrum. 2013, [cit. 2014-04-19]. Dostupné z: http://www.bestoutcome.com/overview-of-scrum.html [30] TTG Media Ltd.: Scope Management. 2006, [cit. 2014-04-23]. Dostupné z: http://cdn.ttgtmedia.com/searchSoftwareQuality/downloads/ Software_Project_Manager_Agility_CH05.pdf [31] Microsoft Consulting Servicies: Vision and Scope Checklist. 1998, [cit. 2014-04-28]. Dostupné z: http://www.docstoc.com/docs/79388816/ MSF-Vision-Scope-Checklist-1-0 [32] Hoda, R.: What Language Does Agile Speak? 2009, [cit. 201404-25]. Dostupné z: http://ecs.victoria.ac.nz/foswiki/pub/Main/ RashinaHoda/Wldas.pdf [33] Ken Auer, R. M.: Extreme Programming Applied: Playing to Win, 1 edition. Addison-Wesley Professional, 2011, ISBN 0201616408. [34] Wong, J.: Agile analysis and best practices. 2013, [cit. 2014-04-25]. Dostupné z: http://www.slideshare.net/JennyWong8/agile-analysisand-best-practices 81

Literatura [35] McGovern, F.: Blending Traditional and Agile Project Documentation. 2010, [cit. 2014-04-25]. Dostupné z: http://www.visiblethread.com/ wp-content/uploads/Lean-Documentation-Blending-Traditionaland-Agile-Project-Documentation.pdf [36] Jongerius, M. H.: Using the Product Vision Board. 2012, [cit. 2014-0423]. Dostupné z: http://mhjongerius.tumblr.com/post/9539129138/ using-the-product-vision-board [37] Conscires Agile Practicies: Why is Product Visioning important? 2012, [cit. 2014-04-25]. Dostupné z: http://agile.conscires.com/2012/06/ 28/why-is-product-visioning-important/ [38] Sauro, J.: 7 Core Ideas about Personas and The User Experience. 2012, [cit. 2014-04-25]. Dostupné z: https://www.measuringusability.com/ blog/personas-ux.php [39] Calabria, T.: An introduction to personas and how to create them. 2004, [cit. 2014-04-21]. Dostupné z: http://www.steptwo.com.au/papers/ kmc_personas [40] Turner, N.: Getting the most out of personas. 2010, [cit. 2014-04-29]. Dostupné z: http://www.uxforthemasses.com/personas/ [41] Cockburn, A.: Agile Use Cases. 2003, [cit. 2014-04-19]. Dostupné z: alistair.cockburn.us/get/2231 [42] Terski, M.: Agile Use Cases in Four Steps. 2009, [cit. 2014-04-23]. Dostupné z: http://blog.casecomplete.com/post/Agile-Use-Cases-inFour-Steps [43] Johnston, C.: User stories: a beginner’s guide to acceptance criteria. 2010, [cit. 2014-04-25]. Dostupné z: http://www.boost.co.nz/blog/2010/09/ acceptance-criteria/ [44] Ropa, S.: Why I Don’t Like the User Story Templates. 2013, [cit. 201404-12]. Dostupné z: http://blogs.versionone.com/agile_management/ 2013/07/16/why-i-dont-like-user-story-templates/ [45] BA-EXPERTS: Non-Functional Requirements Add Value to User Stories (Part 5). 2013, [cit. 2014-04-25]. Dostupné z: http: //businessanalysisexperts.com/non-functional-requirementsadd-value-to-user-stories-part-5/ [46] Atlassian Documentation: Working with Epics. [cit. 2014-04-12]. Dostupné z: https://confluence.atlassian.com/display/AGILE/ Working+with+Epics 82

Literatura [47] Bradley, C.: A User Story Checklist. 2012, [cit. 2014-04-21]. Dostupné z: http://scrumcrazy.wordpress.com/2012/04/16/a-user-storychecklist/ [48] BA-EXPERTS: Five Rules for Effective User Stories. 2012, [cit. 2014-0425]. Dostupné z: http://businessanalysisexperts.com/five-rulesfor-effective-user-stories/ [49] BA-EXPERTS: A User Story Expresses What, Not How. 2013, [cit. 201404-21]. Dostupné z: http://businessanalysisexperts.com/a-userstory-expresses-what-not-how/ [50] BA-EXPERTS: Focus on Relevant User Stories. 2013, [cit. 201404-27]. Dostupné z: http://businessanalysisexperts.com/writingrelevant-user-stories/ [51] Agile Alliance: User Stories. [cit. 2014-04-19]. Dostupné z: http:// guide.agilealliance.org/guide/user-stories.html [52] Whipps, H.: The 300-year History of Internet Dating. 2009, [cit. 201404-29]. Dostupné z: http://www.livescience.com/3362-300-yearhistory-internet-dating.html [53] Ženy.cz: Jak se "balí"po Česku aneb Kdo jsou typičtí uživatelé seznamek. 2012, [cit. 2014-04-27]. Dostupné z: http://zeny.e15.cz/clanek/ sex-a-vztahy/jak-se-bali-po-cesku-aneb-kdo-jsou-typictiuzivatele-seznamek [54] Lidé.cz: Lidé.cz. [cit. 2014-04-25]. Dostupné z: http://www.lide.cz/ [55] Awaissoft: The WWW as we all know it . . . ? 2013, [cit. 2014-04-29]. Dostupné z: http://awaissoftnews.wordpress.com/2013/10/09/thewww-as-we-all-know-it/ [56] eDarling: eDarling. //www.edarling.cz/

[cit.

2014-04-19].

Dostupné

z:

http:

[57] Seznamka HARMONIE: Seznamka HARMONIE: hledání štěstí. [cit. 2014-04-12]. Dostupné z: http://zivotni-energie.cz/seznamkaharmonie-hledani-stesti.html [58] Seznamka pro postižené: Seznamka pro postižené. [cit. 2014-04-25]. Dostupné z: http://www.seznamkapropostizene.cz/ [59] katolik.cz: Seznamka katolik.cz. [cit. 2014-04-19]. Dostupné http://seznamka.katolik.cz/vypis_inzeraty.asp?rub=0&kr= all&typ=0&kat=0

z:

83

Literatura [60] Dosh, K.: The 10 Most Common Lies in Online Dating Profiles. 2013, [cit. 2014-04-25]. Dostupné z: http://www.womansday.com/sexrelationships/dating-marriage/online-dating-profile-lies [61] TwoOfUs: 10 Online Dating Myths. 2010, [cit. 2014-04-25]. Dostupné z: http://www.twoofus.org/educational-content/articles/ 10-online-dating-myths/index.aspx [62] Česká televize: Internetové seznamky. 2012, [cit. 2014-04-28]. Dostupné z: http://www.ceskatelevize.cz/porady/10396240499-svetzazraku/6726-reportaz/15951-internetove-seznamky/ [63] Janda, J.: Proč seznamky nefungují. 2012, [cit. 2014-04-28]. Dostupné z: http://psychologie.cz/proc-seznamky-nefunguji/ [64] Seznamka Harmonie: Seznamka Harmonie - nekalé praktiky, podvodníci, lháři. [cit. 2014-04-23]. Dostupné z: http://zivotni-energie.cz/ seznamka-harmonie-nekale-praktiky-podvodnici-lhari.html [65] Ariely, D.: Internetové seznamky. 2013, [cit. 2014-02-10]. Dostupné z: http://www.videacesky.cz/navody-dokumenty-pokusy/ internetove-seznamky [66] Horáková, M.: Internetové seznamky. Jak z nich vytěžit co nejvíc? 2013, [cit. 2014-04-28]. Dostupné z: http://www.leyter.com/blog/ internetove-seznamky-jak-z-nich-vytezit-co-nejvic/ [67] Laskomat.cz: Laskomat.cz. [cit. 2014-04-12]. Dostupné z: http:// www.laskomat.cz/seznamka/ [68] Badoo: Badoo. [cit. 2014-04-25]. Dostupné z: http://badoo.com/cs/ [69] Objevit.cz: Badoo začíná s dalším spamem? 2013, [cit. 2014-04-25]. Dostupné z: http://objevit.cz/badoo-zacina-s-dalsim-spamemt20706 [70] Elchron: Elchron. eseznamka.wz.cz/

[cit.

[71] Jiskření.cz: Jiskření.cz. //www.jiskreni.cz/

2014-04-12]. [cit.

Dostupné

2014-04-25].

z:

Dostupné

http:// z:

http:

[72] Seznamka.cz: Seznamka.cz. [cit. 2014-04-25]. Dostupné z: http:// www.seznamka.cz/ [73] SeznamkaAZ: SeznamkaAZ. [cit. 2014-04-28]. Dostupné z: http:// www.seznamkaaz.cz/ [74] Štěstí.cz: Štěstí.cz. [cit. 2014-04-25]. Dostupné z: http://www.stesti.cz/ 84

Literatura [75] Rande.cz: Rande.cz. [cit. 2014-04-23]. Dostupné z: http://www.rande.cz/ index.aspx [76] MojeID. [cit. 2014-04-25]. Dostupné z: http://www.mojeid.cz [77] Líbímseti.cz: Proč už na libko nikdo nechodi? [cit. 2014-04-28]. Dostupné z: http://diskuze.libimseti.cz/proc-uz-na-libko-nikdonechodi-933823 [78] Grenning, J.: Planning Poker or How to avoid analysis paralysis while release planning. 2002, [cit. 2014-04-25]. Dostupné z: http:// renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf [79] McConnell, S. C.: Code Complete, Second Edition. Microsoft Press, 2004, ISBN 0735636974. [80] Pichler, R.: Agile Product Planning with the Vision Board. 2013, [cit. 2014-04-23]. Dostupné z: http://www.slideshare.net/romanpichler/ agile-product-planning-with-the-vision-board-26535797 [81] Pichler, R.: The Vision Board. 2011, [cit. 2014-04-25]. Dostupné z: http://www.romanpichler.com/blog/product-vision/the-productvision-board/#.Ux30l0DSquf [82] Humeník, M.: Vývoj a provoz sociální sítě – Vývoj webové aplikace I. Diplomová práce, ČVUT v Praze, Fakulta informačních technologií, 2014. [83] Jeschke, L.: Vývoj a provoz sociální sítě – Vývoj webové aplikace II. Diplomová práce, ČVUT v Praze, Fakulta informačních technologií, 2014.

85

Příloha

Seznam použitých zkratek API Application programming interface – - rozhraní pro programování aplikací BA business analýza BMI Body Mass Index – index tělesné hmotnosti FTFP Fixed Time, Fixed Price – pevný termín, pevná cena – kontrakt na dodávku v pevném termínu a pevné ceně CTU Czech Technical University in Prague ČVUT České vysoké učení technické v Praze BOZP Bezpečnost a ochrana zdraví při práci FIT Fakulta informačních technologií GUI Graphical user interface – Grafické uživatelské rozhraní HTML Hypertext markup language HW Hardware IS Informační systém IT Informační technologie LOC Lines of Code – Řádky kódu MS Microsoft PHP Hypertext Preprocessor PO Požární ochrana 87

A

A. Seznam použitých zkratek QA Quality assurance – Zajištění kvality RAD Rapid Application Development ROI Return On Investment – Návratnost investic (R)UP (IBM Rational) Unified Process SRS Software Requirements Specification – Specifikace požadavků softwarového produktu SW Software TBD To Be Determinated – K budoucímu upřesnění TM Time and Material – čas a materiál – kontrakt na dodávku placenou za odpracovaný čas a využité zdroje UML Unified modeling language UAT User Acceptance Test – Uživatelské akceptační testování WBS Work Breakdown Structure – Hierarchická struktura prací XML Extensible markup language XP Extreme Programming

88

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD src.....................................................výstupy práce business_analysis...........dokumenty business analýzy redesignu Líbímseti.cz impl...........................zdrojové kódy redesignu Líbímseti.cz management...................dokumenty týkající se vedení projektu QA................dokumenty týkající se zajištění kvality na projektu thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce DP_Stefan_Pindak_2014.pdf ............ text práce ve formátu PDF 89

B