Metodologia agile: veloce e sporco o piano prima?

La metodologia agile è in primo piano. Prima non pianifichiamo tutto. Di fatto raccogli i requisiti, la progettazione, il codice, il test, la distribuzione e la presentazione. Fai tutto ciò in meno di una quindicina di giorni (da dare o da fare) sulla più piccola funzionalità che puoi implementare e ricevere feedback. Poi fai di nuovo tutto aggiungendo un'altra funzione o modificando una vecchia.

La chiave è scrivere il codice che accetta i cambiamenti 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 il flusso dovrebbe andare" (o qualsiasi altra cosa) cambia ancora, non è traumatico.

Non puoi scrivere in modo rapido e sporco. Veloce e sporco ti dà il codice ridgid. Sii veloce lavorando in piccolo. Resta flessibile con non diffondere la conoscenza . Idealmente, qualsiasi modifica di una singola funzionalità dovrebbe influire solo su una posizione nel codice.

Non puoi spendere un sacco di tempo senza fare altro che pianificare. È possibile pianificare ma è necessario essere in grado di modificare il piano. È necessario scoprire rapidamente i motivi per modificare il piano. Quando la pianificazione procede senza intoppi, senza sorprese da cui imparare, cioè quando la pianificazione è andata avanti per troppo tempo. La pianificazione e la codifica devono accadere vicine l'una all'altra. Se stai imparando, più vecchio è il piano, il più scemo è.

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

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

Agile riguarda la costruzione di un sistema, in cui il cambiamento, anche in ritardo nello sviluppo, è banale. Questo viene fatto costruendo il software in piccoli blocchi incrementali e bloccando il comportamento di quei blocchi con solidi test automatici. E utilizzando la distribuzione frequente e automatizzata in produzione per convalidare il valore di tali modifiche.

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

Alcuni dicono che "un po 'di design in anticipo" è buono con agilità. Ma se hai intenzione di ripetere questo progetto in seguito, devi comunque assicurarti che la tua cultura dello sviluppo produca un sistema facile da modificare. Quindi "SDUF" non invalida la necessità di test robusti, refactoring aggressivo e implementazione continua.

Costruendo "facilità di cambiamento" nel sistema, non è necessario pensare seriamente alla progettazione iniziale del progetto, poiché è possibile modificarlo in seguito. L'approccio "Veloce e sporco", la maggior parte delle persone lo chiama "spike", è utilizzabile solo se si stabilizzano le caratteristiche che si trovano di valore. Ma non dovresti lasciare pezzi di codice hacked-up nella tua base di codice troppo a lungo, poiché rallentano il cambiamento.

Nessuno dei due.

È "Inizia semplice e migliora mentre ti sposti".

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

Pianificare prima è rigido, ma stabile (se il progetto viene completato prima che venga eseguito in limiti finanziari o temporali).

Agile è un'alternativa al 2 sopra. Si basa su un approccio iterativo in cui le funzionalità vengono completate una alla volta, funzione per caratteristica, e le conoscenze acquisite durante il completamento di questi elementi del programma completamente funzionali vengono utilizzate per adattare e regolare il piano man mano che lo sviluppo procede. Per fare ciò è necessario pianificare in anticipo - è necessario pianificare almeno in modo sufficiente per poter stimare quanto lavoro richiedono le singole funzionalità - ma poiché l'agile si aspetta un cambiamento, una pianificazione eccessiva porta allo spreco.

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

Quindi il tuo approccio va bene. Il pericolo però è di dire "Bello, funziona, ho finito. Cosa succede dopo?". Non hai finito, ci sono un sacco di angoli tagliati da raddrizzare e dovresti ottenere / prenditi il tempo per farlo correttamente una volta che è chiaro che il tuo approccio produce un sistema funzionante e funzionante. Potrebbe essere scrivere test, documentare, StyleCop, ottimizzare, istruire i colleghi su ciò che hai fatto e su come lo hai fatto, farlo rivedere, ecc.

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

Molto 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 stai risolvendo esattamente lo stesso problema. Se in futuro dovrai risolvere una variante di tale problema, in futuro dovrai ridefinire il tuo design per aggiungere tale variante, ma tieni presente non in questo momento.

In altre parole, pianifica l'attività immediata, ma non pianificare nulla di più avanti.