Como parar / evitar o tempo em um Time Scrum?

14

Na verdade, estou ajudando uma pequena loja de software em sua implementação do Scrum. Recentemente, o Scrum Master me informou que ele tem um problema porque a equipe está trabalhando ao longo do tempo para atingir o escopo (Committed Backlog). Então eles têm uma Unreal Velocity .

Minha pergunta formal é:

  1. Além de falar sobre o Encontro Retrospectivo; Você acha que é uma boa idéia implementar alguns hard-blocks para evitar o Over Time?
  2. Se sim, que técnicas / ferramentas você sugere?

    • Sistema de controle de revisão (SVN, GIT, HG, etc ...), blocos por horas (8 a 5)
    • Blocos de estação de trabalho por horas (8 a 5) ou horas acumuladas (até 8 horas / dia)?
    • Outro (s) ...
  3. Ou, talvez, não dificulte esse tipo de coisa; mas implementar algum "Sistema de Penalidades" para Horas extras não justificadas ?

Primeiro: Tks tudo por suas respostas rápidas.

@Baqueta (e outras com perguntas semelhantes): Não, elas não foram pagas por horas extras. Meu primeiro conselho a eles foi revisar suas estimativas porque talvez eles estavam subestimando. Este foi o meu conselho favorito:

If they have an interest in working overtime, remove it. Development isn't something you can do for 60 hours a week and stay productive, and there are numerous studies out there that prove this. If overtime pay is the issue, get rid of it and improve their base pay so they're getting what they're worth.

Além disso, acho que o problema raiz (para essa equipe) é uma combinação do seguinte:

  1. The developers are being told what they must achieve in a sprint/aren't being consulted on what's achievable/are being ignored when they say there's too much work.
  2. The developers are consistently underestimating how much time tasks will take/how many units of work are involved in each task.

Resumo: falarei com a equipe para analisar suas estimativas e com o P.O. porque eu sinto que eles não estão sendo consultados sobre o escopo, como você mencionou.

    
por Lorenzo Solano 01.08.2012 / 05:30
fonte

8 respostas

26

Francamente, esses "blocos duros" que você mencionou no # 2 são a pior ideia que eu já ouvi em muito tempo. O que acontece se um bug de alta prioridade for encontrado às 16h45 e o cara que tem a capacidade de substituir seus bloqueios estiver doente? Quanto ao nº 3 - você está sugerindo que castigue as pessoas por fazerem seus trabalhos .

Se a equipe estiver trabalhando constantemente para completar as sprints, ou se tiver interesse em trabalhar horas extras, por exemplo, horas extras pagam ou recebem horas extras de volta como feriados - ou estão se comprometendo a fazer muito trabalho nos sprints.

Se eles tiverem interesse em trabalhar horas extras, remova-o . O desenvolvimento não é algo que você pode fazer durante 60 horas por semana e continuar sendo produtivo, e há vários estudos que comprovam isso. Se o pagamento de horas extras é o problema, livre-se dele e melhore o salário base para que eles recebam o que valem.

Se houver muito trabalho nos sprints, isso geralmente ocorre por uma das três razões:

  1. Os desenvolvedores estão sendo informados sobre o que devem conseguir em um sprint / não estão sendo consultados sobre o que é possível / estão sendo ignorados quando dizem que há muito trabalho.
  2. Os desenvolvedores estão constantemente subestimando quanto tempo as tarefas levarão / quantas unidades de trabalho estão envolvidas em cada tarefa.
  3. Os desenvolvedores continuam sendo atraídos para tarefas que não fazem parte do scrum.

Se é o número 1, você está fazendo errado . Não há duas maneiras sobre isso!

Se for # 2, a causa usual é a inexperiência - seja com estimativas de tempo ou com o sistema sendo desenvolvido. Uma boa maneira de contornar isso é parar de fazer estimativas de tempo e começar a estimar 'unidades de trabalho'. Use alguma unidade abstrata, apenas certifique-se de que não são horas em tempo real (em última análise você ainda está representando um intervalo de tempo, mas a abstração é importante!). Você pode então calcular quantas unidades de trabalho realmente são feitas em uma semana, depois configurar sprints usando esses dados.

