Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Trabalhando com requisitos geis
Utilize histrias de usurio com Scrum e Behaviour-Driven Development
Carlos Alberto Tristacci
carlos@tristacci.com.br
Consultor de TI e articulista de portais e
revistas sobre Gerenciamento de Projetos
e Engenharia de Software. Bacharel em
Administrao pelo IESB, Especialista em
Anlise de Sistemas Orientados a Objetos
pelo IESB. O foco principal de seu trabalho
no gerenciamento de projetos, anlise de
negcios e no desenvolvimento de softwa-
re, atuando na liderana de equipes e no
coaching de mtodos geis. Membro da
Agile Alliance, Scrum Alliance, Scrum.org,
PMI, IIBA e ISACA.
6 Engenharia de Software Magazine - Trabalhando com requisitos geis
Requisitos geis:
O desenvolvimento de projetos de software con-
tinua passando por adaptaes significativas. Nos
ltimos anos tem-se observado ao crescimento da
aplicao de conceitos de agilidade em atividades
do desenvolvimento. Talvez o principal objetivo
desses conceitos possa ser resumido no fato de
entregar rapidamente as necessidades de maior
valor agregado para o cliente. Para isso, o paradig-
ma gil foca naquilo que essencial no desenvol-
vimento do projeto, evitando assim o uso muitas
vezes excessivo de documento durante o projeto.
O Behaviour-Driven Development (Desenvol-
vimento Guiado por Comportamento) tem por
objetivo ajudar o desenvolvimento na entrega
priorizada, com valor de negcio verificvel, for-
necendo um vocabulrio comum que abrange as
reas de negcio e de tecnologia. Reuni ideias do
Test-Driven Development (o qual auxilia o desen-
volvedor a criar cdigo de alta qualidade, por meio
de testes de unidade escritos antes da implemen-
tao do cdigo), Acceptance Test Driven Planning
(escrever testes durante a reunio de planejamen-
to da iterao) e Domain-Driven Design (DDD).
O test-driven development se refere a uma tcnica
de desenvolvimento de software que se baseia em
ciclos curtos de desenvolvimento onde para cada
ciclo o desenvolvedor escreve um caso de teste au-
tomatizado. Feito isso, o cdigo da funcionalidade
elaborado e apenas aprovado quando passar com
sucesso no caso de teste definido anteriormente.
Normalmente, um ciclo de desenvolvimento utili-
zando o TDD considera as seguintes atividades: de-
finir um teste, executar os testes, escrever o cdigo,
executar novamente os testes, refatorar o cdigo e
repetir o processo at que todo cdigo seja aprova-
do pelos casos de teste escritos.
Neste contexto, este artigo retrata a forma de
documentar requisitos com foco em testes de
aceitao e com uma linguagem comum entre
especialistas de domnio e equipe de desenvolvi-
mento. A abordagem utilizada baseada em inte-
grao entre o Behaviour-Driven Development e o
Scrum. Este ltimo define uma maneira simples e
repetvel de gesto do trabalho que pode ser uti-
lizada para o desenvolvimento de novos projetos
ou produtos.
Em que situao o tema til:
Para quem tem como objetivo trabalhar com os
requisitos em um ambiente gil, com a documen-
tao na medida certa para cada fase do processo
de desenvolvimento de software, com foco na
modelagem colaborativa.

