Como é que um Scrum Master “gerir” um fora de controle Product Owner? [fechadas]

Question

I novo para Scrum e enquanto eu entender o conceito de equipe por trás dos Sprints, imagino que ainda precisa para ser um guardião para a equipe que minimiza a interferência de produtos proprietários que não estão familiarizados com o desenvolvimento de software. Quais são os seus sucessos, e que histórias de horror você tem vivido?

Update:

Eu estou procurando o equilíbrio entre a codificação para implementar processos de negócios vs criando a arquitetura apropriada para um cliente. Se o proprietário do produto é a partir da unidade de negócios tem de haver orientação sobre o que quantidade de tempo deve ser gasto em modelo de dados, etc.

Definição:

Por "fora de controle" proprietário do produto Quero dizer normalmente alguém da unidade de negócio que define de forma agressiva prazos embora não tenha capacidade técnica real para criar essa estimativa. Normalmente esta pessoa vai dizer: ". Eu preciso dessas telas antes da próxima reunião com o Comitê Operacional próxima semana, então priorizar os produtos de trabalho Primeiro vamos abordar o banco de dados depois que falar com Operações"

Great responde a todos. Obrigado pela boa entrada.

Answer 1

"tem de haver orientação sobre o que quantidade de tempo deve ser gasto em modelo de dados, etc."

Right. Isso é o que a priorização é tudo. Você define o trabalho, você priorizar. Você trabalha de acordo com as prioridades.

O que pode sair do controle?

1. redefinindo o trabalho antes de qualquer coisa é feito?

2. redefinindo as prioridades antes do trabalho é feito?

A solução é a mesma. Quebrar o trabalho em pedaços menores para algo seja feito antes que haja uma oportunidade de fazer uma mudança.

Se você tem sprints de curta duração (2 semanas), não é possível estar fora de controle. Se você vai para um pouco mais práticos sprints de 4 semanas, então você tem uma pequena chance de se meter em encrencas.

Answer 2

As responsabilidades estão claramente definidas no Scrum -. O Product Owner define itens do backlog e prioriza-los, os desenvolvedores cometem em quanto eles podem fazer em um Sprint

Assim, um Product Owner simplesmente não tem autoridade em tudo com estimativas definidos. É claro que ele ainda pode dizer que ele precisa de algo para um ponto específico no tempo - que simplesmente acontece. Mas ainda é os desenvolvedores que vão dizer se é pode ser feito. E se não puder, eles têm que trabalhar juntos sobre como alterar o âmbito ou qualquer outra coisa que pode ser feito para obter as necessidades do PO cumprido da melhor forma possível.

Agora, exatamente como o SM deve agir em uma situação onde isso não funciona sem problemas depende muito da situação específica. Eu prefiro vê-lo facilitar um relacionamento bom e cultura de comunicação entre o PO e da equipe do que tê-lo escudo a equipe do PO, no entanto.

Answer 3

O proprietário do produto é suposto ser a única que protege você de requisitos do cliente ambíguas ou diferentes.

O proprietário do produto não deve dar as estimativas.

Answer 4

Eu não acho que é uma questão de "fora de controle".

"Eu preciso dessas telas antes da próxima reunião com o Comitê Operacional na próxima semana, então priorizar os trabalhos produtos de primeira. Vamos enfrentar o banco de dados depois falamos com Operações. "

Não há nada de intrinsecamente errado com essa afirmação por si só . Se seu aplicativo está devidamente captada, então o seu DB é de qualquer maneira separada. O principal problema com UI primeiro é mais psicológica: Os não-devs irá assumir que a maioria do trabalho é feito se vêem as telas e ir bonkers quando as coisas "slow down". No entanto, aqui está o que eu acho que o problema real pode ser:

A pessoa que você tem sinalizado como um Product Owner não é possuir o produto, e por isso não está a assumir a responsabilidade suficiente.

O produto é o toda coisa, não apenas os "requisitos funcionais" (a terminologia borrow). Suas necessidades SM para ter um assento para baixo e ser inflexível que as necessidades PO não tentar empurrar a compreensão do escopo do nos bastidores trabalho que precisa ser realizado. Quando estiver PO começa a olhar para todo o escopo, então eles podem realmente ser o seu representante para a comunidade mais ampla das partes interessadas.

Em última análise, o seu SM é o encarregado de processo de execução. Eles devem agir como tal.

Answer 5

Eu usei Agile em duas lojas diferentes, ambas as vezes ele funciona bem. Eu não vejo como um fora de controle qualquer coisa pode arruinar o sistema. Antes do sprint, você planejar todas as tarefas que você vai fazer e guesstimate quanto tempo eles vão demorar (até sempre e volta). Depois, você pode descobrir aproximadamente quanto trabalho pode ser feito durante o seu sprint.

A maioria das lojas usar 4 sprints semana, e 6.5hrs de tempo viável por dia. Quando um sprint foi definido, você não introduzir novas tarefas e trabalho única não planejado que se arrasta em um sprint é corrigir bugs no características que você está adicionando, é claro que é suposto ser incluído no seu tempo guesstimate.

Se você quer uma resposta mais específica, você precisa definir o que você quer dizer com um "fora de controle" proprietário do produto.

Answer 6

Eu tenho duas coisas a dizer.

Você provavelmente tem algum tipo de gerente de P & D (que não é necessariamente scrum master) e que não é um proprietário do produto).

