Cum poate Agile IT transforma industria IT?

Autor: Roger Morrison
Data Creației: 20 Septembrie 2021
Data Actualizării: 19 Iunie 2024
Anonim
30 Silly Questions for an Agile Coach [IT Career]
Video: 30 Silly Questions for an Agile Coach [IT Career]

Conţinut



Sursa: Darkovujic / Dreamstime.com

La pachet:

Pentru mulți, modelul de dezvoltare a cascadei a fost standard timp de zeci de ani, dar acesta este acum înlocuit de metodologia Agile mult mai flexibilă.

Metodologia Agile pentru dezvoltarea de software poate avea un impact pozitiv în industria IT. Rezultatele adoptării metodologiei Agile pot fi măsurate în mai multe moduri. O schimbare mai rapidă a cererilor de schimbare de software, mai puține erori, măsurarea cantitativă a performanței echipei și blocajele sunt toate reflectări ale unei implementări de succes a Agile. Pentru a măsura cu succes impactul Agile, o organizație trebuie să compare diverse valori legate de dezvoltarea pre-agilă și cea post-agilă. Impactul real al Agile nu poate fi măsurat doar prin creșterea veniturilor sau cu numărul crescut de buguri rezolvate. Mai mulți parametri interni trebuie luați în considerare pentru a înțelege impactul real. (Pentru mai multe despre dezvoltarea Agile, a se vedea Agile Software Development 101.)


De ce IT Agile?

Industria IT s-a aplecat către practici agile, în principal din cauza constrângerilor modelului de cascadă în dezvoltarea de software. În general, s-a observat că companiile IT nu sunt în măsură să răspundă la schimbările cerințelor clienților sau la situațiile de piață sau să reducă costurile cu modelul cascadei de dezvoltare software. Chiar dacă contrabalansăm această înclinare copleșitoare spre metodologia Agile și considerăm o parte din entuziasmul doar pentru a fi hype, există multe feedback empiric împotriva modelului cascadei.

Mai simplu spus, modelul cascadă este un model de dezvoltare software în care lucrările sunt realizate în mod secvențial - o fază după alta. Există cinci faze ale acestui model: cerințe, proiectare, implementare, verificare și întreținere. De obicei, după ce o fază a fost finalizată, este dificil, dacă nu imposibil, să efectuați modificări la o fază anterioară. Deci, presupunerea este că cerințele sunt destul de fixate. Principala diferență cu modelul Agile constă în presupunerea că nu se va schimba cerințele. Agile presupune că situațiile de afaceri se vor schimba și la fel și cerințele. Deci, software-ul este livrat în bucăți mai mici peste ss, în timp ce în modelul cascadei, prima livrare sau eliberare se face după mult timp. (Pentru mai multe despre dezvoltare, consultați modul în care Apache Spark ajută la dezvoltarea rapidă a aplicațiilor.)


Cea mai notabilă critică împotriva modelului cascadei a fost presupunerea sa că nu va exista nicio schimbare a cerințelor. Presupunerea însăși este defectuoasă și nerealistă. De exemplu, în 2001, un studiu pe 1.027 de proiecte IT din U.K. a arătat că această presupunere a fost cel mai mare motiv pentru eșecul proiectelor IT.

Într-un alt exemplu, Craig Larman, autorul cărții „Agile and Iterative Development: A Manager's Guide”, a arătat cum o serie de proiecte executate de Departamentul Apărării (DoD) folosind modelul cascadei din SUA nu au reușit își ating obiectivele. De-a lungul anilor 1980 și 1990, DoD a fost obligat să folosească modelul cascadei pentru proiectele sale de dezvoltare software conform standardelor publicate în DoD STD 2167. Statisticile șocante au relevat că 75% din aceste proiecte software nu au fost niciodată utilizate. În urma acestui raport, un grup de lucru a fost lansat în cadrul Dr. Frederick Brooks, un cunoscut expert în inginerie software. Grupul de lucru a ieșit cu un raport care a comentat „DoD STD 2167 are, de asemenea, nevoie de o revizuire radicală pentru a reflecta cele mai bune practici moderne. Dezvoltarea evolutivă este cea mai bună din punct de vedere tehnic, economisește timp și bani. "

Următoarele patru presupuneri ale modelului cascadei au eșuat în scenariile din lumea reală:

  • Cerințele date sunt rezonabil bine definite și, prin urmare, nu se vor schimba semnificativ.
  • Chiar dacă cerințele se schimbă în faza de dezvoltare, acestea vor fi suficient de mici pentru a fi încadrate în ciclul de dezvoltare.
  • Integrarea sistemului, care se întâmplă după livrarea de software, va merge conform planului.
  • Inovația software și efortul necesar pentru a inova vor merge conform unui program planificat și previzibil.

Cum abordează metodologia agilă problemelor modelului cascadei?

