Sou desenvolvedor que trabalha em um novo aplicativo móvel para Android e iOS com um grande componente de back-end. Estivemos em três corridas deste projeto e usamos o Scrum com todas as suas cerimônias (refinamento, planejamento, diários, retrospectivas etc.).

Em dois dos sprints, a equipe teve que trabalhar (não remunerada) horas extras e fins de semana, porque a gerência estava muito alarmada que não concluiríamos o compromisso do sprint a tempo. Todo mundo trabalhou duro, mas algumas dependências externas e estimativas otimistas nos fizeram lutar para realizar todas as histórias do sprint.

Na minha experiência, ter uma pequena porcentagem de histórias não concluídas durante alguns sprints é algo normal, e elas podem ser abordadas na próxima. Mas nosso gerente de projetos diz que a culpa é nossa, pois nós mesmos fizemos a estimativa; portanto, devemos concluir todos os itens do sprint.

1. É uma variação aceitável / comum do Scrum que eu não conheço?

2. Como você sugere que eu deva agir sobre isso?

Algumas coisas se destacam para mim.

A idéia de que a gerência tem que a equipe se compromete com um conjunto de trabalhos é inconsistente com as versões mais recentes do Guia Scrum. A palavra "commit" ou "commit" é usada apenas duas vezes na versão mais recente (novembro de 2017) do Guia Scrum - uma vez ao listar os valores Scrum e outra vez para indicar que "as pessoas se comprometem pessoalmente a atingir os objetivos da equipe Scrum "

A ideia de objetivos é importante para o Scrum. Não apenas as organizações e equipes têm objetivos amplos, mas no Scrum, cada Sprint possui um Objetivo Sprint definido no Sprint Planning como uma colaboração entre o Dono do Produto e a Equipe de Desenvolvimento. O Objetivo da Sprint é atingido através da implementação de itens do Backlog do Produto, mas não é simplesmente "concluir este corpo de trabalho" e geralmente não representa o Backlog completo do Sprint. Ou seja, você deve conseguir atingir a meta da Sprint sem concluir cada item do Backlog do produto selecionado para o Sprint ou cada item no Backlog do Sprint. Meu pensamento atual é que o trabalho necessário para atingir a meta da Sprint deve estar em torno de 60 a 70% da capacidade da sua equipe, no entanto, você é responsável pela capacidade. Porém, organizações diferentes serão diferentes, mas isso '

Trabalhar horas extras e fins de semana também é uma prática anti-Agile de Desenvolvimento de Software. Um dos princípios subjacentes é que todas as partes interessadas de um esforço são capazes de trabalhar em um ritmo sustentável. Dias longos e fins de semana, mesmo que pagos, não são sustentáveis ​​para uma equipe.

Neste ponto, existem alguns próximos passos. O Scrum Master da equipe deve educar o gerenciamento sobre os valores e princípios do Scrum e do Agile Software Development (como "compromisso" e "ritmo sustentável"). A equipe deve trabalhar em sua capacidade de prever o trabalho e negociar o escopo com o Dono do produto. A equipe também deve identificar e trabalhar para solucionar ou impedir os impedimentos que levaram a essa situação (eliminar ou reduzir o impacto de dependências externas).

A situação que você descreve, onde a gerência exige que a equipe trabalhe horas extras para concluir todas as histórias planejadas, é um dos motivos pelos quais a literatura do Scrum parou de usar o termo "compromisso". Um comprometimento verdadeiro só pode ser dado quando toda a incerteza for removida, incluindo incertezas sobre dependências de terceiros, quanto trabalho cada item é, quanto tempo todos estarão disponíveis, levando em consideração a doença, etc.

Uma das idéias básicas do Scrum é que a equipe trabalhe em um ritmo sustentável, o que significa essencialmente trabalhar horas normais sem horas extras (pagas ou não). Isso significa diretamente que você não está enfrentando uma variação aceitável do Scrum.

O que você pode fazer sobre isso depende do seu papel.

Se você é um desenvolvedor, o melhor que pode fazer é

