Zdroj: Diagnostika a testování elektronických systémů [online]. [cit. 2019-02-26]. Dostupné z:
http://www.umel.feec.vutbr.cz/bdts/index.php/embedded-systemy/vyvojove-modely
2.5.5 Agilní metodiky
Agilní metodiky se vyznačují podstatně menší měrou formálnosti oproti klasickým metodikám. Agilní metodiky se soustředí hlavně na spolupráci, komunikaci a připravenost na změnu. Jde o to, aby pracovní tým byl pokud možno co nejvíce produktivní a efektivní a aby výsledný produkt byl dodán v prvotřídní kvalitě a v co nejkratším čase. Cílem agilních metodik není nějaký produkt, ale hodnota zákazníka neboli jeho spokojenost.
(Šochová, 2014, s. 13)
U agilního vývoje neexistuje žádný přesně definovaný postup nebo model, kterého by se vývojáři měli nebo museli striktně držet. Spíše se jedná o způsob myšlení a řešení problémů. Myšlenku agilního vývoje softwaru přibližuje následující manifest (Agilemanifesto, 2001):
Jednotlivci a interakce před procesy a nástroji
Fungující software před vyčerpávající dokumentací
Spolupráce se zákazníkem před vyjednáváním o smlouvě
Reagování na změny před dodržováním plánu
Při vývoji softwaru je složité odhadnout čas a náklady pro vytvoření aplikace. Obvykle také dochází ke změně zadání ze strany zákazníka, protože sám na začátku ani neví, co chce.
Lean metoda
Lean metoda je založena na omezování rozdělané práce, to znamená, že v danou chvíli se pracuje jen na tom, co je přesně známé a definované. Jedná se o převedení „systému tahu“
do vývoje informačních technologií. Takzvaně přestat vyrábět na sklad, ale až tehdy, když je to potřeba. Podle základních doporučení by se nemělo pracovat na něčem, co se později ani nepoužije, tento čas by měl být využit efektivněji. Zpětná vazba by se měla zjišťovat již během vývoje, aby se předešlo časovým ztrátám po dokončení vývoje a možnému předělávání aplikace. Čím později padne rozhodnutí, tím více informací bude do té doby možno získat. Dále může pomoct delegování zodpovědnosti na jednotlivé členy týmu, což povede k jejich většímu zapojení a též i motivaci na rozdíl od klasických topdown firemních struktur. (Šochová, 2014, s. 18-19)
2.5.6 Další modely vývoje softwaru
Jedná se o různé modely, které vycházejí z vodopádového modelu a snaží se odstranit jeho nedostatky. (Kadlec, 2004)
Test Development – vodopádový model je rozšířen na konci každé fáze o specifikaci a provádění testů
Exploratory Programming – předchůdce iterativního přístupu spočívá ve vyvinutí pouze základní kostry podle základních požadavků, které se poté rozšiřují o konkrétní připomínky a specifičtější požadavky zákazníků
Prototyping Model – vodopádový model kde se nejdříve vytvoří prototyp systému
Evolutionary/Incremental Model – Evoluční či Inkrementální model je předchůdcem iterativního programování
3. Případová studie organizace
V následujících odstavcích se nachází popis a srovnání organizační struktury firmy a všech rolí konkrétního projektu ve zkoumané firmě. Záměrem této studie je porovnat a propojit teoretická východiska s těmi praktickými.
3.1 Zainteresované strany
Zainteresované strany, které se aktivně účastní tohoto konkrétního projektu, by se daly rozdělit do tří skupin.
3.1.1 Zadavatel projektu
Zadavatelem projektu je obvykle sportovní federace anebo organizační výbor, kteří si koupí licenci na tento registrační a akreditační systém. V rámci kontraktu je zahrnuta konfigurace systému pro potřeby dané plánované události. Dále kontrakt může obsahovat i dodatečný vývoj nové funkcionality či úpravu stávajícího chování systému. Ve formě alokovaného času, což je součet celkového odpracovaného času všech vývojářů pracujících na určitém zadání. Zákazník samozřejmě očekává bezchybný funkční systém, dalšími chtěnými vlastnostmi jsou jednoduchá obsluha, kompatibilita všech součástí a použití moderních technologií. Zadavatelem projektu se stává jakýkoli zákazník, který projeví zájem o tento registrační a akreditační systém a následně si zakoupí jeho licenci. To vede k tomu, že i přesto, že se jedná o jeden a ten samý informační systém, tak má vícero zadavatelů, kteří mohou, ale nemusejí mít stejné požadavky a cíle.
Každý ze zadavatelů představuje jednu sportovní federaci, například Mezinárodní Basketbalová federace (FIBA), Mezinárodní a Evropská Házenkářská federace (IHF a EHF), Mezinárodní Plavecká federace (FINA) a Evropský Olympijský výbor (EOC).
3.1.2 Uživatelé projektu
Tímto pojmem se myslí koncoví uživatelé, kteří zčásti budou stejní jako zadavatelé
určen pro registraci všech účastníků a umožňuje široké komplexní řešení celé plánované události. Mimo jiné sem patří organizační výbor dané události, sportovci a jejich doprovod, média, externí dodavatelé a bezpečnostní složky. Tito všichni musejí být akreditováni a tudíž i zaregistrováni, ať již sami sebou nebo někým jiným. Ne všichni uživatelé mají zkušenosti s počítači a informatikou všeobecně, proto musí být systém pro ně dostatečně přehledný a jednoduchý na pochopení.
3.1.3 Vlastník projektu
Vlastníkem projektu by se v tomto případě dala označit zkoumaná firma, jejíž vedení má za cíl, jakožto v jakémkoli jiném odvětví, za co nejnižších nákladů vytvořit a provozovat co nejlepší a konkurence schopný výrobek nebo službu, v tomto případě informační systém.
Vlastníkem je proto, že pouze prodává licenci k používání svého softwaru. Jedná se o koncepci Software jako služba (SaaS), kdy poskytovatel webové aplikace pouze poskytuje možnost s aplikací pracovat, nikoli však aplikaci samotnou. Aplikace je hostována na vzdáleném serveru a klient k ní přistupuje prostřednictvím internetu. Na stejném principu funguje například sada aplikací Google Apps. Další podobná koncepce je Platforma jako služba (PaaS), kde si zákazník pronajímá nástroje na vývoj aplikací a vlastní aplikaci si musí vyvinout sám. Hranice mezi oběma koncepcemi může být někdy poněkud nejasná.
(Velte, 2011)
3.2 Projektový tým
Projektový tým tvoří již konkrétní zaměstnanci pracující na vývoji a chodu projektu po celou jeho dobu životnosti. Projektový tým pro tento projekt je značně skromný a sestává se ze čtyř lidí. To nutně vede k tomu, že jeden člen týmu zastává i vícero týmových rolí.
Základní rozdělení rolí je následující:
3.2.1 Manažer projektu
Celý tento projekt stojí na práci projektového manažera, který toho o tomto informačním systému ví nejvíce, zároveň má také nejvíce zkušeností z celého týmu. Jeho další rolí, kromě řízení a plánování projektu, je komunikace se zákazníky. Ať již se jedná o školení či diskutování o budoucím vývoji. Manažer by měl být flexibilní, umět efektivně využívat dostupných informací. V případě nutnosti najít alternativy postupu.
Manažer projektu se nachází uprostřed všeho dění a měl by se starat o řízení činností a vztahů uvnitř projektu, motivování členů projektového týmu a každodenní řízení procesů.
(Svozilová, 2011, s. 31)
Dle definice projektových rolí podle Doležala, by se v tomto případě dala Manažeru projektu přisoudit i role Garanta výstupu. Kdy je zodpovědný za správný a včasný výstup projektu. (Doležal, 2016)
3.2.2 Asistent manažera projektu
Zkoumaný projektový tým se skládá ze dvou asistentů projektového manažera. Jejich hlavní aktivitou je komunikace se zákazníky a jejich technická podpora. Což zahrnuje školení, správná konfigurace systému a případně i pomoc s obtížnými kroky v registračním či akreditačním workflow1. Dále také příprava dokumentace. Každý z asistentů má přidělené určité zákazníky, zadavatele projektu. A každý z asistentů má jednoho zadavatele projektu jako svoje hlavní zaměření, ale zároveň má i sekundární, tak aby existovala zastupitelnost například v případě nemoci, dovolené nebo služební cesty. Každý z nich
1 Workflow (v překladu: průběh práce, pracovní postup) V informatice, ale také jiných oborech lidské působnosti se takto označuje způsob pracovního postupu, nebo také celý pracovní proces. Složitější operace jsou zde rozvrženy a rozepsány do jednotlivých bodů a dílčích prací.
Zdroj: https://it-slovnik.cz/pojem/workflow/?utm_source=cp&utm_medium=link&utm_campaign=cp
musí znát jak je nakonfigurovaný systém pro daného zákazníka, znát zákaznické kontaktní osoby, historii komunikace a další specifika daného zadavatele projektu.
Dále vzhledem k malé velikosti projektového týmu je jejich další rolí, testování systému a hledání chyb. Tato role je označována jako tester. Cílem testera je odhalit veškeré chyby v systému, které se objevily během vývoje, nebo špatnou konfigurací. Druhy testování jsou Testování jednotek, Integrační testování, Systémové testování a Akceptační testování.
V prvním případě se jedná o Testování jednotek, které má za cíl otestovat, zda funguje nově přidaná funkcionalita, tím že se otestuje jen daná část systému a vyzkoušejí se všechny možné kombinace vstupů. Dalším krokem jsou Integrační testy, které zkoumají, zda přidání nové funkcionality neovlivnilo chování staré funkcionality nebo správný chod systému jako celku. Posledním krokem testerů je Systémové testování, což je simulování chování z pohledu zákazníků, jak oni budou systém v praxi sami používat, zdali je systém pro ně dostatečně srozumitelný a práce v něm uživatelsky přívětivá. Akceptační testování již následně provádí sám zákazník, zdali mu systém případně nová funkcionalita vyhovují.
(Patton, 2002)
Tabulka 1: Časová náročnost technické podpory na příkladech Akce
Jak je patrné z dat v předchozí tabulce, časovou náročnost podpory projektu určuje rozsah sportovní akce, ale neplatí vždy, že větší počet účastníků také znamená více času stráveného podporou. Dalším určujícím faktorem je to, zda se jedná o multi sportovní akci, či jen akci pro jeden sport. Dále také jak moc je místní organizační výbor akce zkušený s podobným typem akcí.
3.2.3 Softwarový inženýr
Posledním, ale neméně důležitým členem týmu je vývojář. Vývojář má na starosti samotné programování aplikace a návrh logiky pro řešení zadání.
Správný vývojář se také musí průběžně seznamovat s novými technologiemi a umět je adaptovat pro jeho vlastní práci.
Kromě stálého vývojáře, který je součástí zkoumaného týmu, se dle potřeb využívá i pomoci od vývojářů z jiných pracovních týmů, zejména pokud se jedná o doplňující součásti systému, jako například mobilní aplikace na zařízeních Android a iOS.
Na takto velkém projektu je nedostatečné mít pouze jednoho vývojáře. Ten svým úsilím stačí pouze na konfiguraci pro nové a stávající zákazníky, opravy chyb a pouze drobné rozšiřování funkcionality. A díky tomu se práce na velkých rozšířeních a nových modulech systému protahuje.
3.2.4 Externí konzultanti
Pro správnou definici požadavků a následné naprogramování systému je nutné zcela pochopit danou problematiku a pracovní postupy. K vysvětlení těchto postupů se dají využít externí konzultanti, kteří mají bohaté zkušenosti s danou problematikou a i určitý pohled zvenčí či nadhled. Nejsou limitováni pouze znalostí jednoho konkrétního systému či firemní business logikou.
Vždy když se objeví nový projekt, tak je snahou dozvědět se od zákazníka co nejvíce informací, aby služby firmy byly co možná na nejvyšší úrovni. Ale občas spolupráce se zákazníkem z nějakého důvodu je nedostatečná a v tuto chvíli je lepší doplnit si informace i z jiného zdroje. Do současné doby bylo služeb externích konzultantů využito pouze dvakrát, ale již se plánují další konzultace k novým projektům, které jsou zatím v rané fázi vývoje.
3.3 Organizační model
V praxi je dosti složité identifikovat konkrétní modely organizační struktury různých firem, neboť se mohou z části prolínat a kombinovat.
Organizační model z pohledu fungování zkoumané firmy jako celku představuje model Autonomního projektového řízení. Kdy ke každému novému projektu jsou přiřazeni pracovníci. Hlavním kritériem pro jejich výběr je jejich specializace, ale také momentální pracovní zatížení. Je běžnou situací, že většina pracovníků spolupracuje na dvou a více projektech zároveň. Tímto se tato organizační koncepce lehce přibližuje k Maticovému projektovému řízení, kdy je pohyb jednotlivých pracovníků či celých projektových týmů řízen aktuální poptávkou po pracovní síle na jednotlivých projektech. Toto uzpůsobení dokáže minimalizovat požadavky na celkový počet kmenových zaměstnanců a tím i snižovat náklady spojené s najímáním pracovní síly.
V následující tabulce jsou zachyceny různé situace k programování a jejich časová náročnost podle počtu souběžně pracujících softwarových inženýrů.
Tabulka 2: Časová náročnost podle počtu programátorů Celkový počet
odpracovaných hodin
Počet dní za kolik bude projekt hotov 1 Programátor 2 Programátoři 3 Programátoři Rozšíření jednotlivých projektů. Z toho vyplývá určité zkreslení, protože se jedná o různé projekty, které mají částečně jiné požadavky a rozsah, a také se jedná o různé programátory, kde každý pracuje jinak rychle, ale pro představu je to dostačující.
Zároveň v posledních letech se ve zkoumané firmě stále více využívají externí pracovníci, kteří jsou najímáni na výpomoc s některými projekty nebo jejich částmi. Tímto se do firemní organizační struktury vypůjčují i prvky ze Síťového projektového řízení a to
konkrétně rozdělení na kmenové a externí pracovníky. Jsou najímáni jak externí programátoři z vybraných libereckých firem, tak se ale také jedná i o jeden projektový tým z Ukrajiny. K tomuto řešení se firma uchýlila, protože již nebylo možné nalézt případně i opravena interním zaměstnancem, protože poměrně často jejich software obsahuje chyby nebo funkcionalita nepokrývá veškeré možné situace, které mohou nastat v případě používání zákazníkem. To staví značný tlak na testery a projektové manažery daných projektů a vyloženě plýtvá jejich časem. Zde by stálo za to zjistit, zda je vůbec výhodné nechat práci na těchto externích pracovnících a poté opravovat jejich kód, nebo zda by nebylo lepší a časově výhodnější, kdyby to naprogramoval rovnou kmenový zaměstnanec.
Toto řešení se nezdá příliš vhodné. Naopak, jako zajímavý nápad se jeví organizační model Projektová kancelář, kde existuje zvlášť oddělení, které by se staralo o celkovou integraci v rámci všech projektů a zajištění používání stejných moderních technologií. Vzhledem k velkému počtu souběžně běžících projektů a dalších, které přibývají, by toto řešení mohlo být pro firmu z dlouhodobého hlediska lukrativní. Projektová kancelář by prospěla lepšímu plánování projektových struktur organizace a efektivnějšímu využívání pracovních sil. V druhé řadě by projektová kancelář mohla sloužit jako kontrolní orgán napříč všemi projekty, stejně tak jako vzdělávací útvar, který by měl na starosti školení a předávání zkušeností novým zaměstnancům nebo funkci preventivní, tak aby se na nových projektech neopakovaly stejné chyby jako v těch předchozích. Jistou náhradu za Projektovou kancelář zastává v současné době projektový ředitel, který má na starosti management jednotlivých projektů a jejich projektových manažerů. Ale projektů k řízení je příliš mnoho pro jednoho člověka, lepší by bylo použít komplexnější řešení jakým je Projektová kancelář.
I když ve firmě vždy při realizaci nového projektu již dochází k určité analýze požadavků a plánování rozvržení pracovních rolí mezi stávající zaměstnance, centrální plánování, které má dokonalý přehled napříč všemi projekty a přehled o pracovní vytíženosti jednotlivých
rozsah projektu, nejsou přítomni projektoví manažeři, kterým je daný projekt přidělen. Se zadavatelem projektu je vedeno řízení, kde se dojednává smlouva a určuje rámec poskytnutých služeb. Vývojářský tým se těchto jednání neúčastní a proto jej ani nemohou nijak ovlivnit. Jejich pohled na věc ani zkušenosti z jiných podobných projektů nejsou brány v potaz. Díky tomu je ne vždy například přesný odhad časové náročnosti přípravy. A samotná realizace projektu je pak následně v časové tíži a jednotliví členové týmu pod tlakem. Nicméně i přesto se ve většině případů daří projekty stihnout včas dokončit, ale je to náročné na psychiku zaměstnanců a z dlouhodobého hlediska by mohlo docházet k takzvanému vyhoření.
Dále samotné plánování projektu probíhá následovně tak, že se nejdříve určí rozsah projektu, všechny požadavky zadavatele projektu. Na základě těchto informací se určí, zda se použije nějaký stávající systém, který se případně upraví pro potřeby zákazníka, nebo zda se naprogramuje zcela nový systém. Někdy je časově výhodnější začít programovat od začátku nanovo. Podle toho je následně sestaven vhodný projektový tým s ohledem na jejich zkušenosti s předchozími projekty a zároveň i současnou pracovní zatíženost.
Pro vedení firmy a zákazníka je důležitý odhad doby trvání vývoje projektu. Špatný odhad může být vážný a drahý problém, ale na druhou stranu stejně tak může představovat problém i dlouhá a nákladná analýza problematiky. (Young, 2007, s. 139)
3.4 Životní cyklus projektu
Jakožto nejspíš každá firma v oboru, si i tato firma prošla různými typy organizace vývoje softwaru. Ve svých začátcích by se princip, podle kterého ve firmě fungoval vývoje softwaru, dal označit za model ‚Napiš a oprav‘. Naštěstí se od této koncepce upustilo a firma se vyvinula dál, později se přešlo ke klasickému Vodopádovému vývoji, kdy se již pracovalo podle určitého workflow, které se osvědčilo při předchozích projektech. Tato koncepce fungovala v případě, že se jednalo o podobné projekty.
Díky malé velikosti firmy o pouhých dvaceti pěti lidech a velmi specifickým projektům se osvědčilo používání agilních metodik způsobu práce. Na prvním místě priorit se objevila komunikace a blízká spolupráce se zadavatelem projektu. Každý milník či problém, na
který se během vývoje přijde, je s ním hned projednáván. Zákazníkům je i nasloucháno a jejich zpětná vazba je často zakomponována do budoucích plánů.
Firma také začala využívat několik aplikací třetích stran pro zefektivnění jejich vývojových procesů.
Pro zlepšení plánování se začala používat aplikace Youtrack. Aplikace, v níž lze nahlašovat a sledovat softwarové bugy, nebo plánovat úkoly, tzv. ‚Task‘. Tyto úkoly lze přiřadit jednotlivým členům týmu a určit jejich časový plán. Takový časový plán se v této aplikaci nazývá ‚Sprint‘, což je určitá časová doba, nejčastěji týden.
Představení aplikace na stránkách výrobce uvádí (JetBrains, 2019-02-28), „A project management tool that can be adapted to your processes to help you deliver great products.
Track tasks and bugs, plan sprints and releases, create workflows, and customize YouTrack for your business processes.“ - „Nástroj pro správu projektů, který lze přizpůsobit vašim procesům, aby vám pomohl dodat skvělé produkty. Sledujte úkoly a chyby, plánujte sprinty a vydání softwaru, vytvářejte pracovní postupy a přizpůsobte YouTrack vašim obchodním procesům.“
Na obrázku 11 je vidět prostředí aplikace Youtrack, konkrétně plánovací nástěnku, kde je možné přehledně plánovat úkoly na jednotlivé sprinty.
Obrázek 11: Prostředí aplikace YouTrack