Nossa incrível apenas conteúdo de extrema qualidade, esta me ajudando muito pois me foi tacado esse cargo em um projeto e to tendo que aprender a lidar e você tem me ajudado bastante a como me organizar e realizar as reuniões muito obrigado
Dicas incríveis! Recentemente comecei como Product Owner Júnior e ainda me sinto um pouco perdida nesse rito, já que meu papel é apenas comentar sobre o que foi feito, enquanto o Tech Lead conduz a reunião. Diogo, você poderia fazer um vídeo explicando como realizar uma boa reunião de rollout? Parabéns pelo excelente conteúdo!
Fico feliz que você tenha encontrado as dicas úteis! A carreira de Product Owner pode ser desafiadora, mas com prática você vai se sentir mais confiante. Vou colocar aqui na lista sua sugestão de vídeo sobre reuniões de rollout! :)
Boa pergunta, Thiago. O que eu faço é organizar com os outros líderes como vamos fazer a divisão. (e esta divisão pode mudar após 3 ou 6 meses, ok?). Geralmente eu vou focar mais no squad que precisa mais, que está com gargalo na parte de Produto (geralmente é discovery ou é comunicação com stakeholders). O squad que está mais focado em desenvolvimento, deixo mais à cargo do Tech Manager. Assim, eu NÃO participo de todas as reunião, e alinho o que pode ter passado na 1on1 que faço semanalmente com o Tech Manager. Ficou mais claro?
Obrigado pelo vídeo. Como funciona o ciclo de desenvolvimento do time? Você menciona sprints de duas semanas, dai o time de desenvolvimento libera uma versão para o time de QA testar alguns dias antes do termino da sprint? ou as duas semanas é para desenvolvimento e libera algo para o time de QA no ultimo dia da sprint?
Olá! em times ágeis raiz, não teria uma divisão entre QA e o resto da squad. As pessoas de QA ficam integradas então o processo é mais contínuo (em Loops). Então sempre que tiver uma feature concluída, ela é testada para validar, ajustes podem ser necessários, e segue o rollout. Em outras palavras, os testes são histórias de usuários normais a serem feitas durante a Sprint.
Esses exemplos que você deu não está mais pro lado da retrospectiva? Na review não deveriam ser feitas discussões técnicas? Ex: Nas proximas US precisamos definir melhor o critério de aceitação... A documentação de API não está boa... Nesse Card não está claro a parte X e assim por diante Sei lá, as vezes to viajando.. mas o review e retrospectiva me parece bem próximas
A retrospectiva é especificamente sobre como trabalhar melhor em equipe, focando em não necessariamente apenas na Sprint. A review é mais técnica e foca no que aconteceu na Sprint. Pode-se fazer uma seguida da outra sem problemas. A única questão que precisa cuidar é que na Review pode ser convidado outras pessoas para participar (como o cliente). Sobre os ex que vc deu, minha sugestão inicial seria que apareceriam mais nas: - Comentários sobre próximas descrições de US (retro) - Documentação (retro) - este card não está claro a pate X (review) Porém, o cerne aqui não pode ser esquecido!!! O objetivo final é que haja a interação, confiança e abertura para se falar estes tópicos. O que a gente tenta combater é o silêncio e medo de comentar o que não estamos satisfeitos. Por isso, pode acontecer de alguns assuntos virem não necessariamente na reunião específica. A intenção não é colocar em caixinhas, mas sim, criar entrosamento.
As perguntas “quais foram os problemas…”, “E o que aprendemos” não seria na retrospectiva???? A review não seria pra revisar com os stakeholders e quais são os próximos passos?
Olá, nas perguntas sobre Problemas e Aprendizados eu me refiro aqui especificamente sobre o desenvolvimento, código, pesquisas, etc. Um momento dedicado para o time revisar o que fez e compartilhar conhecimento entre si. Isso a cada 2 semanas. Esta forma de trabalhar foi uma adaptação que fizemos ao longo do tempo que proporcionou muito resultado para o time. Existe também a REVISÃO com o cliente externo (que é a que vc se refere). Porém, na minha experiência não tem exatamente uma frequência definida e tem uma proposta mais de atualização de status, e coleta de feedback do que foi feito. Então eu deixo ela "fora" do calendário fixo da gestão ágil. Na retro, vc pode usar as mesas perguntas, Mas o objetivo e foco é mais na relação de como trabalhar entre o time.
Nossa incrível apenas conteúdo de extrema qualidade, esta me ajudando muito pois me foi tacado esse cargo em um projeto e to tendo que aprender a lidar e você tem me ajudado bastante a como me organizar e realizar as reuniões muito obrigado
Olá, Daniel!! Blz?
Obrigado pelo feedback!!
Muito sucesso na jornada! Tamo junto
Muito massa Diogo, trazer exemplos práticos, isso com certeza é um diferencial do seu conteúdo. Ajudou bastante, valew!
Obrigado pela mensagem e feedback!!A ideia é sempre trazer a vida real para aprender com exemplos. tamo junto!!!
Excelente, conteúdo! Obrigada, Diogo. Tudo 100% claro!
Obrigado pelo feedback, Maria ! tamo junto!
Dicas incríveis! Recentemente comecei como Product Owner Júnior e ainda me sinto um pouco perdida nesse rito, já que meu papel é apenas comentar sobre o que foi feito, enquanto o Tech Lead conduz a reunião.
Diogo, você poderia fazer um vídeo explicando como realizar uma boa reunião de rollout?
Parabéns pelo excelente conteúdo!
Fico feliz que você tenha encontrado as dicas úteis! A carreira de Product Owner pode ser desafiadora, mas com prática você vai se sentir mais confiante. Vou colocar aqui na lista sua sugestão de vídeo sobre reuniões de rollout! :)
Pode comentar como conduz as atividades com diversas squads? Você participa de todas as reuniões com todas squads?
Boa pergunta, Thiago.
O que eu faço é organizar com os outros líderes como vamos fazer a divisão. (e esta divisão pode mudar após 3 ou 6 meses, ok?).
Geralmente eu vou focar mais no squad que precisa mais, que está com gargalo na parte de Produto (geralmente é discovery ou é comunicação com stakeholders). O squad que está mais focado em desenvolvimento, deixo mais à cargo do Tech Manager.
Assim, eu NÃO participo de todas as reunião, e alinho o que pode ter passado na 1on1 que faço semanalmente com o Tech Manager. Ficou mais claro?
Obrigado pelo vídeo.
Como funciona o ciclo de desenvolvimento do time? Você menciona sprints de duas semanas, dai o time de desenvolvimento libera uma versão para o time de QA testar alguns dias antes do termino da sprint? ou as duas semanas é para desenvolvimento e libera algo para o time de QA no ultimo dia da sprint?
Olá! em times ágeis raiz, não teria uma divisão entre QA e o resto da squad. As pessoas de QA ficam integradas então o processo é mais contínuo (em Loops). Então sempre que tiver uma feature concluída, ela é testada para validar, ajustes podem ser necessários, e segue o rollout.
Em outras palavras, os testes são histórias de usuários normais a serem feitas durante a Sprint.
Esses exemplos que você deu não está mais pro lado da retrospectiva?
Na review não deveriam ser feitas discussões técnicas?
Ex: Nas proximas US precisamos definir melhor o critério de aceitação... A documentação de API não está boa... Nesse Card não está claro a parte X e assim por diante
Sei lá, as vezes to viajando.. mas o review e retrospectiva me parece bem próximas
A retrospectiva é especificamente sobre como trabalhar melhor em equipe, focando em não necessariamente apenas na Sprint.
A review é mais técnica e foca no que aconteceu na Sprint.
Pode-se fazer uma seguida da outra sem problemas.
A única questão que precisa cuidar é que na Review pode ser convidado outras pessoas para participar (como o cliente).
Sobre os ex que vc deu, minha sugestão inicial seria que apareceriam mais nas:
- Comentários sobre próximas descrições de US (retro)
- Documentação (retro)
- este card não está claro a pate X (review)
Porém, o cerne aqui não pode ser esquecido!!!
O objetivo final é que haja a interação, confiança e abertura para se falar estes tópicos. O que a gente tenta combater é o silêncio e medo de comentar o que não estamos satisfeitos. Por isso, pode acontecer de alguns assuntos virem não necessariamente na reunião específica. A intenção não é colocar em caixinhas, mas sim, criar entrosamento.
👏
As perguntas “quais foram os problemas…”, “E o que aprendemos” não seria na retrospectiva???? A review não seria pra revisar com os stakeholders e quais são os próximos passos?
Olá, nas perguntas sobre Problemas e Aprendizados eu me refiro aqui especificamente sobre o desenvolvimento, código, pesquisas, etc. Um momento dedicado para o time revisar o que fez e compartilhar conhecimento entre si.
Isso a cada 2 semanas. Esta forma de trabalhar foi uma adaptação que fizemos ao longo do tempo que proporcionou muito resultado para o time.
Existe também a REVISÃO com o cliente externo (que é a que vc se refere). Porém, na minha experiência não tem exatamente uma frequência definida e tem uma proposta mais de atualização de status, e coleta de feedback do que foi feito. Então eu deixo ela "fora" do calendário fixo da gestão ágil.
Na retro, vc pode usar as mesas perguntas, Mas o objetivo e foco é mais na relação de como trabalhar entre o time.