O que é User Story?

O Scrum é uma das metodologias ágeis que vem ganhando força e se destacando pela sua forma ágil de capturar requisitos. A User Story.

Uma User Story nada mais é do que um requisito capturado através de conversas com o Product Owner, onde é descrito as necessidades de forma clara utilizando uma linguagem simples, e possui características que derivam das demais metodologias ágeis, que focam mais na comunicação “face-a-face” do que na documentação em si.

Ela deve ser vista como um lembrete, e é isso que a torna diferente no levantamento de requisitos, pois acaba ajudando a estabelecer uma comunicação clara com o time e possibilita que todos tenham  entendimento do que esta sendo pedido, devendo ficar exposta em um quadro no qual é possível visualizar o progresso do trabalho.

E o que torna as User Stories tão interessantes, é que elas são pequenas, não são complexas (cheias de detalhes), não necessitam de manutenção, não se tornam obsoletas rapidamente, e não exigem atualizações constantes, permitindo assim dividir uma etapa grande em pequenos pedaços e com isso possibilitar a interação entre a equipe e a entrega de cada parte quando terminada.

Uma boa User Story tem que ser INVEST !

Não, não. Isso não tem nada a ver com investimento financeiro!

INVEST é um acrônimo de palavras da língua inglesa para listar as características de uma boa User Story, que deve ser Independente,Negociável, Valiosa,Estimável, pequena(Small) e Testável.

Independente:

Quando se diz que uma User Story deve ser independente, significa que ela deve ser ligada o menos possível com outras Stories, permitindo que seja desenvolvida completamente sem depender da finalização de uma outra, já que uma Story representa basicamente uma função completa de um elemento do projeto vista pela visão do usuário. Por isso também, ele deve ser assimilada por qualquer pessoa, e não necessitar de nenhuma fonte externa ou da leitura de outras Stories para ser compreendida.

Negociável:

Uma boa Story não deve ser inflexível, e seus detalhes devem ser discutidos entre todos os envolvidos no projeto (Product Owner, Scrum Master e o Time de Desenvolvimento). Esta característica compreende às “conversas” dos 3 C’s das User Stories.

Valiosa:

O elemento que está sendo descrito na Story deve retornar algum valor para o cliente. Não necessariamente um valor monetário, mais pode ser um valor funcional por exemplo.

Estimável:

Deve reunir um número de detalhes suficiente através das conversas, para que seja estimado o seu tempo total de realização, o custo de desenvolvimento, e outras métricas que sejam necessárias.

Pequena:

Stories enormes e cheias de detalhes, além de prejudicarem a formação das estimativas, podem comprometer a sua própria independência e alterar o valor a ser passado para cliente, podendo até resultar em um elemento finalizado, porém inútil ao projeto.

As Stories também não devem ser tão pequenas e mal detalhadas ao ponto de prejudicar o seu entendimento. O segredo está na dimensão apropriada da Story.

Testável:

Deve-se haver a possibilidade da Story ser testada para se confirmar o seu funcionamento esperado ou a sua conclusão.  Esta parte compete aos Testes de Aceitação.

User Story e os 3 C’s (Cartão, Conversas e Confirmação).

Cartão

User Stories são escritas em cartões, que contem informações das necessidades do usuário. As informações dos cartões devem ser curtas e simples, sendo assim fácil de identificar de que se trata a necessidade. Eles são usados no planejamento e normalmente são entregues ao time para que este implemente os requisitos.

Normalmente são estabelecidos três parâmetros da necessidade do usuário “QUEM”, “O QUÊ” e “POR QUE”.

• QUEM define quem é o usuário que tem a necessidade.
• O QUE define qual a necessidade do usuário.
• POR QUE define o beneficio e a funcionalidade para atender as necessidades do usuário.

Conversas

São conversas sobre a User Story onde são discutidas soluções, opiniões e pensamentos sobre o projeto, ocorrem durante o planejamento, no momento em que as tarefas são definidas. Participam Product Owner, time de desenvolvimento e outras pessoas envolvidas no projeto caso haja. As conversas são fundamentais para que todos possam entender o que é necessário para que o projeto seja bem sucedido.

Confirmação

São critérios e testes deles derivados que documentam detalhes da User Story, responsáveis por garantir que o projeto tenha a funcionalidade esperada. Estes são denominados de Critérios e Testes de aceitação.

Os critérios normalmente são curtos e de fácil entendimento, são usados pelo time de desenvolvimento para identificar quando uma funcionalidade esta completa, e assim nada mais pode ser adicionada a ela.

Esses critérios de aceitação também ajudam o Product Owner a determinar ao time de desenvolvimento o que ele precisa para que uma tarefa proporcione um resultado esperado, e o time a partir dos critérios geram os Testes de Aceitação.

Testes de Aceitação.

Quando se fala de Testes de Aceitação em Scrum, deve-se pensar no conceito de testar uma funcionalidade do início ao fim, dando entradas para o sistema e observando o comportamento de saída. Os resultados devem estar compatíveis com os requisitos do sistema em termos de tempo de resposta, validade do resultado, facilidade de uso e qualquer outro critério que o cliente tenha estabelecido.

