É um grande aumento na velocidade realista em um ambiente Scrum?

Bem, é perfeitamente simples aumentar a velocidade em 40% - basta adicionar 40% mais pontos a todas as suas estimativas e fazer a mesma quantidade de trabalho.

Dado que é assim, deve ficar claro por que usar velocidade como alvo está errado, apenas encoraja estimativas infladas.

Uma resposta menos simplista é que sua estimativa já pressupõe que você está indo o mais rápido possível enquanto faz tudo corretamente. A única maneira de realmente aumentar a produtividade em 40% é trabalhar horas extras ou não fazer tudo corretamente. Ambas agilizam as coisas a curto prazo, mas retardam as coisas a longo prazo. E o longo prazo, neste caso, não é muito longo, um mês no exterior. A estratégia ideal a longo prazo é nunca ir mais rápido do que o seu ritmo sustentável.

Peopleware fala de forma eloquente sobre as questões de tentar forçar os programadores para uma maior produtividade, e é um clássico frequentemente citado . Mas, em geral, não será fácil mudar a mente de um gerente que está seguindo o caminho que o seu é. Seu projeto pode estar em apuros - isso é certamente uma bandeira vermelha.

Como os comentários apontaram, o pedido está obviamente errado da maneira como foi colocado. Mas ele não está realmente errado em querer melhorar constantemente a produtividade. Como regra geral, é para isso que os gerentes se esforçam (e são avaliados).

Dito isso, os gerentes estão sempre procurando melhorar o desempenho, e o Scrum e o Agile são adaptáveis. Enquanto a velocidade é uma medida do seu atual ritmo sustentável, você não deve se recostar em seus louros. O Scrum tem um lugar para avaliar e mudar o que funciona e o que não funciona no seu processo: a retrospectiva. Se você tirar vantagem disso e ajustar seu processo, a produtividade (e possivelmente a velocidade) deve aumentar.

Então, você está procurando (em suas retrospectivas) maneiras de se tornar mais produtivo como um time? Existe alguma coisa em seus sprints que consuma regularmente uma quantidade desproporcional de esforço? Pode ser endereçado? Provavelmente não vai te dar um aumento de 40%, mas 5-10% é um começo, não? A cada sprint você deve procurar por gargalos e resolvê-los. Eventualmente, você pode chegar perto do objetivo que ele estabeleceu para você.

TL; DR

A velocidade é muito útil para estimar horários ou gerar valores de planejamento e também pode ser um controle detetive significativo para avaliação de gargalos de processo ou mudanças na capacidade da equipe. Não é, no entanto, uma medida válida de produtividade.

Quando a velocidade está confusa com os alvos de gerenciamento

"Velocity" é um intervalo que expressa a capacidade média de uma equipe em algum período histórico. É uma análise estatística do desempenho passado, que pode então ser usada para projetar estimativas probabilísticas de capacidade de carga de trabalho futura ou tempos de ciclo. Isso está em contraste absoluto com um "objetivo de programação", que é um objetivo gerencial que define um cronograma ou uma meta para propósitos de planejamento.

Os experientes gerentes de projeto ágil sabem que o uso adequado da velocidade é determinar se uma equipe tem a capacidade sustentável de atender às metas de programação definidas pelo gerenciamento. Às vezes a resposta é sim e todos estão felizes. Às vezes, a resposta é não. Nesse ponto, o triângulo de ferro força as decisões de negócios sobre escopo, custo, tempo e qualidade. / p>

Avalie suas opções políticas

We have an average velocity of 50 story points...I have been asked to increase it by 40% to 70 story points (with no increase in team members).

Supondo que suas práticas de estimativa sejam sólidas e que sua velocidade seja razoavelmente estável, seu gerente não terá prazer em ajustar a escala estimada ou definir metas de gerenciamento que não sejam baseadas no desempenho histórico. Como você apontou corretamente, isso é fundamentalmente um problema capacidade .

