Klávesové zkratky na tomto webu - základní
Přeskočit hlavičku portálu

Rychleji, lépe, levněji. Přísliby agilních metodik vývoje software

Komerční sdělení   0:01aktualizováno  0:01
Znáte hlavní přísliby agilních metodik vývoje software posledních let? Rychleji, lépe a levněji. Shrňme si základní rozdíly mezi klasickým „vodopádovým“ způsobem vývoje projektů a agilním přístupem s konkrétními dopady na projekt a zákazníka.

Komerční sdělení

Toto jsou komerční sdělení. iDNES.cz neovlivňuje jejich obsah a není jejich autorem. Více

Komerční sdělení je speciální inzertní formát. Umožňuje inzerentům oslovit čtenáře na ploše větší, než je klasický banner, hodí se tedy například ve chvíli, kdy je potřeba popsat vlastnosti nového produktu, představit společnost nebo ukázat více fotografií.

Aby bylo na první pohled odlišitelné od redakčních textů, obsahuje jasné označení „Komerční sdělení“ v záhlaví článku.

Pro komerční sdělení platí podobná pravidla jako pro další formy inzerce na iDNES.cz. Nesmí tedy být v rozporu s dobrými mravy a zásadami poctivého obchodního styku, nesmí porušovat práva třetích osob a poškozovat něčí dobrou pověst. Na rozdíl od bannerové reklamy je z komerčních sdělení vyloučena politická inzerce.

Komerční sdělení, jejich titulky a tvrzení v nich obsažená nesmějí být lživá a klamavá.

Ceník komerčních sdělení včetně kontaktů na obchodní oddělení najdete zde.

Rychleji, lépe, levněji. Přísliby agilních metodik vývoje software. | foto: Neit Consulting s.r.o.

Pro pochopení rozdílů a výhod agilního přístupu k vývoji software bude vhodné tento přístup srovnat s tradičně používanou metodikou prediktivně a sekvenčně zaměřeného vývoje software tzv. vodopádový způsob. Typické pro tuto metodiku je, že je dodána předem dohodnutá funkcionalita v určitých předem určených časových inkrementech (např. v řádu několika měsíců, čtvrtletně, pololetně, atp.). V tomto případě je projekt implementován jako jedna velká dodávka nových funkcionalit podle předem dohodnutého detailního harmonogramu.

Harmonogram většinou obsahuje velké etapy projektu např. analýza, design, vývoj, testování, které trvají řádově měsíce a pokrývají v dané fázi bezezbytku vše, co má být v rámci projektu realizováno, např. v rámci fáze analýza analýzu všech funkcionalit projektu.

Dokud není dokončena většina analytických prací, není možné začít s fází designu a vývoje. Rozsah projektu na úrovni uživatelských požadavků je jasně definován již na začátku projektu v úvodní fázi projektu v časově jasně ohraničené fázi analýzy.

Při tomto nastavení změny typu nový požadavek nebo jeho změna nejsou možné a projekt řízený vodopádovým způsobem tak není příliš citlivý na změnu uživatelských požadavků. Dokumentace projektu je vytvářena na velmi detailní a formální bázi a je schvalována po každé fázi.

Při realizaci projektů vodopádovým způsobem jsme jako implementační specialisté na BI/DWH projekty narazili na následující problémy:

  • Neúměrně dlouhé cykly vývoje nových funkcionalit – mezi zadáním požadavku uživatelem a okamžikem, kdy tato funkcionalita je dostupná uživateli uplynou měsíce.
  • Naddimenzované rozpočty – robustnost projektové metodiky, nutnost odhadnout celou funkcionalitu na začátku projektu a nutnost vytvářet velmi detailní a formální dokumentaci často vede k nafukování rozpočtů.
  • Nižší míra spokojenosti s realizací požadavků – požadavky uživatelů se v průběhu projektu (několik měsíců) změnily např. vlivem změn na trhu, legislativy nebo zákaznického portfolia.
  • Nedostatečná spolupráce IT vs. business uživatelé – např. nutnost generovat extrakty ze zdrojových systémů ručně, neúměrně dlouhé cykly nasazování změn a nových funkcionalit nebo závislost na změnách ve zdrojových systémech.
  • Kumulace řešení chyb/nejasností do testovací fáze na závěr projektu – většina chyb zadání a nepochopení z analytické fáze projektu je řešena až v rámci testování na konci projektu. Je tak vytvářen neúměrný tlak jednak na uživatele, aby otestovali všechny nové funkcionality v rámci relativně krátkého intervalu a i na dodavatele řešení, aby zjištěné chyby opravil.

