A aceitação no meio do sprint é um conceito válido no Agile/SCRUM?[fechado]

Question

Fechado.Esta pergunta é baseado em opinião.No momento não está aceitando respostas.

---

Quer melhorar esta questão? Atualize a pergunta para que ela possa ser respondida com fatos e citações por editando esta postagem.

Fechado 2 anos atrás.

Faço parte de uma equipe Agile Scrum trabalhando no lançamento de um produto de software.A duração do sprint é de 2 semanas (~10 dias).

Há uma métrica peculiar usada aqui, chamada 'aceitação no meio do sprint'.Essencialmente, a expectativa é que metade dos pontos da história do usuário comprometidos e planejados por uma equipe scrum em um sprint precisem ser concluídos no meio desse sprint.Isso, dizem eles, resulta em uma queima linear de pontos, o que é um forte indicador de que o sprint está indo bem.

Como equipe, nossas aceitações no meio do sprint geralmente são ruins, mas sabemos que concluímos todos os pontos comprometidos da história do usuário até o final do sprint.

Tenho as seguintes perguntas:

1) A aceitação no meio do sprint é uma prática Agile/SCRUM válida?Está sendo usado em algum outro lugar?

2) Esperar que metade do trabalho seja concluído em metade do tempo é o mesmo que tratá-lo como um trabalho de “chão de fábrica”, onde a natureza e a complexidade do trabalho em questão são completamente determinísticas.Como o desenvolvimento de software é um processo “criativo”, tais métricas rígidas em uma metodologia altamente flexível como o Agile são irrelevantes.O que você acha?

3) Embora minha equipe scrum cumpra todos os nossos compromissos bem a tempo para o sprint, estamos sendo questionados por nossas más métricas de aceitação no meio do sprint.É completamente normal que equipes Scrum em todos os outros lugares cumpram seus compromissos apenas no final dos sprints?

Muito obrigado antecipadamente.

Answer 1

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

Eu nunca ouvi falar de aceitação no meio do sprint antes.Não acredito que seja uma prática Agile/Scrum válida. Esse site pareceria concordar "Uma vez que a equipe se compromete com o trabalho, o Product Owner não pode adicionar mais trabalho, alterar o curso no meio do sprint ou microgerenciar."

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

Quaisquer métricas rígidas geralmente não são uma boa ideia para uso com desenvolvedores pelos motivos mencionados.Também é provável que os desenvolvedores estejam mais interessados ​​em obter uma nota de aprovação em tudo o que está sendo medido e não em produzir um produto de qualidade.Este é um dos ursos insetos de Joel Spolsky - aqui, aqui e aqui

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

Uma equipe Scrum bem-sucedida deve concluir tudo o que se comprometeu a fazer até o final do sprint.O gráfico de burndown deve estar visível para orientar o progresso em direção a esse objetivo e certamente na segunda metade do sprint indicará se o sprint tem probabilidade de ser um sucesso.Em sprints bem-sucedidos com os quais estive envolvido, é normal fazer um progresso constante na conclusão das histórias de usuários, mas isso não pode ser refletido na conclusão de metade das histórias de usuários na metade do tempo e eu desaconselharia uma métrica desse tipo.

Answer 2

Você já tentou limitar a quantidade de trabalho que você tem em andamento.Se você conseguir toda a equipe para se concentrar em algumas histórias e não seguir em frente até que essas histórias terminem, você deve ver seu burecimento tornar-se muito mais linear.

Também pode valer a pena olhar para o tamanho das histórias.Eu pessoalmente não gosto de ver uma história que demora mais do que alguns dias para completar o início para terminar.

Answer 3

Não é uma prática de scrum.Pode ser interpretado como uma métrica, mas é ruim.Em relação às suas dúvidas, você está certo.

Scrum tem uma ferramenta perfeita para seguir a progressão - o gráfico de queimaduras.Não há necessidade de adicionar qualquer marco arbitrário.

Parece que sua administração não entende o conceito básico de um sprint, eles devem obter algum aconselhamento ou seguir um treinamento básico.Se é ainda importante para o seu gerenciamento O que é feito dentro de uma semana, tente sugerir cortar o comprimento do sprint em metade.

Answer 4

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

É sim.

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

Se você dividir as tarefas em tarefas bem pequenas, poderá obter uma boa métrica de evolução do trabalho.Portanto, as tarefas de design devem ser concluídas em um dia de trabalho e você poderá obter um bom uso da métrica de burndown.Se você tiver tarefas longas e imprevisíveis, a métrica de burndown é irrelevante, como você disse.

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

O problema não é a equipe, mas o desenho das tarefas.A questão diz respeito à granularidade da tarefa.Sua equipe pode realizar o trabalho na métrica de tempo do sprint, mas agora você precisa refinar as tarefas para que 50% delas sejam concluídas na métrica de tempo intermediário do sprint.Divida as tarefas em tarefas menores e você poderá obter o gráfico de burndown (linear) desejado.

Answer 5

É terminologia não padrão, mas há algo para o que seu gerente está dizendo.

Um gráfico de queimado que é pesado final (isto é, permanece alto para uma grande parte do gráfico, depois caudas de repente no final) é indicativo de uma prática onde as tarefas são grosseiras - isto é, um A tarefa provavelmente tomará um sprint inteiro para completar - e realizado por desenvolvedores individuais. Com este padrão, todas as tarefas permanecem incompletas até antes do final do sprint.

Isso não é da maneira que é suposto funcionar: se o backlog estiver em ordem prioritária, por que questões que não têm a maior prioridade que está sendo trabalhada? Além disso, isso define o "número do barramento" para cada tarefa muito baixa, o que pode aumentar significativamente o risco de tarefas permanecendo incompleto até o final do sprint.

Para corrigir isso, as tarefas devem ser divididas em pedaços muito menores. Se você estiver fazendo o Planing Poker, e uma tarefa é estimada em 8 pontos ou mais, é provável que a tarefa seja sublevada. Deve ser quebrado. Tente e mantenha-o para 2s e 3s (ou menor!) Se possível. Desta forma, você pode ter vários desenvolvedores trabalhando de forma independente no mesmo objetivo geral, e seu gráfico de queima deve começar a parecer mais suave, e menos arriscado, mesmo que o mesmo trabalho esteja sendo feito.

Answer 6

meados de aceitação de sprint não é uma prática ágil ou não funciona na realidade.Se você tiver uma estimativa correta para cada história e tarefa de usuário (e.g in Rally), então o gráfico de burndown mostra claramente se o funcionamento da Sprint está em alinhamento com o plano e pode ser concluído a tempo ou não.A aceitação é feita apenas no final do desenvolvimento e teste da história do usuário não tarefas.