Conhecer as reais necessidades dos usuários e desenvolver funcionalidades condizentes com essa realidade são fatores primordiais na construção de produtos de sucesso. Neste artigo, você verá mais detalhes sobre esse tema, especialmente, no que se refere a técnicas para escrita de histórias do usuário de qualidade e assertivas, exemplo de aplicação e outros assuntos, que também são trazidos no livro Product Backlog Building (PBB), dos autores Fábio Aguiar e Paulo Caroli.
- Surgimento das histórias do usuário
- Método Cascata e Métodos Ágeis
- Formatos de Histórias do Usuário
- Critério de Aceite
- Quebrando histórias em tarefas
- Interface com o usuário
- Escrevendo histórias com PBB
- Exemplo de história do usuário
- TAPAs para verificar a qualidade das histórias do usuário
- Facilitadoras no PBB
- Definição de preparado
- Definição de pronto
- Histórias do usuário no Scrum
- Histórias do usuário no Kanban
Surgimento das histórias do usuário
Quando falamos em histórias do usuário, não podemos esquecer de um importante nome: o autor Mike Cohn. Ele é considerado uma das grandes referências quando se trata de histórias do usuário.
Em seu livro User Stories Applied: For Agile Software Development, Mike Cohn destaca que a melhor maneira de construir um produto em conformidade com as necessidades do usuário é fazendo uso de histórias do usuário.
Foi ele quem popularizou o acrônimo INVEST, que você irá conferir mais detalhes a seguir. Para Cohn, é fundamental haver a identificação dos papéis de cada usuário, pois, a partir disso, passa a existir uma conexão com a dor desse usuário e, assim, a criação de produtos de valor.
Método Cascata e Métodos Ágeis
O Método Cascata, também chamado de Modelo Waterfall ou Método Tradicional, é um modelo de gerenciamento baseado em fases, onde o término de uma fase indica o início da próxima. Por exemplo: planejamento, execução, validação e entrega.
Imagem: Cascata X Ágil.
No entanto, para os dias atuais, apesar do sucesso no século passado, o modelo em Cascata, aparenta ser um modelo “engessado”, tendo em vista que só há avanços no projeto a partir do final de cada etapa e esse seguimento depende, ainda, da aprovação do artefato gerado naquela etapa.
Os métodos ágeis vieram para mudar essa realidade. Com um modelo bem mais flexível, conta com o trabalho do time em ciclos curtos e frequentes, com o planejamento de atividades e entregas rápidas, centradas no usuário. Outra diferença grande está no fato da possibilidade de haver mudanças ao longo do desenvolvimento do produto, enquanto que no Método Cascata mudanças não são bem-vindas.
> Leia mais: Seria a Lean Inception uma espécie de Cascata Ágil?
Formatos de Histórias do Usuário
Originalmente, as histórias de usuário nasceram com o propósito de que a própria pessoa afetada escrevesse. No entanto, com o passar do tempo, muito impulsionado pela expansão do framework Scrum, a Product Owner tornou-se a pessoa principal a escrever essas histórias e organizá-las em um backlog de produto. Entretanto, qualquer um pode (e deve) escrever uma história de usuário. Aliás, o PBB te ajuda a escrever histórias do usuário. Confira mais nesse artigo e no livro PBB.
Imagem: Livro PBB – Formatos de História do Usuário.
3Ws da História de usuário
História de usuário é um formato textual para a descrição concisa de um requisito, que busca responder a três indagações específicas do acrônimo conhecido como 3Ws: Who – Quem? What – O quê? E why – Por quê?
INVEST
Em seu livro Extreme Programming Explored, William C. Wake compartilhou o acrônimo INVEST, onde cada letra representa uma das seis características importantes de uma história de usuário: independente, negociável, valiosa, estimável, small (pequena) e testável.
Alguns anos após essa criação, Mike Cohn acabou renomeando a letra S, de small, para sized appropriately (sob medida), pois algumas pessoas criavam histórias um pouco maiores, mas adequadas ao seu contexto.
- INDEPENDENTE: Uma história não depende de outra.
- NEGOCIÁVEL: Uma história captura a essência do que é desejado. Não é um contrato fechado, conversas e negociação são bem-vindas.
- VALIOSA: Uma história descreve, claramente, o valor para o cliente.
- ESTIMÁVEL: Uma história fornece informações suficientes para o time elaborar uma estimativa de alto nível.
- SOB MEDIDA: Uma boa história deve ser relativamente pequena em tamanho para ser concluída no menor tempo possível e caber em uma iteração, considerando o contexto do time.
- TESTÁVEL: Uma história deve estar clara o suficiente para que testes possam ser definidos para ela.
Logo, o acrônimo INVEST auxilia na escrita de boas histórias, com os seguintes questionamentos: ela é Independente? Negociável? Valiosa para o negócio? Estimável? Sob medida? Testável?
Modelo 3Cs
Além do Modelo INVEST, uma boa história de usuário também consiste em três elementos, chamados de 3Cs:
CARTÃO: A descrição feita para a história de usuário deve caber em um cartão índice, com informações breves e suficientes para identificá-la. O formato mais comum é:
- COMO <papel/perfil>
- POSSO <ação/meta>
- PARA <benefício/razão>
CONVERSA: Para esclarecer dúvidas e detalhar o trabalho para a implementação, muita conversa é necessária. Em histórias de usuário, as conversas serão contínuas, não somente no início quando o requisito é definido. Os melhores documentos nos ajudam a recordar nossas conversas, apesar disso, não as substituem.
CONFIRMAÇÃO: Nessa etapa, é determinado se o objetivo da história de usuário foi alcançado. Para isso, os critérios de aceitação são importantes e devem ser definidos para cada história antes que o time comece a implementá-la.
Critério de Aceite
O Critério de Aceite tem o objetivo de descrever a forma como validar uma história de usuário. Geralmente, uma história terá alguns critérios de aceite, também chamados de ACs (do inglês, acceptance criteria).
Com isso, os ACs fornecem uma lista de verificação que determina quando uma história de usuário está concluída, completa e funcionando.
Do livro Product Backlog Building, trazemos como exemplo a seguinte história: “como cliente, gostaria de sacar dinheiro no caixa eletrônico para evitar a fila do banco”. Segue uma possível lista de ACs para essa situação:
- O cliente com saldo suficiente consegue sacar dinheiro da sua conta.
- O cliente sem saldo suficiente não consegue sacar dinheiro da sua conta.
- O cliente com saldo suficiente não consegue sacar dinheiro da sua conta se o caixa eletrônico não tiver dinheiro suficiente para o saque.
O formato apresentado é comparado a uma checklist usada para verificar se a história está completa e funcionando, ou seja, se passa por todos os ACs. Havendo mais de cinco critérios, é indicado quebrar a história em duas.
Quebrando histórias em tarefas
Essa quebra das histórias em pedaços menores, dá surgimento às tarefas. Com elas, o time de desenvolvimento entra em detalhes técnicos sobre como os pedaços menores serão implementados. Diferente das histórias, as tarefas são mais diretas e com linguagem técnica, não seguindo um formato textual definido.
As tarefas identificam algo que precisa ser feito em uma história. Como exemplos de tarefas temos: alterar campos da tabela de partida, criar contas de teste para usuários, automatizar os scripts de geração de dados etc.
Interface com o usuário
A maneira de descrever a interface de uma história varia conforme a decisão do time e isso pode ser feito das seguintes formas: esboço (ou desenhos simples em um papel), wireframes, mockups ou protótipo.
Imagem: Livro PBB – Interface.
Um questionamento que surge é o quanto da interface precisa estar definida para começar o trabalho na história? A resposta é, basicamente, o acordo do time para decidir se a história está pronta do ponto de vista da UI. O mais importante é que o grupo esteja alinhado e confortável com o trabalho a ser realizado.
A imagem abaixo é uma representação do que foi o esboço da interface para a história.
Imagem: Livro PBB – Esboço de Interface.
Escrevendo histórias com PBB
O preenchimento do Canvas PBB será um facilitador na hora de escrever as histórias do usuário. Como foi visto anteriormente, a escrita de uma história de usuário basicamente responde a três perguntas principais: Quem? O quê? Por quê?
Imagem: Livro PBB – Quem? O quê? Por quê?
Diante disso, o PBB vem auxiliar na escrita das histórias de usuário. O método tem o “quem?” que é a persona; o “o quê?” que são os PBIs (abreviação de Product Backlog Items); e o “por quê?” que está nos benefícios da funcionalidade. Nas imagens abaixo, são exemplificadas as escritas de histórias com o auxílio do Product Backlog Building.
Imagem: Livro PBB – Histórias com PBB.
Faça o download deste post inserindo seu e-mail abaixo
Exemplo de história do usuário
No livro PBB, os autores compartilham alguns exemplos de história do usuário, como a criação do produto digital Palestras Coletivas. Criado pela comunidade Tá Safo, visa elaborar um portfólio de palestras e organizar eventos. Abaixo, você verá alguns detalhes sobre a descrição de três funcionalidades do produto com algumas histórias de usuário, critérios de aceite, tarefas e interface:
Persona, funcionalidade, histórias
Seguem as três funcionalidades de exemplo do Palestras Coletivas com suas respectivas personas e histórias de usuário.
PERSONA: PALESTRANTE
FUNCIONALIDADE 1: Publicar trabalho.
HISTÓRIA 1.1: Como palestrante, posso acessar a área de trabalho para gerenciar de forma privada.
HISTÓRIA 1.2: Como palestrante, posso realizar a publicação de trabalho para disponibilizar conteúdo.
HISTÓRIA 1.3: Como palestrante, posso linkar a apresentação externa para integrar trabalhos.
PERSONA: PARTICIPANTE
FUNCIONALIDADE 2: Participar de evento.
HISTÓRIA 2.1: Como participante, posso localizar evento disponível para visualizar programação.
HISTÓRIA 2.2: Como participante, posso efetuar a inscrição no evento para consumir conteúdo.
HISTÓRIA 2.3: Como participante, posso registrar check-in no evento para confirmar presença.
PERSONA: ORGANIZADOR
FUNCIONALIDADE 3: Organizar evento.
HISTÓRIA 3.1: Como organizador, posso definir programação do evento para divulgar a grade.
HISTÓRIA 3.2: Como organizador, posso divulgar evento nas mídias para atrair público.
HISTÓRIA 3.3: Como organizador, posso convidar co-organizadores do evento para facilitar a organização.
História, critérios de aceite, tarefas
Agora, confira um exemplo de uma história e dois habilitados da funcionalidade “publicar trabalho” do Palestras Coletivas. A história está de acordo com a definição de preparado, com seus critérios de aceite, tarefas e interface.
HISTÓRIA 1.1
Como palestrante, posso linkar a apresentação externa para integrar trabalhos.
CRITÉRIO DE ACEITE 1
CENÁRIO 1: Associar apresentação nas plataformas de compartilhamento de apresentação.
– Dado que existe um link válido na plataforma SlideShare
– Quando associar o link da apresentação externa
– Então mostrará uma prévia da apresentação na tela.
CRITÉRIO DE ACEITE 2
CENÁRIO 2: Associar apresentação ao publicar trabalho.
– Dado que o link da apresentação é válido
– Quando realizar a publicação do trabalho
– Então mostrará a apresentação associada nos detalhes do trabalho publicado.
TAREFAS
– Consumir o endpoint da apresentação.
– Criar UI para mostrar o arquivo PDF da apresentação.
– Criar lógica no backend para linkar apresentação com trabalho publicado.
– Alterar parâmetro para link publico ou privado.
– Criar dados de teste para verificar se link é válido.
– Alterar DB para incluir o link da apresentação.
TAPAs para verificar a qualidade das histórias do usuário
Mesmo usando o PBB para gerar suas histórias, é preciso verificar a qualidade das mesmas, ou seja, o alinhamento entre o time sobre os principais atributos da história. Foi com esse intuito que Manoel Pimentel criou a técnica TAPAs.
Segundo ele, o TAPAs ajuda a enriquecer a análise e o entendimento sobre os principais atributos de uma história de usuário, os quais formam o acrônimo TAPA: tangível, atômica, preciosa, acessível (em inglês, tangible, atomic, precious and affordable):
- TANGÍVEL: A história é tátil, concreta e específica.
- ATÔMICA: A história é pequena e independente.
- PRECIOSA: A história resolve um problema importante para o usuário.
- ACESSÍVEL: A história é de claro e fácil entendimento.
Similar a uma refeição em um restaurante espanhol de tapas, Manoel Pimentel explica que você vai se alimentar de várias tapas, que são entregues com frequência (Sprint a Sprint). Diferentemente de restaurantes tradicionais (não ágeis), que trabalham com um prato principal que vai demorar mais a ser servido, e, provavelmente, vai precisar de garfo e faca para cortá-lo em pedaços menores.
Facilitadoras no PBB
Em uma sessão de PBB, é fundamental definir quem será a chamada pessoa facilitadora. Entre as missões da facilitadora estão: ajudar a decidir quanto tempo a sessão irá durar; adequar a facilitação do PBB de acordo com o contexto e a realidade do time e da organização; provocar a colaboração de todas as pessoas do time; além de incentivar a comunicação ativa de todos os participantes na ideação, entendimento, análise e criação dos incrementos do produto.
A pessoa facilitadora pode ser toda e qualquer pessoa que tenha interesse em ajudar a construir um bom backlog do produto. Geralmente, alguém do time já assume o papel de facilitadora dos workshops colaborativos. Essa pessoa é uma boa candidata para uma primeira facilitação de PBB. Nesse sentido, também temos várias pessoas interessadas em que ocorra uma boa facilitação, como, por exemplo, a Product Owner, a Scrum Master, a agile coach, a gerente de produto e a desenvolvedora.
Definição de preparado
A definição de preparado (em inglês, definition of ready (DoR) é o acordo entre o time e a PO que indica quando um PBI estará preparado para ser puxado para uma Sprint, ou seja, quando ele terá informações suficientes para ir para planejamento, execução e entrega.
As pessoas costumam dizer que: “Esse item está ready para começar o trabalho”, e, geralmente, isso indica que o time:
- Tem a informação necessária para trabalhar no item;
- Entende o porquê do item;
- Consegue mostrar o término do trabalho;
- Identifica como o item compõe/se relaciona com uma funcionalidade;
- Concorda que o item cabe em uma Sprint.
Em relação a cada PBI candidato a próxima Sprint, o time verifica se:
- O PBI está representado por uma história de usuário.
- O PBI está coberto por critérios de aceite & BDD.
- O PBI está mapeado para uma interface (quando necessário).
- As dependências do PBI estão identificadas (se houver).
O refinamento do backlog do produto deve ser contínuo. Vale lembrar que o uso da definição de preparado e da definição de pronto não se limita somente ao Scrum, pois também é uma prática muito útil quando estamos trabalhando com Kanban e outros métodos ágeis.
Definição de pronto
Já a definição de pronto (em inglês, definition of done (DoD), é o acordo que demonstra a qualidade do PBI produzido, na qual “done” comprova a satisfação de todos com o trabalho realizado. Ela esclarece o entendimento do trabalho concluído como parte do incremento do produto.
Com isso, em relação a cada PBI considerado pronto, o time demonstra que o item:
- Entrega um incremento do produto.
- Contempla os critérios de aceite estabelecidos.
- Está documentado para uso.
- Está aderente aos padrões de codificação.
- Mantém os índices de performance do produto.
Histórias do usuário no Scrum
O Scrum é considerado a metodologia ágil mais famosa e está baseado no conceito de Sprint – ciclos curtos (uma ou duas semanas) – para manter a cadência de um time. Com isso, é recomendado que cada Sprint tenha seu início definido com uma reunião de planejamento (Sprint Planning) e finalize com um encontro visando à revisão do trabalho realizado (Sprint Review).
Antes da Sprint Planning, as funcionalidades desejadas são detalhadas em histórias do usuário. Para essa construção, o método PBB irá auxiliar na quebra dessas funcionalidades em histórias, ou seja, as funcionalidades do seu PBB Canvas vão estar sendo detalhadas em histórias do usuário.
Dessa forma, durante a Sprint, o time Scrum trabalha nas histórias do usuário. Na Sprint Review, o time vai verificar o andamento dessas histórias, das suas funcionalidades e do incremento do produto. Após, o time Scrum segue trabalhando, o incremento é entregue e o time segue trabalhando nas próximas funcionalidades e histórias, do próximo incremento do produto.
>> Leia mais: SCRUM: significado, aplicação, conceitos e exemplos.
>> Leia mais: Como fazer a entrega do MVP usando Scrum e Kanban?
Histórias do usuário no Kanban
Outro método bastante reconhecido é o Kanban, criado por David J. Anderson. É muito utilizado para gestão do fluxo de trabalho de um processo incremental e evolutivo. Assim, é possível ter uma visualização compartilhada de todas as fases do fluxo de trabalho, as pessoas e as tarefas a serem executadas.
Kanban recomenda limitar o trabalho em andamento (WIP de work-in-progress em Inglês). Com isso, acontece um “sistema puxado”, ou seja, um novo trabalho só é “puxado” para a nova etapa quando há capacidade disponível dentro do limite WIP. Isso faz com que haja organização, planejamento, agilidade e não sobrecarregue o time.
Em um quadro Kanban simplificado, você vai montar e dividir o seu work in progress com as próximas funcionalidades e histórias do usuário (To Do), as que estão em trabalho (Doing) e, na última coluna, as funcionalidades que já estão prontas (Done). Ao terminar todas as histórias de uma funcionalidade, abre-se espaço no quadro e puxa a próxima funcionalidade.
>> Saiba mais: 3 principais fatores de atrasos em projetos ágeis.
Muito deste conteúdo vem do livro PBB, um pouco do livro Lean Inception e, mais um pouco, em outros posts e no E-book e Treinamento Lean Delivery.
Este conteúdo foi escrito e compilado por Paulo Caroli e revisado por Fábio Aguiar.
Gostou deste conteúdo?
>> Então confira o livro PBB e o Treinamento PBB.
>> Na página do livro PBB você também vai encontrar um excelente material (DoR, DoD, ACs etc) para baixar em formato PDF.
Na Caroli.org há, dentre outras coisas, diversos materiais relacionados ao tema. Acesse agora e dê continuidade ao seu processo de conhecimento e aprendizado, bem como na construção de um produto de sucesso.