O limite de capacidade pode estar relacionado ao número de pessoas da sua equipe ou pode ser uma limitação dos seus processos organizacionais. Claro, adicionar mais pessoas nem sempre adiciona capacidade real de projeto; veja a Lei de Brooks para saber mais sobre esse equívoco comum.

O problema você é político. A partir do tom do seu post, parece que o seu gerente quer ver um aumento na produtividade sem fazer nenhuma alteração real na capacidade subjacente da equipe. As soluções são, portanto, também políticas, e em grande parte educacionais por natureza.

Se você é um Scrum Shop, peça ao seu Scrum Master para resolver este problema através dos canais apropriados do framework. Backlog Grooming e Sprint Retrospectivas são muitas vezes as oportunidades ideais para inspecionar e adaptar-se a este assunto específico.

Se você não é um Scrum Shop, você deve decidir qual a maneira correta de resolver suas preocupações dentro de sua organização. Se você está em boas relações com o seu gerente, você pode até emprestar uma cópia do Agile Estimating and Planning para vocês dois discutirem durante o almoço.

Se tudo mais falhar, prepare-se para uma marcha da morte escovando seu currículo e fazendo sua melhor profissional até o projeto implodir. 68% dos projetos de TI falham ; a menos que as metas de gestão estejam solidamente fundamentadas na capacidade organizacional, provavelmente a sua será uma delas.

Eu não estou entendendo qual papel seu gerente tem na equipe Scrum? Ele é um treinador? Ele é dono de produto?

Se ele está dentro da equipe como um treinador ou tal (ele trabalha em uma tarefa de desenvolvimento) você pode perguntar por que ele subestima sua própria produtividade, porque parece que não era o caso para outros membros da equipe. Se ele acredita que pode assumir pessoalmente 30 pontos de história a cada iteração, mostre-o.

Mais provável: ele está fora da equipe, talvez o dono do produto? Se assim ele deve entender fazendo um pedido tão estúpido, ele simplesmente parou de agilidade.

Uma regra básica é que o proprietário do produto define a meta enquanto a equipe define o que pode ser feito em uma iteração. Não fazê-lo leva ao clássico e conhecido círculo de ferro: recursos, velocidade, características. Escolhe dois! Você não pode escolher três deles de uma vez (e lembre-se: a qualidade não é uma variável de ajuste, tentar reduzir os cantos com baixa qualidade tornará as coisas ainda piores).

Se ele não quiser mudar a meta atual, talvez um aumento de 40% na produtividade possa ser alcançado com o recrutamento de mais pessoas para a equipe? Talvez investir em algum treinamento avançado para alguns membros da equipe? As equipes também podem ganhar velocidade ao longo do tempo por meio da melhoria contínua, mas certamente não por decisão arbitrária.

Tentar mudar a velocidade de uma equipe é como tentar mudar o tamanho de uma sala. Isso pode ser feito, mas basicamente você precisa mudar a sala.

Você não tem algum Scrum Master, ou algumas outras pessoas com um entendimento básico do Scrum que poderia explicar isso a ele?

Neste caso, o gerente virou a direção errada depois de obter uma estimativa honesta e fiel da equipe. O gerente deve se dirigir ao stakeholder e informá-lo de que seus requisitos não podem ser concluídos no tempo solicitado. O gerente / analista deve, então, priorizar quais dos recursos devem ser incluídos e os outros que podem esperar (se apenas algumas semanas). Se a parte interessada não for razoável, pode ser necessário que os gerentes se envolvam mais, o que geralmente pode ser desafiador e exigir um outro conjunto de discussões.

Se eu estivesse no seu lugar, eu apresentaria um caso detalhado de por que o projeto IS vai durar o tempo estimado. Também tente identificar itens de baixo retorno. Encontre os itens que não agregam muito valor e exigem esforços substanciais de programação e defende a remoção daqueles do sprint. Desenvolva também uma abordagem iterativa que forneça "X" na data "Y" e certifique-se de que é viável, em seguida, crie uma iteração de acompanhamento que lhes permita obter os itens restantes.

