Jak může agilní IT transformovat IT průmysl?

Obsah

• Proč agilní IT?
• Jak agilní metodologie řeší problémy vodopádového modelu?
• Jak Agile ovlivnil IT průmysl?
• Žádné chyby, žádný stres - Váš průvodce krok za krokem k vytváření softwaru pro změnu života, aniž by došlo ke zničení vašeho života
• Důvody BT přešly na agilní praktiky
• Špatné řízení požadavků
  
• Špatný návrh softwaru
• Omezení rozvoje
• Co udělala BT k řešení výše uvedených problémů?
• Závěr

Zdroj: Darkovujic / Dreamstime.com

Odnést:

Pro mnohé byl model vodopádu vývoje softwaru standardem po celá desetiletí, ale nyní je nahrazen mnohem flexibilnější metodikou Agile.

Agilní metodologie pro vývoj softwaru může pozitivně ovlivnit IT průmysl. Výsledky přijetí agilní metodiky lze měřit několika způsoby. Rychlejší obrat v požadavcích na změnu softwaru, méně chyb, kvantitativní měření výkonu týmu a úzká místa jsou odrazem úspěšné implementace Agile. Aby bylo možné úspěšně měřit dopad agility, musí organizace porovnat různé metriky související s vývojem před agilním a post-agilním vývojem. Skutečný dopad Agile nelze měřit pouze zvýšením příjmů nebo zvýšením počtu opravených chyb. K pochopení skutečného dopadu je třeba zvážit několik interních parametrů. (Více o agilním vývoji viz Agile Software Development 101.)

Proč agilní IT?

IT průmysl se přikláněl k agilním postupům hlavně kvůli omezením vodopádového modelu vývoje softwaru. Obecně bylo zjištěno, že IT společnosti nejsou schopny reagovat na měnící se požadavky zákazníků nebo situace na trhu nebo snižovat náklady pomocí vodopádového modelu vývoje softwaru. I když vyvažujeme tento ohromný sklon k agilní metodologii a považujeme některé vzrušení za jen humbuk, existuje spousta empirické zpětné vazby proti vodopádovému modelu.

Jednoduše řečeno, model vodopádu je model vývoje softwaru, kde se práce provádí postupně - jednu fázi za druhou. Tento model má pět fází: požadavky, návrh, implementace, ověření a údržba. Obvykle po dokončení jedné fáze je obtížné, ne-li nemožné, provést změny v dřívější fázi. Předpokládáme tedy, že požadavky jsou do značné míry pevné. Hlavní rozdíl oproti modelu Agile spočívá v předpokladu, že nedojde ke změně požadavků. Agile předpokládá, že se změní obchodní situace, stejně jako požadavky. Software je tedy dodáván v menších kusech než ss, zatímco u modelu vodopádu je první dodání nebo uvolnění provedeno po dlouhé době. (Další informace o vývoji naleznete v tématu Jak Apache Spark pomáhá rychlému vývoji aplikací.)

Nejvýznamnější kritikou proti vodopádovému modelu je jeho předpoklad, že nedojde ke změně požadavků. Samotný předpoklad je chybný a nerealistický. Například v roce 2001 studie o 1 027 IT projektech ve Velké Británii ukázala, že tento předpoklad byl jediným největším důvodem neúspěchu IT projektů.

V dalším příkladu Craig Larman, autor knihy „Agilní a opakující se vývoj: Manažerská příručka“, poukázal na to, jak mnoho projektů provedených ministerstvem obrany (DoD) pomocí modelu vodopádu v USA selhalo. dosáhnout svých cílů. V průběhu osmdesátých a devadesátých let muselo DoD používat model vodopádu pro své projekty vývoje softwaru podle standardů zveřejněných v DoD STD 2167. Šokující statistiky odhalily, že 75% těchto softwarových projektů nebylo nikdy použito. Po této zprávě byla zahájena pracovní skupina pod Dr. Frederickem Brooksem, známým odborníkem na softwarové inženýrství. Pracovní skupina vyšla se zprávou, která komentovala „DoD STD 2167 rovněž potřebuje radikální přepracování, aby odrážel moderní osvědčené postupy. Evoluční vývoj je technicky nejlepší, šetří čas a peníze. “

Následující čtyři předpoklady modelu vodopádu selhaly ve scénářích skutečného světa:

• Uvedené požadavky jsou přiměřeně dobře definovány, a proto se významně nezmění.
• I když se požadavky během vývojové fáze změní, budou dostatečně malé, aby se přizpůsobily vývojovému cyklu.
• Systémová integrace, ke které dojde po dodání softwaru, bude probíhat podle plánu.
• Inovace softwaru a úsilí potřebné k inovacím budou probíhat podle plánovaného a předvídatelného harmonogramu.

Jak agilní metodologie řeší problémy vodopádového modelu?

Agilní metodologie se zásadně liší od vodopádového modelu a je zřejmá z jeho předpokladů:

