É uma prática ruim trabalhar em várias histórias simultaneamente? [fechado

Question

Em uma equipe Scrum, qual a importância de completar uma única história antes de seguir em frente?

Nosso Scrum Master é bastante dogmático em concluir uma única história antes de seguir em frente. Eu posso ver que o desenvolvimento parece ser mais "controlado" nesse cenário, além do Scrum Master teria uma imagem muito precisa do que os membros da equipe estavam trabalhando a qualquer momento ... mas estou interessado no que isso realmente compra nós?

Claramente, o mestre do scrum quer minimizar a divergência do queimaduras da realidade para evitar um choque no final do sprint - mas certamente se o sprint tiver duas semanas, o queimado é atualizado de forma consistente e os bloqueadores são comunicados em standups - qualquer dessas divergência irá Seja restringido pelo comprimento do sprint e seja tornado visível no meio dos canais habituais (ou seja, o stand-up ou falando com o mestre scrum individualmente). Quaisquer problemas restantes podem ser tratados na retrospectiva quinzenal.

A razão para a pergunta é que pareço que trabalho com mais eficiência, mantendo as histórias Say 2 (ou 3, se for particularmente fácil) em andamento a qualquer momento em que trabalho como considero adequado. Isso parece ajudar no pensamento subconsciente que auxilia na conclusão da tarefa. Também me permite entender melhor o quadro geral se algumas histórias estiverem relacionadas.

Nossas histórias geralmente trabalham para um ou dois dias de trabalho.

Então, o trabalho de algumas histórias de cada vez está desaprovado e, em caso afirmativo, o que o de um andar de um tempo compra para você?

Answer 1

Eu acho que realmente cabe à equipe decidir. Eu acho que você acertou em seu escrito sobre o Burndown, o mais importante é cumprir seus compromissos de sprint de forma consistente. Como isso acontece realmente deve chegar à equipe se eles realmente são autônomos. A equipe que estou agora, nossa norma é trabalhar em várias histórias de uma só vez; É a natureza da nossa configuração, uma vez que tentamos realmente espalhar a propriedade de histórias pela equipe. Pode ser uma norma diferente para a sua, se você tiver histórias mais curtas e mais um estilo de propriedade individual.

Answer 2

Pessoalmente, acho que uma história de cada vez funciona bem porque mantém você focado em uma tarefa. O custo da mudança de contexto entre várias histórias pode ser alto. Esta é uma preferência pessoal para mim, mas pessoas diferentes trabalham de maneira diferente. Embora eu ache que seu mestre de scrum está correto em sua metodologia, se você encontrou razões muito convincentes para várias histórias por vez e pode demonstrar que está de fato ajudando a progredir, isso seria um bom caso a se apresentar.

Answer 3

IMO, há uma questão subjacente aqui. Às vezes, ao trabalhar em uma história, precisarei de algo de outro departamento/equipe, por exemplo, esclarecimentos sobre um requisito ou um gráfico para uma página, e isso significa que não terminarei uma história antes de passar para outra história. Enquanto você menciona isso ao discutir os bloqueadores no Stand -Up, isso pode acontecer onde cabe a alguém do lado de fora para me ajudar a terminar uma história para que haja vários no meu prato. Assim, posso ter várias histórias devido ao bloqueio de algo e ainda querendo ser produtivo.

Em geral, não gosto de tentar gerenciar várias cópias da base de código ou mudar muito meu código, então prefiro fazer uma história de cada vez, assumindo que não há bloqueadores. O tamanho da base de código com o qual estou trabalhando é de ~ 1,1 GB de dados espalhados por mais de 82.000 arquivos, portanto, ter várias cópias pode ser um pouco doloroso que eu imagine.

Meu palpite pessoal é que cabe à equipe definir o padrão e ver que ele funciona para eles. Se alguns como uma história de cada vez e outros fazem vários e tudo está bem, legal. Se todo mundo gosta de ter várias histórias em vários pontos de conclusão, isso também pode funcionar.

Answer 4

Não houver o backlog ...Na minha experiência, quando as histórias têm entre 1 e 2 dias de tamanho, elas tendem a ser implementadas por um único desenvolvedor. Se você estiver trabalhando em 2 ou 3 andares simultaneamente, isso pode reduzir a quantidade de coisas no backlog que outros desenvolvedores podem escolher e comprometer o sprint.

... mas planeje bloqueioPor outro lado, trabalhar com 2 ou 3 andares significa que, se você estiver momentaneamente bloqueado em uma história, poderá ser imediatamente produtivo no outro. Acho que há alguma sobrecarga cada vez que começo uma nova história. Essa sobrecarga dificulta o preenchimento de uma hora "lacuna" no meu dia com um novo História, enquanto é muito mais fácil mudar para uma história que eu já comecei.

Resumindo, deixe a equipe decidir ... e depois revise os resultados durante uma retrospectiva. Se suas histórias, tarefas e processo de trabalho apoiarem um ambiente em que os membros da equipe podem trabalhar 2 (talvez 3) histórias por vez sem sacrificar a produtividade ou previsibilidade, então seu SM deve respeitar isso. Mas, ao mesmo tempo, você deve revisar honestamente os resultados durante cada retrospectiva e estar preparado para mudar se o SM não achar que está funcionando.

Answer 5

Eu geralmente pensaria que a decisão de como funcionar melhor deve ser tomada quase exclusivamente pela equipe. O papel do Scrummaster é ajudar e apoiar a equipe, não questionar a maneira da equipe de trabalhar durante um sprint.

Para ser justo, às vezes pode ser uma boa idéia para o Scrummaster apontar possíveis falhas ou riscos - que se enquadram na categoria "ajuda e suporte". Ser dogmático sobre sua ideia pessoal sobre como um sprint deve parecer internamente não é algo que eu gostaria que um scrummaster agisse. Parece um pouco como mal interpretar o papel de papel de um gerente, o que simplesmente não é o caso.

Quanto à maneira como fazemos: quase sempre trabalhamos em várias histórias de uma só vez. No momento, estamos tendo uma equipe de scrum de quatro pessoas com três desenvolvedores e um testador e quase sempre temos pelo menos dois ou três andares ao mesmo tempo. No último sprint, tentamos começar com todas as histórias no início do sprint para chegar ao ponto em que temos um design básico e uma boa idéia sobre quais poderiam ser os problemas em potencial. É claro que não estávamos trabalhando em todas as histórias ao mesmo tempo depois disso.

Entendo que, em termos de gerenciamento de riscos, você pode querer garantir que tudo seja feito para uma história antes de enfrentar o próximo. No entanto, a desvantagem é que, quando você encontra problemas imprevistos mais tarde, talvez não tenha tempo suficiente para corrigi -los. Geralmente, os problemas mostram seus rostos feios durante a fase de implementação e com frequência suficientemente cedo. Então, você basicamente troca um risco por outro.

Qual risco é mais fácil de lidar com a equipe. Afinal, é o sprint deles e, embora eu ache perfeitamente justo o Scrummaster mencionar preocupações sobre a maneira como o sprint está indo, ele não deve forçar sua idéia da melhor maneira de trabalhar na equipe.

No final, acho que tudo se resume a essas duas coisas:

1. Sim, trabalhamos em várias histórias de uma só vez e funcionou bem até agora.

2. Lembre -se de que o Scrummaster está trabalhando para a equipe, não o contrário.

Observe que estou falando principalmente de toda a equipe trabalhando em várias histórias de uma só vez, não um desenvolvedor. O problema que eu veria lá é que você precisa garantir que não bloqueie nenhuma história, mantendo-as abertas, para que ninguém mais possa continuar o trabalho. Mais uma vez, isso é uma questão de circunstância e preferência. Quando se trata de testes, nosso testador geralmente tem algumas tarefas de teste para histórias diferentes, para que ele possa mudar facilmente para uma tarefa diferente, se alguns bugs o impedirem de continuar testando um recurso.