você está aqui: Home  → Arquivo de Mensagens

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.


Um storyboard desenvolvido durante um seminário conduzido por Greg Nudelman

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:

Sobre o autor

Cesar Brod é empresário e consultor nos temas de inovação tecnológica, tecnologias livres, dados abertos e empreendedorismo. Sua empresa, a BrodTec, faz também trabalhos tradução e produção de conteúdo em inglês e português. Além de sua coluna, Cesar também contribui com dicas para o Dicas-L e mantém um blog com aleatoriedades e ousadias literárias. Você pode entrar em contato com ele através do formulário na página da BrodTec, onde você pode saber mais sobre os projetos da empresa.

Mais sobre o Cesar Brod: [ Linkedin ] | [ Twitter ] | [ Tumblr ].


Para se manter atualizado sobre as novidades desta coluna, consulte sempre o newsfeed RSS

Para saber mais sobre RSS, leia o artigo O Padrão RSS - A luz no fim do túnel.

Recomende este artigo nas redes sociais

 

 

Veja a relação completa dos artigos de Cesar Brod