Quando uma iteração ágil é considerada completa? [fechado

Question

Estou trabalhando em uma equipe que está explorando a possibilidade de adotar práticas de desenvolvimento ágil.

Uma pergunta que estamos enfrentando é decidir quando uma iteração (sprint) deve concluir.

Digamos que definimos nosso backlog de recursos e produzimos estimativas de ponto de história para eles, e decidimos que o primeiro sprint de 30 dias incluirá os recursos A, B, D e F. O que você deve fazer se em você ' chegando ao final do sprint e você concluiu A, D e F - mas B está apenas 80% completo. Você deveria:

1. Complete o sprint a tempo, mas exclua o recurso B (adiando o trabalho restante para um sprint futuro)

2. Estenda o sprint pelo tempo necessário para concluir o recurso B, mas não inicie o próximo sprint.

3. Estenda o sprint pelo tempo necessário para concluir o recurso B e começar a trabalhar no próximo sprint.

4. Falha todo o sprint e agrupa todo o trabalho para fazer parte de um lançamento futuro.

O problema que vejo com a opção 1 é que a equipe não está entregando o que se comprometeu. Em alguns casos, você pode não ser capaz de excluir o recurso B sem tornar o lançamento inteiro inútil (ou pelo menos substancialmente menos valioso). Pode dificultar o orçamento da direção do próximo sprint sem o recurso B.

O problema com a opção 2 é que alguns membros da equipe podem estar ociosos por um período significativo de tempo - que consome a produtividade geral. Você poderá adicionar mais testes de unidade ou recursos de polimento, mas ele não agrega valor proporcional. Também é politicamente difícil explicar à gerência por que a maioria da sua equipe está ociosa.

A opção 3 parece ser contra o espírito do Agile - você está colocando o próximo sprint em risco, não permitindo que os resultados do anterior guiassem a próxima iteração do desenvolvimento.

A opção 4 parece severa e tem a maioria dos mesmos problemas das opções 1 e 3. Primeiro, você está perdendo completamente um compromisso. Segundo, a agrupamento de mais recursos em uma versão subsequente torna mais difícil testar e verificar com os clientes - e novamente impede a capacidade de orientar a iteração futura com base no feedback dos anteriores.

Answer 1

Opção 1, é claro. Sua velocidade para a próxima iteração será menor, pois é baseada em Ontem clima, então a próxima iteração você tem uma chance melhor de estar completo.

Em scrum você é Time-boxing. E você só fornece recursos que funcionam.

No Planejamento de sprint Você fez uma estimativa do que poderia entregar. O cliente precisa aceitar um certo nível de incerteza na estimativa ou estar preparado para ter muitos recursos na equipe.

Se você perder a próxima iteração novamente, mude para um comprimento de iteração mais curto e verifique se o tamanho dos recursos individuais é menor.

Answer 2

Você normalmente faria a opção 1 - terminar o sprint. Use o trabalho concluído, deixe o trabalho inacabado refletir na velocidade do projeto - para que o planejamento futuro leva em consideração as dificuldades que você experimentou.

Sim, a opção 1 significa que não terminamos o que nos comprometemos - mas se foi o que aconteceu, é melhor admitir e aprender a lidar melhor na próxima vez do que escondê -lo. Coisas ruins acontecem com todo mundo - o crítico é como melhoramos de onde estamos.

Você pode fazer a opção 2 - continue terminando o excelente trabalho, estendendo o sprint. Faça isso apenas se o trabalho for uma prioridade super alta para o cliente e eles optarem explicitamente. Estender o comprimento dos sprints torna mais difíceis de se comparar - porque são comprimentos diferentes.

Absolutamente nunca nunca deixe um sprint se fundir para o próximo - Ou você está estendendo o velho sprint, ou está iniciando um completamente novo. Se você deixar dois sprints se fundirem um para o outro, você não está mais fazendo sprints e planejando quebrar ...

Answer 3

Posso responder com "depende"? Além disso, eu gostaria de jogar um "Definir completo".

Tivemos essa situação algumas vezes e lidamos com isso de maneira diferente, dependendo das circunstâncias.

Tanto quanto me lembro em dois casos, deixamos o sprint falhar. Na verdade, era mais um tipo de falha rejeitado pela demonstração. As características em si foram consideradas completas pela equipe, mas havia muitas perguntas em aberto, pontas soltas e pequenos detalhes que surgiram durante a demonstração. Levaria alguns dias para encerrar tudo, então deixamos o sprint falhar e levamos todos os itens abertos para o próximo sprint. Ainda tínhamos um planejamento retrospectivo e de sprint para novas histórias de usuários, mas não havia integração de linhas de código e o sprint foi oficialmente marcado como falhado.

Em outro caso, tivemos apenas alguns bugs que apareceram no último minuto, além de algumas coisas da história do usuário. Estimamos o trabalho total para três dias e apenas estendemos o sprint. Isso foi suficiente para consertar o bug, fazer algumas mudanças e fazer uma segunda demonstração de sprint cerca de três dias depois.

Então, era a opção 4 ou a opção 2 para nós quando foi solicitado.

Há algumas coisas a considerar aqui. Primeiro de tudo, (e estou falando de terminologia do Scrum aqui, porque estou acostumado, então fique à vontade para substituí -lo por tudo o que se encaixa melhor) Reúna o Scrummaster, o proprietário do produto e a equipe e discutir as opções abertamente. Eu não acho que há um caminho a percorrer. Você pode manter a metodologia pura, mas na vida real nem sempre é o melhor caminho a percorrer. Às vezes, dobrar um pouco as regras ajuda muito e facilita a vida para todos.

Se você estiver trabalhando bem juntos, encontrará uma opção que funcione para todos os envolvidos. (Se você não puder, pode ter problemas subjacentes de qualquer maneira.) Não solte algo na equipe sem pelo menos discuti -lo ou pelo menos explicar os motivos.

A opção 3 parece a mais confusa para mim, então eu descartaria isso.

Muitas pessoas aqui argumentaram que a opção 2 vai contra as regras básicas do ágil (ou scrum), mas eu discordaria. O Scrum diz explicitamente que você pode estender o sprint, se necessário, o mesmo que pode reduzir histórias ou adicionar recursos. Você não deve fazer isso até absolutamente necessário, mas até onde eu sei, não é estritamente contra o livro. Na base, quando o fizemos, foi a melhor solução para todos, porque ainda fizemos o sprint, apenas três dias depois e todos ficaram muito felizes com os resultados. Se estivéssemos conversando uma semana ou mais a opção 2 não teria sido apropriado.

Eu realmente não gosto da opção 1. Tomar coisas meia-municipal de uma implementação em funcionamento pode ser realmente confuso. Você perde o contato com o código que foi feito e a integração, francamente, pode ser uma dor. Pode ser diferente, dependendo da maneira como você trabalha, mas da minha experiência, tirar o código de uma linha de código não é algo que você deseja fazer.

Quanto à opção 4, é bastante duro, mas, novamente, quando comunicado corretamente, deve ficar bem. A equipe geralmente sabe quando estragou tudo e não será capaz de entregar, por isso não é como se você estivesse dando notícias para eles.

Então, há algumas coisas a considerar.

• Quanto tempo ele precisará fazer isso? Se for apenas um ou dois dias, estender seu sprint pode ser a melhor opção.
• Quanto esforço será remover o código que já está lá? Se estiver confuso e leva tempo, resolva a opção 2 ou 4. Se for fácil, talvez a opção 1 seja o caminho a percorrer.
• O que a equipe pensa? O que o proprietário do produto pensa? O que os outros pensam? Falhar em uma primavera pode ter um impacto no moral da equipe, mas pode não.

Answer 4

Para um projeto ágil, é importante ter uma 'definição de fazer'. Esta é uma pequena lista de verificação de coisas que precisam ser feitas para classificar algo como completo. Não é incomum ter diferentes níveis de feito:

• História do usuário - Isso pode incluir coisas como todas as tarefas associadas aos EUA devem estar concluídas, todo o código é verificado e aumentando com sucesso com os testes de unidade passantes, o teste de aceitação foi concluído.

• Sprint - Isso pode incluir coisas como todas as histórias para o sprint são 'feitas' (veja acima, uma retrospectiva foi realizada, o proprietário do produto viu uma demonstração da funcionalidade etc. etc.

• Sprint de liberação - O desenvolvimento da série anterior de sprints foi integrado com sucesso e a regressão testada, a funcionalidade foi lançada no ambiente ao vivo.

Em termos das 4 opções, é menos claro. Muito é dito e foi escrito sobre o que deve e não deve ser feito em torno da falha no sprint, estendendo o sprint e excluindo um recurso ou outro. Acho que, com projetos ágeis, é necessário muito pragmatismo, especialmente nos primeiros sprints.

O importante é não ser pendurado. Apenas aprenda com ele, adapte e siga em frente.

Answer 5

Eu adotaria uma variação da opção 1. Se o recurso B puder ser dividido no que é concluído e o que não estiver concluído, isso deve levar a um conjunto de tarefas revisado para concluí -lo para o próximo sprint. O que está concluído é entregue e, embora a entrega não seja perfeita, a idéia deve ser tentar o melhor de alguém e depois trabalhar no que está a seguir, de acordo com a prioridade.

Estender o sprint é uma receita para o desastre em minha mente. A conclusão do recurso significa resolver todos os bugs também? Já viu software que tinha zero bugs?

Falha no sprint introduz muito perfeccionismo nas coisas. Algo que é feito 99% sem valor? Eu não pensaria assim, mas há algumas pessoas que têm padrões realmente altos e podem ser bastante exigentes.

Editar: Às vezes, é fornecido um recurso inicialmente com requisitos vagos que são esclarecidos ao longo do sprint. Por exemplo, uma solicitação de recurso de "Como usuário, eu gostaria de fazer um pedido", pode ser dividido ainda mais como parte do planejamento do sprint ou durante o sprint. Em ambos os casos, se algumas histórias envolvendo um recurso forem concluídas, elas podem e devem ser apresentadas na demonstração, se for feito. O objetivo é poder dizer: "É aqui que estamos. Quão prioritária existe em terminar isso?" Como o que poderia ter sido urgente antes, pode não ser assim no final do sprint.

Answer 6

Primeiro, a regra: as iterações são caixas de tempo fixo e estão completas no final da caixa de tempo. Portanto, isso elimina a opção 2 e a opção 3. Em relação à opção 4, a rescisão anormal da iteração pode ocorrer em circunstâncias muito particulares (certeza de que a meta não pode ser alcançada, o evento externo invalida a meta, ...), mas esse deve permanecer um evento excepcional. E antes de abortar, existem em geral outras opções: 1. Faça outra coisa / Inovente 2. Obtenha ajuda / terceirização 3. Reduza o escopo. E isso deixa você com a opção 1, a escolha óbvia.

O problema que vejo com a opção 1 é que a equipe não está entregando o que se comprometeu. Em alguns casos, você pode não ser capaz de excluir o recurso B sem tornar o lançamento inteiro inútil (ou pelo menos substancialmente menos valioso). Pode dificultar o orçamento da direção do próximo sprint sem o recurso B.

Se isso for verdade, então B foi mais importante que a, d e f e você não funcionou nos itens mais importantes primeiro, o que está errado, não deve acontecer ou ... a, d e f são realmente muito Valioso nesse caso, sua suposição não é verdadeira e adiar B não é um grande problema. Portanto, faça -o assim que você perceber que não será feito e veja se você pode substituí -lo por um item menor.