In che modo l'IT agile può trasformare il settore IT?

Autore: Roger Morrison
Data Della Creazione: 20 Settembre 2021
Data Di Aggiornamento: 21 Giugno 2024
Anonim
In che modo l'IT agile può trasformare il settore IT? - Tecnologia
In che modo l'IT agile può trasformare il settore IT? - Tecnologia

Contenuto



Fonte: Darkovujic / Dreamstime.com

Porta via:

Per molti, il modello a cascata dello sviluppo software è stato lo standard per decenni, ma ora viene sostituito dalla metodologia Agile molto più flessibile.

La metodologia Agile per lo sviluppo del software può avere un impatto positivo sul settore IT. I risultati dell'adozione della metodologia Agile possono essere misurati in diversi modi. Il rapido inversione delle richieste di modifica del software, un minor numero di bug, la misurazione quantitativa delle prestazioni del team e i colli di bottiglia sono tutti i riflettori di un'implementazione riuscita di Agile. Per misurare con successo l'impatto di Agile, un'organizzazione deve confrontare varie metriche relative allo sviluppo pre-Agile e post-Agile. Il reale impatto di Agile non può essere misurato solo dall'aumento delle entrate o dall'aumento del numero di bug corretti. Diversi parametri interni devono essere considerati per comprendere il reale impatto. (Per ulteriori informazioni sullo sviluppo Agile, consultare Agile Software Development 101.)


Perché Agile IT?

Il settore IT si è orientato verso le pratiche Agile principalmente a causa dei vincoli del modello a cascata dello sviluppo del software. In generale, è stato osservato che le società IT non sono in grado di rispondere alle mutevoli esigenze dei clienti o alle situazioni di mercato o di ridurre i costi con il modello a cascata dello sviluppo del software. Anche se controbilanciamo questa schiacciante inclinazione verso la metodologia Agile e consideriamo che l'eccitazione sia solo un clamore, ci sono molti feedback empirici contro il modello a cascata.

In poche parole, il modello a cascata è un modello di sviluppo software in cui il lavoro viene svolto in modo sequenziale, una fase dopo l'altra. Esistono cinque fasi di questo modello: requisiti, progettazione, implementazione, verifica e manutenzione. Di solito, dopo che una fase è stata completata, è difficile, se non impossibile, apportare modifiche a una fase precedente. Quindi, il presupposto è che i requisiti siano praticamente fissi. La differenza principale con il modello Agile è nel presupposto che non ci saranno cambiamenti nei requisiti. Agile presume che le situazioni aziendali cambieranno e così anche i requisiti. Pertanto, il software viene consegnato in blocchi più piccoli rispetto a ss, mentre nel modello a cascata, la prima consegna o rilascio viene effettuata dopo molto tempo. (Per ulteriori informazioni sullo sviluppo, vedere Come Apache Spark aiuta lo sviluppo rapido di applicazioni.)


La critica più notevole contro il modello a cascata è stata la sua ipotesi che non ci saranno cambiamenti nei requisiti. Il presupposto è imperfetto e irrealistico. Ad esempio, nel 2001, uno studio su 1.027 progetti IT nel Regno Unito ha mostrato che questa ipotesi è stata la principale ragione del fallimento dei progetti IT.

In un altro esempio, Craig Larman, autore del libro "Agile and Iterative Development: A Manager's Guide", ha sottolineato come un certo numero di progetti realizzati dal Dipartimento della Difesa (DoD) utilizzando il modello a cascata negli Stati Uniti non siano riusciti a raggiungere i loro obiettivi. Durante gli anni '80 e '90, al DoD è stato richiesto di utilizzare il modello a cascata per i suoi progetti di sviluppo software secondo gli standard pubblicati nel DoD STD 2167. Le statistiche scioccanti hanno rivelato che il 75% di questi progetti software non è mai stato utilizzato. A seguito di questo rapporto, è stata lanciata una task force sotto la guida del Dr. Frederick Brooks, un noto esperto di ingegneria del software. La task force è uscita con un rapporto che ha commentato che "DoD STD 2167 ha anche bisogno di una revisione radicale per riflettere le migliori pratiche moderne. Lo sviluppo evolutivo è tecnicamente migliore, consente di risparmiare tempo e denaro ".

I seguenti quattro presupposti del modello a cascata erano falliti negli scenari del mondo reale:

  • I requisiti indicati sono ragionevolmente ben definiti e quindi non cambieranno in modo significativo.
  • Anche se i requisiti cambiano durante la fase di sviluppo, saranno abbastanza piccoli da poter essere inseriti nel ciclo di sviluppo.
  • L'integrazione del sistema, che si verifica dopo la consegna del software, andrà secondo il piano.
  • L'innovazione del software e lo sforzo necessario per innovare andranno secondo un programma pianificato e prevedibile.

In che modo la metodologia agile affronta i problemi del modello a cascata?