E
ric Evans, em seu livro Domain-Driven Design, destaca
que muitas coisas podem fazer um projeto perder seu
rumo: a burocracia, objetivos pouco claros e a falta
de recursos, para citar alguns. Mas a abordagem dada ao
projeto que, em grande parte, determina at que ponto os
softwares podem se tornar complexos. Quando a complexida-
de foge do controle, os desenvolvedores j no podem enten-
der o software bem o suficiente para alter-lo ou expandi-lo
com facilidade e segurana.
Cada software est relacionado a alguma atividade ou in-
teresse do seu usurio. Essa rea de interesse do usurio o
domnio do software. Os domnios dos softwares geralmente
tm pouco a ver com computadores. Por isso, para criar
softwares que tenham valor para as atividades desempenha-
das pelos usurios, a equipe de desenvolvimento deve trazer
consigo um conjunto de conhecimentos relacionados a essas
atividades. Mas a quantidade de conhecimento necessria pode
ser estarrecedora. O volume e a complexidade de informao
podem ser imensos. Modelos so ferramentas para atacar
essa sobrecarga. Um modelo uma forma de conhecimento
seletivamente simplificada e conscientemente estruturada. Um
modelo adequado faz com que as informaes tenham sentido
e se concentra em um problema.
Outro aspecto relevante a linguagem utilizada. Especia-
listas de um domnio possuem um entendimento limitado do
vocabulrio tcnico usado no desenvolvimento. J os desenvol-
vedores, por outro lado, podem entender e discutir o sistema
em termos descritivos e funcionais, desprovidos do significado
transmitido pela linguagem dos especialistas.
Em meio a essa diviso lingustica, os especialistas de um
domnio descrevem vagamente o que querem. Os desenvol-
vedores, lutando para entender um domnio novo para eles,
entendem tudo vagamente.
Por este motivo, um processo sem uma linguagem comum,
faz com que desenvolvedores tenham que traduzir para os
especialistas do domnio. Esses especialistas traduzem entre
cada desenvolvedor e tambm com outros especialistas do
domnio. At mesmo os desenvolvedores traduzem uns para
os outros. A traduo confunde os conceitos do modelo, o que
leva a uma refatorao destrutiva do cdigo.
O custo de toda a traduo, alm do risco de entendimento
errado, simplesmente muito alto. Por este motivo, um projeto
precisa de uma linguagem em comum. Essa linguagem deve
ser baseada no modelo e deve ser usada entre os desenvolve-
dores para descrever no s artefatos do sistema, mas tarefas
e funcionalidades.
Existem maneiras sistemticas de pensar que podem ser
empregadas pelos desenvolvedores na busca por novas vises
e pela gerao de modelos eficazes. Uma destas maneiras o
Behaviour-Driven Development (BDD) Desenvolvimento
Guiado por Comportamento , que tem por objetivo ajudar o
desenvolvimento na entrega priorizada, com valor de negcio
verificvel, fornecendo um vocabulrio comum, ou linguagem
ubqua, que abrange a rea de negcio e a rea de tecnolo-
gia. Reunindo ideias do Test-Driven Development (TDD),
AgiLidAdE
do Acceptance Test Driven Planning (ATDP) e do Domain-
Driven Design (DDD) em um todo integrado, tornando a
relao entre estas duas abordagens mais evidentes.
O TDD ajuda desenvolvedores a criar cdigo de alta
qualidade, por meio de testes de unidade escritos antes
da implementao do cdigo-fonte para modelar o design
que se deseja usar. Isto ajuda a evitar defeitos durante essa
implementao, evitando tambm que atividades futuras
possam afetar as j desenvolvidas.
No entanto, os clientes ou especialistas de domnio raramente
tm interesse em cdigo. Eles tm interesse em softwares que
os ajudam a ser mais produtivos, ganhar mais dinheiro, manter
ou melhorar a capacidade operacional. Ou seja, necessrio
entregar software que suporte as funes de negcio ou neces-
sidades de mercado. ATDD o que ajuda os desenvolvedores a
criar software de alta qualidade que atenda as necessidades de
negcio de uma forma confivel como TDD ajuda a garantir a
qualidade tcnica do software. Mas agora cobrindo o compor-
tamento, descrevendo os requisitos em histrias de usurios e
no somente no design do cdigo.
O ATDP traz a abordagem de escrever testes durante a reu-
nio de planejamento da iterao, utilizando o ATDD como
principal prtica para escrever testes. Desta forma, especia-
listas de domnio e equipe de desenvolvimento definem os
comportamentos esperados para cada funcionalidade do
sistema e os testes de aceitao, para definir quando a funcio-
nalidade est pronta.
O BDD uma tcnica de desenvolvimento de software
cuja amplitude se estende s atividades de levantamento de
requisitos, design, documentao, verificao e validao,
tratando-as de modo unificado, disciplinado e com foco em
qualidade e em entrega rpida de software de valor. BDD
encoraja e fornece um ambiente propcio colaborao entre
desenvolvedores e especialistas de domnio em um projeto
de software.
Apesar de Dan North demonstrar interesse em transformar
o BDD em uma metodologia inteira, no artigo Behaviour-
Driven Stories ele fornece apenas uma forma de utilizar a
linguagem ubqua e no fornece demais processos necessrios
ao desenvolvimento de software. Sendo assim, este artigo
apresentar como trabalhar com requisitos utilizando o BDD
e o framework Scrum.
Scrum uma maneira simples e repetvel de gesto do tra-
balho que pode ser usado para projetos ou produtos. Ele foi
originalmente projetado para o trabalho de desenvolvimento
de software, mas no especfico para este fim e, por isso, pode
ser utilizado para gerenciar qualquer trabalho. Alm disso, o
Scrum muito difundido na comunidade gil.
Assim, o Scrum foi escolhido para ajudar no entendimento
da aplicao dos processos de engenharia de requisitos em um
contexto gil, demonstrando a forma de definir e documentar
os requisitos durante seus diversos eventos.
A partir de agora sero apresentadas um conjunto de prticas
que podem ser utilizadas no apoio s atividades de requisitos
em cenrios geis de desenvolvimento.
Edio 58 - Engenharia de Software Magazine 7
Definir a viso do produto
De acordo com o Scrum, inicialmente definida uma viso
que orientar todos os envolvidos sobre o que deve ser de-
senvolvido, tendo o dono do produto como a principal fonte
de informao do domnio, direcionando a equipe de desen-
volvimento de acordo com seus objetivos estratgicos para
o produto. A equipe de desenvolvimento, por sua vez, deve
fornecer as informaes tcnicas necessrias formulao do
documento. Alm disso, todas as pessoas tomam conhecimen-
to da criao do produto para que possam contribuir com a
definio da viso.
Ser capaz de antever como um novo produto ou a sua prxima
verso deve se parecer e se comportar essencial para chegar
ao objetivo. Esta anteviso resulta em um esboo do produto
futuro. A viso atua como a meta abrangente, reanimando e
orientando as pessoas, e a razo de ser do produto. A viso
descreve por que o projeto est sendo realizado e qual o estado
final desejado.
A viso do produto geralmente concisa se passar pelo teste
do elevador de Moore. A declarao de elevador ou persuaso
no elevador um gamestorming (ver Nota do DevMan 1) criado
por Geoffrey Moore que pode ser jogado individualmente ou
por pequenos grupos de trabalho. Tem por objetivo desenvol-
ver e comunicar a viso de algo, devendo ser curta o suficiente
para ser comunicada em uma subida fictcia de elevador, toda-
via, deve conter uma descrio convincente do problema que
se est solucionando, para quem ir solucionar, e um benefcio
importante que o diferencie das outras ideias.
Nota do DevMan 1
Gamestorming: um conjunto de prticas co-criadas a partir de pessoas inova-
doras de diversas empresas em diversos lugares do mundo.
Este gamestorming envolve uma fase de gerao e uma fase
de formao. Para preparar a fase de gerao, responda as
seguintes perguntas:
Quem o cliente-alvo?
Qual a necessidade do cliente?
Qual o nome do produto?
Qual a sua categoria no mercado?
Qual seu benefcio mais importante?
Quem ou o que a concorrncia?
Qual o diferencial nico do produto?
Esses se tornaro os elementos da persuaso no elevador,
que ser desenvolvida na fase de formao, seguindo a se-
guinte estrutura:
PARA (cliente-alvo);
QUE (necessidade do cliente);
O (nome do produto) a (categoria no mercado);
8 Engenharia de Software Magazine - Trabalhando com requisitos geis
QUE (o benefcio-chave do produto, compelindo a razo
de comprar);
EM COMPARAO (nome da concorrncia);
NOSSO PRODUTO (diferencial nico).
Uma viso de produto definida pela declarao de elevador
estimula os membros da equipe de produto a focar sua viso,
anteriormente diferente, em uma forma concisa e textualmente
curta. Por exemplo:
PARA assinantes;
QUE necessitam acesso ao contedo do assinante de qual-
quer lugar;
A Revista Digital uma revista eletrnica;
QUE oferece contedo especializado sobre tecnologia da
informao;
EM COMPARAO ao atual formato impresso da revista;
NOSSO PRODUTO possibilita o acesso atravs de qualquer
dispositivo, seja ele um computador, tablet ou smartphone.
Caixa de viso do produto
Esta ferramenta tem como objetivo criar a viso do produto
como se fosse um software de prateleira, estimulando a equi-
pe de projeto e de produto na criao de uma imagem que
represente o mesmo.
Na atividade de desenho da caixa, a equipe inteira, incluindo
os membros da equipe de clientes de produto, divide-se em
grupos de quatro a seis pessoas. Suas tarefas sero desenhar
a caixa do produto, frente e verso. Na frente deve ser definido
o nome do produto e de trs a quatro caractersticas-chave
para vender o produto. No verso deve haver uma descrio
detalhada das caractersticas e instrues de operao.
Aps os grupos conclurem as caixas do produto, as mesmas
devem ser apresentadas e os grupos devem discutir sobre
suas diferentes vises sobre o produto e condens-las em uma
nica viso que todos concordem. Esse exerccio ajuda a gerar
muitas informaes boas, esclarecendo o propsito para qual
o produto est sendo criado, alm de ser divertido e, tambm,
ajudar a criar coeso na equipe. A Figura 1 mostra um exemplo
de caixa do produto.
Figura 1. Exemplo de Caixa de Viso do Produto

