Os sprints Scrum pretendem trabalhar no ritmo mais rápido possível?

21

Recentemente, entrevistei algumas empresas que fazem o Agile, o Scrum, para ser mais preciso e há algumas coisas que não me parecem muito ágeis. Vou pegar um caso que me interessa particularmente agora, o de Scrum Sprints.

Um gerente de projeto em particular com quem falei (sim, eu disse que o gerente de projeto) declarou orgulhosamente que as pessoas de sua equipe entendem ("foi informado" o que eu aprendi no contexto) que você não vai para casa quando o horário de trabalho termina , você vai para casa quando o trabalho é concluído, não importa quanto seja necessário. O que eu li nas entrelinhas é que reunimos o máximo de recursos possível em um sprint e trabalhamos horas extras para que isso aconteça.

Agora, ainda não fiz o Agile (trabalhei com instituições financeiras e governamentais que ainda preferem o cascata), mas meu entendimento é o seguinte:

sprint no Scrum é o nome da iteração genérica no Agile;
a equipe deve trabalhar em um ritmo sustentável e tentar evitar horas extras de longo prazo, pois isso só afeta o curto espaço de tempo e os efeitos são diminuídos pelos problemas em que incorrem no longo prazo.

Minhas declarações estão corretas? E devo considerar a apresentação do gerente como uma bandeira vermelha?

agile scrum development-methodologies

— JohnDoDo
fonte

Também não há experiência real com o Agile, mas pelo que entendi, sua carga de trabalho do sprint deve ser equilibrada com a duração do sprint; portanto, os desenvolvedores estão subestimando sua carga de trabalho ou o gerente está apenas dando a eles trabalho sem pedir feedback sobre a carga de trabalho . Neste caso, provavelmente, o último. - Corrija-me se estiver errado, no entanto

— Andreas

4

@gnat Eu acho que as perguntas são muito diferentes

— Andreas

27

"... você não vai para casa quando o horário de trabalho termina, você vai para casa quando o trabalho é feito, não importa quanto seja necessário ...". Corra como o vento. Ela é uma idiota.

— JᴀʏMᴇᴇ

Votei para reabrir esta pergunta. A questão da duplicata proposta é "ágil-o-novo-microgerenciamento" tem em comum com esta pergunta: que o gerente chama algo de "scrum" e o solicitante quer saber se isso é realmente scrum. Esta questão é sobre "horas extras", a proposta sobre "não é permitido conversar com outros desenvolvedores".

— K3b

"... que você não vai para casa quando o horário de trabalho termina, você vai para casa quando o trabalho é feito, não importa quanto seja necessário" parece um conflito direto com o conceito-chave de ritmo sustentável - eu trabalhar lá se eu tivesse que colocar comida na mesa. HST, se isso ocorrer de tempos em tempos, não tenho problema. Às vezes, apesar de todo esforço, há uma crise, e o cliente vem em primeiro lugar. Mas ela faz parecer que isso é uma ocorrência regular e que é admirável. O que isso significa é que eles não estão fazendo a causa raiz para entender por que está ocorrendo e corrigir o problema subjacente.

— Don Branson

27

Você não precisa procurar muito para ver que essas práticas são contrárias aos princípios por trás do Agile. Um dos princípios por trás do Manifesto Ágil afirma:

Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente.

Alguns anos atrás, Scrum fez uma mudança sutil, mas importante . Em vez de as equipes se comprometerem com o trabalho que pode ser alcançado, elas prevêem o que pensam que podem ser feitas.

A mudança ocorre por causa do abuso, que parece muito com a atitude de não ir para casa até que tudo seja feito. No desenvolvimento, existem muitos fatores fora do controle das equipes com os quais eles não podem se comprometer - para usar a analogia do clima, você não pode "comprometer" que choverá amanhã.

Para responder diretamente às suas perguntas:

sim, Sprint é o nome de uma iteração no Scrum. Veja esta resposta pela diferença
Sim, as equipes devem trabalhar em um ritmo sustentável. A única certeza de horas extras é que ele vai reduzir a equipes de produtividade a longo prazo.
sim, é uma bandeira vermelha!

— Dave Hillier
fonte

23

Sim, você está certo, e se me dissessem o que foi dito, eu fugiria dali o mais rápido possível. Eles estão apenas usando o ágil como desculpa. Soa como a marcha da morte clássica.

— Miki Watts
fonte

3

