Kako Agile IT može transformirati IT industriju?

Sadržaj

• Zašto Agile IT?
• Kako agilna metodologija rješava probleme modela vodopada?
• Kako je Agile utjecao na IT industriju?
• Bez grešaka, bez stresa - Vaš korak po korak vodič za stvaranje softvera koji mijenja život bez uništavanja života
• Razlozi BT prebačeni su na okretne prakse
• Loše upravljanje zahtjevima
  
• Loš softverski dizajn
• Ograničenja razvoja
• Što je BT učinio da riješi gore navedene probleme?
• Zaključak

Izvor: Darkovujić / Dreamstime.com

Oduzeti:

Za mnoge je model vodopada u razvoju softvera već desetljećima standard, ali to je sada zamijenjeno mnogo fleksibilnijom Agile metodologijom.

Agilna metodologija za razvoj softvera može pozitivno utjecati na IT industriju. Rezultati usvajanja Agile metodologije mogu se mjeriti na više načina. Brži zaokret u zahtjevima za promjenom softvera, manje grešaka, kvantitativno mjerenje performansi tima i uska grla sve su odraz uspješne implementacije Agile-a. Da bi uspješno izmjerio utjecaj Agile-a, organizacija mora usporediti različite metrike povezane s prije-agilnim i post-agilnim razvojem. Stvarni utjecaj Agile-a ne može se mjeriti samo povećanjem prihoda ili povećanim brojem ispravljenih pogrešaka. Nekoliko unutarnjih parametara treba uzeti u obzir da bi se shvatio stvarni utjecaj. (Više o Agile razvoju potražite u odjeljku Agile Software Development 101.)

Zašto Agile IT?

IT industrija bila je naklonjena agilnoj praksi, uglavnom zbog ograničenja modela slapa u razvoju softvera. Općenito, primijećeno je da IT kompanije nisu u stanju odgovoriti na promjenjive zahtjeve kupaca ili tržišne situacije ili smanjiti troškove pomoću vodopadnog modela razvoja softvera. Čak i ako uravnotežimo taj nagibni nagib prema Agile metodologiji i smatramo da je neko od uzbuđenja samo hirovitim, postoji mnogo empirijskih povratnih informacija protiv modela vodopada.

Jednostavno rečeno, model vodopada model je razvoja softvera u kojem se rad izvodi na uzastopni način - jedna faza za drugom. Postoji pet faza ovog modela: zahtjevi, dizajn, primjena, provjera i održavanje. Obično je nakon završene jedne faze teško, ako ne i nemoguće, napraviti promjene u ranijoj fazi. Dakle, pretpostavka je da su zahtjevi prilično fiksni. Glavna razlika s Agile modelom je u pretpostavci da neće biti promjena zahtjeva. Agile pretpostavlja da će se poslovne situacije promijeniti, a isto tako i zahtjevi. Dakle, softver se isporučuje u manjim dijelovima preko ss, dok je kod modela vodopada prva isporuka ili puštanje napravljeno nakon dužeg vremena. (Za više informacija o razvoju, pogledajte kako Apache Spark pomaže brzom razvoju aplikacija.)

Najistaknutija kritika protiv modela vodopada bila je njegova pretpostavka da neće biti promjena u zahtjevima. Sama pretpostavka je pogrešna i nerealna. Na primjer, 2001. godine, studija o 1.027 IT projekata u Velikoj Britaniji pokazala je da je ta pretpostavka jedini najveći razlog neuspjeha IT projekata.

U drugom primjeru, Craig Larman, autor knjige "Agilni i iterativni razvoj: Vodič za menadžera", ukazao je na to kako brojni projekti koje je Ministarstvo obrane (DoD) izvršilo koristeći model vodopada u SAD-u nisu uspjeli postižu svoje ciljeve. Tijekom osamdesetih i devedesetih godina prošlog stoljeća DoD je zahtijevao da koristi model vodopada za svoje projekte razvoja softvera prema standardima objavljenim u DoD STD 2167. Šokantna statistika otkrila je da 75% ovih softverskih projekata nikada nije korišteno. Nakon ovog izvješća pokrenuta je radna skupina pod dr. Frederickom Brooksom, poznatim stručnjakom za softverski inženjering. Radna skupina izašla je s izvješćem koje je komentiralo da “DoD STD 2167 također treba radikalan pregled kako bi odražavao modernu najbolju praksu. Evolucijski razvoj je tehnički najbolji, štedi vrijeme i novac. "

Sljedeće četiri pretpostavke modela vodopada nisu uspjele u stvarnim scenarijima:

• Navedeni zahtjevi su razumno definirani i tako se neće bitno promijeniti.
• Čak i ako se zahtjevi promijene tijekom razvojne faze, oni će biti dovoljno mali da se mogu smjestiti u razvojni ciklus.
• Integracija sustava, koja će se dogoditi nakon isporuke softvera, ići će prema planu.
• Inovacija softvera i napor potrebni za inoviranje ići će prema planiranom i predvidljivom rasporedu.

Kako agilna metodologija rješava probleme modela vodopada?

Agile metodologija bitno se razlikuje od modela vodopada i to je jasno iz njegovih pretpostavki:

• Nitko, pa ni kupac, ne može u potpunosti znati ili razumjeti zahtjeve. Ne postoji jamstvo da se zahtjevi neće promijeniti.
• Promjene zahtjeva možda nisu male i upravljive. Zapravo, oni će dolaziti u različitim veličinama i nastavit će dolaziti. Dakle, softver će se isporučivati ​​u malim koracima za praćenje promjena.

Kako je Agile utjecao na IT industriju?

Agile se usvaja na puno mjesta, dok puno tvrtki planira usvojiti Agile. Iako je Agile definitivno donio temeljne promjene u IT industriji, činjenice i brojke još su malo teško dobiti. Učinak Agile-a može se shvatiti niže navedenom studijom slučaja British Telecom (BT).

Bez grešaka, bez stresa - Vaš korak po korak vodič za stvaranje softvera koji mijenja život bez uništavanja života

Ne možete poboljšati svoje programiranje kad nikoga nije briga za kvalitetu softvera.

Razlozi BT prebačeni su na okretne prakse

BT je počeo imati problema s praksama razvoja softvera još 2004. godine. BT je razvio brojne softverske projekte, i jednostavne i složene. Mnogi softverski projekti nisu uspjeli razviti kvalitetne rezultate unutar dogovorenog vremenskog okvira. BT je otkrio da problemi duguju svoje korijene modelu vodopada. Dakle, jačanje modela vodopada nije trebalo pomoći. U nastavku su navedeni glavni uzroci problema:

Loše upravljanje zahtjevima

• Previše je zahtjeva za ispunjavanje u previše ograničenom vremenu.
• Mnogi su zahtjevi bili nevažni za poslovne potrebe.
• Gotovo svi, ako nisu svi zahtjevi dodijeljeni su statusu visokog prioriteta.
• Zahtjevi su predstavljali trenutne poslovne potrebe bez obazivanja na buduće scenarije. To je ostavilo mogućnost za buduće promjene softvera.

Loš softverski dizajn

• S obzirom na ogroman broj zahtjeva, dizajneri su potrošili previše vremena samo pokušavajući shvatiti što zahtjevi znače. Malo je vremena ostalo za stvarni dizajn.
• Analitičari zahtjeva prešli su na druge zadatke, uzimajući sa sobom nepisano, prešutno znanje.
• Gornja dva čimbenika rezultirala su lošim dizajnom. Dizajneri su se ipak morali isporučiti u skladu s izvornom vremenskom trakom.

Ograničenja razvoja

Kodiranje je bilo užurbano i loše kvalitete zbog pogrešnog dizajna softvera. Programeri bi shvatili da će loš softverski softver rezultirati lošim kodom, ali ipak se mora isporučiti u dogovorenom roku. Za vrijeme integracije bilo bi prijavljeno puno bugova jer se nisu provodili jedinični testovi i regresijski testovi.

Do trenutka uvođenja softvera, kupac primjećuje da su se zahtjevi već promijenili, pa tako i poslovni scenarij. Softver također ima puno problema. Učinkovito, čitav napor na razvoju softvera smatra se gubitkom.

Što je BT učinio da riješi gore navedene probleme?

BT je shvatio da ojačavanje modela vodopada nije odgovor na probleme. Trebao je novi pristup. Dakle, odlučila je provesti agilni pristup. Prema novom pristupu, odlučuju se sljedeće stvari:

• Umjesto 12-mjesečnog razvojnog ciklusa, BT bi sada isporučio djelotvorne dijelove softvera u 90-dnevnom ciklusu. Ideja je bila usredotočiti se na jedan ili dva poslovna problema, a cilj je isporučiti softversko rješenje u roku od 90 dana. Početak ovog ciklusa obilježen je intenzivnom raspravom između različitih dionika kako bi zahtjevi bili jasno identificirani, analizirani i prioritetni.
• Cilj je bio pružiti jasne, opipljive poslovne vrijednosti. Unutarnji kupac bio je pod pritiskom da postavi jasne zahtjeve. Umjesto nejasnih ciljeva, korisničke su priče dane s jasnim kriterijima prihvaćanja.
• Softver koji bi se isporučio bio bi u potpunosti testiran i dokumentiran. Softver će proći česte integracijske testove da bi prethodno uočio probleme.

Uz Agile pristup, BT bi se mogao lakše prilagoditi promjenjivim zahtjevima ili poslovnim situacijama. Kvaliteta koda se poboljšala i riješene su osnovne pogreške u posljednjoj minuti.

Zaključak

Agilna, za sve svoje prednosti i hipe oko nje, još uvijek je u fazi u kojoj njezin potencijal nije u potpunosti ostvaren. To je zbog toga što mnoge organizacije prilagođavaju pristup u mjeri u kojoj mijenjaju svoje izvorne principe. Kao rezultat toga, model vodopada u nekim se slučajevima vraća. Iako će se prilagodba nastaviti, važno je zadržati Agilesove osnovne principe. Mnogo organizacija tvrdi da su u potpunosti agilne, ali im preostaje neki put da postanu uistinu agilna tvrtka.