Arquitetura do produto
O objetivo da arquitetura de produto definir um esqueleto
inicial para guiar tanto o trabalho tcnico quanto a organiza-
o de pessoas que executam o trabalho tcnico. A inteno
comunicar o contexto geral equipe de desenvolvimento e no
limitar o projeto, pois no desenvolvimento gil a arquitetura
um guia, e no uma camisa de fora.
A modelagem gil incentiva esboos estruturais para criar
uma viso geral da abordagem e ajudar a determinar estima-
tivas de custo e cronograma, seguida por uma evoluo na
arquitetura e no design.
Uma estrutura analtica de funcionalidades Feature Bre-
akdown Structure (FBS) pode ser usada para ilustrar um
modelo de arquitetura de produto. Muitas representaes
da arquitetura so teis para as equipes tcnicas, mas a FBS
serve para a comunicao entre o dono do produto e a equipe
de desenvolvimento.
A FBS, a partir da construo de um modelo geral, tem
as regras de negcio identificadas e decompostas em aes
menores. Cada ao uma funcionalidade do sistema. Essas
funcionalidades tambm so conhecidas como funes de
valor para o cliente e podem ser expressas no formato de
histrias de usurio.
Exemplo:
Acesso
- Autenticao
- Alterar senha
- Recuperar senha
Usurio
- Consultar Usurio
- Cadastrar Usurio
- Alterar Usurio
Assinatura
- Consultar Assinatura
- Cadastrar Assinatura
- Alterar Assinatura
Definio de preparado
A definio de preparado deve deixar claro quando um
requisito est com o detalhamento necessrio, e somente o
necessrio, para ser desenvolvido. Um item preparado deve ser
claro, vivel e testado. Uma histria de usurio clara se todos
os membros da equipe de desenvolvimento tm uma compre-
enso compartilhada sobre ela. Escrever histrias de usurio
de forma colaborativa, adicionando critrios de aceitao para
as que tiverem prioridade mais alta facilita a clareza.
A histria vivel se ela pode ser concluda em uma Sprint,
de acordo com a definio de pronto. Isto implica em duas
coisas: o item deve ser pequeno o suficiente e no deve ser
muito complexo.
Um item testvel se existe um modo eficaz para determinar
se a funcionalidade funciona conforme o esperado. Critrios de
aceitao asseguram que cada histria pode ser testada.
A partir desta conceituao podemos definir o que deve
ser preparado para que a equipe de desenvolvimento tenha
AgiLidAdE
a quantidade de informaes necessrias para executar suas
atividades e atingir o objetivo da Sprint.
Para ajudar nesta atividade, os membros da equipe devem
responder constantemente a pergunta: Quais so os processos
e a documentao que devem estar disponveis para neces-
sidade de desenvolvimento?.
As histrias de usurio que sero apresentadas neste artigo
so uma forma de entregar informao para a equipe de
desenvolvimento e poderiam estar declaradas como itens da
definio de preparado.
Definio de pronto
A definio de pronto uma simples lista de atividades (escre-
ver cdigo, testes unitrios, testes de integrao, documentos
de projeto, etc.) que adiciona valor verificvel/demonstrvel
ao produto. Focar nas atividades permite que a equipe se
concentre no que deve ser concludo, eliminando atividades
desnecessrias que s complicam os esforos de desenvolvi-
mento de software.
Scrum pede que as equipes entreguem software potencial-
mente entregvel no final de cada sprint. Software potencial-
mente entregvel uma funcionalidade que pode ser liberada
para os usurios finais, a critrio do dono do produto, que
esteja de acordo com a definio de pronto. Por exemplo: os
itens do backlog do produto devem ser trabalhados conforme
a definio de pronto:
Em conformidade com os navegadores:
- Internet Explorer 8+;
- Safari 5+;
- Google Chrome 20+;
- Mozilla Firefox 14+;
- Opera 11+.
Em conformidade com os dispositivos (responsivo):
- Apple iPhone;
- Apple iPad
- Samsung Galaxy SI.
Passado nos testes de aceitao
Documentao
- Atualizao das Histrias de Usurio na Wiki;
- Atualizao do Manual do Usurio.
Rodando em Ambiente de Homologao.
Definir o backlog do produto
O objetivo de criar um backlog do produto expandir a viso
do produto, atravs de um processo evolutivo de definio
das necessidades, dentro de uma lista de funcionalidades do
produto, ou backlog.
Na fase de anteviso, a equipe cria uma estrutura analtica
do produto na qual as funcionalidades so identificadas. Na
fase de especulao, a equipe expande essa lista, e para cada
funcionalidade, cria um ou mais cartes de histria que con-
tm informaes bsicas de descrio, estimativa, priorizao
e custo.
Ao documentar os requisitos de um sistema a equipe deve
ter cuidado, pois quando algo escrito, parece oficial, formal e
Edio 58 - Engenharia de Software Magazine 9
definitivo, e faz com que a equipe desenvolva o software sem
questionar o que foi escrito e sem revisar o significado, alm
de diminuir a responsabilidade compartilhada da equipe.
Estas desvantagens da comunicao escrita no querem di-
zer que se deve abandonar os documentos de requisitos por
escrito. Em vez disso, devem-se usar documentos quando for
apropriado. Uma vez que o manifesto gil descreve software
funcionando mais que documentao abrangente, o desenvol-
vimento gil foi mal interpretado como contra a documentao.
O objetivo no desenvolvimento gil encontrar o equilbrio
certo entre documentao e discusso.
As histrias de usurio so a melhor maneira de mudar o foco
Figura 2. Modelo de carto
da redao dos requisitos para a sua discusso. Uma histria
de usurio uma descrio curta e simples de um requisito
contada a partir da perspectiva do especialista de domnio. Algumas pessoas podem considerar o por que desneces-
srio. No entanto, importante deixar explcito o motivo pelo
Histrias de usurio qual o recurso da histria importante. Muitas vezes, quando
Histrias de usurios so originrias do extreme program- h dificuldade em justificar a existncia de uma histria,
ming, mas podem ser facilmente utilizadas para coleta de por que ela no importante. Em uma conversa, responder
requisitos em qualquer processo de desenvolvimento gil. esta pergunta pode ajudar o cliente a analisar se a mesma
No XP, histrias de usurio so muitas vezes escritas pelo realmente importante.
cliente, integrando o cliente diretamente no processo de de- Alm disso, descrever o por que pode influenciar a forma
senvolvimento. Em Scrum, o dono do produto (product owner), como um recurso deve funcionar e pode ajudar a descobrir ou-
muitas vezes escreve as histrias do usurio, com a entrada tros recursos que sejam teis e apoiem os objetivos de negcio.
dos clientes, partes interessadas e da equipe. No entanto, na A Figura 3 exemplifica um carto de histria de usurio.
prtica, qualquer membro da equipe com conhecimento de
domnio suficiente pode escrever histrias de usurios, mas
cabe ao dono do produto aceitar e priorizar essas histrias no
backlog do produto.

