Waterfall Project Management - Oggi, la maggior parte dei team IT sta cercando di adottare sistemi di Project Management Agile. Ma quello che finiscono per fare è adottare i sistemi di Project Management Agile nei loro progetti. Ciò significa una combinazione di sistemi tradizionali di gestione dei progetti (chiamati Waterfall Project Management Systems), combinati con i Principi di Agile Management, come dettagliato nel Manifesto Agile originale.
Dato che un numero maggiore di progetti in tutto il mondo incorpora pratiche di Project Management Agile, ciò significa la fine della gestione dei progetti a cascata? Tutti i progetti IT finiranno per essere Agile Project Management?
Per comprendere i diversi modelli, incluso Agile, e utilizzare quello più adatto alla propria situazione, è importante capire innanzitutto di cosa tratta il tradizionale sistema di gestione dei progetti, chiamato Waterfall Project Management Model.
Il modello di gestione del progetto Waterfall, così chiamato per la natura del processo del flusso di lavoro, è caratterizzato da quanto segue:
- Il prodotto finale viene prima visualizzato nei minimi dettagli.
- Quindi le fasi del flusso di lavoro vengono implementate in sequenza:
- Requisiti e analisi
- Design
- Implementazione
- analisi
- Installazione
- Manutenzione
- Il piano di progetto dovrebbe essere infallibile perché una volta completata una fase della sequenza, gli sviluppatori non possono rivisitare lo stesso senza ricominciare la pianificazione.
- C'è poco spazio per modifiche o errori e il piano di progetto deve essere seguito diligentemente.
Origine del modello di gestione del progetto Waterfall:
Nelle prime fasi del settore IT, non esisteva un modello specifico per lo sviluppo del software.
Pertanto, l'industria ha adottato il modello di flusso di lavoro sequenziale utilizzato nelle industrie manifatturiere e delle costruzioni. Queste industrie avevano fasi di lavoro ben definite e avevano sviluppato un modello che soddisfaceva la loro necessità di un rigoroso controllo dei costi. Quindi il modello di industria hardware è stato applicato all'industria del software.
Winston W Royce ha presentato questo modello per la prima volta nel 1970, ma non ha usato il termine "Waterfall Project Management". In effetti, ha presentato il modello come difettoso. La rappresentazione pittorica del modello sembrava una cascata. Thomas E. Bell e TA Thayer in seguito hanno usato il termine "cascata" nel loro documento del 1976, "Requisiti software: sono davvero un problema?" E il termine è rimasto.
Esistono numerose varianti di questo modello. Le sei fasi distinte comunemente utilizzate nel Modello di gestione del progetto Waterfall sono spiegate di seguito. Tuttavia, a seconda del progetto, due fasi possono essere combinate insieme.
Consideriamo l'esempio della costruzione di una scuola come esempio per comprendere meglio il modello di gestione del progetto a cascata.
-
Requisiti e fase di analisi:
Innanzitutto, dobbiamo sapere esattamente cosa stiamo progettando. Per questo, potremmo voler:
- Condurre discussioni dettagliate con il cliente
- Prova a visualizzare chiaramente il prodotto con i suoi minimi dettagli
- Analizza quali componenti hardware e software sono richiesti
- Elencare i dettagli che includono: il problema che il prodotto dovrebbe risolvere, i vincoli del cliente, il livello di prestazioni e la compatibilità con i sistemi già esistenti.
- Condurre casi di studio di un prodotto simile.
- Considera i requisiti di ciascun stakeholder
- Elencare le specifiche nel documento sui requisiti del prodotto, che costituisce l'input per il passaggio successivo.
Nel nostro esempio di costruzione di una scuola, in questo passaggio, elenchiamo il numero di aule, il materiale da utilizzare per la costruzione, le persone necessarie, l'infrastruttura già esistente. Inoltre, annotiamo ciò che richiede la gestione della scuola (stanza dell'ufficio, stanza del personale) e cosa richiedono gli studenti (migliori servizi igienici, campi da gioco)
-
Design:
In fase di progettazione, tutto ciò che è stato visualizzato nella prima fase viene trasformato in un progetto.
Nei progetti IT, ciò consiste nel definire:
- L'hardware che verrà utilizzato
- La piattaforma software da utilizzare, inclusa la distribuzione locale o cloud
- L'architettura del software, inclusi i diversi componenti e moduli da creare
- Input richiesti per il corretto funzionamento del progetto
- Risultati prevedibili (idealmente, questo si sincronizzerà con i requisiti dettagliati nella fase precedente)
Esistono due tipi di design che entrano in gioco in un progetto software:
- Progettazione logica
- Disegno fisico
Progettazione logica:
Ciò include i dati e i processi di base che verranno inclusi nel progetto. Descrive in dettaglio la progettazione di moduli e report, la progettazione dell'interfaccia e la progettazione del database. Ad esempio, per un sito Web di biglietteria del treno, questo progetto determinerà come funzionerà l'intero processo: lo schermo su cui il viaggiatore immette i suoi dettagli e come tali dati fluiranno nel database, e anche quale tipo di database memorizzerà questi dettagli.
Disegno fisico:
Ciò riguarda la progettazione del database fisico, i programmi e i processi e i sistemi distribuiti. Questo viene fatto dopo il Logical Design e includerà "come" verrà fatto il progetto: l'hardware, la piattaforma su cui verrà sviluppato, i vari database, schermate e moduli che verranno utilizzati, ecc.
-
Implementazione:
- Qui è dove si svolge lo sviluppo reale del software / sistema.
- L'input per questa fase sono le specifiche di progettazione fornite dalla fase precedente.
- L'output è uno o più componenti del prodotto costruiti su specifiche, sottoposti a debug, testati e integrati per soddisfare l'architettura del sistema.
- Questa fase è generalmente curata dal team di sviluppo composto da programmatori, progettisti di interfacce e altri specialisti e gli strumenti utilizzati sono compilatori, debugger, interpreti ed editor di media.
- Questa fase richiede in genere il tempo massimo ed è importante tenere traccia diligentemente dei processi e del design. Le modifiche al design in questa fase sono difficili in Waterfall Project Management.
- Per un progetto di grandi dimensioni che coinvolge più team, si consiglia il controllo della versione per tenere traccia delle modifiche all'albero del codice e ripristinare le istantanee precedenti per la gestione degli errori.
- Nel nostro esempio: l'effettiva costruzione dell'edificio utilizzando manodopera e materiali viene eseguita in questa fase.
-
test:
I test possono essere eseguiti per l'intero prodotto o per i singoli componenti. I "casi di test" possono essere verificati per vedere se il prodotto può essere consegnato come promesso. Ci possono essere test di moduli, test di sistema del prodotto integrato e test di collaudo. I test di accettazione comportano la verifica delle scappatoie del prodotto da parte dell'utente finale o del cliente. I difetti vengono annotati per essere corretti dal team di implementazione. Una volta apportate le correzioni, viene preparata una documentazione formale del prodotto.
Nell'esempio, l'infrastruttura della scuola viene testata, probabilmente da un gruppo di audit. In alcuni casi, gli insegnanti sono invitati a entrare e utilizzare i locali per fornire feedback.
-
Installazione:
Una volta completato il collaudo del prodotto in tutti gli aspetti, il prodotto può essere immesso sul mercato o installato presso la sede del cliente. In questa fase viene consegnata anche la documentazione completa del prodotto.
Nel caso della nostra scuola, viene ufficialmente inaugurato (preferibilmente da un colpo grosso!) E la scuola inizia le operazioni!
-
Manutenzione:
In questa fase, il team IT risolve eventuali problemi che potrebbero sorgere quando il cliente inizia effettivamente a utilizzare il prodotto o quando si verifica un miglioramento del prodotto. Una buona documentazione è la spina dorsale della manutenzione. I problemi vengono risolti modificando i codici, chiamati "patch".
Se sono necessarie importanti modifiche, il progetto potrebbe tornare al team di sviluppo come nuovo progetto.
Nel nostro esempio, la scuola ha bisogno di una manutenzione regolare, per lo più infrastrutturale, ad esempio cavi elettrici difettosi o bagni che perdono. Questi problemi devono essere affrontati di volta in volta.
Come puoi vedere ormai, le fasi della gestione del progetto di sviluppo delle cascate sono distinte e, sebbene di solito vi sia una costante interazione con il cliente, si tratta principalmente di discutere sullo stato di avanzamento del progetto, non sulla progettazione o sui requisiti. Tuttavia, il modello di gestione dei progetti a cascata ha servito adeguatamente l'industria IT per molti anni e, per la maggior parte dei progetti, le fasi sono ancora valide, sebbene non così rigide.
Vi sono, tuttavia, diversi progetti per i quali il modello di gestione del progetto Waterfall è molto adatto.
A che tipo di progetto è adatto Waterfall Project Management?
Definizione del prodotto:
Innanzitutto, il risultato finale (prodotto) deve poter essere ben definito all'inizio stesso. I progetti in cui il proprietario del prodotto non è molto sicuro delle specifiche esatte del prodotto desiderato possono seguire bene le pratiche di gestione agile.
Documentazione:
Il progetto dovrebbe essere uno che può essere documentato. La documentazione è un requisito importante del modello di gestione del progetto Waterfall. I requisiti del prodotto, il design e il codice sorgente devono essere chiaramente documentati in tutte le fasi. Se i membri originali del team si ritirano, questo costituisce la guida per la continuità del progetto.
Tempo e risorse:
Non ci deve essere urgenza immediata per rilasciare il prodotto. Le tempistiche sono fissate all'inizio del progetto e il team deve essere in grado di aderire ad esse. Inoltre, devono essere disponibili ampie risorse in termini di manodopera e tecnologia.
Rischio e incertezza:
Waterfall Project Management Tools non funziona bene in un ambiente di rischio e incertezza. Ad esempio, l'app per dispositivi mobili è un tipo di prodotto che deve affrontare incertezze in termini di accettazione da parte dei clienti e concorrenza di app simili.
Fasi chiaramente definite:
Le fasi del sistema dovrebbero essere ben definite in quanto devono essere completate in sequenza e non possono esserci sovrapposizioni.
Quando viene creata una nuova versione del software esistente.
Al di fuori del dominio IT, il modello di gestione del progetto Waterfall è stato utilizzato con successo in grandi progetti come
- Costruzione dell'aeroplano
- Progetti infrastrutturali come i ponti
- Produzione di attrezzature per la difesa
- Sistemi di assistenza sanitaria negli ospedali
Nei progetti IT, Waterfall Project Management è particolarmente adatto a quei progetti in cui è richiesto hardware esterno. Le specifiche di questo non possono essere modificate a metà poiché ciò comporterebbe una perdita di milioni di dollari.
Quando le inadeguatezze nel Waterfall Project Management sono diventate evidenti nel settore del software, si è pensato molto a come i team IT possano offrire il massimo valore ai clienti garantendo al contempo flessibilità nel processo del flusso di lavoro.
E così nacque l'Agile Project Management System, che ora viene adottato dalla maggior parte delle società di software.
Waterfall Project Management vs Agile Systems:
Il sistema di gestione dei progetti Agile è un modello flessibile che è diventato popolare negli anni '90. Implica la suddivisione del progetto in "mini progetti" chiamati sprint e il lavoro indipendente su ciascuno di essi. Questo tipo di modello consente agli sviluppatori di incorporare più rapidamente le modifiche richieste ed è molto efficace laddove l'ambiente del cliente è variabile.
Gli aspetti positivi delle fasi di gestione del progetto Waterfall sono:
- Poiché il prodotto finale è noto nella sua interezza, la pianificazione e la progettazione sono inequivocabili.
- I potenziali problemi che potrebbero sorgere nel progetto possono essere risolti durante la fase di progettazione stessa; prima che sia stato scritto qualsiasi codice.
- Misurare l'avanzamento dei lavori è facile poiché le fasi sono ben definite.
- La stabilità del team è presente poiché il team rimane fino alla fine del progetto. Nel caso di Agile, il team cambia costantemente e ciò richiede un certo aggiustamento.
- La documentazione è ampia, facilitando la gestione dei team in caso di partenza di un membro.
- Gli sviluppatori trovano questo modello più facile da lavorare in quanto è facile da capire,
- Dopo la fase Requisiti, la partecipazione attiva del cliente finale è necessaria solo nella fase di test. Questo perché tutti i requisiti sono stati discussi logori, senza lasciare ambiguità.
- Il prodotto può essere sviluppato nel suo complesso, invece di svilupparlo in parti.
- Le problematiche relative alla gestione dei contratti e dei clienti vengono gestite meglio nel modello di gestione del progetto Waterfall.
Gli aspetti positivi di Agile Project Management sono:
- Il cliente può interagire con il team di progetto durante l'intero ciclo e può apportare di volta in volta modifiche al prodotto per adattarsi all'ambiente in evoluzione.
- Se il prodotto deve essere rilasciato molto presto a causa di circostanze di mercato, il team di Project Management Agile può rilasciare una versione di base che può avere versioni avanzate in un secondo momento.
- Il sistema è abbastanza trasparente dal punto di vista del cliente e ha una buona idea della fase in cui si trova il suo prodotto.
- Poiché il cliente fornisce la priorità delle funzionalità, il team sa che deve concentrarsi sulle funzionalità che offrono il massimo valore per l'azienda.
- Il processo ha il suo slancio.
- I team sono fluidi e flessibili, consentendo l'ideazione di ogni membro
- La documentazione è minima e quindi il tempo viene liberato da tali compiti.
Dopo molti anni di entrambi i modelli esistenti fianco a fianco, è evidente che:
Il modello di gestione del progetto Waterfall è efficace per la gestione del progetto in cui una volta completato il progetto, ci sono cambiamenti minimi.
Agile Project Management è più adatto alla gestione dei prodotti in cui è importante essere flessibili ai cambiamenti.
Indipendentemente da ciò, il sistema di gestione del progetto Waterfall rimane una componente importante della maggior parte dei progetti IT. Non si può dire con certezza che un particolare progetto segue rigorosamente le pratiche di gestione agile. Di solito è che i principi Agile sono "incorporati" nei progetti IT.
Alcuni Agile Project Management hanno Project Manager mentre rigorosamente un modello Agile ha solo Scrum Masters. Si tratta di combinazioni ibride di modelli di gestione dei progetti Agile e Waterfall che alcuni chiamano progetti "Agifall" o "Agency Agile".
La popolarità del sistema di gestione del progetto Waterfall è anche dovuta al fatto che i problemi di gestione del contratto e dei clienti sono gestiti meglio dai metodi di gestione del progetto Waterfall.
Mentre sempre più progetti rientrano nel gruppo Agile Project Management e sempre più aziende vedono i vantaggi di un modello di gestione flessibile, la popolarità del modello di gestione del progetto Waterfall sta scemando.
Tuttavia, è difficile immaginare un futuro per i progetti IT completamente agili, nel prossimo futuro. E Waterfall Project Management, che ha aiutato l'industria del software fin dalla sua infanzia, vivrà in alcuni componenti della gestione del progetto almeno per qualche altro anno a venire.
Prima fonte di immagini: picjumbo.com
articoli Correlati
- 6 fasi utili del flusso di lavoro nella gestione dei progetti delle cascate
- Suggerimenti efficaci per la discussione di gruppo (consulenza di esperti)
- Primi 10 miti sulla gestione dei progetti eliminati
- 6 buoni motivi per cui tutti hanno bisogno di un progetto di passione sul lavoro
- Primi 5 tipi di strumenti di reporting per la gestione dei progetti
- Gestione del prodotto e gestione del marchio - Differenze utili