• (coletivamente como equipe de desenvolvimento) se recusam a "se comprometer" com mais trabalho do que você tem certeza absoluta de que pode entregar em um sprint. Provavelmente será muito menos do que o que a gerência deseja que você faça.
• mantenha o foco no trabalho de conclusão, em vez de iniciar novas tarefas. Se você perceber que algum trabalho não pode ser concluído, indique-o o mais cedo possível, para que os planos possam ser ajustados.

Se você é um mestre do Scrum, pode realmente provar seu valor educando a gerência sobre o Scrum. Alguns pontos que se destacam para mim:

• Conforme declarado no primeiro parágrafo, a equipe não se compromete durante o planejamento do sprint, mas fornece uma previsão do trabalho que espera ter terminado.
• Embora a equipe deva evitar o trabalho inacabado no final de um sprint, essa situação é quase inevitável no início de um projeto (ou após uma alteração na composição da equipe). A quantidade de trabalho que a equipe pode realizar realisticamente em um sprint só pode ser determinada com base em números históricos dos últimos sprints da equipe nessa composição. No início do projeto, essas figuras históricas simplesmente não existem; portanto, uma equipe realizando nos três primeiros sprints exatamente o que o planejado para cada sprint é mais um acidente do que um bom planejamento. Após cerca de 5 sprints em um ritmo sustentável, existem dados suficientes para ter uma idéia razoável de quanto trabalho a equipe pode concluir realisticamente em um sprint.

Seu PM não tem nenhum negócio envolvido em seu scrum.

Seu PM não tem negócios solicitando horas extras não remuneradas.

O mais óbvio é estimar todas as tarefas de forma que você possa garantir que elas serão concluídas a tempo. Então você deve poder ir ao pub pela segunda maneira, pois se subestimar uma tarefa significa que você a conclui de graça, então superestimar significa que você tem tempo sem trabalho.

Há vários aspectos nisso, mas em um nível alto, sim - o gerente geral deseja entender claramente por que o trabalho planejado não foi concluído. No entanto, isso deve ser levantado (e resolvido) na retrospectiva. Do lado do desenvolvedor, há muitos fatores que podem contribuir para falhas no sprint.

Algumas coisas que você pode querer considerar:

Muito no sprint

Se você se comprometer regularmente com muito trabalho, os sprints falharão. A velocidade do sprint deve ser rastreada ao longo do tempo para descobrir qual é o número ideal de pontos (ou dias).

Alocação de recursos

Assegure-se de que o planejamento do sprint responda adequadamente a atividades de não desenvolvimento, como cerimônias, feriados, treinamento, administração, suporte e outros projetos etc. colocá-lo no pé traseiro desde o início.

Estimar variação

Você está refinando, mas existem certos tipos de tarefas que sempre excedem? Geralmente, esses requisitos estão ausentes ou vagos. Se os requisitos forem confusos, a história não deve chegar ao sprint, a menos que tenha sido adequadamente refinada ou que tenha sido planejado um pico.

Velocidade

Se a velocidade estiver sendo rastreada corretamente, o número real de histórias deve ficar claro. Isso não quer dizer que eles sempre sejam feitos a tempo, mas deve facilitar muito as coisas.

Boa vontade

Em qualquer projeto, a boa vontade é limitada. Se você está constantemente trabalhando fora do expediente, o moral sofrerá e os desenvolvedores se esgotarão - isso é uma falha no gerenciamento de projetos . Como já descrevi, certifique-se de que o planejamento da sprint apenas programa um número realista de histórias usando velocidade e picos para ajudá-lo ao longo do caminho.

Espigões

Se um item é muito refinado ou simplesmente lanoso, não tenha medo de colocar um pico para fornecer uma estimativa melhor para os sprints posteriores. Sim, algumas pessoas são ruins em estimativas, mas na maioria das vezes, os fatos completos não são conhecidos no momento. Idealmente, isso deveria ter sido coberto no refinamento ou captado cedo pela OP, mas às vezes eles podem passar rapidamente. Os desenvolvedores devem se esforçar bastante, pois podem facilmente torpedear um sprint que está indo bem.

