Hur kan Agile IT omvandla IT-branschen?

Innehåll

• Varför agil IT?
• Hur hanterar smidig metodik problem med vattenfallsmodellen?
• Hur har Agile påverkat IT-branschen?
• Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
• Skäl BT skiftas till smidiga praxis
• Dålig hantering av krav
  
• Dålig programvarudesign
• Utvecklingsbegränsningar
• Vad gjorde BT för att ta itu med ovanstående problem?
• Slutsats

Källa: Darkovujic / Dreamstime.com

Hämtmat:

För många har vattenfallsmodellen för mjukvaruutveckling varit standarden i årtionden, men den ersätts nu av den mycket mer flexibla Agile-metoden.

Agile-metoden för mjukvaruutveckling kan påverka IT-industrin positivt. Resultaten av antagande av agil metod kan mätas på ett antal sätt. Snabbare vändning av programförändringsbegäranden, färre buggar, kvantitativ mätning av teamets prestanda och flaskhalsar är alla återspeglingar av en framgångsrik implementering av Agile. För att framgångsrikt kunna mäta effekterna av Agile måste en organisation jämföra olika mätvärden relaterade till utvecklingen före agile och post-agile. Den verkliga effekten av Agile kan inte mätas bara genom ökningen av intäkter eller av det ökade antalet fixade buggar. Flera interna parametrar måste beaktas för att förstå den verkliga effekten. (Mer information om Agile-utveckling finns i Agile Software Development 101.)

Varför agil IT?

IT-industrin har lutat sig mot Agile-metoder, främst på grund av begränsningarna i vattenfallsmodellen för mjukvaruutveckling. I allmänhet har det observerats att IT-företag inte kan svara på förändrade kundkrav eller marknadssituationer eller sänka kostnaderna med vattenfallsmodellen för mjukvaruutveckling. Även om vi motverkar denna överväldigande lutning mot Agile-metodik och anser att en del av spänningen bara är hype, finns det mycket empirisk feedback mot vattenfallsmodellen.

Enkelt uttryckt är vattenfallsmodellen en mjukvaruutvecklingsmodell där arbetet utförs på ett sekventiellt sätt - en fas efter den andra. Det finns fem faser av denna modell: krav, design, implementering, verifiering och underhåll. När en fas har avslutats är det vanligtvis svårt, om inte omöjligt, att göra ändringar i en tidigare fas. Så antagandet är att kraven är ganska mycket fixerade. Den största skillnaden med Agile-modellen är antagandet att det inte kommer att förändras några krav. Agile antar att affärssituationer kommer att förändras och krav kommer också att göras. Så mjukvara levereras i mindre bitar över ss, medan i vattenfallsmodellen görs den första leveransen eller släppningen efter en lång tid. (Mer information om utveckling finns i Hur Apache Spark hjälper till snabb applikationsutveckling.)

Den mest anmärkningsvärda kritiken mot vattenfallsmodellen har varit dess antagande att det inte kommer att förändras några krav. Själva antagandet är bristfälligt och orealistiskt. År 2001 visade till exempel en studie på 1 027 IT-projekt i Storbritannien att detta antagande var den enskilt största orsaken till att IT-projekt misslyckades.

I ett annat exempel har Craig Larman, författaren till boken "Agile and Iterative Development: A Manager's Guide", påpekat hur ett antal projekt som utförts av Department of Defense (DoD) med vattenfallsmodellen i USA har misslyckats med att uppnå sina mål. Under hela 1980- och 1990-talet var DoD skyldigt att använda vattenfallsmodellen för sina programvaruutvecklingsprojekt enligt de standarder som publicerades i DoD STD 2167. Chockande statistik avslöjade att 75% av dessa programvaruprojekt aldrig användes. Efter denna rapport lanserades en arbetsgrupp under Dr. Frederick Brooks, en välkänd expert inom programvaruteknik. Arbetsgruppen kom ut med en rapport som kommenterade ”DoD STD 2167 behöver också en radikal översyn för att återspegla modern bästa praxis. Evolutionär utveckling är bäst tekniskt, det sparar tid och pengar. ”

Följande fyra antaganden om vattenfallsmodellen hade misslyckats i verkliga scenarier:

• De angivna kraven är rimligt väl definierade och kommer därför inte att ändras väsentligt.
• Även om kraven ändras under utvecklingsfasen, kommer de att vara tillräckligt små för att rymmas inom utvecklingscykeln.
• Systemintegration, som sker efter leverans av mjukvara, går enligt plan.
• Mjukvaruinnovation och den ansträngning som krävs för att innovera kommer att gå enligt ett planerat och förutsägbart schema.

