background design element dropbackground design element dropbackground design element drop

Co je agilní vývoj aplikací a kdy jej využívat


Barbora Koďousková
Aktualizováno:20.10.2020· 15 min. čtení
Počet zobrazení:18942
Facebook iconTwitter iconLinkedIn icon
Obsah článku
Facebook iconTwitter iconLinkedIn icon

Pokud patříte mezi vývojáře, nebo jste se rozhodli pro vývoj vlastní aplikace pro podnikání, tak jste se již jistě setkali s pojmem agilní metody vývoje (agile). Agile je ve své podstatě odpovědí na otázky, jak přistupovat k organizaci a realizaci projektu. Jedná se tedy o určitý standard, který stanovuje, jakým způsobem by měla probíhat komunikace v týmu a s klientem.

Úloha programátora již dávno nespočívá pouze ve znalosti a dovednosti aplikovat programovací jazyky či javascriptové frameworky. Moderní weby vyžadují komplexní přehled o aktuálních trendech webových i mobilních aplikací, pravidlech SEO či metodikách přístupu k programování. Metodiky se pak obvykle člení na původní rigorózní a novější agilní, jejichž smyslem je zvýšení produktivity a efektivity práce.

co je agilní programování

Co znamená agilní vývoj

Agile je tedy označení pro způsoby tvorby softwaru založené na iterativním (přírůstkovém) či inkrementálním vývoji, k čemuž hodně využívají takzvané MVC architektury. Základním princem agilní metody je úzká spolupráce mezi vývojářem a zákazníkem, který po dokončení každého cyklu zadává připomínky na úpravy a přímo tak ovlivňuje průběh vytváření webové, či mobilní aplikace.

Agilní metody se v praxi vyskytují již nějakou dobu, jejich oficiální podobu však definuje až Manifest agilního programování z roku 2001. V tomto manifestu lze najít bližší specifikaci přístupu a zásady, kterých by se měli vývojáři i klienti během spolupráce řídit. Projekt řízený agilním přístupem lze rozdělit do několika fází:

  • nultá iterace – prvotní krátká analýza předložených požadavků a naprogramování základní kostry,
  • analýza změny – stanovení plánu pro jeden cyklus, kdy každý z programátorů dostává úkol, který je potřeba během stanovené doby zpracovat,
  • implementace požadované změny – samotné programování a realizace naplánovaných činností,
  • předvedení klientovi – klient dostane první verzi celkového projektu a dostává prostor pro připomínkování, bližší specifikaci další funkcionality a podobně.

co je agilní vývoj aplikací

Jakmile se klient vyjádří, započíná se druhý cyklus, který musí opět projít všemi uvedenými fázemi vývoje. Takto se celý proces opakuje až do té doby, dokud není klient se svou aplikací spokojen. Když se tak stane, přichází na řadu potřebná údržba a další případný rozvoj. Projekt se tedy ke klientovi dostává postupně, přičemž mohou tvůrci nástroje okamžitě reagovat na jeho připomínky a řídit se jimi před započetím dalšího kroku. Podmínkou každého cyklu pak zůstává, že musí být vždy hotová alespoň část dalšího kódu, aby měl zákazník co hodnotit.

Tento přístup je alternativou k původnímu rigoróznímu vývoji, který zákazníkovi prezentoval až kompletní aplikaci. Agile může v mnoha případech vést k větší spokojenosti klienta a současně umožnit postupné nasazování aplikace do provozu. Příkladem takto řízeného projektu je například streamovací služba Spotify, jež tímto způsobem uzpůsobovala své prostředí posluchačům.

Příklady agilních metod

Agilní programování je možné realizovat prostřednictvím několika přístupů. Jedná se o obecné pojetí, které je vždy nutné přizpůsobit prostředí a možnostem konkrétního vývojářského týmu. Každý člen týmu by se pak měl s jeho praktikami ztotožnit a dodržovat nastolené standardy. Příkladem může být extrémní programování, jeden z nejstarších agile přístupů k vývoji aplikací, který je postaven na častých dodávkách softwaru v krátkých vývojových cyklech.

Je zde aplikované jednotkové testování kódu, což znamená že je v první řadě specifikován způsob a smysl testu a až později psán program (aplikace). Programuje se pak pouze ta část, která je nezbytně nutná. Stejně jako u ostatních agilních metod je i zde dbáno na častou komunikaci se zákazníkem a v rámci programátorského týmu. Vývojáři si typicky stanovují vlastní, interní standardy, kodex, kterého se při programování dodržuje. Může se jednat například o formátování jednotlivých částí kódu nebo způsoby komentování. Programátor si v případě extrémního programování obvykle sám volí, kterou část kódu bude tvořit a současně může utvářet dvojici s dalším programátorem. To je v praxi označováno jako párové programování.

