Kuinka ketterä IT voi muuttaa IT-alaa?

Sisältö

• Miksi ketterä IT?
• Kuinka ketterä menetelmä ratkaisee vesiputousmallin ongelmat?
• Kuinka ketterä on vaikuttanut IT-alaan?
• Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
• Syyt BT siirtyi ketteriin käytäntöihin
• Vaatimuksien huono hallinta
  
• Huono ohjelmistosuunnittelu
• Kehitysrajoitukset
• Mitä BT teki edellä mainittujen ongelmien ratkaisemiseksi?
• johtopäätös

Lähde: Darkovujic / Dreamstime.com

Ottaa mukaan:

Monille ohjelmistokehityksen vesiputousmalli on ollut standardi vuosikymmenien ajan, mutta se on nyt korvattu paljon joustavammalla ketterällä menetelmällä.

Ketterä ohjelmistokehitysmenetelmä voi vaikuttaa positiivisesti IT-alaan. Ketterän metodologian käyttöönoton tulokset voidaan mitata monilla tavoilla. Ohjelmiston nopeampi muutospyyntö, vähemmän virheitä, tiimin suorituskyvyn kvantitatiivinen mittaus ja pullonkaulat ovat kaikki heikkoja Agile-ohjelman onnistuneen käyttöönoton aiheita. Ketterän vaikutuksen onnistuneeksi mittaamiseksi organisaation on vertailtava erilaisia ​​mittareita, jotka liittyvät ennen ketteryyttä ja sen jälkeen tapahtuvaan kehitykseen. Ketterän todellista vaikutusta ei voida mitata pelkästään tulojen kasvulla tai korjattujen virheiden lisääntyneellä määrällä. Todellisten vaikutusten ymmärtämiseksi on otettava huomioon useita sisäisiä parametreja. (Lisätietoja ketterästä kehityksestä, katso ketterä ohjelmistokehitys 101.)

Miksi ketterä IT?

IT-ala on nojautunut ketteriin käytäntöihin lähinnä ohjelmistokehityksen vesiputousmallin rajoitusten takia. Yleensä on havaittu, että IT-yritykset eivät pysty vastaamaan muuttuviin asiakkaiden vaatimuksiin tai markkinatilanteisiin tai vähentämään kustannuksia ohjelmistokehityksen vesiputousmallilla. Vaikka vastapainottaisimme tätä ylivoimaista taipumusta ketterään metodologiaan ja katsomme, että osa jännityksestä on vain hypeä, vesiputousmalliin on paljon empiiristä palautetta.

Yksinkertaisesti sanottuna vesiputousmalli on ohjelmistokehitysmalli, jossa työ tehdään peräkkäin - vaihe toisensa jälkeen. Mallissa on viisi vaihetta: vaatimukset, suunnittelu, toteutus, todentaminen ja ylläpito. Yleensä yhden vaiheen suorittamisen jälkeen on vaikeaa, ellei mahdotonta tehdä muutoksia aikaisempaan vaiheeseen. Joten oletetaan, että vaatimukset ovat melko kiinteät. Suurin ero ketterässä mallissa on oletuksessa, että vaatimuksissa ei tapahdu muutoksia. Ketterä olettaa, että liiketoimintatilanteet muuttuvat, samoin vaatimukset. Joten ohjelmisto toimitetaan pienempinä palasina ss: n verran, kun taas vesiputousmallissa ensimmäinen toimitus tai julkaisu tapahtuu pitkän ajan kuluttua. (Lisätietoja kehittämisestä on artikkelissa Kuinka Apache Spark auttaa nopeaa sovelluskehitystä.)

Merkittävin kritiikki vesiputousmallia vastaan ​​on ollut sen olettamus, että vaatimuksissa ei tapahdu muutoksia. Hyvin oletus on virheellinen ja epärealistinen. Esimerkiksi vuonna 2001 Yhdistyneessä kuningaskunnassa tehty 1 027 IT-hanketta koskeva tutkimus osoitti, että tämä oletus oli ainoa suurin syy IT-hankkeiden epäonnistumiseen.

