Como podemos reduzir o tempo de inatividade no final de uma iteração?

Eu tenho lutado com a mesma pergunta ultimamente. Estamos começando na próxima iteração, mas sinto que isso remove a satisfação de uma iteração bem feita.

Estou pensando na opção de deixar para os desenvolvedores, com a ressalva "desde que a intenção seja beneficiar a empresa".

Exemplos:

• Passe o dia aprendendo alguma coisa
• Gastar em um projeto de tempo de inovação
• Gastar para arrumar essa parte chata de código que você nunca consegue refatorar
• Tenha uma boa experiência no aplicativo com o objetivo de usar o UX (que parece que nunca encontramos tempo para fazer de outra forma)

Tudo o que motiva o programador, dando-lhe um incentivo para entregar o lançamento a tempo.

Tire o dia de folga. Você fez o trabalho que você deveria fazer então por que você ainda está trabalhando?

Se a alteração do processo for possível, considere eliminar as iterações, liberar continuamente e manter as histórias do acúmulo. Mas você não merece um pouco de tempo?

Tenho notado o mesmo problema (e às vezes usamos sprints de duas semanas, o que agrava ainda mais). O que eu tento fazer nesses dias (sprint review day e sprint planning day) é economizar algum trabalho que sei que vou querer fazer, mas que não exige muito planejamento ou comunicação intrateam, como bugs de baixa prioridade, polimento, ou melhorias de ferramentas. Às vezes, isso realmente se torna positivo, pois cria um bom momento para fazer um trabalho importante, mas não sexy, do qual seria difícil ter tempo.

Mesmo que nossas histórias de usuário estejam quase sempre concluídas até o final de uma iteração, sempre temos uma longa lista de "bons para quem" no final, junto com uma lista de bugs conhecidos. Então, quando as pessoas terminam suas histórias, há sempre muito o que fazer.

Eu acho que fazer reuniões retrospectivas é rei, mesmo que sejam os mesmos problemas que são levantados, é muito importante gastar um pouco de tempo refletindo sobre como foi a iteração, como você está aprendendo, se você não perceba seus erros e as coisas que correram bem.

Se todos os bugs forem feitos, uma longa lista de coisas a serem feitas melhor, juntamente com pontos de ação, eu acho que é bom juntar a equipe na frente de uma tela grande, e tentar brincar com o software que foi construído, juntamente com algumas cervejas. Não é muito produtivo, mas é bom falar sobre o que foi implementado e como ele realmente funciona.

Se você tem dias, então eu tentaria encontrar algo novo para aprender, e tentar brincar com ele, talvez seja a próxima grande coisa. Mas, novamente, se houver dias, então provavelmente há uma história de usuário no backlog para fazer

Nossas iterações terminam às quintas-feiras para poder corrigir qualquer problema de última hora na sexta-feira. Mas as sextas-feiras (uma a cada duas semanas) coincidem com as nossas sextas-feiras de cerveja, por isso tentamos levá-las com toda a calma. Corrigir alguns pequenos bugs, passar algum tempo lendo coisas (livros, StackExchange, blogs, etc) e relaxar com uma cerveja no final do dia. Caso contrário, você não alcançará a sensação de conclusão ou encerramento, e, em vez disso, se sentirá como um hamster girando em uma roda sem parar.

Não tenho certeza de que deseja que sempre termine exatamente no horário. Fazer seu trabalho um pouco mais cedo permite que você pense em histórias, recursos e recursos futuros. Dá-lhe um pouco de pausa depois de um trabalho bem feito que pode ser mais recompensador do que começar cedo ou dedicar-se a mais histórias e ter sempre trabalho a transitar.

Ken Schwaber afirma em seu blog link

"Deus nos ajude. As pessoas encontraram maneiras de ter folga na cachoeira, descansar e ser criativas. Com Lean e Kanban, esses esconderijos foram removidos. Agora temos uma progressiva marcha da morte sem pausa."

Nos meus projetos, durante o planejamento de iteração, sempre selecionamos algumas tarefas extras e as rotulamos como "tarefas de bônus" que são trabalhadas se tudo na iteração for concluído. Pragmaticamente, essas "tarefas de bônus" geralmente são o que seriam trabalhadas primeiro na próxima iteração, mas, psicologicamente, chamá-las de "tarefas bônus" funciona muito melhor, então simplesmente ter sempre mais trabalho planejado pode ser completado.

Para outras coisas, como o aprendizado ou o tempo de inovação, simplesmente deixamos cada desenvolvedor gastar até um dia por semana com essas coisas como algo esperado. Pode ser qualquer dia da semana (ou seja, não precisa ser no final de cada semana).

Todos os desenvolvedores da minha equipe usam o tempo livre no final de um sprint (desde que todas as tarefas do sprint sejam concluídas) como 'Google time'.

É onde cada desenvolvedor trabalha em sua própria idéia / projeto, desde que beneficie a empresa. Eu sugiro strongmente colocar um sistema como este no lugar, isso realmente aumentou os níveis de satisfação no trabalho dentro de nossa equipe.

Se você está terminando constantemente três dias antes, isso sugere que você não está planejando histórias suficientes para o sprint.

Um dos objetivos do scrum é aumentar a produtividade - você não fará isso se estiver subindo em cada sprint.

Para resolver isso, planeje mais histórias do que você. Apenas se comprometa com sua velocidade anterior, mas se você terminar essas histórias, comece a trabalhar nas outras. Se você completar mais, aumente sua velocidade para o próximo sprint. Sempre planeje um pouco mais do que você vai se comprometer, ou pelo menos ter algumas histórias alinhadas, apenas no caso.

Esta é uma das razões pelas quais mudamos para o Kanban. Todos os benefícios do scrum sem ter que sair do projeto.

Eu gosto da resposta de Todd de tirar o dia de folga, no entanto eu diria que tente planejar sprint retrospectivamente pela manhã e definir um desafio de fazê-lo a tempo para o almoço e depois fazer um longo almoço como um time. No almoço, incentive a discussão sobre o sprint para obter uma retrospectiva informal de graça.

Se você não pode, em seguida, dar o aftenoon fora (e eu quero dizer como ir para casa no início da tarde fora de definir seus próprios objetivos tarde), em seguida, resolver dívida técnica como é a única coisa que deprime um desenvolvedor mais do que qualquer coisa else (fonte: minha opinião) ter que contornar a dívida técnica quando eles souberem exatamente como lidar com isso e tornar sua vida mais fácil.

Agora, em vez de ter uma retrospectiva, cada par de desenvolvedores escolhe um item pendente da lista de pendências retrospectiva existente e trabalha nele.

Também mantemos um backlog de dívida técnica em andamento, que funciona como itens de bônus para sprints (se a empresa não estiver pronta para implementar algo de seu backlog antes do tempo).

Isso já provou ser bastante positivo, pois todos os pequenos itens que apenas continuam borbulhando recebem um dia inteiro de atenção a cada sprint.

Faça uma sessão de design com quadro branco e compartilhe ideias de implementação para histórias interessantes sobre o próximo sprint. Faça isso depois e separe da sessão de planejamento, em que as histórias ainda eram leves em detalhes e avaliadas por pontos de história ou estimativas de tamanho de camisetas. Mantenha a sessão informal e incentive a criatividade.