Histórias de usuários e análise MoSCoW

Olá Pessoas!

Vocês sabem o que são histórias de usuários?

Você, desenvolvedor maroto, tá lá na tranquilidade do seu cubículo, quando um ser surgindo de Deus sabe onde pede que você desenvolva um sistema com centenas de features por que a planilha de excel dele tá dando pau.

Daí você, experiente e sincero manda a real prá ele...

Em tradução livre:1-Eu não posso te dar todas essas funcionalidades na primeira versão; 2-E cada funcionalidade precisa de ter o que chamamos de "História de usuário"; 3-OK, vou te dar uma história: você me dá todas as funcionalidades ou eu vou arruinar a sua vida.

 

Bom, no quadro acima temos uma ideia bem humorada do que é uma história de usuário. Normalmente utilizada em métodos ágeis de desenvolvimento, a história de usuário é uma descrição simples -em linguagem natural- e curta -normalmente em um parágrafo- das funcionalidades que o sistema deve ter para atender aos objetivos do cliente negócio.

Mas, não são os requisitos que dizem para o desenvolvedor o que vai ser implementado e o que não vai ser implementado no sistema? E a resposta é... Sim

Tá dando "bug" aqui

 

Então qual é a diferença entre os requisitos do sistema e as histórias do usuário?

Bueno chico, ambos os conceitos se integram e se completam. Os requisitos de sistema dizem o que o sistema é capaz de fazer para atingir seus objetivos. Já as histórias de usuário fracionam os requisitos para que seja possível estimar o esforço necessário para o sistema realizar o objetivo.

Geralmente, cada funcionalidade do seu sistema será uma história de usuário. O problema é que as vezes a funcionalidade está muito generalista tornando impossível de ser completamente implementada em uma única iteração.

Surge aí o conceito de ÉPICO. Épicos são grandes histórias de usuários, grandes demais para serem implementadas em uma única iteração, surgindo aí a necessidade de dividir (split) a história em histórias menores até que ela caiba em uma iteração.

Você pode escrever a história da forma que achar mais conveniente, contanto que ela responda a 3 perguntas, não necessariamente nesta ordem:

1. Quem se beneficia com a história do usuário? (ator) O proprietário da história. De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema.
2. O que se quer? (ação) É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema.
3. Qual o benefício? (funcionalidade) É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa.

Exemplos:

 

Mas como saber se a história foi bem escrita, ou seja, cumpre bem o seu papel?
Avaliando a qualidade da história

O modelo de 3 C's ou Card, Conversation, Confirmation Model

Foi proposto em 2001 por Ron Jeffries para distinguir as histórias de usuários dos requisitos documentais, como casos de uso.

O modelo captura os componentes de uma história de usuário:

"Cartão" (ou, muitas vezes, uma Nota de Post-It), é um símbolo físico que dá forma tangível e durável ao que de outra forma seria apenas uma abstração. A história deve ser pequena o suficiente para caber em um cartão.

"Conversação" ocorrendo entre as várias pessoas envolvidas (cliente, usuário, desenvolvedor, testador) por uma determinada característica de um produto de software em diferentes momentos e lugares. Esta conversa é em grande parte verbal, mas na maioria das vezes complementada por documentação e promove a comunicação para dar entendimento comum da funcionalidade a ser entregue.

"Confirmação" o comportamento esperado para confirmar o escopo. Também conhecido como plane de testes, escrito no verso do cartão.

O critério INVEST

Foi criado por Bill Wake em 2003 como um lembrete das características que uma história com qualidade deve ter, sendo o qual, uma boa história de usuário deve cumprir com seis atributos.

 

Vantagens e desvantagens das histórias de usuários

Baseado no que foi abordado podemos definir algumas vantagens e desvantagens das histórias de usuários:

Vantagens

• Não se precisa de experiência
• Não é investido muito tempo e dinheiro
• Comunicação com o cliente
• Compreensão do que o produto final tem a realizar
• Priorização

Desvantagens

• Não é uma documentação detalhada (e não é este o objetivo)
• Não aborda explicitamente como documentar requisitos não funcionais
• Pode não ser adequada para ambientes com regulamentações ou quando o nível de documentação é imposto pelo cliente

A análise MoSCoW

Na segunda parte deste post falarei um pouco sobre a análise MoSCoW e sua utilização para a priorização de requisitos.

