Ako môže agilný IT transformovať IT priemysel?

Obsah

• Prečo agilný IT?
• Ako rieši agilná metodika problémy modelu vodopádu?
• Ako Agile ovplyvnil IT priemysel?
• Žiadne chyby, žiadny stres - Váš sprievodca krok za krokom k vytvoreniu softvéru na zmenu života bez zničenia vášho života
• Dôvody BT sa presunuli na agilné praktiky
• Nedostatočné riadenie požiadaviek
  
• Zlý softvérový dizajn
• Obmedzenia rozvoja
• Čo urobila spoločnosť BT pri riešení vyššie uvedených problémov?
• záver

Zdroj: Darkovujic / Dreamstime.com

Zobrať:

Pre mnohých je vodopádový model vývoja softvéru už desaťročia štandardom, ktorý však teraz nahrádza oveľa flexibilnejšia agilná metodika.

Agilná metodika pre vývoj softvéru môže mať pozitívny vplyv na IT priemysel. Výsledky prijatia agilnej metodológie sa dajú merať rôznymi spôsobmi. Rýchlejší obrat požiadaviek na zmenu softvéru, menej chýb, kvantitatívne meranie výkonnosti tímu a úzke miesta sú odrazom úspešnej implementácie Agile. Na úspešné zmeranie dopadu agility musí organizácia porovnať rôzne metriky súvisiace s vývojom pred agilitou a po agile. Skutočný dosah Agile sa nedá merať iba zvýšením príjmu alebo zvýšeným počtom opravených chýb. Na pochopenie skutočného dopadu je potrebné zvážiť niekoľko vnútorných parametrov. (Viac informácií o agilnom vývoji nájdete v časti Agilný vývoj softvéru 101.)

Prečo agilný IT?

Odvetvie IT sa prikláňalo k agilným praktikám hlavne kvôli obmedzeniam modelu vodopádu vývoja softvéru. Vo všeobecnosti sa zistilo, že IT spoločnosti nie sú schopné reagovať na meniace sa požiadavky zákazníkov alebo situácie na trhu alebo znižovať náklady pomocou vodopádového modelu vývoja softvéru. Aj keď vyvážime tento ohromujúci sklon k agilnej metodológii a niektoré z nadšení považujeme len za humbuk, existuje veľká empirická spätná väzba proti vodopádovému modelu.

Jednoducho povedané, model vodopádu je model vývoja softvéru, v ktorom sa práca vykonáva postupne - jednu fázu za druhou. Tento model má päť fáz: požiadavky, návrh, implementácia, overenie a údržba. Po dokončení jednej fázy je zvyčajne ťažké, ak nie nemožné, vykonať zmeny v skoršej fáze. Predpokladá sa teda, že požiadavky sú do značnej miery stanovené. Hlavný rozdiel oproti modelu Agile spočíva v predpoklade, že sa nezmenia požiadavky. Agile predpokladá, že obchodné situácie sa zmenia, rovnako ako požiadavky. Softvér sa dodáva v menších množstvách ako ss, zatiaľ čo v modeli vodopádu sa prvé dodanie alebo uvoľnenie uskutoční po dlhej dobe. (Viac informácií o vývoji nájdete v časti Ako Apache Spark pomáha rýchlemu vývoju aplikácií.)

Najvýznamnejšou kritikou proti vodopádovému modelu je jeho predpoklad, že sa nezmenia požiadavky. Samotný predpoklad je chybný a nereálny. Napríklad v roku 2001 štúdia o 1 027 IT projektoch v Spojenom kráľovstve ukázala, že tento predpoklad bol jediným najväčším dôvodom zlyhania IT projektov.

V ďalšom príklade Craig Larman, autor knihy „Agile and Iterative Development: A Manager's Guide“, poukázal na to, ako sa mnohým projektom realizovaným ministerstvom obrany (DoD) pomocou modelu vodopádu v USA nepodarilo dosiahnuť svoje ciele. Počas 80. a 90. rokov sa od DoD vyžadovalo, aby používal vodopádový model pre svoje projekty vývoja softvéru podľa štandardov uverejnených v DoD STD 2167. Šokujúce štatistiky odhalili, že 75% týchto softvérových projektov sa nikdy nepoužilo. Po tejto správe bola vytvorená pracovná skupina pod vedením Dr. Fredericka Brooksa, známeho odborníka na softvérové ​​inžinierstvo. Pracovná skupina vyšla so správou, v ktorej sa uvádza, že „DoD STD 2167 musí tiež radikálne prepracovať, aby odrážal najlepšie osvedčené postupy. Evolučný vývoj je technicky najlepší, šetrí čas a peniaze. “

Nasledujúce štyri predpoklady modelu vodopádu zlyhali v skutočných scenároch:

• Uvedené požiadavky sú primerane dobre definované, a preto sa významne nezmenia.
• Aj keď sa požiadavky menia počas vývojovej fázy, budú dosť malé na to, aby sa dali prispôsobiť vývojovému cyklu.
• Systémová integrácia, ktorá nastane po dodaní softvéru, pôjde podľa plánu.
• Inovácia softvéru a úsilie potrebné na inováciu pôjdu podľa plánovaného a predvídateľného harmonogramu.

Ako rieši agilná metodika problémy modelu vodopádu?

Agilná metodika sa zásadne líši od modelu vodopádu a vyplýva z jej predpokladov:

