È appropriato eseguire una configurazione complessa e un progetto di migrazione del sistema aziendale in modo simile a un progetto di sviluppo Scrum?

1

Sto appena iniziando l'implementazione di un grande sistema aziendale, che ha requisiti complessi e molte parti interessate.

L'azienda è stata sottoposta a valutazioni e procedure di gara di alto livello e ha deciso di acquistare un prodotto "off-the-shelf" altamente configurabile anziché costruire un sistema interamente su misura. Il sistema sostituirà diversi sistemi esistenti e richiederà una notevole quantità di migrazione dei dati.

Penso che l'implementazione di questo sistema (che dovrebbe richiedere più di 2 anni) potrebbe essere eseguito in modo simile a un progetto di sviluppo software Scrum.

Con i primi sprint mirati a costruire le funzionalità minime possibili necessarie (attraverso tutte le aree funzionali), e quindi approfondire iterativamente il livello di funzionalità in base al feedback degli stakeholder. Penso che questo rischierà di compromettere il progetto e contribuire a garantire un equilibrio tra le esigenze delle parti interessate entro il tempo disponibile.

Le storie degli utenti sono sempre le stesse, è solo che per implementarle abbiamo lavorato entro i limiti del sistema pre-acquistato. Quando si tratta di "costruire cose", invece di scrivere codice personalizzato, il team configurerà il pacchetto standard, scrivendo script di conversione dei dati e simili (e dovrebbe essere molto più veloce!).

Questo suona come un approccio ragionevole? L'approccio Agile ha senso qui?

    
posta AndyM 24.11.2012 - 11:13
fonte

2 risposte

2

Come AlexBottoni ha già menzionato SCRUM può essere usato perché anche la personalizzazione è lo sviluppo del software.

Ma per il tuo approccio a fare diversi sprint nella creazione di funzionalità di base è il modo sbagliato. Prendi uno dei sistemi esistenti e sostituiscilo con la nuova soluzione. Questo dovrebbe essere fatto solo in pochi sprint. Seleziona solo alcuni racconti utente all'inizio da implementare. Quando viene sostituito il primo sistema, prendi il secondo. Non provare a sostituire tutto in una volta perché è più probabile che fallisca. Anche se sembra costare più tempo, vale la pena sostituire un sistema dopo l'altro. Inoltre, la gestione vedrà più rapidamente ciò che verrà acquisito.

Se impieghi due anni per sostituire tutto, i sistemi attuali verranno ulteriormente sviluppati e avrai un obiettivo mobile ...

    
risposta data 24.11.2012 - 12:25
fonte
2

Nonostante l'uso di un prodotto standard, questo è un progetto di sviluppo software e dovrà essere eseguito di conseguenza (con SCRUM, Agile e / o altre metodologie).

Come hai detto, dovrai scrivere script di migrazione, file di configurazione e così via. Questo è lo sviluppo del software. Qualsiasi altra cosa.

Dovrai utilizzare un sistema di controllo del codice sorgente come GIT, Hg, Subversion o CVS. Dovrai tenere traccia dei bug e delle funzionalità richieste. Dovrai documentare ciò che stai sviluppando. Dovrai testare il tuo sistema.

Questo è solo "sviluppo software", quindi il tuo approccio è più che ragionevole. È obbligatorio.

Lo sviluppo agile produce quasi sempre (almeno un po ') senso. A volte deve essere usato insieme ad altre metodologie (più formali) ma è quasi sempre un buon punto di partenza.

    
risposta data 24.11.2012 - 12:09
fonte