Výše zmíněné nedostatky vodopádového způsobu řízení projektů se nám podařilo vyřešit pomocí použití agilní metodiky řízení našich projektů. V případě agilní metodiky se jedná spíše o kontinuální proces a nikoliv jednorázovou implementace.

To v praxi znamená, že je celá metodika založena na iterativním principu, kdy jsou nové funkcionality dodávány dříve než tradičním procesem realizace pomocí vodopádového řízení projektu, kdy se na konci projektu dodá finální produkt. Fáze sběru požadavků (analýza), design (extrakty, datový model, logické mapování) se překrývají s vývojem a testováním, což vede k redukci vývojových cyklů pro rychlejší dodání uživateli.

Agilním metodika se nezaměřuje na vyřešení všech BI požadavků najednou, ale spíše na průběžné poskytování ucelených částí nových funkcionalit v krátkých vývojových cyklech, které obsahují vše od analýzy po testování včetně minimální nutné dokumentace. Zároveň je tato metodika připravena na rychlou adaptaci na změny business požadavků, protože je možné zařazovat do implementace nové požadavky a přehodnocovat priority mezi jednotlivými vývojovými cykly.

Z následujícího obrázku je zřejmý rozdíl mezi tradiční vodopádovou metodikou a agilní metodikou a to zejména z hlediska průběžného dodávání nových funkcionalit a přidané uživatelům.

Rychleji, lépe, levněji. Přísliby agilních metodik vývoje software.

Jak ve skutečnosti vypadá běžný den na projektu, kde je uplatněna agilní metodika? Máme k dispozici Project Backlog, což je seznam uživatelských požadavků zapsaný formou user stories z pohledu uživatele se zaměřením na popis požadavku, zdůvodnění požadavku s definicí přidané hodnotu pro uživatele, definicí závislostí, zdrojových dat a akceptačních kritérií. Tyto User Stories jsou seřazeny podle priorit a jedná se o konkrétní požadavky realizovatelné v např. 2-6 týdenním intervalu.

User Story musí být dostatečně detailní, pokud možno nezávislé, aby ho bylo možné samostatně nasadit, odhadnutelné, testovatelné a jeho popis by se měl vejít na malou kartičku. Pro ilustraci uvádím příklad: „Jako šéf nákupčích potřebuji implementovat metodiku pro komplexní hodnocení dodavatelů, které nám umožní dosáhnout zlepšení kvality dodávek, dodržování termínů ze strany dodavatelů a zajistím nám podklady pro argumentaci při jednání s dodavateli.“.

Dalším základních pojmů agilní metodiky je sprint. Jedná se o dvou až šestitýdenní iterace, ve kterých je nová funkcionalita dodávána uživateli.

Rychleji, lépe, levněji. Přísliby agilních metodik vývoje software.

Celý sprint začíná uživatelskou konferencí (Story Conference), kdy se tým dodavatele společně s klíčovými uživateli zákazníka dohodnou na rozsahu konkrétního sprintu formou seznamu User Stories, které vyberou podle již definovaných priorit z Project Backlog a které budou na konci sprintu dodány. Tyto User Stories jsou prodiskutovány do většího detailu a je rámcově odhadnuta jejich pracnost. Následuje plánování (Task Planning), kdy jsou jednotlivé User Stories rozpadnuty na konkrétní úkoly, u kterých je možné stanovit již relativně přesný odhad pracnosti, čímž je ověřeno, že vybrané User Stories je možné v daném sprintu realizovat nebo dojde k revizi. Následuje implementační fáze (Development), ve které si náš tým jednotlivé úkoly sám mezi sebou rozdělí podle svých schopností a preferencí mezi jednotlivé členy týmu a vzhledem k jasně ohraničenému zadání je možné neustále sledovat průběh sprintu a provádět případné korekce, tak aby bylo dosaženo dokončení všech úkolů v co nejkratším čase s přihlédnutím k jejich závislostem.