• Nikto, dokonca ani zákazník, nemôže úplne poznať alebo porozumieť požiadavkám. Neexistuje žiadna záruka, že požiadavky sa nezmenia.
• Zmeny požiadaviek nemusia byť malé a zvládnuteľné. V skutočnosti prídu v rôznych veľkostiach a budú neustále prichádzať. Softvér bude dodávaný v malých prírastkoch, aby bolo možné sledovať zmeny.

Ako Agile ovplyvnil IT priemysel?

Agile sa prijíma na mnohých miestach, zatiaľ čo mnoho spoločností plánuje prijať Agile. Aj keď Agile definitívne urobila zásadné zmeny v IT priemysle, fakty a čísla je stále ťažké získať. Dopad Agile je možné pochopiť pomocou prípadovej štúdie British Telecom (BT) uvedenej nižšie.

Žiadne chyby, žiadny stres - Váš sprievodca krok za krokom k vytvoreniu softvéru na zmenu života bez zničenia vášho života

Svoje programovacie schopnosti si nemôžete vylepšiť, keď sa nikto nestará o kvalitu softvéru.

Dôvody BT sa presunuli na agilné praktiky

Spoločnosť BT začala mať s praktikami vývoja softvéru skúsenosti už v roku 2004. BT vyvinula množstvo softvérových projektov, jednoduchých aj komplexných. Mnoho softvérových projektov nedokázalo vyvinúť kvalitný výstup v dohodnutom časovom rámci. Spoločnosť BT zistila, že problémy spôsobili korene modelu vodopádu. Posilnenie modelu vodopádu teda nepomôže. Hlavné príčiny problémov sú uvedené nižšie:

Nedostatočné riadenie požiadaviek

• Bolo zadaných príliš veľa požiadaviek na to, aby boli splnené v príliš obmedzenom čase.
• Mnoho požiadaviek nebolo pre obchodné potreby relevantné.
• Takmer všetkým, ak nie všetkým požiadavkám, bol pridelený štatút vysokej priority.
• Požiadavky predstavovali súčasné obchodné potreby bez toho, aby sa sledovali budúce scenáre. Zostáva tak otvorená možnosť budúcich zmien softvéru.

Zlý softvérový dizajn

• Vzhľadom na veľké množstvo požiadaviek návrhári vynaložili príliš veľa času len na to, aby zistili, čo znamenajú. Na skutočný dizajn zostalo málo času.
• Analytici požiadaviek sa presunuli do iných úloh a vzali so sebou nepísané a tiché znalosti.
• Uvedené dva faktory viedli k zlej konštrukcii. Dizajnéri museli dodávať podľa pôvodného časového plánu.

Obmedzenia rozvoja

Kódovanie bolo unáhlené a nekvalitné z dôvodu chybného návrhu softvéru. Vývojári by si uvedomili, že zlý návrh softvéru by mal za následok zlý kód, ale napriek tomu musel dodať dohodnutý časový harmonogram. Počas integrácie bolo hlásených veľa chýb, pretože sa neuskutočnili testy jednotiek a regresné testy.

V čase nasadenia softvéru zákazník poznamenáva, že požiadavky sa už zmenili, a tak má aj obchodný scenár. Tento softvér má tiež veľa problémov. V skutočnosti sa celé úsilie na vývoj softvéru považuje za plytvanie.

Čo urobila spoločnosť BT pri riešení vyššie uvedených problémov?

Spoločnosť BT si uvedomila, že posilnenie modelu vodopádu nebolo riešením problémov. Vyžadovalo to nový prístup. Preto sa rozhodla implementovať agilný prístup. V rámci nového prístupu sa rozhodlo o týchto veciach:

• Namiesto 12-mesačného vývojového cyklu by spoločnosť BT teraz dodávala funkčné časti softvéru v 90-dňovom cykle. Cieľom bolo zamerať sa na jeden alebo dva obchodné problémy a zamerať sa na dodanie softvérového riešenia do 90 dní. Začiatok tohto cyklu sa vyznačoval intenzívnou diskusiou medzi rôznymi zúčastnenými stranami, aby sa požiadavky jasne identifikovali, analyzovali a stanovili priority.
• Cieľom bolo poskytnúť jasné a konkrétne obchodné hodnoty. Interný zákazník bol pod tlakom, aby poskytol jasné požiadavky. Namiesto nejasných cieľov boli príbehy používateľov poskytnuté s jasnými kritériami akceptácie.
• Softvér, ktorý by sa dodal, by bol úplne otestovaný a zdokumentovaný. Softvér by predtým absolvoval časté testy integrácie, aby identifikoval problémy.

Vďaka agilnému prístupu by sa spoločnosť BT mohla ľahšie prispôsobiť meniacim sa požiadavkám alebo podnikateľským situáciám. Zlepšila sa kvalita kódu a riešili sa základné chyby na poslednú chvíľu.

záver

Agilný, pre všetky jeho výhody a humbuk okolo neho, je stále v štádiu, keď jeho potenciál nie je úplne využitý. Je to tak preto, že mnoho organizácií prispôsobuje prístup rozsahu úpravy svojich pôvodných zásad. Výsledkom je, že model vodopádu sa v niektorých prípadoch vracia. Aj keď bude prispôsobovanie pokračovať, je dôležité zachovať základné princípy Agiles. Mnoho organizácií tvrdí, že sú úplne agilné, ale stále majú nejaký spôsob, ako sa stať skutočne agilnou spoločnosťou.