Aspectos da histria de usurio

Ron Jeffries (2001) destaca trs importantes aspectos das his-
trias de usurio: Carto, Conversa e Confirmao. Enquanto o
carto contm a descrio da histria, os detalhes so acertados
durante a conversa e recordados durante a confirmao.

Carto
Histrias de usurio so tradicionalmente escritas em um
carto. Um carto no contm toda a informao que constitui
o requisito. Ao invs disso, possui apenas o texto suficiente
para identificar a necessidade e para lembrar o que deve ser
implementado. Notas, estimativas, observaes, coment-
rios, prioridade e custo, entre outras informaes, podem ser
escritas.
Dan North (2006), na tentativa de definir uma linguagem
nica para a anlise, desenvolveu um modelo para histria
de onde deve se concentrar em quem, o que e por que de um
recurso, e no como, conforme representado na Figura 2.
Onde o que a funcionalidade do sistema, o por que o
benefcio ou valor da funcionalidade para o negcio e quem
a pessoa (ou papel) que vai se beneficiar com a funcionalidade.
Tendo como vantagem deste modelo a de obrigar a identificar
o valor de entrega de uma histria. Isto ajuda a identificar
histrias que no agregaro valor ao negcio, tornando fcil
retir-las do escopo.
Figura 3. Exemplo de carto
Conversa
Detalhes que podem surgir durante a comunicao do re-
quisito do cliente para a equipe de desenvolvimento. Estes
detalhes iro esclarecer o objetivo da histria.
Confirmao
O cliente define com a equipe de desenvolvimento quando
a histria de usurio pode ser considerada pronta. Aqui se
tem os critrios de aceitao que confirmam se a histria de
usurio est se comportando de acordo com os requisitos.
Detalhes que j foram determinados atravs de conversas se
tornam testes.
Testes de aceitao definem as respostas que a funcionalida-
de deve fornecer de acordo com cada utilizao por parte do
usurio. Segundo Teles (2006), os testes de aceitao devem ser

