BDD no Scrum

BDD – Uma abordagem interessante no Scrum

Bom galera, hoje vou falar um pouco sobre o BDD no Scrum e como estou utilizando em projetos aqui na Sciensa.

BDD - Uma abordagem interessante no Scrum
Fonte: rajnishc.blogspot.com.br

Minha experiência como desenvolvedor Java utilizando BDD para meus testes comportamentais do sistema vem me dando uma luz. As formas como levantávamos as histórias com o P.O. eram muitas vezes massiva e acabava por faltar itens importantes para o projeto.

O BDD facilitou ao saber em detalhes o que deveria ser feito, seus cenários e o que era esperado.

Um único “documento” consistente tanto para o P.O. quanto para o time. Não seria perfeito?

Foi assim que o BDD surgiu dentro dos projetos no qual trabalho e até hoje é uma poderosa ferramenta que utilizamos e que se mostra um diferencial dentro dos projetos da empresa.

Mas o que é o BDD?

Mas o que é o BDD?
Fonte: froglogic.com

Behavior-Driven Development ou Desenvolvimento Orientado por Comportamento:

  • Foco do comportamento que o sistema deve ter;
  • Visa um desenvolvimento focado em testes;
  • Usa uma linguagem comum (como a Ubiquitous Language do DDD);
  • Beneficia tanto o P.O. do projeto quanto o time;
  • Comporta diversos cenários;
  • Possui aspectos do DDD e conceitos fundamentais do TDD.

Ou seja, as narrativas são as histórias com seus devidos cenários, exemplos:

  • Narrativa/História: Cadastro Alunos
  • Para meu sistema de gerenciamento do Aeroclube
  • Eu, como funcionário da secretaria
  • Desejo poder realizar cadastros de novos alunos no sistema

Exemplo:

Cenário I: Cadastro de Aluno

  • Dado que um funcionário selecione a opção Cadastrar Aluno
  • Quando clicar no menu
  • Então deverá ser aberta a tela com os dados para efetuar o cadastro do aluno e os botões Salvar e Cancelar.

Utilizando das palavras chaves (em negrito) o P.O. vai criando as histórias que ele precisa com seus cenários, pontos positivos desta ação:2

  • Cliente vai vendo a cada cenário a complexidade do sistema que ele tem em mente;
  • Cliente vai evoluindo o próprio sistema e criando ou removendo funcionalidades;
  • Time durante a planning tem uma visão mais clara do que pode ser desenvolvido;
  • Erros de compreensão e interpretação são eliminados;
  • Requisitos funcionais e não funcionais se tornam comportamentos funcionais e critérios de aceite;
  • Vocabulário comum a todos;
  • Equipe entende como os comportamentos estarão relacionados entre si;
  • Agilizam as reuniões de Daily, Review e Planning.

Nosso dia a dia

Na Sciensa, toda vez que um membro da equipe ou um cliente entra, passamos um treinamento sobre SCRUM e BDD. Um mentor fica um tempo auxiliando o cliente a escrever os BDDs até que o mesmo já caminhe sozinho. Estes BDDs além de servir como histórias ainda servem para montagem de testes no Frontend e no Backend com Yadda e Cucumber no caso de um tester no time, ou o próprio cliente utiliza o mesmo para validar a entrega do time.

Os BDDs nos fornecem um documento único e poderoso para o P.O., Testers, Programadores com uma linguagem simples e objetiva.

 

Referências:

BREGAIDA, Eduardo. DDD+BDD+TDD+SCRUM. Disponível em http://slides.com/eduardobregaida/deck#/ – Acesso em 01 de dezembro de 2017

BREGAIDA, Eduardo. Do estudo ao sucesso – Passos para sua conquista. Disponível em: https://pt.slideshare.net/eduardo.bregaida/ – Acesso em 01 de dezembro de 2017

BREGAIDA, Eduardo. Scrum – Passos e Desafios. Disponível em: http://javawora.blogspot.com.br/search/label/Scrum – Acesso em 01 de dezembro de 2017

MALIK, Zia. Value of Behavior-Driven Development for Backlog Refinement in Scrum. Disponível em: http://www.scrumalliance.org/articles/500-value-of-behaviordriven-development-for-backlog-refinement-in-scrum – Acesso em 01 de dezembro de 2017

 
Eduardo Bregaida

Eduardo Bregaida

Desenvolvedor desde 2003, Java desde 2004, Scrum Master desde 2009. Palestrante de tecnologias e metodologias de desenvolvimento de software em diversos eventos, ainda consegue tempo para ser piloto de avião nas horas vagas.

1 comment

Deixe uma resposta

  • Sensacional! Creio que é por este caminho que devemos ir.

    Não só desenvolvedores, mas TODO MUNDO que trabalha com PRODUTOS tem muito a ganhar com esse mindset.

    Documentação em massa com milhões de páginas que só burocratiza e dificulta a evolução do produto devem morrer para dar lugar a esse tipo de abordagem: informações concisas que une de verdade todos envolvidos no produto falando a “mesma lingua”.

    Matando de vez o problema da “torre de babel” que temos a décadas.
    Parabéns pelo artigo!!!

     

Your Header Sidebar area is currently empty. Hurry up and add some widgets.

%d blogueiros gostam disto: