Scrum - Requisitos Ágeis

Por Cesar Brod

Data de Publicação: 21 de Novembro de 2014

O Scrum não prescreve a forma pela qual os requisitos para um projeto devem ser coletados. A partir do livro de Mike Cohn, User Stories Applied, de 2004, os praticantes adotam, de forma crescente, a documentação dos requisitos em um formato simples, que reflete em uma narrativa expressiva, aquilo que o usuário final espera realizar:

Como {ator}, desejo {realizar ação} para {atingir objetivo}

Alguns exemplos:

Como estudante, desejo consultar as opções de refeições em locais próximos para escolher onde vou almoçar, com base em pontuações de outros estudantes.

Como estudante, desejo pontuar um estabelecimento que sirva refeições para que outros estudantes saibam da qualificação que dou ao estabelecimento.

Como fornecedor de refeições, quero cadastrar meu estabelecimento para que os estudantes o encontrem.

A responsabilidade por coletar e priorizar essas histórias é do Product Owner que, durante o planejamento de cada Sprint, estará disponível para esclarecê-las e tomar conhecimento de quais serão escolhidas para serem desenvolvidas. Lembro que é a equipe que seleciona as histórias com as quais se compromete durante a Sprint.

Os requisitos - escritos na forma de histórias - são suficientes para que a equipe desenvolva os incrementos funcionais do produto, da primeira Sprint até a sua entrega? A resposta é sim, mas não pode ser um sim dado de maneira leviana.

Lembro de uma conversa com o Giba Assis Brasil e o Jorge Furtado, da Casa de Cinema de Porto Alegre sobre roteiros e diretores. Na ocasião, eu e o Giba conversávamos sobre o minicurso de Roteiros de cinema com software livre que ministraríamos na Latinoware de 2009.

Abaixo, uma porção do roteiro de Houve uma vez dois verões

CENA 1 - PRAIA - EXTERIOR/DIA

Uma praia se perde no horizonte, quase vazia. O
vento surge e some em linhas de areia branca,
o céu é branco e o mar quase marrom. Muito ao
longe, um HOMEM se aproxima. CHICO e JUCA, 16
anos, estão sentados numa duna quase na beira
da praia, olhando para o mar. Chico está de
boné. Juca tem uma tala no pescoço. Chico dá
uma olhada na direção do HOMEM que se aproxima:
quarenta anos, copo de cerveja na mão, relógio.

Agora, considere as seguintes alternativas:

CENA 1 - PRAIA - EXTERIOR/DIA (ALTERNATIVA 1)

Praia quase vazia. CHICO e JUCA, adolescentes,
estão sentados numa duna, olhando para o
mar. Juca tem uma tala no pescoço. Chico olha
na direção de um HOMEM que se aproxima com um
copo de cerveja na mão.

CENA 1 - PRAIA - EXTERIOR/DIA (ALTERNATIVA 2)

A praia de Cidreira, no Rio Grande do Sul, se
perde no horizonte, quase vazia, em meados do mês
de março, 10 horas da manhã. O vento nordeste
surge e some em linhas finas de areia branca,
o céu é branco e o mar quase marrom. Um HOMEM
se aproxima, vindo de cerca de 300 metros da
direção norte. CHICO e JUCA, 16 anos, estão
sentados numa duna distante cinco metros da
praia, olhando para o mar. Chico usa um boné azul
marinho, de grife. Juca tem uma tala no pescoço,
indicando um problema nas vértebras. Chico dá
uma olhada na direção do HOMEM que se aproxima:
quarenta anos, magro, careca, copo descartável
de cerveja na mão esquerda, relógio grande,
pulseira metálica, no pulso direito.

Nosso papo era justamente sobre o nível de detalhes que deve estar contido em um roteiro e o quanto alguns diretores preferem mais ou menos detalhes. Com menos detalhes, o diretor tem mais liberdade criativa. Com mais detalhes o roteirista garante que sua visão da cena seja melhor passada ao diretor, mas diminui a liberdade do mesmo em adequar a cena a realidade do momento. Se não estiver ventando, por exemplo, como a filmagem poderia ser feita? Ou se um patrocinador não concordar com o uso de um boné de grife?

Em projetos ágeis, o Product Owner é o responsável por conversar com os usuários, clientes, patrocinadores do projeto e captar a essência do que será desenvolvido, construir a visão do produto e, junto com a equipe, garantir a integridade da arquitetura.

Greg Nudelman, em seu recente livro The $1 Prototype, sugere uma abordagem quase cinematográfica para a captura de requisitos ágeis: comece desenhando o cenário onde seu produto ou serviço será usado, posicione os usuários em situações reais e crie uma história que poderá ser testada com usuários reais. Tive a grata oportunidade de ser o revisor técnico do Greg nesse seu novo livro (eu já havia traduzido, dele, o Padrões de Projeto para Android) e, desde então, conversamos sobre requisitos, prototipia e desenvolvimento ágil.

Uma vez construído o cenário, ilustrado com histórias de uso, na forma que o usuário entenda e concorde com eles, os desenvolvedores serão capazes de desenvolver o produto, desde que os requisitos não funcionais estejam bem definidos. Gosto de fazer isso na Sprint Zero, aquela Sprint antes das demais, onde as entregas não são feitas para os clientes, mas para a própria equipe. Alguns exemplos de requisitos não funcionais:

Tecnologias usadas para o desenvolvimento @@ Os tipos de dispositivos que os usuários utilizarão para acessar o produto @@ Tempo de resposta @@ Disponibilidade (24 horas, sete dias por semana; só em determinados horários)

Além das histórias e cenários, outros documentos de referência podem ser utilizados para o desenvolvimento. Em minhas oficinas de Scrum e desenvolvimento ágil de forma geral, sempre digo que documentos de projeto devem passar por, pelo menos, dois filtros:

Se o documento não for lido, ele não deve ser escrito @@ Se paira dúvida se o documento deve ser escrito, ele não deve ser escrito

Documentos absolutamente necessários farão falta no desenvolvimento do projeto e acabarão passando pelos filtros acima. Padrões de codificação e guias de leiaute estão entre eles e devem ser conhecidos por toda a equipe, assim como regras de negócio específicas a domínios que podem não ser óbvias para todos.

Em resumo, um requisito ágil deve ser escrito na forma de uma história simples, compreendida pelo usuário e pela equipe de desenvolvimento, cujo detalhamento evolui de acordo com o nível dessa compreensão. Os requisitos não funcionais não entram na história, mas englobam todas elas e estão descritos em documentos de apoio realmente necessários.

Leia Mais:

• Scrum - User Stories
• Muito mais sobre Scrum