Hvordan kan Agile IT transformere IT-branchen?

Indhold

• Hvorfor Agile IT?
• Hvordan adresserer agile metodologi problemerne med vandfaldsmodellen?
• Hvordan har Agile påvirket IT-branchen?
• Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
• Årsager BT flyttes til smidig praksis
• Dårlig styring af krav
  
• Dårligt softwaredesign
• Udviklingsbegrænsninger
• Hvad gjorde BT for at løse de ovennævnte problemer?
• Konklusion

Kilde: Darkovujic / Dreamstime.com

Tag væk:

For mange har vandfaldsmodellen inden for softwareudvikling været standarden i årtier, men denne erstattes nu af den meget mere fleksible Agile-metode.

Agile-metodologien til softwareudvikling kan have en positiv indflydelse på IT-branchen. Resultaterne af Agile metodologi-vedtagelse kan måles på en række måder. Hurtigere vending af anmodninger om ændring af software, færre fejl, kvantitativ måling af teamets ydeevne og flaskehalse er alle afspejlinger af en vellykket implementering af Agile. For at kunne måle virkningen af ​​Agile er en organisation nødt til at sammenligne forskellige målinger relateret til udviklingen før agile og post-Agile. Den reelle virkning af Agile kan ikke måles kun ved stigningen i indtægter eller af det øgede antal fejlrettede. Flere interne parametre skal overvejes for at forstå den reelle virkning. (For mere om Agile-udvikling, se Agile Software Development 101.)

Hvorfor Agile IT?

IT-industrien har været tilbøjelig til agile praksis hovedsageligt på grund af begrænsningerne i vandfaldsmodellen for softwareudvikling. Generelt er det blevet observeret, at it-virksomheder ikke er i stand til at reagere på ændrede kundebehov eller markedssituationer eller reducere omkostningerne med vandfaldsmodellen til softwareudvikling. Selv hvis vi opvejer denne overvældende hældning mod Agile-metodologi og betragter noget af spændingen som bare at være hype, er der en masse empiriske feedback mod vandfaldsmodellen.

Kort sagt, vandfaldsmodellen er en softwareudviklingsmodel, hvor arbejdet udføres i rækkefølge - den ene fase efter den anden. Der er fem faser af denne model: krav, design, implementering, verifikation og vedligeholdelse. Normalt, efter at en fase er afsluttet, er det vanskeligt, hvis ikke umuligt, at foretage ændringer til en tidligere fase. Så antagelsen er, at kravene er temmelig faste. Den største forskel med Agile-modellen er under antagelsen af, at der ikke vil være nogen ændring i kravene. Agile antager, at forretningssituationer vil ændre sig, og det vil også kravene. Så software leveres i mindre bidder over ss, mens i vandfaldsmodellen foretages den første levering eller frigivelse efter lang tid. (For mere information om udvikling, se Hvordan Apache Spark hjælper med hurtig applikationsudvikling.)

Den mest bemærkelsesværdige kritik mod vandfaldsmodellen har været dens antagelse om, at der ikke vil være nogen ændring i kravene. Selve antagelsen er mangelfuld og urealistisk. I 2001 viste for eksempel en undersøgelse af 1.027 it-projekter i Storbritannien, at denne antagelse var den største enkeltårsag til fiaskoen i it-projekter.

I et andet eksempel har Craig Larman, forfatteren af ​​bogen "Agile and Iterative Development: A Manager's Guide", peget på, hvordan et antal projekter udført af Department of Defense (DoD) ved hjælp af vandfaldsmodellen i USA ikke har kunnet nå deres mål. Gennem 1980'erne og 1990'erne blev DoD pålagt at bruge vandfaldsmodellen til sine softwareudviklingsprojekter i henhold til standarderne offentliggjort i DoD STD 2167. Stødende statistikker afslørede, at 75% af disse softwareprojekter aldrig blev brugt. Efter denne rapport blev en taskforce lanceret under Dr. Frederick Brooks, en velkendt softwareteknisk ekspert. Taskgruppen kom med en rapport, der kommenterede ”DoD STD 2167 har ligeledes brug for en radikal revision for at afspejle moderne bedste praksis. Evolutionsudvikling er bedst teknisk, det sparer tid og penge. ”

De følgende fire antagelser om vandfaldsmodellen var mislykkedes i virkelige scenarier:

• De givne krav er rimeligt veldefinerede og vil derfor ikke ændre sig væsentligt.
• Selv hvis kravene ændres i udviklingsfasen, vil de være små nok til at imødekomme inden for udviklingscyklussen.
• Systemintegration, der sker efter levering af software, vil gå som pr. Plan.
• Softwareinnovation og den krævede indsats for at innovere vil gå i henhold til en planlagt og forudsigelig tidsplan.

Hvordan adresserer agile metodologi problemerne med vandfaldsmodellen?

