- [email protected]
- + (55) 11 945 071 133
Como evitar o retrabalho de tarefas e atividades com histórias de usuário??
Não é um porre quando a gente se mata por uma tarefa ou atividade…
e quando terminamos dizem que não era bem isso que o cliente queria...
ou ainda que aquela funcionalidade não serve para nada?
Eu já me senti como um palhaço muitas destas vezes…
Outras eu alternava entre raiva e frustação!
Alguns de vocês podem até sentir o sangue subindo a cabeça quando isso acontece.
Quero te mostrar uma das maneiras mais simples de organizar demandas mais ágeis…
seja em formas de requisitos, ou em forma de atividades/tarefas, de forma ágil e centrado no que importa.
A seguir, você vai ver e entender:
Vamos em frente! 🙂
Histórias de Usuário é uma forma de apresentação mais transparente de demandas e requisitos..
que pode ser muito poderosa em nos ajuda a seguir alguns dos mais fundamentais princípios ágeis.
Princípios como a priorização da satisfação do cliente, com entregas antecipadas e regulares de valor às suas necessidades.
Ou ainda como o princípio da simplicidade na redução de tarefas desnecessárias.
De modo a organizarmos as atividades necessárias,
separando aquelas que realmente tem valor mais urgente, daquelas que não são assim tão importantes de imediato.
Podemos mesmo até utilizar quadros de comunicação visual para isso…
mas de nada adianta, se nos quadros constarem apenas tarefas que não possuem propósitos bem comunicados.
Ou ainda com interpretações dúbias. Que podem nos fazer sentir desorientados.
Para isso, a história de usuário usa uma metalinguagem, que nos ajuda a eliminar muitas destas situações.
E ela funciona assim:
Como [usuário ou papel]
Eu quero [ação]
Para que [propósito ou objetivo]
Então por exemplo:
“Como um líder de processos, eu quero visualizar a quantidade de análises em andamento, para que eu possa dimensionar as horas de trabalho de minhas equipes.”
Ou ainda
“Como um chefe de segurança, eu quero desabilitar cartões de acesso para evitar acessos fraudulentos em áreas sensíveis da companhia.”
Basta isso??
Ouvindo assim parece simples, não é? 🙂
Só que não, rs
Como eu digo em outro artigo, não podemos misturar o simples com o simplório.
Por exemplo, não é incomum encontrarmos histórias de usuários como:
“Como desenvolvedor, eu quero um ambiente de homologação, para que eu possa testar minhas implementações antes de colocá-las em produção.”
Ok, mas o que há de errado com isso?
“No primeiro momento nada”, alguém poderia dizer.
Afinal o desenvolvedor de sistemas, que rala, não poderia ser também uma persona?
Claro que pode.
Acontece que perder a visão dos usuários finais nesta ferramenta pode azedar o processo de entrega ágil.
Ver essa foto no Instagram
Vejamos: para que motivo o desenvolvedor precisa de uma infra de testes?
Alguém poderia dizer: “Para atender a uma necessidade do cliente.”
Necessidade como aquela de um líder de negócios receber uma funcionalidade…
onde ele pode puxar um relatório atualizado de análises em andamento.
Neste caso, a infra de teste pode, ou não, entrar mais como um pré-requisito desta história de usuário.
Uma vez que a user story foca nas necessidades mais urgentes do cliente.
E assim uma história de usuário acaba deixando mais claro a persona que vai lidar com a funcionalidade (no nosso exemplo o líder de processos) …
e quem vai construir a funcionalidade (no nosso caso, o desenvolvedor, o dev).
Por isso é comum classificarmos atividades como a de infra como uma tarefa ou subatividade derivada da história de usuário original.
Como aquela história original do líder de processos.
E também tem o seguinte:
o “como” ou “o quê é preciso”, fica todo a cargo do time desenvolvimento apurar,
encontrar soluções e recursos para que a história de usuário tenha o seu propósito atingido.
Afinal, não é só as necessidades dos clientes que podem mudar.
As formas de atendê-los também.
E são refinamentos como estes que um bom Product Owner é potencializado em suas formações profissionais.
o que fundamenta o sucesso desta metalinguagem, vem de outro lugar.
Quem já conhece administração de operações e produção…
já deve reparar na similaridade que esta ferramenta possui com uma outra ferramenta de qualidade…
onde são descritas o
O “quem”
O “o quê”
E “o porquê”
Essas 3 perguntinhas mágicas, não só revelam o desejo do cliente, mas os motivos que ele possui para aquelas necessidades.
Quantas vezes você já não se perguntou?
“Para que isso vai servir mesmo?”
Ou ainda pode ter passou por equipes que não atuavam com o mesmo senso de urgência que seus demandantes.
Um dos requisitos mais básicos do engajamento humano está justamente na identificação do propósito, ou motivos, em suas tarefas/missões.
Sem a compreensão da razão que gerou a demanda…
muitos não veem o valor que isso pode proporcionar.
E logo, cair em desinteresse.
Isso sem falar nas demandas, que mesmo entregando no prazo, nunca foram utilizadas.
Porque muitas vezes não questionamos para que servem.
E quando percebemos, já está lá mais uma funcionalidade inútil.
Por isso de sempre colocarmos o ponto de vista do usuário final daquela história.
Para evitar de realizarmos mais trabalhos que podem se provar inúteis.
Me diga aí nos comentários que tipos de trabalhos inúteis você também já fez.
E agora você sabe também o propósito da metalinguagem de uma user story:
A de colocar a visão do cliente em primeiro lugar.
Ou seja, de nos ajudar a ser customer centric.
E ainda minimizar, e até eliminar riscos.
Vídeo Aula: Histórias de Usuário
Antes de mais nada, devemos lembrar que, fora a estrutura original da metalinguagem…
não existe bala de prata para todos os cenários…
cada projeto, cada cultura corporativa, cada time tem a sua característica e seu contexto.
Por isso, devemos compreender que o processo de refinamento com User Story é um processo aberto e contínuo.
Ele por si não é um processo linear, como poderia ser sugerido na gestão mais tradicional de desenvolvimento de produtos e serviços.
Mas é um processo muito semelhante ao modelo PDCA para resolução de problemas. 😉
Assim, ele segue a mesma filosofia de aprimoramento contínuo (um dos fundamentos da gestão ágil de produtos e serviços).
Desta forma, vamos para algumas dicas de construção das histórias de usuários:
De maneira geral, um épico é nada mais que uma necessidade ou desejo ainda um pouco abstrata.
E por isso, normalmente ele é percebido com um “requisito grande” 😊
Afinal, em uma gestão ágil, nem sempre teremos todos os requisitos tão bem definidos logo de início.
Por isso, é natural quebrarmos estas necessidades em partes menores, definindo características e condições.
Até finalmente chegarmos a definir histórias de usuários.
Por isso, manter o rastreio desta relação entre Épicos e Histórias de Usuários pode te ajudar a manter o propósito original dos desejos descritos no início do projeto.
Evitando, assim, perguntas do tipo:
“Como foi que esta história chegou aqui mesmo?”😉
Ela nada mais é do que uma ferramenta, que indica uma resolução para uma necessidade ou problema.
Atender a esta necessidade ou este problema é o seu objetivo final 😉
É uma ótima ideia que cada história de usuário tenha aderência com os seguintes conceitos:
Independente: Cada história de usuário deveria ser finalizada independentemente de outras histórias de usuário.
Negociável: Seu próprio processo de refinamento exige uma comunicação construtiva e saudável com todos os interessados pelo produto ou serviço.
Valor: Cada user story deveria entregar um valor que resolve um problema negocial para o usuário final.
Estimável: Cada história de usuário deve ter detalhes o suficiente, que permite ao time de desenvolvimento definir um prazo, ou horizonte, de execução desta mesma história.
Small (Pequeno): Mesmo que que detalhes sejam desejados, o quanto menor podermos deixar uma história de usuário melhor.
Aqui vale recordar: Ser Simples não é o mesmo que ser simplório.
Testável: Cada user story permite que a funcionalidade desenvolvida seja testada, e define como deve ser testada (lembra dos critérios de aceitação?) 😉
Em qualquer início de projeto ou serviço, teremos histórias de usuário mais refinadas, e outros nem tanto assim 😊
Por isso é natural classificá-las de acordo com a situação que se encontram.
Se estão prontas para planejamento, ou ainda se dependem de confirmação com usuários ou com a área de negócios por exemplo.
Uma relação mais comum que encontramos no mercado é a seguinte:
Como podemos observar, a “história de usuário” é uma história do????
Usuário! 😊
Ou seja, ela conta uma necessidade, um problema a ser resolvido, sob a perspectiva do usuário final daquela funcionalidade.
Ter só a descrição da metalinguagem na história de usuário em um card, pode complicar a gestão do dia-a-dia do agilita a longo prazo.
Isso porque quanto mais o projeto se desenvolve, mais e mais histórias aparecem.
Em pouco tempo passamos de algumas poucas, para centenas ou milhares de histórias de usuário.
Por isso que encontraremos em muitas ferramentas de gestão ágil, a possibilidade de colocarmos títulos curtos e únicos para histórias de usuário.
No dia-a-dia, isso facilita a identificação do que estamos operacionalizando em determinada Sprint.
Uma boa estratégia para o refinamento de histórias de usuários é captar as intenções por detrás dos requisitos.
E para entender melhor essas intenções, uma boa ideia é usar de personas para compreender as principais características e objetivos de um tipo de usuário.
Uma vez que temos uma compreensão melhor da persona, podemos não só refinar melhor as histórias de usuário…
como podemos priorizá-las de acordo com os objetivos delas.
É de bom tom já definir os critérios de aceitação no refinamento da própria história de usuário.
Isso evita muita confusão nas reuniões de Revisão e de Retrospectiva de Sprints.
Com o intuito de ajudar no planejamento técnica, é de bom costume colocar requisitos técnicos aqui também 😉
Normalmente, costuma ser o Product Owner o responsável por selecionar e refinar as histórias de usuário para o desenvolvimento do produto ou serviço.
Porém, na gestão ágil, qualquer um pode escrever e refinar uma história de usuário para o time ágil.
De fato, o melhor é que a construção e refinamento destas histórias tenham a participação de todo o time.
Assim, evitamos que a user story seja passada adiante como um ticket qualquer.
Gerando mais confusão e interrupções para o desenvolvimento do produto ou serviço.
Pense que as histórias de usuário devem ser criadas com aqueles que irão desenvolver o produto ou serviço. E não para eles.
Nem toda a atividade ou tarefa é representada por uma história de usuário.
Lembre-se que uma user story é focada no usuário/cliente daquele produto o serviço.
Por isso, não faz muito sentido escrever histórias como:
Como um Developer…
Como um Arquiteto….
Se é uma tarefa, ela é apenas isso, uma tarefa.
Que por sinal, também pode ser vinculada às histórias de usuários e até aos épicos.
Aqui, o quadro Kanban é uma das ótimas, e das mais simples, ferramentas visuais para identificarmos em que fase ou etapa cada história de usuário está.
Além de nos permitir encontrar possíveis gargalos de onde e porque certas user stories estariam limitando a produtividade do time.
Se você nunca usou um quadro como este antes, fique tranquilo/a.
Não há necessidade nem mesmo de um software para isso 😉
Basta um quadro, com colunas para cada etapa ou fase, onde você pode colar post-its (com suas histórias) nele.
E desta forma observar o fluxo de desenvolvimento de uma Sprint.
E quem sabe, até se antecipar a problemas operacionais e impedimentos da Sprint.
Se necessário for, adicione qualquer nova informação que julgar pertinente à história de usuário.
Fluxogramas, desenhos, planilhas, relatórios… não importa.
Se for para ajudar a melhorar a compreensão, eles podem ser anexados junto à user story.
Tem hora que menos é mais..
mas também tem hora que mais é necessário.
A comunicação não é uma ciência exata, podendo a informação ser processada de maneiras diferentes.
O que pode gerar falsas interpretações e muitas discussões.
E claro, que podem acabar não resolvendo o problema do usuário final.
E assim gerando maior insatisfação de clientes, internos e/ou externos.
Bom, ou você aprende a comunicar suas funcionalidades e requisitos de forma correta…
…. ou infelizmente, você corre o grande risco de continuar atrasando seus projetos e produtos
…., ou o que é pior… perder seus clientes e suas oportunidades na carreira.
Por isso preparamos uma Masterclass para te apresentar novas técnicas e métodos para refinar requisitos e tarefas.
Para te ajudar a antecipar entregas e resultados, mesmo em grandes projetos/produtos.
Na Masterclass Fatiando e Quebrando Itens de Trabalho™, você vai descobrir e dominar técnicas que executam 2 etapas…
para engajar e produzir novas entregas com resultados adiantados para seus produtos e serviços.
Confira os detalhes para participar desta Masterclass exclusiva clicando aqui 😊
Ver essa foto no Instagram
Um grande abraço e te vejo em breve.