10 Engenharia de Software Magazine - Trabalhando com requisitos geis

 AgiLidAdE

detalhados para fornecer o mximo de informaes aos desen- Durante a Sprint:

volvedores que faro a manuteno do sistema no futuro e para
validar a funcionalidade ao mximo de modo a assegurar que
ela esteja funcionando corretamente.
Segundo North (2006), o comportamento de uma histria
simplesmente seu critrio de aceitao. Se o sistema cumpre
todos os critrios de aceitao, ele est se comportando corre-
tamente. Se isso no acontecer, no est. Por este motivo, Dan
North criou um modelo para capturar os critrios de aceitao
de uma histria:
Dado [algum contexto inicial];
Quando [algum evento ocorrer];
Ento [verificar resultados];
Para ilustrar, vamos utilizar como exemplo a autenticao
de um usurio:
Funcionalidade: Autenticao do assinante;
Como assinante;
Quero autenticar no sistema;
Para que eu possa acessar o contedo do assinante.
Para que seja possvel definir se a histria est pronta,
necessrio verificar diversos cenrios. O usurio pode ser um
assinante vlido e autenticar no sistema, o usurio pode errar
sua senha ou pode estar com sua assinatura expirada. Existem
outros cenrios possveis, mas com estes possvel demonstrar
o modelo dado-quando-ento, com os seguintes cenrios:
Cenrio: Acesso a rea do assinante
- Dado que estou na tela de autenticao;
- E possuo um usurio registrado;
- E possuo uma assinatura vlida;
- Quando informo usurio
- E informo senha;
- E clico em autenticar;
- Ento visualizo a rea do assinante.
No so feitas mudanas que podem afetar o objetivo da
Sprint;
A composio da equipe de desenvolvimento no
modificada;
As metas de qualidade no diminuem;
O escopo pode ser clarificado e renegociado entre o dono
do produto e a equipe de desenvolvimento quanto mais for
aprendido.
Cada Sprint pode ser considerada um projeto com hori-
zonte no maior que um ms. Como os projetos, as Sprints
so utilizadas para realizar algo. Cada Sprint tem a defi-
nio do que para ser construdo, um plano projetado e
flexvel que ir guiar a construo, o trabalho e o resultado
do produto.
Reunio de planejamento da Sprint
O trabalho a ser realizado na Sprint planejado na reunio
de planejamento da Sprint, que consiste em duas etapas.
Na primeira etapa, a equipe de desenvolvimento trabalha
para prever as funcionalidades que sero desenvolvidas duran-
te a Sprint. O dono do produto apresenta os itens do backlog
do produto ordenados para a equipe e todos colaboram com
o entendimento do trabalho a ser realizado.

