Quais argumentos posso usar para "vender" o conceito de BDD a uma equipe relutante em adotá-lo?

Sou um pouco defensor da metodologia Behavior Driven Development (também conhecida como BDD). Aplico o BDD há alguns anos e adotei o StoryQ como minha estrutura de escolha ao desenvolver aplicativos DotNet. Embora eu tenha testado a unidade por muitos anos e tenha adotado anteriormente uma abordagem de teste primeiro, descobri que aproveito muito mais o uso de uma estrutura BDD, porque meus testes capturam a intenção dos requisitos de maneira relativamente limpar o inglês dentro do meu código e porque meus testes podem executar várias asserções sem terminar o teste no meio - o que significa que posso ver quais asserções específicas passam / falham rapidamente sem depurar para prová-lo.

Essa foi realmente a ponta do iceberg para mim, pois também notei que sou capaz de depurar os códigos de teste e de implementação de uma maneira mais direcionada, com o resultado de que minha produtividade aumentou significativamente e que posso determine facilmente onde ocorre uma falha se ocorrer um problema para chegar até a construção da integração devido à saída que entra nos logs de construção. Além disso, a API do StoryQ possui uma adorável sintaxe fluente, fácil de aprender e que pode ser aplicada de diversas maneiras, sem necessidade de dependências externas para usá-la.

Portanto, com todos esses benefícios, você acha fácil introduzir o conceito no restante da equipe. Infelizmente, os outros membros da equipe estão relutantes em olhar para o StoryQ para avaliá-lo adequadamente (sem falar na idéia de aplicar o BDD), e se convenceram a tentar remover vários elementos do StoryQ da nossa estrutura de teste principal, até apesar de originalmente oferecerem suporte ao uso do StoryQ, e mesmo que o código que desejam remover não tenha impacto em nenhuma outra parte do nosso sistema de teste. Fazer isso acabaria aumentando significativamente minha carga de trabalho em geral e contraria a realidade, pois estou convencido, por meio da experiência prática, de que é a melhor maneira de trabalhar em um primeiro teste em nosso ambiente de trabalho específico e só pode levar a maiores melhorias na qualidade do nosso software, dado que eu Foi mais fácil manter o teste primeiro usando o BDD. Para esclarecer ainda mais, a maioria dos testes de unidade que tendemos a ser bastante frágeis e difíceis de manter, uma retração de anos de testes mal aplicados, nos quais uma relutância em seguir um processo orientado a testes fez com que os desenvolvedores voltassem aos velhos hábitos e faça todos os testes no final do projeto (essas mesmas pessoas afirmam ser ágeis!).

Portanto, a questão realmente se resume ao seguinte:

1. Que argumentos eu posso usar para realmente esclarecer que seria melhor para essa equipe usar o StoryQ ou, pelo menos, adotar a metodologia BDD?
2. Você pode me indicar alguma evidência anedótica que eu possa usar para apoiar meu argumento de adotar o BDD como nosso método padrão de escolha?
3. Que contra-argumentos você acha que poderia sugerir que meu desejo de incentivar a equipe a adotar o BDD possa estar errado? Sim, estou feliz por provar que estou errado, desde que o argumento seja sólido.

NOTA : Não estou defendendo que reescrevamos nossos testes na íntegra, mas simplesmente comece a trabalhar de maneira diferente para todos os trabalhos futuros de teste e, de preferência, da maneira como envolvemos nossos clientes.

E para aqueles que desejam aprender mais sobre o BDD, os seguintes links podem ser úteis:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Para os interessados ​​em mais detalhes, somos uma pequena equipe de 4 trabalhando em cerca de 5 grandes projetos. O "teste piloto" para BDD durou cerca de 2 meses inicialmente, com outro período de aproximadamente 4 meses a seguir. A equipe aceitou que eu continuasse trabalhando dessa maneira e fizesse seus próprios testes. Estou no BDD há cerca de 2 anos desde que o julgamento terminou, enquanto os outros se tornaram muito bons em evitar o problema. Em vez de forçar um "confronto" sobre o assunto, estou procurando maneiras de persuadir gentilmente a equipe a se livrar de seus interesses coletivos e reservar um tempo para fazer a sua parte.}