Não, essa não é uma forma reconhecida de Agile , por um motivo muito importante: se você está comprometendo-se a entregar tudo , não está fazendo Agile, está fazendo o Waterfall - e se pensa que está agindo em vez disso , provavelmente você está mal no Waterfall . Tenho certeza que você já ouviu a serra velha "bom, rápido, barato, escolha duas", certo? Com o desenvolvimento de software, é mais como "todos os recursos entregues dentro do prazo e do orçamento, escolha o primeiro ou os outros dois". O Waterfall escolhe o primeiro e o Agile, o segundo.

Se você for ágil, precisará da flexibilidade de retirar as histórias do Sprint que não é possível concluir a tempo. Uma maneira possível de fazer isso é solicitar ao Dono do produto que avalie as histórias usando a priorização do MoSCoW. Isso envolveria a seleção de não mais que 60% das histórias (pelo total de pontos da história) como pontos de preenchimento obrigatório que serão concluídos, 20% como pontos de preenchimento obrigatório que você deve concluir no projeto e o Produto mínimo viável for lançado, 20% como Os Haves poderiam ser concluídos se você tiver tempo e qualquer coisa fora do escopo da versão atual como Waves Haves. Também é importante observar que, quando combinados, os Must Haves devem ter carne suficiente até os ossos para criar o Produto Mínimo Viável, sem a necessidade de incluir itens de outras categorias.

Determinar se os itens do Droplog do Sprint Backlog devem ou não ser descartados é de responsabilidade do Dono do Produto, após ter sido solicitado pela Equipe, e quaisquer itens que forem retirados do Backlog do Sprint serão avaliados pelo Dono do Produto e, em seguida, serão retirado inteiramente do projeto ou colocado no Backlog do Projeto em uma posição adequadamente classificada.

Nesse caso, acho que seu Dono do Produto é seu Gerente de Projeto, certo? Seria o trabalho dele determinar quais tarefas abandonar, então ele certamente não deve culpá-lo por se comprometer demais, pois seria o trabalho dele abandonar as tarefas para compensar isso, e parece que ele não está fazendo isso.

Ele está certo, de que não deve haver transferência entre os sprints. As equipes do Scrum tendo uma transferência entre sprints é um antipadrão e não algo que o Scrum canônico aceita como resultado válido.

Mas, sua abordagem não é boa.

Durante um sprint, a equipe deve monitorar constantemente o trabalho que está sendo feito e se eles podem manter seu compromisso de planejar o sprint sobre o término de histórias selecionadas. Se a equipe identificar que não pode terminar todas as histórias, ela deve se encontrar com o PO e selecionar uma história para remover do sprint. Ao fazer isso, todos param de trabalhar na história e se concentram em concluir as histórias restantes. Lembre-se: é sempre melhor terminar uma história completamente do que ter duas histórias pela metade.

Os problemas de dependências externas e estimativas imprecisas são exatamente o motivo de existirem retrospectivas. Durante o Retro, a equipe deve refletir e identificar esses problemas. E a equipe deve encontrar e implementar soluções para esses problemas. As estimativas podem ser feitas com mais precisão, conhecendo melhor o sistema e a experiência simples. Dependências externas são mais difíceis, mas não impossíveis de corrigir.

Seu PM (o que a PM está fazendo em uma equipe Scrum ?? ) não deve ser permitido pelo Scrum Master para forçá-lo a terminar todas as histórias. Em vez disso, se ele se queixar, deve mantê-las para Retrospectiva. E melhor ainda, deve fazer parte da solução dos problemas que impediam que as histórias fossem concluídas no prazo.

É uma variação aceitável / comum do Scrum que eu não conheço?

Não . Está completamente errado. Talvez eu pudesse simpatizar com horas extras pagas , se o OP cometer o erro de fornecer as estimativas como fatos antes do final do sprint, mas as horas extras não remuneradas são completamente ridículas e me fazem procurar outro emprego o mais rápido possível.

