}w
!"#$%&'()+,-./012345<yA|
Masarykova univerzita
Fakulta informatiky
Agilné metodológie riadenia
vývoja softwaru
Diplomová práca
Bc. Martin Kacvinský
Brno, jeseň 2011
Prehlásenie
Prehlasujem, že táto diplomová práca je mojím pôvodným autorským dielom,
ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som
pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením
úplného odkazu na príslušný zdroj.
Bc. Martin Kacvinský
Vedúci práce: RNDr. Jaroslav Škrabálek
ii
Poďakovanie
Veľká vďaka patrí môjmu vedúcemu RNDr. Jaroslavovi Škrabálkovi za inšpiratívne vedenie a môjmu konzultantovi doc. RNDr. Petrovi Sojkovi, Ph.D. Ďakujem
tiež môjmu kamarátovi a bývalému kolegovi Ondřejovi Kocianovi za láskavú
a trpezlivú technickú pomoc. V neposlednom rade ďakujem mojím rodičom a
slečne Janke Dubovej za prejavenú trpezlivosť a podporu počas obdobia vzniku
tejto práce.
iii
Zhrnutie
Diplomová práca sa zaoberá výskumom v oblasti agilného riadenia vývoja softwaru. Skúma súčasne dostupné agilné metodiky a analyzuje ich možnosti použitia pri vývoji projektov moderných webových služieb a mobilných riešení.
Praktická časť práce je venovaná použitiu týchto metodík v skutočnom (komerčnom) prostredí. Pomocou prípadovej štúdie sú analyzované problémy konkrétneho projektu rozsiahlej internetovej služby, ktorej vývoj je riadený agilnou
metodikou.
Výstupom praktickej časti je návrh programového riešenia, ktoré umožní efektívne riadenie ako z pohľadu manažéra, tak vývojára. Toto programové riešenie
si súčasne kladie za cieľ čiastočne eliminovať problémy vyplývajúce z prípadovej
štúdie implementáciou nových spôsobov používateľského ovládania a interakcie.
Výsledné riešenie je podrobené funkčnými, výkonnostnými a záťažovými
testami.
iv
Kľúčové slová
agilný, agilné, metodológie, metodika, projektový manažment, SCRUM, vývoj
webových aplikácií
v
Obsah
1
2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Motivácia a cieľ práce . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Prehľad práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Ujasnenie pojmov . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Softwarové inžinierstvo . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Softwarová kríza . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Model životného cyklu vývoja softwaru . . . . . . . . . . . . . . . . .
2.3.1 Vodopádový model . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Špirálový model . . . . . . . . . . . . . . . . . . . . . . . .
Metodiky vývoja softwaru . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Objektovo orientované iteratívne metodiky . . . . . . . . . . . . . . . .
3.1.1 Metodika Rational Unified Process (RUP) . . . . . . . . . .
3.1.2 Metodika Unified Software Development Process . . . . .
3.1.3 Vzťah RUP/UP k internetovým projektom a malým tímom
3.2 Agilné metodiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Agilný manifest . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Prehľad agilných metodík . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Extrémne programovanie (XP) . . . . . . . . . . . . . . . .
3.3.2 Lean development . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Vývoj riadený vlastnosťami softwaru (FDD) . . . . . . . .
3.3.4 Vývoj riadený testami (TDD) . . . . . . . . . . . . . . . . .
3.3.5 SCRUM Development process . . . . . . . . . . . . . . . .
3.3.6 Ďalšie metodiky . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Rozdiel vo vývoji moderných internetových a mobilných aplikácií od
klasického vývoja . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Porovnanie agilných a rigoróznych metodík . . . . . . . . . . . . . . .
Prípadová štúdia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Zadávateľ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Súčasný stav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Analýza problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Návrh riešenia problému . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Analýza súčasných SW riešení . . . . . . . . . . . . . . . . . . . . . .
4.5.1 JIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.2 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3 XPlanner a XPlanner-plus . . . . . . . . . . . . . . . . . . .
1
2
4
5
6
6
7
7
8
9
11
11
12
14
14
15
16
16
16
20
21
23
24
29
29
30
33
33
34
36
37
39
39
40
40
vi
5
6
7
A
B
C
D
4.5.4 Iné podporné programové riešenia .
Návrh a implementácia . . . . . . . . . . . . . .
5.1 Use-case diagram . . . . . . . . . . . . . . . .
5.2 Diagram tried . . . . . . . . . . . . . . . . . .
5.3 Implementačná architektúra a infraštruktúra . .
5.4 Spôsob vývoja . . . . . . . . . . . . . . . . . .
5.5 Voľba programového prostredia . . . . . . . . .
5.6 Návrh grafického prostredia a spôsobu ovládania
5.6.1 Backlog . . . . . . . . . . . . . . . .
5.6.2 Plánovací míting . . . . . . . . . . .
5.6.3 Daily SCRUM . . . . . . . . . . . . .
5.6.4 Retrospektíva . . . . . . . . . . . . .
Výsledky a kontrola kvality . . . . . . . . . . . .
6.1 Funkčné testovanie . . . . . . . . . . . . . . .
6.2 Výkonnostné a záťažové testovanie . . . . . . .
6.2.1 Metodika testovania . . . . . . . . .
6.2.2 Použitý hardware . . . . . . . . . . .
6.2.3 Test č. 1 – 40 súbežných požiadaviek
6.2.4 Test č. 2 – 20 súbežných požiadaviek
6.2.5 Test č. 3 – 5 súbežných požiadaviek
6.2.6 Záver testovania . . . . . . . . . . .
Záver a diskusia . . . . . . . . . . . . . . . . . . .
Návrhy obrazoviek aplikácie . . . . . . . . . . .
Obrazové prílohy . . . . . . . . . . . . . . . . . .
Obrazové ukážky aplikácie . . . . . . . . . . . .
Obsah CD . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
42
43
44
46
46
47
47
48
48
49
50
50
51
52
52
53
54
54
54
55
63
67
73
81
vii
Je nezmysel byť optimistom,
keď súčasne nie ste agilný.
Elsa Triolet
francúzska spisovateľka
Kapitola 1
Úvod
Predstavme si, že je začiatok roka 2006, my sme úspešný manažér na strednej
úrovni riadenia a naša budúcnosť sa zdá byť ružová. Spolu so spoločnosťou
rastie aj naša kariéra a náš plat. Zachováme sa prediktívne, budeme očakávať rast
aj naďalej. Zriadime aj obrovskú hypotéku a začneme stavať dom s dátumom
ukončenia o päť rokov – teda v roku 2011.
V roku 2008 už však aj v Európe pociťujeme dôsledky hospodárskej krízy. Naši
zákazníci rušia objednávky a firma musí začať šetriť, v dôsledku čoho ku konca
roku stratíme prácu. Hoci sa nám podarí do konca ďalšieho roka zamestnať sa
inde, museli sme prijať pracovnú ponuku s polovičným platom oproti predchádzajúcej pozícii. Takmer ročný výpadok príjmov a naše súčasné nižšie príjmy
prinútili hypotekárnu banku k miernemu odpusteniu úrokov a predĺženiu obdobia splatnosti našej pôžičky, čím sa znížila aj výška našich mesačných splátok.1
Aktuálne je rok 2011, nedávno sme prevzali dostavaný dom a situácia na trhu sa
pomaly stabilizuje. Máme nadštandardne vybavený dom s bazénom, no čaká nás
nesmierne ťažké splátkové obdobie. A iba zázrakom sme o celú stavbu v období
našej krízy neprišli.
A teraz si predstavme, že by sme sa chovali menej prediktívne a viac agilne. . . Ako
by asi prebiehala celá situácia? Pravdepodobne by sme si na začiatku požičali
peniaze na krátke obdobie a z týchto prostriedkov začali stavať. Až by nám
prostriedky došli, znova by sme si požičali na ďalšie krátke obdobie. A takto by
sme to opakovali v určitých iteráciách dookola, pričom naša stavba by postupne
1. Všimnime si, že banka upravila hodnoty času a zdrojov.
1
1. Úvod
inkrementálne rástla. Na prípadné problémy by sme dokázali reagovať flexibilne.
S príchodom hospodárskej krízy by sme, napríklad, upustili od myšlienky stavby
bazénu a urobili by sme určité zjednodušenia vo vybavení domu, čím by sme
dokázali adaptívne reagovať na našu aktuálnu situáciu.
Nerobiť veľké chyby (respektíve ich včasne odhaľovať) a pružne reagovať na
meniace sa požiadavky a prostredie je pri vývoji softwaru kritické. Software
sa však od bežného (uchopiteľného) produktu zásadne odlišuje, hoci na prvý
pohľad spolu majú určité spoločné charakteristiky. Je vysoká pravdepodobnosť,
že zákazník bude chcieť software – na rozdiel od takej chladničky, ktorú zakúpi,
inštaluje do kuchyne a začne niekoľko rokov používať – neustále pozmeňovať a
dopĺňať o rôznu funkcionalitu.
Tradičné (rigorózne) metodiky riadenia vývoju softwaru nedostatočne reflektujú
súčasnú dynamickú dobu. Tradičné techniky (okrem tých úplne najjednoduchších) sú pre vývoj internetových aplikácií pomerne nevhodné. Hlavným dôvodom
je zvláštny charakter Internetu, jeho rýchly rozvoj a silné konkurenčné prostredie. [10] Klasické modely vývoja tiež prestali stačiť požiadavkám na rýchlosť
vývoja, ktorá je spolu s kreatívnym dizajnom jedným z najhlavnejším kritériom
pri tvorbe webových služieb a mobilných riešení. Klienti dnes požadujú vysokú
rýchlosť, nehodlajú sa však vzdať vysokej kvality ani šírke funkcionality.
Preto sa na prelome tisícročia prihlásili k slovu metodológie umožňujúce čo
najrýchlejší vývoj softwaru, jeho priebežnú údržbu a kontrolu kvality ako aj
priebežnú reakciu na meniace sa podmienky a zadanie. Tieto metodológie sa
nazývajú agilné a ich hlavnou myšlienkou je čo najrýchlejšie vyvinúť kostru systému, predložiť ho zákazníkovi a ďalej ho upravovať na základe spätnej väzby. To
má za následok neustále aktuálnosť zadania a kontrolu kvality. Riadenie daného
projektu agilne tiež kladie zvláštny dôraz na ľudské zdroje, rýchle reagovanie na
časté zmeny a dodržovanie stanovených termínov. [8]
Správne pochopenie a schopnosť implementovať nové trendy pri riadení projektov môže byť rozhodujúcim faktorov na konkurenčnom trhu.
1.1 Motivácia a cieľ práce
Cieľom tejto práce je zoznámiť čitateľa s agilnými technikami – najmä v súčasnosti veľmi diskutovanou metodikou SCRUM – a ich typickými problémami pri
praktickej implementácii, s dôrazom na oblasti webových služieb a mobilných
riešení. Práve tieto oblasti sú, z autorovho pohľadu, v súčasnosti najrýchlejšie sa
2
1. Úvod
rozvíjajúcim a neustále sa meniacim IT odvetvím. Z tohto pohľadu sú to práve
tieto segmenty, ktoré musia vo svojom vývoji nutne presadiť agilné metodiky,
nakoľko rýchlosť a kvalita je v ich prípade existenčnou otázkou. Uvoľňovanie
nových verzií formou „veľkého tresku“ so sebou nesie vysoké riziko odmietnutia
a nepochopenia u používateľov, ako aj riziko zanesenia veľkého množstva chýb.
Veľa firiem deklaruje agilný vývoj, hoci v praxi ide často o životný cyklus softwaru
definovaný modelom vodopádu. Teda prevažujúce sú klasické (rigidné) metódy
vedenia projektu. Top manažment často akoby nemal odvahu prijať plné dôsledky
nasadenia agilných metodík a tak sa v praxi občas používa určitý hybrid – agilné
techniky prispôsobené pre „ich“ prostredie. Čím viac napätia v rámci dôsledku
nesprávne stanovených cieľov vzniká, tým viac sa viac sa začína pracovať klasicky,
„po starom“. Druhým extrémom je prílišné zameranie sa na podporné softwarové
riešenia, ktoré môžu mať za následok nedostatočné zapojenie členov tímu do
procesu vývoja. V oboch prípadoch môže dôjsť k postupnému zastavovaniu sa
iteratívneho/inkrementálneho cyklu a jeho následnému zavrhnutiu.
Mojím cieľom je poukázať na typické chyby, ktoré sa pri zavádzaní agilných
metodík robia a na ich dôsledky.
Základom praktického výstupu je analýza overeného riešenia na menších lokálnych spoločnostiach. Konfrontovaním tejto analýzy s potrebami väčších nadnárodných firiem vzniklo v praktickej časti tejto práce programové riešenie. Dôležitými vlastnosťami pre agilné tímy je schopnosť pre samo-organizáciu, možnosť
byť neustále v kontakte a nutnosť zapojenia sa do celého procesu. To môže byť na
globálnom trhu u nadnárodných spoločností s tímom zloženým s ľudí s rozličným
lokálnym pracovisko veľký problém. Výstupom praktickej časti je programové
riešenie reflektujúce tieto skutočnosti.
Motiváciou k vzniku tejto práce je moje jeden a pol ročné pôsobenie vo firme
Seznam.cz, a.s. Počas môjho pôsobenia v tejto spoločnosti som mohol sledovať
takmer zdvojnásobenie sa počtu vývojárov a problémy s tým súvisiace. V určitých oblastiach som tiež mal možnosť pozorovať tradičnú (ne)-organizovanosť a
postupnú implementáciu agilných techník do vývoja webových služieb. Počas
môjho pôsobenia som mohol experimentovať s aplikovaním rôznych agilných
metodík a metód – ako Extrémne programovanie, SCRUM, Vývoj riadený testami
(TDD), KANBAN, a ďalšie. Niektoré postupy sa ujali, iné nie.
Asi najviac diskutovanou bola metodika SCRUM, na ktorú som sa zameral najviac. Vyskúšal som si tiež zapojenie sa do role SCRUM Master, ako aj rolu člena
vývojového tímu. Mohol som teda túto metodiku pozorovať v plnej svojej kráse
so všetkými svojimi výhoda. Rovnako som bol denne konfrontovaný s jej ne3
1. Úvod
správnym použitím a nepochopením. Počas mojej dlhej praxe som mal možnosť
vyskúšať viacero experimentov a poznatky z nich sú odzrkadlené vo výstupe
praktickej časti. Dôležitým prvkom u tejto metodiky je silná zviazanosť tímu vývojárov, čo sa u tímu zloženého z ľudí s rozličnou geografickou polohou dosahuje
veľmi ťažko. Takéto tímy sú však stále častejšie, preto si praktická časť tiež kladie
za cieľ zmierniť ich problémy podporným softwarom.
Správnosť tohto riešenia je diskutovaná a verifikovaná v spolupráci so súkromným sektorom.
1.2 Prehľad práce
Práca je členená do siedmych kapitol. Prvá kapitola uvádza čitateľa do problematiky, stanovuje ciele a opisuje motiváciu vzniku práce.
Druhá kapitola pojednáva o softwarovom inžinierstve. Prináša stručný historický
pohľad na motiváciu k jeho vzniku. Opisuje prvotné problémy vývoja softwaru a
predstavuje inžinierske postupy, ktoré vznikli ako reakcia na ne.
Tretia kapitola je prehľadom niektorých dostupných metodík vývoja softwaru, ako
tradičných (rigoróznych), tak „moderných“ agilných. Záver kapitoly je venovaný
porovnaniu typických charakteristík pre tieto kategórie vývojových metodík.
Štvrtá kapitola rozoberá formou jednoduchej prípadovej štúdie súčasnú situáciu
u zadávateľa, ktorý už vyvíja pomocou agilnej metodiky SCRUM. Problémom je
snaha o zavedenie agilného vývoja u pracovných skupín s členmi s odlišnou fyzickou lokalitou. S tým súvisiacim problémom je chýbajúce programové riešenie
umožňujúce podporné funkcie ako pre vývojárov, tak manažment. Sú definované
požiadavky na tento software. V kapitole je následne analyzovaný najrozšírenejší
dostupný podporný software a konfrontovaný s požiadavkami od zadávateľa.
V kapitole je tiež obsiahnutá konfrontácia s nárokmi, ktoré na vývoj kladú technológie internetových a mobilných aplikácii. Na záver je diskutované optimálne
riešenie – implementácia vlastného programového riešenie.
Piata kapitola obsahuje analýzu a návrh programového riešenia. Ďalšia časť je
venovaná implementačným detailom ako návrhy obrazoviek, voľbu vhodných
prostriedkov z oblasti programovacích jazykov a architektúry. Analýze sú tiež
podrobené súčasné pokročilé vizualizačné postupy a spôsoby interakcie človeka
s počítačom a na základe toho navrhnuté moderné užívateľské rozhranie a jeho
4
1. Úvod
ovládanie. V kapitole sú ďalej ukážky a popis najzaujímavejších implementačných
častí.
Šiesta kapitola kontroluje kvalitu hotovej implementácie za pomoci funkčných,
výkonnostných a záťažových testov. Výsledky testov sú diskutované. Obsiahnuté
sú tiež informácie získané z praktického používania v súkromnom sektore.
Posledná kapitola je venovaná záverečnému hodnoteniu a sú diskutované možné
rozšírenia do budúcnosti.
1.3 Ujasnenie pojmov
V práci sa často vyskytujú pojmy, ktoré sa v bežnej komunikácii často zamieňajú.
Pre úplnosť je teda dobré pojmy pre účely tejto práce zadefinovať.
Pod pojmom:
• metodológia sa rozumie náuka o metodikách [13],
• metodika (vývoja softwaru) označujeme komplexné postupy a návody pre
vývoj softwarovej aplikácie [10],
• metóda označujeme nejaký konkrétny postup vedúci k vyriešeniu čiastkového problému.
Pojmy model životného cyklu (life-cycle model) a vývojový proces zastávajú v tejto práci
takmer ekvivalentný význam s pojmom metodiky, hoci v skutočnosti metodiky
zachádzajú v predpisovaní postupov a návodov o čosi hlbšie.
Práca je písaná v slovenskom jazyku a snaží sa nájsť ekvivalent k anglickej terminológii. Agilné metodiky sú v porovnaní s tradičnými metodikami stále horúcou
novinkou a tak v niektorých prípadoch ešte nedošlo k ustálenému prekladu určitých termínov, alebo sa priamo používajú termíny anglické. Snaha o zavádzanie
lokalizovaných termínov by v tomto prípade bola na úkor zrozumiteľnosti.
5
Softwarové inžinierstvo je
zavedenie a používanie riadnych
inžinierskych princípov tak, aby
sme dosiahli ekonomickej tvorby
softwaru, ktoré je spoľahlivý a
pracuje účinne na dostupných
výpočtových prostriedkoch. [1]
Kapitola 2
Friedrich L. Bauer
nemecký počítačový vedec
Softwarové inžinierstvo
2.1 História
V úplnom počiatku vývoja programov sa používal triviálny model „Napíš a
oprav“ (Code and fix model). Model vznikol úplne spontánne, svoje meno dostal
až neskôr. Jeho princíp spočíva v napísaní aplikácie, jej odovzdania a následnej
opravy chýb.
Implementácia
Dodanie aplikácie
Oprava chýb,
rozširovanie
Obr. 2.1: Schéma modelu „Napíš a oprav“ (Code and fix model) (prevzaté z [21])
V úplných začiatkoch tento model mohol vyhovovať, no veľmi skoro však začalo byť zrejmé, že vyvíjať software takýmto spôsobom nie je dlhodobo možné.
Tento jednoduchý model totiž absentuje akúkoľvek formu zberu požiadaviek na
software, nezaoberá sa návrhom, no rovno sa vrhá do fázy písania programu.
Preto bol v roku 1957 definovaný model založený na striktnej postupnosti fázy
(stagewise model). Tento model rozdeľuje vývoj softwaru do niekoľkých fáz (definícia problému, špecifikácia požiadavkou, návrh, architektúra, implementácia,
integrácia, prevádzka). [17]
6
2. Softwarové inžinierstvo
2.2 Softwarová kríza
V dobe končiacich šesťdesiatych rokov minulého storočia svetom softwaru otriaslo
ťažké obdobie, neskôr označené ako softwarová kríza. Charakteristickými znakmi
softwarovej krízy bolo neúnosné predlžovanie a predražovanie projektov, nízka
kvalita programov, nejednoduchosť/nemožnosť údržby a inovácií, zlá produktivita práce programátorov, neefektivita vývoja, neistota výsledku (do posledného
okamžiku bolo nejasné nielen to, či sa projekt oplatí, ale dokonca aj to, či bude
vôbec dokončený) a rada ďalších nepekných znakov. [10]
Ilustráciou softwarovej krízy je štatistika z jej obdobia, podľa ktorej zo všetkých
zákaziek pre americkú vládu (ktoré mali hodnotu mnoho miliónov dolárov), bolo
cez 40 % zákaziek dodaných, ale nikdy nebolo úspešne použitých. Zhruba 25 %
bolo zaplatený, no aj napriek tomu nebolo nikdy dodaných. Asi necelých 15 %
bolo po drastických úpravách zahodených. Len necelé tri percentá projektov bolo
po úpravách použitých a iba asi dve percentá produktov mohlo byť použitých
bez zmien. [17, 10]
Problémov, ktoré túto situáciu spôsobili bolo veľa – zlá komunikácia, nesprávny
prístup, zlé odhady, chybné plánovanie, podcenenie rizík, nízka produktivita
práce, a ďalšie. Najväčším problémom však bolo, že sa všetky tieto problémy vzájomne kombinovali a podporovali – výsledkom bola katastrofálna neefektivita.
Podstatnými investormi v tej dobe boli štátne inštitúcie a armády jednotlivých štátov, ktoré určovali, akým smerom sa má uchyľovať vývoj efektívnejších metód. [8]
Preto sa na konferencii NATO v roku 1968 [1] začal formovať nový koncept vývoja
a bol zavedený pojem práve softwarového inžinierstva. Novum v začiatkoch 70.
rokov predstavovalo vzniknutie nových techník, ako je napríklad špecifikácia,
návrh, testovanie, či modely životného cyklu (napríklad vodopádový model).
2.3 Model životného cyklu vývoja softwaru
Na prvý pohľad by sa mohlo zdať, že software je výrobok (produkt), ako každý
iný. Detailný pohľad však odhalí, že táto predstava nie je presná. Software sa
od iných odlišuje spôsobom „výroby“ a aj jeho následným používaním. Kým
u väčšiny klasických produktov zvyčajne existuje niekoľko exaktne zmerateľných
charakteristických parametrov, u softwaru to nie je také jednoduché. Vnútorná
kvalita softwaru (napríklad počet riadkov kódu, počet tried, atď.) je pre zákazníka
nič nevypovedajúci parameter. Definovať vonkajšiu kvalitu pomocou určitých
parametrov vôbec nie je jednoduché.
7
2. Softwarové inžinierstvo
Software je vo svojej podstate neviditeľná a nehmotná substancia. Z tohto dôvodu
je potrebné stavať sa k procesu vývoja softwaru inak, ako k výrobe klasického
hmatateľného produktu. Bežné inžinierske postupy teda nestačia, respektíve
nezohľadňujú podstatné špecifiká tvorby softwaru. Ďalším dôležitým rozdiel je
v spôsobe používania. Kým klasický produkt, napríklad chladničku, vyberieme
na základe parametrov a následne nemáme prakticky žiadnu možnosť na zmenu
niektorých jej častí, alebo jej rozšírenie, u programových riešení to býva inak. Dá
sa priamo očakávať, že zákazník bude po prevzatí programu potrebovať nielen
opravu chýb, ale aj následné zavádzanie nových funkcií.
Z vyššie uvedených informácií vyplýva, že je dôležité zamerať sa nielen na fázu
vývoja softwaru od prvého definovania problému po odovzdanie výsledku zákazníkovu, ale aj na nasledujúcu fázu opravy chýb a implementácií nových súčastí.
Z toho dôvodu vznikajú modely životného cyklu, ktoré zahŕňajú celé obdobie
používania softwaru od jeho vytvorenie až po jeho úplné nahradenie iným, alebo
vyradenie.
2.3.1 Vodopádový model
Definícia problému
Špecifikácia
požiadaviek
Špecifikácia nových
požiadaviek
Návrh
Implementácia
Vývoj
Údržba
Itegrácia
a testovanie
Údržba
Obr. 2.2: Vodopádový model životného cyklu (prevzaté z [21])
8
2. Softwarové inžinierstvo
Vodopádový model vznikol z veľkej časti ako riešenie najzávažnejších problémov,
ktoré viedli k obdobiu softwarovej krízy. Predstavuje veľmi vysokú abstrakciu
vývojového procesu. Jednoznačne definuje postupnosť vývojových fáz. Projekt
sa vždy nachádza iba v jednej vývojovej fáze, prechod medzi fázami prebieha
„po krokoch“ (teda ukončením jednej a prechodom na ďalšiu nasledujúcu fázu).
Jeho architektúra teda pripomína vodopád.
Napriek tomu, že tento model obsahuje niekoľko problémov, poslúžil ako podklad
pri vzniku efektívnejších spôsobov vývoja. Vo vodopádovom modely prechádza
projekt usporiadanými fázami. Každá fáza obsahuje akceptačné kritéria, ktoré
musí medziprodukt spĺňať, aby mohla byť fáza ukončená. Pri problémoch je
možné sa vrátiť do predchádzajúcej fázy, no stratíme hodnotu vytvorenú všetkými
nasledujúcimi fázami (fázy je potrebné zopakovať). Vodopádový model je silne
založený na dokumentoch (document driven) – dokumenty sú najdôležitejším
výstupom ukončených a súčasne podkladom pre nasledujúce fázy. [21]
Tento model je ešte aj dnes nezriedka používaný – dosahuje dobré výsledky pri
vývoji softwaru, u ktorého sú dopredu dobre známe všetky požiadavky. Prípadné problémy sú potom detekované dostatočne skoro a ich odstránenie nie
je veľký problém. Súčasne je tento model pomerne jednoduchý, jasný a ľahko
implementovateľný. Na druhej strane neposkytuje pre zákazníka hmatateľný výsledok (software namiesto dokumentov) a tak je zákazník často schopný priniesť
prvé zásadné pripomienky až v predposlednej fázy. Druhým problémom je, že
zákazník dostáva software formou „veľkého tresku“, nárazovo. Počas dlhého
obdobia vývoja zákazník nemôže meniť svoje požiadavky a súčasne nemôže
využívať ani časť systému, celé riešenie dostane na koniec.
2.3.2 Špirálový model
Vodopádový model čelil čoskoro po svojom vzniku množstvu pripomienok a
kritických poznámok. Nevýhody si postupne začala uvedomovať aj vtedajšia
softwarovo-inžinierska komunita, na ktorej čele stál Barry Boehm. Práve on
obohatil vývojársky svet o špirálový model životného cyklu. [10] Vznikol v roku
1986. [5]
Do procesu vývoja sú zavedené dva prelomové koncepty:
• iteratívny prístup,
• opakovanú a dôslednú analýzu rizík. [17]
9
2. Softwarové inžinierstvo
Vodopádový model bol postavený na priamočiarom postupe od zadania až po
odovzdanie systému. Problémom je, že zadanie môže byť na začiatku projektu
nejasné, alebo nekompletné, respektíve môže sa ešte v čase meniť. U špirálového
modelu prebieha vývoj v opakovaných cykloch, takzvaných iteráciách. V každej
iterácii sa vykonávajú fázy: stanovenie cieľov, analýza rizík, vývoj/testovanie a plánovanie. Opakovaním týchto fáz vlastne umožňuje cyklicky spresňovať špecifikáciu
a dotvárať produkt podľa konkrétnej situácie.
Výstupy každej iterácie sú odovzdané formou prototypu, na ktorom môže zákazník overiť správnosť vývoja. Ďalšou výhodou je zníženie nákladov tým, že sú
včas odhaľované chyby.
Z dnešného pohľadu má tento model niekoľko problémov. Kladie veľký dôraz na
dôveru vo vývojársky tím a v schopnosť ľudí identifikovať a analyzovať zdroje
rizík. Súčasne, vzhľadom k menším projektom ide o celkovo pomerne komplikovaný model – a tak je navyše zaťažený množstvom byrokratických povinností.
10
Všetky metodiky sú posvätné,
ak sú vnútorne potrebné.
Všetky metodiky sú hriechy,
pokiaľ nie sú odôvodnené
vnútornou potrebnosťou.
Kapitola 3
Wassily Kandinsky
ruský maliar
Metodiky vývoja softwaru
Klasické modely vývoja softwaru, ktoré sa pokúšali na software napasovať predstavu „sériového výrobku“ kládli dôraz na podrobné špecifikácie, rozsiahle
dokumentácie, robustný návrh a prepracovanú architektúru s postupom času
prestali stačiť požiadavkám na rýchlosť vývoja. Postupne sa na celý proces začína
nahliadať z iného uhla, vznikajú nové metodiky.
Za metodiku sa označujú komplexné postupy a návody pre vývoj softwarovej
aplikácie. Pod týmto pojmom sa skrývajú všetky etapy riešenia, metodika sa však
problematikou zaoberá viac z nadhľadu. Moderné metodiky môžu obsahovať
celý systém doporučení napríklad aj na odporúčanú dĺžku stretnutí, spôsob
rozmiestnenia ľudí v kancelárií a podobne.
3.1 Objektovo orientované iteratívne metodiky
Metodiky založené na objektovom prístupe na rozdiel od štruktúrovaných metodík nazerajú na dáta a funkcie ako na neoddeliteľnú súčasť objektu. [8] Takto sa
snažia pomocou predpísaných modelov dôveryhodnejšie zobraziť realitu. Medzi
základné modely objektových metodík patria najmä statické modely (napríklad
model tried) a dynamické modely (napr. diagram aktivít). [21]
11
3. Metodiky vývoja softwaru
3.1.1 Metodika Rational Unified Process (RUP)
Rational Unified Process (skratka RUP) je prepracovaná, rozsiahla, objektovo orientovaná iteratívna metodika vývoja softvéru vytvorená spoločnosťou Rational
Software Corporation (ktorá bola neskôr zakúpená spoločnosťou IBM). [10] Metodika RUP vychádza z kolekcie osvedčených praktík a postupov pri vývoji
softvéru. Metodika RUP je distribuovaná a prístupná ako súhrn internetových
stránok tvoriacich znalostnú bázu (resp. procesný rámec – process framework).
Je vhodná primárne pre rozsiahlejšie projekty a väčšie vývojárske tímy (keďže
kladie dôraz na analýzu a dizajn, plánovanie, riadenie zdrojov a dokumentáciu),
no je možné ju upravovať aj pre menšie projekty (ale použiť niektorú, ktorá z RUP
vychádza).
Korene metodiky siahajú do roku 1987, kedy Ivar Jacobson zužitkoval svoje skúsenosti a vyvinul metodiku Objectory Process, v ktorom sa prvýkrát objavuje koncept
prípadov použitia (use-case) a objektovo orientovaného návrhu. V roku 1995 vznikol vo firme Rational koncept iteratívneho vývoja a architektúry, ku ktorému
pripojila princípy získavania a riadenia požiadaviek (requierements management),
čo viedlo v roku 1996 ku vzniku produktu Rational Objectory Process 4.0. [10]
Metodika RUP definuje 6 základných a všeobecných praktík pri vývoji softwaru:
• Iteratívny vývoj – problém tradičného vývoja je, že pred sebou „tlačí“ rizika,
ktorých odstránenie je postupne stále nákladnejšie. Naproti tomu v iteratívnom a inkrementálnom vývoji, ktorý vychádza z Boehmovho špirálového
modelu (Obrázok 2.3.2) dochádza k detekcií rizík priebežne.
• Správa a riadenie požiadaviek – požiadavky sú zvyčajne dynamické a je potrebné počítať s tým, že sa v čase menia.
• Použitie komponentovej architektúry – ak je vyvíjaný systém otvorený k použitiu iných komponent, môže byť vývoj efektívnejší. Znovu použitie hotovej
komponenty znamená úsporu zdrojov.
• Vizuálne modelovanie softwaru – model je zjednodušením reality, je vytváraný
za účelom dokonalejšieho porozumenia systému. Použitie štandardného
modelovacieho jazyka UML znamená zjednodušenie komunikácie.
• Priebežné zaisťovanie a overovanie kvality – nájdenie a odstránenie problému je
100krát až 1000krát drahšie po odovzdaní produktu než v úvodných fázach
vývoja.
• Riadenie zmien (change management) – neriadené zmeny vedú k chaosu. [14]
RUP ďalej definuje štyri základné, najdôležitejšie elementy modelovania, na
ktorých stojí nielen modelovanie, ale je sú prenesené na celý vývojový proces:
12
3. Metodiky vývoja softwaru
• Pracovníci workers a role roles – pracovníci odpovedajú na otázku kto. Chovanie pracovníka je popísané pomocou činností (activities). Zodpovednosť
je obvykle definovaná vo vzťahu k medziproduktom (artifacts).
• Činnosti activities – odpovedajú na otázku ako. Činnosťou sa rozumie jednotka práce, ktorú má vykonať jednotlivec alebo skupina a ktorá ma vyústiť
do zmysluplného výsledku v kontextu projektu.
• Medziprodukty activities – odpovedajú na otázku čo. Ide o časť informácie, ktorá je produkovaná, modifikovaná alebo použitá v rámci procesu
(napríklad model, dokument, zdrojový kód,. . . ).
• Pracovné procesy workflows – odpovedajú na otázku kedy. Jedná sa o definíciu postupnosti činností a stanovenie interakcie medzi pracovníkmi. [10]
RUP teda podrobne odpovedá na všetky otázky súvisiace s procesom tvorby softwaru, ktoré začínajú slovami kto, čo, kedy a ako. [10] RUP popisuje proces vývoja
v dvoch úrovniach. Prvá definuje štyri základné fázy vývoja, ktoré sú z časového
hľadiska organizované do iterácii. Po skončení každej fázy sa vykonáva hodnotenie dosiahnutých cieľov danej fázy (milestone). [21] Druhá úroveň popisuje aké
príbuzné aktivity (disciplíny) a v akej miere sú vykonávané v priebehu vývoja.
Vývoj (podľa RUP) prebieha v cykloch (iteráciách) – realizácia projektu môže byť
rozdelená do viacerých častí, v rámci ktorých sa opakujú rovnaké procesy naprieč všetkými disciplínami. Každá cyklus má podobu menšieho vodopádového
modelu – obsahuje jeho všetky fázy od analýzu po testovanie. Iterácia je teda
rozdelená do štyroch fáz:
• zahájenie (inception) – definovanie požiadaviek a cieľov,
• rozpracovanie (elaboration) – definovanie architektúry systému,
• budovanie (construction) – návrh a realizácia systému,
• zavedenie (transition) – nasadenie systému do prevádzky. [14]
V rámci každej z fáz sa realizujú činnosti každej disciplíny, no s rozdielnym
dôrazom. Napríklad na začiatku iterácie strávime viac času pri požiadavkách,
zatiaľčo v neskoršej fáze sa kladie dôraz na implementáciu.
Metodika implementuje k vizualizácií „dokumentov“ pre lepšie porozumenie
vyvíjaného softwaru vizuálny model, ktorý je založený na modelovacej notácií
Unified Modeling Language (UML).
Najsilnejšou stránkou tejto metodiky je jej všeobecnosť, šírka a mohutnosť – vďaka
čomu je vhodná pre širokú škálu projektov. Ďalšie výhody vyplývajú z iteratívneho prístupu (včasné odhalenie rizík, jednoduchšia správa zmien, lepšia znovu
použiteľnosť, vývojový tím sa môže priebežne zdokonaľovať, dobrá kontrola projektu atď.). Za výhodu tiež možno považovať tiež detailnú prepracovanosť, vďaka
13
3. Metodiky vývoja softwaru
ktorej sú podrobne zdokumentované všetky kroky. Objektová orientovanosť metodiky umožňuje lepšie priblíženie k problému, realistickejšie modelovanie a
intuitívnejšie uchopenie situácie. Navyše, výrobca priebežne pracuje na vývoji
metodiky – tím skúsených odborníkov vytvára pravidelne nové verzie s podporou nových štandardov. Spolu s metodikou firma dostane aj celý rad užitočných
nástrojov. Výhoda RUP tiež spočíva v možnostiach jeho prispôsobenia.
Niektoré z týchto silných stránok môžu byť súčasne interpretované aj ako nevýhody v závislosti na konkrétnom projekte a požiadavkách. Rozsiahlosť RUP
môže byť na škodu pri menších tímoch pracujúcich na rozsiahlejších projektoch
– tím môže stráviť príliš veľa času skúmaním metodiky a následnou tvorbou
medziproduktu a potrebnej byrokratickej činnosti. Vývoj tak môže začať strácať
efektivitu. Rozsiahlosť metodiky vyžaduje hlboké štúdium.
Značnou nevýhodou je nakoniec samotný fakt, že RUP je komerčným produktom (s nie malou nákupnou cenou) a tak sa stáva pre veľkú skupinu vývojárov
prakticky nedostupný.
3.1.2 Metodika Unified Software Development Process
V predchádzajúcej kapitole sme si uviedli ako jednu z veľkých nevýhod metodiky
RUP (vzhľadom k cieľu výskumu v oblasti malých a internetových tímoch) jej
komerčnú dostupnosť – teda nie malú vstupnú investíciu. V tomto prípade môže
poslúžiť metodika Unified Software Development Process (skrátene UP1 ), ktorá je
RUP nesmierne podobná a súčasne bezplatne dostupná.
3.1.3 Vzťah RUP/UP k internetovým projektom a malým tímom
Všeobecne je možné prehlásiť, že použitie metodiky RUP/UP malými tímami a
pre internetové projekty nie je úplne vylúčené. Architektúra RUP/UP je natoľko
robustná a adaptabilná, že umožňuje prispôsobiť proces prakticky akokoľvek
úzkemu tímu a akokoľvek malému projektu.
Pracovníci v rámci RUP/UP majú skôr úlohu „klobúkov“ – jeden fyzický človek
môže zastávať viac rolí. Aj úzky tímy teda môžu RUP/UP použiť, podmienkou je
jedine vhodné „namapovanie“ pracovníkov. [10]
1. Pretože názov Unified Software Development Process (USDP) je pomerne krkolomný a ťažko
zapamätateľný, používa sa bežné skrátené označenie Unified Process (UP).
14
3. Metodiky vývoja softwaru
3.2 Agilné metodiky
V predchádzajúcich kapitolách sme si ukázali, že tradičné technicky aj napriek
svojej sile a prepracovanosti nie sú vždy najlepšou voľbou pre malé a pružné
projekty, typické pri vývoji webových aplikácií. Najväčším problémom týchto
techník v rámci nášho kontextu je príliš veľký náklad na byrokratickú réžiu a súčasne nedostatočná pružnosť na zmeny. Kvôli tomu sa v tejto kapitole zameriame
na agilné techniky.
Podľa prieskumu realizovaného Scottom W. Amblerom zlyhávajú softwarové
projekty vedené tradičným spôsobom častejšie, než projekty vedené agilným
spôsobom. [8] Jednou z príčin je, že väčšina tradičných techník spolieha na
schopnosť klienta v úvode ucelene definovať požiadavky už v počiatku vývoja a
že si následne svoje zadanie nerozmyslí a nebude ho chcieť zmeniť. Pri vývoji
webových služieb však rozhodne nie je možné pracovať s predpokladom presne
definovanej špecifikácie v iniciálnej fáze vývoja.
Najmä v súčasnosti pri tak veľkom rozmachu Internetu a obrovskej konkurencii
je rýchlosť vývoja veľmi dôležitým kritériom kvalitných projektov. Každú hotovú funkcionalitu je potrebné okamžite dostať do produkcie. Pri tak závratnej
rýchlosti rozvoja a zmeny trendov by sa mohlo stať, že odkladané nasadenie
hotovej funkcionality do prevádzky už v čase svojho oneskoreného uvedenia
nebude vyhovovať aktuálnym požiadavkám. Rovnako, ako rýchlo sa dnes menia trendy a technológie, podobne to môže byť aj so špecifikáciou požiadaviek.
Konkurenčné prostredie si vyžaduje adaptáciu techník, ktoré umožňujú veľmi
pružne upravovať zadanie a ciele projektu.
Historicky prvýkrát bol agilný vývoj implementovaný v spoločnosti Toyota v roku
1949. Po druhej svetovej vojne bolo potrebné obnoviť produkciu, no Japonský trh
potreboval na rozdiel od Ameriky vyrábať veľa rôznych modelov áut s odlišnou
výbavou. Z toho dôvodov do vývoja zaviedli biznis metódu Just in Time (JIT)
(štíhla výroba, lean development). [23]
Takzvané „ľahké“ (lightweight) metodiky vývoja softaru vznikli v strede 90-tych
rokov ako reakcie proti „ťažkým“ (heavyweight) metodikám, ktoré boli kritizované pre svoju silnú reguláciu, prísnu riadenosť (často so sklonom k mikromanažmentu), či založené na vývoji typu vodopád.
Pod pojmom agilný vývoj si je možné predstaviť vývoj, ktoré je rýchly, vrtký, čulý,
aktívny a svieži, ktorý nepostáva zdĺhavo u jednotlivých fázy. Jeho túhou je čo najrýchlejšie postupovať k vytýčenému cieľu – k dodaniu fungujúcej aplikácie. [10]
15
3. Metodiky vývoja softwaru
Agilný vývoj softwaru je skupina metodík vývoja softwaru založená na iteratívnom a inkrementálnom vývoji, pričom požiadavky a riešenia vznikajú na
základe spolupráce v seba-organizovaných (self-organizing) a viac-odborových
(cross-functional) tímoch. To podporuje adaptívne plánovanie, evolučný vývoj a dodávky, v dopredu časovo ohraničených intervaloch, a podporuje rýchle a pružné
reakcie na zmeny. Jedná sa o koncepčný rámec, ktorý podporuje predpokladané
interakcie počas vývojového cyklu. Tento termín bol zavedený v dokumente
Agilný Manifest [12] (Agile Manifesto) v roku 2001.
3.2.1 Agilný manifest
V roku 2001 sa na jednom mieste (americký Utah) zišli najvýznamnejší predstavitelia nových prístupov v tvorbe softwaru. Už predtým mnohí z nich pracovali
na návrhu nových metodík. Na svojich metodikách pracovali nezávisle, avšak
čiastočne o svojej činnosti navzájom vedeli a začali zisťovať, že ich výtvory (aj
napriek tomu, že sa v mnohom odlišujú) obsahujú zároveň prekvapivé množstvo spoločných princípov. [10] Na spoločnom stretnutí sa po podrobnej analýze
jednotlivých metodík zhodli na základných tézach, z ktorých následne vzišla
formulácia Manifestu agilného vývoja.
Odhalili sme lepší spôsob vývoja softwaru, sami ho používame a chceme pomôcť aj
ostatným, aby ho používali. Z tohto pohľadu dávame prednosť:
• individualitám a komunikácií pred procesmi a nástrojmi,
• prevádzkyschopnému softwaru pred rozsiahlou dokumentáciou,
• spoluprácou so zákazníkom pred ujednávaním kontraktu,
• reakciou na zmenu pred plnením plánu. [6]
3.3 Prehľad agilných metodík
V tejto kapitole sa zameriame na najrozšírenejšie agilné metodiky. Dôraz pri ich
analyzovaní je kladený na ich špecifiká pri implementácii do vývoja moderných
webových a mobilných aplikácií.
3.3.1 Extrémne programovanie (XP)
Extrémne programovanie (XP) patrí v súčasnosti medzi jednu z veľmi rozšírených
agilných metodík, hoci jej vrchol už bol pravdepodobne dosiahnutý pred dvoma
16
3. Metodiky vývoja softwaru
až troma rokmi. Aj napriek tomu je stále chápaná ako určitý hlavný predstaviteľ
všetkých agilných techník. Na rozdiel od iných agilných prístupov, ktoré často
vychádzajú z desiatky rokov používaných princípov v iných odvetviach, XP je
pomerne mladou technikou. Vznik extrémneho programovania sa datuje do roku
1999. [10] XP predstavuje účinný, flexibilný, zábavný a predvídateľný spôsob
vývoja softwaru, využíva veľmi rozumný prístup a realistický spôsob myslenia
(zdravý rozum) – avšak ich používanie doťahuje do „extrémov“:
• jednoduchosť – systém ponechávame v najjednoduchšej podobe, ktorá
vyhovuje požiadavkám,
• revízie – ak sa osvedčia revízie a kontroly zdrojového kódu, budeme revidovať a kontrolovať priebežne (párové programovanie),
• návrh – ak sa osvedčuje návrh, budú všetci každodenne navrhovať a vylepšovať existujúci návrh (refaktorizácia),
• architektúra – bude neustále vylepšovaná a prepracovávaná (metafora),
• testovanie funkcionality – ak sa osvedčuje testovanie, všetci budú priebežne
testovať (unit testing),
• krátke iterácie – tesná prepojenosť so zákazníkom; snaha eliminovať metódu
dodávania „veľkého tresku“; iterácie extrémne krátke – sekundy, minúty a
hodiny. [6]
XP je metodika vhodná pre malé až stredné tímy (typicky sa uvádza počet od
dvoch do desiatich programátorov), ktoré sa pri vývoji musia vyrovnať s rýchlo
sa meniacim a nejasným zadaním. Základným filozofickým východiskom extrémneho programovania je presvedčenie, že jediným exaktným, jednoznačným,
zmerateľným, overiteľným a nespochybniteľným zdrojom informácií je zdrojový
kód. [10]
XP mierne modifikuje tri tradičné premenné vývojového cyklu (Obrázok 3.2) a
navyše predstavuje štvrtú premennú s najväčším dôrazom:
• kvalita (zodpovedá funkcionalite),
• čas,
• náklady (zodpovedá zdrojom),
• šírka zadania (nová premenná). [20]
Dôležitou axiómou XP je, že zákazníci, zadávatelia a manažéri stanovujú hodnoty ľubovoľných troch premenných – výslednú hodnotu zostávajúcej, štvrtej
premennej potom vyberie vývojový tím. Ak s výslednou premennou nebudú
spokojní, môžu predefinovať tri vstupné premenné. XP si je vedomé, že manažéri/zákazníci majú tendenciu stanovovať všetky štyri premenné, čo má za
následok drastické zníženie kvality. [10] Tím bude pracovať pod stresom a na
17
3. Metodiky vývoja softwaru
kvalitu neostane čas. Práve preto XP umožňuje tejto skupine definovať iba tri
premenné a v prípade nespokojnosti môže upraviť jedine svoje vstupy.
Medzi dôležité pojmy XP patria štyri pojmy:
• komunikácia – ako náhle sa v projekte objavia problémy alebo oneskorenie,
existuje veľká pravdepodobnosť, že ich prvotná príčina je v komunikácii
(typicky je možné v tíme objaviť osobu, ktorá zabudne alebo nenájde odvahu
oznámiť niekomu inému dôležitú informáciu),
• jednoduchosť – XP čiastočne riskuje, keď sa pýta: „Ako vypadá najjednoduchšia vec, ktorá ešte môže fungovať?“, avšak typicky je lepšie (aj z ekonomického hľadiska) urobiť jednoduchú vec čo najskôr a za prípadnú zmenu
(ak bude vôbec vyžadovaná) zaplatiť radšej neskôr,
• spätná väzba – informuje o tom, v akom stave sa práve nachádza vývojový
systém a tím a o všetkých záležitostiach, ktoré sa vývoja týkajú; najčastejšie
je realizovaná metódou testovania,
• odvaha – použitie XP bez odvahy je prakticky vylúčené,
a pod týmito štyrmi hodnotami leží ešte piata, podprahová hodnota:
• rešpekt – členovia tímu sa musia zaujímať o to, čo ktorý z nich práve robí a
nepracovať samostatne, podľa svojich vlastných pravidiel. [2]
V predchádzajúcich paragrafoch definované hodnoty tvoria ideový základ XP,
každopádne nestačia k vytvoreniu funkčnej metodiky. Preto obsahuje XP 12
základných postupov, ktoré by mali viesť k vytváraniu kvalitných softwarových
produktov:
1. Plánovacia hra – cieľom je zapojiť celý tím do vytvorenia plánu.
2. Malá verzia – nové verzia sú uvoľňované často a v čo najmenšej konfigurácii.
3. Metafora – celý vývoj je vedený pomocou jednoduchého príbehu o tom,
ako má celý systém fungovať. Výhodou metafory je, že jej rozumejú všetky
zainteresované strany.
4. Jednoduchý návrh – systém je navrhovaný najjednoduchšie, ako je to v daný
moment možné.
5. Testovanie – nakoľko XP neobsahuje žiaden explicitne definovaný návrh,
jedinou možnosťou ako udržať kvalitu je priebežne testovať.
6. Refaktorizácia – reštrukturalizácia systému bez zmien v jeho chovaní pomáha systém zjednodušovať, zlepšuje komunikáciu, odstraňuje duplicity a
podobne. Nevykonáva sa neustále, ale iba keď je naozaj potrebná.
7. Párové programovanie – zdrojový kód píše dvojica programátorov, ktorá
zdieľa jeden monitor, klávesnicu a počítač. V každom páre sú dve role –
človek, ktorý „vlastní“ klávesnicu premýšľa o najlepšom spôsobe implementácie na aktuálnom mieste, jeho kolega premýšľa o globálnej stratégii.
18
3. Metodiky vývoja softwaru
8. Spoločné vlastníctvo – niektoré metodiky implementujú pravidlo vlastníctva
kódu (autor triedy je za ňu zodpovedný a má ako jediný právo rozhodovať
o pridaní nových metód). XP považuje za svoje pravý opak – ktokoľvek
môže zmeniť ktorúkoľvek časť kódu v akomkoľvek čase. 2
9. Nepretržitá integrácia – systém je integrovaný, zostavovaný a testovaný niekoľkokrát denne (najmenej jedenkrát).
10. Štyridsaťhodinový pracovný týždeň – dlhodobé nadčasy vedú k preťažovaniu
ľudských zdrojov a ústia v neefektivitu.
11. Zákazník na pracovisku – skutočný používateľ alebo zákazník sa po dobu
vývoja stáva súčasťou tímu.
12. Štandardy pre písanie zdrojového textu – je nutné, aby programátori pri písaní dodržiavali pravidla, ktoré umožnia komunikáciu prostredníctvom
zdrojového kódu. [3]
XP je „ľahkou“ metodikou – nepredpisuje kroky exaktne, ale ponecháva ich
konkrétnu podobu na potrebách a možnostiach v tíme. Čiastočne je XP možné
kombinovať s inými metodikami. Jednou z veľkých výhod je, že práca je v XP
v súlade s ľudskými inštinktmi a nie proti nim. Ďalšie výhody vyplývajú z iteratívneho, inkrementálneho spôsobu vývoja. XP netrvá na formalitách, postup
k cieľu je priamočiary. Táto metodika je nesmierne vhodná práve pre malé tímy
do 10 členov. U internetových projektov, u ktorých viac ako kde inde záleží na
včasnom dodaniu, je filozofia okamžitého zahájenia implementácie v priamom
súlade s potrebami tímu a zákazníka. Neposlednou výhodou je veľký rozšírenosť
tejto metodiky, je teda o nej možné nájsť celý rad zdrojov informácii.
XP je jednoduché v detailoch, ale zložité pri vykonávaní. [2] Nevýhodou je ťažká
praktická realizácia, najmä pri prvom použití v tíme si členovia musia zvykať.
Zložité môže byť robiť veci jednoducho, naučiť sa komunikovať so zákazníkom,
pripustiť neznalosť, tímovosť a podobne. Ľudia v XP tíme sa musia naučiť nehanbiť
sa za svoje emócie a vyjadrovať ich, inak sa po krátkej dobe môže znížiť výkonnosť
celého tímu. Z toho všetkého vyplýva, že nie každý človek je vhodný do XP tímu.
Nie vždy je však možné niektorých ľudí do vývoja nezahrnúť, obzvlášť v menších
firmách.
V súčasnosti typické použitie XP je vo veľmi malých projektoch, respektíve implementácia určitých metód XP do inej agilnej metodiky – napríklad kombinácia
metodiky SCRUM (Kapitola 3.3.5) a metódy párového programovania vyňatej
z XP.
2. Tento bod znamená zvýšenie truck faktoru, ktorého hodnota 1 znamená, že každej časti zdrojového kódu rozumie práve jeden expert.
19
3. Metodiky vývoja softwaru
3.3.2 Lean development
Metodika Lean development3 má svoje korene v iných inžinierskych (a predovšetkým výrobných) disciplínach. [10] Vychádza z metodiky štíhlej výroby (Lean
manufacturing), ktorú vyvinula firma Toyota po 2. svetovej vojne.
Hlavnou myšlienkou je absolútne odstránenie všetkého zbytočného, čo v priebehu vývoja vzniká a môže znížiť efektivitu a zvýšiť náklady. Lean development
je definovaný ako systematický prístup k identifikovaniu a eliminácii možných
zdrojov plytvania v priebehu celého vývojového procesu, ktorý sa pokúša dodať zákazníkovi perfektný produktu a splniť tak jeho požiadavky. [20] Nejde
o exaktnú metodiku popisujúcu, akým spôsobom vyvíjať, poskytuje však rad
princípov a pravidiel, ktorých dodržiavanie povedie k efektívnejšiemu vývoju a
ekonomickejším výsledkom.
Lean development je postavený na desiatich všeobecných pravidlách, ktoré boli
definované už pre systém Lean manufacturing:
1. Odstrániť plytvanie – všetko, čo je zbytočné (vytváranie toho, čo zákazník
nepoužije či nepotrebuje; málo či žiaden čas na učenie, tvorba nepoužívanej
dokumentácie).
2. Vstavaná kvalita (lepšie je chyby neurobiť vôbec, než ich vedieť efektívne
opravovať).
3. Bez učenia sa nezaobídeme (bez spätnej väzby sa nemôžeme učiť a zlepšovať, rozhoduje sa až so znalosťou kontextu a možných variant).
4. Vývoj je „ťahaný dopytom“ – väčšina rozhodnutí sa uskutočňuje tak neskoro, ako je to len možné.
5. Doručujeme rýchlo – maximalizácia toku (rýchla spätná väzba pre tím,
zákazník môže niektorú funkcionalitu okamžite používať).
6. Rešpektujeme ostatných (aby sme vytvorili vhodné prostredie pre ich motiváciu, znamená to tiež nastavenie organizačnej štruktúry, systému, nástrojov
a slobody).
7. Vybudovať kultúru pre možnosť neustáleho zlepšovania celého systému
(nespoliehať sa na na best practices, ale overovať hypotézu v praxi; neustále
vystavovať proces konštruktívnej kritike a zlepšeniu; vychovávať v tíme
vodcov). [7]
Lean development teda nie je žiadnou striktnou metodikou, či komplexným popisom vývoja softwaru. Táto metodika jedine naznačuje, akým spôsobom by mal
3. Lean development ešte nemá ustálený slovenský preklad, vychádza však z metodiky Lean
manufactoring, ktorá sa prekladá ako Štíhla výroba. Správny preklad by teda mohol byť Štíhly vývoj,
no v odborných kruhoch sa oveľa častejšie vyskytuje pôvodný anglický termín.
20
3. Metodiky vývoja softwaru
vývoj prebiehať a ako by nemal byť uskutočňovaný, čoho by sa mal vyvarovať
a kam by mal smerovať. V praxi sa v súčasnosti veľmi často uplatňuje o vývoji
veľmi nestálych systémov, v ktorých sa požiadavky menia veľmi razantne a často.
Príkladom dobrého uplatnenia tejto metodiky môže byť pri údržbe systému a
podobne.
V súčanosti veľmi diskutovaným konceptom, ktorému ako základ poslúžili myšlienky Lean development, je KANBAN. Ide o systém delenia výroby pomocou
KANBAN karty. Karta identifikuje novo vyrábané výrobky a súčasne slúži ako
objednávacia karta. Pomocou jednoduchého princípu je možné sledovať celý
proces a minimalizovať zásoby. V IT sa KANBAN implementuje ako tabuľa, ktorej stĺpčeky reprezentujú jednotlivé stavy výroby. Pomocou KANBAN tabule je
možné vizualizovať celý proces, hľadať úzke hrdlá (bottle neck) a zlepšovať proces.
3.3.3 Vývoj riadený vlastnosťami softwaru (FDD)
Vývoj riadený vlastnosťami softwaru (anglicky Feature Driven Development) je
agilný a flexibilný prístup k vývoju, v ktorom hrajú hlavnú rolu vlastnosti výsledného produktu. Zjednodušene – FDD postupuje po „jednotlivých vlastnostiach“,
ktoré sú pri vývoji kľúčovým stavebným kameňom.
FDD predstavil Jeff De Luca a Peter Coad v deväťdesiatych rokoch minulého storočia. [10] Metodika umožňuje ľuďom – základným pilierom akéhokoľvek projektu
– pracovať efektívne a produktívne, ktorá znižuje množstvo zmätku, neistoty a
nervozity pri vývoji a ktorá maximalizuje produkciu – kladie silný dôraz na výsledný produkt. Vlastnosťami softwaru sú elementárne funkcionality prinášajúce
používateľovi hodnotu.
Vývoj podľa metodiky FDD začína vytvorením celkového, globálneho modelu
systému – definuje smerovanie celého systému. [10] Vývoj ďalej pokračuje krátkymi iteráciami, odporúčaná dĺžka je dva týždne, no konkrétny rozsah závisí na
rozsahu produktu a situácii. Jedným z dôležitých aspektov FDD je dodávanie
nových beta verzií. Odporúčanie tejto metodiky je, že by zákazníkovi mal byť
dodaný funkčný medziprodukt s nejakými novými funkcionálnymi prírastkami
zhruba každé 1 až 3 týždne, po skončení každej iterácie.
Kľúčovým pojmom je predovšetkým vlastnosť – z pohľadu FDD definovaná ako
malý výsledok (malá časť funkčnosti) užitočný z pohľadu zákazníka. Dôležitými
charakteristikami vlastností sú predovšetkým: merateľnosť, zrozumiteľnosť a
realizovateľnosť. [10]
21
3. Metodiky vývoja softwaru
FDD definuje niekoľko ľahkých procesov:
1. vytvorenie celkového(globálneho) modelu – približne 10 % celkového času,
2. vypracovanie podrobného zoznamu vlastností – približne 4 % celkového
času,
3. plánovanie (podľa vlastností) – zaberie cca 2 % času,
4. návrh (podľa vlastností),
5. implementácia (podľa vlastností) – vykonáva sa spolu s návrhom v krátkych
iteráciách a zaberie približne 77 % celkového času potrebného pre celý
projekt. [10]
Metodika nedefinuje presný postup pre každú proces, predpisuje jedine, že osoba
s rolou hlavného programátora musí vedieť, ako konkrétne robiť jednotlivé činnosti (vedúce k dosiahnutiu výsledku v každom procese). Pokiaľ to zodpovedná
osoba nevie, je nutné do procesu zahrnúť poradcu.
FDD prichádza s niekoľkými inovatívnymi princípmi, ktoré sú neskôr využité aj
v iných vývojových procesoch:
• Objektové modelovanie domén – spočíva vo vytváraní diagramu tried (class diagram) znázorňujúcich významné objekty vo vnútri jednej domény (v rámci
oblasti jedného problému) a vzťahy medzi nimi. Umožňujú zachytiť dedičnosť a navyše modelovať aj operácie uskutočňované nad objektami (ich
metódy). Autori FDD naviac odporúčajú rozšíriť diagramy tried o diagramy
postupností (Sequence Diagrams).
• Vývoj podľa vlastností – zákazník (doménový expert) vytvorí zoznam funkčných požiadaviek, ktoré prinášajú používateľovi priamu hodnotu. Túto
podmnožinu funkcií nazýva FDD vlastnosťami. Zoznam je možné kategorizovať a prioritizovať. Takýto vývoj prináša niekoľko výhod, napríklad
priamu kontrolu plnenia zákazníckych požiadaviek.
• Vlastníctvo tried – každá trieda má vlastníka, ktorý zodpovedá za jej úspešnú
implementáciu a otestovanie.
• Tímy zostavované podľa vlastností – vznikajú tímy, ktorých úlohou je implementovať jednu vlastnosť. Jeden človek je zároveň členom viacerých tímov.
Tímy vznikajú a zanikajú dynamicky. Veľkosť tímu je obvykle medzi tromi
až šiestimi vývojármi. [10]
V rámci metodiky FDD sa vytvorí kategorizovaný zoznam vlastností podľa toho,
ako prebiehajú rozhovory so zadávateľom – doménovým expertom. Nad týmto
zoznamom potom prebieha vývoj v rámci ktorého priebežne vznikajú a zanikajú
tímy majúce na starosti návrh a implementáciu konkrétnej vlastnosti.
22
3. Metodiky vývoja softwaru
Táto metodika je vhodná skôr pre menšie projekty, ktoré je možné špecifikovať
súhrnom vlastností – rozhodne však ide o väčšie projekty, ako zvláda (napríklad)
XP (Kapitola 3.3.1), nakoľko FDD vďaka deleniu na tímy lepšie škáluje. Prináša
niekoľko inovatívnych metód a veľa výhod. V súčasnosti sú už však známe
aj niektoré z nevýhod plynúcich z použitia tejto metodiky – napríklad proces
vlastníctva tried môže vytvárať medzi vlastníkom a triedou určitý „citový vzťah“.
Ten potom na jednej strane nedopustí jej nekvalitný obsah, v určitých prípadoch
však nedopustí ani jej kvalitné otestovanie. Navyše, ako náhle vlastník odíde,
stratí tým človeka, ktorý sa v danom kóde ako jediný dostatočne vyzná. Novšie
metodiky teda vyberajú osvedčené postupy a idey z FDD a snažia sa vyhnúť
podobným problémom.
3.3.4 Vývoj riadený testami (TDD)
Vývoj riadený testami (anglicky Test-Driven Development) kladie dôraz predovšetkým na testovanie vyvíjaného produktu a stavia testovanie na vrchol pyramídy
jednotlivých krokov pri vývoji softwaru. Testovanie je jednou z najznámejších a
najviditeľnejších zložiek v oblasti zaisťovania kvality (Quality Assurance, QA).
Test-Driven Development (TDD) vyžaduje vytvorenie testu ešte pred napísaním
samotného kódu, ktorý sa má testovať. [11] Po vytvorení testu programujeme
funkčnosť, pričom implementujeme presne také množstvo programového kódu,
koľko dokáže prejsť samotným testom. Po dokončení zdrojového kódu, ktorý
úspešne prejde testovaním nastáva fáza úprav prostredníctvom refaktorizácie
(úprav kódu bez zmeny jeho funkčnosti).
Vývoj riadený TDD prechádza nasledujúcimi krokmi:
1. Čo najrýchlejšie vytvorenie testu. V tomto okamžiku test nemôže prebehnúť
úspešne.
2. Spustenie všetkých doterajších testov (v prípade veľmi veľkého projektu
určitej ich podmnožiny). Testy nesmú prejsť úspešne.
3. Písanie/úprava samotného zdrojového kódu. Až v tomto kroku začína
z hľadiska produktu vznikať funkcionalita.
4. Spustenie nad novým programovým kódom všetkých dostupných testov
(prípadne ich podmnožiny). V prípade neúspešného testu sa vracia k predchádzajúcemu kroku.
5. Úpravy nad súhrnom testovacích prípadov, prípadné odstránenie duplicít.
Presunutie testu do testovacej sady, je však potrebné skontrolovať, že nebola
porušená integrita testov a ich logická previazanosť. [4]
23
3. Metodiky vývoja softwaru
V praxi sa častejšie používajú automatizované testovania, z otestovaného kódu sa
pravidelne automaticky zostavujú balíky určené k produkčnému použitiu (release
package). Kent Beck definoval dve jednoduché pravidlá k použitiu TDD:
1. Nový aplikačný kód píšeme v prípade, že automatizovaný test zlyhal.
2. Je nutné eliminovať akékoľvek duplicity, ktoré nájdeme. [4]
Dôležité je vytvárať testy efektívne, musia bežať rýchlo, nezávisle a poskytovať
správne a pochopiteľné výstupné dáta. Súčasne reprezentujú krok k celkovému
cieľu, splnením testu by malo byť zrejmé, aká nová funkcionalita bola do programu pridaná a aké nové funkcie sú k dispozícii. Akceptačné testy sú dôležitou
súčasťou dokumentácie.
Myšlienkou TDD je nepísať zbytočne kód s chybami a následne ho opravovať.
Naopak, vždy je nutné najskôr implementovať test a potom produkovať správny
(bezchybný) kód, ktorý zaistí splnenie testu. Pomocou tohto postupu sa eliminuje
fáza hľadania chýb (debugging) – ktorej časť pri metodikách s klasickým usporiadaním fáz (testovanie na konci) v praxi bežne vykonáva až zákazník, nakoľko
je uvoľnenie produktu tlačené termínom – v TDD sú totiž všetky chyby (bugs)
odstránené okamžite pri prechode testovacím prípadom.
Nevýhodou tejto metodiky je potrebná expertíza ľudí a čiastočne aj nutná silná
kontrola (alebo presvedčenie členov tímu), nakoľko táto metóda je pre typicky
netrpezlivých vývojárov nepohodlná.
Výhodou je okrem iného možnosť implementácie TDD do inej (globálnejšej)
metodiky. Takým spôsobom je možné postupne prenášať expertízu niekoľkých
členov tímu na iných.
3.3.5 SCRUM Development process
SCRUM Dvelopment process (ďalej len SCRUM) je v súčasnosti veľmi rozšírenou
a obľúbenou agilnou metodikou. SCRUM inklinuje k objektovo orientovanému
videniu sveta, ale organizuje a riadi proces úplne novým spôsobom. [10]
Názov metodiky pochádza z terminológie hry ragby – označuje kumulovanie
mnoho hráčov na jednom mieste za účelom dotlačenia lopty na požadovanú
pozíciu. [7] Celý vývojový proces si v metafore metodiky SCRUM je možné predstaviť ako ragbyový zápas, pričom za víťazstvo sa považuje spokojný zákazník.
SCRUM je skutočnou metodikou, nepredpisuje iba „pravidlá hry“, ale prináša
množstvo zaujímavých princípov udržujúcich súdržnosť tímu a podobne.
24
3. Metodiky vývoja softwaru
SCRUM je založený na teórii riadení empirických procesov [19] a využíva iteračný
a inkrementálny prístup k optimalizácii predvídateľnosti a riadeniu rizika. Každá
implementácia riadenia empirického procesu stojí na troch pilieroch:
• Transparentnosť – všetky aspekty procesu, ktoré majú vplyv na výsledok
by mali byť ľuďom, ktorí výsledky riadia stále viditeľné a musia im byť
zrozumiteľné (Ak niekto niečo považuje za hotové, musí sa to plne zhodovať
s tým, ako je „hotovo“ definované.).
• Kontrola – rôzne aspekty procesu sa musia kontrolovať tak často, aby bolo
možné odhaliť neprijateľné odchýlky v procese.
• Adaptácia – v prípade, že revízor na základe kontroly rozhodne, že jeden
alebo viac aspektov procesu sú mimo prijateľné hranice a že výsledný
produkt nebude akceptovaný, musí súčasne prispôsobiť proces alebo spracovávané materiály. Zmena musí byť uskutočnená čo najskôr. [22]
Vývoj podľa metodiky SCRUM prebieha v rámci postupností pevne daných
časových intervalov. Tieto intervaly sa nazývajú sprinty (Sprints). Každý sprint
trvá jeden mesiac, alebo menej – nie však dlhšie. Po skončení každého Sprintu je
tím schopní dodať medziprodukt, ktorý je funkčný a otestovaný, teda potenciálne
nasaditeľný. Po skončení každého Sprintu začína plánovanie a začiatok ďalšieho.
Obr. 3.1: Grafické znázornenie SCRUM procesu (prevzaté z [15])
SCRUM definuje tri body pre kontrolu a prispôsobenie (adaptáciu). Prvým je
Daily Scrum, denný míting (Daily Meeting, Dialy Standup Meeting), ktorý slúži ku
kontrole postupu práce voči cieľom Sprintu a k uskutočňovaniu korekcií vedúcich
k optimalizácii hodnôt, ktoré budú následne vytvorené. Trvanie tejto schôdzky
je veľmi krátke, odporúča sa uskutočňovať v stoji (nikto z tímu nesedí), čím sa
udržuje rozumná dĺžka stretnutia. Ďalším bodom sú Sprint Review (hodnotenia,
25
3. Metodiky vývoja softwaru
alebo tiež Demo Meeting) a Sprint Planning (plánovanie), ktoré slúžia ku kontrole
postupu práce voči cieľom a k uskutočňovaniu korekcií vedúcich k optimalizácii
hodnôt vytváraných v nadchádzajúcom Sprinte. Podsledným bodom je Sprint
Retrospective (retrospektíva). Tento míting sa využíva k zhodnoteniu práve dokončeného Sprintu a k stanoveniu zmien, ktoré uskutočnia nasledujúci Sprint
produktívnejším, viac naplňujúcim a zábavnejším. [22]
Rámec metodiky SCRUM sa skladá zo skupiny SCRUM tímov a s nimi spojených
rolí, časových rámcov (Time-Boxes), artefaktov a pravidiel. [19]
SCRUM tímy sú zostavené tak, aby optimalizovali flexibilitu a produktivitu.
K dosiahnutiu tohto cieľu je využívaná samoorganizácia tímov, multi-funkčnosť
ich členov a práca v iteráciách.
Každý SCRUM tím obsahuje tri role:
• SCRUM Master – je zodpovedný za pochopenie procesu, jeho dodržiavanie
a neustálu optimalizáciu.
• Vlastník produktu (Product Owner) – je zodpovedný za dosiahnutie maximálnej hodnoty vytvorenej SCRUM tímom. V praxi je do tejto role obsadzovaní
priamo zákazník, alebo zástupca zákazníka.
• Tím (Team Member) – ktorý prácu realizuje. Skladá sa z vývojárov so všetkými potrebnými znalosťami, ktoré zaistia pretvorenie požiadaviek Vlastníka produktu v potenciálne nasaditeľný inkrement produktu po ukončení
Sprintu. [22]
SCRUM využíva časové rámce k vytvoreniu pravidelnosti. Medzi tieto časovo
ohraničené elementy patria: Míting pre plánovanie release (Release Planning Meeting),
Míting pre plánovanie Sprintu (Sprint Planning Meeting), Sprint – fáza samotného
vývoja, Daily Scrum – zhodnotenie a Retrospektívu (Sprint Retrospective). [10, 22]
SCRUM obsahuje štyri hlavné artefakty:
• Produktový backlog (Product Backlog) – zoznam požiadaviek na produkt. Je
to prioritizovaný zoznam všetkého, čo má produkt obsahovať. Priebežne
ho vytvára Product owner a podľa potreby v ňom prioritizuje.
• Sprint Backlog) – je zoznam úloh, ktoré majú v rámci jedného sprintu premeniť časť produktového backlogu v prírastok potenciálne nasaditeľného
produktu.
• Release Burndown – Burndown graf slúži ako ukázateľ zostávajúcej práce
v čase. Release Burndown je graf, ktorý slúži k meraniu veľkosti ešte nerealizovaných (zostávajúcich) položiek produktového backlogu v čase v rámci
plánu vydania (release).
26
3. Metodiky vývoja softwaru
• Sprint Burndown – graf znázorňujúci veľkosť zostávajúcich položiek v čase
v rámci prebiehajúceho sprintu.
Časové rámce, role a artefakty SCRUM-u sú spojené pomocou pravidiel. Postupnosť krok a fází je znázrnená schémou na Obrázku 3.3.5. V rámci kroku
plánovania sa definuje rozsah aktuálnej verzie, harmonogram, nutné zdroje a
podobne. Vzniká backlog, definujúci potrebné úlohy, ktoré je nutné vykonať. Na
úplnom začiatku vytvára Product Owner backlog celého projektu. Tento zoznam
obsahuje položky – Stories – popis požadovanej funkcionality z produktového
hľadiska. Pri plánovaní sprintu dochádza k mapovaniu položiek projektového
backlogu na objekty, prevádza sa analýza rizík, volia sa vývojové nástroje a vznikajú odhady a Story je vývojovým tímom rozdelená na úlohy (Tasky). Výstupom
plánovacieho mítingu pre sprint je Sprint backlog a jasný cieľ sprintu (v podobe
slovného popisu, musí byť však špecifický pre každý sprint).
Produktový backlog môže vlastník neustále upravovať, každý sprint však začína
so zadaním ktoré definuje Sprint backlog, ktorý sa už počas sprintu zásadne
nemení. Začiatok sprintu je vlastne začiatkom vývoja. Sprint začína bezprostredne
po plánovacom mítingu.
Počas sprintu sa každý deň vykonáva Dialy SCRUM Meeting, počas ktorého sa
rozdeľuje práca, informuje o stave a upresňujú sa odhady. Na konci každého
denného mítingy SCRUM Master aktualizuje Sprint Burndown graf.
Na konci sprintu sa uskutoční Sprint Review míting, počas ktorého sú produktovému vlastníkovi odprezentované ukončené Stories. Za dokončené sa považujú
iba Stories, ktoré majú hotové všetky úlohy (Tasks) a ktoré splňujú zadanie. Prezentovanie rozpracovaných Stories je neprípustné. Aby sa predišlo nedorozumeniam,
uvádza sa pri každej Story buď akceptačné kritérium (Acceptance criteria), alebo
slovný popis, ako má byť funkcionalita odprezentovaná (How to demo – presný
popis požadovanej funkcionality definovanej pomocou scenára z používateľského hľadiska). Každá prezentovaná Story je produktovým vlastníkom buď
prijatá v prípade splnenia zadania, alebo neprijatá v prípade nesplnenia dopredu
stanoveného zadania a rozsahu.
Po každom Sprint Review stretnutí nasleduje Sprint Retrospective. Ide o míting,
ktorého sa zúčastňujú všetky role a ktorého cieľom je odhaliť problémy a stanoviť
ich riešenie. Každý člen tímu vyjadrí svoj názor.
Nevýhodou metodiky SCRUM je fakt, že sa jedná skôr o súhrn vzorov (SCRUM je
viac framework, ako metodika) než o špecifikáciu konkrétnych krokov vedúcich
k vývoji softwaru. Toto je súčasne aj výhodou, SCRUM totiž organizuje vývoj
27
3. Metodiky vývoja softwaru
z určitého vyššieho pohľadu, o spôsob samotnej práce sa môže starať iná metodika. Často sa SCRUM kombinuje, napríklad, s použitím metodika Test-Driven
Development (TDD). [11] Nie je to však podmienkou.
Spoločnou nevýhodou u väčšiny agilných metodík je potrebný prechod na úplne
iný „myslenie“. Firma sa musí prispôsobiť novým myšlienkam, v praxi však dochádza k deformácii, pri ktorej sa metodiky postupne upravujú tak, aby dokázali
fungovať v rámci aktuálneho firemného prostredia.
Veľkou výhodou SCRUM-u je schopnosť pružne reagovať na zmeny vznikajúce
v priebehu práce na projekte. SCRUM každodenne reflektuje prípadné zmeny a
hľadá riziká, ktoré z nich vyplývajú. Na základe toho je možné efektívne zmeniť
smerovanie projektu a formu dodávky v akýkoľvek okamžik, pokiaľ by to malo
za následok zvýšenie efektivity.
SCRUM poskytuje vývojárom slobodu navrhnúť optimálne riešenie, prípadne
zmeniť prístup v priebehu projektu pohľad toho, kam sa uberajú aktuálne požiadavky zákazníka. Úlohou role SCRUM Master nie je klasický manažment
– má tímu slúžiť ako ochrana pred vonkajšími vplyvmi a neustále sa pokúša
o zefektívnenie procesu.
SCRUM je vhodný predovšetkým pre menšie tímy a nie príliš rozsiahle projekty
– takými internetové a mobilné aplikácie zvyčajne bývajú. Aj v prípade vývoja
rozsiahlej internetovej služby zväčša nie je možné čakať na jej kompletné dokončenie a vývoj prebieha pomocou rôznych komponent a verzií, ktoré už pomocou
tejto metodiky je možné riadiť veľmi efektívne. Z toho dôvodu je SCRUM dnes
v prípade vývoja internetových služieb a mobilných riešení veľmi používanou
metodikou.
Aj napriek veľkej slobode je však SCRUM metodika založená na disciplíne. Pomocou SCRUM metodiky sú možné tiež pomerne veľké zásady od vedenia firmy.
V prípade, ak je k dispozícii vyspelejší tým, ktorý ma vhodné vnútorné zloženie
a vyspelú schopnosť plánovania, je často vhodnou metodikou Extrémne programovanie (XP), nakoľko kontrolné mechanizmu metodiky SCRUM môžu byť pre
takýto tím neefektívne a vedú k mikromanažmentu.
SCRUM je dnes tiež pomerne častou voľbou u spoločností, ktoré sa snažia o prechod na agilný spôsob vývoja.
28
3. Metodiky vývoja softwaru
3.3.6 Ďalšie metodiky
Existuje ešte celý rad ďalších agilných metodík a metód – napríklad Crystal metodiky (Crystal family of methodologies), metodika Jennifer Fleming, Adaptívny vývoj
softwaru (Adaptive Software Developlemt, ASD), Dynamic Systems Development Method (DSDM), Agilné modelovanie, The Agile Unified Process (AUP), Open Unified
Process (OpenUP), Microsoft Solutions Framework (MSF), Essential Unified Process
(EssUP), Velocity tracking a mnoho ďalších. Veľká časť z nich vychádza z metodiky
Rational Unified Process (RUP) (Kapitola 3.1.1) a rozširujú ho o agilné princípy.
Niekedy je možné kombinovať pri vývoji priamo dve metodiky, alebo vziať z konkrétnych metodík niektoré ich metódy a skombinovať ich.
Zjednodušene by sa dalo povedať, že ak by sme sa pokúsili o všeobecný popis
ktorejkoľvek (v predchádzajúcom texte skúmanej) agilnej metodiky, skončili by
sme pri veľmi podobných tvrdeniach. V zásade majú všetky agilné metodiky
rovnaký všeobecný popis, nakoľko ich princípy sú často zhodné: učiniť vývoj
rýchlejší a efektívnejší a znížiť jeho vedľajšie účinky, napríklad nervozitu a stres
ľudí.
3.4 Rozdiel vo vývoji moderných internetových a mobilných
aplikácií od klasického vývoja
Prvá veľká odlišnosť spočíva v rýchlosti vývoja. Žiaden zákazník rád nečaká
na dodávku softwaru príliš dlho, no u internetových projektov je však rýchlosť
vývoja a dodania jedným z najdôležitejších faktorov úspechu, či neúspechu. V súvislosti s vývojom webových aplikácií sa uvádza pojem „web-time“, upozorňujúci
na extrémne pojatie času pri vývoji internetových projektov. Ani ten však nesmie
vývojovému tímu zabrániť vyprodukovať kvalitnú prácu. Odporúča sa v používanej metodológii modifikovať štandardný rozhodujúci proces „kúpiť či vyvinúť“
(develop or purchase) v prospech nákupu – ak je možné kúpiť už hotové riešenie,
alebo znovu použiť už existujúce, je to takmer vždy výhodné.
Webové projekty by od začiatku mali pracovať s predpokladom, že sa budú
neustále meniť a rozvíjať – nielen po stránke funkčnej, ale aj grafickej. Vývoj a
použité technológie by tento predpoklad mali zohľadniť.
Špecifické pre vývoj internetových projektov je aj zloženie tímu, ktoré obsahuje
niektoré netradičné profesie a role – napríklad grafikov či propagačných textárov.
Začleniť tieto role do agilného vývoja – kde sú si väčšinou všetky role rovné –
29
3. Metodiky vývoja softwaru
môže byť zložité, typicky sa však za najlepšie považuje tieto role od tímu neoddeľovať. Zahrnutím tíchto ľudí do agilného procesu sa dosiahne (minimálne)
zdieľanie skúseností a neskôr možné odstránenie úzkych miest (hoci spočiatku sa
môže zdať ich zahrnutie kontraproduktívne a nezmyslené). Vyčleňovanie týchto
rolí a osôb, vytváranie pre nich iných pravidiel, vyčlenenie a oddeľovanie (čohokoľvek) v lepšom prípade nie je dostatočne efektívne, v horšom prípade spôsobí
v priebehu vývoja problémy.
Kým klasické projekty bývajú často dodávané priamo pre jednu platformu, pri
vývoji internetových projektov je požadovaná multiplatformná podpora – aplikácia musí fungovať na niekoľkých prehliadačoch a niekoľkých operačných
systémoch. To prakticky znemožňuje použiť vývoj riadený testovaním, nakoľko
automatické testovanie v tomto prípade je nemožné, respektíve iba ťažko možné
(časovo neefektívne).
Vývoj mobilných aplikácií prináša ešte jednu špecifickú vlastnosť. Rovnako, ako
pri vývoji internetových projektov je rozhodujúca rýchlosť (tu ešte silnejšie), tím
bude typicky ešte menší (rovnako však obsahuje veľa rôznych rolí) – čo je však
typické je distribuované zloženie tímu (ľudia v tíme sa nenachádzajú na rovnakej
fyzickej lokalite). Mobilné aplikácie sa typicky vyvíjajú veľmi rýchlo a trh je veľmi
mladý, mobilných vývojárov je dnes veľmi málo. Preto pre potreby krátkeho
vývoja často vznikajú tímy ľudí s odlišnou lokalitou; vývojári sa po uvoľnení
produkčnej aplikácie zase zaradia do iného vývoja.
3.5 Porovnanie agilných a rigoróznych metodík
Rozdiel medzi tradičnými prístupmi a agilnými metodikami je možné najlepšie
pozorovať na Obrázku 3.2.
Tradičné metodiky (znázornené ľavým trojuholníkom) vychádzajú z nutnosti
naplniť za každú cenu dokument Špecifikácia požiadaviek. Požiadavky – teda funkcionalita – sú teda fixné, zatia ľčo v roli premenný vystupujú čas a potrebné zdroje.
V týchto premenných dochádza k zmenám v prípade, ak v projekte dochádza
k ohrozeniu fixnej funkcionality. Často je dodatočne potrebné navýšiť rozpočet,
pridávať do vývoja ďalších ľudí (čo môže byť samo o sebe kontraproduktívne) a
podobne.
Agilný prístup naopak považuje čas a zdroje za fixné (stanovené zadávateľom
na začiatku) a mení sa (priebežne sa prispôsobuje) funkcionalita (funkčné požiadavky). Hoci sa tento prístup môže zdať na prvý pohľad ako nevýhodný, nie je to
30
3. Metodiky vývoja softwaru
úplne tak. Často je výhodnejšie čo najrýchlejšie uvoľniť produkt na trh a následne
na ňom na základe spätnej väzby pracovať.
Obr. 3.2: Porovnanie tradičného a agilného vývoja softwaru (prevzaté z [16])
Na rozdiel od tradičného prístupu si agilné metodiky uvedomujú, že úplné
zadanie by nemalo vznikať celé na začiatku (v čase najväčšej neistoty) ale malo byť
priebežne menené a s tým neustále spresňované všetky odhady. Úzke prepojenie
so zákazníkom navyše vytvára prostredie vyššej dôvery.
Hlavné rozdiely medzi oboma smermi vývoja približuje tabuľka porovnania
týchto dvoch prístupov (Tabuľka 3.1), ktorá je usporiadaná podľa vybraných
hľadísk porovnania.
Rigorózne metodiky
Agilné metodiky
1. Proces
vývoja
softwaru
Presne a podrobne definovaný Empirický proces, je možné ho
proces, je možné ho opakovať. opakovať, ale vyžaduje
adaptáciu.
2. Zmeny a
požiadavky
Minimalizácia zmien (zber
požiadavkou a plánovanie
vopred), zmeny sú súčasťou
riadenia zmien.
Akceptácia zmien (prírastkové
zhromažďovanie
požiadavkou, plánovanie po
iteráciách) prehodnocovanie
požiadavkou, snaha
o umožnenie zmien
(v závislosti na nových
znalostiach).
31
3. Metodiky vývoja softwaru
Rigorózne metodiky
Agilné metodiky
3. Zapojenie
zákazníka
na riadení
projektu
Bez zásahu. Nedôvera
Participácia a spolupráca –
zákazník sa aktívne zapája do
v zákazníka – po podpise
celého projektu, môže meniť
zmluvy a vymedzení
priority funkcií pri každej
dokumentu špecifikácie
požiadaviek počiatočnej fázy, iterácii.
zákazníka zaujíma až konečné
riešenie.
4. Kvalita
Viac zamerané na kvalitu
vlastných procesov, než na
výsledok pre zákazníka.
Zameranie sa na priority
zákazníka, na užitočnú
hodnotu pre zákazníka, teda
na výslednú kvalitu produktu.
5. Spôsob a
rozsah
riešenia
Podrobný popis procesov a
činností, zložité riešenie. Pri
vývoji obsiahnuté všetky
funkcie, snaha o zabudovanie
budúcich požiadaviek.
Eliminácia nepotrebných
činností, jednoduché riešenie.
Pri vývoji zahrnuté potrebné
funkcie, snaha
o minimalizáciu, žiadne
začlenenie budúcich
požiadavkou.
6. Rozloženie
tímového
know-how
Každý člen týmu má
priradené činnosti, v rámci
role, ktorú zastáva.
Požiadavka na špecializáciu
zamestnancov. Prevláda
písomná forma komunikácie
(dokumentácia).
Zdieľanie znalostí v tíme,
spolupráca (kooperácia) a
aktívna komunikácia v rámci
tímu, spoločné riešenie
problémov, riadenie a
integrácia znalostných tokov.
7. Ľudský
faktor
Pohľad na ľudí ako na
sekundárny faktor, procesy
doplňované rozsiahlou
dokumentáciou. Jedinci sú
nahraditeľní.
Ľudia ako primárny a kľúčový
faktor úspechu projektu.
Využitie schopností a
vedomostí jedincov
(individualít), dôraz na
znalosti, kvalifikáciu.
8. Spôsob
vývoja
Vodopádový životný cyklus,
Prírastkový (inkrementálny)
iteratívny s dlhými iteráciami. vývoj s veľmi krátkymi
iteráciami.
Tabuľka 3.1: Tabuľka porovnania rigoróznych a agilných metodík [6]
32
Základné princípy metodiky
SCRUM sa môže každý naučiť
aj z Wikipédie. Jej nesprávne
uchopenie však môže mať za
následok, že sa nám vývojový
cyklus začne „spomaľovať“,
alebo sa úplne zastaví.
Kapitola 4
Michal Vallo
agilný kouč a konzultant
Prípadová štúdia
V nasledujúcej si predstavíme firmu z komerčného sektoru, ktorá v predchádzajúcom období čiastočne prešla na agilný spôsob vývoja softwaru. S firmou bolo
vedených niekoľko dialógov s cieľom zistiť najväčšie problémy, ktoré po prechode
zaznamenali a pomôcť im optimalizovať celý proces. V prípadné problémy budú
analyzované a bude navrhnuté ich riešenie.
4.1 Zadávateľ
Zadávateľom problému1 , partnerom, respektíve „zákazníkom“ je spoločnosť
FOCUS Institut Marketing Research Ges.m.b.H. s hlavným sídlom v rakúskej
Viedni.
Firma FOCUS je vedúcou spoločnosťou v oblasti výskumu trhu a IT poradenstva
v Európe. Poskytuje dáta, know-how, systémy a poradenstvo v nasledujúcich
obchodných sférach: trh a spotrebiteľský prieskum, mediálny výskum, monitorovanie cien, IT poradestvo a riešenia. Regionálne zameranie firmy je na západnú,
strednú, východnú a juhovýchodnú Európu. Firma FOCUS má pobočky v pätnástich krajinách.
1. Na tomto mieste je vhodné dodať, že hoci pre potreby tejto práce bola zvolená jedna zahraničná
firma ochotná spolupráce, podobné problémy som zaznamenal aj vo viacerých väčších firmách.
Veľká časť ďalej napísaného teda platí aj pre iné firmy, ktoré majú vývoj roztrieštený vo viacerých
pobočkách.
33
4. Prípadová štúdia
FOCUS pomocou zložitých interných alogritmov spracováva veľké množstvo dát,
z ktorých poskytuje klientom štatistiky. Podstatnú časť vývoja venujú rozširovaniu ich online aplikácie, ktorá tvorí pre zákazníkov vstupnú bránu k objednaným
správam a štatistikám. Aplikáciu je potrebné neustále rožširovať a prispôsobovať požiadavkám nových klientov. Aplikácia má niekoľko častí, každá z nich
zodpovedá projektu, ktorý vyvíja malý agilný tím.
Súčasťou vývoja je tiež podpora pre prístup z mobilnej platformy.
FOCUS si dlhú dobu po svojom vzniku vystačila s malým IT vývojovým oddelením a nepotrebovala žiadne zložitejšie manažérske postupy riadenia. Organizácia
práce prebiehala často systémom ad-hoc stretnutí (príkladom sú náhodné stretnutia v kuchynke, počas ktorých sa robili dôležité biznis rozhodnutia), podobne sa
organizovala, rozdeľovala a plánovala práca.
S postupným rastom firmy bolo potrebné začať prácu organizovať, IT oddelenie
začalo používať ticket system (kombinácia klasickej databázy chýb bug tracking
system, do ktorej boli vkladané aj požiadavky na novú funkcionalitu). Prácu
rozdeľoval vedúci.
Nedostatok potrebných IT profesií donútil firmu založiť ďalšie vývojové oddelenia
v iných krajinách.
4.2 Súčasný stav
V súčasnosti prebieha hlavný vývoj v troch lokalitách (Rakúsko, Slovensko,
Česko), niektoré z tímov sú distribuované – vývojový tím je zložený z ľudí na
rôznych pracoviskách, majú odlišnú fyzickú lokalitu. Hlavné riadenie, plánovanie, zadávanie úloh a tvorba procesov sa deje v hlavnej lokality – v Rakúsku,
ostatné dve pobočky tvoria v IT oddeleniach iba vývojári.
Vývoj už takmer absolútne prebieha agilnou formou (tradičné metodiky sú spontánne používané iba pri veľmi malých a zväčša interných projektoch). Firma
vyvíja zložité experimentálne funkcie – tie vyvíjajú špecialisti v Rakúsku, ide
najčastejšie o prirodzene veľmi dobre organizovaných expertov. Nakoľko takýto
vývoj prebieha na jednej lokalite, tímy sú veľmi malé (2 až 4 ľudia) a sedia v jednej
miestnosti, s ich organizáciou nie je žiaden komplexnejší problém. Komplikované býva nahradiť niektorého z expertov v prípade jeho odchodu (firma ich
veľmi dobre platí, pretože si je tohto problému vedomá), inak si vedenie firmy
a vedúci týchto tímov nie sú vedomí žiadnych väčších problémov. Vývoj je ria34
4. Prípadová štúdia
dený prevažne metodikou XP (Kapitola 3.3.1), respektíve určitými metódami
prebranými z tejto metodiky. Nepoužívajú však striktne iba túto metodiku, riadenie údržby kódu má vlastnosti metodiky Lean development (Kapitola 3.3.2), jeden
tím experimentuje s metodikou Test-driven develompment (Kapitola 3.3.4) súčasne
s metodikou SCRUM (Kapitola 3.3.5).2
Firma však pociťuje problémy pri vývoji v distribuovaných tímoch, ktoré vyvíjajú menej intelektuálne náročný software (napríklad zákaznícke systémy, ktoré
pracujú nad dátami, ktoré spracovávajú algoritmy od expertov), alebo vyvíjajú
spôsobom, že zadanie prichádza z Rakúska (na rozdiel od expertných tímov
tak nemusia vytvárať zložitý návrh a experimentovať, zadanie vždy dostanú
dostatočne špecifikované). Vývoj prebieha tak, že zadávateľ práce je v Rakúskej
lokalite, vlastný vývojoví tím je však v Českej alebo Slovenskej pobočke, prípadne
je zložený z ľudí z rôznej lokality. Najväčšie problémy z pohľadu manažéra vyplývajú z nedostatočnej komunikácie (nepochopené zadanie, nedostatočná kontrola
ľudí, zdĺhavé odstraňovanie chýb a podobne). Vývojári majú tiež často problém
s komunikáciou s ľuďmi na inej fyzickej lokalite, súčasne medzi nimi absenciou
kontaktu na jednom pracovisku nevzniká dostatočné prepojenie, čo sa prejavuje
najčastejšie vo vypätých obdobiach pred blížiacimi sa termínmi (prehadzovanie
zodpovednosti z jednej lokality na druhú, nedostatočná tímovosť, vnútorné roztržky a nedostatok rešpektu, absencia možnosti vydiskutovať si niečo jednoducho
mimo počítačov a podobne). Tímom taktiež často chýba disciplína a u týchto
tímov dochádza častejšie k výmenám (fluktuácii členov).
FOCUS sa rozhodol zaviesť do tohto druhu vývoja metodiku SCRUM približne
v januári 2011, čím sa čiastočne zlepšila disciplína. Aj napriek tomu však pociťujú
metodiku výrazne efektívnejšiu u nedistribuovaných tímov. Geografickej roztrieštenosti tímov sa tak pokúšajú čo najviac vyhnúť, nie vždy je to však možné –
minimálne z dôvodu, že zadanie pochádza vždy z Rakúska, produktový vlastník
(Product owner), s ktorým prebieha dôležitá a početná komunikácia je vždy na
inej lokalite ako tím.
Problematické je tiež zdielanie dôležitých dokumentov súvisiacich s metodikou
SCRUM. Zo začiatku udržiavali produktový backlog a backlog sprintu ako textový
dokument umiestnený na zdielanom počítači, SCRUM tabuľu mal tím na stene
v lokalite (Obrázok B.9), z ktorej pochádzalo najviac vývojárov a ostatným posielali každý deň fotografiu (na čo často zabúdali a problémom bola aj čitateľnosť
rukou písaných textov). Všetky mítingy prebiehali pomocou telekonferencie
alebo videokonferencie, pričom z nich nevytvárali žiaden zápis.
2. V prípade ak by boli pravidlá metodiky Test-driven development v rozpore s pravidlami metodiky SCRUM, dávajú vývojári prednosť pravidlám SCRUM.
35
4. Prípadová štúdia
Kvôli hromadiacim sa problémom s nedostatočným zápisom (a následným neplnením dohôd, keďže z nich nepochádzal žiaden záznam) a súčasne kvôli stále
menšej ochote ľudí zúčastňovať sa mítingov začala firma používať interný podporný ticket system, ktorý však neobsahuje potrebné vizualizačné SCRUM nástroje
– dátumom ohraničené sprinty, cieľ sprintu, burndown grafy a tabuľu denného
mítingu.
4.3 Analýza problému
Po niekoľkých návštevách vo firme a dlhšími dialógmi so zainteresovanými ľuďmi
som dospel k interpretácii problémov analyzovanej v tejto kapitole.
Kým tímy nepoužívali žiaden podporný systém, zo začiatku všetko fungovalo
dobre. Súvisí to jednak s nadšením pri implementácii novej metodiky (ktorá
sa navyše snaží byť maximálne hravá a zábavná). Na druhej strane to súvisí
priamo aj s tým, že žiaden podporný systém nepoužívali (mimo videokonferencie,
telekonferencie a instantné správy). Tím tak mal okolo seba dôležité vizualizačné
elementy – napríklad SCRUM tabuľa s burndown grafom informuje členov tímu
o možných problémoch s nesplnením termínu dostatočne skoro. Tím bol viac
motivovaný voči dodržiavaniu zadania. Problémom však boli členovia tímu v inej
lokalite, ktorí sa potom necítili byť dostatočne zapojení do procesu.
Vedenie tak rozhodlo v čo najväčšej miere vytvárať iba tímy zložené z ľudí z jednej
lokality, nevenovali však dostatočnú pozornosť tomu, že hoci vývojový tím bude
kompletne sídliť iba v jednej lokalite, produktový vlastník bude vždy z Rakúska.
Pritom úloha produktového vlastníka je nesmierne dôležitá a členovia tímu
potrebujú nezriedka komunikovať s produktovým vlastníkom viac, ako so svojimi
kolegami. Aj preto sa produktový vlastník často považuje za člena tímu (len s inou
rolou).
Niektorí členovia tímu majú na ušiach počas celého dňa slúchadlá a dávajú si ich
dole iba počas denného mítingu. Slúchadlá s hrajúcou hudbou nosia, pretože ich
vo veľkom priestore rušia od práce iní ľudia.
Problémom je tiež, že rolu SCRUM Master na seba berie človek z vývojového
tímu. Musí príliš často prepínať medzi dvoma rolami a nedokáže sa sústrediť
na potrebné činnosti – ak sa sústredí na tvorbu zápisov, nezvláda premýšľať
o náročnosti odhadovanej práce (a tím tak stráca dôležitý názor jedného z členov),
alebo naopak nestíha robiť zápis a ochraňovať tím, ak sa snaží byť plnohodnotným
vývojárom.
36
4. Prípadová štúdia
Zúčastnil som sa tiež niekoľkých plánovacích mítingov, ktoré trvajú často celý
pracovný deň. FOCUS tieto mítingy organizuje pomocou videokonferencie. Na
každej lokalite tím využíva uzatvorenú zasadaciu miestnosť, na jednej lokalite
majú počítač so spusteným tracking systémom a jeden člen tímu (respektíve
SCRUM Master) zapisuje potrebné informácie. Obrazovku tohto počítača vysielajú
pomocou videokonferencie do iných lokalít.
Obdobne prebiehajú aj denné mítingy, s rozdielom že míting prebieha telefonicky
– jedna osoba zadáva údaje do počítača, v ostatných lokalitách ľudia dookola
obnovujú stránky systému a reportujú do telefónu ďalšie zmeny.
Najväčším problémom týchto mítingov je nezainteresovanosť ich členov. Kým
pri mítingoch, ktoré sa odohrávajú v jednej miestnosti je možné málo aktívnych
členov priamo vyzvať ku aktivite a súčasne každý z účastníkov stretnutia môže
papierovú kartičku jednoducho presúvať, alebo prepisovať, pri videokonferencii
je to horšie. Tím sa spolieha na „osobu s počítačom“, teda člena tímu, ktorý zapisuje údaje do počítača. Tím sa potom nedostatočne stotožňuje s odhadmi a cieľmi
sprintu, často sa poriadne ani nezaujímajú o úlohy, ktorých časovú náročnosť
odhadujú. Dôvodom je pravdepodobne chýbajúca interakcia s procesom.
Softwarové podporné systémy síce obsahujú veľa manažérskych funkcií, neposkytujú ale dostatočnú interaktivitu. Pri dlhých mítingoch – akým je plánovací
míting – tak osoby nie sú dostatočne zapojené do deja (za dáta v systéme je
zodpovedný jeden človek), rýchlo strácajú záujem a necítia sa byť zodpovední za
výstupy týchto stretnutí.
4.4 Návrh riešenia problému
Dôležité je priniesť do tímov čo najviac komunikácie ako je možné. V prípade
tímov, ktoré sedia v otvorených (open-space) priestoroch je potrebné v prvom rade
posadiť členov tímu vedľa seba (aj keby to malo znamenať, že sa budú po každom
sprinte presúvať medzi projektmi a tak aj fyzicky po miestnosti). Spolu s tým
je potrebné vytvoriť pre členov tímu súkromie – pokiaľ nie je možné postaviť
v priestore priamo priečku, je potrebné priestor rozdeliť aspoň opticky, napríklad
pomocou veľkých kvetináčov a podobne. Tím musí mať pocit určitej izolovanosti
od iných skupín, aby mohol nerušene pracovať v prípade napätých termínov
a zároveň aby mohli členovia tímu rozhovormi zlepšovať svoje vzťahy v čase
„pohody“ a nerušili pritom iné tímy. Osoby v tíme jednoducho musia mať pocit,
že môžu kedykoľvek čokoľvek povedať – takýmto spôsobom dochádza k výraznej
výmene informácií.
37
4. Prípadová štúdia
Problematické slúchadlá na pracovisku je potrebné čo najviac eliminovať. V prípade, ak sa tím vo veľkom priestore izoluje od iných tímov, nemalo by už dochádzať k veľkému rušeniu. Ak by totiž jeden člen tímu rušil svojich kolegov,
prípadné konsekvencie za to ponesie celý tím vrátane jeho. Problémom často
býva, ak má jeden tím príliš veľa voľného času (napríklad v období medzi sprintami) a ruší ostatných. Ak by sa pracovníci nechceli zrieknuť slúchadiel, dobrým
kompromisom je určité obdobie, kedy slúchadlá môžu používať a kedy nie.3
Niektorým pracovníkom nevyhovoval čas denného stretnutia, ktoré nedemokraticky definoval SCRUM Master, alebo niekto z manažmentu. Je dôležité, aby
s termínom tohto stretnutia súhlasili všetci zainteresovaní. Súčasne však toto
stretnutie musí prebiehať v rovnaký čas každý deň, inak postupne dôjde práve
k ignorovaniu tohto mítingu (pracovníci ho začnú považovať za zbytočný tak,
ako v našom prípade).
Problém s nedostatočnou zainteresovanosťou jednotlivých osôb by čiastočne
mohla eliminovať nepretržitá videokonferencia na pracovisku. Napríklad ak má
tím časť ľudí v Česku a zvyšnú časť na Slovensku, na každej lokalite bude na
stene pri každom tíme veľký televízor, v ktorom bude nepretržite spustený video
prenos. Tím tak aspoň virtuálne uvidí, čo robí jeho zvyšná (distribuovaná) časť.
V prípade spontánnych rozhovorov tím pristúpi bližšie k videokonferencii a
zvyšná časť si bude môcť tento rozhovor tiež vypočuť, alebo sa zapojiť.
Druhou časťou problému s nezainteresovanosťou je nedostatočná vizualizácia
všetkých dát. Hoci sú všetky potrebné informácie v intranetovom systéme, pre čo
najvyššiu efektivitu potrebujú mať pracovníci tieto dáta stále v dohľade. Riešením
by mohlo byť umiestnenie druhého televízora (vedľa toho s videokonferenciou) na
stenu v blízkosti tímu. Na tomto televízore by bola nepretržite spustená podporná
softwarová aplikácia so záložkou SCRUM tabule – každý z tímu tak neustále
uvidí všetky úlohy a graf priebehu sprintu (sprint burndown graf ).
Riešením nedostatočnej interaktivity so systémom je dotykové ovládanie aplikácie. Ak pri dennom mítingu mení odhady jedna osoba za počítačom, zvyšná
časť ľudí môže stratiť prehľad. Ak bude míting prebiehať pred dotykovou obrazovkou (hneď vedľa druhej obrazovky s videokonferenciou) a presúvanie úloh
medzi stĺpčekom dokončených a nedokončených úloh bude prebiehať dotykom
a presúvaním po obrazovke, zvyšná časť ľudí jasne uvidí tento pohyb a bude sa
orientovať. Dôležité je, aby bola obrazovka na každej lokalite synchronizovaná –
3. Je dobré stanoviť túto dobu zvlášť pre každý tím vypozorovaním, kedy osoby z tímu komunikujú najviac a kedy skutočne sústredene pracujú. Komunikáciu však odstrániť nechceme,
výsledkom nebude vyššia efektivita.
38
4. Prípadová štúdia
teda ak niekto presúva úlohu na jednej lokalite, na druhej lokalite uvidia cez
videokonferenciu, že niekto stojí pri obrazovke a súčasne sa ich SCRUM tabuľa
synchronizuje s novými údajmi.
Je tak potrebné nájsť podporné riešenie, ktoré disponuje touto funkcionalitou
a súčasne presvedčiť manažment o potrebe investície do hardwarového vybavenia. V prípade, že neexistuje potrebné softwarové riešenie, je potrebné nájsť
také, ktoré sa našim potrebám približuje čo najviac a chýbajúce časti je potrebné
doprogramovať. V prípade, že nenájdeme žiaden čiastočne vyhovujúci software
alebo ak vyhodnotíme ako lacnejšie vytvoriť vlastný systém, učiníme tak.
4.5 Analýza súčasných SW riešení
V nasledujúcom texte stručne zachytíme informácie získané z testovania niektorých dostupných softwarových riešení.
4.5.1 JIRA
JIRA je komerčný softwarový nástroj vyvíjaný spoločnosťou Atlassian. JIRA
podporuje a zjednodušuje proces riadenia projektov a požiadaviek, ponúka
flexibilné a používateľské nástroje pre riadenie a sledovanie pracovníkov pri
výkone plnenia úloh.
Softwarové riešenie JIRA neobsahuje potrebné nástroje k efektívnemu riadeniu
pomocou metodiky SCRUM, je však možné k JIRA pripojiť aplikáciu GreenHopper
vyvíjanú tou istou spoločnosťou, ktorá tieto nástroje obsahuje. Príkladom je
záznam obrazovky z plánovacieho mítingu (Obrázok B.1).
Príklad ceny za použitie tohto softwaru po firme s počtom pracovníkov do 100
je 300 dolárov mesačne za JIRA a ďalších 300 dolárov mesačne za GreenHopper.
Spolu teda 600 dolárov mesačne, čo je v prepočte približne 12 000 Kč (teda 144 000
Kč ročne).
Toto riešenie obsahuje veľmi veľa užitočných manažérskych nástrojov, je však
nedostatočne používateľsky orientované (nevyhovuje našim požiadavkám z Kapitoly 4.4).
39
4. Prípadová štúdia
Ako najvhodnejšie sa javí používať toto riešenie ako doplnok ku klasickým nástrojom metodiky SCRUM (tabuľa s Post-it papierikmi a podobne). SCRUM Master
po každom mítingu zozbiera vykonané zmeny a zaznamená ich do systému.
Je tiež možné používať iba túto online aplikáciu, tím však stratí potrebnú interakciu.
4.5.2 Redmine
Redmine je slobodný a open source software pre riadenie projektov a bug tracking
system. Obsahuje kalendár a Ganttov diagram umožňujúci vizualizáciu projektov a ich termínov. Redmine obsahuje integrované nástroje pre správu projektov,
správu úloh a podporu mnoho verzovacích systémov. Vzhľad Redmine je významne ovplyvnený softwarovým balíkom Trac, ktorý firma FOCUS používa
k sledovaniu ticketov u niektorých projektov (ukážka vzhľadu Redmine je na
Obrázku B.2).
Redmine používa v súčasnosti veľká časť tímov vo firme FOCUS. Problematická je
nedostatočná podpora dôležitých nástrojov metodiky SCRUM (Obrázok B.3), hoci
existujú prídavné moduly, ktoré ich sprístupnia. Z dlhodobého hľadiska však
tímy zaznamenali niekoľko chýb – problémom je neoficiálna podpora týchto prídavných modulov a v prípade novej verzie Redmine tak občas prestane fungovať
niektorá z pridanej funkcionality.
Výhodou Redmine je jeho bezplatné šírenie a otvorený zdrojový kód. Obsahuje
veľmi kvalitné nástroje pre správu backlog zoznamov. Chýbajú mu však natívne
nástroje pre podporu SCRUM metodiky a jeho prídavné moduly sú nespoľahlivé.
Kvôli absencii požadovanej funkcionality (najmä na spôsob ovládania a interakcie)
sme sa rozhodli Redmine ďalej nepoužívať a nájsť inú alternatívu.
4.5.3 XPlanner a XPlanner-plus
Xplanner je slobodný a open source software pre riadenie projektov a bug tracking
system. Od roku 2006 však nebola oficiálne vydaná žiadna novšia verzia tohto
systému. Z toho dôvodu vznikol ako jeho nástupca projekt Xplanner-plus.
40
4. Prípadová štúdia
Xplanner-plus je často využívaný agilnými tímami. Rovnako ako u Redmine (a narozdiel od JIRA s rozšírením GreenHooper), neobsahuje všetky potrebné nástroje
pre podporu vývoja riadeným metodikou SCRUM.
Xplanner-plus používala donedávna napríklad firma Seznam.cz (v súčasnosti už
používa vlastný systém), ktorá ho rozšírila o SCRUM tabuľu (Obrázok B.4). Hoci
túto obrazovku by nebolo zložité rozšíriť o dotykovú podporu, problematická
ostáva správa backlogu (Obrázok B.5). Našu požiadavku na jednoducho a prehľadnosť (kvôli permanentnému zobrazeniu na dotykovom displeji) nespĺňajú ani
obrazovky na reportovanie (Obrázok B.7). Problémom je tiež, že dôležité detaily a
poznámky každej úlohy nie sú zobrazené na SCRUM tabuli, ale až na obrazovke
detailu úlohy (Obrázok B.6).
Výrazným nedostatkom Xplanner-plus je absencia podporného riešenie pre plánovací míting, hodnotiaci míting a retrospektívu.
4.5.4 Iné podporné programové riešenia
Väčšina ostatných dostupných riešení disponuje podobnými, alebo menej prepracovanými funkciami. Do niektorých hotových riešení by bolo možné doprogramovať dotykové ovládanie, bolo by však potrebné prispôsobiť na takýto druh
vstupov celé grafické používateľské rozhranie.
Ako najvhodnejší kandidát na úpravu sa javil Xplanner-plus, stále by sme však boli
obmedzovaní v niektorých našich požiadavkách (napríklad automatická synchronizácia na rozdielnych obrazovkách by bola prakticky nemožná doprogramovať
kvôli chýbajúcej asynchrónnej AJAX komunikácia).
Takmer všetky testované najznámejšie podporné riešenia obsahujú veľmi kvalitné
manažérske nástroje, nepredpokladajú však jednoduché dotykové ovládanie a
majorita riešení neobsahovala podporné nástroje pre plánovanie a retrospektívu.
Predpokladom tvorcov je, že k takýmto mítingom nie je potrebná podporná aplikácia. V prípade distribuovaných tímov je však vizuálne podloženie dôležitým
faktorom, aby sa z týchto mítingov nestalo stretnutie, na ktorom sa iba rozpráva
a časť tímu sa tak bude nudiť a nebude zainteresovaná do diania.
Z vyššie uvedených dôvodov som sa rozhodol navrhnúť a postupne implementovať vlastné riešenie.
41
A štandardizované procesy môžu
spomaliť vývoj a implementáciu
nových vecí.
Kapitola 5
Mitchell Baker
predsedkyňa Mozilla foundation
Návrh a implementácia
Z predchádzajúcej analýzy vyplynulo, že vzhľadom k požiadavkám bude potrebné implementovať vlastné riešenie. Táto kapitola pojednáva o jeho návrhu a
demonštruje zaujímavé implementačné detaily.
5.1 Use-case diagram
Use-case diagram je v prípade nášho systému triviálny. Vychádza z pravidiel
metodiky SCRUM (Kapitola 3.3.5) a obsahuje všetky tri role, ktoré definuje metodika – SCRUM Master, Product Owner, Team Member. Všetky činnosti, ktoré môžu
vykonávať vyplývajú z pravidiel tejto metodiky, v systéme nebudeme vytvárať
žiadnu špecifickú funkcionalitu, nakoľko chceme udržať široké možnosti použitia
riešenia.
Všetky činnosti vychádzajú z klasického používania metodiky (v rámci jedného
pracoviska, s použitím klasických techník akými sú presúvanie Post-it papierikov
po stene a podobne). Jediným problémom je, že v elektronickom systéme ešte
potrebujeme špeciálnu rolu Administrátor, ktorý bude mať oprávnenie na správu
všetkých používateľov a právo vytvárať nové projekty.
Vzhľadom k jednoduchosti tohto diagramu použitia som rovno vytvoril diagram tried, ktorý v rámci takto malého projektu lepšie pomôže pri počiatočnom
stanovovaní rozsahu systému.
42
5. Návrh a implementácia
5.2 Diagram tried
Diagram tried vznikol ako podklad k počiatočným stretnutiam a ujasneniu rozsahu systému. Vzhľadom k agilnému spôsobu vývoja výsledné riešenie neodpovedá pôvodnému konceptu vo všetkých častiach – niektoré časti sme po skúsenostiach z praktického používania zmenili.
ManazerTasku
ManazerStatistik
ManazerStory
+CRUD()
+zmenitOdhad()
+priraditTeamMembera()
+odobratTeamMembera()
+CRUD()
+generujStastikyProSprint(sprint_ID)
+generujStatistikyProAktualniDen(sprint_ID)
+spocitajStatistikyOPolnoci()
Story
patrí k
1
-name
-odhad
-poznamky
-how_to_demo
Statistika
0..*
0..*
patri k
Task
-name
-odhad
0..*
1
Sprint
0..*
0..*
pracuje na
0..*
Team Member
ManazerSprintu
1
+CRUD()
-date_start
-date_end
-ciel
+ukoncitSprint()
+spustitSprint()
+vypisTaskyPreSprint()
0..*
0..*
sa vztahuje k
1
0..*
0..*
Polozka retrospektivy
-typ
-text
-flag_dolezita
je priradený k
spravuje
User
-name
-email
-username
-password
Superadmin
Scrum
Master
-date
-celkovyOdhadSprintuPreDen
0..1
ManazerUserov
patrí k
+CRUD()
+nastavitRoluProductOwnera()
+nastavitRoluScrumMastera()
ManazerRetrospektivy
+CRUD()
+oznacitAkoDolezitu()
1
Produkt
Product Owner
-name
0..1
spravuje
0..*
Model
Controller
ManazerProduktov
+CRUD()
+nastavitProductOwnera()
Obr. 5.1: Diagram tried
43
5. Návrh a implementácia
Diagram vznikol s ohľadom na plánované použitie modernej softwarovej architektúry Model-View-Controller (MVC) (Kapitola 5.3), teda dátový model aplikácie,
jej používateľské rozhranie a riadiaca logika je rozdelená do troch nezávislých
komponent. Modifikácia niektorej z komponenty nemá zásadný vplyv na ostatné.
Obrázok 5.1 na strane 43 zobrazuje počiatočný návrh systému. Entity vyznačené
žltou farbou sú v rámci MVC architektúry riadiacou logikou, modré entity tvoria
dátový model.
5.3 Implementačná architektúra a infraštruktúra
Výsledné riešenie som sa rozhodol pojať ako webovú aplikáciu. Dovolím si tvrdiť,
že akékoľvek iné riešenie by bolo horšie. U takéhoto druhu služby je dôležité, aby
bolo celé prostredie prístupné rýchlo a pohodlne, bez nejakej inštalácie. Súčasné
smerovanie vývoja a takzvaná Post-PC doba (stále väčšia rozšírenosť inteligentných mobilov s internetovým pripojením, tabletov, ultraprenosných počítačov a
podobne) nám tiež napovedajú pravdepodobný vývoj v oblasti tvorby softwaru –
dátový model a časť riadiacej logiky bude prístupná online a používateľ bude
k aplikácii pristupovať pomocou webového prehliadača (Thin-client).
Webová služba vyvíjaná monoliticky je dnes už prakticky odsúdená k rýchlemu
zániku, nakoľko údržba a rozširovanie takéhoto systému sú po krátkej dobe
prakticky nemožné. Z toho dôvodu som sa rozhodol ako architektonický vzor
zvoliť Mode-View-Controller (MVC) (Obrázok 5.2). Pre ďalšiu životnosť webovej
aplikácie je totiž dôležité čo najviac oddeliť databázovú časť, riadiacu logiku a
grafické rozhranie, či skripty vykonávané na klientskej strane.
Prehliadač
7
2
3
Databáza
4
Model
5
1
Radič
6
Pohľad
Obr. 5.2: Princíp MVC architektúry webovej aplikácie [24]
Všeobecne povedané, vytváranie aplikácie s použitím MVC arhitektonického
zoru vyžaduje vytvorenie troch komponent:
• Model (model) – doménová špecifická reprezentácia informácií, s ktorými
aplikácia pracuje,
44
5. Návrh a implementácia
• View (pohľad) – prevádza dáta reprezentované modelom do podobny vhodnej k používateľskej prezentácii,
• Controller (radič) – reaguje na udalosti (používateľské aleboo od systému) a
zaisťuje zmeny v modeli alebo v pohľade. [9]
Ďalšou dôležitou požiadavkou aplikácie je schopnosť distribuovaných prístupov
(ak uskutoční zmeny v systéme časť tímu v jednej lokalite, musí sa to dozvedieť aj tím v inej lokalite). Z tohto dôvodu musí veľká časť komunikácie medzi
prehliadačom a serverom prebiehať asynchrónne (Obrázok 5.3).
Prehliadač
Vyžiadaj stránku
Server
HTTP GET
alebo POST
Tradičná
webová
aplikácia
Vráť HTML
Vykresli stránku
Čakaj na udalosť
AJAX volanie
AJAX
webová
aplikácia
HTTP GET
alebo POST
Vráť HTML fragement,
skript alebo iné dáta
Urob niečo s dátami,
vykresli časť stránky,
vykonaj skript
Obr. 5.3: Požiadavky na server v AJAX webovej aplikácii [24]
Asynchrónna komunikácia je tiež dôležitá s ohľadom na typ používateľov – so
systémom bude často pracovať celá skupina ľudí naraz (aj v rámci jednej lokalite
chceme, aby so systémom pracovali všetci naraz a nie jeden človek). Klasický
spôsob komunikácie (odoslanie požiadavku a načítanie novej stránky) by síce bol
zrozumiteľné pre osobu, ktorá akciu do systému zadá, toto by však mohlo pôsobiť
nezrozumiteľne voči ostatným prizerajúcim používateľom. Uvážme situáciu denného Daily SCRUM mítingu. Tím reportuje uskutočnenú prácu, každý pracovník
svoj progres postupne zadá do systému. Pre ostatných prizerajúcich (tých čo
zrovna nezadávajú dáta do systému) môže byť neustále nové načítavanie stránky
(obzvlášť ak boli dáta zadané na odskrolovanej stránke a po novom načítaní sa
ocitla na začiatku) nezrozumiteľné.
45
5. Návrh a implementácia
5.4 Spôsob vývoja
Po úvodnom stanovení približného rozsahu bol stanovený spôsob vývoja. Pri
vývoji, ktorý realizuje jeden človek nemá zmysel používať konkrétnu metodiku
(ktorej význam spočíva najviac v zefektívnení komunikácie). Spôsob vývoja však
prebiehal v agilnom zmysle – v trojtýždňových iteráciách. Pred každou iteráciou
došlo k stretnutiu s produktovým vlastníkom (zodpovedná osoba z firmy FOCUS)
a stanoveniu rozsahu požadovanej funkcionality na danú iteráciu. Výstupom
každej iterácie bol otestovaný kód, ktorý bol firme odovzdaný formou balíku
(release).
Po prvých troch iteráciách vznikla už produkčne použiteľná aplikácia, ktorú
firma začala používať a funkčne testovať.
Vývoj je verzovaný pomocou SVN. Každá iterácia bol odklonená do vlastnej
vývojovej vetvy a po skončení vývoja bola zlúčená s produkčnou vetvou.
Po odovzdaní balíka do produkcie boli zozbierané požiadavky na funkčné zmeny
a prípadné chyby. Zber požiadaviek prebiehal pomocou bug tracking systému
Bugzilla.
5.5 Voľba programového prostredia
Vzhľadom k veľkému rozsahu aplikácie a predpokladanej náročnosti vzhľadom
k používateľskému prostrediu bola voľba programovacieho jazyka podriadená
jeho čo najvyššej funkčnej efektivite (možnosť veľkého prírastku funkcionality
v krátkom čase) oproti jeho výkonnosti (to, či je daná funkcionalita dostatočne
rýchla).
Kvôli požadovanej MVC architektúre pripadali do úvahy najmodernejšie jazyky.
Kvôli požiadavke na funkčnú efektivitu bol zvolený k vývoju framework – softwarová štruktúra, ktorá slúži ako podpora pri programovaní. Obsahuje rôzne
už implementované návrhové vzory, ktoré programátor môže znovu použiť a
nemusí ich znova programovať.
Vývoj prvého prototypu začal pomocou programovacieho jazyka Ruby a jeho
frameworku Ruby on Rails. Výhodou bol veľmi rýchly spôsob vývoja.
Po overení si funkcionality na prototype som začal vyvíjať serverovú časť v programovacom jazyku Python a frameworku Django. Dôvodom k prechodu bola
lepšia dokumentácia tohto frameworku.
46
5. Návrh a implementácia
Vývoj používateľského prostredia prebiehal pomocou moderných technológii –
HTML5, CSS3 a javascriptového frameworku jQuery.
Výhodou takto zvoleného riešenia je jeho multiplatformovosť a podpora pre
všetky najpoužívanejšie databázové systémy. Ďalšou výhodou je veľká bezpečnosť – používané vzory z frameworku neobsahujú bezpečnostné diery. Použitím
javascriptového frameworku bolo možné použiť veľké množstvo funkcionality,
ktorá bola otestovaná naprieč všetkými používanými prehliadačmi a tak sa nebolo potrebné zdržiavať zložitým testovaním.
5.6 Návrh grafického prostredia a spôsobu ovládania
Najdôležitejšou časťou pri vývoji vlastného programového riešenia bol správny
návrh grafického prostredia a spôsobu ovládania aplikácie. Ako vzor poslúžilo
klasické používanie metodiky SCRUM pomocou klasickej tabule a kancelárskych
papierikov Post-it.
Tím pri vývoji riadenom metodikou SCRUM používa nasledovné nástroje:
• backlog,
• plánovací míting – Sprint Planning,
• denný míting – Daily SCRUM,
• retrospektíva.
5.6.1 Backlog
Backlog vytvára Product Owner. Najpoužívanejším nástrojom je Microsoft Excel,
nakoľko umožňuje vlastníkovi jednoducho presúvať vytvorené položky.
S ohladom na tieto požiadavky vznikol návrh obrazovky (Obrázok A.4), na ktorej
môže Product Owner a SCRUM Master vytvárať nové Sprinty a spravovať tím a
súčasne môže Product Owner vytvárať backlog, prioritizovať ho a vyberať, ktoré
z položiek chce zahrnúť do ktorého Sprintu.
Nakoľko časť manažérov používa tablety s nízkym rozlíšením,celé rozhranie je
zobraziteľné aj na takomto zariadení.
47
5. Návrh a implementácia
5.6.2 Plánovací míting
Najčastejšie prebieha tak, že Product Owner vytlačí položky z backlogu, ktoré
chce zahrnúť do Sprintu na kartičky a tie prinesie na plánovací míting. Tím
rozloží kartičky na veľký stôl v zasadacej miestnosti, kartičky ľubovoľne presúvajú,
dopisujú na ne poznámky, vytvárajú odhady a dopĺňajú úlohy, ktoré je potrebné
vytvoriť k splneniu danej Story.
Výhodou kartičiek rozložených na stole je, že tím nesedí, ale je neustále v pohybe
a je nútený zapájať sa do plánovania. V prípade ak sa plánovanie odohráva
v počítači, existuje riziko, že bude do plánovania zapojení iba jeden človek (človek
„s klávesnicou“) a zvyšok tímu nebude dostatočne zainteresovaný (svoje nápady
nemôžu zrealizovať okamžite sami, ale musia čakať na osobu „s klávesnicou“).
Výstupom pre plánovací míting je návrh obrazovky (Obrázok A.1), ktorý má za
cieľ čo najviac simulovať skutočné plánovanie. Ideálne plánovanie by sa odohrávalo v zasadacej miestnosti s dotykovým projektorom – obraz bude premietaný
na stôl (prípadne bude použitý stôl s dotykovou obrazovkou). Každý z tímu
môže presúvať kartičky a vytvárať odhady. Možné je tiež plánovať s pomocou
dotykovej obrazovky, no tento spôsob nebude dostatočne efektívny, nakoľko
pravdepodobne nastane situácia že nie všetci budú dostatočne blízko obrazovky,
aby sa mohli zapojiť.
5.6.3 Daily SCRUM
Denný míting zvyčajne prebieha postojačky pri stene, ktorá je blízko miesta, kde
sedí tím. Je dôležité, aby členovia tímu videli na túto stenu a mali stále na očiach
všetky kartičky s úlohami a burndown graf. Počas denného mítingu každý z tímu
reportuje odvedenú prácu, problémy, skúsenosti a vyberá si úlohy na ďalší deň.
Úlohy sú napísané zvyčajne na Post-it kartičkách a tím ich presúva po stene.
Výstup pre virtuálny denný míting je návrh obrazovky (Obrázok A.2), ktorého
hlavnou úlohou je zobrazovať všetky informácie na jednej obrazovke tak, ako by
to bolo v prípade použitia klasickej steny a kartičiek. Kartičky je možné posúvať
dotykmi, každá akcia na tabuli je teda vizuálne podtrhnutá pre ostatných členov tímu. Na obrazovke sa nachádza automaticky generovaný Burndown graf
Sprintu, ktorý informuje tím o tom, nakoľko sa približujú ideálnej rýchlosti vývoja.
Pod grafom sú uvedené ciele Sprintu a akcie na zlepšenie sa, ktoré vyplynuli
z retrospektívy predchádzajúceho Sprintu.
48
5. Návrh a implementácia
Pretože so systémom budú pracovať distribuované tímy, je u tejto obrazovky
dôležité, aby akcia vykonaná na jednej obrazovke bola synchronizovaná so všetkými ostatnými obrazovkami. Táto funkcionalita bola implementovaná pomocou
AJAX komunikácie.
5.6.4 Retrospektíva
Máloktorý software obsahuje aj podporu pre retrospektívu. U distribuovaných
tímov je to však nevyhnutnosť. Zároveň je dobré, ak ostanú výstupy z retrospektívy zaznamenané v systéme a dôležité pripomienky, ktoré vzniknú počas
retrospektívy by mali ostať neustále na očiach.
Pri klasickej retrospektíve pripevní na stenu každý z členov tímu dva druhy
papierikov – zelené symbolizujú čo sa podarilo urobiť dobre, na červené sa píšu
prekážky a problémy a súčasne akcia, ktorá by ich mala odstrániť.
Návrh obrazovky retrospektívy (Obrázok A.3) reprezentuje takúto stenu. Obrazovka podporuje dotykové ovládanie, dôležité úlohy je možné označiť a zobrazovať potom pri ďalšom Sprinte.
Všetky ostatné návrhy používateľského grafického rozhrania sú v prílohe A. Záznamy obrazoviek hotovej aplikácie sú v prílohe C.
49
Kapitola 6
Koniec-koncov, fakty sú fakty a
hoci môžeme s úškrnom citovať
jeden druhému slová múdreho
štátnika: „Lži, prekliate lži a
štatistika“, stále sú niektoré prosté
čísla, ktoré aj ten najjednoduchší
musí pochopiť a ktoré ani ten
najľstivejší neprekrúti.
Leonard H. Courtney
britský politik
Výsledky a kontrola kvality
V nasledujúcej kapitole sa sústredíme na kontrolu výslednej aplikácie pomocou
funkčných, výkonnostných a záťažových testov. Tieto testy kontrolujú nielen
kvalitu a použiteľnosť, ale poskytujú aj obraz o náročnosti aplikácie a pomôžu
stanoviť správnu konfiguráciu pre danú firmu.
6.1 Funkčné testovanie
Vývoj podpornej aplikácie prebiehal agilne. Nakoľko jediným vývojárom bol
autor tejto práce, nebolo potrebné implementovať do vývoja plnohodnotnú agilnú
metodiku (denné mítingy by boli neefektívne a zbytočné). No vývoj aj napriek
tomu napĺňal hlavné myšlienky agilného vývoja – vývoj v iteráciách, časté odovzdávanie funkčných a otestovaných verzií a definovanie a úprava rozsahu požadovanej funkcionality prebiehala priebežne.
Vývoj bol verzovaný pomocou SVN (Obrázok B.8), pričom otestovaná funkčná
verzia bola vždy v produkčnej vetve a samotný vývoj prebiehal v inej vetve.
Predpokladom je, že výstupom každej iterácie je otestovaný kód. Manažéri a
vývojári tak mali k dispozícii vždy aktuálnu otestovanú verziu (neobsahovala
programové chyby). Približne po dvoch mesiacoch vývoja obsahoval software
dostatočnú funkcionalitu a v dvoch tímoch nahradil ich dovtedy používaný
podporný systém.
50
6. Výsledky a kontrola kvality
Samotné funkčné testovanie teda prebiehalo priebežne po uvoľnení novej verzie
(release). Spätná väzba bola zozbieraná pomocou bug tracking systému Bugzilla.
V každej daľšej verzii už boli všetky požiadavky na zmenu funkcionality implementované. Funkcie uvoľnené po iterácii boli teda produkčne otestované a
upravené najneskôr s release o dve iterácie neskôr. V dôsledku nekonečného kolobehu uvoľňovania nových funkcií a ich následnej úpravy prebehlo z času na
čas uvoľnenie hlavnej verzie, ktorá neobsahuje žiadny funkčne neotestovaný kód
(nie je to teda najnovšia dostupná verzia, ale je stabilnejšia). V závere vývoja sa
testovacím tímom stal už iba jediný, zvyšné tímy používali stabilnejšie verzie.
V dôsledku príliš častých nových verzií sa totiž museli príliš sústrediť na podporný systém a nie samotnú metodiku a vývoj. K uvoľňovaniu takýchto verzií
dochádzalo približne každých 9 týždňov.
Jedna takáto verzia sa nachádza v prílohe D. Vo vývoji softwaru však mám v pláne
ďalej pokračovať a zamerať sa na zdokumentovanie kódu (pri agilnom vývoji sa
dáva prednosť vlastnému kódu pred dokumentovaním) tak, aby sa do vývoja
mohli zapojiť aj iní vývojári.
Pri implementovaní požadovaných zmien vyplývajúcich z funkčných a používateľských testov bol kladený dôraz na univerzálnosť výsledného riešenia a niektoré
z požiadaviek neboli implementované. Firma by sa mala snažiť prispôsobiť metodike, no súčasne sme podporný systém nevytvorili striktne obmedzujúce a
ponechali sme tímu v niektorých prípadoch slobodu.
6.2 Výkonnostné a záťažové testovanie
Predpokladom, ktorý potrebujeme overiť je, že aplikácia zvládne produkčnú
prevádzku aj v stredne veľkej firme. Zároveň by sme potrebovali zistiť, s akým
hardwarom by mala firma pri nasadzovaní aplikácie počítať.
Uvážme firmu, ktorá ma 100 zamestnancov zapojených do vývoja pomocou metodiky SCRUM. Každý tím tvorí 7 členov, jeden SCRUM Master a jeden Product
Owner, teda náš systém bude aktívne využívať približne 10 skupín. Predpokladáme taktiež, že každý z tím je distribuovaný – polovica tímu sa fyzicky nachádza
v inej lokalite ako druhá polovica ľudí. Každý tím má na svojej lokalite k dispozícii svoju SCRUM obrazovku, nebude teda nastávať situácia, že by systém chceli
využívať úplne všetci naraz.
Predpokladajme (v rámci záťaže vyvíjanej voči serveru) najhorší scenár – všetky
tímy budú svoj denný míting robiť v rovnakom čase. Každý tím má dve obrazovky,
51
6. Výsledky a kontrola kvality
SCRUM Master a Product Owner majú každý vlastný počítač alebo tablet. Môžeme
teda očakávať, že v jednom čase nastane situácia, keď 10 tímov odošle na server
každý po štyri požiadavky. Každý terminál vytvára spojenia typu Keep-alive a
čaká na prípadnú aktualizáciu obsahu pomocou AJAX komunikácie.
Náš systém by teda mal byť schopný obslúžiť 40 požiadaviek, pričom dĺžka
odozvy by nemala používateľov nijak obmedzovať.
6.2.1 Metodika testovania
Testovanie prebiehalo pomocou jednoduchého konzolového nástroja ApacheBench
(AB). AB dokáže podať predstavu o výkonnosti danej aplikácie na danom serveri.
Výstupom je počet obslúžených požiadaviek (request) za sekundu a ich latencia.
V rámci webovej aplikácie bola identifikovaná výpočtovo najzložitejšia stránka –
tabuľa pre denný míting. Pomocou ApacheBench bolo z jednej lokality s veľmi
rýchlym pripojením (server aisa na Fakulte informatiky MU) na server s aplikáciou
odosielaných 2000 požiadaviek (spojenia typu Keep-alive). Testované boli rôzne
hodnoty súbežne vytvorených (konkarentných) požiadaviek.
6.2.2 Použitý hardware
Pre potreby testovania bol zriadený virtuálny server v konfigurácii:
Procesor:
garantovaný jedno jadrový,
s frekvenciou 2.13 GHz (Intel Xeon L5630).
RAM pamäť:
garantovane 1024 Mb.
Softwarová konfigurácia:
Debian Linux (squeeze),
Apache2 (konfigurácia typu single worker),
MySQL 5, Python 2.7.2, Django 1.3.1,
libapache2-mod-wsgi 3.3-2.
Tabuľka 6.1: Konfigurácia testovaného servera (v cene 800 Kč mesačne)
52
6. Výsledky a kontrola kvality
№ spojení
(v %)
Test č. 1
Test č. 2
Test č. 3
50 %
≤1515 ms
≤316 ms
≤216 ms
66 %
≤1677 ms
≤390 ms
≤261 ms
75 %
≤1794 ms
≤479 ms
≤288 ms
80 %
≤1891 ms
≤510 ms
≤309 ms
90 %
≤2164 ms
≤618 ms
≤359 ms
95 %
≤2424 ms
≤948 ms
≤461 ms
98 %
≤2656 ms
≤2278 ms
≤712 ms
100 %
36570 ms
37744 ms
36112 ms
Tabuľka 6.2: Výsledky troch výkonnostných testov - pri 40, 20 a 5 súbežných
spojeniach
6.2.3 Test č. 1 – 40 súbežných požiadaviek
Tento test uvážil najväčšiu predpokladanú záťaž a opakoval ju nepretržite. Na
server bolo odosielaných 40 súbežných požiadaviek, spolu ich bolo odoslaných
2000.
Výsledky prvého testu (Tabuľka 6.2.2, druhý stĺpček) ukázali, že 50 % požiadaviek
bolo obslúžených v čase kratšom alebo rovnom ako 1,5 sekundy. 98 % požiadaviek
bolo obslúžených v čase kratšom alebo rovnom približne 2,6 sekundy, dĺžka
najdlhšej odpovede bola až 36 sekúnd. V praxi sú tieto hodnoty stále prijateľné,
no používanie aplikácie nebude príjemné a svižné (nízky user experience). Ak by
sme očakávali takto masívnu záťaž, potrebovali by sme zvýšiť RAM pamäť na
serveri.
Tu je však dôležité dodať, že tento test je značne naddimenzovaný. Predpovedá
najhorší možný scenár a opakuje ho stále dookola, akoby takáto záťaž bola predpokladaná neustále, čo je silne nepravdepodobné.
53
6. Výsledky a kontrola kvality
6.2.4 Test č. 2 – 20 súbežných požiadaviek
Tento test zodpovedá viac reálnej záťaže, ak by aplikáciu používali všetky tímy
naraz (za predpokladu, že nebudú nepretržite vykonávať nejaké operácie – každý
z tímov potrebuje nejaký čas na diskusie, počas ktorých nebude voči serveru
požadovať žiadnu činnosť). Na server bolo odosielaných súbežne 20 požiadaviek,
spolu ich bolo odoslaných 2000.
Výsledky druhého testu (Tabuľka 6.2.2, tretí stĺpček) nám ukázali, že 50 % požiadaviek bolo obslúžených v čase kratšom alebo rovnom ako 0,39 sekundy. 95
% požiadaviek bolo obslúžených v čase kratšom alebo rovnom približne 0,9
sekundy. Tieto hodnoty sú úplne dostačujúce.
6.2.5 Test č. 3 – 5 súbežných požiadaviek
Tento test zodpovedá predpokladanej záťaži, ak by so systémom skupiny nepracovali presne v rovnakom čase, ale nezávisle na sebe v priebehu dňa (čo asi
najviac zodpovedá realite).
Výsledky posledného testu (Tabuľka 6.2.2, posledný stĺpček) nám ukázali, že 50 %
požiadaviek bolo obslúžených v čase kratšom alebo rovnom ako 0,21 sekundy.
95 % požiadaviek bolo obslúžených v čase kratšom alebo rovnom približne 0,42
sekundy. Tieto hodnoty sa nijak výrazne neodlišujú od druhého uskutočneného
testu.
6.2.6 Záver testovania
Pomocou výkonnostných a záťažových testov na produkčne nakonfigurovaný
virtuálny server sme si ukázali, že aplikácia poskytuje dostatočne rýchlu odpoveď
aj pri vysokej záťaži. Testovanie prebiehalo na výpočtovo najzložitejšej stránke –
obrazovka SCRUM tabule obsahuje niekoľko zložitých SQL príkazov.
Aplikáciu by bolo možné zrýchliť pomocou proxy (nemusí sa čakať na pomalé
pripojenia), zavedením cache u používateľa, alebo alokáciou výkonnejšieho hardwaru.
Kompletné výsledky testov sú v prílohe D.
54
Kapitola 7
Záver a diskusia
Náplňou mojej práce bolo preskúmať agilné techniky a reflektovať ich teóriu
s praktickým používaním. V práci som sa zameral na riadenie vývoja moderných webových a mobilných riešení a jednotlivé najrozšírenejšie agilné metodiky
skúmal prevažne z tohto hľadiska.
Do riešenia diplomovej práce som zapojil súkromný sektor. V rámci praktickej
časti som uskutočnil analýzu súčasného postupu riadenia vývoja vo veľkej medzinárodnej spoločnosti, ktorá vyvíja rozsiahlu webovú službu. Pokúsil som sa
odhaliť problémy, ktoré zaznamenávajú pri vývoji a odhalil som najväčší problém – vývoj v agilných tímoch.
Myslím, že sa mi úspešne podarilo navrhnúť programové riešenie, ktoré umožnilo
efektívne riadenie vývoja softwaru ako z manažérskeho pohľadu, tak z pohľadu
vývojárov (na ktorých pohľad som sa zameral, keďže väčšina dostupných riešení
sa zameriava na manažérske funkcie). Výsledné programové riešenie implementuje nadčasový spôsob dotykového ovládania, ktorý sa možno v budúcnosti stane
štandardom. Systém som navrhol tak, aby bolo čo najviac informácií zobrazených
v rámci jednej obrazovky a aby slúžil ako nepretržitá informačná a vizualizačná
podpora pre tím. Aplikácia berie ohľad na stále častejšie sa vyskytujúce distribuované tímy (typické pre moderný vývoj webových a mobilných služieb) a snaží
sa riešiť niektoré z ich problémov.
Nakoľko vývoj samotného praktického výstupu prebiehal agilne, výsledné riešenie som neustále podroboval funkčným, výkonnostných a záťažovým testom.
Hoci firma zapojená do riešenia výsledný software úspešne používa, v jeho vývoji plánujem ďalej pokračovať a zamerať sa na niektoré chýbajúce manažérske
funkcie.
Som presvedčený, že zadanie sa mi podarilo splniť.
55
Zoznam obrázkov
2.1
2.2
Schéma modelu „Napíš a oprav“ (Code and fix model) (prevzaté
z [21]) 6
Vodopádový model životného cyklu (prevzaté z [21]) 8
3.1
3.2
Grafické znázornenie SCRUM procesu (prevzaté z [15]) 25
Porovnanie tradičného a agilného vývoja softwaru (prevzaté
z [16]) 31
5.1
5.2
5.3
Diagram tried 43
Princíp MVC architektúry webovej aplikácie [24] 44
Požiadavky na server v AJAX webovej aplikácii [24] 45
A.1
A.2
A.3
A.4
A.5
A.6
Obrazovka plánovania sprintu 63
Obrazovka rozhrania pre denné mítingy 64
Obrazovka podpory retrospektívneho mítingu 65
Obrazovka tvorby backlog záznamov pre projekt 65
Obrazovka vytvárania projektov (admin) 66
Obrazovka nastavení sprintu 66
B.1
Plánovacia obrazovka komerčného softwaru JIRA s doinštalovaným
rozšírením pre podporu agilného vývoja GreenHopper 67
Používanie Redmine vo firme FOCUS – zoznam všetkých úloh
reprezentuje Project backlog 68
Používanie Redmine vo firme FOCUS – každý balík (release)
reprezentuje Sprint, každý zoznam pod Sprintom tvorí Sprint
backlog 69
Záznam obrazovky SCRUM tabule denného mítingu aplikácie
Xplanner špeciálne upravenej pre SCRUM 69
Záznam obrazovky zoznamu Stories v aplikácii Xplanner 70
Záznam obrazovky detailu Story v aplikácii Xplanner – detaily nie sú
zobrazené na tabuli denného mítingu 70
Záznam obrazovky reportovania v aplikácii Xplanner – ovládanie
predpokladá klávesnicu a jedného používateľa 71
Vývoj aplikácie bol verzovaný pomocou SVN 71
SCRUM tabuľa vytvorená z Post-it papierikov [18] 72
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
C.1
C.2
Výsledné riešenie je multiplatformové, na obrázku je zachytený
proces inštalačného skriptu, ktorý do zvolenej databázy nahrá
iniciálne dáta 73
Výsledné riešenie obsahuje vstavaný webový server 73
56
7. Záver a diskusia
C.3
C.4
Projekty a používateľov spravuje administrátor 74
Obrazovka administračného rozhrania, v ktorom správca systému
vytvára nové projekty a používateľov (všetky obrazovky sú
zobraziteľné aj na zariadeniach s veľmi úzkou obrazovkou, pri
zmenšení okna dôjde k preskupeniu obsahu a zoštíhleniu menu) 74
C.5 Backlog ukážkového projektu umožňuje spravovať sprinty, tímy a
produktovému vlastníkovi vytvárať nové Stories, rozdeľovať ich do
Sprintov a prioritizovať ich 75
C.6 Obrazovka plánovania podporuje dotykové ovládanie, v kombinácii
s dotykovou projekciou na konferenčnom stole umožňuje tímu
zefektívniť plánovanie 76
C.7 Rozdeľovanie Story na úlohy umožňuje vytvoriť presnejšie
odhady 76
C.8 Obrazovka pre podporu Daily SCRUM mítingu by mal mať tím
neustále na očiach, slúži ako hlavný informačný a motivačný
zdroj 77
C.9 Retrospektíva u distribuovaných tímov inšpirovaná klasickou
retrospektívou uskutočňovanou na SCRUM stene pomocou Post-it
kartičiek – sú farebne rozlíšené a dobre čitateľné 78
C.10 Aplikácia je prístupná nielen pomocou dotykových obrazoviek a
veľkých projektorov, ale aj prostredníctvom počítača alebo
tabletu 79
C.11 Aplikácia podporuje dotykové gestá 80
57
Zoznam tabuliek
3.1
Tabuľka porovnania rigoróznych a agilných metodík [6] 32
6.1
6.2
Konfigurácia testovaného servera (v cene 800 Kč mesačne) 52
Výsledky troch výkonnostných testov - pri 40, 20 a 5 súbežných
spojeniach 53
58
Register
agilný, 1, 2
agilný manifest, 16
best practices, 20
bottle neck, 21
bug, 24
bug tracking system, 34
Burndown, 26
cache, 54
change management, 12
class diagram, 22
code and fix model, 6
debugging, 24
develop or purchase, 29
diagram aktivít, 11
distribuovaný tím, 30, 34
FDD, 21
Feature Driven Development, 21
framework, 46
KANBAN, 21
Lean development, 20
Lean manufacturing, 20
ľahké metodiky, 15
metóda, 5
metodika, 5, 11
metodológia, 5
mikro-manažment, 15
model životného cyklu, 5
model tried, 11
MVC, 44
Controller, 45
Model, 44
View, 45
proxy, 54
QA, 23
Quality Assurance, 23
refaktorizácia, 17, 23
release, 26
release package, 24
requieremnts management, 12
riadenie zmien, 12
rigidný, 3
RUP, 12
activities, 13
construction, 13
elaboration, 13
inception, 13
process framework, 12
roles, 13
transition, 13
workers, 13
workflows, 13
SCRUM, 3, 24–28
Daily Scrum, 25–27
Product Backlog, 26
Product Owner, 26
Release Burndown, 26
Release Planning Meeting, 26
SCRUM Master, 3, 26
Sprint, 25, 26
Sprint Backlog, 26
Sprint Burndown, 27
Sprint Planning Meeting, 26
Sprint Retrospective, 26
Sprint Review, 25
Story, 27
59
7. Záver a diskusia
Team Member, 26
Sequence diagrams, 22
softwarová kríza, 7
stagewise model, 6
Štíhla výroba, 20
Štíhly vývoj, 20
špirálový model životného cyklu, 9
TDD, 23
Test-Driven Development, 23
testovanie, 23
ticket system, 34
time-box, 26
tracking system, 34
UML, 12, 13
Unified Software Development Process,
14
unit testing, 17
use-case, 12
user experience, 53
vodopádový model životného cyklu, 8
Vývoj riadený testami, 23
Vývoj riadený vlastnosťami softwaru,
21
web-time, 29
XP, 3, 16
párové programovanie, 17
truck faktor, 19
60
Literatúra
[1] Bauer, F. L.: The Software Crisis. [Konferencia], NATO Science Committee,
1968.
[2] Beck, K.: Extreme Programming Explained. Addison-Wesley, 1999, ISBN
978-0-201-61641-5, 224 s.
[3] Beck, K.: Extrémní programování. Praha: Grada, 2002, ISBN 80-247-0300-9,
160 s.
[4] Beck, K.: Test Driven Development: By Example. Addison-Wesley, prvé
vydanie, 2002, ISBN 978-0-3211-4653-3, 240 s.
[5] Boehm, B.: A spiral model of software development and enhancement.
1986: s. 11–14.
[6] Buchalcevová, A.: Metodiky vývoje a údržby informačních systémů. Praha:
Grada, 2004, ISBN 80-247-1075-7, 164 s.
[7] Cohn, M.: Succeeding with Agile: Software Development Using Scrum.
Addison-Wesley, prvé vydanie, 2009, ISBN 0-321-57936-4, 504 s.
[8] Džaferagić, A.: Agilní přístup k řízení softwarových projektů. [Diplomová
práca], RNDr. Jaroslav Ráček, Ph.D., Masarykova univerzita, Brno.
[9] Holovaty, A.; Kaplan-Moss, J.: The Definitive Guide to Django: Web
Development Done Right. Apress Series, Apress, 2009, ISBN 978-1-4302-0331.
Dokument dostupný na URL
http://books.google.com/books?id=Gpr7J7-FFmwC
[10] Kadlec, V.: Agilní programování: metodiky efektivního vývoje softwaru. Brno:
Computer Press, prvé vydanie, 2004, ISBN 80-251-0342-0, 278 s.
[11] Kniberg, H.: Scrum and XP from the Trenches (Enterprise Software
Development). Lulu.com, prvé vydanie, 2007, ISBN 978-1-4303-2264-1, 140 s.
[12] Kolektív: Agile Manifesto. Dokument dostupný na URL
http://agilemanifesto.org/ (cit. 20. septembra 2010)
61
[13] Kraus, J.: Nový akademický slovník cizích slov A-Ž. Praha: Academia, prvé
vydanie, 2009, ISBN 978-8-020-01351-4, 879 s.
[14] Kroll, P.: Agility and Discipline Made Easy: Practices from OpenUP and RUP.
Addison-Wesley, prvé vydanie, 2006, ISBN 978-0-321-32130-5, 448 s.
[15] MountainGoatSoftware: Introduction to SCRUM – An agile process.
Dokument dostupný na URL
http://www.mountaingoatsoftware.com/topics/scrum (cit. 30. októbra
2011)
[16] Ošlejšek, R.: Objektové metody návrhu informačních systémů. Dokument
dostupný na URL https://is.muni.cz/auth/el/1433/jaro2010/PA103/
um/prez/01_Strategie-vyvoje-sw.pdf (cit. 12. septembra 2011)
[17] Pressman, R.: Software Engineering: Practitioner’s Approach. Boston:
McGraw-Hill, piate vydanie, 2001, ISBN 0073655783, 860 s.
[18] van Roosmalen, R.: The Agile Office - Part 1, Communication. Dokument
dostupný na URL http://softwaredevelopmentisfun.blogspot.com/
2010/07/agile-office.html (cit. 30. októbra 2011)
[19] Schwaber, K.: Agile Project Management with Scrum (Microsoft Professional).
Microsoft Press, prvé vydanie, 2004, ISBN 978-0735619937, 192 s.
[20] Shore, J.: The Art of Agile Development. O’Reilly Media, prvé vydanie, 2007,
ISBN 978-0-5965-2767-9, 440 s.
[21] Sommerville, I.: Software engineering. Harlow: Addison-Wesley Publishing
Company, šieste vydanie, 2001, ISBN 020139815X, 693 s.
[22] Sutherland, K.; Schwaber, J.: Scrum guide. Dokument dostupný na URL
http://www.scrum.org/scrumguides/ (cit. 2011)
[23] Vallo, M.: Introduction to methodology and agile management.
[Doktorandský kurz], Fakulta informatiky, Masarykova univerzita, 2011.
[24] Žatkulák, M.: Případová studie komplexního návrhu komunitní webové aplikace.
[Diplomová práca], RNDr. Jaroslav Škrabálek, Masarykova univerzita, Brno.
62
Dodatok A
Návrhy obrazoviek aplikácie
Obr. A.1: Obrazovka plánovania sprintu
63
A. Návrhy obrazoviek aplikácie
Obr. A.2: Obrazovka rozhrania pre denné mítingy
64
A. Návrhy obrazoviek aplikácie
Obr. A.3: Obrazovka podpory retrospektívneho mítingu
Obr. A.4: Obrazovka tvorby backlog záznamov pre projekt
65
A. Návrhy obrazoviek aplikácie
Obr. A.5: Obrazovka vytvárania projektov (admin)
Obr. A.6: Obrazovka nastavení sprintu
66
Dodatok B
Obrazové prílohy
Obr. B.1: Plánovacia obrazovka komerčného softwaru JIRA s doinštalovaným
rozšírením pre podporu agilného vývoja GreenHopper
67
B. Obrazové prílohy
Obr. B.2: Používanie Redmine vo firme FOCUS – zoznam všetkých úloh reprezentuje Project backlog
68
B. Obrazové prílohy
Obr. B.3: Používanie Redmine vo firme FOCUS – každý balík (release) reprezentuje
Sprint, každý zoznam pod Sprintom tvorí Sprint backlog
Obr. B.4: Záznam obrazovky SCRUM tabule denného mítingu aplikácie Xplanner
špeciálne upravenej pre SCRUM
69
B. Obrazové prílohy
Obr. B.5: Záznam obrazovky zoznamu Stories v aplikácii Xplanner
Obr. B.6: Záznam obrazovky detailu Story v aplikácii Xplanner – detaily nie sú
zobrazené na tabuli denného mítingu
70
B. Obrazové prílohy
Obr. B.7: Záznam obrazovky reportovania v aplikácii Xplanner – ovládanie predpokladá klávesnicu a jedného používateľa
Obr. B.8: Vývoj aplikácie bol verzovaný pomocou SVN
71
B. Obrazové prílohy
Obr. B.9: SCRUM tabuľa vytvorená z Post-it papierikov [18]
72
Dodatok C
Obrazové ukážky aplikácie
Obr. C.1: Výsledné riešenie je multiplatformové, na obrázku je zachytený proces
inštalačného skriptu, ktorý do zvolenej databázy nahrá iniciálne dáta
Obr. C.2: Výsledné riešenie obsahuje vstavaný webový server
73
C. Obrazové ukážky aplikácie
Obr. C.3: Projekty a používateľov spravuje administrátor
Obr. C.4: Obrazovka administračného rozhrania, v ktorom správca systému
vytvára nové projekty a používateľov (všetky obrazovky sú zobraziteľné aj na
zariadeniach s veľmi úzkou obrazovkou, pri zmenšení okna dôjde k preskupeniu
obsahu a zoštíhleniu menu)
74
C. Obrazové ukážky aplikácie
Obr. C.5: Backlog ukážkového projektu umožňuje spravovať sprinty, tímy a produktovému vlastníkovi vytvárať nové Stories, rozdeľovať ich do Sprintov a prioritizovať ich
75
C. Obrazové ukážky aplikácie
Obr. C.6: Obrazovka plánovania podporuje dotykové ovládanie, v kombinácii
s dotykovou projekciou na konferenčnom stole umožňuje tímu zefektívniť plánovanie
Obr. C.7: Rozdeľovanie Story na úlohy umožňuje vytvoriť presnejšie odhady
76
C. Obrazové ukážky aplikácie
Obr. C.8: Obrazovka pre podporu Daily SCRUM mítingu by mal mať tím neustále
na očiach, slúži ako hlavný informačný a motivačný zdroj
77
C. Obrazové ukážky aplikácie
Obr. C.9: Retrospektíva u distribuovaných tímov inšpirovaná klasickou retrospektívou uskutočňovanou na SCRUM stene pomocou Post-it kartičiek – sú farebne
rozlíšené a dobre čitateľné
78
C. Obrazové ukážky aplikácie
Obr. C.10: Aplikácia je prístupná nielen pomocou dotykových obrazoviek a veľkých projektorov, ale aj prostredníctvom počítača alebo tabletu
79
C. Obrazové ukážky aplikácie
Obr. C.11: Aplikácia podporuje dotykové gestá
80
Dodatok D
Obsah CD
Priložené CD médium obsahuje:
• zdrojový kód tejto práce vo formáte LATEX,
• túto prácu vo formáte PDF,
• priložené obrázky, diagramy a fotografie v digitálnom formáte,
• zdrojový kód aplikácie naprogramovanej v jazyku Python za pomoci
frameworku Django,
• neminimalizované zdrojové kódy a dokumentácie k použitým
JavaScriptovým knižniciam,
• textové výstupy z výkonnostných a záťažových testov.
81
D. Obsah CD
82
Download

Agilné metodológie riadenia vývoja softwaru