Basicamente, alguém precisa dizer ao stakeholder o que ele pode esperar receber dentro do prazo e que ele inclui a maioria de seus requisitos. e que pelo lançamento seguinte eles terão os itens restantes. Se o cliente não é razoável, então a alta gerência precisa estar envolvida, o gerente deve poder fazer isso acontecer.

No entanto, se o cliente foi prometido, e ninguém falou até agora, será uma batalha difícil. Esta não é uma situação incomum, infelizmente.

Parece que você enfrenta dois problemas.

A parte sobre medir a velocidade que incomoda é provavelmente a medida que é o custo . O que você realmente quer melhorar é o valor . Infelizmente, medir o valor do software é notoriamente difícil e subjetivo. Ainda assim, até mesmo uma métrica imperfeita e subjetiva pode ser útil. Pode ser que a verdadeira questão não seja que sua equipe precise escrever mais código, mas que as histórias precisam ser mais valiosas.

O outro problema é que, com base na sua conta, seu gerente esperava um aumento de 40% na produtividade. Não foi indicado na sua pergunta o contexto deste pedido. Pode ser um desejo bem-humorado, se desejar, melhorar sua equipe. Ou pode ser uma indicação não tão sutil de que seu gerente acredita que sua equipe está com desempenho ruim.

edit: Com base no seu comentário, a situação parece ruim. Parece que sua empresa está preparando o terreno para demitir você e sua equipe (talvez seu gerente também). Eu sugiro que você procure outro emprego.

demiti-lo. Ou seja, passe por cima de sua cabeça e explique que ele perdeu toda a confiança de sua equipe e explique que não tem valor para o negócio. Explique que os gerentes com esse nível de incompetência são muito mais fáceis de substituir do que a equipe abaixo.

Não há uma boa razão para colocar-se com tal gerente, mas isso não deve significar automaticamente que os desenvolvedores devem renunciar. Não há necessariamente algo errado com o negócio, apenas com esse indivíduo. Corrigir esse problema.

E para evitar qualquer problema da alta gerência, deixe claro que isso não é um erro perdoável. Isso sinaliza que o gerente responsável tem não entendimento da equipe que ele está gerenciando. Isso não se presta à fixação, nem há necessidade no atual mercado de trabalho. Os gerentes são eminentemente substituíveis como treinadores esportivos. Os proprietários não disparam equipes.

Agora, isso pode parecer uma estratégia que pode sair pela culatra. Mas considere: se a alta administração se posicionar com seu gerente, independentemente, você já estaria em uma posição perdedora de qualquer maneira. Então, se você considerar apenas as situações em que você ainda não está nessa posição perdida, o resultado provavelmente será muito mais positivo. O risco real é que a alta administração apenas ative toda a equipe, incluindo o gerente. Só você pode estimar esse risco. Aparentemente, sua saída é desejada, senão eles não pediriam mais, mas a que preço?

Minha experiência é que tem sido muito, muito difícil aumentar a velocidade real de uma equipe, dado que nem a equipe, o domínio do problema ou a pilha de tecnologia mudam.

Onde consegui aumentar, tem sido uma questão de:

• limpando dívida técnica; garantindo que tudo esteja rodando a versão correta (não necessariamente a mais recente!), que o código é bem fatorado e que não há redundância no sistema (código duplicado, código não utilizado, etc.)

• aprimorando práticas; emparelhamento sempre que possível (sim, descobri que aumenta a velocidade), tendo tempo para refatorar agressivamente (idem!) e ser impiedoso quanto ao escopo e foco

• encontrar e / ou comprar as melhores ferramentas para o trabalho (por exemplo, o ReSharper for .NET vale seu peso em ouro, Airbrake e Splunk para desenvolvimento em Ruby, etc.)

