Enfatizando a importância do TDD para os clientes

Como líder de projeto e, se possível, de qualquer forma, eu nem falaria sobre o TDD com o cliente. O cliente se importa com o término do projeto no prazo que você concordou antes. Eles provavelmente não se importam se você escreve seu projeto usando AWT ou Swing, às vezes nem mesmo se você usa Java ou .NET. Por que eles deveriam se preocupar com TDD ou sem TDD?

Concordo com o Raku de que é melhor você não falar sobre o TDD com seu cliente. Talvez conte a eles sobre o TDD depois que você completou o projeto e eles perguntam como você o fez tão bem: -)

Eu não acho que os projetos de TDD sempre levem mais tempo. Eles certamente levarão mais tempo se a equipe não aprender a fazer bem o TDD . Gostaria de sugerir que, primeiro, você aproveite o tempo para aprender o TDD sozinho, até que possa fazê-lo bem e sem esforço; então você compartilha a técnica com sua equipe somente quando você pode fazer isso sozinho.

Embora a resposta do Raku esteja correta - essas decisões / detalhes do documento não afetam seus clientes / clientes , você não parece apreciar os fatores comerciais que seus clientes enfrentam.

É provável que eles entendam a importância da manutenção, mas outros fatores têm prioridade.

Outra resposta em outra pergunta destacou o fator tempo para comercializar jogos para dispositivos móveis. É melhor que os negócios tenham software para vender hoje do que amanhã, especialmente se a concorrência estiver desenvolvendo algo semelhante.

É melhor para as empresas ter software utilizável na natureza do que algo que está no laboratório sendo testado e testado novamente.

Seus clientes decidirão se o investimento vale a pena e, se o produto deles for bem-sucedido, eles poderão reinvestir em manutenção, mas com base nessas decisões você precisa seguir a linha para fazer o orçamento / orçamento (se usar TDD, então o tempo para o seu desenvolvimento é calculado nas estimativas para essas citações). Se você tem tempo para fazer TDD dentro dessa citação e suas estimativas, você deve usar TDD, mas se você não tiver tempo, então você não pode se dar ao luxo de fazê-lo.

"Testes mínimos muito básicos" parece que você não está preocupado com a qualidade do produto. Isso não tem nada a ver com TDD versus não-TDD, tem a ver com os padrões de qualidade de sua equipe.

O TDD não é uma mágica, mas acho que é seguro dizer que, se você acha que pode reduzir a quantidade de testes que faz para entregar mais cedo, a única coisa que o cliente faz é dar eles um produto de menor qualidade. Só você pode dizer se isso é um risco aceitável. Entregando um clone de tetris para um tablet android? É aceitável. Escrevendo software para equipamentos médicos, não tanto.

Então, antes de discutir TDD ou não-TDD, você precisa decidir se a qualidade é algo que lhe interessa ou não. Uma vez que você decide comprometer-se a entregar um produto de qualidade ao invés de um que tenha "testes mínimos", então você pode começar a discutir se o TDD é a maneira apropriada de fazer seus testes. TDD não é sobre quantos testes você faz, é sobre quando você faz isso. Pelo som da sua pergunta, você está mais preocupado com a quantidade de testes a fazer.

Acho que os clientes gostam de saber que você segue práticas sólidas. Às vezes eles entendem TDD. Você pode estar trabalhando em um projeto paralelo terceirizado por um gerente de TI e preferir consultores que tenham os mesmos padrões.

Eu não acho que você possa usar isso como um motivo para faturar mais horas em comparação com a sua campanha. O cliente quer resultados. Os riscos de não seguir boas práticas são absorvidos por você e não pelo cliente. Caso contrário, eles vão onde alguém pode convencê-los de que eles vão entregar. Imagine um carpinteiro querendo cobrar o dobro porque eles "medem duas vezes e cortam uma vez".

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 .

Esse não é o ponto de teste. O teste em si não agrega nenhum valor. Se feito corretamente, vários tipos de testes podem melhorar a correção, flexibilidade e usabilidade de um software. Você está vendendo um produto, não o processo.

A menos que um projeto seja tão pequeno, que possa ser implementado adequadamente sem iterações, você pode fazer bom uso da flexibilidade que um código robusto adiciona (TDD sendo uma das maneiras mais populares e fáceis de obter robustez). Há uma pequena sobrecarga na primeira iteração de uma funcionalidade, mas você pode responder às alterações rapidamente e a sobrecarga é amortizada muito antes da última iteração. Então, em uma escala maior de coisas, você provavelmente será mais rápido.

O TDD é, obviamente, uma metodologia melhor para tornar o cronograma do projeto mais curto. Ele também ajuda o desenvolvedor a avançar para atender aos requisitos do cliente quanto à funcionalidade do produto.

Se o processo de desenvolvimento se concentrar na produção de código cuidadosamente elaborado (incluindo design, teste de unidade, documentação, controle de versão, rastreabilidade ...), o TDD não deve custar muito mais tempo.

Além disso, o TDD permite grandes ganhos de tempo em manutenção, principalmente quando o cliente solicita um novo recurso que precisa de uma grande refatoração.

Citando Thorbjørn Ravn Andersen:

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