Vídeo muito bom... poderia me ajudar a criar 4 historias de usuários nesse exemplo? Preparação de uma campanha publicitária online para converter usuários da versão gratuita de um aplicativo em usuários pagantes. O app consiste em uma mesa de exercícios voltada para perda de peso. Na versão paga existem três categorias de exercícios (peitorais, abdominais e extremidades), narrados ao longo de 30 dias combinados com recomendações gerais sobre a dieta mais recomendada. A versão paga inclui uma análise personalizada a partir dos dados inseridos pelo usuário e um leitor de código de barras que fornece informações sobre as calorias de cada alimento.
Fala Diogo, parabéns pela didática, muito bom! Só um ponto, definição de pronto (DoD) é genérico aplicado as todas as historias de usuário, os critérios de aceite são específicos da história. Ex de DoD Funcionalidade disponível em produção Testes unitários realizados Cenários de testes aprovados Review realizada e aprovada E por aí vai
Sim, eu até já tenho uma listinha meio que pré-definida para a DoD e só vou copiando e colando em cada história pra ganhar tempo, á que não muda muito de uma pra outra. kkkk
Grande Diogo, parabéns pelo conteúdo. só uma informação... SPIKE são histórias de testes.. por exemplo se um time vai utilizar uma determinada tecnologia que não conhece... eles devem fazer um spike para testar a tecnologia antes de assumirmos como compromisso de entrega... então spike são pequenos testes de implementação, ou provas de conceitos...
Diogo, muito boa sua explicação! Explicação leve, objetiva, sem formalismo, muito fácil de entrar na cabeça. Você me passou o link pelo Linkedin. Valew!
Diogao, seria legal ter um conteúdo que você convida uma pessoa de design para mostrar a sinergia necessária entre os dois mundos: produto & design para que o usuário seja bem "servido". Nem sempre o que a gente rollouta tem as melhores métricas de adoção e ad vezes não é a funcionalidade em si, e sim a experiência fornecida. Acho que pode ser um conteúdo bem rico ;)
Mais um conteúdo top !!! Uma duvida: É normal criar uma historia de uma forma mais "superficial" e contar com a experiência dos Dev's ou geralmente é melhor detalhar o máximo possível as funcionalidades (validação de campo, comportamento da funcionalidade e etc.)? Pois caso seja muito detalhado, podemos "perder tempo" escrevendo o óbvio.
Boa pergunta, Thyago! Acho que a dúvida que todos temos quando estamos fazendo várias histórias. Mas a resposta é na linha que temos que escrever imaginando que uma pessoa média vai ler. (média no sentido de nova na empresa ou super antiga). Não necessariamente vc vai escrever tudo do projeto. Pois precisamos ser objetivos. Existem outras documentações que servem para dar contexto mais detalhado. Recomendo neste caso colocar o link delas para consulta. por ex: o link de uma apresentação do projeto, por ex. Temos que ter documentação nos Épicos tb. Para que as histórias consigam ser mais específicas. Em times de tecnolgia também temos o problema de ter uma giro alto de pessoas e Histórias é uma forma de deixar todo mundo na mesma página.
Ótimo conteúdo, muito obrigado por compartilhar esse conhecimento. Só me bateu uma dúvida que você montou o DOD para a história específica. O DOD não seria uma definição de pronto criada para que atenda a todas histórias?
Olá! Obrigado! Isso, eu coloquei o DoD para a história que coloquei como exemplo pois ela, em si, é uma feature inteira do produto. Assim, ela tem como ficar "Pronta". Tanto que para a História que usei como exemplo, comento que dá para criar Sub-tasks dentro dela. Eu acho que toda história fica melhor com o DoD pois conseguimos ter noção de quando ela termina e o que precisa ser feito. Histórias sem DoD ou Critérios de aceite tendem a gerar dúvidas. Ficou mais claro? :)
@@DiogoBeckerProductManagement Acho que minha pergunta ficou confusa. Minha dúvida é o seguinte: Na história específica, vc colocou um DOD com especificação para aquela história em específico. O DOD não teria que ser um conjunto de definições "geral", que quando qualquer história atenda, esteja "pronta" ? Ou realmente o DOD é específico por tarefa?
Olá! sim, é possível usar vários frameworks existentes (BDD, JTBD, etc) ou mesmo criar um próprio. Checklists sempre ajudam a gente nãoo esquecer nada relevante! :)
Olá! As regras de negócio podem estar na parte de Contexto. Ou então linkadas em um Doc mais abrangente de Product Discovery, já que as regras de negócio vão servir para várias Histórias.
Fiquei com uma dúvida. Normalmente na descrição do épico ali no Jira, devemos colocar também uma história de usuário do propósito da aplicação ou só uma descrição explicativa do que seria o épico?
Boa pergunta Lucas! O que diferencia um Épico de uma História às vzes é até filosófico. Gosto de enxergar um Épico como uma História GRANDE. Então eu seguiria de forma parecida, dando contexto, explicando quem são os clientes, stakeholders, qual o problema, necessidade, qual a solução, etc. Às vezes, acontece até da gente ter 1 História de usuário que fica tão grande que decidimos mudar ela para um Épico com outras histórias aninhadas. Porém, não precisa ficar repetindo descrição sempre, tá? A ideia desta "árvore" é agilizar e não burocratizar. Ficou mais claro?
Excelente, parabéns!
Muito obrigado!
Vídeo muito bom... poderia me ajudar a criar 4 historias de usuários nesse exemplo?
Preparação de uma campanha publicitária online para converter usuários da versão gratuita de um aplicativo em usuários pagantes.
O app consiste em uma mesa de exercícios voltada para perda de peso.
Na versão paga existem três categorias de exercícios (peitorais, abdominais e extremidades), narrados ao longo de 30 dias combinados com recomendações gerais sobre a dieta mais recomendada.
A versão paga inclui uma análise personalizada a partir dos dados inseridos pelo usuário e um leitor de código de barras que fornece informações sobre as calorias de cada alimento.
Fala Diogo, parabéns pela didática, muito bom!
Só um ponto, definição de pronto (DoD) é genérico aplicado as todas as historias de usuário, os critérios de aceite são específicos da história.
Ex de DoD
Funcionalidade disponível em produção
Testes unitários realizados
Cenários de testes aprovados
Review realizada e aprovada
E por aí vai
Olá, Lucas! Obrigado pelo feedback!
E massa demais a sua contribuição. Super clara! Faz sentido.
Obrigado e tamo junto!!
Sim, eu até já tenho uma listinha meio que pré-definida para a DoD e só vou copiando e colando em cada história pra ganhar tempo, á que não muda muito de uma pra outra. kkkk
Seria legal disponibilizar o Miro
Grande Diogo, parabéns pelo conteúdo. só uma informação... SPIKE são histórias de testes.. por exemplo se um time vai utilizar uma determinada tecnologia que não conhece... eles devem fazer um spike para testar a tecnologia antes de assumirmos como compromisso de entrega... então spike são pequenos testes de implementação, ou provas de conceitos...
Olá, Marcos!! Obrigado pelo feedback e contribuição!!
Baita conhecimento compartilhado! tamo junto!! ;)
Incrível esse vídeo, linguagem super simples que até parece que é fácil, hehehe. Sua didática é muito boa. Obrigada por manter este canal ativo.
Muito obrigado pelo feedback! Saber que o conteúdo é aprendido é o maior resultado que um professor pode receber. :)
Muito bom o conteúdo! a melhor aula sobre histórias de usuário que vi até agora no youtube
Muito obrigado pela mensagem, Victor! Conta muito pra mim! Tamo junto
Uhuuu... muito bom Diogo!! Gostei demais, ajudou muito!! Bora lá!! Ansioso para o próximo vídeo!!
Obrigado pelo feedback, Life!! tamo junto!! :)
Muito bom! Pra mim aproximou demais a teoria da prática. Perfeito!
Obrigado pelo feedback, Gabriel!! Pegou o espírito da coisa! Tamo junto
gostei muito do tipo de video
Obrigado pelo Feedback, Tiago! Tamo junto
Gostei Muito! Show!
Obrigado pelo feedback, Ariadne! tamo junto
Bom demais, como smp! Já tô me coçando pra fazer o curso kkkkk
Boa, Maísa!!! Será um prazer ter vc como aluna! Eu tiro as dúvidas por whats e email tb :)
Excelente vídeo!
Boooa, Felipe! Tamo junto!!
Muito bom... ótima explicação
Muito obrigado pelo feedback, Israel! Tamo junto
Parabéns, valeu mais uma vez Diogo. Seu conteúdo tem ajudado muito no meu dia a dia.
Muito obrigado novamente, Rafael!! Tamo junto, guri
Muito bom, está ficando inevitável fazer esse curso!!! Rsrs... Obrigado pelo conteúdo!
Obrigado pelo feedback, Stevan!! Será um prazer ter vc como aluno. Conte comigo, tamo junto
Excelente conteúdo !
Obrigado pelo feedback, Gustavo! Tamo junto!!
Diogo, muito boa sua explicação! Explicação leve, objetiva, sem formalismo, muito fácil de entrar na cabeça. Você me passou o link pelo Linkedin. Valew!
Booooa Jefferson! Obrigado pelo feedback e mensagem. Tamo junto!!
Sensacional!! Obrigada ♥
Top!! Obrigado
Diogao, seria legal ter um conteúdo que você convida uma pessoa de design para mostrar a sinergia necessária entre os dois mundos: produto & design para que o usuário seja bem "servido".
Nem sempre o que a gente rollouta tem as melhores métricas de adoção e ad vezes não é a funcionalidade em si, e sim a experiência fornecida.
Acho que pode ser um conteúdo bem rico ;)
Ótima sugestão, Leo!!
Vou pensar neste tema e criar um roteiro aqui.
Se tiver alguma sugestão de pessoa ref para falar, ajuda tb! hehe
Muito esclarecedor o vídeo.
Espero ter ajudado! tamo junto!
Conteúdo incrível, Diogo! Sou fã do canal ✨
Muito obrigado pelo feeedback e parceria faz tempo já, né? tamo junto, Larisse! :)
Boa didática!!!
Obribado pela mensagem! tamo junto
sensacional o video...
Muito obrigado pelo feedback, Kaio! Tamo junto!
@@DiogoBeckerProductManagement já vou fazer a aquisição do curso ein... realmente seus conteúdos bons e passam a visão do dia a dia
Mais um conteúdo top !!!
Uma duvida: É normal criar uma historia de uma forma mais "superficial" e contar com a experiência dos Dev's ou geralmente é melhor detalhar o máximo possível as funcionalidades (validação de campo, comportamento da funcionalidade e etc.)? Pois caso seja muito detalhado, podemos "perder tempo" escrevendo o óbvio.
O óbvio não é óbvio para todo mundo. Devemos escrever com detalhes de qualidade o que queremos construir =)
Boa pergunta, Thyago! Acho que a dúvida que todos temos quando estamos fazendo várias histórias. Mas a resposta é na linha que temos que escrever imaginando que uma pessoa média vai ler. (média no sentido de nova na empresa ou super antiga).
Não necessariamente vc vai escrever tudo do projeto. Pois precisamos ser objetivos. Existem outras documentações que servem para dar contexto mais detalhado. Recomendo neste caso colocar o link delas para consulta. por ex: o link de uma apresentação do projeto, por ex.
Temos que ter documentação nos Épicos tb. Para que as histórias consigam ser mais específicas.
Em times de tecnolgia também temos o problema de ter uma giro alto de pessoas e Histórias é uma forma de deixar todo mundo na mesma página.
Ótimo conteúdo, muito obrigado por compartilhar esse conhecimento.
Só me bateu uma dúvida que você montou o DOD para a história específica. O DOD não seria uma definição de pronto criada para que atenda a todas histórias?
Olá! Obrigado!
Isso, eu coloquei o DoD para a história que coloquei como exemplo pois ela, em si, é uma feature inteira do produto.
Assim, ela tem como ficar "Pronta".
Tanto que para a História que usei como exemplo, comento que dá para criar Sub-tasks dentro dela.
Eu acho que toda história fica melhor com o DoD pois conseguimos ter noção de quando ela termina e o que precisa ser feito. Histórias sem DoD ou Critérios de aceite tendem a gerar dúvidas.
Ficou mais claro?
:)
@@DiogoBeckerProductManagement Acho que minha pergunta ficou confusa. Minha dúvida é o seguinte: Na história específica, vc colocou um DOD com especificação para aquela história em específico.
O DOD não teria que ser um conjunto de definições "geral", que quando qualquer história atenda, esteja "pronta" ? Ou realmente o DOD é específico por tarefa?
Muito bom o vídeo! Tem algum motivo para você não usar o nível de "Funcionalidade" e ir do "Épico" direto para a "História"?
Olá, Funcionalidade é uma tradução para Feature? Se for, está um nível acima do Épico e seria gerenciada no Roadmap.
A escrita de cenários, no formato BDD, dentro da história faz sentido?
Olá! sim, é possível usar vários frameworks existentes (BDD, JTBD, etc) ou mesmo criar um próprio.
Checklists sempre ajudam a gente nãoo esquecer nada relevante! :)
Diogo, boa tarde!!! Tudo bem? E as Regras não deveriam entrar separado como o item Critérios de Aceite? Teria mensagens, como de sucesso ou de erro?
Normalmente sim. Aqui na minha empresa nós separamos: Histórias, cenários, requisitos e regras de negócio.
Olá! As regras de negócio podem estar na parte de Contexto.
Ou então linkadas em um Doc mais abrangente de Product Discovery, já que as regras de negócio vão servir para várias Histórias.
Fiquei com uma dúvida. Normalmente na descrição do épico ali no Jira, devemos colocar também uma história de usuário do propósito da aplicação ou só uma descrição explicativa do que seria o épico?
Boa pergunta Lucas!
O que diferencia um Épico de uma História às vzes é até filosófico.
Gosto de enxergar um Épico como uma História GRANDE.
Então eu seguiria de forma parecida, dando contexto, explicando quem são os clientes, stakeholders, qual o problema, necessidade, qual a solução, etc.
Às vezes, acontece até da gente ter 1 História de usuário que fica tão grande que decidimos mudar ela para um Épico com outras histórias aninhadas.
Porém, não precisa ficar repetindo descrição sempre, tá?
A ideia desta "árvore" é agilizar e não burocratizar.
Ficou mais claro?
@@DiogoBeckerProductManagement Ficou sim! Muitíssimo obrigado!
Pegunta de noob, essas historias de usuario serve a estrutura tbm pra BUGs?
Olá, Marieli. Para BUGs dá pra deixar mais direto e enxuto.
Se for um problema maior que apenas um BUG, ai recomendo fazer uma história de usuário.
Dinheiro faria sentido se tivesse opção de entrega já que é online
E o INVEST?
É um framework que pode te auxiliar a escrever. Mas é opcional.
Parabéns pela iniciativa. Peço mil desculpas, mas me vejo obrigado a comentar, o conceito de SPIKE dado no vídeo está equivocado!
Olá! Imagino que vc use o spike como o tempo dedicado a estudar para refinar, isso?
Ótimo conteúdo!
Obrigado pelo feedback Andre! tamo junto