• Koncept
o Koncept při druhu úlohy „Požadavek na úpravu“ a „Chyba“ je prvním krokem. K tomuto kroku vývojového procesu jsou tyto druhy úlohy přiřazeny v momentě, jakmile jsou projektovým týmem vytvořeny a uloženy.
o V „Konceptu“ člen projektového týmu sepisuje základní informace ohledně požadavku na úpravu softwaru nebo chybě. Jestliže má člen produktového týmu dostatečné informace, aby vytvořil plnohodnotný úkol a tyto informace přehledně a správně zpracuje, tak je možné úkol posunout do dalšího kroku
„Produkt: K převzetí“.
• Produkt: K převzetí
o Úlohu dostává konkrétní řešitel v oddělení produktového týmu. V tomto úkole zanalyzuje obdržené požadavky a související informace. Jeho úkolem je posoudit, zda jsou informace správné a dostatečné a na základě diskuze s Product Ownerem zařadit úlohu do správného Epicu se správnou verzí vydání nové verze softwaru. Po provedení těchto úkonu se úloha posouvá k dalšímu kroku „Produkt: Rozpracováno“.
• Produkt: Rozpracováno
o V tomto kroku se úloha stále drží u produktového manažera, který je uveden jako řešitel. Tento krok je pro doplnění důležitých informací, které se získají například analýzou legislativy či konzultace s ostatními členy jak produktového oddělení, tak i oddělení vývoje. V závěrečném kroku projektový manažer zkontroluje správné umístění úlohy v rámci Epics a verze. Po kontrole se posouvá úloha dále na krok „Vývoj: K převzetí“.
• Produkt: Reklamováno
o Tento krok vývojového cyklu softwaru je pro stav, kdy oddělení vývoje obdrží úkol, ale na základě stávajících informací není schopen úlohu úspěšně zpracovat. Po konzultaci s Product Ownerem a předcházejícím projektovým manažerem, který byl řešitel dané úlohy, se úloha vrací o krok zpět na projektového manažera, který úlohu zpracovával. Úkolem projektového manažera je na základě konzultace doplnit chybějící informace, nebo na základě nově zjištěných informací úlohu upravit. Jestliže je tento krok
proveden úspěšně, tak se úloha posouvá na další krok a to „Vývoj:
K převzetí“.
• Vývoj: K převzetí
o V tomto kroku vývojového cyklu dostává úlohu oddělení vývoje. Úloha je přiřazena vedoucímu oddělení vývoje, který na základě komunikace s Product Ownerem urči Sprint Backlog. Po určení Sprint Backlogu a zařazení konkrétní úlohy do Sprintu daného týdne se určí podle Kanban Table vhodný programátor, který bude konkrétní úlohu zpracovávat, a úloha se mu přiřadí. Po provedení těchto kroků se ještě nemění stav kroku vývojového cyklu softwaru. Ten se mění, jakmile přiřazený programátor zanalyzuje obsah úlohy a označí ji, že na ní začíná pracovat. V tomto momentě se daná úloha posouvá na „Vývoj: Rozpracováno“.
• Vývoj: Rozpracováno
o Přiřazený programátor úlohu označil, že na ní začal pracovat. Programátor nyní tvoří algoritmus a sepisuje kód, aby splnil zadání úlohy. Při řešení komunikuje s ostatními členy oddělení vývoje a případně i s projektovým manažerem, který úlohu zpracoval. Při zpracování celé úlohy probíhá komunikace mezi přiřazeným programátorem a členy projektového týmu k případnému vysvětlení požadavku. Je to z důvodu toho, že každý člověk si může psaný text vyložit po svém a je vhodnější ústní upřesnění a nasměrování programátora k vytvoření požadovaného algoritmu, než aby programátor vytvořil „něco“ podle sebe a ve výsledku odevzdal algoritmus s nepožadovaným výsledkem. Zároveň je zde i prostor přímo pro invenci programátora, pokud ho při vypracování úlohy napadne vhodnější řešení. Na základě tohoto zjištění navrhne úpravu zadání úlohy pro vypracování. Tento návrh konzultuje s projektovým manažerem a na základě toho se rozhodují, jestli se bude pokračovat původní zadání úlohy anebo navrženým a upraveným zadáním. Jakmile programátor vytvoří algoritmus, který splňuje zadání, tak se úloha posouvá na krok vývojového cyklu „Test: K převzetí“.
• Vývoj: Reklamováno
o Tento krok vývojového cyklu softwaru označuje stav, kdy úlohu obdrží zpět programátor od testera poté, co tester nalezne chybu či nesrovnalost oproti zadání.
o Programátor, který obdrží úlohu nazpátek, tak provádí úpravy na základě zpětné vazby od testera. Tento krok se při procesu vývoje úlohy nemusí vůbec stát anebo se může stát i vícekrát. Záleží na obtížnosti zadání, zkušenosti a šikovnosti programátora, jak danou úlohu dokáže zpracovat. Vždy když vrací úlohu zpět testerovi, tak posouvá na krok vývojového cyklu „Test:
K převzetí“.
• Test: K převzetí
o První krok vývojového cyklu softwaru, který má na starosti tester. Tester si v tomto kroku musí přesně projít zadání úlohy, nastudovat si, co přesně bylo cílem za vytvoření funkcionality anebo úpravy funkcionality. Dále si musí zjistit v jakém Epicu je daná funkcionalita vytvořena a v jaké verzi je publikován build aplikace. Jakmile tester takto úlohu nastuduje a zanalyzuje, tak přesouvá celou úlohu na krok „Test: Rozpracováno“.
• Test: Rozpracováno
o Tester posunul úlohu na krok „Test: Rozpracováno“. Tím si otevřel úlohu, kterou obdržel od oddělení vývoje a nyní má za úkol otestovat a projít publikovanou verzi softwaru s funkcionalitou a provést několik schémat testů. Jelikož se jedná o první vlnu testů, tak je velice pravděpodobné, že se některé nedostatky testerovi povedou objevit. Všechny nedostatky sepíše detailně, co je nekorektně zpracováno, případně v jakém stavu a při jakých krocích se objevuje chyba a úlohu vrací o krok zpět na krok „Vývoj:
Reklamování“. Zároveň s tímto přiřazuje nazpátek programátora, který úlohu vypracovával.
o Jakmile s testováním skončil a nalezl nedostatky, tak posouvá úkol zpět v rámci vývojového cyklu na krok „Vývoj: Reklamováno“. Pokud se testerovi při provádění testovacích schémat nepodaří objevit nedostatek nebo chybu ve fungovaní funkcionality a celého softwaru a software je stabilní (neobjevují se jiné chyby), tak úlohu posouvá dále v rámci vývojového cyklu na krok „Produkt: Kompletace“.
• Produkt: Kompletace
o Krok „Produkt: Kompletace“ znamená, že úloha prošla první iterací vývoje, je otestovaná a funkční v rámci Epicu. Tento krok dává úlohám vlastnost, že jsou připraveny k Mergi do hlavní vývojové větve. Pokud všechny úlohy v rámci jednoho Epicu získají tento krok v rámci vývojového cyklu softwaru, tak se celý Epic posouvá do stavu „Merge“.
• Test Merge: K převzetí
o Tímto krokem začíná druhé kolo testování. Úloha se z Epicu dostala do hlavní vývojové větvě softwaru. Nyní je požadavek na testera zajistit opětovné otestování úlohy, aby ověřil, že během procesu Merge nedošlo k tomu, že nová funkcionalita přestala fungovat, začaly se objevovat některé chyby anebo jiné nechtěné konflikty, které mohly vzniknout právě Mergem do hlavní vývojové větve softwaru.
• Test Merge: Rozpracováno
o Tester se zaměří na jednu konkrétní úlohu a posune ji do stavu „Test Merge:
Rozpracováno“. V tomto kroku inicializoval testování úlohy ve druhé vlně a testuje úlohu v hlavní vývojové větvi aplikace. Opět veškeré nedostatky, či případné chyby podrobně zapisuje i například s přiloženými obrázky nebo logy aplikace. Po dotestování posouvá úlohu buď na krok vývojového cyklu softwaru „Vývoj Merge: Reklamováno“, když se během testu objevily chyby anebo na „Produkt: Hotovo“, pokud se během testu už chyby neobjevily.
• Vývoj Merge: Reklamováno
o „Vývoj Merge: Reklamováno“ je krok vývojového cyklu softwaru, do kterého se úloha dostává na základě druhé vlny testování. Jakmile tester objeví ve druhé vlně testu chybu, znamená to, že funkcionalita z úlohy je již implementovaná v hlavní větvi softwaru. Oddělení vývoje a původní řešitel programátor obdrží úlohu nazpátek, aby na základě zpětné vazby od testera provedl následné nápravy.
o Jelikož se jedná o druhou vlnu testování, tak nebývá pravidlem, že by se v tomto kroku už objevovaly některé chyby, zvlášť když se první vlna testování prováděla poctivě. Avšak se může stát, že se chyby naleznout i při tomto kroku vývojového cyklu softwaru.
• Vývoj Merge: Rozpracováno
o V tomto kroku vývojového cyklu softwaru se provádí opravná činnost od programátora na základě zjištěných chyb z druhé vlny testování po implementování úlohy do hlavní větve softwaru. Programátor musí provést analýzu zpětně vazby od testera a na základě zpětné vazby provést nápravu funkčnosti aplikace. Po provedení nápravy posouvá úlohu v rámci vývojového cyklu na krok „Test Merge: K převzetí“ k opětovnému otestování právě provedené nápravy.
• Produkt: Hotovo
o Do stavu „Produkt: Hotovo“ se úloha dostává po úspěšném Mergi a úspěšném otestování ve druhé vlně. Aby se úloha do tohoto stavu dostala, tak musí projít vývojovým cyklem bez nalezených chyb nebo nepřesností vzhledem k zadání. V tomto stavu se úloha „odškrtává“ vzhledem k vývojovým činnostem projektového týmu. Zbývá ještě provést a zpracovat uživatelskou dokumentaci na nově vzniklou funkcionalitu z úlohy. Tím se úloha posouvá do stavu „Dokumentace a distribuce“.
• Dokumentace a distribuce
o Úloha je z pohledu vývoje a analýza dokončena. Úlohu obdrží k dořešení oddělení podpory zákazníka. Zde je jejich činnost a cíl ten, že si musí funkcionalitu z úlohy podrobně nastudovat a zpracovat uživatelskou dokumentaci, která se publikuje do uživatelského prostoru na webu „Centrum Informací“. Po zpracování dokumentace a nastudování nové funkcionality se úloha dostává do stavu „K uzavření“.
• Distribuce: Reklamováno
o Jedná se o poslední krok vývojového cyklu softwaru, který vrací úlohu nazpátek. Děje se to v momentě, kdy oddělení podpory zákazníka zjistí při práci na úloze nějakou nesrovnalost. Tuto nesrovnalost musí detailně popsat a předat veškeré informace, podle kterých se jedná opravdu o nesrovnalost.
Jakmile tyto informace a nedostatky sepíší, tak s tímto krokem vrací úlohu zpět na původního produktového manažera, aby si zpětnou vazbu od oddělení produktu zákazníka nastudoval. Na základě toho se a případné diskuze se rozhodne jakým, způsobem se bude nadále pokračovat. Může se buď vytvořit
nová úloha, která budou souviset s touto původní a bude zpracovávat zpětnou vazbu od člena oddělení podpory zákazníka. Zpětná vazba se může se také vyřešit v rámci původní úlohy. Úloha se dostane znovu do oddělení vývoje a zde se nedostatky vyřeší. Poslední možným způsobem řešení je ten, že se na základě diskuze s projektovým týmem a Product Ownerem nebude zpětná vazba řešit a úkol se posouvá na krok „K uzavření“.
• K uzavření
o V kroku vývojového cyklu softwaru „K uzavření“ se řeší poslední evidenční informace úlohy, kdy se eviduje, jestli byla úloha opravdu realizována, nebo případně nebyla realizována a důvod této nerealizace. Dále se zde evidují verze aplikace, ve kterém se úloha nakonec reálně vyřešila. Posledním prvkem tohoto kroku je, že se musí předat informace Product Ownerovi, aby získal podvědomí o dokončení úlohy. Jakmile je toto provedeno, tak se úloha uzavírá krokem „Uzavřeno“.
• Ke zrušení
o Speciální krok vývojového cyklu softwaru je „Ke zrušení“. Do tohoto kroku se úloha může dostat prakticky z každého jiného kroku. Tento krok „Ke zrušení“ uvádí, že se daná úloha nebude realizovat a zjistilo se to již během jiného kroku, a to ať už při úvodní analýze, detailnější analýze nebo později.
V tomto kroku se u úlohy uvádí, proč se daná úloha nebude realizovat a přesunem do kroku „Ke zrušení“ se úloha zruší. Jakmile se tyto informace uvedou, tak se úloha posouvá na poslední krok vývojového cyklu softwaru, a to „Uzavřeno“.
3 Návrh zefektivnění vývojového cyklu
V následující kapitole je sepsáno několik návrhů na zefektivnění cyklu pro vývoj softwaru, na základě definované teorie v diplomové práci a praktických zkušeností získaných během práce ve společnosti, kterou se zabývá tato diplomová práce.
3.1 Určení jednoznačné metodiky
Během tvorby analýzy aktuálního stavu ohledně způsobu projektového řízení vývoje softwaru bylo určeno, že jeden z hlavních bodů nedostatků je, že nikde není jasně určeno, jakým způsobem společnost provádí projektové řízení. Při analýze bylo zjištěno, že se jedná o stav „někde na půli cesty“ mezi tradiční metodikou a metodikou agilní. To znamená, že některé činnosti se provádí stále způsobem tradičních metodik, i když se společnost snaží přesunout do agilního světa projektového řízení vývoje softwaru. Jak je sepsáno v druhé kapitole této diplomové práce, tak je ve společnosti použit velmi strukturovaný procesní graf, kterým by měl projít každý prvek Product Backlogu podle druhu úlohy. Problém však nastává v momentě, kdy se u některých úloh takto nejedná, a někteří členové produktového týmu mají silnější vliv a dokáží si své úlohy „protlačit“ svým způsobem bez ohledu na strukturovaný procesní graf pro projektové řízení vývoje softwaru. Tyto upřednostněné úlohy následně neprobíhají vůbec žádným Epicem, ale jsou vyvíjeny přímo do hlavní vývojové větve programu. Zpravidla jsou zde tvořeny iterační metodou z tradičních metodik. Toto obcházení vývojového procesu může způsobit problémy v plánování týdenních Sprintů. Navíc mohou vznikat nepřesnosti či jiné nepřehlednosti v daných plánech či dokonce využití pracovní kapacity jednotlivých oddělení projektového týmu.
Z technického hlediska je pak problém merge jednotlivých Epiců (vývojových větví), který je pak náročnější do změněného kódu proti stavu na začátku, kdy se Epic (větev) oddělil.
Zároveň je to doprovázeno dalším závažným problémem, který byl identifikován. Vedoucí pozice projektového týmu jsou zastoupeny pracovníky, kteří nemají úplně velké zkušenosti s projektovým řízením pomocí agilní metodiky. Tento stav vede k tomu, že se agilní metodiky prosazují od členů projektového týmu, kteří jsou v organizační struktuře společnosti níže. Tento přístup je shledán za ne velice vhodný. Může docházet ke střetům
mezi členy projektového týmu. Projekt je veden dle procesního grafu vývoje softwaru a do této části projektu vstoupí člen projektového týmu z vyšší pozice organizační struktury, který nemá tolik zkušeností z agilní metodiky řízení a razí svoji cestu. Tato vlastní cesta je zpravidla postavena na tradiční metodice. V momentě, kdy dojde ke střetu názorů, tak se projet začne řídit podle člena projektového týmu, který je v organizační struktuře firmy výše.
Návrhem pro zlepšení stavu je vydání závazné interní směrnice, která stanoví proces řízení vývoje softwaru podle agilních metodik a začne se prosazovat od nejvyšších pozic členů projektového týmu. Jakmile se tohoto docílí, tak se začne prosazovat jeden shodně obecný postup při řízení projektu, který se bude razit od nejvyšších pozic až po ty nejspodnější agilních metodik. Tato druhá část návrhu bude zpočátku pro společnost náklad. Přinese to však společnosti tolik cenné zkušenosti ohledně této problematiky. Tyto zkušenosti pomůžou postavit pevné základy pro řízení projektů pomocí agilních metodik. Na těchto pevných základech je pak možné dále stavět, a profitovat z toho bude jak celý projektový tým společnosti, tak i společnosti jako taková. Výsledek návrhu bude zefektivnění a zoptimalizovaní projektového řízení. Tato optimalizace a zvýšení efektivnosti projektového řízení ve výsledku sníží časové a finanční náklady při vypracování jednotlivých projektů a zvýší i celkové příjmy firmy.
3.2 Jasné určení role Product Ownera v projektovém týmu
Tento návrh pro optimalizaci projektového řízení při vývoji softwaru v agilní metodice souvisí s předcházejícím bodem. Při analýze bylo zjištěno, že není definovaná role Product Ownera, která je brána v úvahu při projektovém řízení vývoje softwaru napříč celou firmou.
Product Owner zde existuje pouze jako jakási „neoficiální“ role, která se bere v potaz pouze pomocí interní komunikace mezi oddělením vývoje, oddělením analýzy pro produkt a oddělením technické podpory. Propojení oddělení obchodu a Product Ownera je velice slabé.
Místo toho se děje, že obchodník po získání zpětné vazby vynechá komunikaci s Product Ownerem a s požadavkem na analýzu přichází rovnou do oddělení analýzy. Vznikají tak nepřesnosti a nepředvídatelnosti při organizaci a plánování časového harmonogramu jednotlivých oddělení. K tomu Product Owner ztrácí kontrolu při řízení a přehled o jednotlivých požadavcích na vývoj. Zároveň Product Owner ztrácí možnost plánování Product Backlogu a následně i jednotlivých Sprintů a Sprint Backlogů. Omezují se jeho možnosti při plánování vydávání jak iterací funkcionalit pro pilotní zákazníky, tak i plánování vydávání oficiálních verzí softwaru pro všechny zákazníky. Díky těmto odkladům při vydávání verzí mohou vznikat záporné zpětné vazby od zákazníků, nesrovnalosti v komunikaci a podobně. Všechny tyto záporné vlastnosti mohou vrhat špatné světlo na firmu mezi zákazníky i potencionálními zákazníky. Pro firmu se tento problém projeví snížením celkových příjmů, ale může se i projevit zvýšením celkových nákladů při tvorbě jednotlivých funkcionalit a oficiálních verzí softwaru.
Návrhem v rámci tohoto bodu je to, aby se v organizační struktuře firmy přímo vytvořila pozice Product Ownera. Tato role bude existovat oficiálně „úředně“ ve firemní politice. Člen projektového týmu, který zastoupí tuto roli bude mít jasně definované činnosti a cíle, které by měl plnit. V první kapitole této práce je pozice Product Ownera teoreticky definována a definice také obsahuje to, že by role Product Ownera neměla být spojovaná s nějakou další rolí v rámci organizační struktury nebo projektového týmu. Je to z toho důvodu, aby si Product Owner dokázal nastavit potřebné cíle při vývoje softwaru s potřebným nadhledem.
Kdyby se stalo, že role Product Ownera bude zastoupena členem projektového týmu, který již zastává ještě nějakou další roli, tak okamžitě Product Owner ztrácí potřebný nadhled.
Tím může nastat problém, že při plánování při vývoji softwaru se upřednostňuje pouze nějaká primární část projektu a další jsou „odstaveny“ na druhou kolej. Toto se nesmí stát, a proto by role Product Ownera měla být zastoupena členem projektového týmu, který bude nezávislý vůči dalším rolím projektového týmu nebo pozic organizační struktury firmy.
Jakmile vznikne oficiálně role Product Ownera, která bude zastoupena nezávislým a schopným členem projektového týmu, tak vznikne správné plánování Product Backlogu, plánování Sprint Backlogů a konkrétních Sprintů. S tím je spojeno, že vznikne komplexnější přehled zdrojů a kapacit při plánování vývoje softwaru. Zároveň vznikne důvěryhodnější odhad při plánování vydávání oficiálních verzí pro zákazníky.
Zavedením činností, které s sebou role Product Ownera se zlepší komunikace se zákazníkem, což by mělo přinést převažující kladnou vazbou. Tímto vytvořeným kladným podvědomím o firmě a její schopnosti tvořit a úspěšně dokončovat jednotlivé projekty se otevírá možnost oslovit pro spolupráci více potencionálních zákazníků. Firma získá větší celkové příjmy jak ze stávajících, tak i z nově získaných potencionálních zákazníků.
Zároveň omezí celkové náklady při nepřesnosti plánování nebo jiných problémech s tím spojených.
3.3 Jasné určení role Scrum Master v projektovém týmu
Jestliže je v předchozí kapitole zanalyzován návrh zavedení role Product Ownera do oficiální role projektového týmu, jelikož existuje ve společnosti pouze v neoficiální formě, tak u role Scrum Master je situace jiná. Při analýze současné situace při projektovém řízení vývoje softwaru se zjistilo, že role Scrum Master v projektovém týmu neexistuje vůbec. Jak vyplývá z definice role Scrum Mastera, tak se jedná o stejně důležitou roli jako Product Owner. Role Scrum Mastera má za cíl propojit celý projektový tým do kompaktní a efektivní entity společnosti. Měl by se starat o celý tým tak, aby spolu co nejvíce úzce spolupracoval, aby zde panovala pravidelná komunikace a pokud by v projektovém týmu vznikl problém, tak je to právě Scrum Master, který tento problém řeší do zdárného a uspokojivého závěru.
Zároveň je to takový dirigent při schůzích projektového týmu, aby diskuze probíhala správnou nekonfliktní formou a postupovala efektivně v celém průběhu.
Ve společnosti je v současnosti projektový tým, který je rozčleněn podle frameworků aplikace. To znamená, že celá aplikace je rozdělená do několika částí. Rozdělení je zobrazeno v tabulce níže.
Framework Počet členů z projektového týmu
Popis frameworku
CORE 6 členů V tomto frameworku se vyvíjejí funkcionality, které se používají napříč celou aplikací. Jedná se například o předky
CORE 6 členů V tomto frameworku se vyvíjejí funkcionality, které se používají napříč celou aplikací. Jedná se například o předky