O gráfico de burndown do Scrum Sprint e a estimativa de trabalho do Scrum, bem como os fatores de conto

Qual pode ser a melhor maneira para os gerentes de tarefas orçamentar e alocar o tempo que os membros do grupo têm para gastar na tarefa? Dependendo de como o empreendimento provavelmente será gerenciado - usando práticas padrão ou técnicas de gerenciamento ágil, por exemplo - determine se a capacidade deve ser considerada em termos de horas (tempo) ou problemas estimados (trabalho).

No gerenciamento de projetos tradicional, os gerentes estimam a capacidade de trabalho de um membro da equipe de acordo com o planejamento do grau de processo. Ou seja, eles estimam quanto tempo eles esperam que tarefas específicas levarão para serem concluídas e, em seguida, atribuem tarefas estabelecidas no tempo total disponível do membro da tripulação, aplicando ferramentas tradicionais como gráficos de Gantt.

O problema com esse método é que ele pode se prestar ao gerenciamento no grau de membro da equipe, não no grau de tarefa. Ou seja, o gestor do empreendimento pode acabar se concentrando demais em manter homens e mulheres ocupados e microgerenciar cargas de trabalho individuais, em oposição ao sucesso geral com o empreendimento que está sendo produzido e também o valor que ele gera para o consumidor. Na melhoria de novos desafios complexos, como equipes de programas de software,

Scrum, uma estrutura comum de gerenciamento de empreendimentos produzida pelos gurus ágeis Ken Schwaber e Jeff Sutherland, adota uma perspectiva drasticamente diversa para determinar como você pode rastrear e relatar o status do empreendimento. Em vez de tentar manter os membros da equipe ocupados, ele se concentra no incremento de produtos ou serviços despacháveis ​​a cada sprint ou cadência de operação. (Ou seja, em última análise, coloca o foco no cliente, preferindo saber que o comprador recebe o que pediu, em vez de manter os membros do grupo ocupados). coisas de estimativa baseada.

Como funciona essa prática de estimativa? Em uma reunião em que o chefe/gerente de projeto está ausente, as equipes estimam em números abstratos para quantificar o trabalho relativo relacionado a uma conta distinta (uma aventura geralmente é composta de várias tarefas). Algumas equipes usam tamanhos numéricos (ou seja, uma escala de 1 a 10) para estimar o "tamanho" de uma conta, enquanto outras usam tamanhos de camisetas (XS, S, M, L, XL, XXL, XXXL).

Alguns usam a sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc.) para capturar como a dificuldade tende a aumentar exponencialmente. Outras equipes utilizaram raças de cães para fins de estimativa, nas quais, digamos, um poodle ou Chihuahua representaria as menores histórias e também um Wonderful Dane ou Bull Mastiff representariam as maiores. O que é significativo para a estimativa de esforço é que a equipe compartilha um entendimento sobre a escala que pode estar empregando, de modo que cada pessoa se sinta confortável usando os valores da escala.

Embora o gerente de desafios (ou Proprietário do Produto ou Serviço, no Scrum) exija essas estimativas para priorizar efetivamente os itens do backlog e, consequentemente, prever a entrega do produto ou serviço que está sendo criado determinado pela velocidade, somente a equipe pode fazer essas estimativas e também o a presença do gerente do empreendimento/vendedor do produto pode pressionar (intencionalmente ou não) uma equipe para minimizar suas estimativas de esforço. Mesmo quando os membros do esquadrão estimam entre si, sugere-se que todos revelem sua estimativa ao mesmo tempo para evitar influenciar os outros. Essa prática se assemelha a um jogo de pôquer em que os indivíduos "mostram suas mãos" - ou revelam suas estimativas - simultaneamente.

Gerentes de negócios convencionais podem se sentir desconfortáveis ​​com uma estratégia de gestão que não lida com a exatidão de orçamentar horas para tarefas. Mas os procedimentos ágeis de gerenciamento de tarefas, como Scrum, na verdade, os gerentes de suporte se concentram no que realmente importa na melhoria: a conclusão bem-sucedida do empreendimento e também um consumidor que ama o produto que seu grupo criou.


