Immagina un progetto in cui l'interfaccia da consegnare è stata bloccata del 90% e sei già in possesso di un solido progetto architettonico. Una metodologia agile offrirebbe ancora un valore in questa situazione?
Mi sembra che le metodologie agili (e sto pensando a Scrum), offrano il massimo valore dove c'è un alto grado di incertezza sui requisiti.
Would an agile methodology still offer any value in this situation?
Sì.
It seems to me that agile methodologies (and I'm thinking Scrum), offer most value where there is a high degree of uncertainty about the requirements.
Anche vero.
Ecco il punto. Agile è uno stile di vita. Leggi il Agile Manifesto alcune volte.
Non è vietato bloccare l'interfaccia. Non ti viene impedito di utilizzare un solido progetto architettonico.
Sei incoraggiato a interagire, creare software, collaborare e rispondere ai cambiamenti.
Non ti è proibito fare lavori di progettazione.
Il punto è evitare processi iper-complessi, pignoli e procedure per il controllo dei cambiamenti. Evita il lavoro impegnativo di scrivere specifiche lunghe e dettagliate quando una conversazione farebbe.
Agile potrebbe sicuramente offrire ancora un valore, anche se potrebbe non valere la pena cambiare se quello che stai già facendo sta funzionando bene.
Agile offre molto valore in situazioni in cui le priorità non sono chiare o cambiano frequentemente, ma trovo che abbia anche altri vantaggi. Trovo che i metodi Agile tendano a migliorare il morale dello sviluppatore (se usato correttamente), a ridurre i processi non necessari e ad aumentare la comunicazione sia all'interno del team di sviluppo che tra il team di sviluppo e i titolari di aziende. L'aumento della comunicazione, IMO, è il più grande vantaggio per Scrum / Agile, in quanto ciò porta a una migliore gestione dei rischi ea processi più efficienti.
Penso che il maggior rischio sia che Scrum faccia qualche scatto per funzionare senza problemi. Scrum fa molto affidamento sulla capacità degli sviluppatori di fare delle buone stime, e questa è un'abilità appresa. Inoltre, la maggior parte delle squadre ha bisogno di aggiustare le regole un po 'prima che funzioni bene per loro. Scrum fornisce un ottimo processo per questo attraverso le retrospettive, ma i primi due o cinque sprint possono essere un po 'scoraggianti. Dopodiché, ho visto in genere i team riprendere in modo significativo e aumentare notevolmente la loro efficienza.
L'idea che i requisiti possano essere bloccati all'inizio del progetto è esattamente il motivo per cui, in primo luogo, è nata l'agilità. Un'idea agile fondamentale è che il cliente / utente non può sapere cosa vuole realmente, finché non può effettivamente vedere e utilizzare il software. L'approccio agile è quello di rilasciare il più presto e spesso il più possibile e ottenere un feedback reale e adattare il tuo progetto da quello.
Se i requisiti del tuo progetto sono veramente "bloccati", perdi gli ovvi benefici dei primi rilasci. Continuo a pensare che l'utilizzo agile sia comunque utile in questo caso, perché può davvero aiutarti a gestire le brutte fasi di integrazione e test (utilizzando l'integrazione continua e test automatici per esempio).
Agile ha un grande vantaggio - impedisce "Paralisi sull'analisi"
Ti costringe a codificare qualcosa (prima le caratteristiche essenziali) e farlo funzionare e poi e solo dopo puoi ridimensionare e continuare con altre funzionalità.
L'essenziale è non preoccuparsi di cosa potrebbe accadere, perché quando accadrà avrai "qualcosa" e le tue decisioni saranno molto più semplici.
Leggi altre domande sui tag project-management agile scrum