Perceba o uso do E para repetir mltiplas vezes o Dado

e o Quando positivamente.
Cenrio: Assinatura expirada
- Dado que estou na tela de autenticao;
- E possuo o usurio registrado;
- Mas no possuo uma assinatura vlida;
- Quando informo usurio;
- E informo senha;
- E clico em autenticar;
- Ento visualizo a mensagem Assinatura expirada.

Perceba o uso do Mas, usado para estender o Dado

negativamente.

Sprint
Sprints definem o ciclo bsico de desenvolvimento utilizando
o Scrum. Cada sprint composta por uma reunio de plane-
jamento da Sprint, reunies dirias, o trabalho de desenvolvi-
mento, uma reviso da Sprint e a retrospectiva da Sprint.

Edio 58 - Engenharia de Software Magazine 11

 A equipe de desenvolvimento, com base no backlog do pro-
duto, o ltimo incremento do produto e a capacidade projetada,
seleciona os itens do backlog para a Sprint. Aps isso, a equipe
de desenvolvimento, o dono do produto e o ScrumMaster
determinam a meta da Sprint.
Tendo selecionado o trabalho para a Sprint, na segunda
etapa, a equipe decide como ir converter os itens do backlog
do produto em um incremento de acordo com a definio de
pronto. Os itens do backlog do produto selecionados para a
Sprint, junto com o plano de entrega destes itens, compem
o backlog da Sprint.
Tarefas
Geralmente, durante o planejamento da Sprint, o time quebra
a histria em atividades, que so as aes necessrias para
entregar uma histria. As tarefas normalmente so estimadas
em horas, aplicando uma escala de 2, 4 e 8 horas. A tarefa deve
ser atribuda a uma pessoa e deve ser entregue em uma mesma
Sprint. Alguns exemplos de tarefas so:
Implementar o front-end;
Implementar o back-end;
Executar testes de aceitao.
Reviso da Sprint
A reviso da Sprint executada no final da Sprint para
inspecionar o incremento e adaptar o backlog do produto, se
necessrio. uma reunio informal, e a apresentao do in-
cremento destina-se a motivar e obter comentrios e promover
a colaborao.
O resultado da reunio de reviso um backlog do produto
revisado que define o provvel backlog do produto para a
prxima Sprint. Nesta etapa, o backlog do produto tambm
pode ser ajustado completamente para atender a novas
oportunidades.
Retrospectiva da Sprint
A retrospectiva da Sprint tem o propsito de inspecionar
como a ltima Sprint ocorreu em relao s pessoas, relaes,
processos e ferramentas; identificar e ordenar os principais
itens que foram bem e as potenciais melhorias; e criar um
plano para implementar melhorias no modo como o trabalho
realizado.
Essa uma tima oportunidade para discutir o formato dos
requisitos e como a soluo est sendo documentada. Depois
de participar de diversos projetos geis, percebe-se que a
forma e o que documentado podem variar em cada projeto.
O foco obter uma documentao til equipe de desenvol-
vimento e que seja de fcil entendimento para os especialistas
de domnio.
Documentos gerados dentro da Sprint
Apesar de este artigo estar focado no Scrum e no BDD,
importante citar as contribuies que a metodologia XP pro-
porcionou para a questo da documentao de requisitos.
A XP indica que deve ser documentado apenas o mnimo
12 Engenharia de Software Magazine - Trabalhando com requisitos geis
necessrio antes de se chegar ao cdigo. Ao mesmo tem-
po, utiliza-se a comunicao face a face como fonte de
informaes para a codificao. A documentao mais
abrangente s ocorre efetivamente quando o cdigo est
pronto. Portanto, a documentao descreve aquilo que foi
efetivamente codificado. No descreve aquilo que se espera
que seja codificado.
Seguindo esta abordagem, o que acaba ocorrendo que a do-
cumentao ps-codificao passa a ser bastante vivel. Dado
que o conjunto de funcionalidades de uma iterao bastante
limitado em relao ao total de funcionalidades do projeto, o
esforo de documentao a cada iterao sempre limitado e
factvel. Usando este procedimento, a equipe consegue dedicar
bastante tempo s funcionalidades e, em pouco tempo, atualiza
a documentao do projeto.
Outra prtica que ajuda muito na documentao ps-codi-
ficao a utilizao de ferramentas para gerao automtica
de documentos.
Segundo Teles (2006), cada projeto tem caractersticas espe-
cficas e pode necessitar de mais ou menos documentos. Mas,
vale a pena citar alguns documentos que podem ser utilizados
em diversos projetos:
Histria de usurio A histria um documento extrema-
mente simples, escrito pelo cliente em um carto, que serve
como um lembrete da necessidade da equipe dialogar com o
cliente no momento de desenvolver a funcionalidade.
Teste de aceitao Toda histria de usurio deve ser as-
sociada a um conjunto de testes de aceitao, que definem as
respostas que a funcionalidade deve fornecer de acordo com
a utilizao (cenrio) por parte do usurio.
Testes de unidade O teste de unidade, alm de verificar a
funcionalidade de uma classe, tambm serve como documenta-
o que informa ao seu leitor qual o funcionamento esperado
para os mtodos da classe (ver Nota do DevMan 2).
Nota do DevMan 2
Teste de unidade: Utilizando histrias de usurio no formato do BDD, conforme
descrito brevemente neste artigo e, em conjunto com ferramentas de automao
de testes, como o Cucumber, possvel gerar testes automatizados a partir das his-
trias de usurio podendo, de acordo com a definio das necessidades da equipe,
do projeto ou do cliente, substituir os testes de unidade.
Processos de negcio Este documento descreve os pro-
cessos de negcio que so implementados pelo sistema. Em
muitos projetos, os processos de negcio que so apoiados
pelo sistema so recentes, muito instveis e evoluem com o
sistema. Por esta razo, este documento deve ser atualizado
no final de cada Sprint, devendo descrever os processos de
negcio que efetivamente so apoiados pelo sistema. Outros
processos que sero apoiados pelo sistema no futuro no

