Trabalho da disciplina Métodos Ágeis aplicados a sistemas móveis, do curso de Especialização em Tecnologia Java e Desenvolvimento para Dispositivos Móveis - turma 2012.
Autores:
- Leosmar José Machado
- Nilson André Machniewicz
- Geucimar Brilhador
A abordagem de
desenvolvimento de software definida no Manifesto Ágil1
trouxe, além da mudança na forma de encarar os processos de
desenvolvimento, na relação entre desenvolvedores e clientes, novos
artefatos que fazem parte do dia-a-dia dos membros de uma equipe
focada nesta forma de desenvolvimento. O user story
(história do usuário) representa certamente o coração desta
metodologia, pois este artefato rompe com os paradigmas adotados nas
metodologias mais tradicionais como o modelo em Cascata ou mesmo o
RUP (Rational Unified Proccess).
Martin Fowler2,
um agilista pioneiro, faz, em seu blog, uma comparação entre os use
cases (casos de uso) e o user stories e ressalta que
muitas pessoas na comunidade ágil encaram os user stories
como uma forma simplificada dos casos de uso utilizados nas
metodologias tradicionais. Porém, embora haja alguma semelhança
entre os artefatos, é importante observar que eles são, em
essência, bastante diferentes.
Definição e User
Story
Dean Leffingwell define:
“A user story is a brief statement of intent that describes
something the system needs to do for the user”3.
O
Artigo “User Stories. O que São? Como Usar ?”, publicado
por Glauco Primo4,
nos permite a compreensão de que user stories são artefatos
de desenvolvimento utilizados em sistemas geridos segundo
metodologias ágeis.
Segundo
ele, user stories focam nos objetivos do usuário e em como o
sistema alcança esses objetivos, devendo cada user story ser
refinado até que possa ser inserido em um pequeno cartão,
facilitando a sua utilização para especificar o ator, a ação e a
funcionalidade desejada.
Essa divisão em ator,
ação e funcionalidade nos permite analisar as necessidades reais
dos usuários e ir diretamente ao ponto que se deseja no software,
quando podemos verificar se realmente uma nova implementação será
ou não incorporada ao software.
Outro ponto importante é
que esse mecanismo de trabalho permite observar a possibilidade de
priorizar os processos, atingindo assim o produto final do software
com maior agilidade e confiabilidade, pois podemos estimar os
esforços necessários e aperfeiçoar o processo de desenvolvimento,
analisando as necessidades reais e os esforços necessários para
implementá-los.
Observamos que, no
artigo, o foco de user stories é trabalhar com “Histórias
de Usuários” e não mais com requisitos prontos, aumentando a
visão dos Analistas e programadores, bem como do próprio usuário,
sobre as suas necessidades reais, o que permite um melhor engajamento
do processo de desenvolvimento, com evoluções das rotinas de acordo
com as ideias que vão sendo compartilhadas entre o usuário e os
programadores envolvidos na automatização dos processos.
Com user stories
se utiliza ainda de critérios de aceitação, com o objetivo de
facilitar o entendimento de todos os envolvidos, interna ou
externamente ao processo, sendo
esses representados por uma lista de itens de
negócio que expressam formas de usar a funcionalidade implementada
em uma história. O objetivo dessa lista é validar se a história
foi implementada de acordo com o que o usuário queria.
Esses
critérios (itens) surgem de perguntas que a equipe faz ao PO
(Product Owner), no momento em que a história está
sendo descrita, na busca por obter mais detalhes do que deve ser
implementado.
Exemplo
e critérios de aceitação:
História
coletada com o usuário
- Como vendedor eu gostaria de verificar se um livro está disponível no estoque para Venda.
Critérios para
aceitação
- O vendedor não pode solicitar a busca se não informar o nome do livro;
- O sistema, encontrando o livro, deve apresentar todos os dados do livro (nome completo, autores, editora e ano de edição) e a quantidade em estoque;
- O sistema, não encontrando o livro, deve informar que o livro não foi encontrado.
Segundo
Felipe Freire5,
as user
stories
fracionam os requisitos para que seja possível e de maneira mais
fácil, estimar o esforço para realizar aquele objetivo. Resumindo,
user
stories
são descrições simples que descrevem uma funcionalidade e é
recomendável que sejam escritas segundo
o ponto de vista do usuário,
de maneira muito simples e de fácil entendimento.
Essa técnica ajuda a
estabelecer uma comunicação clara no time. Ao invés de ser uma
forma muito especializada de capturar requisitos, que exige um
especialista para aplicá-la corretamente. As user stories
podem ser elaboradas e compreendidas por qualquer membro da equipe de
projeto. Nesse sentido, essa técnica fortalece a colaboração
pois ela exige que os membros da equipe conversem para que a user
story seja compreendida por todos.
Outro ponto importante é que as user
stories são pequenas e simples e não capturam muitos detalhes.
Por deixar de fora detalhes de implementação, como a navegação no
sistema, a user story requer muito pouca manutenção, não se
tornando um documento obsoleto rapidamente ou que exija muito esforço
para mantê-lo atualizado.
As user stories ajudam a
transformar um grande problema (que o sistema irá resolver) em
pequenas partes. Essas partes são utilizadas para guiar o
desenvolvimento. Dessa forma, as user stories possibilitam o
desenvolvimento iterativo, permitindo que a equipe do projeto faça
pequenas entregas evolutivas enquanto interage e colabora com o
cliente.
A grande diferença
entre user story e use case
Como podemos ver, é
bastante reforçado entre a comunidade, que o user story
representa uma percepção do usuário do sistema, por isso
diferentemente do casos de uso, as pequenas sentenças que definem um
user story são redigidos na primeira pessoa do singular,
utilizando a forma: Como um <ator> eu preciso <ação>
para <resultado>. Esta forma de redação difere dos casos
de uso que normalmente são redigidos de forma impessoal, segundo a
visão que o analista tem dos passos realizados pelo usuário na
realização de sua tarefa.
Esta abordagem faz do
user story o principal artefato e o transforma no pilar do
processo de desenvolvimento ágil.
1
Disponível
em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em:
08/03/2013.
2
FOWLER,
M. (2002). Use
Cases and Use Stories.
Disponível em:
<http://www.martinfowler.com/bliki/UseCasesAndStories.html >.
Acesso em: 08/03/2013.
3
LEFFINGWELL,
D. (2011). Agile
Software Requirements.
1st ed. Pearson Education. “Um User
Story
é uma breve afirmação que descreve alguma função que o sistema
deve fazer para o usuário.” (Tradução dos autores).
4
Disponível
em:
<http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/>.
Acesso em 08/03/2013.
5
FREIRE,
Felipe. User Story. Por que utilizar user stories ao inves de caso
de uso. Disponível em
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/rationalbrasil/entry/user-stories?lang=en>.
Acesso em 08/03/2013.
Nenhum comentário:
Postar um comentário