Como obter sucesso nos Workshops de Especificações do BDD?

Hoje tentamos introduzir o BDD em nosso processo de desenvolvimento de software, realizando um workshop de especificação.

Neste workshop, tivemos 2 desenvolvedores, 1 testador e 1 analista de negócios. O workshop durou 1h30 e, no final, conseguimos descobrir alguns cenários do BDD para o nosso novo recurso. Tentamos nos concentrar em encontrar os cenários que poderíamos perder e os difíceis.

No final do workshop, algumas pessoas estavam realmente descontentes com o workshop.

Um desenvolvedor sentiu que desperdiçou seu tempo, pois costumava receber os cenários diretamente pelo analista de negócios e analisá-los com ela. O analista de negócios não se sentiu confiante com a cobertura de nosso cenário (tinha a sensação de que poderíamos ter perdido outras coisas importantes), mas o mais importante era que esse workshop também era uma perda de tempo, pois ela poderia ter descoberto sozinha todos esses cenários. e em um curto período de tempo .

Esse workshop experimental durou 1h30 e, no final, não estávamos confiantes o suficiente sobre o que fizemos ... com certeza poderíamos ter gastado mais tempo com ele, mas honestamente a maioria das pessoas fica exausta após 1h30 de brainstorming para buscar negócios regras do cérebro BA.

Então, minha pergunta é como esse tipo de oficina pode realmente funcionar. Na teoria, como você tem um novo recurso para desenvolver, você coloca a árvore 'amigos' (dev / tester / ba) na mesma sala para que eles possam colaborar juntos na criação dos diferentes requisitos para o novo recurso usando exemplos. Eu posso ver todos os benefícios disso. Especialmente em termos de compartilhamento de conhecimento e visão comum de produto / objetivo final / realizado.

Nossa conclusão deste experimento foi que, na verdade, é mais econômico ter primeiro um BA para trabalhar sozinho nos exemplos e só então ter os cenários a serem revistos / retrabalhados pelos 3 'amigos'. Ao ter o BA para trabalhar por conta própria, na verdade nos sentimos mais confiantes de que perderemos menos coisas + ainda poderemos revisar os cenários posteriormente para verificar novamente. Não achamos que uma sessão de brainstorming / descoberta deliberada única seja suficiente para cobrir seriamente todos os requisitos de um novo recurso. O analista de negócios é realmente a melhor pessoa para esse tipo de coisa. A melhor coisa que podemos fazer é revisar o que ela escreveu e ver se temos um entendimento comum (o que poderia levar a reescrever alguns de seus cenários ou adicionar novos que ela poderia ter perdido).

Então, como você pode fazer isso funcionar efetivamente na prática ?

Se você pode derivar os cenários da descrição, está pronto.

Um antipadrão que muitas vezes vejo no BDD são as pessoas que sentem a necessidade de conversar e anotar todos os cenários em detalhes.

Alguns cenários são tão bem compreendidos que basta derivá-los de uma breve descrição. Por exemplo, se eu disser "Gostaria do recurso de login esta semana", você sabe como deve ser. Você sabe que existem cenários para a senha correta, a senha errada, o nome de usuário errado. Nós realmente não precisamos conversar sobre eles ou capturá-los em detalhes.

Da mesma forma, eu poderia dizer: "Aqui está o formulário para registro do usuário. Precisamos criar novos usuários, permitir que eles editem seus detalhes e se excluam, exceto que a exclusão não deve realmente ser excluída, deve apenas marcá-los como excluídos. para que eles possam recuperar suas contas, se quiserem ".

E você pode perguntar: "A recuperação da conta faz parte desse recurso?"

"Eles podem ser dois recursos, se você quiser."

"Ok, então temos cenários para criar, ler, atualizar, excluir; isso deve ser fácil o suficiente. Vamos falar sobre recuperação de conta; isso parece mais interessante."

Em geral, se a descrição do comportamento for suficiente para a equipe de desenvolvimento derivar os cenários, não será necessário conversar com eles. Você pode fazer isso se houver alguma dúvida, mas você pode apenas querer capturar quais cenários você precisa se lembrar, se você capturar algum.

Se você nunca fez isso antes ou não tem certeza, fale sobre os cenários.

Concentre-se nas áreas incomuns, principalmente se houver recursos que você nunca fez antes. Esses são lugares fantásticos para conversar e escrever exemplos surpreendentes que surgirem. Normalmente, tenho duas perguntas, com base no modelo do BDD:

Dado um contexto
Quando um evento acontece,
um resultado deve ocorrer.

• Existe algum outro contexto que, para o mesmo evento, produza um resultado diferente?
• Existe algum outro resultado que também seja importante?

Se todo mundo na mesa estiver entediado, o recurso pelo qual você está conversando provavelmente será bem compreendido. Muitas vezes basta dizer: "Deveria funcionar como X , mas com Y ". Isso é o que Dan North chama de padrão Ginger Cake ; é como a receita do bolo de chocolate, mas com gengibre em vez de chocolate.

Mesmo que a parte interessada do negócio consiga derivar os cenários, é realmente importante que a equipe de desenvolvimento possa conversar com ele, entender e internalizar seu idioma. Essa linguagem é então transportada para o código, permitindo que eles tenham melhores conversas no futuro e ajudando os novatos no projeto a entender o que está acontecendo. Se os desenvolvedores não conseguirem falar o idioma, eles não o usarão .

Se o interessado ou o analista de negócios realmente não deseja gastar o tempo capturando coisas na sessão, prefiro que os desenvolvedores anotem os cenários em colaboração com os testadores, e depois solicitem que ele os revise. É mais provável que descubra mal-entendidos do que o contrário.

Às vezes, o BDD não funciona.

Outra possibilidade é que você encontre um cenário sobre o qual as partes interessadas do negócio não tenham certeza. "Oh, eu não tinha pensado nisso! Não tenho certeza." Em vez de tentar prender a empresa e puni-la com certeza, pode valer a pena abandonar o BDD neste momento e tentar algo simples para obter algum feedback e fornecer à empresa algo sobre o qual eles possam iterar. Mantenha a mudança fácil e escreva os cenários assim que entender melhor o que está acontecendo.

O BDD bem feito pode realmente ajudar a descobrir lugares de incerteza. Uma vez que cada pena projeto fazendo tem algum aspecto do que há de novo e nunca foi feito antes, não é alguma incerteza lá, em algum lugar. Se você se concentrar em usar os cenários para ajudar a descobrir deliberadamente a ignorância , aprenderá mais rapidamente, e o aprendizado geralmente é uma grande parte do tempo gasto em um projeto.

Além disso, descobri que quanto mais as equipes de desenvolvimento colaboram dessa maneira, mais os negócios estão preparados para confiar nelas com incerteza e mais inovação começa a ocorrer. As empresas inovadoras, por sua própria natureza, têm muita incerteza em seus projetos.

Escrevi um post no Cynefin há algum tempo , o que acho realmente me ajuda a entender onde as conversas serão mais eficazes. Se você ler e entender os quatro domínios, aqui estão as regras que eu uso:

• Coisas simples e complicadas (conhecidas) geralmente são bem compreendidas e você não precisa falar detalhadamente dos cenários.

• Coisas altamente complexas (desconhecidas) não são compreendidas. Você pode descobrir isso falando dos cenários. A falta de certeza significa que o BDD não funcionará aqui, por isso repita algo fácil de mudar e obtenha feedback rápido. Qualquer prática que mantenha suas opções, como o teste AB, também é excelente neste espaço.

• O BDD trabalha brilhantemente no espaço intermediário (conhecível) como um mecanismo para transmitir o conhecimento e descobrir os outros dois espaços. Não é um martelo, e nem tudo é um prego. De fato, se você pode concentrar o tempo gasto conversando em algo, não se trata dos exemplos que pode encontrar; trata-se de encontrar os exemplos que você não pode .

A duração da reunião não é problema seu. Não há problema em que essas reuniões durem muito tempo. Mas todo mundo deveria sair disso se sentindo confiante. Que eles não fizeram é o seu problema.

Eu sugeriria uma breve reunião para discutir um requisito. Agende uma segunda reunião alguns dias depois, para que todos saibam que devem estar preparados até lá.

Então, o BA e o testador devem apresentar seus cenários, porque ambos olham o software de maneiras muito diferentes. Faça com que eles os escrevam em cartões e cole todos em um quadro em algum lugar, pelo menos um dia antes da segunda reunião, deixe que todos olhem no seu próprio tempo e pensem sobre isso. Jogue fora as duplicatas, cole todos os cenários que não foram considerados.

Não jogue fora nada que você discorde, mas marque-o como controverso. Se uma conversa muito breve com a pessoa que a escreveu vai ajudar, faça isso, mas principalmente a salve.