Hojně využívanou agilní metodou je takzvaný Scrum. Scrum je postavený na úzké spolupráci mezi všemi členy týmu, kteří spolu každodenně komunikují (ať už osobně, nebo virtuálně, například pomocí Slacku) a vzájemně se informují o vykonané práci i o plánech pro aktuální den.
Práce na projektu se rozděluje do sprintů čili úseků, ve kterých by měla být vyvinuta předem stanovená část aplikace. Délka trvání jednoho sprintu se odvíjí od zvyklostí konkrétního týmu a povahy projektu, může se jednat o rozmezí 1-4 týdnů, přičemž je typicky využíván čtrnácti denní interval. Výstupem každého sprintu by mělo být demo aplikace, které je předloženo klientovi pro další připomínky a návrhy.

Každému sprintu by měla předcházet krátká schůzka během které se tým domluví, co vše se bude během úseku vykonávat a stanoví si počet hodin, jenž nad prací stráví. Jednotlivým programátorům je přidělena, respektive každý programátor si zvolí, určitou část, na kterou se zaměří a zbytek úkolů se uloží do backlogu. Čili skladiště shrnující všechny potřebné úkony. Během sprintu již komunikace probíhá výše uvedeným způsobem, tedy formou krátkého pravidelného reportu o vykonané a plánované činnosti.

Scrum současně definuje tři základní hierarchické role. Nejvyšší příčkou žebříčku je Product Owner, jež má na starosti veškerou komunikaci s klientem a definování toho nejlepšího produktu. Do značné míry tedy rozhoduje o tom, která funkce by se měla kdy implementovat. Pod ním je vedoucí programátorského týmu, nazývaný Scrum Master. Ten má na starosti zajištění řádného chodu vývoje neboli kontrolu činnosti vývojářů. Vývojáři utvářejí poslední příčku hierarchie, Scrum terminologie je definuje jako Scrum Team Members.

Třetím příkladem přístupu k agilnímu vývoji aplikací může být Lean Developmment a MVP. Metodika, který má za cíl zefektivnit a zrychlit celý proces tvorby aplikace. Vývoj je zde rozdělen do pěti částí a programátorům pevně přidělena konkrétní úloha.

Jak probíhá agile (Scrum) vývoj aplikace

Předchozí odstavce již naznačily popularitu agile vývoje s využitím Scrum, který nyní uvedeme do praktického příkladu. Celý proces započíná oslovením vývojářského týmu a stanovením základní funkcionality. Na to Product Owner (projektový manažer) svolá Sprint planning čili setkání pro tým vývojářů, na kterém se projekt rozdělí do menších časových úseků (sprintů) a stanoví se činnosti, kterým se budou jednotlivci během první fáze cyklu věnovat. Zbytek se uloží do backlogu (již zmíněného místa pro budoucí úkoly).

Stanovená činnost není zcela striktně daná, ale neměla by se v průběhu sprintu měnit. Na konci dvoutýdenního cyklu (případně jiného stanoveného termínu) by mělo být vyhotoveno kompletní zadání. Během každého sprintu probíhá technická analýza v podobě testování a revize uživatelského rozhraní z hlediska uživatelské přívětivosti (UI/UX design). Pokud by programátor během sprintu měl čas navíc, může využít úkolů uložených v backlogu. Po skončení sprintu je dosavadní podoba aplikace zaslána klientovi, který ji ohodnotí a udělí případné další pokyny, aby se mohl celý proces zopakovat.

Jak funguje agilní vývoj scrum

Zákazník se tak sám aktivně podílí na vývoji své aplikace a má možnost zasahovat do její finální podoby již v průběhu procesu. Agilní vývoj apps v tomto podání dává prostor pro vytváření kvalitních produktů za poměrně krátký čas, v závislosti na množství připomínek apod. Z popisu již ovšem vyplývá důležitost pozice Product Ownera, který má za úkol stanovovat prioritní úkoly tak, aby se vývoj vždy posunul směrem kupředu a nezacyklil se v nekonečném koloběhu sprintů.

Výhody a nevýhody agilního vývoje

Ze stávajícího textu již vyplynulo několik základních výhod, které agilní vývoj aplikací provázejí. Tou nejzásadnější je bezpochyby maximální přizpůsobení produktu potřebám a požadavkům zákazníka. Druhým kladem může být příležitost k průběžnému nasazování řešení na produkci, kdy si je klient jistý, že pokaždé dostane hodnotnou část softwaru. Současně se nedělá nic navíc, jelikož klient sám do značné míry určuje, na čem konkrétně bude tým v rámci cyklu pracovat. Šetří se tak finanční prostředky i čas a platí se jen za produktivní činnost. Průběžné dodávání je navíc spojeno také s průběžným testováním, jež umožňuje okamžitou opravu případných chyb.