Uma marcha da morte normalmente não teria fim? Esse projeto parece um inferno eterno, se é assim que eles funcionam sprint após sprint.

— DXM

5

Não, em uma marcha da morte, sempre há "apenas precisamos avançar para a próxima versão, para refatorar e corrigir bugs! Oops, prometemos ao cliente a próxima versão seguinte em dois meses, apenas precisamos avançar para a próxima próxima versão!" e assim por diante, você entendeu a ideia.

— Miki Watts

2

@DXM termina quando todos saem ou são demitidos. Os projetos da Marcha da Morte podem durar anos.

— Dogweather

3

As marchas da morte do @DXM terminam quando você morre.

— precisa saber é o seguinte

hmm, acho que estava projetando minha própria experiência lá. De alguma forma, em minha mente, os projetos mal administrados são uma combinação de marcha da morte seguida de meses de indecisão sobre onde ir. Por mais tempo, nossa equipe ficou em pé com a lista de pendências vazia, durante quase oito meses. Então nós ser dada 4-6 meses para um lançamento com a declaração "estamos em um ciclo de lançamento anual"

— DXM

11

Há uma coisa importante que pode tornar isso aceitável: a equipe aceita o escopo do sprint.

No Scrum, as equipes não recebem apenas trabalho atribuído. O proprietário do produto negocia com a equipe para priorizar o trabalho do produto e o trabalho técnico (de dívida). O gerente de projeto, o proprietário do produto e a equipe negociam o que é puxado para uma sprint e qual é o escopo desse trabalho.

Nesse mundo, a equipe está basicamente dizendo "podemos realizar o trabalho do X, testar e enviar essa iteração". Então, eu esperaria que uma equipe ocasionalmente trabalhasse horas extras para cumprir esses compromissos.

Dito isto, muitos lugares bastardizam o ágil - e tão poucos líderes de equipe podem negociar efetivamente com pessoas que geralmente são seus chefes ... Eu consideraria isso uma enorme bandeira vermelha.

— Telastyn
fonte

8

"ocasionalmente horas extras de trabalho para atender a essas ( erroneamente estimados compromissos)" => fazer estimativas erradas em um hábito

— mosquito

1

@gnat - pssh. Às vezes, as estimativas são altas. Às vezes, as estimativas são baixas. Se a subestimação se tornar uma tendência, certamente será um problema. Mas é por isso que existem iterações: para ajudar a refinar a estimativa.

— Telastyn

8

As fábricas de programação geralmente não aceitam negociações dos trabalhadores.

— Maple_shaft

1

@gnat: Se você descobrir, em equipe, que está subestimando o trabalho habitualmente, deve se comprometer com menos trabalho no próximo sprint.

— Bart van Ingen Schenau

Quando as metas de gerenciamento são para realizar o máximo de trabalho possível, independentemente dos limites de horas de trabalho (e a experiência indica que isso é verdade na grande maioria dos casos), e as metas dos funcionários são para realizar o máximo de trabalho sem exceder o trabalho remunerado horas (admito que alguns gerentes podem argumentar que isso é otimista), então, independentemente do erro inerente na estimativa, a programação sempre tenderá a> = horas de trabalho. A extensão lógica é que as metas dos funcionários devem mudar para subestimar. @BartvanIngenSchenau é assim que esse hábito se desenvolve naturalmente.

— Steven Evers

1

O Scrum é dividido em sprints, onde você estima um conjunto de tarefas a serem concluídas durante o sprint (normalmente 2 semanas, mas eu já vi de 1 dia a 4 semanas). Eu acho que isso cria um incentivo para não avaliar tarefas. Os OPs (proprietário do produto) desejam estimativas baixas para obter um grande comprometimento por sprint. A equipe fará grandes estimativas para gerar bons gráficos de burndown para os PMs verem. Estes são, obviamente, indicativos de uma organização ruim. Você realmente deseja obter estimativas precisas e não ter medo de ficar aquém e levar as histórias para o próximo sprint ou terminar mais cedo e retirar tarefas extras do backlog. Eu acho que o termo "sprint" cria essa imagem de pessoas trabalhando mais rápido.

— jiggy
fonte

1

exceto que a OP não deve participar do processo de estimativa. Se eles fossem ágeis, as equipes seriam as únicas responsáveis por apresentar estimativas e com base no que a equipe estima que o OP só pode alterar as prioridades de pendências.

— DXM

2

