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

56

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?

Adam Lear
fonte
3
Eu voto para começar cedo. Isso é o que fazemos.
14
Eu voto por ir para casa mais cedo. Isso é o que eu faria.
Kirk.burleson
@ Kirk 11h pode ser um pouco cedo demais. ;)
Adam Lear
Se a retrospectiva levar apenas 1 hora e meia (11h - 8h) / 2 reuniões), talvez você deva torná-la mais divertida. :)
bzlm

Respostas:

68

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.

pdr
fonte
14
Eu gosto do seu primeiro item "Passe o dia aprendendo alguma coisa" a longo prazo, isso pode trazer enormes benefícios não apenas para o desenvolvedor, mas também para a empresa.
Unkwntech 12/04
11
Para uma visão interessante de algo muito parecido com os seus exemplos, os dias fedex ( blogs.atlassian.com/rebelutionary/archives/000495.html ) são uma ideia muito interessante. Construa o que quiser, mas entregue-o em 24 horas.
Steven Evers
Aprender coisas novas pode ser um enorme impulso moral. Apenas certifique-se que está em uma esfera que é algo relacionado aos negócios da empresa
Rudolf Olah
22

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?

Todd Hoff
fonte
8
Porque acredita em mim, quando os sprints exigem que você trabalhar até tarde - você vai trabalhar até tarde :)
Spedge
14

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.

dfan
fonte
7

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

Kim.Net
fonte
5

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.

Rafa
fonte
5

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."

JohnK
fonte
2
Exatamente. O post do OP parece ser o oposto do que deveria ser ... está basicamente dizendo "Como podemos fazer mais trabalho depois que terminamos cedo?" em vez de dizer "Terminamos cedo, vamos relaxar um pouco".
Wayne Molina
3

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).

jwanagel
fonte
Bom - como você os chama, deve ficar claro que esse é um trabalho extra realizado. Não há nada mais desmoralizante do que ter um sprint rotulado como falido porque o trabalho prometido não foi concluído.
Robbie Dee
2

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.

thegreendroid
fonte
2

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.

Jeremy French
fonte
1

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

Si Keep
fonte
0

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.

narcisos
fonte
0

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.


fonte
Quanto tempo você demorou para eliminar os problemas retrospectivos comuns (histórias ruins, estimativas)? Você nunca faz uma retrospectiva, movendo toda a discussão para discussões menores em todo o sprint?
cringe
-1

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.


fonte