Concordo com outras pessoas que dizem que seu gerente pedindo um aumento arbitrário de velocidade é uma bandeira vermelha. Eu estaria procurando outro emprego como alta prioridade.

Seu gerente está pedindo (ou dizendo) à sua equipe que trabalhe horas extras. Embora a remoção de gargalos e a obtenção de ganhos de eficiência possam melhorar um pouco sua velocidade, a única maneira de obter esse aumento (40%) é trabalhar mais horas, porque você precisa colocar mais unidades de trabalho nesse período.

Vamos dar uma ideia.

Para uma interação de duas semanas, digamos 10 dias. Utopia seria de 8 horas por dia, com um ponto de história sendo abstraído para um dia de trabalho. Então, de cima, a sua velocidade seria 8. Mas, relisticamente, as pessoas provavelmente estão recebendo em 6 boas horas por dia com e-mail, reuniões, intervalos de casa de banho, etc Então agora você está em um 6 por desenvolvedor. Então sua linha de base é 6. Vamos dizer que você quer que as pessoas trabalhem horas extras, agora às 10 horas por dia. Então, isso seria 10 pontos de velocidade por desenvolvedor.

Sua velocidade sempre flutuará, talvez tenha sido baixa porque você teve que lidar com muitos bugs durante essa iteração, talvez os requisitos estivessem faltando, talvez alguém tenha ficado doente por alguns dias. Talvez tenha sido alto porque o trabalho foi superestimado ou sua equipe colocou horas extras.

Mas se você estiver em um estábulo de 50, realmente para chegar a 70, precisará de horas extras.

O problema com a velocidade é que ela é uma variável dependente, uma saída medida do seu processo de desenvolvimento. Exigir aumentar a velocidade 40% é como tentar chegar ao trabalho mais cedo, gritando para os carros irem mais rápido. A velocidade aumenta, alimentando mais combustível e ar no motor ou obtendo um carro mais rápido, além de encontrar uma rota com menos tráfego.

Trabalhar mais horas não aumenta a velocidade se você as medir corretamente, digamos, em pontos de recurso por hora do desenvolvedor. Só funciona se você medir pontos por dia e, em seguida, redefinir o que é um "dia" na medição média. Isso fornece apenas a ilusão de velocidade.

Um aumento na velocidade requer melhorar as variáveis independentes no processo de desenvolvimento; computadores e compiladores mais rápidos, sistema de compilação mais eficiente, melhor processo de design, desenvolvedores mais capacitados, melhor espaço de trabalho, motivação super-duper. Uma melhoria de 40% exigiria mudanças muito significativas.

Pergunte se o seu gerente consideraria colocar a sua equipe em escritórios fechados em torno de uma sala de trabalho comum, comprar o novo hardware do time ou contratar alguns desenvolvedores realmente sêniores para orientar a equipe, se isso lhe daria 40 pontos. %. Se não houver recursos disponíveis para melhorar as entradas para o seu processo de desenvolvimento, isso praticamente elimina o interesse sincero em melhorar. Isso deixa a engenharia reversa do seu gerente para descobrir o que realmente está motivando-o, o que seria o assunto de todo um segmento diferente.

Bem, estou um pouco surpreso que as outras respostas levem o pedido do chefe a sério. Alguém que exige um aumento de 40% na produtividade não sabe nada sobre desenvolvimento de software.

Eu ainda gosto de ler Phil Factor sobre esse assunto:

There are two basic routes into IT management. You can learn your trade through blood, sweat and tears and work your way up the ladder gradually, based on the credibility you've gained from hard-earned technical know-how and successful projects. Alternatively, you can don a sharp suit and tie, learn the lingo, and smooth talk your way to the top.

Both routes seem equally effective. Dealing with the latter breed can certainly cause some moments of dismay and incredulity… despair even… and some of that is documented in these stories.