• Nikdo, ani zákazník, nemůže plně znát nebo porozumět požadavkům. Neexistuje žádná záruka, že se požadavky nezmění.
• Změny požadavků nemusí být malé a zvládnutelné. Ve skutečnosti přijdou v různých velikostech a budou neustále přicházet. Software bude dodáván v malých krocích, aby bylo možné sledovat změny.

Jak Agile ovlivnil IT průmysl?

Agile je přijímána na mnoha místech, zatímco mnoho společností plánuje přijetí Agile. Přestože Agile rozhodně provedl zásadní změny v IT průmyslu, fakta a čísla je stále trochu obtížné získat. Dopad Agile však lze pochopit pomocí případové studie British Telecom (BT) uvedené níže.

Žádné chyby, žádný stres - Váš průvodce krok za krokem k vytváření softwaru pro změnu života, aniž by došlo ke zničení vašeho života

Nemůžete zlepšit své programovací schopnosti, když se nikdo nestará o kvalitu softwaru.

Důvody BT přešly na agilní praktiky

BT začala zažít řadu problémů s postupy vývoje softwaru již v roce 2004. BT vyvinula řadu softwarových projektů, jednoduchých i komplexních. Mnoho softwarových projektů nebylo schopno vyvinout kvalitní výstup v dohodnutém časovém rámci. BT zjistila, že problémy dluží jejich kořeny vodopádovému modelu. Posílení vodopádového modelu tedy nepomohlo. Hlavní příčiny problémů jsou uvedeny níže:

Špatné řízení požadavků

• Bylo zadáno příliš mnoho požadavků na to, aby byly splněny v příliš omezeném čase.
• Mnoho požadavků nebylo pro obchodní potřeby relevantní.
• Téměř všem, ne-li všem požadavkům, byl přidělen status s vysokou prioritou.
• Požadavky představovaly současné obchodní potřeby bez ohledu na budoucí scénáře. To ponechalo otevřenou možnost budoucích změn softwaru.

Špatný návrh softwaru

• Vzhledem k velkému počtu požadavků strávili designéři příliš mnoho času jen snahou zjistit, co tyto požadavky znamenají. Na skutečný design zůstalo málo času.
• Analytici požadavků se přesunuli do dalších úkolů a vzali si s sebou nepsané, tiché znalosti.
• Výše uvedené dva faktory vedly ke špatnému designu. Designéři museli dodat podle původní časové osy.

Omezení rozvoje

Kódování bylo unáhlené a nekvalitní kvůli chybnému návrhu softwaru. Vývojáři by si uvědomili, že špatný návrh softwaru by vyústil ve špatný kód, ale přesto musel dodat dohodnutou časovou osu. Během integrace bylo hlášeno mnoho chyb, protože nebyly spuštěny testy jednotek a regresní testy.

V době nasazení softwaru si zákazník všimne, že požadavky se již změnily, a tak má i obchodní scénář. Software má také spoustu problémů. Celkově se úsilí o vývoj softwaru považuje za plýtvání.

Co udělala BT k řešení výše uvedených problémů?

BT si uvědomila, že posílení vodopádového modelu nebylo odpovědí na problémy. Vyžadovalo to nový přístup. Proto se rozhodl implementovat Agilní přístup. V rámci nového přístupu byly rozhodnuty tyto věci:

• Namísto 12měsíčního vývojového cyklu by nyní BT dodávala funkční kousky softwaru v 90denním cyklu. Záměrem bylo zaměřit se na jeden nebo dva obchodní problémy a zaměřit se na dodání softwarového řešení do 90 dnů. Začátek tohoto cyklu byl poznamenán intenzivní diskusí mezi různými zúčastněnými stranami, aby byly požadavky jasně identifikovány, analyzovány a stanoveny priority.
• Cílem bylo poskytnout jasné a hmatatelné obchodní hodnoty. Interní zákazník byl pod tlakem, aby poskytl jasné požadavky. Takže místo nejasných cílů byly uživatelské příběhy dány s jasnými kritérii pro přijetí.
• Software, který by byl dodán, by byl plně testován a zdokumentován. Software by prošel častými integračními testy, aby předem identifikoval problémy.

Díky agilnímu přístupu by se BT mohla snáze přizpůsobit měnícím se požadavkům nebo obchodní situaci. Zlepšila se kvalita kódu a řešily se základní chyby na poslední chvíli.

Závěr

Agilní, pro všechny své výhody a humbuk kolem něj, je stále ve fázi, kdy jeho potenciál není plně využit. Je tomu tak proto, že mnoho organizací přizpůsobuje přístup do té míry, že mění své původní zásady. Výsledkem je, že model vodopádu se v některých případech opět vrací. Zatímco přizpůsobení bude pokračovat, je důležité zachovat základní principy Agiles. Mnoho organizací tvrdí, že jsou plně agilní, ale stále mají nějaký způsob, jak se stát skutečně agilní společností.