Quais argumentos eu posso usar para realmente esclarecer que seria melhor usar o StoryQ ou, pelo menos, aplicar a metodologia BDD?

"O cliente quer."

Na IMO, você deseja vender o BDD aos seus clientes / especialistas em domínios pelo menos tanto quanto à equipe de desenvolvimento.

O BDD é um processo colaborativo externo em que várias partes interessadas estão envolvidas. Os benefícios do BDD não são apenas para os desenvolvedores inferirem automaticamente seu código de teste a partir de testes de aceitação, eles também residem na cooperação criativa que ocorre entre pessoas técnicas e de negócios para produzir especificações valiosas e bem definidas do comportamento pretendido do sistema.

Oferecer aos clientes / analistas de negócios acesso a uma interface na qual eles podem executar cada especificação executável, controlar seu status e ver a progressão em sua implementação também é muito apreciada.

Há uma apresentação de Dan North sobre como você pode vender o BDD para a empresa: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. Em uma equipe relutante em adotar o BDD, provavelmente não há "argumentos" que você possa usar para "converter" seus colegas em adoção em larga escala.
    
   Eu acho que o melhor que você pode fazer é convencê-los a tentar ("teste de fumaça", "execução a seco", "projeto piloto") - especialmente se você deixar perfeitamente claro que desistirá da ideia se testar os resultados são negativos.
2. Sua abordagem para encontrar evidências anedóticas se encaixa perfeitamente na idéia de convencer a equipe a experimentá-la. Para isso, basta pesquisar na Web algo como "História de sucesso de desenvolvimento orientado a comportamento" e escolher o que parecer mais fácil de usar.
3. Existem alguns contra-argumentos em que posso sugerir que seu desejo de converter os esforços da equipe em BDD pode estar errado.
    
   Nada disso é particularmente construtivo, especialmente do ponto de vista de um "defensor da mudança", mas infelizmente você provavelmente terá que lidar com exatamente esse tipo de retórica ( BTDTGTTS ):
    
   • você não pode garantir que a produtividade geral da equipe melhore
   • você não pode garantir que os esforços investidos na adoção do BDD proporcionem um ROI substancial
   • equipe estava indo suficientemente bem sem BDD, o risco de mudar a abordagem atual não se justifica
   • O Google (ou Microsoft ou IBM - basta preencher o nome de qualquer fornecedor de software "respeitável") está indo bem sem o BDD, o que "prova" que o BDD não é necessário
   • abordagens não BDD não tiveram uma chance justa em testes comparativos
   • O BDD pode estar geralmente bom, mas para este e aquele módulo / projeto não é aplicável

Pela minha experiência, a maneira menos dolorosa de abordar contra-argumentos como listados acima foi executando um teste controlado limitado para uma alteração proposta.

O status "teste limitado" invalida essencialmente três dos quatro argumentos acima, exceto um sobre "fornecedor respeitável", que pode ser combatido ao fornecer evidências anedóticas da história de sucesso (a evidência anedótica provavelmente não funcionará para uma "mudança do big bang", mas para teste limitado é bom o suficiente).

Se a mudança realmente vale a pena e a execução do teste é organizada adequadamente, você notará uma mudança positiva na atitude da equipe e da gerência, tornando a transição para a mudança em grande escala suave e indolor.

Outro benefício da execução limitada do teste é que ele permite esclarecer e ajustar os detalhes do processo de destino sem causar muitos problemas e com menor risco de "danos à reputação" da idéia. Toda vez que participei de tais testes , fiquei agradavelmente surpreso ao descobrir como era fácil mudar para a adoção em larga escala, com os detalhes mais importantes definidos e esclarecidos no teste.

Talvez seja hora de recrutar a gerência. Se você experimentou e obteve resultados sólidos, mas a equipe está hesitando, talvez a gerência precise se envolver.

Isso é especialmente verdadeiro se eles estão prejudicando o membro da equipe mais produtivo da empresa. Esteja preparado para reação. Você pode começar abordando o gerenciamento e procurando que a equipe pare de prejudicá-lo retirando seus casos de teste.