Jefferson Girão

Behaviour-Driven Development (BDD) ou Desenvolvimento Dirigido por Comportamento é uma evolução no pensamento por trás do Test Driven Development (TDD) e Acceptance Test Driven Planning.

O objetivo é dar ao TDD e o DDD (Domain Driven Design) uma visão integrada, fazendo o relacionamento entre essas duas abordagem ficar mais evidente de forma que o desenvolvimento seja focado em entregar algo de valor para o negócio de forma priorizada e verificável.

Para que esse objetivo seja alcançado é definido um vocabulário comum (Ubiquitous Language para pessoas familiarizadas com o conceito de DDD) que une quem entende de tecnologia com as pessoas que entendem do negócio. A idéia é que gerentes, usuários, analistas, desenvolvedores, testadores, enfim, todos envolvidos no projeto se expressem nos mesmos termos sobre o sistema em desenvolvimento.

O BDD apresenta um framework baseado em três princípios:

1. A área de negócios e a de tecnologia precisam se referir a mesma parte do sistema da mesma forma
- Tudo é comportamento

2. Toda parte do sistema precisa ter um valor identificável e verificável para o negócio
- Valor de negócio

3. Analisar, projetar e planejar tudo de cima a baixo tem retorno decrescente.
- O suficiente é suficiente

Se você está achando que BDD é apenas um novo nome para uma série de boas práticas existentes, você não está de todo errado. O objetivo do BDD é juntar todas essas boas práticas existentes sob uma só bandeira com uma terminologia consistente e sem ambiguidades.

User Story (História do Usuário)

“Uma User Story descreve funcionalmente o que será valioso para os usuários e aos compradores de um software.” Mike Cohn

Uma User Story precisa ser

I ndependente
N egóciável
V aliosa ao comprador
E stimável
S mall (pequena)
T estável

Story Card

No processo do BDD um especialista no assunto tratado(geralmente um usuário comum) trabalha com um analista de negócios para identificar um requisito de negócio. Este requisito é expresso utilizando um cartão.

A idéia da User Story ser escrita em um cartão ao invés de outra mídia permite nos manter no princípio Small (que a Story seja pequena). Se uma User Story ultrapassar os limites de um cartão talvez já seja hora de desmembrá-la.

Na escrita da User Story utilizamos o seguinte modelo:

Como um [pessoa ou papel desempenhado]

Eu quero [funcionalidade]

Para [benefício ou valor dessa funcionalidade ao negócio]

No cartão definimos também os critérios para a sua aceitação (Acceptance Criterias). Uma User Story só estará pronta quando todos seus critérios de aceitação forem atendidos.

Exemplo de Story Card:

Como um autor
Eu quero adicionar e gerenciar posts
Para blogar

Nota: Um post precisa ter nome, conteudo e status
Nota: O status de um post pode ser PUBLICADO ou NAO_PUBLICADO
Nota: Um post é criado com o status inicial NAO_PUBLICADO

No nosso próximo post veremos o conceito de Cenário de utilização e tornaremos uma User Story executável em projeto Rails através do Cucumber

Fontes:
http://behaviour-driven.org/
http://www.milfont.org/tech/2009/03/29/palestra-behaviour-driven-development/
User Stories Applied - Mike Cohn

This entry was posted on quinta-feira, maio 28th, 2009 at 11:47 am and is filed under bdd, desenvolvimento. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.