È possibile chiamare correttamente (o il proprio team) "Agile" se non si esegue TDD (Test-Driven Development)?

Sì, sì, sì, un milione di volte sì.

Agile è una filosofia, TDD è una metodologia specifica.

Se volessi essere davvero esigente, potrei semplicemente sottolineare che ci sono alcune varianti di xDD - che i loro sostenitori spiegheranno in profondità non sono TDD - ma quelle sono ancora sostanzialmente legate al test prima, quindi sarebbe barare.

Quindi diciamo questo: puoi essere agile senza fare lo sviluppo "test first" (guarda come funziona scrum - da nessuna parte ci sono dettagli su come scrivere il codice). Guarda una lavagna kanban, guarda ogni sorta di metodologie agili.

Vuoi test unitari? Certo che lo fai, per tutti i tipi di motivi - e potresti benissimo sostenere che non puoi essere agile senza test unitari (anche se sospetto che tu possa esserlo) - ma non devi scriverli prima di essere agile.

E infine, è altrettanto vero che potresti fare Test First senza essere Agile e argomenti forti per fare test prima indipendentemente dalla tua filosofia di sviluppo generale.

Sembra che altri (con un rappresentante più SOLIDO) abbiano un'opinione simile ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Sebbene non sia impossibile fare Agile senza TDD e OOD, è difficile. Senza TDD il tasso di iterazione di ...

(Il link nel tweet è la risposta completa su LinkedIn)

"Essere agili" significa semplicemente aderire ai valori e ai principi del manifesto agile . Nulla in quel documento menziona TDD, o addirittura test unitari per quella materia.

Quindi sì, puoi essere agile senza fare TDD o test unitari.

Non lo consiglierei però ...

Sì ,

Guarda uno dei valori agili:

Individui e interazioni su processi e strumenti

Questo dovrebbe già rispondere. TDD è una certa metodologia, un processo. In effetti un processo che potrebbe eventualmente essere utilizzato in processi di sviluppo agili, ma niente di più. Penso che forse TDD sia allo stato dell'arte ora quando si è agili. Ma penso che il concetto di agile sarà ancora in grado di durare, anche se forse il TDD è stato sostituito da altre pratiche.

Vorrei riassumere come:

• Oggi TDD è un defacto-standard per essere agile

• Ci possono essere modi di essere agili senza TDD

dico

No [sorta di]

Se torni alla fonte originale http://en.wikipedia.org/wiki/Extreme_Programming TDD è fondamentale per il processo; i test sostituiscono le specifiche dei requisiti e i casi d'uso di cascata, servono come documentazione vivente ed esempi di funzionamento, ecc. Sono indispensabili.

Tuttavia, ci sono così tanti gusti diversi di "agile" che fluttuano ora che è del tutto possibile che uno di loro eviti il ​​TDD

EDIT: l'interpretazione di @ Murph della domanda sembra essere quella preferita. Diamine, l'ho persino votato, è una buona risposta. Tuttavia , sostengo la mia posizione secondo cui il Manifesto Agile è un insieme di principi, non una metodologia di sviluppo. Non vedo nulla nel dire "oh sì, sono agile" senza implementare effettivamente le pratiche che portano i benefici. In particolare:

Il software di lavoro è la misura principale del progresso.

e

I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato.

Per me, questi due principi implicano se non richiedono TDD - almeno non conosco nessun altro modo per raggiungerli senza di essa!

EDIT 2: sì, tecnicamente puoi scrivere i test in seguito; ma considero ancora test-first / TDD fondamentali. Non perché non puoi "essere agile" senza di essa, ma perché sarai più agile con esso. Test-first / test-driven è un approccio molto più efficiente di test-later / test-after Thought. Le descrizioni dei test sono i requisiti . Non rimandarli a dopo ;-)

EDIT 3: Alla fine ho capito cosa mi preoccupa così tanto della risposta molto ben scritta di Murph. È l'idea che si potrebbe "essere agili" senza farlo davvero . E "farlo" (come mostrato sopra) praticamente richiede TDD.

Rigorosamente, sei agile aderendo al manifesto agile . In pratica, una base di codice non è agile a meno che non abbia una buona copertura del test. È possibile eseguire TDD e scrivere i test prima / durante lo sviluppo della funzionalità o scrivere test per la funzionalità dopo che è stato sviluppato. Tuttavia, di solito è più facile ed efficace farlo nel modo TDD.

Puoi essere agile, ma probabilmente c'è spazio per miglioramenti.

Uno dei principi in agile è che devi essere in grado di rispondere al cambiamento. Ciò significa che non sai in anticipo cosa devi costruire. Se seguissi un processo a cascata, sapresti con x mesi di anticipo esattamente cosa devi costruire e potresti progettare singoli componenti software in modo che ciascuno di essi prenda parte a uno schema più ampio, raggiungendo il prodotto finale (almeno penseresti che era così). Ma poiché l'agile impone di non sapere quale sia il prodotto finale, non si sa mai per quale codice verrà utilizzato e, soprattutto, quando verrà modificato.