Se é # 3, você precisa começar a considerar essas outras tarefas de alguma forma. Se for consistente, deve ser fácil contabilizar (ver # 2 acima). Se é frequente, mas imprevisível, é muito mais complicado lidar com isso. Você vai querer dar uma olhada em porque isso está acontecendo (por exemplo, bugs sérios no código 'live' = > seu teste é completo o suficiente?), Mas se isso não puder ser resolvido, o scrum pode não ser a abordagem correta para você . Minha equipe recentemente mudou para o Kanban por essa mesma razão ...

Editar: Esclareceu minha crítica às idéias apresentadas na pergunta.

    
por 01.08.2012 / 10:21
fonte
12
Em primeiro lugar, parece que eles trabalharam demais em um sprint se tiverem que trabalhar horas extras para fazê-lo. Todas as horas são registradas? Nesse caso, você pode contar quanto trabalho real é um ponto da história e usar esse número para calcular o trabalho para o próximo sprint.

Também é importante certificar-se de que a equipe entenda que eles estão apenas se prejudicando por meio de muito trabalho. Até o manifesto ágil fala em ritmo sustentável: "Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente." Trabalhar horas extras o tempo todo não é sustentável.

Em suma, eu sugeriria comunicação em vez de força e penalidades. Eu imagino que isso só levaria à desmoralização da equipe.

    
por 01.08.2012 / 06:29
fonte
4

Os desenvolvedores que trabalham horas extras estão provavelmente respondendo a algum incentivo, seja real ou percebido. O é para remover o incentivo, se for real, ou para comunicar que um incentivo percebido não está operacional.

Cada limite rígido sugerido tem algumas soluções alternativas ou outros problemas. Os blocos de controle de origem apenas levariam os desenvolvedores a manter seus commits até que a janela fosse aberta novamente. Os blocos de estações de trabalho precisariam ser executados assim que houvesse algum problema de suporte ou um dos devs necessários para mudar suas horas por algum motivo. Sistemas de penalização apenas levarão a esconder ou enterrar horas extras.

Eu acho que o problema é mais fundamental - a equipe tem algum incentivo (ou acredita que eles têm um incentivo) para trabalhar horas extras.

Isso é o que precisa ser tratado. Suas avaliações de desempenho estão vinculadas a seus números de velocidade? A gerência trabalha horas extras? As promoções e prêmios são concedidos a quem trabalha por longas horas? Eles são contratados que recebem horas extras?

    
por 01.08.2012 / 17:05
fonte
3

Simplesmente diga à equipe para não fazer hora extra. Período.

Isso pode fazer com que eles não consigam terminar algum trabalho. Isso não é um problema, é um ponto de dados. Eles podem então usar esse ponto de dados no planejamento do próximo sprint. Mais uma vez, não deixe que eles trabalhem horas extras. Se eles terminam ou não, eles têm outro ponto de dados. Espuma, enxaguar, repita.

Nenhuma quantidade de truques ou limites são necessários. Apenas não trabalhe horas extras. Saiba quanto trabalho você pode realizar e ajuste seu planejamento de sprint de acordo.

    
por 01.08.2012 / 13:08
fonte
0

Talvez exista um problema de não como "muito" eles estão funcionando, mas quando. Isso pode ser um problema quando há um dia de trabalho agendado, mas grande parte das horas normais é composta de reuniões e outras distrações sociais e pessoais. Eles estão trabalhando durante períodos de tempo excessivo porque se sentem mais produtivos?

Reduza a quantidade de trabalho no sprint e comece a trabalhar no tempo flexível. Permitir que eles cheguem mais tarde. A pessoa responsável precisa apenas dizer às pessoas para irem para casa; está tudo bem. Existem algumas culturas corporativas que criam um ambiente em que sair cedo pode trazer algumas carrancas.

    
por 01.08.2012 / 17:10
fonte
0