Eräässä toisessa esimerkissä Craig Larman, kirjan "Agile and Iterative Development: a Manager's Guide", kirjoittaja, on kertonut, kuinka monet Yhdysvaltain vesiputomallia käyttävät puolustusministeriön (DoD) toteuttamat projektit eivät ole onnistuneet saavuttaa tavoitteensa. 1980-luvun ja 1990-luvun aikana DoD: ta vaadittiin käyttämään vesiputousmallia ohjelmistokehitysprojekteihinsa, kuten julkaisussa DoD STD 2167 julkaistut standardit osoittavat. Järkyttävät tilastot osoittivat, että 75% näistä ohjelmistoprojekteista ei koskaan käytetty. Tämän raportin jälkeen perustettiin työryhmä, tunnettu Frederick Brooks, tunnettu ohjelmistosuunnittelun asiantuntija. Työryhmä julkaisi raportin, jossa kommentoitiin ”DoD STD 2167 tarvitsee myös radikaalin muutoksen, jotta se heijastaisi nykyaikaisia ​​parhaita käytäntöjä. Evoluutiokehitys on teknisesti paras, se säästää aikaa ja rahaa. ”

Seuraavat neljä vesiputomallin olettamusta olivat epäonnistuneet reaalimaailman skenaarioissa:

• Annetut vaatimukset on suhteellisen hyvin määritelty, joten ne eivät muutu merkittävästi.
• Vaikka vaatimukset muuttuisivat kehitysvaiheen aikana, ne ovat riittävän pieniä mukautumaan kehityssykliin.
• Järjestelmän integrointi, joka tapahtuu ohjelmiston toimituksen jälkeen, etenee suunnitelman mukaan.
• Ohjelmistoinnovaatiot ja innovointiin tarvittavat ponnistelut kulkevat suunnitellun ja ennustettavan aikataulun mukaisesti.

Kuinka ketterä menetelmä ratkaisee vesiputousmallin ongelmat?

Ketterä menetelmä eroaa pohjimmiltaan vesiputousmallista, ja se käy selvästi ilmi oletuksista:

• Kukaan, edes asiakas, ei voi täysin tuntea tai ymmärtää vaatimuksia. Ei ole takuuta, että vaatimukset eivät muutu.
• Vaatimusmuutokset eivät välttämättä ole pieniä ja hallittavissa. Itse asiassa niitä on erikokoisia ja tulee jatkuvasti. Joten ohjelmisto toimitetaan pieninä osina seurataksesi muutoksia.

Kuinka ketterä on vaikuttanut IT-alaan?

Ketterä otetaan käyttöön monissa paikoissa, kun taas monet yritykset suunnittelevat ketterän käyttöönottoa. Vaikka Agile on ehdottomasti tehnyt perusteellisia muutoksia IT-alaan, tosiasioita ja lukuja on edelleen vaikea saada. Mutta Agilien vaikutukset voidaan ymmärtää jäljempänä esitetyllä British Telecomin (BT) tapaustutkimuksella.

Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi

Et voi parantaa ohjelmointitaitojasi, kun kukaan ei välitä ohjelmiston laadusta.

Syyt BT siirtyi ketteriin käytäntöihin

BT alkoi kokea useita ongelmia ohjelmistokehityskäytäntöjen kanssa jo vuonna 2004. BT kehitti useita ohjelmistoprojekteja, sekä yksinkertaisia ​​että monimutkaisia. Monet ohjelmistoprojektit eivät kyenneet kehittämään laadukasta tulosta sovitussa aikataulussa. BT totesi, että ongelmien juuret johtuvat vesiputousmallista. Joten vesiputousmallin vahvistamisesta ei ollut apua. Seuraavassa on esitetty ongelmien tärkeimmät syyt:

Vaatimuksien huono hallinta

