Sì ... If ...
Dirò solo sì se riesci a eliminare le funzionalità dal tuo progetto per raggiungere la scadenza.
Altrimenti riceverai solo una parte dei benefici da un approccio Agile.
Le scadenze arbritrarie non funzionano
Timescales are tight, and reputations have been staked on delivering on time.
Questo mi preoccupa, questo sa di una scadenza arbritraria creata dall'ottimistica migliore analisi delle ipotesi. Le scadenze arbritrarie non funzionano, e in effetti si è dimostrato che funzionano a detrimento di un progetto.
Joel Spolsky ha scritto un grande saggio su Pianificazione basata sull'evidenza
3) Simulate the future
Rather than just adding up estimates to get a single ship date, which sounds right but >gives you a profoundly wrong result, you’re going to use the Monte Carlo method to >simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible >scenarios for the future. Each of these possible futures has 1% probability, so you can >make a chart of the probability that you will ship by any given date.
Preparati a eliminare le funzionalità per risparmiare tempo
Mettere quella parte con un periodo di tempo prefissato per un progetto Agile va bene, tuttavia è necessario essere in grado di dare la priorità alle funzionalità più importanti nel prodotto software e quindi eliminare le funzionalità non così preziose per raggiungere il traguardo temporale.
Questo dovrebbe accadere ogni singolo sprint, le uniche funzionalità che vengono unite in un "rilascio" alla fine di uno sprint sono funzionalità completamente testate e funzionanti. Le funzionalità non completamente testate e funzionanti vengono lasciate cadere per il prossimo sprint o il prossimo "rilascio". Release non significa deliverable per il cliente, ma dopo ogni sprint hai un prodotto software pienamente funzionante (sebbene in modo limitato) completamente testato.
Utilizza le migliori funzionalità di Agile
L'idea di usare agile è che le tue caratteristiche tra gli sprint non sono impostate in pietra. In un normale progetto agile il cliente ha inserito ogni sprint e può richiedere l'aggiunta di una nuova funzionalità come priorità più alta rispetto a una funzione richiesta 3 sprint fa.
Evita una gara del progetto (se possibile)
Nel tuo caso questo probabilmente non succederà, hai già la funzione definita nei tuoi progetti esistenti, e inoltre sembra che tu abbia una condizione di gara in cui gareggerai attuale ciclo di manutenzione per i progetti esistenti con il nuovo progetto in modo da poterlo sostituire.
If you have been a programmer for more than two or three years, you
have probably been significantly slowed down by someone else’s messy
code. If you have been a programmer for longer than two or three
years, you have probably been slowed down by your own messy code. The
degree of the slow-down can be significant. Over the span of a year or
two, teams that were moving very fast at the beginning of a project
can find themselves moving at a snail’s pace. Every change they make
to the code breaks two or three other parts of the code. No change is
trivial. Every addition or modification to the system requires that
the tangles, twists, and knots be “understood” so that more tangles,
twists, and knots can be added. Over time the mess becomes so big and
so deep and so tall, they can not clean it up. There is no way at all.
As the mess builds, the productivity of the team continues to
decrease, asymptotically approaching zero. As productivity decreases,
management does the only thing they can; they add more staff to the
project in hopes of increasing productivity. But that new staff is not
versed in the design of the system. They don’t know the difference
between a change that matches the design intent, and a change that
thwarts the design intent. Furthermore, they, and everyone else on the
team are under horrific pressure to increase productivity. So they all
make more and more messes, driving the productivity ever further
towards zero.
Eventually the team rebels; and they inform management that they
cannot continue to develop in this horrific code base. They demand a
redesign. Management does not want to expend the resources on a whole
new redesign of the project, but they cannot deny that productivity is
terrible. Eventually they bend to the demands of the developers, and
authorize the grand redesign in the sky.
A new tiger team is selected. Everyone wants to be on this team
because it’s a green-field project. They get to start over and create
something truly beautiful. But only the best and brightest are chosen
for the tiger team. Everyone else must continue to maintain the
current system.
Now the two teams are in a race. The tiger team must build a new
system that does everything that the old system does. Not only that,
they have to keep up with the changes that are continuously being made
to the old system. Management will not replace the old system until
the new system can do everything that the old system does, on the day
of the change.
This race can go on for a very long time. I’ve seen it take 10 years.
And by the time it’s done, the original members of the tiger team are
long gone, and the current members are demanding that the new system
be redesigned because it’s such a mess.
If you have experienced even one small part of the story I just told,
then you already know that spending time keeping your code clean is
not just cost effective; it’s a matter of professional survival.
Un'alternativa: ripulisci l'architettura esistente
Robert Martin come citato sopra esprime un'alternativa a un progetto di riscrittura nel suo discorso sull'artigianato del software. Se non l'hai visto prima, vale la pena guardarlo fino in fondo.
Ho anche raccomandato alcuni metodi per eseguire un refactoring graduale anziché una riscrittura completa nella mia risposta a una domanda simile.
Guida introduttiva
In passato ho avviato grandi progetti greenfield (ovviamente non era anche SOA). Ho scoperto che la prototipazione iniziale dell'architettura e l'assestamento del framework richiedevano un po 'di tempo in cui potevo riprogettare il mio approccio, cancellare le mie idee una mezza dozzina di volte mentre prototipo e testavo teorie e le migliori pratiche di progettazione.
Non perdere tempo a scrivere le specifiche che verranno eliminate solo
Utilizzare un design all'avanguardia per una nuova architettura significa perdere tempo e fatica, quindi è essenziale adottare un approccio agile dei requisiti e delle specifiche funzionali su un documento di specifiche complete per non sprecare tempo e buttare via idee sbagliate che sembravano carta ma non ha funzionato nella vita reale.
Prototipazione iniziale
Questa fase iniziale di prototipazione che ho trovato in genere non produce nulla che sia consegnabile al cliente fino a quando non sia effettivamente finito e funzionante. Tuttavia ciò che dovresti alla fine dovrebbe essere un'architettura ben congegnata, con moduli facilmente configurabili e il refactoring delle applicazioni esistenti nella nuova architettura dovrebbe prestarsi abbastanza facilmente a una metodologia agile con i risultati visibili dei clienti.
Seguito da un aumento di velocità
Una volta che il tuo prototipo è terminato e la tua architettura sistemata, scoprirai che avrai un periodo di transizione in cui dovrai istruire il resto del tuo team sul modo migliore per migrare o rifattorizzare i tuoi progetti esistenti per adattarli al nuovo quadro.
Quindi puoi aspettarti una velocità di accelerazione lenta seguita da una maggiore velocità in prossimità della fine del progetto quando avrai più sviluppatori online e implementerai il tuo progetto.