Metodologia Agile este fundamental diferită de modelul cascadei și asta este clar din presupunerile sale:

  • Nimeni, nici măcar clientul, nu poate cunoaște sau înțelege pe deplin cerințele. Nu există nicio garanție că cerințele nu se vor schimba.
  • Modificările cerințelor pot să nu fie mici și ușor de gestionat. De fapt, vor veni în diverse dimensiuni și vor continua. Astfel, software-ul va fi livrat în pași mici pentru a urmări modificările.

Cum a avut impact Agile în industria IT?

Agile este adoptat în multe locuri, în timp ce o mulțime de companii își propun să adopte Agile. Deși Agile a făcut cu siguranță modificări fundamentale în industria IT, faptele și cifrele sunt încă puțin dificil de obținut. Dar impactul Agile poate fi înțeles cu studiul de caz al British Telecom (BT) prezentat mai jos.

Fără bug-uri, fără stres - Ghidul dvs. pas cu pas pentru crearea de programe care schimbă viața fără a vă distruge viața


Nu îți poți îmbunătăți abilitățile de programare atunci când nimeni nu îi pasă de calitatea software-ului.

Motivele BT au trecut la practici agile

BT a început să întâmpine o serie de probleme cu practicile sale de dezvoltare software în 2004. BT a dezvoltat o serie de proiecte software, atât simple cât și complexe. Multe proiecte software nu au putut dezvolta o calitate de calitate în termenul convenit. BT a constatat că problemele își datorau rădăcinile modelului cascadei. Deci, consolidarea modelului cascadei nu va fi de folos. Principalele cauze ale problemelor sunt prezentate mai jos:

Gestionarea deficitară a cerințelor

  • Au fost date prea multe cerințe pentru a fi îndeplinite într-un timp prea limitat.
  • Multe cerințe erau irelevante pentru nevoile afacerii.
  • Aproape toate, dacă nu toate cerințelor li s-au atribuit statut de prioritate ridicată.
  • Cerințele reprezentau nevoile curente ale afacerii, fără a privi scenariile viitoare. Aceasta a lăsat deschisă posibilitatea viitoarelor modificări software.

Proiectare software slabă

  • Având în vedere numărul mare de cerințe, designerii au petrecut prea mult timp doar încercând să-și dea seama ce au însemnat cerințele. A rămas puțin timp pentru proiectarea propriu-zisă.
  • Analiștii cerinței s-au mutat la alte misiuni, luând cu ei cunoștințe nescrise, tacite.
  • Cei doi factori de mai sus au dus la un design deficitar. Proiectanții au fost nevoiți să livreze în conformitate cu cronologia inițială.

Constrângeri de dezvoltare

Codificarea a fost pripită și de proastă calitate din cauza proiectării software defectuoase. Dezvoltatorii și-ar da seama că un design software slab ar duce la un cod slab, dar totuși a trebuit să furnizeze termenul convenit. O mulțime de erori ar fi raportate în timpul integrării, deoarece testele de unitate și testele de regresie nu au fost executate.

Până la implementarea software-ului, clientul observă că cerințele s-au schimbat deja și la fel și scenariul de afaceri. Software-ul are, de asemenea, o mulțime de probleme. În mod eficient, întregul efort de dezvoltare a software-ului este considerat acum risipă.

Ce a făcut BT pentru a aborda problemele de mai sus?

BT și-a dat seama că consolidarea modelului cascadei nu a fost răspunsul la probleme. Avea nevoie de o nouă abordare. Deci, a decis să implementeze abordarea Agile. În baza noii abordări, s-au decis următoarele lucruri:

  • În locul ciclului de dezvoltare de 12 luni, BT va livra acum piese software viabile într-un ciclu de 90 de zile. Ideea a fost să vă concentrați pe una sau două probleme de afaceri și să vizați livrarea unei soluții software în 90 de zile. Începutul acestui ciclu a fost marcat de o discuție intensă între diferite părți interesate, astfel încât cerințele au fost clar identificate, analizate și priorizate.
  • Obiectivul a fost acela de a furniza valori comerciale clare și tangibile. Clientul intern a fost sub presiune pentru a furniza cerințe clare. Deci, în loc de obiective vagi, poveștile utilizatorilor au fost date cu criterii clare de acceptare.
  • Software-ul care va fi livrat va fi complet testat și documentat. Programul va trece prin teste de integrare frecvente în prealabil pentru a identifica problemele.

Cu abordarea Agile, BT s-ar putea adapta mai ușor la cerințele sau situațiile de afaceri în schimbare. Calitatea codului s-a îmbunătățit și au fost abordate erorile de bază ale ultimului minut.

Concluzie

Agile, pentru toate avantajele sale și hype-ul din jurul său, este încă într-o etapă în care potențialul său nu este pe deplin realizat. Acest lucru se datorează faptului că o mulțime de organizații personalizează abordarea în măsura modificării principiilor sale inițiale. În consecință, modelul cascadei revine în unele cazuri. În timp ce personalizarea va continua, este important să se păstreze principiile de bază ale Agiles. Multe organizații susțin că sunt pe deplin agile, dar mai au de unde să meargă pentru a deveni o companie cu adevărat agilă.