• Liian monta vaatimusta annettiin täyttää liian rajoitetussa ajassa.
• Monilla vaatimuksilla ei ollut merkitystä liiketoiminnan tarpeisiin.
• Lähes kaikille, ellei kaikille vaatimuksille, annettiin korkean prioriteetin tila.
• Vaatimukset edustivat nykyisiä liiketoiminnan tarpeita ilman tulevaisuuden skenaarioita. Se jätti mahdollisuuden tuleviin ohjelmistomuutoksiin.

Huono ohjelmistosuunnittelu

• Koska valtava määrä vaatimuksia, suunnittelijat käyttivät liikaa aikaa yrittäessään selvittää, mitä vaatimukset tarkoittivat. Varsinaiseen suunnitteluun jäi vähän aikaa.
• Vaatimusanalyytikot siirtyivät muihin tehtäviin ottaen mukanaan kirjoittamatonta, hiljaista tietoa.
• Edellä mainitut kaksi tekijää johtivat huonoon suunnitteluun. Suunnittelijoiden piti toimittaa edelleen alkuperäisen aikataulun mukaisesti.

Kehitysrajoitukset

Koodaus oli kiireistä ja huonoa laatua virheellisen ohjelmistosuunnittelun takia. Kehittäjät ymmärsivät, että huono ohjelmistosuunnittelu johtaisi huonoon koodiin, mutta sen oli kuitenkin toimitettava sovitulla aikataululla. Integroinnin aikana ilmoitetaan paljon virheitä, koska yksikkötestejä ja regressiotestejä ei suoritettu.

Ohjelmiston käyttöönottoajankohtana asiakas toteaa, että vaatimukset ovat jo muuttuneet ja samoin liiketoimintaskenaario. Ohjelmistolla on myös paljon ongelmia. Koko ohjelmistokehitysponnistelua pidetään nyt tuhlauksena.

Mitä BT teki edellä mainittujen ongelmien ratkaisemiseksi?

BT tajusi, että vesiputousmallin vahvistaminen ei ollut vastaus ongelmiin. Se tarvitsi uuden lähestymistavan. Joten se päätti toteuttaa ketterän lähestymistavan. Uuden lähestymistavan mukaisesti päätettiin seuraavista asioista:

• 12 kuukauden kehityssyklin sijaan BT toimittaisi nyt toimivia ohjelmistopapereita 90 päivän jaksossa. Ajatuksena oli keskittyä yhteen tai kahteen liiketoimintaongelmaan ja tavoitteena toimittaa ohjelmistoratkaisu 90 päivän kuluessa. Tämän syklin alkuun leimasi intensiivinen keskustelu eri sidosryhmien välillä niin, että vaatimukset yksilöitiin, analysoitiin ja priorisoitiin selvästi.
• Tavoitteena oli toimittaa selkeät, konkreettiset liiketoiminnan arvot. Sisäinen asiakas painostettiin antamaan selkeät vaatimukset. Joten epämääräisten tavoitteiden sijasta käyttäjän tarinoille annettiin selkeät hyväksymiskriteerit.
• Toimitettavat ohjelmistot testataan ja dokumentoidaan täysin. Ohjelmisto läpäisi usein integraatiotestit ongelmien tunnistamiseksi etukäteen.

Ketterän lähestymistavan avulla BT voisi helpommin mukautua muuttuviin vaatimuksiin tai liiketoimintatilanteisiin. Koodin laatu parani ja viime hetken perusvirheitä korjattiin.

johtopäätös

Ketterä kaikista eduistaan ​​ja sen ympärillä olevasta hypestä on edelleen vaiheessa, jossa sen potentiaalia ei hyödynnetä täysin. Tämä johtuu siitä, että monet organisaatiot mukauttavat lähestymistapaa sen alkuperäisten periaatteiden muuttamiseksi. Tämän seurauksena vesiputousmalli on paluuta joissain tapauksissa. Vaikka mukauttaminen jatkuu, on tärkeää säilyttää Agilesin perusperiaatteet. Monet organisaatiot väittävät olevansa täysin ketteriä, mutta niillä on vielä jonkin verran matkaa, jotta heistä tulisi todella ketterä yritys.