Enfatizzando l'importanza del TDD per i clienti

In qualità di capo progetto e, se possibile, in qualsiasi modo, non parlerei nemmeno di TDD con il cliente. Il cliente si preoccupa che il progetto sia finito alla scadenza stabilita in precedenza. Probabilmente non gli interessa se scrivi il tuo progetto usando AWT o Swing, a volte nemmeno se usi Java o .NET. Perché dovrebbero interessarsi a TDD o no-TDD?

Sono d'accordo con Raku che è meglio non parlare di TDD con il cliente. Magari parlagli di TDD dopo aver completato il progetto e ti chiedono come lo hai fatto così bene: -)

Non penso che i progetti TDD richiedano sempre più tempo. Certamente ci vorrà più tempo se la squadra non ha imparato a fare bene TDD . Suggerirei innanzitutto che tu prenditi il tempo per imparare TDD da solo, finché non puoi farlo bene e senza sforzo; quindi condividi la tecnica con la tua squadra solo quando puoi farcela da sola.

Mentre la risposta Raku è corretta - queste decisioni / dettagli dell'attrezzo non riguardano i tuoi clienti / clienti , non sembri apprezzare i fattori di business che devono affrontare i tuoi clienti.

È probabile che capiscano l'importanza della manutenzione, ma altri fattori hanno la priorità.

Un'altra risposta su un'altra domanda ha evidenziato il fattore tempo di mercato per i giochi mobili. È meglio per le aziende avere un software che venderà oggi rispetto a domani, soprattutto se la concorrenza sta sviluppando qualcosa di simile.

È meglio per le aziende avere software utilizzabile in natura rispetto a qualcosa che si trova in laboratorio e che è stato nuovamente testato e ri-testato.

I tuoi clienti decideranno se vale la pena investire e se il loro prodotto ha successo possono reinvestire in manutenibilità, ma in base a tali decisioni devi fare la fila per farlo fare per il costo / budget quotato (se usi TDD, quindi il tempo per il tuo sviluppo è preso in considerazione nelle stime per queste citazioni). Se hai tempo per fare TDD all'interno di tale preventivo e le tue stime, dovresti usare TDD, ma se non hai tempo allora non puoi permetterti di farlo.

"Test minimi di base" sembra che tu non sia interessato alla qualità del prodotto. Questo non ha nulla a che fare con TDD contro non-TDD, ha a che fare con gli standard di qualità della tua squadra.

TDD non è una bacchetta magica, ma penso che sia sicuro dire che se pensi di poter ridurre la quantità di test che fai in modo da poterli consegnare prima, l'unica cosa che fa per il tuo cliente è di dare potenzialmente loro un prodotto di qualità inferiore. Solo tu puoi dire se questo è un rischio accettabile. Consegna un clone di tetris per un tablet Android? È accettabile Scrivere software per attrezzature mediche, non così tanto.

Quindi, prima di parlare di TDD o di non TDD, devi decidere se la qualità è qualcosa che ti interessa o meno. Una volta che decidi di impegnarti a fornire un prodotto di qualità piuttosto che uno che ha "test minimi", allora puoi iniziare a discutere se TDD è il modo appropriato per eseguire i tuoi test. TDD non tratta di quanti test fai, riguarda quando lo fai. Dal suono della tua domanda sei più preoccupato di quanti test fare.

Penso che i clienti amano sapere che segui solide pratiche. A volte capiscono TDD. Potresti lavorare a un progetto secondario esternalizzato da un responsabile IT e preferire consulenti con gli stessi standard.

Non penso che tu possa usare questo come motivo per fatturare più ore rispetto alla tua vita. Il cliente vuole risultati. I rischi di non seguire solide pratiche sono assorbiti da te e non dal cliente. Altrimenti, andranno dove qualcun altro può convincerli che consegneranno. Immagina un carpentiere che vuole farti pagare il doppio perché "misura due volte e taglia una volta".

The result would be a Test After Development which would be very basic minimal tests to please the coverage tools and let the project analyzers have a great Graph .

Non è questo il punto di test. Il test di per sé non aggiunge valore. Se fatto correttamente, vari tipi di test possono migliorare la correttezza, la flessibilità e l'usabilità di un software. Stai vendendo un prodotto, non il processo.

A meno che un progetto sia così piccolo, che possa essere implementato correttamente senza iterazioni, puoi fare buon uso della flessibilità che aggiunge un codice robusto (TDD è uno dei modi più popolari e facili per raggiungere la robustezza). C'è un piccolo sovraccarico nella prima iterazione di una funzionalità, ma è possibile rispondere rapidamente alle modifiche e l'overhead viene ammortizzato molto prima dell'ultima iterazione. Quindi su una scala più ampia di cose, probabilmente sarai più veloce.

Il TDD è ovviamente una metodologia migliore per ridurre la durata del progetto. Aiuta anche lo sviluppatore a muoversi verso il soddisfacimento dei requisiti del cliente per la funzionalità del prodotto.

Se il tuo processo di sviluppo si concentra sulla produzione di codice accuratamente elaborato (tra cui design, unit test, documentazione, controllo della versione, tracciabilità ...), TDD non dovrebbe costare molto più tempo.

Inoltre, TDD consente enormi guadagni di tempo nella manutenzione, soprattutto quando il cliente richiede una nuova funzionalità che richiede un grande refactoring.

Citando Thorbjørn Ravn Andersen:

TDD is an investment in maintenance cost, not initial development.