ola, isso mesmo a palavra final é dele Show
Boa tarde Hugo! Em princípio a afirmação realmente parece forte, mas é isso mesmo. O Scrum Guide é categórico ao afirmar que o PO (Product Owner) é a única pessoa responsável por gerenciar o Backlog do Produto, e cita que esse gerenciamento inclui as seguintes atividades:
É que do meu ponto de vista, ser responsável e ser o único que pode alterar o backlog são coisas distintas. Eu acredito que pela filosofia da metodologia, qualquer um do time Scrum poderia alterar, mas o Product Owner teria que revisar todas, aprovando, rejeitando ou solicitando retificações, não? solução! Hugo você tem razão! De fato ser o responsável e ser o único que pode alterar o Backlog do Produto são coisas distintas. Até porque como visto acima, o Dono do Produto pode delegar esta atividade ao Time de Desenvolvimento e mesmo assim continua a ser o responsável por ela. Contudo, quando você menciona que acredita que "qualquer um do Time Scrum poder alterar e depois o Dono do Produto vai revisar..." eu entendo que essas alterações (não só do Time mas também dos demais Stakeholders) são levadas ao Dono do Produto para que sejam adicionadas ao Backlog do Produto. Aqui já há uma necessidade de persuasão do Dono do Produto Scrum Guide: "Para que o Product Owner tenha sucesso, toda a organização deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto." O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que o Produto deve ter e é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia (em geral, quem mais entende de tecnologia é o Time) podem causar mudanças no Backlog do Produto. Em que pese haver uma ordenação prévia dos requisitos pelo Dono do Produto (pode contar com a ajuda do Scrum Master), ela não é impositiva. O Dono do Produto não impõe nada ao Time de Desenvolvimento, ele negocia com o Time de Desenvolvimento defendendo a visão do cliente. (Eu sei que você não entrou nesse mérito, mas essa explicação é necessária para entender-mos que existem etapas de refinamento do Backlog do Produto). Essas novas características são então submetidas a uma priorização pelo próprio Time Scrum no Planejamento da Sprint (por exemplo pelo método MoSCoW) se for a 1ª Sprint do Projeto, ou através de grooming se for nas demais Sprints do Projeto. Assim, as características que geram mais valor para o cliente provavelmente receberão a classificação Must Have (Deve ter), já as características que não geram nenhum valor receberão a classificação Won't Have (Não deve ter), pulei propositalmente Should e Could Have. Aqui ocorre outra validação, desta vez por todo o Time Scrum Cabe ressaltar que dentre os valores propagados pelo Scrum Guide consta a coragem para o Time Scrum fazer a coisa certa e trabalhar em problemas difíceis. E o respeito: "Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes." Como se vê, no Scrum todo o time deve se respeitar e isso inclui desenvolver a capacidade de negociação e empatia com os colegas. Assim, apesar de ser o responsável pelo Backlog do Produto se o Dono do Produto for inflexível demasiadamente descartando arbitrariamente os inputs fornecidos pelo Time provavelmente não obterá sucesso com o projeto. Daí, nota-se também, a importância de uma boa escolha do Dono do Produto para um determinado Projeto. Veja também: https://cursos.alura.com.br/course/scrum-parte-4/task/22414 Bons estudos! :D
Ao final de cada Sprint, uma Revisão da Sprint é realizada. Durante esta reunião, o Time de Desenvolvimento apresenta o que foi realizado durante a Sprint. Tipicamente, esta apresentação é feita na forma de uma demonstração das novas funcionalidades. O projeto é avaliado baseado na Meta da Sprint, determinado durante a Reunião de Planejamento da Sprint. O ideal é que a equipe tenha concluído todos os itens do Backlog do Produto alocados para a Sprint, mas é mais importante que eles alcancem a Meta da Sprint. Participantes da Revisão da Sprint, tipicamente inclui o Product Owner, o Time de Desenvolvimento, o Scrum Master e outros que se fizerem necessários, cujo feedback é considerado importante. O propósito da reunião da Revisão da Sprint não é o de se obter a aprovação formal dos clientes sobre o que foi feito na Sprint, ou seja, polegar para cima ou carimbo de “aceito” no contrato. Não é uma sessão de testes de aceitação, tampouco. A aprovação para se concretizar uma entrega deve ser feita em outro momento, fora do contexto do Scrum. O objetivo da reunião da Revisão da Sprint é de se obter feedback do cliente sobre o Incremento do Produto gerado na Sprint e, com isso, poder frequentemente fazer ajustes de direção, diminuindo os riscos do projeto. É trabalho — e obrigação — do Time de Desenvolvimento e do Product Owner puxarem esse feedback dos clientes e demais partes interessadas presentes. Convidá-los a usarem o produto ali mesmo. Instigar. Fazer perguntas. Mostrar alternativas. O Product Owner utilizará o feedback obtido nessa reunião como matéria-prima para modificar o Backlog do Produto para Sprints futuras. É, portanto, uma reunião de inspeção e adaptação do produto. Algum cliente achou que algo não estava exatamente como ele queria? Excelente! Deixemos a postura defensiva de lado. Não tenhamos medo. Nós não fizemos errado. Não estragamos tudo. Na realidade, já esperávamos por isso. Faremos de tudo para acertar, claro, mas não é possível ler a mente de ninguém. E, mesmo que fosse, isso de nada adiantaria, pois o cliente só saberá exatamente o que ele precisa após ver algo pronto. O produto, na cabeça do cliente, é construído aos poucos, incrementalmente. Mesmo quando der tudo errado e clientes entenderem que tudo o que foi feito na Sprint não serve para nada, pelo menos obteremos esse feedback antes de gastarmos meses trabalhando naquilo. Gestão de riscos pura, não? Ou seja, o espírito da Revisão da Sprint não é:
Mas talvez algo assim:
Uma vez que o foco da apresentação é colocado na Meta realizada, o Incremento do Produto pode ser demonstrado como um todo. Alternativamente, muitos times apresentam e demonstram os itens desenvolvidos durante a Sprint um a um, do mais importante ao menos importante. Clientes e demais presentes trabalham colaborativamente com o Time de Desenvolvimento e com o Product Owner, fazendo perguntas e obtendo respostas sobre o que lhes está sendo demonstrado, e apresentando suas ideias sobre o que esperam do produto nas próximas Sprints. É uma excelente prática convidar os presentes a experimentarem diretamente o produto. Isso os estimulará a fornecerem feedback e permitirá que este seja mais profundo e preciso. No entanto, a Reunião de Revisão não é uma reunião para testes do produto e, assim, não deve ser utilizada para substituir práticas de testes que devam ser realizadas ao longo da Sprint. É igualmente interessante perguntar aos presentes o que esperam ver pronto nas próximas reuniões de Revisão da Sprint. Ou seja, estimulá-los a elaborar sobre quais são as próximas necessidades de negócios mais importantes a serem atendidas. A partir do que foi e do que não foi gerado na Sprint, o Product Owner e o Time de Desenvolvimento esperam que se tenha realizado a Meta da Sprint. Ou seja, que o problema proposto para a Sprint tenha sido resolvido. É importante observar que, para realizar essa Meta, o Time de Desenvolvimento não necessariamente deverá ter completado todos os itens planejados. Salvo tenha havido algum impedimento prevenindo um item importante de ser desenvolvido, geralmente os itens não prontos ao final da Sprint são os de mais baixa importância para se realizar a Meta da Sprint. O feedback obtido a partir da interação entre Time de Desenvolvimento, Product Owner e demais presentes na reunião de Revisão da Sprint é usado pelo Product Owner como matéria-prima para adicionar, remover ou modificar itens do Backlog do Produto. É dessa forma que o produto é construído incrementalmente para melhor atender às necessidades dos seus clientes. Caso haja, na reunião de Revisão da Sprint, itens da Sprint não prontos de acordo com a Definição de Pronto, eles podem retornar ao Backlog do Produto e reaparecerem no próximo ou em alguma das próximas Sprint. Pode-se também decidir que sejam eliminados, se assim fizer sentido a partir do feedback obtido ou de outras questões de negócio. É papel do Product Owner, e apenas dele, decidir o destino desses itens. A reunião de Revisão da Sprint intencionalmente se mantém informal, normalmente com regras proibindo o uso de apresentações em Power Point e não permitindo ultrapassar o timebox de realização da mesma. O Incremento do Produto funcionando, ou seja, o valor gerado para os clientes do projeto, é o foco da demonstração. Da mesma forma, questões técnicas somente serão discutidas se forem de interesse das pessoas presentes. Caso contrário, há o risco de que considerem a reunião uma perda de tempo, o que dificultará o seu comparecimento nas próximas. Apresentam-se apenas os itens do Backlog da Sprint que estejam prontos, de acordo com a Definição de Pronto. Quanto tempo o time de desenvolvimento deve alocar para manter o Backlog do produto?Uma grande parte desse trabalho se concentrano que chamamos de refinamento do Product Backlog, estimativa de tamanho e priorização dos itens. A equipe de desenvolvimento deve alocar até 10% do seu tempo em cada sprint para ajudar o Product Owner com essas atividades.
Qual é o tempo máximo que o Scrum recomenda que um time?1) Reunião de Planejamento da Sprint
Todos os integrantes do Time Scrum participam desta reunião, sendo que o time-box máximo é de 8 horas de duração. Em Sprints menores, a duração tende a ser proporcionalmente menor.
Qual a duração máxima do refinamento do Product Backlog Backlog do produto )?Quanto Tempo Deve Levar o Refinamento do Backlog? O Guia do Scrum não diz nada sobre quanto tempo o Refinamento do Backlog deve levar. Ele apenas especifica que normalmente não leva mais de 10% da capacidade da Equipe de Desenvolvimento.
Qual é o tempo máximo que o Scrum recomenda que um time gaste em uma reunião diária de Scrum?Daily Scrum é, basicamente, uma reunião diária, que deve durar até 15 minutos. Essa conversa visa entender o que já foi feito, o que precisa ser colocado em prática naquele dia e também identificar gargalos que estejam impossibilitando o andamento dos processos.
|
Quanto tempo o time Scrum deve alocar para manter o Backlog do produto Scrum?
Postagens relacionadas
direito autoral © 2024 pt.wiewird Inc.