However, it's easy to become sad and embittered when one encounters technical incompetence in positions of power, and to tar all managers with that same brush. Phil advises against it. Most managers work hard and contribute well to the company, and even poor managers can be trained up to the required standard, if you just follow a few simple guidelines. It's part of your team responsibility to help your manager function in a way that will benefit all.

Ultimately, if you can't train them, get them promoted, or avoid them, maybe you can learn to love them just for their unintended contribution to the rich comedy of the workplace.

O conselho de não ficar "triste e amargurado" é o melhor que você pode conseguir. Não lute contra um chefe tecnicamente incompetente em questões técnicas. Ele só vai ver isso como um ataque pessoal.

Seu gerente entendeu mal o uso da velocidade. Não é uma métrica e não é um alvo. Sua finalidade é a calibração da carga de trabalho da equipe por sprint.
Se você pensar sobre isso, sua velocidade emerge de um melhor palpite, que você repassa após cada sprint. Normalmente, com o passar do tempo, deve se tornar um pouco estável. Mas isso não muda o fato de que é um subproduto do que sua equipe está realmente fazendo: criar valor para seus clientes.

A razão pela qual é errado usá-lo como um alvo e / ou uma métrica é porque isso tornaria uma métrica de vaidade. Ficaria bem no papel, mas não faria absolutamente nada para refletir se os seus produtos estão satisfazendo as necessidades de seus clientes. E isso é o que é mais importante (espero).

Com relação à minha experiência e indo direto ao assunto.

Primeiro, você pode inflar a estimativa, mas isso não significa que você está fazendo mais.

Segundo (premissa: sem inflar, apenas focando na velocidade da equipe),

Tente encontrar as habilidades dentro de sua equipe. Eles estão trabalhando no que são melhores? Você precisa de um arquiteto de sistemas para tomar as decisões difíceis em relação à construção do aplicativo e às coisas complexas? Como a equipe está gastando seus esforços? Eles estão gastando tempo pesquisando soluções para seus problemas, refatorando, tomando decisões de negócios ou o quê?

Eles são confortáveis, focados e estimulados? O que está acontecendo com eles?

Isso não é "eu sou empurrado para os limites" ... é mais como uma pergunta para todo o time "Estamos nos limites?" e "Como podemos forçar os limites?" ...

Tenho equipes de alto desempenho (para a primeira construção e / ou migrações) ... a motivação da equipe é a chave do sucesso ... e planejar como a base da aplicação deve ser essencial. Às vezes, eu ou um colega de equipe assumimos o papel de arquiteto de sistemas e decidimos como e onde a "coisa" deveria ir.

Às vezes, quando vejo que meus colegas de chá estão perdendo a eficiência, tento interromper e convidá-los para sair para tomar uma cerveja ou algo de que gostem. Isso resolve qualquer conflito e no dia seguinte eles estão concentrados novamente.

VENDENDO ...

Se explicar as razões pelas quais você não pode aumentar a velocidade é difícil, use o ROI.

Scrum foca no que é mais importante para o cliente. Teoricamente as tarefas mais rentáveis.

Se os seus problemas estão relacionados com a venda do esforço de desenvolvimento, o que você acha que vende o que é o ROI do esforço de desenvolvimento, em vez disso, converte diretamente os pontos da história para o "preço". Se você puder comprovar que sua equipe trabalha com um ROI alto, quem vai questioná-lo? Além disso, cada equipe tem seus limites se a equipe encontrou seu "tamanho de conforto", tente um pouco a cada mês, se eles não conseguissem concluir todas as tarefas, este (provavelmente) seria o limite.

Mostre o histórico das tarefas, a receita de lucro (se disponível), o ponto da história que você usou e mostre que a PRODUTIVIDADE NÃO É O ESFORÇO DA EQUIPE é um cálculo determinado pela equipe para avaliar a complexidade e talvez o tempo fazer algo ser feito