È possibile chiamare correttamente te stesso (o il tuo team) "Agile" se non lo fai TDD (Test-Driven Development)?
Sì, sì, sì, un milione di volte sì.
Agile è una filosofia, TDD è una metodologia specifica.
Se volessi essere veramente pignolo, potrei semplicemente sottolineare che ci sono alcune varianti di xDD - che i loro sostenitori spiegheranno in modo approfondito sono non TDD - ma quelli sono ancora sostanzialmente legati al test, quindi sarebbe un imbroglio.
Quindi diciamo questo: puoi essere agile senza fare lo sviluppo di "testare prima" (guarda come funziona Scrum - da nessuna parte ci sono specifiche su come scrivi codice). Guarda una scheda kanban, guarda tutti i tipi di metodologie agili.
Vuoi test unitari? Certo che lo fai, per tutti i tipi di motivi - e potresti ben argomentare che non puoi essere agile senza test unitari (anche se sospetto che tu possa essere) - ma non devi prima scriverli per essere agile.
Infine, è altrettanto vero che puoi provare senza senza argomenti agili e forti per eseguire test prima, indipendentemente dalla tua filosofia di sviluppo generale.
Sembra che altri (con un rappresentante più solido) abbiano un'opinione simile ...
@unclebobmartin: http://t.co/huxAP5cS Though it's not impossible to do Agile without TDD and OOD, it is difficult. Without TDD the iteration rate of...
(Il link nel tweet è la risposta completa su LinkedIn)
"Essere agili" significa semplicemente aderire ai valori e ai principi del manifesto agile . Niente in quel documento menziona TDD, o anche test unitari per quella materia.
Quindi sì, puoi essere agile senza fare test TDD o unità.
Non lo consiglierei però ...
Sì ,
Guarda uno dei valori agili:
Individuals and interactions over processes and tools
Questo dovrebbe già rispondere. TDD è una certa metodologia, un processo. Effettivamente un processo che potrebbe essere utilizzato in processi di sviluppo agili, ma niente di più. Penso che forse TDD sia all'avanguardia quando è agile. Ma penso che il concetto di agile sarà ancora in grado di durare, anche se forse il TDD è stato sostituito da altre pratiche.
Lo riassumerei come:
Oggi TDD è uno standard defacto per essere agile
Ci possono essere modi di essere agili senza TDD
Dico
Se torni al sorgente originale link TDD è fondamentale per il processo; i test sostituiscono le specifiche dei requisiti e i casi d'uso della cascata, servono come documentazione vivente e esempi di funzionamento, ecc. Sono indispensabili.
Tuttavia, ci sono così tanti diversi gusti di "agile" che fluttuano ora che è del tutto possibile che uno di essi non rimuova TDD
EDIT: l'interpretazione di @ Murph della domanda sembra essere quella preferita. Diamine, l'ho persino svalutato, è una buona risposta. Tuttavia , sostengo la mia posizione secondo cui il Manifesto Agile è un insieme di principi, non una metodologia di sviluppo. Non vedo l'utilità di dire "oh sì, sono agile" senza implementare effettivamente le pratiche che portano i benefici. In particolare:
Working software is the primary measure of progress.
e
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Per me, questi due principi implicano se non richiedono TDD - almeno non conosco altro modo per raggiungerli senza di essa!
EDIT 2: sì, tecnicamente puoi scrivere i test in seguito; ma considero fondamentale il test-first / TDD. Non perché non puoi "essere agile" senza di esso, ma perché sarai più agile con esso. Test-first / test-driven è un approccio molto più efficiente di test-after / test-afterthought. Le descrizioni dei test sono i requisiti . Non metterli via più tardi; -)
EDIT 3: Alla fine ho capito cosa mi preoccupa tanto della risposta molto ben scritta di Murph. È l'idea che si possa "essere agili" senza effettivamente farlo . E "farlo" (come mostrato sopra) richiede praticamente TDD.
Rigorosamente, sei agile aderendo al manifesto agile . In pratica, un code-base non è agile a meno che non abbia una buona copertura di test. È possibile eseguire TDD e scrivere i test prima / durante lo sviluppo di funzionalità o scrivere test per la funzionalità dopo che è stato sviluppato. Di solito è più facile e più efficace farlo nel modo TDD.
Puoi essere agile, ma ci sono probabilmente margini di miglioramento.
Uno dei principi in agile è che devi essere in grado di rispondere ai cambiamenti. Ciò significa che non sai in anticipo cosa devi costruire. Se si stesse seguendo un processo a cascata, si conoscono x mesi in anticipo esattamente ciò che è necessario creare e si potrebbero progettare singoli componenti software in modo che ciascuno di essi prenda parte a uno schema più ampio, raggiungendo il prodotto finale (almeno si potrebbe pensare che era così). Ma dal momento che agile impone che non si conosce il prodotto finale, non si sa mai per cosa verrà utilizzato il codice e, cosa ancora più importante, quando verrà modificato.
Pertanto è necessaria una completa suite di test per accertarsi che le funzionalità che hai già creato continuino a funzionare man mano che la base di codice viene modificata.
Ma quello stesso non è TDD. Se scrivi i test dopo aver scritto il codice, non è TDD. Ma TDD aiuta con un altro aspetto, previene la sovrapproduzione.
Nel mio stesso team agile ho lottato con sviluppatori che scrivevano codice che credevano sarebbe diventato utile in seguito nel progetto. Se fosse stato lo sviluppo di una cascata probabilmente sarebbe stato OK, perché stavano aggiungendo il 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 ciò sia addirittura necessario. La funzione pianificata per la prossima settimana può essere improvvisamente rimandata indefinitamente.
Se segui correttamente il principio TDD, allora una singola riga di codice non può esistere prima che un test detta questa linea di codice (personalmente posso scrivere qualche codice banale senza test), e se inizi a scrivere il test di accettazione, allora implementa solo esattamente ciò che è necessario per fornire le funzionalità richieste.
Quindi TDD aiuta a evitare la sovrapproduzione, consentendo al team di essere il più efficace possibile, che è anche un principio fondamentale dell'agile.
Working software is the primary measure of progress
Puoi essere agile senza fare TDD (sviluppo basato su test)?
Risposta breve: Sì.
Risposta più lunga: Ci sono già molte buone risposte a questa domanda e ottime referenze. Non cercherò di discutere questi punti.
Nella mia esperienza, Agile punta a scegliere il giusto livello di Leanness per il progetto in questione. Cosa intendo per Lean-ness? E, perché lo porto in questa risposta?
Lean non significa tagliare tutto fuori dal tuo metodo. Come ha notato uno dei nostri colleghi, non è necessario includere TDD o Unit Test nei tuoi comportamenti. Tuttavia, nel contesto del progetto in cui ti trovi, potrebbe essere utile o meno.
Pensiamo alla catena di approvvigionamento di un grande rivenditore non specificato che si trova 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 da spedizioni di vari produttori. I produttori a loro volta hanno a loro volta intere catene di fornitura.
Cosa succede quando al direttore generale per la spedizione nella catena di approvvigionamento di cui sopra viene detto che riceverà un bonus annuale di $ 1 milione per ogni anno in cui ha meno di 10 camion nella flotta? Egli taglierà immediatamente la flotta a 9 camion. In questo scenario "orribile", questo farà aumentare la quantità di merci immagazzinate nel magazzino (aumentando i costi in quel nodo). E, "affamerà" i fronti del negozio.
Quindi, la supply chain complessiva soffre se l'ottimizzazione locale è consentita senza considerare l'intero.
Torna a TDD e UT. TDD è un meccanismo di espressione dei requisiti. Il sistema DEVE eseguire questi vincoli. Giusto. TDD può sostituire il comportamento dei requisiti Use Case Development Development o User Story Driven Development. Ha il vantaggio "pendente" di combinare i carichi di lavoro dell'unità Test e requisiti. È un vantaggio se il carico di lavoro complessivo è ridotto. Non lo è, se il carico di lavoro complessivo della catena di approvvigionamento è aumentato (fissiamo la qualità).
E così, hai chiesto: puoi essere agile senza fare TDD (sviluppo basato su test)?
Certo che puoi. Una domanda diversa e forse migliore è: - Se applico TDD a questo progetto, si otterrà una consegna del software complessivamente più efficiente o meno efficiente?
Per citare un autore preferito ... J.R.R. Tolkien
Lord of the Rings. Fellowship of the Rings. Pg 94 'And it is also said', answered Frodo, 'Go not to the elves for counsel, for they will both no and yes.'
Quindi, alla fine, ... dipende. Devi rispondere alla domanda. Quale percorso ti condurrà in modo più efficiente agli obiettivi desiderati.
A TDD o non a TDD. Questa rimane la domanda. : -)
PS - Sto ripubblicando questa risposta anche su un altro sito. link
Confronto con la progettazione di un castello.
Se dovessi progettare un castello usando Agile. Dovresti scrivere parti con funzioni specifiche e incoraggiare l'utente a utilizzare le parti funzionali, adeguando il design futuro alle reazioni dell'utente. Quindi, costruisci il dungeon e comunichi con il custode del dungeon, testerai le fondamenta fornite dalla terra e dal dungeon. Costruisci i parapetti e chiedi ai guardiani notturni se è buono. Costruirai i muri e i soldati metteranno alla prova il valore difensivo. Costruisci la cucina e chiedi ai cuochi di controllarla. E durante questo processo, ogni parte fino ad oggi funzionerebbe in aggiunta alla struttura attuale. Quindi, quando hai finito il sotterraneo, potresti far entrare i prigionieri. E così via. Ma quando hai finalmente finito il castello, scopri che i prigionieri sono fuggiti. Ora devi tornare nel dungeon e scoprire che hai bisogno di barre più spesse, ma le porte non sono abbastanza profonde per contenere le barre, e le cerniere non supportano porte più grandi.
Con il TDD, ti presenti con i prigionieri e vedi se scappano. Quindi scrivi le celle della prigione finché non possono scappare. Quindi devi rifattorizzare il codice rimuovendo in modo pulito le celle non necessarie, e rimuovendo le barre che si trovano nella posizione sbagliata, e prova di nuovo. I prigionieri non sono fuggiti. Non devi comunicare con il carceriere. E potresti consegnare l'intero castello una volta che hai finito tutto. A quel punto il carceriere dice che il dungeon ha bisogno di più celle, e ora devi scavare più delle fondamenta.
Se si combinano Agile e TDD. Vedresti se i prigionieri sono fuggiti, poi chiedi al carceriere cosa è necessario. Dice che hai bisogno di più cellule. Andresti a prendere delle persone a caso per fingere di essere prigionieri e vedere se scappano. Se non lo fanno, allora lo fai vedere al carceriere, e lui è contento. Quindi inizi a costruire i parapetti.
Quindi entrambi risolvono diversi problemi. Agile aiuta a cambiare i requisiti in base alla scoperta delle esigenze degli utenti quando vedono il prodotto svilupparsi nel punto in cui è più facile adattarsi. Si tratta di rilasciare aggiunte stabili interrotte dal progetto generale.
TDD risolve il problema di anticipare il fallimento. Scoperta e correzione dell'errore mentre si verifica in un punto del processo in cui è più semplice da risolvere. Si tratta di testare unità di codice disaccoppiate stabili dal design generale.
È facile vedere TDD come un'estensione di Agile, perché entrambi seguono lo stesso schema, il progresso guidato dall'unità e la revisione. La differenza è che le unità in Agile funzionano esternamente fino ad oggi nel loro complesso, mentre le unità in TDD funzionano come una parte e potrebbero non produrre un prodotto funzionante per la revisione esterna. Entrambi i processi governano esigenze diverse (usabilità vs. correttezza). Dal momento che entrambe funzionano su un processo di sviluppo in unità, entrambi i processi di revisione possono verificarsi in punti simili, con TDD diviso più finemente.
Agile ti obbliga ad affrontare e mitigare i rischi di pianificazione e di qualità ad ogni iterazione. Ad esempio, TDD non è necessario per essere considerato Agile .
Tuttavia, TDD è un'enorme tecnica per mitigare i rischi di qualità, in particolare per un progetto con un numero elevato di iterazioni o persone. In un progetto di questo tipo, TDD aggiungerà alcuni rischi di pianificazione nelle iterazioni iniziali, perché anche i casi di test devono essere scritti. Tuttavia, TDD produce enormi risparmi sui costi nelle iterazioni successive perché attenua continuamente i rischi di qualità. Ad esempio, TDD è raccomandato.