Em seguida, faça sua reunião de planejamento / design. Tenha uma agenda sólida para essa reunião (comece com a pilha de cartas, coloque as contenciosas no topo) e não permita que ela se desvie dos trilhos. Certifique-se de sair dessa reunião com todos os pontos de disputa resolvidos.

Sempre verifique se todos os participantes de uma reunião estão preparados para o assunto dessa reunião!

Nunca use uma reunião para "debater" qualquer coisa juntos. Perde o tempo de todo mundo.

Receita geral para reuniões eficazes:

• alguém prepare os itens a serem discutidos
• exigir que todos os participantes tenham estudado (e não apenas lido) esses itens
• reunir comentários com antecedência e exigir que todos os participantes os estudem (não apenas os leiam)
• realizar a reunião para tomar decisões

Sobre as reclamações ...

Vamos começar com estes:

Um desenvolvedor sentiu que desperdiçou seu tempo, pois costumava receber os cenários diretamente pelo analista de negócios e analisá-los com ela.

Era o que ele estava fazendo no workshop. Então isso parece uma desculpa mal-humorada e ruim para mim. Suspeito que esse desenvolvedor não goste (ou de ambos) do exame minucioso do workshop e de suas restrições de agendamento.

O analista de negócios não se sentiu confiante com a cobertura do cenário (tinha a sensação de que poderíamos ter perdido outras coisas importantes)

Como isso é diferente do que quando ela faz do seu lado e a revista por um desenvolvedor, além do fato de que mais pessoas viram isso? Eu suspeitaria que este é apenas o resultado do workshop, talvez um pouco caótico. Você terá certeza de que possui testes suficientes implementando-os e integrando-os. Você nunca pode ter certeza de ter encontrado todos os bugs e, quando se trata de cobertura, a melhor maneira seria fazer um diagrama deles nas histórias de usuários.

mas, mais importante, sentiu que esse workshop também era uma perda de tempo, pois ela poderia ter descoberto todos esses cenários sozinha e em um período mais curto.

Sim, e inteiramente por conta própria, em seu jardim murado e sem compartilhar conhecimento. Considerando que, ao fazer isso, as oficinas futuras podem ser mais produtivas, pois todos os participantes adquiriram um pouco de conhecimento de como abordar essas coisas.

Talvez a reunião tenha sido lenta desta vez, isso não significa que sempre será. E como pessoal externo, eu teria dado algum treinamento para acertar isso, mais confiança de que a cobertura era melhor em um workshop com 3 participantes com mentalidades diferentes do que com um único ditador.

Além disso, se já havia uma necessidade de um desenvolvedor revisar esses cenários com ela, tenho certeza de que o vaivém é muito mais rápido e eficiente no workshop do que usar o "eu faço minhas coisas sozinho e dou você, você revisa sozinho e volta para mim e vamos fazer isso de novo ".

Sugestões

• Seja positivo e enfatize que, se o processo estiver correto, você melhorará.

• Tente otimizar o workshop e mantê-lo no caminho certo.

• Talvez dê algum espaço para a análise do "lobo solitário", iniciando o workshop com todo mundo criando alguns cenários por conta própria (melhor ainda, antes do workshop), depois triagem e mesclá-los.

E se você não acha que isso é necessário, tudo bem: faça o BA trabalhar sozinho, mas faça a revisão como um workshop, pelo menos. Os mais olhos melhor, para citar Eric S. Raymond 's Lei de Linus :

Given enough eyeballs, all bugs are shallow.

Você já tem algumas respostas muito boas aqui, então vou focar em um pequeno aspecto que até agora foi esquecido. O papel de cada um dos Três Amigos deve poder ser entregue à sessão. Cada um deles oferece valor de maneiras diferentes, cada um entende um conjunto diferente de restrições.

Em geral, o BA deve ser capaz de trazer o principal caminho feliz para a sessão, além de fornecer os principais cenários de falha do ponto de vista comercial. A experiência em teste deve ser capaz de identificar casos extremos e um cenário adicional necessário para provar que o sistema funciona em todas as circunstâncias. O trabalho do desenvolvedor não é realmente adicionar cenários, embora muitas vezes o façam por falhas técnicas, o trabalho deles também garante que você tenha um entendimento completo dos requisitos para transmitir implicações e implementar o requisito com o mínimo de comunicação extra.