Esse cara pode e deve (eu acho) "proteger" os desenvolvedores. Estávamos em situação quando tivemos um cara, e funcionou muito bem. Ele nos ajudou com a obtenção de material não-funcional no backlog por exemplo.

Agora, não temos esse cara. Nosso gerente é Scrum Master. E ele faz bom trabalho protegendo-nos bem. Embora ... o problema aqui é que Scrum Master genérico não tem poder oficial, então ele não pode dizer "você não está indo para pressioná-los muito presente", mas é claro que ele pode e deve falar se ele vê que teem precisa de ajuda.

A equipe de si e do produto proprietário também evoluir com o tempo para que eles começam a cuidar mais de si. proprietário do produto entende quando a equipe simplesmente não se comprometer com mais ou diz "precisamos de algum tempo para o material não-funcional agora".

Mas então - mais uma vez - é bom, claro, se há um gerente cuja responsabilidade principal é cuidar de desenvolvedores de R & D em separado ... então ele vai ser mais equilibrada eu acho ..

Nós também temos o departamento de apoio que empresta desenvolvedores para tarefas de apoio. Às vezes é difícil chegar a acordo o que vai ou não vai ser feito por este ou aquele cliente (porque o apoio quer tudo). Para este gerente D caso R & - uma idéia muito boa também ..

Idealmente, eu gosto da idéia de ir completamente inclinar-se para que os desenvolvedores não precisa de um gerente ou escudo ... mas eu não sei se e como ele funciona ...:)

Answer 7

Eu concordo com S. Lott. sprints curtos são melhores. histórias de usuários curtas podem ajudar a. Tentamos limitar as nossas histórias de usuários para 2 - 4 dias Máximo.

1. Certifique-se de que todo o seu usuário histórias são bem definidos e que o proprietário de acordo com eles.

2. Uma vez que um sprint começou, insistem que as novas tarefas não podem ser adicionados a o sprint atual, mas podem ser alta prioridade no próximo sprint. sprints curtos fazer isso muito mais mais fácil.

3. Além disso, a fim de remover o imposição de prazos artificiais, você realmente não deve entregar itens do sprint atual até que o início do próximo sprint quando possível.

A parte mais difícil de desenvolvimento ágil é a disciplina. Uma vez que você tem uma equipe disciplinada e Scrum Master, os usuários se acostumar com isso e as coisas se movem muito mais suave. Eu não tenho certeza se você usar qualquer software para gerenciamento de projetos, mas dê uma olhada Rally. Eles fizeram algumas melhorias importantes ao longo do ano passado ou assim.

Answer 8

A iteração (Sprint em Scrum) escopo não deve ser alterado durante a iteração. É por isso que apenas uma iteração é planejada de cada vez. Como S. Lott apontou, quanto menor a iteração, quanto mais cedo o Product Owner será capaz de fazer as coisas novas planejadas.

O papel Scrum Master é isolar a Equipe de tal pressão e disser ao Product Owner que novos pedidos ter que esperar para a próxima iteração.

Agora o papel Product Owner é maximizar o valor do trabalho que a equipe produz, por isso, se há um novo item de alta prioridade, que não podia esperar para o final da iteração atual, ainda é possível substituir itens com estimativa similar e que não foram iniciados . Esta deve ser a exceção, não a regra.

Answer 9

Vara com as regras claramente definidas de noivado, então você (SM) pode sim passar o tempo, levando sua equipe.

Answer 10

Uma ágil equipe é consiste no desenvolvedor, analista de negócios, Tester, DBA, Scrum master e proprietário do produto. Todos estão trabalhando como uma equipe com base recurso .

metodologia Agile está aqui para ajudar as empresas a acelerar o desenvolvimento mais rápido de produtos. O proprietário do produto pode definir a prioridade e alterar a prioridade dele. Na verdade, é uma equipe Scrum, que estimam que inclusive (SME, desenvolvedor, projetista, testador .... Todos) membro da equipe .Cada traz uma perspectiva diferente sobre o produto e o trabalho necessário para entregar uma história de usuário e um Sprint compreende com grande e história de usuário pequena. Se a equipe Scrum sente que não pode ser feito dentro de Sprint, em seguida, ele precisa ser uma divisão no pequeno pedaço da história de usuário e estimar baseado no rastreamento de pilha envolvidos para o desenvolveu.

i. Se Product Owner (PO) quer a necessidade história de usuário específico para terminar em primeiro lugar, mas se essa história incluiu as várias alterações (ou seja, frontend e backend incluindo banco de dados) e não pode completa em um sprint, equipe Scrum pode seguir abaixo regras fundamentais:

elementos-chave :

• Divide na história sub-usuário com base na pista pilha
• Estimativa cada história de usuário relacionadas a este
• Scrum Master deve Informou o Product Owner sobre a linha do tempo para terminar esta história de usuário com base em equipe a velocidade da equipe atual
• proprietário do produto deve ser maduro o suficiente para entender a linha do tempo, uma vez que não pode ser concluída dentro do sprint.

• Se ainda PO tem o problema de prioridade, ele / ela pode consultar o Scrum Master / camioneta.

  À primeira vista, Agile é mais para ajudar as empresas, mas precisam tomar cuidado para que ele não irá sobrecarregar a equipe scrum. Como se trata de um processo regular para desenvolvimento iterativo.