È un errore dire che le migrazioni di sistema non si adattano ad una metodologia agile come i requisiti sono noti in anticipo?

Sì, è un errore.

Ciò che il tuo manager chiama: "i requisiti sono noti in anticipo" rientra nella categoria Pianificazione predittiva . " Sappiamo cosa fare, quindi ci vuole solo per assegnare compiti alle persone e attenersi alla pianificazione ".

Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan.

Martin Fowler -Co-author of the Agile Manifesto-

Ma non significa che non si verificheranno cambiamenti .

AgileandFluencydiMartinFowler-Barcelona2017

Potrebberoessercicambiamentineirequisitiosolocambiamentidipriorità.Potrebberoessercicosìtantecosechepossonoandarestorteocambiareduranteilprocessodisviluppo.AmenocheiltuoManagernonguidiunDeLoreanconuncondensatorediflusso,nonpuòassicurartichenoncisarannocambiamenti.

UnodegliscopidiAgileèdiessereingradodiadattarsiaicambiamenti.Seliaspettiamoono.Nonpotendoadattarciaicambiamenti,questipossonocomportarecostidiopportunitàperilcliente.

Agileplansareabaselinethatweusetohelpuscontrolchange.Agileteamsplanjustascarefullyastraditionalteams,buttheplansareconstantlychangingtoreflectthethingswelearnduringaproject.Successisbasedonvaluedeliveredbythesoftware.

MartinFowler-Co-authoroftheAgileManifesto-

PotrebberoessercialtrimotivipernonpraticareAgile,maquelloquiindicatononèvalido.

"The only constant in the Universe is change".

Heraclitus

Successivamente modifica

L'industria del software ha tentato senza successo di imitare i processi di produzione tipici di altri settori con una storia più lunga.

Queste industrie hanno perfezionato il loro piano di produzione nel corso dei decenni e alcune di esse nel corso dei secoli. Questi sono arrivati a un punto in cui è possibile per loro ridurre l'incertezza dei cambiamenti quasi all'insignificanza. Ad un costo Hanno rimosso dal piano qualsiasi influenza umana sul processo.

Questo non è possibile per noi da fare al momento. Il software di oggi è ancora realizzato da persone per le persone.

Se il processo è stato perfezionato fino all'industrializzazione o no, nulla sfugge ai cambiamenti. Nel complesso, quando entra in gioco il fattore umano.

La tua domanda contiene una dichiarazione più audace rispetto a quella del gestore quotato.

Il gestore indicato afferma che non è necessario, come se richiederebbe un investimento maggiore per realizzare un progetto agile rispetto a un progetto non agile. Sembra che non gli dispiacerebbe andare agile, crede solo che i costi extra non ne valga la pena. Che solleva domande. Forse non hanno mai agito prima e si aspettano dei costi di adattamento.

Ma agile non significa solo rispondere a requisiti nuovi o mutevoli, quindi l'affermazione citata non ha senso.

Sì. L'insieme di tutti i requisiti non è mai conosciuto all'inizio di un progetto. Dicendo con orgoglio che non stanno usando una metodologia agile, è come se dicessero "Rifiutiamo la possibilità di dover adattare il nostro piano e faremo del nostro meglio per resistere al cambiamento del nostro piano."

Il potenziale danno che questa linea di pensiero causerà dipende dalla dimensione della migrazione.

Dipende. Esistono molti tipi di migrazione.

In molti casi, migrerai da un'applicazione completamente funzionale a un'altra applicazione pienamente funzionante. Dato che la nuova applicazione è un'applicazione completamente funzionale, i requisiti funzionali sono completamente noti - dopo tutto, qualcuno ha costruito la cosa.

Lo sforzo di migrazione riguarda principalmente la conversione delle strutture del database in base alla nuova applicazione. L'obiettivo è un evento big bang in cui la vecchia applicazione viene ritirata e tutti gli utenti vengono indirizzati alla nuova applicazione.

In questo caso, sarebbe piuttosto difficile inserirlo in un approccio agile o iterativo. C'è solo una versione. I dati devono essere convertiti tutti in una volta, durante la finestra go-live.

Quindi, mentre si possono avere diverse sessioni a secco, ognuna delle quali produrrà rapporti di fallout (dati che non possono essere convertiti), alla fine non c'è software funzionante fino alla fine. Ciò è in contrasto con l'idea agile che si stanno apportando piccole modifiche in un modo in cui ogni versione è un prodotto funzionale con un sottoinsieme di funzionalità.

In altri casi, potresti avere due applicazioni in esecuzione in parallelo e convertire i moduli uno alla volta. Ad esempio, se si esegue la conversione da Clearquest e Subversion a TFS, è possibile migrare il codice in una volta sola, quindi migrare i difetti, quindi eseguire la migrazione delle attività. Si potrebbe prima elaborare un sistema di identità federato per consentire a un utente di passare agevolmente da un'applicazione all'altra, quindi configurare il sistema di menu in modo che punti a software diversi a seconda di ciò che è stato convertito nel momento attuale. Probabilmente questo potrebbe essere affrontato in modo agile.

In altri casi, non stai realmente migrando ma ri-implementando. Ad esempio, se si sta eseguendo la migrazione da un'applicazione personalizzata a un'altra applicazione appena acquistata e un'analisi delle lacune ha dimostrato che è necessario personalizzare anche la nuova applicazione. In questo caso il progetto potrebbe essere Agile, perché stai ri-implementando le funzionalità man mano che vai.

Non direi che la dichiarazione è fallace senza sapere di più su cosa sia il progetto. In una banca, se stanno migrando il loro host principale, sarebbe sicuramente un evento big bang, a causa dei requisiti di integrità dei dati: un conto bancario non può avere due registri principali oppure si verificheranno seri problemi di contabilità. Ma se stanno mantenendo il loro ospite ma stanno cambiando un paio di siti web rivolti ai clienti, potrebbe essere concepito in fasi successive. Inoltre, è molto probabile che uno di questi stadi sia troppo grande per adattarsi a ciò che è in genere pensato come un'iterazione.

Se il tuo manager suppone che la migrazione verrà eseguita in passaggi definiti da serie di modifiche nelle versioni vecchie e nuove, mentre entrambi rimarranno funzionanti, testabili e comparabili dopo ogni passaggio, è agile, anche se non lo fa conoscilo e non usare SCRUM.

Se vuole apportare tutte le modifiche in un enorme passo e dopo che inizia a testarlo, sembra più un suicidio che un errore.