no momento em que sua prioridade for atingida, ou seja, no momento em que a his-
tória fizer parte de uma iteração. É importante que a história seja detalhada apenas quando o momento de seu desenvolvimento estiver próximo, isto é, quando chegar
o momento de a história
entrar na iteração corrente. Quanto mais cedo ela for ana-
lisada e detalhada, maiores serão as chances de haver retrabalho e até mesmo perda
de tempo e energia, considerando que o cliente aprende e muda de ideia à medida
que as iterações vão sendo concluídas.
Para ilustrar melhor este exemplo, imagine uma história que tenha como obje-
tivo a criação de um relatório de apuração de impostos. Imagine que, segundo sua
prioridade, ela será implementada somente daqui a seis meses, mas que ainda as-
sim, inicia-se um trabalho de análise e discussão sobre ela. Se o governo realizar
alguma mudança no plano tributário, você provavelmente terá desperdiçado tempo
e dinheiro!
3. Histórias devem agregar valor aos clientes. Como mencionado anteriormente,
histórias devem descrever funcionalidades que de alguma forma oferecerão ao cli-
ente retorno ao seu investimento. Por essa razão, histórias de caráter técnico não
são aconselháveis, por exemplo, atualizar o Spring Framework para versão 2.5 não
agrega valor de negócio ao software, pelo menos não diretamente, isso não significa
que você não possa fazê-lo, mas é aconselhável que exista uma história escrita pelo
cliente que a justifique;
4. Histórias devem ser estimáveis. É importante que os desenvolvedores sejam
capazes de estimá-las. Para que sejam estimáveis é necessário que os desenvolve-
dores possuam ou tenham acesso através do cliente ao conhecimento de negócio,
e possuam também o conhecimento técnico necessário para transformar a história
em software. Seria inviável pedir a um desenvolvedor que nunca escreveu uma linha
de código em Java que estime o esforço para desenvolver um pedido de venda em
um projeto Java EE com EJB 3. O mesmo aconteceria se pedíssemos ao desenvolve-
dor para que estimasse o esforço para criar um relatório de fluxo de caixa, sem antes explicar a ele o que é um fluxo de caixa;
5. Histórias devem ser pequenas. Histórias muito grandes são difíceis de esti-
47
3.6. Escrevendo Histórias de Usuário
Casa do Código
mar, por isso deve-se tomar os devidos cuidados para mantê-las sempre curtas e,
quando necessário, quebrá-las em histórias menores. Para ilustrar melhor, imagine
a seguinte história: Um usuário pode realizar compras na loja virtual. Ela pode
envolver muitas funcionalidades que estão implícitas, e por isso, pode gerar diferentes interpretações e levar os desenvolvedores ao erro. Em casos como este, podemos
quebrar a história grande em outras histórias menores: Um usuário pode adicionar
produtos ao seu carrinho de compras, Ao finalizar a compra o usuário deve esco-
lher a forma de pagamento, Para compras acima de R$100,00 o frete deverá ser
gratuito etc.;
6. Histórias devem ser testáveis. É preciso ter critérios de aceitação bem defini-
dos para que um desenvolvedor possa saber quando uma história está ou não con-
cluída. Uma boa prática ao usar cartões para escrever as histórias é pedir ao cliente que escreva alguns critérios de aceitação no verso do cartão.
Para que a história seja testável, é preciso que o cliente escreva critérios objetivos e concretos. Por exemplo, O relatório deve ser intuitivo é um exemplo de crité-
rio difícil testar, porque o conceito de intuitivo é abstrato e subjetivo, pode possuir significados diferentes para cada pessoa. Ao invés disso, o relatório deve possuir
um rodapé com a soma dos valores ou o título das colunas deve se manter fixo ao
navegar entre os lançamentos são exemplos de critérios fáceis de testar, bastando
que o desenvolvedor certifique-se de que eles estão sendo atendidos para saber se a
história será aceita pelo cliente.
Essas características formam o acrônimo INVEST:
I - Independente
N - Negociável
V - Valiosa
E - Estimável
S - Sucinta
T - Testável
Temas, Épicos, Funcionalidades e Histórias
É comum que muitos projetos de software, naturalmente, possuam uma estru-
tura hierárquica de requisitos, de forma que algumas necessidades do usuário de alto 48
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
nível podem ser derivadas em diversas partes menores que, por sua vez, podem ser
dividas novamente até uma granularidade que possa ser mais facilmente compreen-
dida e que possa ser desenvolvida em um determinado
espaço de tempo.
Dean Leffingwell, sugere que a hierarquia de requisitos comece com Temasque
representam um conjunto de iniciativas que guiam os investimentos em sistemas,
produtos, serviços e aplicações [37]. Desses temas são derivados os épicos, inicia-
tivas de desenvolvimento que têm potencial de agregar valor ao tema do qual foi
derivado. São requisitos em alto nível e não são implementados diretamente, antes,
são quebrados em funcionalidades, que posteriormente são quebradas em histórias