Aqui é onde eu acho que o Desenvolvimento Orientado a Comportamento mostra ganhos imediatos, mas não tenho certeza de que o desenvolvimento orientado a teste o faça.
No desenvolvimento orientado por comportamento, você aborda seus tickets de uma maneira diferente: senta-se com a pessoa de negócios e trabalha com ela para definir os comportamentos que esse pedaço de funcionalidade deve ter. Eu descrevo isso em uma entrada no meu blog (o título do post: Comportamentos de escrita ).
Sentar-se com a pessoa de negócios ou com quem ajudará você e eles a entender melhor o que o sistema precisa fazer para que todos fiquem felizes com essa parte da funcionalidade. O que é preciso fazer para poder ser aceito pelo processo de controle de qualidade que você possui.
Definir critérios de teste e, em seguida, gravá-los em seu conjunto de testes automatizado, deve reduzir a quantidade de vaivém que você recebe: alguém alegando que a funcionalidade está quebrada, porque você perdeu alguma coisa (porque você perdeu alguma coisa legitimamente ou porque nunca disse a ela você sobre isso).
Isso também pode ajudar a percepção dos outros sobre sua equipe: se você se sentar e definir o que precisa ser feito no sistema, poderá passar de "idiotas que superengenham tudo e gastam tempo com coisas que não pedimos", para, "pessoas inteligentes que estão apresentando recursos úteis".
TL; DR: o desenvolvimento orientado a comportamento pode mostrar melhorias rapidamente porque é focado no "cliente". O Desenvolvimento Orientado a Testes, para mim, parece ser sobre o teste interno da base de código com a qual "ninguém" se importa e oferece benefícios comerciais menos óbvios. (O Behavior Driven Development tem uma mudança imediata: na sua frente, os engenheiros estão repentinamente passando muito mais tempo com o "cliente" ou o analista de negócios para tentar acertar isso - o que deve ser visto como uma coisa boa. " , eles estão tendo uma reunião sobre o recurso X, o que significa que há progresso nessa frente! ")