Nevýhody agilního vývoje lze shledávat zejména v požadavcích na zákazníka i vývojářský tým. Ne každý klient má dostatek času a energie k tomu, aby mohl pravidelně konzultovat objednaný produkt. Může být proto pro něj vhodnější přístup, kdy se k němu dostane až finální verze aplikace, přičemž nemusí do průběhu vývoje nikterak zasahovat. Stejně tak nemusí agile vyhovovat každému vývojářskému týmu. Je tedy na zvážení každého z nich, zda se mu tato forma spolupráce vyplatí, nebo raději zvolí klasický vodopádový model.

Kdy využít agilní vývoj aplikace

Pro agilní vývoj aplikace by se měl rozhodnout pouze ten klient, který má zájem či čas na projektu úzce a pravidelně spolupracovat. Z druhé strany programátorský tým potřebuje mít někoho, kdo se postará o komunikaci s klientem a současně zvládne efektivně koordinovat vývoj tak, aby každý cyklus přinesl nějaký posun ve funkcionalitě či vzhledu aplikace.

Ve většině případů se agile přístup hodí zejména v situací, kdy klient ještě nemá přesnou představu o finální podobě aplikace a pro větší projekty, které je nutné postupně přizpůsobovat. Současně ovšem není nutné tuto formu aplikovat u menších projektů.

Vodopádový versus agilní vývoj aplikací

Předchozí obsah již několikrát zmiňoval alternativu k agile vývoji, kterou jsou rigorózní metody. K tomuto účelu je typicky nejčastěji přistupováno přes takzvaný vodopádový model, jenž dodnes zastává řada předních vývojářů.

Co je vodopádový model vývoje aplikací

Vodopádový model je tedy předchůdcem agile přístupu k tvorbě aplikací a současně jedním z nejzásadnějších představitelů rigorózní metodiky. Jedná se o sekvenční vývojový proces, jehož jednotlivé části na sebe plynule navazují a vycházejí ze sebe. Nelze tedy žádnou etapu přeskočit ani přerušit. Posun v procesu je tak přímo závislý na zajištění stoprocentní úspěšnosti předchozí fáze.

Vždy je zde proto zajištěna maximální funkcionalita, avšak na úkor horšího provádění změn. Aplikace se typicky ke klientovi dostane až ve fázi testování, kdy již může být provádění určitých změn komplikovanější než v rané fázi vývoje. Největší úskalí zde proto spočívá v tom, že klient nemusí předem znát všechny své požadavky, nebo si nedostatky v zadání uvědomí až po zhlédnutí finální verze.

jak funguje vodopádový model programování

Vývojáři se současně nemohou vracet k předešlé fázi vývoje, takže pokud nedostatky odhalí až později, musí k nápravě dojít až po dokončení cyklu. Tedy po vydání finální verze. Programátoři jsou navíc pod neustálým dohledem a tlakem předem definovaného času na vývoj. Je zde tedy vyžadována mnohem větší disciplína.

Na druhou stranu se však jedná o princip zajišťující stabilní a kvalitní produkty, které jsou výsledkem předem připravené, pečlivé analýzy požadavků. Striktní pravidla kolem dokumentace navíc řeší případný odchod některého z programátorů, jenž může v případě agilního vývoje, kde na dokumentaci není kladen takový důraz, znamenat spoustu promrhaného času stráveného luštěním kódu.

Obecně je proto možné souboj agilní vývoj versus vodopádový model shrnout tak, že je agile vhodnější zejména pro větší projekty, zatímco vodopád spíše pro menší, kde není tolik zapotřebí průběžná konzultace. Stejně tak je však vodopád lepší pro klienty, kteří se nechtějí, nebo nemají čas přímo podílet na vývoji.

Agilní vývoj aplikací v praxi

Vývoj aplikace na míru je mimo samotné programování a design spojený také se smlouvou mezi dodavatelem a zákazníkem. Smlouvy se obvykle objevují ve dvou podobách, a to jako rámcová smlouva o poskytování služeb, nebo jako dohoda fixní částky a fixního času. V prvním případě se jedná o definování poskytovaných služeb, nikoli definici produktu. Programátor (vývojářský tým) se tak zavazuje poskytovat zde uvedené služby, jako je design, programování apod.

Samotná podoba aplikace však vychází až z konkrétní domluvy, která je postupně upravována na konci cyklů. Tato forma je tedy ideální pro agilní vývoj. V případě klasického, rigorózního přístupu je ovšem vhodnější druhá zmíněná možnost, která přesně specifikuje podobu díla a pevně stanovuje částku za jeho dodání. Celý proces musí proběhnout v předem stanoveném čase, kdy se zhotovitel zavazuje dodat produkt a objednatel za něj musí zaplatit.

Pokud i vy přemýšlíte o vývoji vlastní aplikace na míru a rozhodujete se, kterou metodiku zvolit, neváhejte využít naší bezplatné konzultace. Můžeme vám pomoci nejen s výběrem, ale i s realizací kompletního projektu. Od prvotního návrhu až po údržbu.
 


Potřebujete poradit?