A importância esta baseada apenas no resultado que se quer obter. Após a determinada entrada, o sistema deve apresentar a resposta desejada, assim essa parte do software esta apta a ser considerada pronta. O objetivo é garantir que o sistema seja capaz de executar funcionalidades da forma desejada, garantindo a qualidade do produto em desenvolvimento.

O teste de aceitação é a última ação de teste antes da implantação do software, e tem como meta verificar se o software está pronto e pode ser usado pelos usuários finais para executar as funções e as tarefas para as quais foi criado. Existem três estratégias comuns para implementar um teste de aceitação. São elas:

• Aceitação Formal
• Aceitação Informal (Teste Alfa)
• Teste Beta

Aceitação formal

O teste de aceitação formal é um processo altamente gerenciado e costuma ser uma extensão do teste do sistema. Em muitas organizações, o teste de aceitação formal é totalmente automatizado. Em algumas organizações, a organização de desenvolvimento com os representantes da organização do usuário final, executa o teste de aceitação. Em outras organizações, o teste de aceitação é executado inteiramente pela organização do usuário final ou por um grupo objetivo de pessoas por ela escolhido.

Os benefícios dessa forma de teste são:

• As funções e os recursos a serem testados são conhecidos.
• Os detalhes dos testes são conhecidos e podem ser medidos.
• Os testes podem ser automatizados, o que permite o teste de regressão.
• O progresso dos testes pode ser medido e monitorado.
• Os critérios de aceitabilidade são conhecidos.

As desvantagens incluem:

• São necessários recursos e planejamento significativos.
• Os testes podem ser uma nova implementação dos testes do sistema.
• Os testes podem não revelar defeitos subjetivos no software, já que são procurados apenas os defeitos esperados.

Aceitação informal ou teste alfa

As funções e as tarefas de negócios a serem exploradas são identificadas e documentadas, mas não há casos de teste específicos para seguir. O testador individual determina o que fazer. Essa abordagem de teste de aceitação não é tão controlada como o teste formal e é mais subjetiva. O teste de aceitação informal é realizado com mais frequência pela organização do usuário final.

Os benefícios dessa forma de teste são:

• As funções e os recursos a serem testados são conhecidos.
• O progresso dos testes pode ser medido e monitorado.
• Os critérios de aceitabilidade são conhecidos.
• Serão revelados defeitos mais subjetivos do que no teste de aceitação formal.

As desvantagens incluem:

• São necessários recursos, planejamento e recursos de gerenciamento.
• Não há controle sobre os casos de teste que são usados.
• Os usuários finais podem se adaptar à forma como o sistema funciona e não encontrar defeitos.
• Os usuários finais podem se concentrar na comparação do novo sistema com um sistema antigo, em vez de procurar defeitos.
• Os recursos do teste de aceitação não estão sob o controle do projeto e podem ser limitados.

Teste beta

Nesse tipo de teste, a quantidade de detalhes, os dados e a abordagem adotada são de inteira responsabilidade do testador individual. Cada testador é responsável por criar o próprio ambiente, selecionar os dados correspondentes e determinar as funções, os recursos ou as tarefas a serem exploradas. Cada um deles é responsável por identificar os próprios critérios que o levarão a aceitar ou rejeitar o sistema no seu estado atual. O teste beta é implementado por usuários finais, geralmente com pouco ou nenhum gerenciamento por parte da organização de desenvolvimento.

Os benefícios dessa forma de teste são:

• O teste é implementado por usuários finais.
• Grande volume de possíveis recursos de teste.
• Aumenta a satisfação do cliente para aqueles que participam.
• Serão revelados defeitos mais subjetivos do que no teste de aceitação formal ou informal.

As desvantagens incluem:

• Nem todas as funções e/ou recursos podem ser testados.
• É difícil medir o progresso do teste.
• Os usuários finais podem se adaptar à forma como o sistema funciona e não encontrar ou relatar defeitos.
• Os usuários finais podem se concentrar na comparação do novo sistema com um sistema antigo, em vez de procurar defeitos.
• Os recursos do teste de aceitação não estão sob o controle do projeto e podem ser limitados.
• Os critérios de aceitabilidade não são conhecidos.
• São necessários recursos com suporte adicional para gerenciar os testadores beta.

Se durante os testes, o sistema não apresentar a resposta esperada, então este teste descobriu um erro, tornando-o visível e suscetível à correção. Em todo caso é importante testar o programa com entradas validas e não validas. O erro ao ser demonstrado deve impedir uma ação do usuário, onde uma entrada positiva ou negativa deve ter um valor correto as suas características. Caberá ao dono do negocio priorizar as operações que são mais importantes no sistema e quais possíveis entradas serão testadas.

Desta forma podemos garantir que todas as funcionalidades que foram sendo entregues ao cliente estão de acordo com a solicitação. Uma vez finalizado a Use Story o sistema estará em pleno acordo com as funcionalidades que foram solicitadas.

Escrito por:

Ademir Gomes Junior

Alex Araujo de Paula

Jaqueline da Silva Pereira

Jean Bueno