O gráfico Burndown do Scrum Sprint

Usamos soluções de desenvolvimento de aplicativos Agile e, para gerenciamento de projetos, o Scrum é nossa técnica preferida. Nossa equipe de desenvolvimento depende do exterior e você encontrará desafios para criar uma função Agile com uma equipe distribuída, mas isso pode ser realizado (e também pode ser divertido!). Então eu pensei em compartilhar uma aventura com você 1 de nossos Sprints reais, conforme relatado através do gráfico de Burndown do Scrum. Por quê? Muito bem, já que acho que podemos entender um ótimo negócio do gráfico Burndown e todas as pessoas têm sua própria conta para contar. Aqui está o nosso:

Para definir o cenário, meu esquadrão Scrum se reuniu (praticamente desnecessário dizer) para planejar a próxima iteração de nossa função desenvolvendo um programa de processamento de pedidos de vendas de produtos sob medida para uma organização principal de serviços públicos do Reino Unido. Sabíamos quais histórias de usuário o Proprietário de item do cliente queria neste Sprint e, por isso, sentamos, listamos os trabalhos necessários para desenvolver as histórias de usuário e estimamos em horas quanto tempo cada um deles levaria. Esta estimativa inicial saiu em 90 horas.

Já tendo passado por alguns Sprints, tivemos uma boa idéia da velocidade da equipe e informamos ao Operador de Produto ou Serviço que isso era demais para totalizar dentro da iteração normal de 2 semanas. Por outro lado, dada a importância desta funcionalidade para o cliente, e para manter o ímpeto até o período de Natal, foi excepcionalmente acordado que este Sprint fosse executado por mais tempo do que o normal.

Tudo começou bem e grandes progressos foram criados, na verdade estávamos adiantados. Então, alguns dias depois, 1 com o grupo percebeu que um trabalho adicional era essencial para totalizar apenas um nas histórias do usuário - então isso foi documentado, estimado e adicionado ao Sprint Backlog. Isso aumentou as horas restantes estimadas em mais 16 horas e assim o gráfico Burndown seguiu para o norte.

Dentro de alguns dias, mais um incidente inesperado ocorreu. O governo britânico anunciou uma redução na alíquota do IVA (imposto sobre vendas de produtos) e, como o programa que construímos para nosso cliente é muitas vezes um programa de processamento de pedidos de receita, que inclui cálculos de preços e faturamento, sabíamos que essa mudança estatutária precisaria sejam tratadas como uma questão prioritária. Agora, somos uma equipe pequena (o que a equipe Agile não é) e rapidamente percebemos que todas as operações de desenvolvimento atuais precisariam ser suspensas para fazer essa mudança crítica.

Então estacionamos este Sprint e trabalhamos por meio da semana e do fim de semana para entregar com sucesso a mudança do IVA pronta para a data de implementação uma semana após o anúncio do Governo. Como resultado, nosso gráfico Burndown ficou estável por uma semana. Portanto, percebemos que isso afetaria nossa data de entrega estimada e começamos a analisar uma janela de conclusão revisada para este Sprint.

No entanto, antes que pudéssemos somar isso, o próximo obstáculo apareceu na nossa frente. O desenvolvedor que havia escolhido um novo emprego percebeu que era mais complexo do que havíamos estimado originalmente; como resultado, o esforço restante aumentou em mais 36 por muito tempo, levando a outro pico ascendente em nosso gráfico e, naturalmente, mais atraso na entrega deste Sprint. Então, novamente, de acordo com a velocidade da equipe, nós reestimamos e saímos com uma janela de conclusão revisada.

Agora, eu já posso ouvir alguns de vocês especialistas em Scrum gritando comigo. Certamente nós realmente deveríamos ter time-boxed a iteração e não estendê-la? Quando caímos em uma nova tarefa, devemos ter procurado o Proprietário do Produto ou Serviço para remover algo em compensação para entregar no Sprint?

E tudo isso é verdade - em um mundo Scrum ideal, é isso que faríamos. Mas, conhecemos bem nosso cliente, temos um excelente relacionamento com ele e sabíamos o quanto era crucial para ele ter essa funcionalidade antes do Ano Novo. Então eu dobrei as regras do Scrum para acomodar suas necessidades. Agora, antes de ser expulso da gangue Scrum, não devemos perder de vista os valores do Scrum:

