[livro] Histórias de Usuário – Por que e como escrever requisitos de forma ágil?

livro
Padrão

Talvez você já saiba, ou talvez não, mas eu e o Daniel escrevemos um livro sobre Histórias de Usuário (user stories).

Trata-se de um eBook gratuito, que se encontra atualmente na segunda edição e já foi baixado por mais de 2.000 pessoas.

Estamos recebendo ótimas criticas, e isto nos deixa muito motivados para seguir evoluindo o livro. Também estamos pensando em mais livros ligados a métodos ágeis.

Você pode nos sugerir temas para os próximos livros na seção de comentários deste post.

Para baixar o livro basta acessar o link http://historiasdeusuario.com.br e seguir as instruções de “pagamento”, (na verdade o livro custa um tweet ou um compartilhamento no facebook).

 

Alguns assuntos abordados no livro:

  • Por que escrever histórias de usuário?
  • Existe um padrão para escrever?
  • Como testar? BDD!
  • O conceito INVEST
  • Cartão, conversação, confirmação! O conceito 3C
  • Bugs também viram histórias de usuário?

Além de exemplos e dicas sobre próximos passos para quem quer se tornar um jedi em histórias de usuário.

Então é isto, baixa lá o livro e boa leitura! :)

 

Definition of Ready

Padrão

4837626192_d4f1c83ff6

Quando um desenvolvedor vai iniciar o trabalho em uma funcionalidade, ele precisa ter informações mínimas para que este trabalho seja bem sucedido. Entender o que o cliente deseja alcançar na funcionalidade, conhecer o contexto de negócio envolvido, entre outras.

Estas informações são chamadas de “definition of ready” ou “definição de pronto para trabalhar”.

Considere que você tem uma demanda do cliente. Qual a quantidade mínima de informação necessária para dizer que ela pode ser colocada no seu “a fazer”, sendo priorizada?

Veja exemplos de perguntas que devem ser respondidas:

- Quem? É importante que esteja identificado a persona que vai utilizar o recurso que está sendo desenvolvido;

- O quê? Uma breve descrição do que deve ser desenvolvido;

- Por quê? Se o desenvolvedor entender porque determinado recurso foi solicitado a sua chance de desenvolver software aderente as necessidades do cliente serão bem maiores;

- Como? Talvez esta seja uma das informações mais importantes. O desenvolvedor precisa saber como será utilizada funcionalidade que está sendo desenvolvida. Ele precisa saber quais são os critérios de aceitação. Este link pode ajudar.

- Estimativa: É interessante que só sejam iniciadas tarefas que já foram estimadas pelo time, isto para evitar que os desenvolvedores trabalhem em épicos.

Estas informações se relacionam a capacidade do time de entender o que o cliente busca, melhorando a escrita das demandas, seja com as perguntas “Quem, O que, Por quê, Como”, seja com protótipos de papel e outras técnicas que ajudem os 3Cs (um Cartão que gera Conversas que vão gerar Confirmações).

Existem outras dicas para se seguir, como o modelo INVEST, mas isto é assunto para outro post.