Agile-metodikken er grundlæggende forskellig fra vandfaldsmodellen, og det er klart fra dens antagelser:

• Ingen, ikke engang kunden, kan fuldt ud kende eller forstå kravene. Der er ingen garanti for, at kravene ikke ændres.
• Kravændringer er muligvis ikke små og håndterbare. Faktisk vil de komme i forskellige størrelser og vil fortsætte med at komme. Så softwaren leveres i små trin for at holde styr på ændringerne.

Hvordan har Agile påvirket IT-branchen?

Agile adopteres mange steder, mens mange virksomheder planlægger at vedtage Agile. Selvom Agile bestemt har foretaget grundlæggende ændringer i IT-branchen, er kendsgerninger og tal stadig lidt vanskelige at få. Men virkningen af ​​Agile kan forstås med nedenstående case study af British Telecom (BT).

Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv

Du kan ikke forbedre dine programmeringsevner, når ingen er interesseret i softwarekvalitet.

Årsager BT flyttes til smidig praksis

BT begyndte at opleve en række problemer med sin softwareudviklingspraksis tilbage i 2004. BT udviklede en række softwareprojekter, både enkle og komplekse. Mange softwareprojekter kunne ikke udvikle kvalitetsproduktion inden for den aftalte tidsramme. BT fandt, at problemerne skyldes vandfaldsmodellen. Så det var ikke til hjælp at styrke vandfaldsmodellen. De vigtigste årsager til problemerne er angivet nedenfor:

Dårlig styring af krav

• Der blev stillet for mange krav til at være opfyldt inden for for begrænset tid.
• Mange krav var irrelevante for forretningsbehovene.
• Næsten alle, hvis ikke alle krav blev tildelt høj prioritet status.
• Kravene repræsenterede aktuelle forretningsbehov uden øje med de fremtidige scenarier. Det gav en mulighed for fremtidige softwareændringer åbent.

Dårligt softwaredesign

• I betragtning af det enorme antal krav brugte designere for meget tid på bare at prøve at finde ud af, hvad kravene betød. Der var lidt tid tilbage til faktisk design.
• Kravanalytikerne flyttede til andre opgaver og tog med sig uskrevet, stiltiende viden.
• Ovenstående to faktorer resulterede i dårlig design. Designere måtte stadig levere i henhold til den originale tidslinje.

Udviklingsbegrænsninger

Kodningen var forhastet og af dårlig kvalitet på grund af mangelfuld software-design. Udviklere ville indse, at et dårligt softwaredesign ville resultere i dårlig kode, men ikke desto mindre skulle levere efter den aftalte tidslinje. Der blev rapporteret en masse fejl under integrationen, fordi enhedsforsøg og regressionstest ikke blev kørt.

På det tidspunkt, softwaren er implementeret, bemærker kunden, at kravene allerede er ændret, og det samme er forretningsscenariet. Softwaren har også en masse problemer. Effektivt betragtes hele indsatsen inden for softwareudvikling nu som spild.

Hvad gjorde BT for at løse de ovennævnte problemer?

BT indså, at forstærkning af vandfaldsmodellen ikke var svaret på problemerne. Det var nødvendigt med en ny tilgang. Så det besluttede at implementere Agile-metoden. Under den nye tilgang blev følgende ting besluttet:

• I stedet for den 12-måneders udviklingscyklus, vil BT nu levere brugbare software-stykker i en 90-dages cyklus. Ideen var at fokusere på et eller to forretningsproblemer og målrette mod at levere en softwareløsning inden for 90 dage. Begyndelsen på denne cyklus blev præget af en intens diskussion mellem forskellige interessenter, så kravene tydeligt blev identificeret, analyseret og prioriteret.
• Målet var at levere klare, håndgribelige forretningsværdier. Den interne kunde var under pres for at stille klare krav. Så i stedet for vage mål blev brugerhistorier givet med klare acceptkriterier.
• Den software, der vil blive leveret, ville blive testet og dokumenteret fuldt ud. Softwaren vil gennemgå hyppige integrationstest for at identificere problemer på forhånd.

Med Agile-tilgangen kunne BT lettere tilpasse sig skiftende krav eller forretningssituationer. Kodekvaliteten blev forbedret, og de grundlæggende fejl i sidste øjeblik blev adresseret.

Konklusion

Agile, for alle dets fordele og hypen omkring det, er stadig i et stadium, hvor dens potentiale ikke er fuldt ud realiseret. Dette skyldes, at mange organisationer tilpasser fremgangsmåden til omfanget af at ændre dens oprindelige principper. Som et resultat er vandfaldsmodellen i nogle tilfælde comeback. Mens tilpasningen fortsætter, er det vigtigt at bevare Agiles grundlæggende principper. Mange organisationer hævder at være fuldt agile, men de har stadig en vej at gå for at blive en virkelig agile virksomhed.