Lo sviluppo agile richiede prima un framework?

Agile è molte cose per molte persone e alcuni si sentono strongmente su queste cose rispetto ad altre. Leggi il manifesto Agile. Questa è solo la mia opinione, ma alla fine della giornata Agile si occupa di fare ciò che è giusto con una quantità minima di spese generali e di usare qualsiasi metodo / tecnica valida e comprovata (cioè TDD ...) che abbia senso per la tua situazione specifica. p>

Come altri hanno già menzionato, i team più agili si sforzano di fornire piccoli incrementi in piccole iterazioni. E quando possibile dovresti fare la stessa cosa. Allo stesso tempo, paga per avere il giusto design fatto in anticipo. Se la tua applicazione richiede un framework, devi assolutamente andare avanti e mettere in atto il framework. Sì, non sarai in grado di consegnare nulla che funzioni per diverse settimane e forse di più, ma se tu e il tuo team sentite di averne bisogno, fatelo. La pietra angolare di Agile è che riguarda le persone, fa ciò che le persone credono che tu debba fare e loro ti daranno le spalle e saranno conferite al prodotto. Abbiamo forzato i vincoli che hanno reso l'intera squadra strana e imbarazzante e questo è solo pessimo.

Allo stesso tempo, tieni presente che puoi trattare il tuo framework come un deliverable separato che deve essere consegnato a un "team di sviluppo" in modo che il team possa consegnare il prodotto finale. La maggior parte delle volte dopo che è stata stabilita la base minima, è possibile lavorare su framework in incrementi proprio come si farebbe sul prodotto reale. Decidi il minimo assoluto di cui avresti bisogno dal framework per fare in modo che il prodotto faccia qualcosa e concentrati su quello.

Anche IMHO, prendi l'espressione "nessun grande progetto in anticipo perché sei agile" con un pizzico di sale. Anche se non è assolutamente necessario entrare nei dettagli e passare 6 settimane a scrivere documenti di design, per un progetto su larga scala vale ancora la pena dedicare un po 'di tempo a pensare all'architettura generale e al design di alto livello. Metti i pezzi grossi al loro posto giusto in modo che la tua squadra abbia una chiara roadmap in cui vuoi finire. Poiché si esegue solo la progettazione di alto livello, se la direzione cambia, è necessario aggiornare solo la documentazione di alto livello (non dovrebbe essere molto). Non farei mai affidamento sul solo refactoring per dettare la struttura finale di una grande applicazione. Il tuo obiettivo è di fare il minimo design NECESSARIO, non il minimo assoluto in un punto in cui virtualmente non esiste alcun design in anticipo e i requisiti guidano l'evoluzione dei tuoi moduli.

Infine, solo perché non puoi consegnare nulla che funzioni effettivamente fino a quando l'intero framework non è a posto, non significa che non puoi tagliare la struttura in più parti e concentrarti su ognuna individualmente insieme a TDD. Puoi astrarre le interfacce SOA, il database, le comunicazioni di rete, qualche altra logica di back-end e anche se tutto ciò deve essere nel framework, puoi scrivere ognuna usando TDD e prendere in giro tutte le interfacce con cui parleranno queste parti. Alcuni membri del tuo team possono iniziare a lavorare sull'effettivo codice dell'applicazione utilizzando le classi di simulazione che fanno finta che il tuo framework finale sia a posto.

Quindi dimentica la metodologia, fai un passo indietro e chiediti a te stesso (e al team), la SOA è l'approccio giusto per questa applicazione? Se lo è, puoi sicuramente farlo funzionare con agilità.

