Implementazione di modifiche di sistema di grandi dimensioni [chiuso]

Question

Se hai familiarità con la frase "costruirne uno da buttare via", beh, sembra che l'abbiamo fatto;stiamo raggiungendo i limiti della versione 1 della nostra app online.È tempo di fare pulizia:

• Riorganizzazione del codice e dell'interfaccia utente
• Unificazione dei processi dell'interfaccia utente
• Aggiunta di più funzionalità
• Costruire per il futuro
• Modificando la struttura del nostro database per gestire tutto quanto sopra

Qual è il modo migliore per realizzare questa transizione?

Vogliamo evitare di gettare tutti i nostri utenti su un nuovo sistema (una volta terminato)...impazzirebbero e non potremmo gestire il carico di chiamate.I nostri utenti spaziano da quelli tecnicamente competenti che usano software per scrivere a quelli che non sanno cosa sia l'HTML.

Dovremmo iniziare una nuova "installazione" del nostro sistema e spostare gradualmente gli utenti su di essa dopo esserci assicurati che questo nuovo design risolva sufficientemente i problemi con la versione 1?

Dovremmo (in qualche modo) modificare ogni modulo del nostro sistema in modo incrementale e fase?Questo potrebbe essere difficile perché il layout del database cambierà, con il risultato di dover modificare il "codice principale" e il codice per diversi moduli circostanti.

È comune avere una serie di clienti fidati, pazienti e "beta tester" che utilizzano una versione all'avanguardia di un'app?(L'obiettivo qui sarebbe ottenere feedback e testare i bug su un nuovo sistema)

Qualche altro consiglio?Esperienza di prima mano?

Answer 1

La risposta, temo, è che dipende.Dipende dal tipo di applicazione e dal tipo di utenti che hai.Senza sapere quale sia il sistema e la portata delle modifiche apportate alla versione, è difficile offrire una risposta.

Detto questo, ci sono alcune regole pratiche.

In primo luogo, evitare il lancio del big bang.Qualsiasi lancio di un sistema avrà problemi.L'industria è disseminata di progetti in cui la gente pensava che il lancio bang-bang fosse una grande idea, solo per problemi iniziali che hanno messo in ginocchio il lancio. Cuil è stata una recente causalità di alto profilo del lancio del big bang.

Per rendere gestibili i problemi iniziali, è necessario lavorare inizialmente con un numero limitato di utenti, per poi aumentare lentamente il numero di utenti.

In secondo luogo, la cosa che devi assolutamente fare è mettere l'utente al primo posto.L'utente dovrebbe svolgere il minor lavoro possibile per utilizzare la V2 del sistema.La quantità di lavoro ideale sarebbe zero.

Ciò significa che se scegli di migrare lentamente gli utenti da un sistema all'altro, Voi sono responsabili di assicurarsi che tutti i loro dati e le impostazioni vengano migrati.Ad esempio, non fare nulla di stupido come dire all'utente che deve utilizzare la V1 per tutti i record prima del 09/12/2008 e la V2 per tutti i record successivi.

Lo scopo del rilascio della V2 dovrebbe essere quello di rendere la vita degli utenti più semplice, non renderla inutilmente più difficile.

In terzo luogo, avere un programma beta.Ciò vale anche per le applicazioni Intranet.Lo sviluppo di un'applicazione è molto simile al metodo di Newton-Raphson per trovare la radice di un polinomio.Indovini ciò che l'utente desidera, lo consegni all'utente, l'utente fornisce feedback e lentamente ma inesorabilmente ogni iterazione ti avvicina alla soluzione del problema.

Un programma beta ti aiuterà a trovare il root molto più velocemente che semplicemente imponendo nuove versioni alle persone senza tempo per commentare le modifiche.Le beta aiutano a coinvolgere i tuoi utenti prima e a farli sentire inclusi nel processo;la cui importanza non potrò sottolineare abbastanza.

Answer 2

Abbiamo appena finito di implementare un nuovissimo sistema CRM per i nostri utenti e lascia che ti dica che è stata un'idea TERRIBILE farlo in questo modo:È stato estremamente doloroso per il mio team e per i nostri clienti.

Utilizzerei ogni mezzo possibile per effettuare rilasci graduali, anche se ciò significa fare più lavoro.Sarai grato perché non dovrai compiere sforzi eroici per spostare tutto e i tuoi clienti apprezzeranno la possibilità di presentare il prodotto un po' alla volta.

Spero che aiuti!

Answer 3

Sono d'accordo con Esteban che i rilasci graduali sono i migliori.È come ristrutturare una casa:farla finita sembra inizialmente una buona idea.Ma significa che devi pianificare tutto in anticipo, assumere un gruppo di appaltatori e trasferirti.Poi qualcosa cambia nel piano o un appaltatore scompare e tutto il tempo che speravi di risparmiare se ne va.Nel frattempo, il cambiamento graduale offre a tutti la possibilità di fermarsi e pensare tra un passo e l’altro.A volte puoi evitare modifiche successive quando le modifiche precedenti funzionano meglio di quanto pianificato.

Lavoro su un sistema che presentava un enorme problema di ridimensionamento.Abbiamo stilato un elenco di tutti i cambiamenti che ritenevamo necessari e abbiamo dato loro la priorità in base al probabile impatto.Poi abbiamo iniziato a fare un cambiamento alla volta.Circa a metà dell'elenco, abbiamo scoperto di aver risolto il problema del ridimensionamento.Ho ancora la lista, ma forse non avrò mai bisogno di finirla.Sono libero di aggiungere funzionalità e risolvere altri problemi.

Naturalmente, ci sono momenti in cui è meglio stringere i denti e demolire tutto.Ma questo è molto meno comune di quanto la gente tende a credere.E per i sistemi operativi critici, la decisione di “smontare” può essere fatale.Consideriamo i grandi progetti governativi che tutti concordano debbano essere portati nell’era informatica moderna, ma che non è possibile perché alcuni servizi vitali andrebbero persi.Se la filosofia fosse stata un cambiamento graduale, forse si sarebbero modernizzati un pezzo alla volta.

Answer 4

Suona come riarchitettura incrementale dovrebbe essere la tua agile frase preferita.

Non l'ho mai fatto su un'applicazione web, ma ho subito alcune modifiche piuttosto radicali all'applicazione client che sono state eseguite in modo incrementale.Se investi un po' di tempo in anticipo per assicurarti che i pezzi di lavoro siano sequenziati in modo abbastanza sensato, può funzionare bene.Un piccolo investimento in buoni aiuti per il refactoring sarà molto utile se non li hai già.Posso consigliare personalmente jetBrains Resharper se utilizzi .NET e se sei basato su Java, credo che IntelliJ IDEA includa funzionalità simili.