Kuidas saab Agile IT muuta IT-tööstust?

Autor: Roger Morrison
Loomise Kuupäev: 20 September 2021
Värskenduse Kuupäev: 21 Juunis 2024
Anonim
Kuidas saab Agile IT muuta IT-tööstust? - Tehnoloogia
Kuidas saab Agile IT muuta IT-tööstust? - Tehnoloogia

Sisu



Allikas: Darkovujic / Dreamstime.com

Ära võtma:

Paljude jaoks on tarkvaraarenduse jugamudel olnud standardiks juba aastakümneid, kuid nüüd on see asendatud palju paindlikuma Agile metoodikaga.

Tarkvaraarenduse vilgas metoodika võib IT-tööstust positiivselt mõjutada. Agile metoodika kasutuselevõtu tulemusi saab mõõta mitmel viisil. Tarkvara muutmistaotluste kiirem käive, vähem vigu, meeskonna jõudluse kvantitatiivne mõõtmine ja kitsaskohad on kõik Agile eduka juurutamise peegeldus. Agiilsuse mõju edukaks mõõtmiseks peab organisatsioon võrdlema erinevaid eel-Agile ja -järgse arenguga seotud mõõdikuid. Agile tegelikku mõju ei saa mõõta üksnes tulude kasvuga või parandatud vigade arvu suurenemisega. Tegeliku mõju mõistmiseks tuleb arvestada mitmete sisemiste parameetritega. (Agiilse arengu kohta leiate lisateavet Agiilsest tarkvaraarendusest 101.)


Miks agar IT?

IT-tööstus on kaldunud vilgaste tavade poole peamiselt tarkvaraarenduse jugamudeli piirangute tõttu. Üldiselt on täheldatud, et IT-ettevõtted ei suuda tarkvaraarenduse jugamudeli abil reageerida muutuvatele klientide nõudmistele või turuolukorrale ega vähendada kulusid. Isegi kui me tasakaalustaksime selle ülipika kallutuse Agile metoodika poole ja arvaksime, et mõni põnevus on lihtsalt hüpe, on jugamudeli kohta palju empiirilist tagasisidet.

Lihtsamalt öeldes on jugamudel tarkvaraarendusmudel, kus tööd tehakse järjestikku - üks etapp teise järel. Sellel mudelil on viis etappi: nõuded, kavandamine, rakendamine, kontrollimine ja hooldus. Tavaliselt on pärast ühe etapi läbimist keeruline, kui mitte võimatu, muuta varasemat faasi. Seega eeldatakse, et nõuded on üsna fikseeritud. Peamine erinevus Agile mudeli osas on eeldusel, et nõudeid ei muudeta. Agiilne eeldab, et ärisituatsioonid muutuvad ja ka nõuded. Niisiis, tarkvara tarnitakse väiksemate tükkidena ss-ga, samas kui jugamudelis toimub esimene tarnimine või vabastamine pika aja möödudes. (Lisateavet arengu kohta leiate teemast, kuidas Apache Spark aitab rakenduste kiiret arendust.)


Kõige märkimisväärsem kriitika jugamudeli vastu on olnud eeldus, et nõudeid ei muudeta. Eeldus on vigane ja ebareaalne. Näiteks näitas 2001. aastal Ühendkuningriigis 1027 IT-projekti käsitlev uuring, et see eeldus oli IT-projektide ebaõnnestumise ainus suurim põhjus.

Teises näites on raamatu "Agile and Iterative Development: A Manager's Guide" autor Craig Larman osutanud, kuidas mitmed kaitseministeeriumi (DoD) poolt USA jugamudelit kasutavad projektid pole suutnud läbi viia saavutada oma eesmärgid. 1980ndatel ja 1990ndatel pidi DoD oma tarkvaraarendusprojektide jaoks kasutama jugamudelit vastavalt standardis DoD STD 2167 avaldatud standarditele. Shokeeriv statistika näitas, et 75% neist tarkvaraprojektidest ei olnud kunagi kasutatud. Pärast seda aruannet loodi töörühm, kes juhtis tuntud tarkvaratehnika ekspert dr Frederick Brooks. Töörühm tuli välja raportiga, milles kommenteeriti: „DoD STD 2167 vajab samamoodi radikaalset ümberkorraldamist, et kajastada tänapäevaseid parimaid tavasid. Evolutsiooniline areng on tehniliselt parim, see säästab aega ja raha. ”

Järgmised neli jugamudeli eeldust olid tegeliku stsenaariumi korral ebaõnnestunud:

  • Esitatud nõuded on piisavalt hästi määratletud ja seega ei muutu need oluliselt.
  • Isegi kui arendusetapis nõuded muutuvad, on need piisavalt väikesed, et neid arendustsüklis mahutada.
  • Süsteemi integreerimine, mis toimub pärast tarkvara tarnimist, toimub plaanipäraselt.
  • Tarkvarainnovatsioon ja uuendusteks vajalikud pingutused kulgevad vastavalt kavandatud ja ettearvatavale ajakavale.

Kuidas agar metoodika lahendab jugamudeli probleeme?

Agiilne metoodika erineb põhimõtteliselt jugamudelist ja see selgub eeldustest:

  • Keegi, isegi mitte klient, ei saa nõudeid täielikult teada ega mõista. Ei ole mingit garantiid, et nõuded ei muutu.
  • Nõuete muudatused ei pruugi olla väikesed ja hallatavad. Tegelikult on neid erinevas suuruses ja neid tuleb ka edaspidi. Niisiis tarnitakse tarkvara muudatuste jälgimiseks väikeste sammudega.

