BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Por que o BDD pode salvar o Agile?

Por que o BDD pode salvar o Agile?

Matt Wynne, fundador da Cucumber Ltd disse no Qcon London 2015 em sua palestra "Como o BDD pode alavancar os benefícios do Agile nas equipes", lutando contra padrões comuns como falta de previsibilidade, comunicação e qualidade.

Trabalhando com empresas que pediram ajuda, Wynne percebeu que estas frequentemente passam por problemas, porquê não compreenderam a diferença entre ser ágil, atingir a agilidade e adquirir alguns tipos de práticas ágeis apenas por seguir uma abordagem cargo cult.

Para lutar contra os pontos incômodos tipicamente encontrados, ele propôs trazer de volta algumas características ágeis eventualmente perdidas. A previsibilidade aumentará se equipes começarem a construir pequenos pedaços do software, comunicação funcionará melhor se equipes colaborarem diariamente e a qualidade melhoraria se as disciplinas técnicas fossem seguidas.

Wynne descreve então, em sua visão, como Behavior-driven development (desenvolvimento orientado a comportamento - BDD) pode ser útil para isso.

De acordo com o Wikipedia:

Behavior-driven development (BDD) é um processo de desenvolvimento de software que emergiu do test-driven development (desenvolvimento orientado a testes - TDD). BDD combina técnicas e os princípios gerais do TDD com idéias vindas do domain-driven desing (projeto orientado a domínio - DDD) e object-oriented analysis and desing (desenvolvimento e análise orientado a objeto) para oferecer equipes de desenvolvimento e gerenciamento de software com ferramentas em comum e um processo compartilhado para colaborar no desenvolvimento de software.

Wynne concentrou sua própria definição no comportamento esperado pelas pessoas que usarão o software.

Praticantes de BDD exploram, descobrem, definem e então entregam o comportamento de software desejado usando conversas, exemplos concretos e automação de testes.

Usando o cone da incerteza, ele mostrou como as pessoas vão de uma fase exploratória, na qual a incerteza é máxima, para uma entrega em que a certeza é tanto quanto possível. As três ferramentas sugeridas para essa jornada são conversas, exemplos concretos e desenvolvimento orientado a testes.

Conversas importam por que software são feito por pessoas, para pessoas. Todo mundo tem uma única perspectiva e todas são importantes. Uma técnica chamada discovery workshop (sessão de descoberta), um "três amigos" para levantar cenários para uma história de usuário, foi proposto para fortalecer a ferramenta de conversa. Exemplos concretos são importantes porque eles fazem sentido para todos, são raízes do problema central fornecendo ajuda na construção de uma linguagem única e uma fonte compartilhada da verdade.

Desenvolvimento orientado a testes são mandatórios porque automatização de testes são sinais de advertência, então o conselho é não esquecer de ouvir o que os testes estão dizendo.

Wynne termina a apresentação relembrando de certo modo as raízes do TDD:

Você não pode permanecer ágil sem código limpo;
Você não pode ter código limpo sem refatoração;
Você não pode ter refatoração sem uma boa automação de testes.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT