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

Onde trabalho, praticamos ágil orientado a scrum com iterações de 3 semanas. Sim, seria bom se as iterações fossem mais curtas, mas mudar isso não é uma opção no momento.

No final da iteração, geralmente acho que o último dia passa muito devagar. O trabalho real já foi concluído e aceito. Existem algumas reuniões (a retrospectiva e o próximo planejamento de iteração), mas, além disso, pouco está acontecendo.

Que tipo de técnicas podemos usar como equipe para manter o ritmo até o último dia? Devemos resolver os defeitos? Começa cedo no trabalho da próxima iteração, afinal? Algo mais?

Ultimamente tenho lutado com a mesma pergunta. 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 isso para os desenvolvedores, com a ressalva "desde que a intenção seja beneficiar a empresa".

Exemplos:

• Passe o dia aprendendo algo
• Gaste-o em um projeto de tempo de inovação
• Gaste-o arrumando aquele pedaço de código irritante que você nunca consegue refatorar
• Tenha uma boa execução do aplicativo com vista para o UX (que parece que nunca encontramos tempo para fazer de outra maneira)

O que quer que motive o programador, incentivando-o a entregar o release no prazo.

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

Se a alteração do processo fosse possível, considere descartar iterações, liberar continuamente e apenas continuar retirando histórias da lista de pendências. Mas você não merece um pouco de tempo de inatividade?

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

Mesmo que as histórias de nossos usuários quase sempre sejam finalizadas no final de uma iteração, sempre temos uma longa lista de itens interessantes no final, juntamente com uma lista de bugs conhecidos. Então, quando as pessoas terminam suas histórias, sempre há muito o que fazer.

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

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

Se você tiver dias, tentarei encontrar algo novo para aprender e tentar brincar com ele, talvez seja a próxima grande novidade. Mas se houver dias, provavelmente há uma história de usuário na lista de pendências a ser feita

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

Não tenho certeza se você deseja sempre terminar exatamente na hora certa. Fazer o seu trabalho um pouco mais cedo permite que você pense em histórias, recursos e recursos futuros. Dá uma pausa depois de um trabalho bem feito, que pode ser mais gratificante do que começar cedo ou comprometer-se com mais histórias e sempre ter o trabalho continuado.

Ken Schwaber afirma em seu blog http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

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

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

Para outras coisas, como tempo de aprendizado ou inovação, simplesmente deixamos cada desenvolvedor gastar até um dia por semana nessas coisas, como uma coisa esperada normal. 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 'tempo do Google'.

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

Se você está constantemente terminando três dias mais cedo, 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 filmando cada sprint.

Para resolver isso, planeje mais histórias do que você já esteve. Comprometa-se apenas com a velocidade anterior, mas se você terminar essas histórias, comece a trabalhar nas extras. Se você completar mais, aumente sua velocidade para o próximo sprint. Sempre planeje um pouco mais do que você se comprometerá, ou pelo menos tenha algumas histórias alinhadas, apenas por precaução.

Essa é uma das razões pelas quais mudamos para o Kanban. Todos os benefícios do scrum sem precisar interromper o projeto.

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

Se você não pode dispensar a folga (e eu quero dizer, como ir para casa no início da tarde e não definir seus próprios objetivos à tarde), então lide com a dívida técnica, pois é a única coisa que deprime um desenvolvedor mais do que qualquer outra coisa (fonte : minha opinião) ter que solucionar a dívida técnica quando souberem exatamente como lidar com ela e facilitar sua vida.

Pessoalmente, acho que as retrospectivas realmente não valem a pena gastar tempo, geralmente existem alguns temas recorrentes (histórias de usuários ruins, estimativas ruins, etc.) e você as aceita como áreas problemáticas e segue em frente. Também tentamos lidar com os problemas quando eles surgem, em vez de esperar pela retrospectiva (o que tínhamos a tendência de fazer nos estágios iniciais da adoção do Scrum).

Agora, em vez de ter uma retrospectiva, cada par de desenvolvedores escolhe um item excelente do backlog retrospectivo existente e trabalha nele.

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

Isso já se mostrou bastante positivo, pois todos os pequenos itens que ficam borbulhando sob a atenção recebem um dia de atenção a cada corrida.

Faça uma sessão de design do quadro branco e compartilhe idéias de implementação para obter histórias interessantes sobre o próximo sprint. Faça isso depois e separe da sessão de planejamento, onde as histórias ainda eram claras sobre os detalhes e julgadas por pontos de história ou estimativas de tamanho de camiseta. Mantenha a sessão informal e incentive a criatividade.