V rámci vývoje jsou vytvořeny dema potenciálně nasaditelných modulů/prototypů (Potentialy Shippable Modules), které jsou v rámci fáze User Demo předvedeny uživateli a v případě připomínek se proces vývoje a generování prototypu opakuje do té doby, dokud není funkcionalita uživatelem odsouhlasena a není připravena k předání do běžného provozu.

Na konci sprintu musí proběhnout retrospekce (Sprint Retrospection), kdy jsou výsledky sprintu prezentovány zadavatelům požadavku a jsou zmíněny pozitiva i negativa průběhu sprintu tak, aby se dala provést opatření pro jejich eliminaci nebo změny procesů v případě pozitiv, tak aby se v dalších sprintech zvýšila efektivita a kapacita celého týmu.

Pokud bych měl na závěr shrnout hlavní výhody agilní metodiky, se kterými jsme se setkali na námi implementovaných BI/DWH projektech, tak je to zejména dodávka nových funkcionalit v řádů týdnů a nikoliv měsíců, jak tomu je u vodopádového způsobu řízení projektů. Dále je to schopnost reagovat na nové požadavky a změnu požadavků v průběhu projektu, což je umožněno možností přidávat požadavky a měnit jejich priority.

Výsledek implementace bude více dopovídat uživatelských požadavkům, protože je tým při implementaci vždy zaměřen na konkrétní jasně ohraničenou skupinu požadavků řešenou v rámci sprintu s odpovídající součinností uživatele. Zároveň pokud tým při implementaci požadavku selže, pak se to doví při první ukázce prototypu uživateli a nikoliv až na konci projektu při testování jako u vodopádového přístupu k vývoji software.

Je také důležité si uvědomit, že agilní metodiku je vhodné uplatnit v případě, že je možné celé řešení rozdělit na menší samostatně implementovatelné celky a tato metodika také klade zvýšené nároky na součinnost a flexibilitu ze strany uživatele a zadavatele. Pokud se ale setká s odpovídající podporou ze strany zákazníka, přináší velmi brzo po začátku projektu vysokou přidanou hodnotu.

Autor je teamleaderem BI/DWH oddělení ve společnosti Neit Consulting s.r.o. Jako BI/DWH architekt má zkušenosti z několika rozsáhlých projektů datových skladů a reportingových řešení, včetně nadnárodních.

Více informací najdete na www.neit.cz.

Hlavní zprávy

Další z rubriky

Jak vybírat školní potřeby pro prvňáčky?
Jak vybírat školní potřeby pro prvňáčky?

Chystá se váš malý prvňáček poprvé do školy? Pak před vámi jako rodiči stojí důležitý úkol – pořídit mu vše potřebné od pastelek až po aktovku. Jaké školní...  celý článek

Asistenční služby jsou nezbytností. Hlavní roli hraje jejich kvalita.
Asistenční služby jsou nezbytností. Hlavní roli hraje jejich kvalita

Cestování Čechů se v posledních letech mění. Požadavek na bezpečnost v zahraničí vyvíjí tlak na cestovní kanceláře i pojišťovny. Cestovní pojištění napříč...  celý článek

Jedinečný gastronomický zážitek vám nabídne TOP HOTEL Praha.
Jedinečný gastronomický zážitek vám nabídne TOP HOTEL Praha

TOP HOTEL Praha vás okouzlí svými pěti restauracemi, kde můžete ochutnat českou, mezinárodní i indickou kuchyni. Restaurace jsou otevřené pro hotelové hosty i...  celý článek

Najdete na iDNES.cz

mobilní verze
© 1999–2017 MAFRA, a. s., a dodavatelé Profimedia, Reuters, ČTK, AP. Jakékoliv užití obsahu včetně převzetí, šíření či dalšího zpřístupňování článků a fotografií je bez souhlasu MAFRA, a. s., zakázáno. Provozovatelem serveru iDNES.cz je MAFRA, a. s., se sídlem
Karla Engliše 519/11, 150 00 Praha 5, IČ: 45313351, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl B, vložka 1328. Vydavatelství MAFRA, a. s., je členem koncernu AGROFERT.