Agile è solo una metodologia di sviluppo del software. Per capirlo meglio, immagina di lavorare in una casa automobilistica. Agile ti dice semplicemente come gestire il tuo lavoro per creare una macchina migliore (non necessariamente per creare un'auto migliore). Tuttavia, non è necessario disporre prima della pipeline di produzione del motore.

Agile significa rompere lunghi periodi di sviluppo in periodi più piccoli (sprint) per dare agli sviluppatori e agli uomini d'affari la possibilità di capire in che modo dovrebbero andare prima, in modo che possano agire in modo più flessibile.

Un team può avviare una metodologia agile, anche senza avere un framework. In tal caso, uno degli elementi del Product Backlog potrebbe essere come sviluppatore, voglio creare un framework, in modo che possa svilupparmi più rapidamente .

Quindi la risposta è no , agile non ha bisogno che tu abbia prima un framework in posto.

Assolutamente no. Agile si basa su piccoli incrementi e feedback costante. A partire da un framework è più probabile generare creep di scope e oltre a questo, non avrai nulla da mostrare, almeno, il primo mese di sviluppo. È molto più importante essere sulla stessa lunghezza d'onda con gli stakeholder, quindi essere in grado di mostrare alcune funzionalità funzionanti (anche se è solo un mockup) molto velocemente è più importante di un framework. Puoi sviluppare il framework mentre sviluppi la tua applicazione e in seguito puoi evolverla in qualcosa che userai in altri progetti.

Non dovresti assolutamente pianificare di scrivere un framework. Puoi pianificare usare quello che è già stato scritto, (ad esempio JEE con Jersey o molti altri), ma il tentativo di scrivere un framework proprietario per soddisfare alcuni requisiti immaginari è nel migliore dei casi di pareggio. Nel peggiore dei casi diventa un errore da molti milioni di dollari. Gli sviluppatori che vogliono scrivere un framework stanno semplicemente rinviando il vero lavoro di soddisfare le esigenze dei tuoi clienti. Se segui lo sviluppo basato sui test e il refactoring continuo, la struttura esatta di cui hai bisogno cadrà come refactoring.

L'approccio di sviluppo agile può essere notevolmente integrato da un framework e dalla struttura del codice.

A rischio di essere colpito per il collegamento al mio progetto, ho lavorato su un framework specificamente ottimizzato per lo sviluppo agile. Qui è piccolo tranne dalla documentazione che spiega l'approccio alla creazione di applicazioni con requisiti molto vividi. È ancora in corso di lavorazione, ma dovrebbe essere in grado di rispondere alla tua domanda.

link

Fare un sacco di design in anticipo (di cui avrete bisogno se volete costruire un buon framework) non è ciò che è agile. Soprattutto i primi incrementi vengono rapidamente distribuiti utilizzando metodologie agili.

Il mio istinto dice che la scelta per un'architettura orientata ai servizi potrebbe essere il problema. Non sto dicendo che non dovresti fare alcuna architettura in un progetto Agile, ma i primi incrementi ti guideranno verso una buona architettura. Se stai davvero facendo un progetto agile, lascerai che i requisiti ti guidino verso l'architettura giusta rifasando i vecchi pezzi di codice a intuizioni più recenti.

Simplicity -- the art of maximizing the amount of work not done -- is essential.

Non dare per scontato nulla su quali framework userete. Concentrati sulla soddisfazione dei tuoi clienti / utenti nel modo più rapido e professionale possibile. Aggiungi quadri quando hai un bisogno reale, misurabile e reale per questo.

Penso che staresti andando nel modo sbagliato cercando di usare il TDD come un modo per arricchire elementi di architettura di alto livello come la scelta di un framework (con l'eccezione di una struttura beffarda, forse, il cui bisogno può essere scoperto man mano che la suite di test cresce). La parte di refactoring del ciclo TDD è molto più legata alle micro decisioni come i cambiamenti nella progettazione delle classi o dei metodi, piuttosto che i grandi riorientamenti dell'immagine. Se hai bisogno di un framework ORM, ad esempio, sicuramente non lo scoprirai tramite TDD.

Potresti avere ragione nel dire che TDD ti permetterà di elaborare ampie parti della tua base di codice in isolamento dal resto e quindi ritardare la scelta di un framework SOA nel momento esatto necessario.

Tuttavia il fatto che puoi permetterti di ritardare la scelta non significa che sia proibito scegliere in anticipo, specialmente per le grandi decisioni architetturali fondamentali che avranno un impatto sul modo in cui è strutturata la tua applicazione. Inoltre, tieni presente che alcuni framework sono invasivi e finisci per essere costretti a codificare le cose in un certo modo, il che potrebbe rovinare una parte dei tuoi sforzi se hai già sviluppato gran parte del tuo livello di servizi in modo agnostico attraverso TDD.