Muitos já passaram por aquela situação onde o PO tenta formular uma História de usuário que contém um requisito de design, mas que, ou por mal entendimento, ou por que a história de usuário estava mal formulada, ou por que o designer simplesmente não captou a intenção do PO, a história é desenvolvida errada, e as vezes compromente seriamente a sprint de design e também a sprint de desenvolvimento.
É aí que entra o conceito de definição de pronto e preparado!
Relembrando, basicamente uma história preparada é uma história que já pode ser estimada pela equipe, porque ela atende a todos os quesitos necessárias para seu desenvolvimento, ou seja, é uma história entendida por todos, clara e que não está sujeita a incongruências.Uma história pronta é uma história que teve seu desenvolvimento terminado, e já pode ser avaliada na reunião de revisão pelo PO.
Mas esses fatores, muitas vezes não são triviais para uma história de design.Como lidamos com conceitos mais abstratos relacionados à emoção, bem estar dos usuários, ergonomia, a história pronta pode não estar exatamente do jeito que deveria estar.
Algumas dicas me ajudaram no entendimento de histórias de usuários, é claro que isso pode não ser suficiente para seu projeto, mas podem ajudar:
(1)Quando você for para a reunião de planejamento, leve um bloco de notas, e anote tudo!
Pergunte a equipe ou ao PO, a chave é perguntar, não haver dúvidas, muitas vezes, a descrição de como uma determinada tela deve ser não está clara, e às vezes, a equipe não sabe exatamente o que quer, nesses casos, vale agendar uma reunião com o PO e a equipe para que todos fiquem de comum acordo.
(2)Dependendo da necessidade, participe da reunião de revisão da equipe de desenvolvimento.
Esporadicamente, as necessidades da equipe de desenvolvimento eram as minhas necessidades também, então ouvir o que o PO estava querendo era fundamental para contextualizar as histórias, sejam as que foram reprovadas ou as novas histórias que dependem de um novo design.
(3)Pergunte, pergunte e pergunte!
Nunca é demais dizer “Não faça algo por instinto!” Pergunte a alguém da equipe, pergunte ao PO, pergunte ao SM, de preferência faça isso cara-a-cara em uma reunião rápida.
(4)Forneça um wireframe das novas telas!
Embora nosso foco não sejam em cargas de documentação como nos modelos clássicos, um wireframe pode ajudar e muito na visualização da localização dos componentes na tela, isso pode evitar aqueles famosos: “ Acho que isso não deveria estar ali…”
É claro, isso são só algumas boas práticas, não são métodos teóricos de eficácia comprovada! Mas pode ajudar sim a fazer um bom design, limpo, claro e correto!
E você? Tem outras práticas em seu trabalho? Compartilhe conosco.