La metodologia Agile è fondamentalmente diversa dal modello a cascata e questo è chiaro dai suoi presupposti:

  • Nessuno, nemmeno il cliente, può conoscere o comprendere appieno i requisiti. Non vi è alcuna garanzia che i requisiti non cambieranno.
  • Le modifiche ai requisiti potrebbero non essere piccole e gestibili. In effetti, arriveranno in varie dimensioni e continueranno ad arrivare. Pertanto, il software verrà consegnato in piccoli incrementi per tenere traccia delle modifiche.

Che impatto ha avuto Agile sul settore IT?

Agile viene adottato in molti luoghi, mentre molte aziende stanno pianificando di adottare Agile. Sebbene Agile abbia sicuramente apportato cambiamenti fondamentali al settore IT, fatti e cifre sono ancora un po 'difficili da ottenere. Ma l'impatto di Agile può essere compreso con il case study di British Telecom (BT) riportato di seguito.

Nessun bug, nessuno stress: la tua guida passo passo alla creazione di software che ti cambia la vita senza distruggere la tua vita


Non puoi migliorare le tue capacità di programmazione quando a nessuno importa della qualità del software.

Motivi BT passati a pratiche agili

BT ha iniziato a riscontrare una serie di problemi con le sue pratiche di sviluppo software nel 2004. BT ha sviluppato una serie di progetti software, sia semplici che complessi. Molti progetti software non sono stati in grado di sviluppare risultati di qualità nei tempi concordati. BT ha scoperto che i problemi erano dovuti al modello a cascata. Quindi, rinforzare il modello a cascata non avrebbe aiutato. Di seguito sono riportate le principali cause dei problemi:

Cattiva gestione dei requisiti

  • Sono stati forniti troppi requisiti per essere soddisfatti entro un tempo troppo limitato.
  • Molti requisiti erano irrilevanti per le esigenze aziendali.
  • Quasi tutti, se non tutti i requisiti sono stati assegnati lo stato di alta priorità.
  • I requisiti rappresentavano le esigenze aziendali attuali senza tenere conto degli scenari futuri. Ciò ha lasciato aperta la possibilità di future modifiche al software.

Progettazione software scadente

  • Dato l'enorme numero di requisiti, i progettisti hanno impiegato troppo tempo a cercare di capire cosa significassero i requisiti. Rimaneva poco tempo per il vero design.
  • Gli analisti obbligatori si sono trasferiti ad altri incarichi, portando con sé conoscenze non scritte e tacite.
  • I due fattori di cui sopra hanno portato a un design scadente. I progettisti dovevano comunque consegnare secondo la cronologia originale.

Vincoli di sviluppo

La codifica era frettolosa e di scarsa qualità a causa della progettazione del software difettosa. Gli sviluppatori si renderanno conto che una cattiva progettazione del software si tradurrebbe in un codice scadente, ma tuttavia doveva consegnare entro la tempistica concordata. Durante l'integrazione verranno segnalati molti bug perché non sono stati eseguiti test unitari e test di regressione.

Al momento della distribuzione del software, il cliente rileva che i requisiti sono già cambiati e quindi anche lo scenario aziendale. Il software ha anche molti problemi. In effetti, l'intero sforzo dello sviluppo del software è ora considerato uno spreco.

Cosa ha fatto BT per risolvere i problemi sopra indicati?

BT si rese conto che il rafforzamento del modello a cascata non era la risposta ai problemi. Aveva bisogno di un nuovo approccio. Quindi, ha deciso di attuare l'approccio Agile. Con il nuovo approccio, sono state decise le seguenti cose:

  • Invece del ciclo di sviluppo di 12 mesi, BT ora fornirebbe software fattibili in un ciclo di 90 giorni. L'idea era quella di concentrarsi su uno o due problemi aziendali e mirare a fornire una soluzione software entro 90 giorni. L'inizio di questo ciclo è stato caratterizzato da un'intensa discussione tra le diverse parti interessate, in modo che i requisiti fossero chiaramente identificati, analizzati e prioritari.
  • L'obiettivo era fornire valori aziendali chiari e tangibili. Il cliente interno era sotto pressione per fornire requisiti chiari. Quindi, invece di obiettivi vaghi, le storie degli utenti sono state fornite con chiari criteri di accettazione.
  • Il software che verrebbe consegnato sarebbe completamente testato e documentato. Il software dovrebbe sottoporsi a frequenti test di integrazione per identificare in anticipo i problemi.

Con l'approccio Agile, BT potrebbe adattarsi più facilmente alle mutevoli esigenze o alle situazioni aziendali. La qualità del codice è migliorata e sono stati risolti i bug di base dell'ultimo minuto.

Conclusione

Agile, nonostante tutti i suoi vantaggi e il clamore che lo circonda, è ancora in una fase in cui il suo potenziale non è pienamente realizzato. Questo perché molte organizzazioni stanno personalizzando l'approccio al punto di modificarne i principi originali. Di conseguenza, il modello a cascata sta tornando in alcuni casi. Mentre la personalizzazione continuerà, è importante mantenere i principi di base di Agiles. Molte organizzazioni dichiarano di essere completamente agili, ma hanno ancora molta strada da fare per diventare un'azienda veramente agile.