O MoSCoW é uma técnica utilizada para análise de negócios e desenvolvimento de software que tem por objetivo alcançar um entendimento comum com os stakeholders sobre a importância de cada requisito do sistema. Foi desenvolvida por Dai Clegg da Oracle UK. Na concepção do criador, MoSCow é uma técnica com prazo fixado de modo que o foco da execução acontece sobre os requisitos mais importantes. É normalmente vista como um aspecto importante em processos de desenvolvimento de software.
 

É uma forma de priorizar requisitos a serem incluídos em sistemas de informação, dividindo os requisitos de um software em quatro categorias:

 

Must ou Essencial - Requisito obrigatório para o projeto / Should ou Importante - Requisitos importantes para o projeto / Could ou Desejável - Requisitos desejáveis para o projeto / Won't ou Dispensável - Requisitos dispensáveis para o projeto

Priorização pelo método MoSCoW

Os requisitos da categoria MUST devem ser garantidos no sistema (obrigatório), ou seja, não podem ficar fora do escopo do projeto sem que o mesmo seja cancelado.

Os requisitos da categoria SHOULD são requisitos de alta prioridade que são esperados que sejam implementados no sistema, mas não são vitais para o sistema. Deste modo, mesmo sem este requisito o sistema continua sendo viável, porém poderá ter alguma perda impactante.

Os requisitos da categoria COULD são requisitos desejáveis, mas somente serão incluídos se houver tempo e recursos para sua inclusão. É um requisito de menor prioridade sendo que o sistema continuará a funcionar perfeitamente sem ele, ou seja, não vai influenciar no sucesso do projeto mas pode influenciar na satisfação do cliente.

Já os requisitos WON'T são requisitos que podem ficar de fora dessa release do sistema neste momento , mas poderá ser incluído em uma release futura.

Deste modo deve ser identificado o impacto e a importância de cada requisito no sistema projetado.

As regras de priorização são determinadas de modo a garantir a entrega de um subconjunto mínimo para o funcionamento do sistema. Assim, os requisitos essenciais não devem exceder 60% do esforço. Este é o subconjunto mínimo utilizável, sendo que os demais requisitos, ambos, ficam com 20% do esforço total cada.

O que podemos ver é que, a priorização dos requisitos através da análise MoSCoW garante que os esforços estão sendo aplicados aos requisitos mais críticos e mostram quais destes merecem mais atenção e quais devem ser implementados primeiro. Diferentemente do processo de priorização tradicional onde os requisitos devem ser priorizados considerando apenas a sua criticidade o que não deixa muito claro a definição destas prioridades.

Exemplificação aplicada a um projeto em desenvolvimento:

Nas aulas de Análise de Sistemas, faço parceria com uma amiga para o desenvolvimento de um sistema para o gerenciamento de uma revenda de gás e água (detalhes aqui). No levantamento de requisitos para o sistema utilizamos as técnicas de histórias de usuário e análise MoSCoW. Segue abaixo dois exemplos de ações que o sistema deverá realizar.

 

Foi feito um brainstorm com o cliente, onde o mesmo falou as ações que ele desejaria que o sistema tivesse.

Como pode ser visto o identificador RF01, a história está muito longa com muitas ações (também conhecida como épico) que podendo ser divididas em histórias menores, por exemplo:

Eu, como -vendedor- quero -registrar endereço e telefone de meus clientes- para -agilizar a entrega.

 

 

Sabemos que nosso sistema deve registrar o endereço e telefone do cliente, o valor final da venda, data de venda, data de recebimento e status do pedido.

Ainda não chegamos ao ponto de dividir os épicos em histórias menos para serem implementadas em uma única iteração mas acho que você já deve ter pegado a intenção.

Veja também que, tanto o identificador RF01 e RF02 possuem a prioridade MUST do MoSCoW, assim, após a subdivisão das histórias, as histórias menores também terão a prioridade MUST.

Bom, é isso. TCHAU

 

FONTE:

FATTO, Consultoria e Sistemas. Histórias de usuário. Disponível em: <https://www.youtube.com/watch?v=sEtiCJfXTE8&t=317s>. Acesso em: 04 de abril. 2017

FATTO, Consultoria e Sistemas. Análise Moscow. Disponível em: <https://www.youtube.com/watch?v=7XcthAr6JHA&t=518s>. Acesso em: 04 de abril. 2017

Agilealliance.org. Glossary: The Three C's. Disponível em: <https://www.agilealliance.org/glossary/three-cs/>. Acesso em: 04 de abril. 2017

blog.myscrumhalf.com. User Stories: O que são? Como Usar. Disponível em: <http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/>. Acesso em: 04 de abril. 2017