(INÍCIO)
[00:00:01]
M1: Bom dia, boa tarde, boa noite. Este é mais um episódio de Enzimas,
breves reflexões que te ajudam a catalisar o agilismo em sua organização.
M2: Bom dia, boa tarde, boa noite. Meu nome é Felipe Soares, sou Product
Owner aqui na DTI Digital e o episódio de Enzimas de hoje é sobre como
escrever boas histórias de usuário. Antes de falar sobre como escrever essas
histórias, vamos entender, primeiramente, o porquê de escrevê-las.
Quando a gente tem demandas para o nosso time de desenvolvimento é
normal que a gente passe o que precisa ser construído, porém, a gente
passa a ele o quê? Se é um contexto, se é um cenário, o nosso time de
desenvolvimento pode não compreender muito bem o que a gente deseja
e até mesmo desenvolver funcionalidades, features, que não façam
sentido, tanto em se tratando de negócios, quanto de usuário. Então é
importante que a gente traga outros pontos. O para quem; em que
2
apresento os meus usuários, para quem eu quero construir e entregar
aquela funcionalidade; e o porquê, por que quero entregar essa
funcionalidade para esse usuário? Qual dor? Qual necessidade quero
atender com ela? São os três pontos base. A escrita de história de usuário,
nós a escrevemos porque precisamos contextualizar, entregar uma
narrativa do que a gente precisa construir para o nosso time de
desenvolvimento para que aquilo faça sentido e ele consiga construir de
uma forma mais assertiva. Portanto, já nesse conceito do porquê, a gente
já entende um pouco do como escrever boas histórias de usuário. Aqui eu
trouxe o núcleo da escrita de uma história de usuário, esses três pontos: o
quê; o para quem; e o porquê. Nós teremos vários templates de escritas de
usuário no mercado, disponíveis. Vários templates que a gente pode utilizar
para escrita, e deve-se utilizá-los, mas eles não vão fugir muito desses três
pontos que nos direcionam, realmente, no entendimento daquela
necessidade. Essas histórias de usuário podem surgir em vários momentos.
Elas podem surgir numa reunião com o meu cliente, em um teste com o
meu usuário, em um feedback. Podem surgir de um trabalho de benchmark,
em um trabalho de discovery. Então elas podem vir de várias fontes.
Quando surgem esses insights, necessidades e essas identificações, é
importante que escrevamos essas histórias de uma forma que, depois de
um tempo, quando aquela história for priorizada e a gente utilizá-la, ela faça
sentido. Porque nem sempre que a gente escreve uma história de usuário
significa que ela será construída imediatamente. Ela entrará para o nosso
backlog e pode ser construída próximo ao que a gente cadastrou ou
posteriormente, quando fizer sentido. Então é importante que a gente seja
bem objetivo na escrita dessas histórias de usuário e siga muito esses
critérios que eu trouxe aqui. A gente deve ter em mente que ela precisa ser
3
bem curta e bem simples porque a intenção nesse primeiro momento não
é detalhar demais aquela história de usuário, não é, ainda, pensar na
solução, dizer como ela será construída, é documentar uma necessidade
que identificamos. No momento que aquela história de usuário for
priorizada no backlog pelo PO, pelo PM, passará por um rito que a gente
chama de refinamento, um processo de refinamento. Tanto refinamento da
parte de negócios, em que a gente vai entender melhor aquela
necessidade, avaliar o que a gente precisa, quais são os critérios para
atender àquela necessidade, a melhor forma de solução e também
selecionar os critérios técnicos que envolvam a construção daquela história.
Então, nesse momento, essa história será refinada. A gente pode até
mesmo utilizar uma técnica muito comum, a técnica INVESPT, em que a
gente traz alguns pontos. Esse acrônimo significa que a história precisa ser
independente, ou seja, não depender de outras histórias para ser
construída; que seja negociável, ou seja, que a gente consiga gerar
discussões a partir dela e entender a melhor solução; valiosa, ou seja,
entregue valor para o meu usuário; estimável, que o time consiga estimála; pequena, caiba em um ciclo de desenvolvimento, em uma sprint;
testável, que a gente consiga testá-la, que o meu desenvolvedor consiga
testá-la. Esse é o acrônimo INVESPT, que é utilizado nesse momento em
que a gente vai refinar para que a gente se atente a esses pontos. Além
disso, é importante também que quando a gente fizer essa escrita da
história de usuário, a gente envolva o nosso cliente para que ele, além de
ter visibilidade do que a gente está pensando em construir, consiga
contribuir com os insights que ele tem por parte do negócio, por parte da
estratégia. Isso é muito importante. Outro ponto que é importante também
a gente se atentar é que esses templates, sobre os quais eu falei um pouco,
4
não quer dizer que a gente precise segui-los e esses refinamentos, que
existe uma forma, como o que eu trouxe da técnica INVESPT, que a gente
deve utilizar isso. Não quer dizer que a gente deve utilizar. São boas práticas
que nós comumente seguimos, a maioria das pessoas pode seguir, mas a
gente precisa entender que é interessante utilizar esses conceitos, essa
base, e que a gente consiga trazer isso para o nosso cenário, para o nosso
time de desenvolvimento porque a escrita, a forma como a gente traz isso
varia muito entre POs, entre time de desenvolvimento. Porque pode fazer
sentido escrever de uma determinada forma para um time que é mais
júnior, para outro time que é mais sênior, ou para o pleno a gente possa
escrever de uma forma diferente. Essa questão do refinamento, a gente
precisa ter essa mobilidade de adaptar, utilizar um conceito base dessas
questões e adaptar ao nosso cenário o que faz sentido para nós. O que a
gente deve ter claro é que as histórias de usuários, para serem bem
construídas precisam responder: o quê; para quem; e o porquê; que elas
sejam simples e objetivas para que qualquer pessoa que utiliza aquela
história de usuário em algum momento, seja um desenvolvedor, seja um
designer, seja o meu negócio, ele consiga entender e dar sequência na
construção daquela feature, daquela funcionalidade.
[00:07:25]
