Kako lahko Agile IT preobrazi IT industrijo?

Vsebina

• Zakaj Agile IT?
• Kako agilna metodologija reši težave modela slapov?
• Kako je Agile vplival na IT industrijo?
• Brez napak, brez stresa - vaš korak za korakom vodnik za ustvarjanje programske opreme, ki spreminja življenje, ne da bi vam uničila življenje
• Razlogi, da je BT prešel na agilne prakse
• Slabo upravljanje zahtev
  
• Slaba zasnova programske opreme
• Omejitve razvoja
• Kaj je BT storil za reševanje zgoraj navedenih težav?
• Zaključek

Vir: Darkovujic / Dreamstime.com

Odvzem:

Za mnoge je model slapanja programske opreme že desetletja standard, vendar ga zdaj nadomešča veliko bolj prilagodljiva metodologija Agile.

Agile metodologija za razvoj programske opreme lahko pozitivno vpliva na IT industrijo. Rezultate sprejetja metodologije Agile je mogoče meriti na več načinov. Hitrejša preobrazba zahtev po spremembi programske opreme, manj napak, kvantitativno merjenje uspešnosti ekipe in ozkih grl so odraz uspešnega izvajanja programa Agile. Za uspešno merjenje učinka Agile mora organizacija primerjati različne meritve, povezane s pred-agilnim in post-agilnim razvojem. Resničnega vpliva Agile ni mogoče izmeriti samo s povečanjem prihodkov ali s povečanim številom odpravljenih napak. Za razumevanje dejanskega vpliva je treba upoštevati več notranjih parametrov. (Za več informacij o razvoju Agile glejte Agile Software Development 101.)

Zakaj Agile IT?

Industrija IT se nagiba k Agile praksam predvsem zaradi omejitev modela slapov pri razvoju programske opreme. Na splošno je bilo opaziti, da se IT podjetja ne morejo odzvati na spreminjajoče se zahteve strank ali tržne razmere ali zmanjšati stroškov z vodnim modelom razvoja programske opreme. Tudi če uravnovešamo ta močan nagib k Agile metodologiji in štejemo, da je nekaj razburjenja zgolj hype, obstaja veliko empiričnih povratnih informacij proti modelu slapov.

Preprosto povedano, model slapov je model razvoja programske opreme, kjer delo poteka zaporedno - eno fazo za drugo. Obstaja pet faz tega modela: zahteve, načrtovanje, izvedba, preverjanje in vzdrževanje. Običajno je po končani eni fazi težko, če ne celo nemogoče, spremeniti prejšnjo fazo. Torej, predpostavka je, da so zahteve precej fiksne. Glavna razlika pri modelu Agile je v predpostavki, da zahtev ne bo sprememb. Agile predvideva, da se bodo poslovne situacije spremenile in tako tudi zahteve. Tako se programska oprema dobavi v manjših kosih prek ss, medtem ko je pri modelu slapov prva dobava ali izdaja izvedena po dolgem času. (Če želite več o razvoju, glejte, kako Apache Spark pomaga hitremu razvoju aplikacij.)

Najbolj opazna kritika proti modelu slapov je bila njegova domneva, da sprememb ne bo sprememb. Sama predpostavka je napačna in nerealna. Na primer, leta 2001 je študija o 1.027 IT projektih v Veliki Britaniji pokazala, da je ta domneva največji razlog za neuspeh projektov IT.

V drugem primeru je Craig Larman, avtor knjige "Agile and Iterative Development: A Manager's Guide", opozoril na to, kako številni projekti, ki jih je izvedlo Ministrstvo za obrambo (DoD) z modelom slapov v ZDA, niso uspeli dosegajo svoje cilje. V vseh osemdesetih in devetdesetih letih prejšnjega stoletja je moral ministrstvo uporabljati model slapov za svoje projekte razvoja programske opreme v skladu s standardi, objavljenimi v dokumentu DoD STD 2167. Šokantna statistika je pokazala, da 75% teh programov nikoli ni bilo uporabljenih. Po tem poročilu je bila ustanovljena delovna skupina pod dr. Frederickom Brooksom, znanim strokovnjakom za programsko inženirstvo. Delovna skupina se je pojavila s poročilom, ki je komentiralo, da "DoD STD 2167 prav tako potrebuje temeljit pregled, da bi odražal moderno najboljšo prakso. Evolucijski razvoj je tehnično najboljši, prihrani čas in denar. "

Naslednje štiri predpostavke modela slapov v dejanskih scenarijih niso uspele:

• Navedene zahteve so dokaj dobro opredeljene in zato se ne bodo bistveno spremenile.
• Tudi če se zahteve spremenijo med razvojno fazo, bodo dovolj majhne, ​​da jih bomo lahko prilagodili znotraj razvojnega cikla.
• Sistemska integracija, ki se zgodi po dobavi programske opreme, bo potekala po načrtu.
• Inovacije programske opreme in prizadevanja za inovacije bodo potekala po načrtovanem in predvidljivem razporedu.

Kako agilna metodologija reši težave modela slapov?

Metodologija Agile se bistveno razlikuje od modela slapov in to jasno izhaja iz njegovih predpostavk:

• Nihče, niti stranka ne more popolnoma vedeti ali razumeti zahtev. Ni zagotovila, da se zahteve ne bodo spremenile.
• Spremembe zahteve morda niso majhne in obvladljive. Pravzaprav bodo prišli v različnih velikostih in bodo še naprej prihajali. Tako bo programska oprema dobavljena v majhnih korakih za spremljanje sprememb.

Kako je Agile vplival na IT industrijo?

Agile sprejemajo na veliko mestih, veliko podjetij pa načrtuje, da bi sprejeli Agile. Čeprav je Agile vsekakor spremenil temeljite spremembe v IT industriji, je dejstev in številk še vedno težko pridobiti. Vpliv Agile je mogoče razumeti s spodnjo študijo primera British Telecoma (BT).

Brez napak, brez stresa - vaš korak za korakom vodnik za ustvarjanje programske opreme, ki spreminja življenje, ne da bi vam uničila življenje

Ne morete izboljšati svojih programskih veščin, kadar nikogar ne skrbi za kakovost programske opreme.

Razlogi, da je BT prešel na agilne prakse

BT je začel s težavami pri razvoju programske opreme začeti leta 2004. BT je razvil številne programske projekte, tako preproste kot zapletene. Številni programski projekti niso mogli razviti kakovostne proizvodnje v dogovorjenem časovnem okviru. BT je ugotovil, da težave dolgujejo svoje korenine modelu slapov. Tako okrepitev modela slapov ne bo pomagala. Spodaj so navedeni glavni vzroki težav:

Slabo upravljanje zahtev

• V preveč omejenem roku je bilo izpolnjenih preveč zahtev.
• Številne zahteve niso bile pomembne za poslovne potrebe.
• Skoraj vse, če ne vsem zahtevam, so bile dodeljene visoko prednostne.
• Zahteve so predstavljale trenutne poslovne potrebe in niso bile pozorne na prihodnje scenarije. To je odprlo možnost prihodnjih sprememb programske opreme.

Slaba zasnova programske opreme

• Glede na ogromno število zahtev so oblikovalci porabili preveč časa, samo da bi poskušali ugotoviti, kaj zahteve pomenijo. Malo časa je ostalo za dejansko oblikovanje.
• Analitiki o zahtevi so se pomerili z drugimi nalogami in s seboj vzeli nenapisano, tiho znanje.
• Zgornja dva dejavnika sta povzročila slabo zasnovo. Oblikovalci so morali še vedno dostaviti v skladu s prvotno časovnico.

Omejitve razvoja

Kodiranje je bilo prenagljeno in slabe kakovosti zaradi pomanjkljive programske zasnove. Razvijalci se zavedajo, da bo zaradi slabe zasnove programske opreme prišlo do slabe kode, vendar so jo kljub temu morali izpolniti v dogovorjenem časovnem roku. Med integracijo bi poročali o številnih napakah, ker enotni testi in regresijski testi niso bili izvedeni.

Po uvedbi programske opreme kupec opazi, da so se zahteve že spremenile in tudi poslovni scenarij. Programska oprema ima tudi veliko težav. Učinkovit je celoten napor za razvoj programske opreme zdaj štet za izgubo.

Kaj je BT storil za reševanje zgoraj navedenih težav?

BT je spoznal, da okrepitev modela slapov ni rešitev za težave. Potreben je bil nov pristop. Torej, se je odločila, da bo uporabila prisilni pristop. Po novem pristopu so se odločile naslednje stvari:

• Namesto 12-mesečnega razvojnega cikla bi BT zdaj v 90-dnevnem ciklu dobavil uporabne dele programske opreme. Ideja je bila, da bi se osredotočili na eno ali dve poslovni težavi in ​​zastavili programsko rešitev v roku 90 dni. Začetek tega cikla je zaznamovala intenzivna razprava med različnimi deležniki, tako da so bile zahteve jasno opredeljene, analizirane in prednostno opredeljene.
• Cilj je bil doseči jasne, oprijemljive poslovne vrednosti. Notranji kupec je bil pod pritiskom, da bi zagotovil jasne zahteve. Namesto nejasnih ciljev so bile uporabniške zgodbe podane z jasnimi merili sprejemanja.
• Programska oprema, ki bi bila dostavljena, bi bila v celoti preizkušena in dokumentirana. Programska oprema bo skozi predhodne preizkuse integracije, da bi predhodno prepoznala težave.

S pristopom Agile se lahko BT lažje prilagodi spreminjajočim se zahtevam ali poslovnim situacijam. Kakovost kode se je izboljšala in odpravili so se osnovne napake v zadnjem trenutku.

Zaključek

Agile je za vse svoje prednosti in hrup okrog sebe še vedno v fazi, ko njegov potencial ni v celoti realiziran. To je zato, ker veliko organizacij prilagaja pristop do obsega spreminjanja njegovih izvirnih načel. Zaradi tega se model slapov ponekod vrača. Čeprav se bo prilagajanje nadaljevalo, je pomembno ohraniti osnovna načela Agilesa. Številne organizacije trdijo, da so popolnoma agilne, vendar jim je treba še kako pomagati, da postanejo resnično agilno podjetje.