O Everton mencionou anteriormente a função do Product Owner (PO). Com meus sete anos de experiência em desenvolvimento, sempre vi as Histórias de Usuário (HIS) chegarem de maneira estruturada, como casos de uso ou como backlog da sprint. Este ano, no entanto, foi a primeira vez que vivenciei o processo inverso. Durante as reuniões de planning, eram os desenvolvedores que deveriam trazer as HIS para o backlog, mas as histórias que chegavam de Produto algumas completamente erradas. Por exemplo, recebíamos uma solicitação para construir um carro e, durante o refinamento, descobríamos que os requisitos eram totalmente diferentes, como, por exemplo, construir uma van. Foi uma verdadeira bagunça.
Muito bom, poderia explorar os dois últimos pontos, Histórias/Tarefas e Lista passo a passo, pois geralmente deixam para desenvolvedor, com tempo de 30 min para gerar todos os cards para as 2 semanas
Opa, posso sim. Vou dar um exemplo que acabei de passar. Eu e um amigo estamos fazendo um projeto para facilitar a vida de pessoas infoprodutoras e uma das funcionalidades é analisar desempenho de campanhas no meta ads. Então, resumidamente, o requisito do ponto de vista de sistema ficou algo como: Preciso ser capaz de analisar os dados de uma campanha dentro de um intervalo de tempo. Poderia ter saído dos ou mais requisitos de sistema. Não existe granularidade certa, pelo menos na minha opinião. O que eu precisei fazer foi pegar esse requisito e dividir em tarefas que quando completadas me permitissem entregar o que era necessário. Não existe distinção de front, back ou qualquer coisa outra aqui. Se precisa existir para entregar o requisito, precisa estar perto uma da outra. Agora qual o limite e granularidade da tarefa? Eu gosto de tarefas que de fato me fazem perceber que dei um passo a frente em relação a materializar o requisito. Sobre a descrição, vai no nível que você entender que te permite olhar para a tarefa e seguir em frente. Perceba que as tarefas vem depois de um refinamento intenso do requisito. Alguns exemplo: Preciso construir um primeiro exemplo consumindo a api do meta ads para entender o passo para importar os dados de uma campanha. Agora preciso fazer o mesmo para pegar os conjuntos e por aí vai. Implementar um serviço interno que faça o meio campo com a api do meta ads. Implementar a tela onde a pessoa vai fazer login e passar os dados necessários para importar a campanha e por aí vai. Para cada tarefa dessa, eu gosto de listar os passos que considero necessários para implementar. E aí faço isso antes de codar.. Claro que se for algo que eu já fiz trocentas vezes, vou e mando ver no código direto :). Espero ter apoiado :).
Oi Breno, um requisito nasce lá na visão de quem é cliente do produto. Antes desta etapa que trago aqui, que está mais voltada para cuidar do processo de materializar tal desejo em uma correção/evolução/nova-feature. Pensando nessa fase inicial, temos todo este processo de descoberta para entender o valor de tal coisa. Muitas vezes isso acontece sem a participaçao efetiva do time de dev (acho legal ter sempre gente da equipe fazendo isso, mas nem sempre acontece). Uma vez que este requisito de fato aparece, agora ele precisa ser trabalhado para virar algo no sistema de verdade... E aí entra tudo isso que eu trouxe aqui. A validação acontece em cada etapa do fluxo descrito no passo a passo. Descreveu o requisito de maneira detalhada? Valida com quem pediu. Juntou com mais gente e fez um rascunho do fluxo de como vai ficar? Valida com quem pediu. Descreveu uns cenários de teste de aceitação? Valida com quem pediu. A ideia é iterar bastante para codar maximizando muito a chance de entregar o que é certo.
Estas entrevistas nao seria responsabilidade do PO ? Ter que juntar estas pessoas para conversar sobre proximas tarefas no meio da sprint nao tira o tempo do dev de ta fazendo a sprint atual ?
Eu desenvolvi estes passos pensando na vida de quem é dev e assumindo que o requisito já foi trabalhado inicialmente por outra pessoa. A ideia aqui é você maximizar a chance de realmente entender direito o que precisa ser feito, validar/validar/validar e aí codar o que de fato precisa ser entregue. Meu chute é que vai te devolver tempo :).
O Everton mencionou anteriormente a função do Product Owner (PO). Com meus sete anos de experiência em desenvolvimento, sempre vi as Histórias de Usuário (HIS) chegarem de maneira estruturada, como casos de uso ou como backlog da sprint. Este ano, no entanto, foi a primeira vez que vivenciei o processo inverso. Durante as reuniões de planning, eram os desenvolvedores que deveriam trazer as HIS para o backlog, mas as histórias que chegavam de Produto algumas completamente erradas. Por exemplo, recebíamos uma solicitação para construir um carro e, durante o refinamento, descobríamos que os requisitos eram totalmente diferentes, como, por exemplo, construir uma van. Foi uma verdadeira bagunça.
Maravilha !! Interessante !! 😮😊
:)
Muito bom, poderia explorar os dois últimos pontos, Histórias/Tarefas e Lista passo a passo, pois geralmente deixam para desenvolvedor, com tempo de 30 min para gerar todos os cards para as 2 semanas
Opa, posso sim.
Vou dar um exemplo que acabei de passar. Eu e um amigo estamos fazendo um projeto para facilitar a vida de pessoas infoprodutoras e uma das funcionalidades é analisar desempenho de campanhas no meta ads.
Então, resumidamente, o requisito do ponto de vista de sistema ficou algo como: Preciso ser capaz de analisar os dados de uma campanha dentro de um intervalo de tempo. Poderia ter saído dos ou mais requisitos de sistema. Não existe granularidade certa, pelo menos na minha opinião.
O que eu precisei fazer foi pegar esse requisito e dividir em tarefas que quando completadas me permitissem entregar o que era necessário. Não existe distinção de front, back ou qualquer coisa outra aqui. Se precisa existir para entregar o requisito, precisa estar perto uma da outra. Agora qual o limite e granularidade da tarefa? Eu gosto de tarefas que de fato me fazem perceber que dei um passo a frente em relação a materializar o requisito. Sobre a descrição, vai no nível que você entender que te permite olhar para a tarefa e seguir em frente. Perceba que as tarefas vem depois de um refinamento intenso do requisito.
Alguns exemplo:
Preciso construir um primeiro exemplo consumindo a api do meta ads para entender o passo para importar os dados de uma campanha. Agora preciso fazer o mesmo para pegar os conjuntos e por aí vai.
Implementar um serviço interno que faça o meio campo com a api do meta ads.
Implementar a tela onde a pessoa vai fazer login e passar os dados necessários para importar a campanha e por aí vai.
Para cada tarefa dessa, eu gosto de listar os passos que considero necessários para implementar. E aí faço isso antes de codar.. Claro que se for algo que eu já fiz trocentas vezes, vou e mando ver no código direto :).
Espero ter apoiado :).
Muito legal, mas antes dessa escrita como a gente valida o entendimento do requisito, para aque a construção seja de fato efetiva? Gostei do vídeo.
Oi Breno, um requisito nasce lá na visão de quem é cliente do produto. Antes desta etapa que trago aqui, que está mais voltada para cuidar do processo de materializar tal desejo em uma correção/evolução/nova-feature.
Pensando nessa fase inicial, temos todo este processo de descoberta para entender o valor de tal coisa. Muitas vezes isso acontece sem a participaçao efetiva do time de dev (acho legal ter sempre gente da equipe fazendo isso, mas nem sempre acontece).
Uma vez que este requisito de fato aparece, agora ele precisa ser trabalhado para virar algo no sistema de verdade... E aí entra tudo isso que eu trouxe aqui. A validação acontece em cada etapa do fluxo descrito no passo a passo.
Descreveu o requisito de maneira detalhada? Valida com quem pediu.
Juntou com mais gente e fez um rascunho do fluxo de como vai ficar? Valida com quem pediu.
Descreveu uns cenários de teste de aceitação? Valida com quem pediu.
A ideia é iterar bastante para codar maximizando muito a chance de entregar o que é certo.
Estas entrevistas nao seria responsabilidade do PO ? Ter que juntar estas pessoas para conversar sobre proximas tarefas no meio da sprint nao tira o tempo do dev de ta fazendo a sprint atual ?
Eu desenvolvi estes passos pensando na vida de quem é dev e assumindo que o requisito já foi trabalhado inicialmente por outra pessoa. A ideia aqui é você maximizar a chance de realmente entender direito o que precisa ser feito, validar/validar/validar e aí codar o que de fato precisa ser entregue.
Meu chute é que vai te devolver tempo :).