* Esteja disposto a se comprometer com uma meta.

* Faça seu trabalho. Concentre todos os seus esforços e habilidades em fazer o desempenho que você se comprometeu a fazer.

* Não se preocupe com mais nada.

* Scrum mantém tudo sobre um empreendimento visível para todas as pessoas.

* Tenha a coragem de se comprometer, de agir, de se abrir e esperar respeito.

Agora, eu vou aceitar que nós dobramos um pouco as regras de Iteração, mas foi por boas razões. Enfrentamos algumas mudanças inesperadas ao longo do Sprint. Mas fomos abertos e honestos com o cliente e pudemos usar o gráfico Sprint Burndown para mostrar rapidamente ao Operador de Produto ou serviço o impacto da mudança e obter sua aprovação para prosseguir.

Mais importante, mantivemos o controle e mantivemos a ordem no que poderia ter sido um caos.

Critérios de Aceitação do Scrum
Antes de um Proprietário de Mercadoria considerar a operação de uma equipe "pronta/pronta/pronta", ele sempre consultaria os critérios de aceitação da história de usuário correspondente. No método Scrum de avanço ágil de pacotes de software, os critérios de aceitação são os requisitos que devem ser atendidos para que uma conta seja concluída.

Os critérios de aceitação são cruciais para o sucesso do gerenciamento do Scrum devido ao fato de comunicarem claramente as expectativas de um proprietário de produto ou serviço, bem como as metas de desenvolvimento de uma equipe de uma só vez. Não há área cinzenta. Qualquer integrante do elenco, a qualquer momento, pode consultar os critérios de aceitação de uma história e ter a certeza de que, se os requisitos listados forem cumpridos até o final do sprint, a equipe receberá o crédito por sua função.

Mas o que acontece quando apenas alguns – ou mesmo a maioria – dos critérios de aceitação de uma história são atendidos? O esquadrão recebe uma porcentagem correspondente nas coisas do conto para a fração de operação que eles completaram?

A resposta simples é não. O Scrum desencoraja os Proprietários de Mercadoria de conceder crédito parcial ao trabalho que certamente, apropriadamente, foi apenas parcialmente concluído. Todos os critérios devem ser atendidos ou a operação é rejeitada como incompleta. Na verdade, muitos ScrumMasters não permitem que as equipes apresentem o trabalho que não foi concluído.

Por que o Scrum promove essa visão de tudo ou nada do progresso? Você vai encontrar uma série de razões para isso. Em primeiro lugar, um critério de aceitação implícito de qualquer aventura é que ela deve ser concluída dentro do sprint. Simplesmente porque a operação está confinada aos limites de um sprint, uma equipe deve respeitar esse prazo para que sua função seja considerada satisfatória.

Em segundo lugar, as equipes geralmente descobrem que o último por cento da operação a ser concluída - o impulso final do sprint - é desproporcionalmente trabalhoso e demorado.

Coloque mais uma maneira, até que seja feito, não é realizado. Por fim, conceder crédito por operação incompleta resulta em inflação de velocidade. Quando o Vendedor de Itens de uma equipe concede crédito por trabalho incompleto, a equipe A velocidade de s não é mais uma métrica confiável e, portanto, não tem valor para previsão.

Além disso, quando uma equipe recebe crédito por um histórico que realmente precisa terminar no próximo sprint, isso significa que o próximo sprint inclui um desempenho adicional que não é contabilizado no backlog do sprint. Assim, um esquadrão deve ter um desempenho mais difícil para compensar. Sem surpresa, essa prática geralmente leva uma equipe a ficar cada vez mais para trás, acumulando uma dívida técnica substancial ao longo do caminho.

Claramente, é vantajoso tanto para o Vendedor do Produto quanto para a equipe conceder crédito apenas quando ele puder ser totalmente obtido. Filosoficamente, reforça os princípios de transparência e comunicação aberta do Scrum e, na prática, permite previsões precisas e evita dívidas técnicas.