Metodologia agile: veloce e sporca o prima pianifica?

Domanda agile: l'agile crede nel far funzionare le cose nel “modo rapido e sporco” - o agile preferisce costruire solidamente da zero? O questa non è una domanda di metodologia, e più una domanda che valuti caso per caso?

Sto tecnicamente "rifacendo" le fondamenta del sistema, dopo che ho già costruito gran parte della struttura stessa ... non è una quantità monumentale di lavoro ... sarebbe stato desiderabile che io volessi prima specificare l'intero flusso, analizzarlo, modificarlo e poi costruire? Mi sento come se fosse meglio così ... una volta messo su un sistema disordinato vedo meglio come deve essere fatto ... d'altra parte non è così organizzato ... solo curioso di sapere quale sia il miglior sviluppo la pratica è al riguardo.

Credo che questa domanda sia in qualche modo diversa da Agile e dai prototipi poiché non sto chiedendo prototipazione e codice usa e getta; Mi interessa l'agile per il codice di produzione.

La metodologia agile è il primo piano. Non pianifica tutto prima. In effetti raccogli requisiti, progettazione, codice, test, distribuzione e presente. Basta fare tutto ciò in meno di quindici giorni (dare o avere) con la più piccola funzionalità che è possibile distribuire e ottenere feedback. Quindi fai di nuovo tutto aggiungendo un'altra funzionalità o modificando una vecchia.

La chiave è scrivere codice che accetti il ​​cambiamento in modo che quando finalmente vedi "come dovrebbe andare l'intero flusso" puoi cambiare il codice per farlo. In questo modo quando "il modo in cui dovrebbe andare il flusso" (o qualunque altra cosa) cambi di nuovo, non è traumatico.

Non puoi scrivere veloce e sporco. Veloce e sporco ti dà il codice ridgid. Sii veloce lavorando in piccolo. Resta flessibile non diffondendo la conoscenza . Idealmente, ogni singola modifica delle funzioni dovrebbe avere un impatto solo su una posizione nel codice.

Non puoi passare un sacco di tempo a fare altro che pianificare. Puoi pianificare ma devi essere in grado di cambiare il piano. Devi scoprire rapidamente i motivi per modificare il piano. Quando la pianificazione procede senza intoppi, senza sorprese da imparare, è quando la pianificazione è andata avanti per troppo tempo. La pianificazione e la codifica devono avvenire l'una vicino all'altra. Se stai imparando, più vecchio è il piano, più stupido è.

A lungo termine, dovresti pianificare di diventare più intelligente. Scrivi un codice flessibile. Quindi diventare più intelligenti non porta al rimpianto.

Non mi piace che per la maggior parte delle persone sia "veloce e sporco" o "grande design in primo piano". Non considerano nemmeno che ci siano altre opzioni.

Agile riguarda la costruzione di un sistema, in cui il cambiamento, anche in fase avanzata di sviluppo, è banale. Questo viene fatto costruendo il software in piccoli blocchi incrementali e bloccando il comportamento di quei blocchi con robusti test automatizzati. E l'utilizzo frequente e automatizzato della distribuzione in produzione per convalidare il valore di tali cambiamenti.

Avendo test automatici automatizzati, diventa banale cambiare anche le parti più difficili dell'architettura, mediante refactoring incrementale per periodi di tempo più lunghi. Pertanto, anche se ti rendi conto che la tua architettura potrebbe essere realizzata meglio a metà del progetto, è realisticamente possibile apportare le modifiche in tempi relativamente brevi.

Alcune persone dicono che "alcuni design in primo piano" è buono con agile. Ma se hai intenzione di iterare su questo progetto in seguito, devi comunque assicurarti che la tua cultura di sviluppo produca un sistema che è facile da cambiare. Quindi "SDUF" non invalida la necessità di test robusti, refactoring aggressivo e implementazione continua.

Costruendo la "facilità di cambiamento" nel sistema, non è necessario riflettere attentamente sulla progettazione iniziale del progetto, poiché ciò può essere modificato in seguito. L'approccio "Quick and dirty", la maggior parte delle persone lo chiama "spike", è utilizzabile solo se stabilizzi le funzionalità che ritieni preziose. Ma non dovresti lasciare pezzi di codice compromesso nella tua base di codice per troppo tempo, poiché rallentano il cambiamento.

Nessuno dei due.

È "Inizia semplice e migliora mentre ti muovi".

Veloce e sporco è fragile, ma veloce (se il progetto è sufficientemente piccolo e di breve durata).

Il primo piano è rigido, ma stabile (se il progetto viene completato prima di incorrere in vincoli finanziari o temporali).

Agile è un'alternativa alla precedente 2. Si basa su un approccio iterativo in cui le funzionalità vengono completate una alla volta, funzionalità per funzionalità, e le conoscenze acquisite durante il completamento di queste parti del programma pienamente funzionali vengono utilizzate per perfezionare e adattare il piano man mano che lo sviluppo procede. Per fare ciò richiede un po 'di pianificazione in anticipo - è necessario almeno una pianificazione sufficiente per essere in grado di stimare la quantità di lavoro richiesta dalle singole funzionalità - ma poiché l'agile prevede cambiamenti, una pianificazione eccessiva porta allo spreco.

Una delle caratteristiche principali di Agile è fare brevi iterazioni e quindi rivalutarle. Corri in avanti per esplorare un nuovo territorio, imparare da esso e quindi fare un piano. In questo modo il tuo piano sarà migliore. E se fallisci (scopri che l'idea del tuo corso non funziona), avrai un "fallimento veloce", il che è positivo.

Quindi il tuo approccio è perfetto. Il pericolo però è quindi dire "Bello, funziona, ho finito. Qual è il prossimo?". Non hai finito, ci sono molti angoli tagliati da raddrizzare e dovresti avere / prenderti il ​​tempo per farlo correttamente una volta che è chiaro che il tuo approccio produce un sistema funzionante e praticabile. Potrebbe essere quello di scrivere test, documentare, StyleCop, ottimizzare, educare i colleghi su ciò che hai fatto e su come lo hai fatto, farlo revisionare, ecc.

Per aggiungere alle risposte di cui sopra, un principio chiave è YAGNI . Se la progettazione e la pianificazione iniziali consentono il passaggio successivo, va bene. Ma se abilita un ipotetico passo futuro che non puoi dimostrare è necessario, allora supponi YAGNI.

Gran parte del design, sia top-down che bottom-up, presuppone che ci sarà un significativo riutilizzo del codice. L'esperienza dice che il riutilizzo del codice semplicemente non è così comune, perché raramente risolvi esattamente lo stesso problema. Se in futuro dovessi risolvere una variante di quel problema, rifatti il ​​tuo progetto in futuro per aggiungere quella variante, ma non considerarla subito.

In altre parole, pianificare il compito immediato, ma non pianificare nulla di più avanti.