Pertanto è necessaria una suite di test approfondita per assicurarsi che le funzionalità già sviluppate continuino a funzionare man mano che la base di codice viene modificata.

Ma questo di per sé non è TDD. Se si scrivono i test dopo aver scritto il codice, non è TDD. Ma TDD aiuta con un altro aspetto, impedisce la sovrapproduzione.

Nel mio team agile ho avuto difficoltà con gli sviluppatori che scrivono codice che credono possano essere utili più avanti nel progetto. Era stato uno sviluppo a cascata che probabilmente sarebbe stato OK, perché stavano aggiungendo supporto per qualcosa nel piano di progetto per i prossimi x mesi.

Ma se stai seguendo i principi agili non dovresti scrivere questo codice, perché non hai idea se sarà nemmeno necessario. La funzionalità prevista per la prossima settimana può essere improvvisamente rinviata a tempo indeterminato.

Se segui correttamente il principio TDD, allora una singola riga di codice non può esistere prima che un test imponga questa riga di codice (personalmente posso scrivere un codice banale senza test), e se inizi scrivendo il test di accettazione, allora implementerai solo esattamente ciò che è necessario per offrire le funzionalità richieste.

Pertanto, TDD aiuta a evitare la sovrapproduzione, consentendo al team di essere il più efficace possibile, che è anche un principio agile fondamentale.

Il software di lavoro è la misura principale del progresso

Puoi essere agile senza fare TDD (test driven development)?

Risposta breve: Sì.

Risposta più lunga: ci sono già molte risposte davvero valide a questa domanda e ottimi riferimenti. Non proverò a discutere questi punti.

Nella mia esperienza, Agile riguarda la scelta del giusto livello di Lean-ness per il progetto in corso. Cosa intendo per Lean-ness? E perché lo inserisco in questa risposta?

Lean non significa tagliare tutto il possibile dal tuo metodo. Come ha notato uno dei nostri colleghi, non è necessario includere TDD o Unit Test nei propri comportamenti. Tuttavia, nel contesto del progetto ti ritrovi, potrebbe essere utile o meno.

Pensiamo alla catena di approvvigionamento per un grande rivenditore senza nome situato in AK. C'è il consumatore Entrano nel negozio. Il negozio riceve vari prodotti tramite camion. I camion, presumibilmente, prendono quei prodotti da un magazzino. Il magazzino è riempito con spedizioni di vari produttori. I produttori a loro volta dispongono di intere catene di approvvigionamento.

Cosa succede quando al direttore generale per la spedizione nella suddetta catena di fornitura viene comunicato che riceverà un bonus annuale di $ 1 milione per ogni anno in cui ha meno di 10 camion nella flotta? Taglia immediatamente la flotta a 9 camion. In questo scenario "terribile", questo aumenterà la quantità di merci immagazzinate nel magazzino (aumentando i costi in quel nodo). E "affamerà" i negozi.

Pertanto, la catena di approvvigionamento complessiva soffre se l'ottimizzazione locale è consentita senza considerare l'insieme.

Torna a TDD e UT. TDD è un meccanismo di espressione dei requisiti. Il sistema DEVE eseguire tali vincoli. Giusto. TDD può sostituire il comportamento dei requisiti di Use Case Drive Development o il comportamento dei requisiti di User Story Driven Development. Ha il vantaggio "incline" di combinare i carichi di lavoro di unit test e requisiti. È un vantaggio se il carico di lavoro complessivo è ridotto. Non lo è se aumenta il carico di lavoro della catena di approvvigionamento (fissiamo la qualità).

E così, hai chiesto: puoi essere agile senza fare TDD (test driven development)?

Certo che puoi. Una domanda diversa, e forse migliore, è: - Se applico TDD a questo progetto, si tradurrà in una consegna del software complessivamente più efficiente o in una meno efficiente?

Per citare un autore preferito ... JRR Tolkien

Signore degli Anelli. La compagnia degli anelli. Pg 94 'E si dice anche', rispose Frodo, 'Non andare dagli elfi per un consiglio, poiché entrambi no e sì.'

Quindi, alla fine, ... dipende. Devi rispondere alla domanda. Quale percorso ti condurrà nel modo più efficiente ai tuoi obiettivi desiderati.

A TDD o non a TDD. Questa rimane la domanda. :-)

PS: sto ripubblicando questa risposta anche su un altro sito. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

Paragonando alla progettazione di un castello.

Castello Agile

