L'agile può essere efficacemente utilizzato per lo sviluppo iniziale su un progetto sostanziale?

5

Penso che la risposta breve a questa domanda sia probabilmente "sì", ma ho pensato di chiedere comunque!

Siamo in procinto di adottare un numero di applicazioni simili simili ma diverse e, come parte di ciò che per noi è forse il più grande progetto di sviluppo di sempre, tentare di sostituirle e qualsiasi successiva, simile ma diversa applicazione con un sistema super configurabile super-arcuato per dominarli tutti. Mi aspetto che la sindrome del secondo sistema complicato ci dia molti problemi nel consegnare il colosso in primo luogo, ma non voglio che la nostra scelta metodologica peggiori le cose. Ci siamo dilettati in modo agile, da qualcosa per lo più a cascata, ma questo sarebbe stato il nostro primo progetto sostanziale utilizzando una nuova metodologia migliorata.

Abbiamo grandi piani per il nuovo sistema e, anche se non tutti devono essere consegnati in una volta dovremo implementare grandi quantità di esso dalla parola prima per consentire di dare qualsiasi cosa al cliente che avrebbero persino capito . La mia preoccupazione è che, dal momento che stiamo drammaticamente cambiando così tanto in una volta, c'è poco spazio per piccoli pezzi di lavoro che portano a risultati utili / dimostrabili. Sono preoccupato che, anche se fossimo riusciti a trovare un modo per farlo in piccoli blocchi, avremmo bisogno di quei pezzi per adattarsi bene a un quadro più ampio, e quindi troveremmo difficile svilupparli separatamente per questo motivo pure. Puntiamo a un approccio SOA abbastanza disaccoppiato, che è qualcosa.

I tempi sono stretti e la reputazione è stata puntata sulla consegna puntuale.

Quindi mi piacerebbe sapere se, in questo caso:

  • è consigliabile fare un sacco di design up-front, mettere insieme la forma generale della app e ottenere i moduli cruciali lavorando in un'unica grande spinta (che potrebbe essere stampabile in termini di tenere traccia del lavoro, ma non così tanto in termini di feedback e miglioramento del design e così via), prima di diventare più agile da quel momento in poi, o ...
  • cerca di essere il più agile possibile fin dall'inizio - accetta cose come gli standard di codifica, forse alcune basi API, le divisioni generali dei moduli, e poi affidati alla codifica indipendente tenendo in mente la flessibilità per lasciare che le altre cose gradualmente si arricchiscano; forse alcune cose devono essere rielaborate, ma tutto ciò che può essere meglio guidato durante lo sviluppo piuttosto che in anticipo ne trarrà vantaggio, oppure ...
  • forse qualcos'altro e ...
  • qualche consiglio generale?
posta frumious 05.08.2011 - 02:00
fonte

2 risposte

4

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.

    
risposta data 05.08.2011 - 02:57
fonte
1

Penso che il classico Rational Unified Process funzioni meglio per i grandi progetti.

La ragione per cui dico questo è che la fase di raccolta dei requisiti per un grande progetto richiede molto tempo e che i requisiti interagiscono in modi imprevisti. Ad esempio, qualcuno negli account ti dirà che hanno bisogno dell'ID fiscale. di chiunque paghi una bolletta a causa delle normative sul riciclaggio di denaro sporco - devi quindi tornare indietro e riprogettare il tuo sito Web per acquisire gli ID fiscali. nella pagina di registrazione, e anche, finire con due moduli aggiuntivi se il nome sulla carta di credito non corrisponde con il nome del cliente registrato.

In molti casi non è possibile rilasciare funzionalità. Non puoi semplicemente andare in diretta con "Order Capture" dopo aver abbandonato la funzione "Order Delivery".

Una volta che ti allontani dalle applicazioni a scopo singolo e inizi a sviluppare applicazioni aziendali "reali", scopri che la maggior parte dei requisiti sono in realtà regolatori. Devi fare cose a causa di contabilità, tasse, protezione dei consumatori, leggi sulla privacy ecc. Nei sistemi finanziari, questo può rappresentare fino al 100% dei tuoi requisiti per alcuni sistemi.

L'agile "consente di parlare con gli utenti e dare loro i cookie" non è possibile quando il tuo "utente" è rappresentato da un documento con duecento pagine di oscuri legalese. Se elimini funzionalità come "Segnala l'imposta sulle vendite", potresti finire in prigione.

Perversamente, visti i commenti di cui sopra, la mia risposta è "Sì", puoi usare Agile e "Sì" funziona, ma solo per i progetti "sub" all'interno del più ampio framework del progetto e, solo se prendi "go" live "per indicare l'ambiente di test" UAT "o" SIT ".

    
risposta data 05.08.2011 - 03:56
fonte

Leggi altre domande sui tag