Eu aconselho strongmente contra "blocos duros". Esses controles podem ser percebidos como microgerenciamento e podem não resolver o problema subjacente.

Sugiro que você descubra por que os programadores estão trabalhando excessivamente. A resposta pode te surpreender. Parece que você é um "estranho" (não um funcionário da empresa), e os programadores podem estar dispostos a ser sinceros com você se você se encontrar com eles em particular (um-contra-um).

A razão para trabalhar horas extraordinárias é realmente a carga de trabalho ou a razão mais está relacionada à cultura ou às expectativas?

Razões de carga de trabalho podem ser

  • O backlog confirmado é muito grande
  • Programadores ou o produto proprietário é "gold-plating" (tornando as funcionalidades mais complexas do que as necessárias)

As expectativas podem ser

  • Algum tipo de recompensa financeira ou de reconhecimento por trabalhar horas extras
  • Medo de fracasso. Os programadores temem que fiquem mal ou sejam punidos se não cumprirem o prazo
  • Os programadores estão subestimando os efeitos nocivos a longo prazo do trabalho extraordinário.
por 01.08.2012 / 17:11
fonte
0

Eu lutei com isso quando mudei para o scrum. É natural querer colocar um esforço extra perto de um prazo, mas o scrum tem prazos a cada duas semanas, então é um ajuste. Além da sugestão que outros fizeram para reduzir os pontos de história comprometidos a cada iteração, eu também sugeriria garantir que as histórias sejam divididas o suficiente, para que cada desenvolvedor possa concluir pelo menos dois ou três em uma iteração.

Isso não apenas garante que cada desenvolvedor se sinta como se tivesse realizado algo em cada iteração, mas também lhe dá alguma folga em seu escopo. Quando sua burndown mostrar que você não será capaz de terminar uma história, pode retirá-la e realocar as pessoas para as histórias que podem ser concluídas. Quando as pessoas perceberem que o escopo pode ser ajustado, elas estarão menos propensas a enfatizar os prazos irrealistas. Se você iniciar uma iteração com todas as histórias em andamento, não terá espaço para ajustes.

Um gráfico de fluxo cumulativo ideal deve ser algo assim se todos estiverem concluindo duas histórias por iteração:

Nunca se parece com isso porque, na realidade, é muito difícil contar todas as histórias para terminar no último dia, mantendo todos ocupados, mas é uma boa regra geral. Se você está supercomprometido, a área vermelha será maior e você poderá remover histórias. Se você não está comprometido, a área azul será maior e você poderá adicionar histórias. Se as suas histórias forem muito grandes, a área verde será maior e você deverá dividir as histórias.

    
por 01.08.2012 / 19:30
fonte
0

Para evitar horas extras, você precisa cortar o escopo do projeto.

O gráfico a seguir mostra onde a incerteza está em um projeto:

Sevocênotar,nasfasesdedefiniçãoerequisitosdoproduto,vocêtemumaenormevariaçãonaestimativadeesforço.Vocênãopodetercertezaselevaráummêsouumdiaparaimplementarorecurso.

Apostoquenenhumadastarefas foi concluída porque são simplesmente muito grande e não especificado e há muitos deles.

Se sua equipe puder lidar com 10 tickets em 5 dias, eles receberão 20 tickets, reduzirão esse número, enviarão o item para o proprietário do produto / gerente de projeto / gerente / cliente e informarão para priorizar.

Neste ponto, essa é a única maneira de salvar a equipe das horas extras. Você não pode entregar tudo, mas o que você fizer será menos provável de ter bugs.

Também aconselho procurar um novo emprego e ajudar seus colegas de equipe a fazer o mesmo e consertar seus currículos e portfólios profissionais. Uma empresa que espera horas extras é uma que ninguém deveria trabalhar e que o software produzido será cheio de bugs.

    
por 07.03.2015 / 17:58
fonte

Tags