Se dovessi progettare un castello usando Agile. Scriveresti porzioni che hanno funzioni specifiche e incoraggino l'utente a utilizzare le parti funzionali, adattando il design futuro alle reazioni dell'utente. Quindi, costruisci il sotterraneo e comunichi con il guardiano del sotterraneo, testeresti le fondamenta fornite dalla terra e dal sotterraneo. Costruiresti i parapetti e chiederesti ai guardiani notturni se va bene. Costruiresti i muri e fai testare il valore difensivo ai soldati. Costruiresti la cucina e la guarderesti dai cuochi. E durante questo processo, ogni parte fino ad oggi funzionerebbe in aggiunta alla struttura attuale. Quindi, quando hai finito la prigione, potresti spostare i prigionieri. E così via. Ma quando hai finalmente finito il castello, scopri che i prigionieri sono fuggiti.

Castello di TDD

Con TDD, ti presenti con i prigionieri e vedi se scappano. Quindi scrivi le celle della prigione fino a quando non possono scappare. Quindi rifatteresti il ​​codice rimuovendo in modo pulito le celle non necessarie e rimuovendo le barre che si trovano nella posizione errata e testando di nuovo. I prigionieri non sono fuggiti. Non devi comunicare con il carceriere. E potresti consegnare l'intero castello una volta finito tutto. A quel punto il carceriere dice che il sotterraneo ha bisogno di più celle, e ora devi scavare più fondamenta.

Agile castello TDD

Se si combinano Agile e TDD. Vedresti se i prigionieri sono fuggiti, quindi chiedi al carceriere cosa è necessario. Dice che hai bisogno di più cellule. Andresti a prendere alcune persone a caso per fingere di essere prigionieri e vedere se scappano. Se non lo fanno, allora lo mostri al carceriere, ed è contento. Quindi inizi a costruire i parapetti.

Conclusione

Quindi entrambi risolvono problemi diversi. Agile aiuta a modificare i requisiti in base alla scoperta delle esigenze degli utenti quando vedono lo sviluppo del prodotto nel punto in cui è più facile adattarsi. Implica il rilascio di aggiunte stabili suddivise dal progetto complessivo.

TDD risolve il problema di anticipare il fallimento. Rilevamento e correzione degli errori nel momento in cui si verifica in un punto del processo in cui è più semplice da correggere. Implica il collaudo di unità di codice disaccoppiate stabili suddivise dal progetto complessivo.

È facile vedere TDD come un'estensione di Agile, perché entrambi seguono lo stesso modello, avanzamento e revisione guidati dall'unità. La differenza è che le unità in Agile funzionano esternamente fino ad oggi nel loro insieme, mentre le unità in TDD funzionano come parte e potrebbero non produrre un prodotto funzionante per la revisione esterna. Ed entrambi i processi regolano esigenze diverse (usabilità vs. correttezza). Poiché entrambi funzionano su un processo di sviluppo in unità, entrambi i processi di revisione possono verificarsi in punti simili, con TDD suddiviso più finemente.

Appunti

• Avere test unitari da soli non significa che usi TDD. TDD significa avere il test prima dell'unità prodotta e usare il test mentre si sviluppa per confermare l'unità. Il test unitario senza TDD può essere utilizzato per assicurarsi di non invalidare la funzionalità precedentemente creata.
• Avere sprint e altri incontri non ti rende agile. Gli obiettivi del manifest ti rendono agile. È possibile suddividere gli obiettivi a cascata in sprint con unità di lavoro, senza rispettare l'impegno di favorire le persone rispetto ai processi.
• Per definizione di TDD e Agile. I test unitari regoleranno le unità non consegnabili, quindi TDD eseguirà un ciclo più veloce di Agile. E se si utilizzano entrambi, i cicli Agile conterranno uno o più cicli TDD (se ogni unità viene testata).
• Da quello che ho capito: fallisci Agile non riuscendo a sviluppare un'unità consegnabile / significativa per l'utente. L'unità può essere significativa anche se accelera il prodotto. Ma come spiega Agile il refactoring per una manutenzione più semplice? Non l'ho coperto abbastanza per rispondere a questo.
• Si fallisce TDD fallendo il test unitario. Produzione di codice che non produce correttamente la funzione.

Agile ti costringe ad affrontare e mitigare programmi e rischi di qualità ad ogni iterazione. cioè TDD non è necessario per essere considerato Agile .

Tuttavia, TDD è una tecnica eccezionale per mitigare i rischi di qualità, specialmente per un progetto con un gran numero di iterazioni o persone. In un tale progetto, TDD aggiungerà alcuni rischi di pianificazione nelle prime iterazioni, poiché è necessario scrivere anche casi di test. Tuttavia, TDD comporta enormi risparmi sui costi nelle iterazioni successive perché mitiga continuamente i rischi di qualità. vale a dire TDD è raccomandato.