Hur hanterar smidig metodik problem med vattenfallsmodellen?

Agile-metodiken skiljer sig grundläggande från vattenfallsmodellen och det framgår av antagandena:

• Ingen, inte ens kunden, kan helt eller delvis förstå eller förstå kraven. Det finns ingen garanti för att kraven inte kommer att ändras.
• Kravförändringar kanske inte är små och hanterbara. Faktum är att de kommer i olika storlekar och kommer att fortsätta att komma. Så mjukvaran kommer att levereras i små steg för att hålla reda på förändringarna.

Hur har Agile påverkat IT-branschen?

Agile adopteras på många ställen, medan många företag planerar att anta Agile. Även om Agile definitivt har gjort grundläggande förändringar i IT-branschen, är fakta och siffror fortfarande lite svåra att få. Men effekterna av Agile kan förstås med fallstudien av British Telecom (BT) som ges nedan.

Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv

Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.

Skäl BT skiftas till smidiga praxis

BT började uppleva ett antal problem med sina mjukvaruutvecklingsmetoder redan 2004. BT utvecklade ett antal mjukvaruprojekt, både enkla och komplicerade. Många programvaruprojekt kunde inte utveckla kvalitetsproduktion inom den överenskomna tidsramen. BT fann att problemen var skyldiga till vattenfallsmodellen. Så att förstärka vattenfallsmodellen skulle inte hjälpa. De huvudsakliga orsakerna till problemen anges nedan:

Dålig hantering av krav

• För många krav gavs för att uppfylla inom en för begränsad tid.
• Många krav var irrelevanta för företagets behov.
• Nästan alla, om inte alla krav tilldelades status med hög prioritet.
• Kraven representerade aktuella affärsbehov utan blick på de framtida scenarierna. Det gav en möjlighet till framtida programvaruändringar.

Dålig programvarudesign

• Med tanke på det enorma antalet krav lät designarna för mycket tid på att bara försöka ta reda på vad kraven innebar. Det fanns lite tid kvar för den faktiska designen.
• Kravanalytikerna flyttade till andra uppdrag och tog med sig oskriven, stillsam kunskap.
• Ovanstående två faktorer resulterade i dålig design. Formgivare måste fortfarande leverera enligt den ursprungliga tidslinjen.

Utvecklingsbegränsningar

Kodningen var hastig och av dålig kvalitet på grund av felaktig programvarudesign. Utvecklare skulle inse att en dålig programvarudesign skulle resultera i dålig kod, men ändå var tvungen att leverera med den överenskomna tidslinjen. Många buggar rapporterades under integrationen eftersom enhetstester och regressionstester inte kördes.

När programvaran distribueras noterar kunden att kraven redan har förändrats och att affärsscenariot också har gjort. Programvaran har också många problem. Effektivt anses nu hela ansträngningen för mjukvaruutveckling vara avfall.

Vad gjorde BT för att ta itu med ovanstående problem?

BT insåg att förstärkning av vattenfallsmodellen inte var svaret på problemen. Det behövdes en ny strategi. Så det beslutade att genomföra Agile-strategin. Enligt den nya metoden beslutades följande saker:

• Istället för en 12-månaders utvecklingscykel skulle BT nu leverera användbara programvara i en 90-dagars cykel. Tanken var att fokusera på ett eller två affärsproblem och mål att leverera en mjukvarulösning inom 90 dagar. Början av denna cykel präglades av en intensiv diskussion mellan olika intressenter så att kraven tydligt identifierades, analyserades och prioriterades.
• Målet var att leverera tydliga, konkreta affärsvärden. Den interna kunden var under press för att ställa tydliga krav. I stället för vaga mål gavs användarhistorier med tydliga godkännandekriterier.
• Programvaran som skulle levereras skulle testas och dokumenteras helt. Programvaran skulle genomgå ofta integreringstester för att identifiera problem i förväg.

Med Agile-metoden kunde BT lättare anpassa sig till förändrade krav eller affärssituationer. Kodkvaliteten förbättrades och basfel i sista minuten behandlades.

Slutsats

Agile, för alla dess fördelar och hypen runt det, är fortfarande i ett stadium där dess potential inte fullt ut realiseras. Detta beror på att många organisationer skräddarsyr tillvägagångssättet i den mån de ändrar sina ursprungliga principer. Som ett resultat gör vattenfallsmodellen ett comeback i vissa fall. Även om anpassningen kommer att fortsätta, är det viktigt att behålla Agiles grundläggande principer. Många organisationer påstår sig vara fulla agila, men de har fortfarande ett sätt att gå för att bli ett verkligt agilt företag.