Vendita di TDD alla squadra

Question

Ho fatto TDD negli ultimi 3 anni. Eravamo una piccola azienda e avevamo un supporto molto solido per la maggior parte degli aspetti del processo agile da parte della direzione. Tutti i membri del team di sviluppo sono stati venduti durante il processo. E così, l'investimento iniziale che solitamente richiede per costruire gli impianti è stato accettato sapendo che avrebbe pagato lungo la strada. (Codice che avvia un server http, codice che popola i database SQL prima dei test, ecc.). La documentazione è per lo più avvenuta nei test e le richieste di aiuto sono state solitamente presentate sotto forma di test negativo.

Ora mi sono spostato in un'azienda più grande e, mentre la gestione supporta il processo Agile, i compagni di squadra sono un miscuglio, alcuni lo vedono utile, alcuni lo fanno a causa della gestione e altri non vedono il valore. È stata una sfida convincere le persone a passare un po 'di tempo a costruire infissi o a convincere un membro del team nel modo migliore per aiutarlo, se avesse avuto il tempo di scrivere un test negativo.

Quindi, qual è il modo migliore per vendere TDD a un compagno di squadra titubante? Solitamente le obiezioni sono: "È un costo non necessario", "possiamo sempre scrivere test dopo il fatto per le parti che sono importanti", "è una parola d'ordine, i team lo raccolgono e poi cade di lato mentre inizia la grind pesante" 'ecc.

Answer 1

"il modo migliore per vendere TDD ad un compagno di squadra titubante"

Non è possibile. Non perdere tempo a "vendere".

Invece, investire tempo in "proving".

Fallo e basta. Riuscire. Quando le persone chiedono quale sia il segreto del tuo successo, allora rivela il TDD. Non prima.

Answer 2

semplice - manutenibilità. TDD ti dà la possibilità di apportare modifiche e vedere dove tali modifiche influenzano il resto del codice. Più grande è la base di codice, più è imperativo che ci siano test per convalidare qualsiasi nuova modifica.

correttezza. Anche se i test possono essere rotti, alla fine raggiungono un punto in cui si accertano che i componenti stiano facendo ciò che dovrebbero. Migliore è lo sviluppatore, più veloce è.

un altro vantaggio è che TDD informa il progetto dei componenti nel sistema. Se stai provando a testare qualcosa, e il test è troppo complicato, probabilmente significa che devi rompere il problema in parti più piccole ...

per venderlo alle persone, tu dici che a lungo andare fa aggiungere nuove funzionalità più economiche e ridurre il rischio di rompere le funzionalità esistenti. Quindi riduce i costi.

Answer 3

Penso che Joel's post spieghi molto bene perché il test è A Good Thing ™.

Non credo che abbia mai usato la frase "TDD", ma ha delle ottime informazioni.

Answer 4

Per l'esitante compagno di squadra, sii paziente, aspetta un'opportunità, poi balza. Nello sviluppo del software ci sarà indubbiamente un problema dove TDD avrebbe prevenuto o mitigato il problema. Essere alla ricerca di una tale opportunità. Lavora con lui/lei per creare un test (s) che avrebbe dovuto essere sviluppato fin dall'inizio. Tuttavia, assicurati di creare il tuo messaggio in modo da non mettere in imbarazzo il tuo compagno di squadra.

Answer 5

Sono d'accordo con S. Lott, non è possibile "venderli" è necessario mostrare il valore.

Uno dei modi più efficaci per farlo è con la programmazione delle coppie. Certo, hai un altro problema di "vendere" convincere le persone che l'accoppiamento è un approccio efficace, ma dopo un po 'di tempo potresti convincere/convertire uno sviluppatore o anche.

TDD era inizialmente un concetto difficile per me, ma ora non riesco a immaginare la programmazione in nessun altro modo.

Answer 6

Mostrare loro questo sito: WeDoTDD.com - casi di utilizzo effettivo del team aziendale. Coloro che stanno praticando con successo TDD in società reali.