Il nostro team ridisegna il software legacy e ci sono un sacco di incontri di design in corso. Molti di questi non sono molto efficaci e mancano di una buona analisi del progetto proposto. Esiste un modo formale per affrontare questo tipo di discussioni per renderle più efficaci? Ho sentito parlare di SWOT, ad esempio, ma a quanto pare è usato di più per i progetti di business.
Potrei suggerire l'agile, se eretica, di Martin Fowler, StranglerApplication , un metodo che ricorda uno di BranchByAbstraction .
Quello che probabilmente vorrai è definire un insieme di interfacce che parlino la tua storia aziendale, ignorando il codice esistente, collegandole con una riscrittura minima e poi lentamente reimplementando sempre più di queste interfacce. La formalità nel processo finisce lì, ma spero che la sua praticità sia ovvia.
Suppongo che tu voglia che il sistema ridisegnato si comporti esattamente come il sistema legacy, almeno all'inizio. Ciò significa che è necessario acquisire i concetti e il comportamento del sistema legacy prima nel modo più preciso possibile. Raccomando di creare modelli di architettura e usarli per la discussione. Tutti dovrebbero avere una buona conoscenza del linguaggio di modellazione che si usa.
Scopri la metologia che utilizziamo in SAP, che è descritta in questo post del blog in 2 parti: link
Non creare solo i diagrammi a blocchi. Consiglio di iniziare con i diagrammi delle relazioni di entità e aggiungere anche le definizioni delle entità. Quindi fai i diagrammi a blocchi - non dimenticare di descrivere i limiti del protocollo e aggiungi una breve descrizione di cosa fa ogni blocco. L'ultima cosa dovrebbe essere uno dei diagrammi dinamici. Usa gli altri tipi di diagramma se ne hai bisogno.
Ciò che sperimenterai sono vivaci discussioni, ad es. se esiste una relazione 1: * o 1: 0 .. * tra due entità. Oppure imparerai molto sulle dipendenze tra i componenti se cerchi di capire dove potresti stabilire un limite di sistema, e così via.
Se utilizzi disegni di powerpoint vaghi della tua architettura di sistema legacy, ognuno avrà la sua interpretazione e comprensione, quindi non farai molti progressi e il tuo nuovo sistema probabilmente non rifletterà il sistema legacy.
suggerimento di Mihai Danila di applicare Fowler's StranglerApplication in sostituzione della tua app legacy è a mio parere il modo migliore per sostituire qualsiasi sistema legacy.
Ho scritto un blogger un paio di anni fa su non riscrivo mai un sistema . Fondamentalmente come Strangler Application si tratta di inserire facciate trasparenti di fronte alle interfacce ai sistemi esistenti e di incrementare progressivamente questo reindirizzamento al nuovo sistema fino a quando il vecchio sistema non è più in uso.
E non riscrivere mai l'intero sistema in un colpo solo, perché ciò richiederà troppo tempo senza alcun vantaggio commerciale almeno per un lungo periodo. È necessario fornire valore per il business insieme alla sostituzione del sistema legacy esistente.
Per quanto riguarda le stime effettive, è possibile applicare molte stime dettagliate in termini di tempo utilizzando varie tecniche. Comunque saranno tutti sbagliati come un dito nella stima aerea, proprio ora sbagliato nei dettagli come direbbe Dan North .
Crea un po 'di epop con priorità di quali funzionalità sono necessarie inizialmente, suddividili ulteriormente se necessario ma non molto di più. Quindi calcola le stime di ordine di grandezza di varie parti del lavoro (t-shirt taglie, 1-10-100 punti storia o giorni o qualsiasi altra cosa). Applicare StranglerApplication e quindi fornire alcuni racconti per i bollettini traccianti per avere un'idea molto migliore della complessità e della fattibilità effettive del progetto.
Prova a tornare alle basi:
Gli incontri inefficaci sono un segno di mancanza di scopo e impegno. Le riunioni dovrebbero avere un chiaro obiettivo e impegno da parte di coloro che la raggiungono. Per alcuni dei migliori esempi di come organizzare un incontro, guarda agli sport professionistici. Sono alcuni dei migliori incontri gestiti nel mondo (puntualità, partecipazione al 100% da parte dei partecipanti, impegno, impegno, regole chiare e risultati). Dove possibile prova a emularlo.
La mancanza di una buona analisi normalmente fa fatica a capire il problema. Se non stai affrontando la causa principale del problema, non stai veramente creando una soluzione. E se non stai creando una soluzione, stai solo creando un altro problema.
C'è un sacco di processi, metodologie e diagrammi per aiutare con questo processo. OpenUP non è un brutto posto dove guardare la documentazione metodologica, se non l'hai fatto prima. Questo dovrebbe almeno fornire alcune strutture e modelli per implementare alcuni dei precedenti. Un'altra risorsa a cui mi trovo di nuovo è Alistair's Awesome guida a praticamente tutto. Con quelli e il resto di Internet a portata di mano , sarai pronto per iniziare
Leggi altre domande sui tag design