devem fazer parte deste documento e devem estar separados
em outro documento, que pode servir para ajudar a aprimorar
o Backlog do Produto;
Modelos de classes O diagrama de classes representa a
estrutura do sistema, recorrendo ao conceito de classe e suas
relaes. Serve para dar uma viso geral do sistema e pode ser
gerada aps a implementao.
Modelo de dados Durante a iterao, a equipe deve fazer as
alteraes que julgar necessrias no banco de dados de desenvol-
vimento. Ao final da iterao, uma ferramenta pode fazer a enge-
nharia reversa das tabelas que compem o banco de dados;
Manual de usurio O manual do usurio descreve os pro-
cessos de negcio atravs das telas do sistema e das aes que
o usurio deve fazer em cada uma delas. Demonstra como os
processos de negcio foram mapeados para dentro do sistema
indicando todos os passos que o usurio deve seguir para
efetuar operaes no software.
Prottipos Construir um prottipo outro mtodo para ob-
ter respostas iniciais sobre os requisitos atravs de um modelo
funcional do produto esperado antes de constru-lo.
Concluso
A forma de elicitar, documentar e comunicar os requisitos a
partir dos princpios geis demonstra-se uma abordagem mais
flexvel e que promove maior interatividade entre especialistas
de domnio e equipe de desenvolvimento.
O modelo apresentado pelo Behaviour-Driven Development
ajuda o processo de anlise dos requisitos por meio de uma
forma simples e estruturada e que utiliza a linguagem de ne-
gcio para descrever o comportamento do sistema, tornando
mais transparente os resultados que devem ser alcanados.
E se considerarmos que o software o produto mais male-
vel que existe, as empresas precisam usar estas caracters-
ticas para sua vantagem competitiva. Manterem-se presas ao
tradicional desenvolvimento em cascata invalida ou dificulta
essa vantagem.
Devido velocidade com que as exigncias do mercado se modi-
ficam, torna-se fundamental poder realizar mudanas no escopo
de produtos de software para que eles atendam as necessidades
do negcio. Com isso, requisitos geis vm para promover uma
forma factvel de documentar e comunicar os requisitos.
D seu feedback sobre esta edio!
s
D
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha da revista!
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
AgiLidAdE
Referncias
[1] COHN, Mike. Desenvolvimento de Software com Scrum: Aplicando mtodos geis
com sucesso. Porto Alegre: Bookman, 2011.
[2] COHN. Mike. User Stories Applied: For Agile Software Development. Estados
Unidos: Addison-Wesley, 2004.
[3] EVANS, Eric. Domain-Driven Design: Atacando as complexidades no corao do
software. Rio de Janeiro: Alta Books, 2009.
[4] GRAY, Dave; BROWN, Sunni; MACANUFO, James. Gamestorming: Jogos Corporativos
para Mudar, Inovar e Quebrar Regras. Rio de Janeiro: Alta Books, 2012.
[5] JEFFRIES, Ron. Essential XP: Card, Conversation, Confirmation. 2001.
http://xprogramming.com/articles/expcardconversationconfirmation/
[6] HIGHSMITH, Jim. Gerenciamento gil de Projeto: Criando produtos inovadores.
Rio de Janeiro: Alta Books, 2012.
[7] KOSKELA, Lasse. Acceptance TDD Explained. 2008.
http://www.methodsandtools.com/archive/archive.php?id=72
[8] NORTH, Dan. Introducing BDD. 2006.
http://dannorth.net/introducing-bdd/
[9] PANCHAL, Dhanvai. What is Definition of Done (DoD)?. 2008.
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod
[10] PICHLER, Roman. Gesto de Produtos com Scrum: Implementando mtodos
geis na criao e desenvolvimento de produtos. Rio de Janeiro: Elsevier, 2011.
[11] PICHLER, Roman. The Definition of Ready. 2010.
http://www.romanpichler.com/blog/product-backlog/the-definition-of-ready/
[12] PMI, Project Management Institute.
http://www.pmi.org
[13] SUTHERLAND, Jeff; SCHWABER, Ken. Guia do Scrum: Um guia definitivo para o
Scrum. 2011.
http://scrum.org/Scrum-Guides
[14] SCHWABER, Ken. SCRUM Development Process. s/d.
http://gowegian.5gbfree.com/scrumDevelopmentProcess.pdf
[15] TELES, Vincius. Extreme Programming: aprendendo como encantar seus usurios
desenvolvendo software com agilidade e alta qualidade. So Paulo: Novatec, 2006.
Feedback
eu [16] WATERS, Kelly. What is Scrum?. 2011.
http://www.allaboutagile.com/what-is-scrum/
sobre e
[17] WATT, Richard; LEIGH-FELLOWS, David. Acceptance Test Driven Planning. 2010.
s
ta
edio
http://www.vietnamesetestingboard.org/zbxe/?document_srl=276643
Edio 58 - Engenharia de Software Magazine 13