"A equipe fará grandes estimativas para gerar bons gráficos de burndown para os PMs verem.": Essa é uma das razões pelas quais acho que todo esse mecanismo é defeituoso. Acho que um gerente pode obter um desempenho muito melhor de uma equipe em que confia do que forçando uma equipe a fornecer estimativas para serem alimentadas em gráficos.

— Giorgio

A equipe deveria, mas como eu disse, eles têm um incentivo para preencher estimativas. Se a OP for quem paga, eles podem aplicar pressão para estimar de forma mais agressiva. Para o fundo, eu trabalho em consultoria para que a equipe scrum é meus colegas de trabalho, enquanto o PO é geralmente externa e pagar a nossa taxa inflado bill :)

— jiggy

@Giorgio uma equipe não confiável sempre pode preencher estimativas e piorar as coisas. Mas uma equipe confiável, mesmo de especialistas, pode aprender a estimar melhor. É por isso que as estimativas são feitas e comparadas com o trabalho real, para tentar melhorar sua capacidade de estimativa. O mecanismo não é defeituoso, ter uma equipe que está tirando vantagem de um sistema é o problema, e será o problema independentemente do sistema de gerenciamento.

— Chris

1

Não: os scrum sprints são uma caixa de tempo, nada mais, nada menos. No início do sprint / iteração, a equipe faz uma estimativa da quantidade de pontos da história que eles acreditam que podem alcançar, com base em desempenho como anterior, disponibilidade, eventos futuros, impedimentos em aberto etc. Eles negociam com o proprietário do produto. sobre quais histórias de usuários são colocadas no sprint. Esse é (ou foi? Veja outra resposta) o compromisso que a equipe dá ao proprietário do produto.

Durante o desenvolvimento, se as coisas não estiverem realmente como o previsto (afinal, é desenvolvimento de software) e existe o risco de a equipe não cumprir o compromisso, eles informam ao proprietário do produto que existe o risco de uma ou mais histórias não ser concluído.

E tudo bem. Claro, é ruim ter que admitir no final do sprint que o sprint falhou, mas não é uma derrota, é uma oportunidade de melhoria. Como no final do sprint / início do novo, você pode fazer uma retrospectiva do sprint, e a primeira coisa que alguém perguntará é: 'Por que falhamos nesse sprint e o que precisamos fazer para não falhar novamente? ? ' Uma opção seria dispensar menos comprometimento (= ocupar menos pontos na história).

tl; dr: ritmo sustentável. Scrum é sobre cadência, algo que a equipe pode manter indefinidamente em uma base de sprint a sprint. Trabalhar horas extras não é; a equipe ficará sobrecarregada, o trabalho ficará desleixado, os membros entrarão doentes ou desistirão por completo, e então você terá um problema muito maior do que um sprint com falha.

— Cthulhu
fonte

0

Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente.

Do pessoal do Manifesto Ágil

Trabalhar horas extras o tempo todo não me parece sustentável.

Dito isso, não vejo problema com o compromisso da primavera ser forte (se é assim que a equipe quer trabalhar), e ter que trabalhar horas extras quando você confirma demais ou estraga as estimativas é um bom incentivo para melhorar a estimativa ou a comunicação. expectativas para o PO.

— ptyx
fonte

0

Um gerente de projeto em particular com quem falei (sim, eu disse que o gerente de projeto) declarou orgulhosamente que as pessoas de sua equipe entendem ("foi informado" o que eu aprendi no contexto) que você não vai para casa quando o horário de trabalho termina , você vai para casa quando o trabalho é concluído, não importa quanto seja necessário. O que eu li nas entrelinhas é que reunimos o máximo de recursos possível em um sprint e trabalhamos horas extras para que isso aconteça.

Isso não é Scrum. A carga de trabalho proposta para uma caixa de tempo é baseada na velocidade da equipe , não na lista de desejos do gerente. Eles estão simplesmente tentando convencê-lo a acreditar que trabalhar horas extras sem fim é "Agile", o que não é. A equipe se tornará mais eficiente enquanto trabalha sem perturbações e foco, mas o Scrum não é uma varinha mágica para ganhos de eficiência sem fim .

O gerente tem um leve mal-entendido sobre o Agile ou (mais provavelmente) ele acha que os desenvolvedores são tão estúpidos. Por outro lado, quando a equipe aceita o sprint repetidamente, sabendo que precisará fazer horas extras, talvez eles sejam realmente estúpidos e não o mereçam melhor?

Eu acho que você sabe a resposta ... ;-)

— JensG
fonte