Como você sugere que eu devo agir sobre isso?

Na minha experiência, as pessoas que são parte do trilho não ouvem argumentos lógicos. A única maneira de ver como está quebrado é mostrar , não contar. Portanto, da próxima vez que você estimar e confirmar, comprometa-se com a menor quantidade possível . Comprometa-se a terminar um pequeno tíquete até o final do sprint. Um que você poderia fazer em um dia. Veja como o seu PM reage. Em seguida, inicie uma discussão a partir de onde o sistema é usado e para que o sistema deve ser usado.

Geralmente, no início do projeto, quando decidimos a velocidade da equipe, optamos por um número conservador (mais baixo do que o habitual), considerando o fato de ser uma nova equipe, levaria um tempo para a equipe se acalmar. , entender-se, entender os requisitos funcionais e de NFR etc. Basicamente, após os primeiros sprints, otimizamos a velocidade da equipe e, obviamente, a velocidade só melhorará a partir desse ponto.

Não faz sentido comprometer uma velocidade mais alta no início e esticar a equipe para alcançá-la.

Mais uma coisa é que, em um cenário pontual, em que há um compromisso de entrega que não pode ser esquecido, os gerentes de projeto podem pressionar a equipe por alongar, trabalhar até tarde e trabalhar nos fins de semana. Mas isso deve ser considerado uma exceção e não a norma do trabalho. Trabalhar dessa maneira pode aumentar a velocidade a curto prazo, mas a longo prazo seria contraproducente, pois poderia resultar em problemas de qualidade do código, problemas de esgotamento da equipe, equipe infeliz com baixa motivação etc.

Perguntas frequentes sobre compromissos

Esse comportamento é normal?

Não tenho certeza.

Isso é surpreendente?

Não. Algumas pessoas sempre entenderão "compromisso" como significando que tudo no compromisso deve ser concluído.

É uma boa ideia?

Não. O desenvolvimento ágil tem a sustentabilidade como um tópico central: trabalhe apenas o máximo / longo / duro que puder fazer indefinidamente. Essa é uma ideia sensata na maioria das vezes. (Se seu gerenciamento não aceitar isso, eles não deverão chamar a organização de forma ágil.)

O que deveríamos fazer?

• Explique que o conteúdo do sprint é baseado em uma estimativa . "Estimativa" significa que apenas algumas vezes estará correto - e geralmente estará errado. Quando está errado, às vezes é muito baixo e às vezes é muito alto.
• Explique que é muito mais fácil alterar o comportamento das estimativas do que a velocidade do trabalho.
• Explique aos alunos que, quando a equipe é punida por estimar muito alto, ela estimará mais baixo e o gerenciamento perderá muito mais progresso dessa maneira do que empurrar parte do conteúdo de um sprint para o outro ocasionalmente.

O bom é: O gerente de projetos já saberá todas essas coisas e as reconhecerá como certas. Só que , a curto prazo, pode-se preferir ignorá-los.

Não concordo com sua equipe de gerenciamento. Eles não deveriam ter feito você fazer horas extras para terminar o sprint.

No entanto, a ideia de que compromissos não são possíveis vem de um mal-entendido sobre desenvolvimento de software. Eu já vi muitas equipes tentarem prever as histórias que eles podem completar em um sprint pelo número de pontos que eles completaram em sprints anteriores. Se isso fosse possível, diria que o desenvolvimento de software é linear, ou seja, se trabalho duas horas, faço o dobro do que em uma hora.

O desenvolvimento de software é criativo e, portanto, não linear. É uma prática melhor para a equipe contar à gerência o que eles podem fazer em um sprint e depois entregar essas histórias. Se você está constantemente perdendo seus compromissos, você não tinha idéia do escopo da história para começar ou está sendo pressionado pelo proprietário do produto a assumir mais.

No primeiro caso, certifique-se de entender o escopo da história antes de concordar em prosseguir. Se for o último, você tem um problema de cultura e há pouco que pode ser feito.