Kuidas on Agile mõjutanud IT-tööstust?

Agile võetakse kasutusele paljudes kohtades, samas kui paljud ettevõtted plaanivad Agile kasutusele võtta. Kuigi Agile on kindlasti teinud IT-valdkonnas põhjalikke muudatusi, on faktide ja arvnäitajate leidmine siiski pisut keeruline. Kuid Agile mõju saab mõista allpool toodud British Telecomi (BT) juhtumianalüüsi abil.

Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata


Te ei saa oma programmeerimisoskusi parandada, kui keegi tarkvara kvaliteedist ei hooli.

Põhjused, miks BT on liikunud vilgaste tavade juurde

BT-l tekkis tarkvara arendamise tavadega mitmeid probleeme juba 2004. aastal. BT arendas mitmeid tarkvaraprojekte, nii lihtsaid kui ka keerukaid. Paljud tarkvaraprojektid ei suutnud kokkulepitud aja jooksul kvaliteetset väljundit välja töötada. BT leidis, et probleemide põhjuseks on jugamudel. Nii et jugamudeli tugevdamine ei aidanud. Probleemide peamised põhjused on toodud allpool:

Nõuete halb haldamine

  • Liiga palju nõudeid esitati liiga piiratud aja jooksul täitmiseks.
  • Paljud nõuded olid ärivajaduste seisukohast ebaolulised.
  • Peaaegu kõigile, kui mitte kõigile nõuetele omistati kõrge prioriteediga olek.
  • Nõuded esindasid praeguseid ärivajadusi, ilma et oleks võimalik tulevikustsenaariume vaadata. See jättis võimaluse tarkvara edaspidiseks muutmiseks.

Kehv tarkvarakujundus

  • Arvestades tohutut arvu nõudeid, kulutasid disainerid liiga palju aega, püüdes lihtsalt aru saada, mida nõuded tähendasid. Tegelikule kujundusele jäi vähe aega.
  • Nõudeanalüütikud siirdusid muudele ülesannetele, võttes endaga kirjutamata, vaikivaid teadmisi.
  • Kaks ülaltoodud tegurit põhjustasid halva kujunduse. Disainerid pidid ikkagi toimetama vastavalt esialgsele ajajoonele.

Arengupiirangud

Kodeerimine oli puuduliku tarkvarakujunduse tõttu kiirustades ja halva kvaliteediga. Arendajad mõistaksid, et halva tarkvara kujundamise tulemuseks oleks kehv kood, kuid sellegipoolest pidi see toimuma kokkulepitud ajakavas. Integreerimise ajal teatatakse paljudest vigadest, kuna ühikteste ja regressioonteste ei käivitatud.

Tarkvara juurutamise ajaks märgib klient, et nõuded on juba muutunud ja nii on ka äristsenaarium. Tarkvaral on ka palju probleeme. Tegelikult peetakse kogu tarkvara arendamise jõupingutusi nüüd raiskamiseks.

Mida tegi BT ülalnimetatud probleemide lahendamiseks?

BT mõistis, et jugamudeli tugevdamine ei olnud probleemidele lahendus. See vajas uut lähenemist. Niisiis, otsustas ta rakendada Agile lähenemisviisi. Uue lähenemisviisi kohaselt otsustati järgmised asjad:

  • 12-kuulise arendustsükli asemel tarniks BT nüüd 90-päevase tsükli jooksul toimivaid tarkvarapakette. Idee oli keskenduda ühele või kahele äriprobleemile ning eesmärk oli pakkuda tarkvaralahendus 90 päeva jooksul. Selle tsükli algust tähistas intensiivne arutelu erinevate sidusrühmade vahel, nii et nõuded olid selgelt määratletud, analüüsitud ja tähtsuse järjekorda seatud.
  • Eesmärk oli pakkuda selgeid ja käegakatsutavaid äriväärtusi. Sisekliendile avaldati survet selgete nõuete esitamiseks. Niisiis anti ebamääraste eesmärkide asemel kasutaja lugusid selgete vastuvõtmiskriteeriumidega.
  • Tarnitavat tarkvara testitakse ja dokumenteeritakse täielikult. Tarkvara läbiks sagedased integratsioonitestid, et probleemid eelnevalt kindlaks teha.

Agiilse lähenemisviisi abil saaks BT kergemini kohaneda muutuvate nõudmiste või ärisituatsioonidega. Koodi kvaliteet paranes ja viimase hetke põhivigadega tegeleti.

Järeldus

Agile kõigi eeliste ja ümbritseva hüpe osas on endiselt etapis, kus tema potentsiaal ei ole veel täielikult realiseeritud. Selle põhjuseks on asjaolu, et paljud organisatsioonid kohandavad lähenemisviisi selle algsete põhimõtete muutmise ulatuses. Selle tulemusel on jugamudel mõnel juhul tagasitulek. Kuigi kohandamine jätkub, on oluline säilitada Agiles'i põhiprintsiibid. Paljud organisatsioonid väidavad, et on täiesti Agile, kuid neil on veel mõni tee minna, et saada tõeliselt Agile ettevõtteks.