Um grande aumento de velocidade é realista em um ambiente Scrum?

89

Meu gerente recentemente realmente pressionou para usar a velocidade como objetivo e medida de produtividade. Atualmente, estamos trabalhando a uma velocidade média de 50 pontos da história. Meu gerente quer que aumentemos de 40% para 70 pontos da história (sem aumento de membros da equipe). Se não conseguirmos esse aumento, ele quer que façamos uma análise completa do motivo.

Toda a ideia de medir o desempenho da equipe pela velocidade e usá-lo como um alvo me parece errada, mas estou tendo dificuldade em explicar o porquê. Qualquer ajuda? Por que esse não é o caminho certo para medir e incentivar a produtividade?

P2l
fonte
19
Uau. o gerente não entende o que é velocidade ou pensa que a equipe está frouxa. ou ambos. Na próxima reunião de planejamento, comprometer-se a 70 pontos e deixar a equipe dizer-lhe os riscos de falha que vai causar
Steven A. Lowe
25
Parece um pedido tão insano, que eu gostaria que você perguntasse a ele por que ele acha que isso é possível - se você já está dando 100%, ele espera que você dê 140%? E se você apenas fizer sprints 40% mais longos?
9136 Jonathan Rich
20
Supõe-se que a velocidade seja uma medida de quão rápido você pode fazer as coisas. Se os seus pontos de velocidade e história são precisos, isso significa que você não pode concluir todo o backlog até o prazo final. A coisa racional a ser feita é aceitar a realidade e cortar as coisas da lista de pendências ou priorizar o que está lá para que o que você faça seja o mais importante. Ou você pode alterar o prazo para algo realista.
Michael Shaw
45
Peça a ele um aumento de 40% no salário se você atingir essas metas e aumente suas estimativas para obter o aumento de 40%.
mattnz
18
Não é como pedir a um corredor de maratona que repita a maratona em 1h25m em vez de 2h?
precisa saber é o seguinte

Respostas:

158

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 a velocidade como alvo está errado, apenas incentiva estimativas infladas.

Uma resposta menos simplória é 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. Ambos aceleram as coisas no curto prazo, mas diminuem as coisas no longo prazo. E o longo prazo, neste caso, não é muito longo, um mês no exterior. A estratégia ideal de longo prazo é nunca ir mais rápido que o seu ritmo sustentável.

O Peopleware fala eloquentemente sobre os problemas de tentar forçar os programadores a aumentar a produtividade e é um clássico frequentemente citado. Mas, em geral, não será fácil mudar de idéia de um gerente que está seguindo o caminho que é seu. Seu projeto pode estar com problemas - isso certamente é uma bandeira vermelha.

psr
fonte
28
Eu acredito firmemente que não há "rápido e sujo". "Sujo" sempre me deixa lento - mesmo a curto prazo.
Doc Brown
1
@ Paul - eu pensei que era bom. Mas o conselho contido na maioria só pode ser seguido pelos gerentes, e os que poderiam se beneficiar provavelmente não o lerão. Nem a leitura necessariamente mudará o comportamento.
Psr
2
E se você concorda e realmente aumenta a velocidade em 40%, parecerá para outras pessoas que você e sua equipe não estavam trabalhando da melhor maneira possível. A maneira profissional de lidar com isso é dar uma resposta direta: "Não, não posso fazer". Outra referência de livro sobre o assunto: "The Clean Coder", de Robert C. Martin.
Pablosaraiva 17/09/2013
1
"sua estimativa já pressupõe que você esteja indo o mais rápido possível enquanto faz tudo corretamente" Essa é provavelmente uma suposição incorreta. Sempre podemos continuar a melhorar e otimizar. As equipes nunca devem assumir que sua velocidade estável indica que não podem melhorar. Mas eles precisam olhar sistematicamente todo o processo e procurar pequenas melhorias no processo.
Curtis Reed
53

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, é para isso que os gerentes se esforçam (e são avaliados).

Dito isto, os gerentes estão sempre buscando melhorar o desempenho, e Scrum e Agile têm tudo a ver com serem adaptáveis. Embora a velocidade seja uma medida do seu ritmo atual e sustentável, você não deve se preocupar com os louros. O Scrum tem um lugar para avaliar e alterar o que funciona e o que não funciona no seu processo: a retrospectiva. Se você tirar proveito disso e ajustar seu processo, a produtividade (e possivelmente a velocidade) deverão aumentar.

Então, você está procurando (em suas retrospectivas) maneiras de se tornar mais produtivo como uma equipe? Existe algo em seus sprints que consuma regularmente uma quantidade desproporcional de esforço? Pode ser endereçado? Provavelmente não lhe dará um aumento de 40%, mas 5-10% é um começo, não? Todo sprint deve procurar gargalos e resolvê-los. Eventualmente, você pode se aproximar da meta que ele estabeleceu para você.

Matthew Flynn
fonte
7
+1: é uma boa maneira de descrevê-lo ao gerente. Você não pode aumentar artificialmente a velocidade, mas pode olhar para trás após cada sprint e aprender o que pode fazer para ser mais eficiente no próximo sprint.
Kevin
3
As probabilidades são de que remover a sobrecarga do gerente (reuniões forçadas, preencher formulários etc.) provavelmente daria a você de 5 a 10% facilmente. Mas como convencê-lo?
AviD 17/09/2013
2
Acho que sua resposta representa um mal-entendido de velocidade. Não é uma métrica absoluta, é uma média medida ao longo da vida do projeto. O que é mais pontos de velocidade em si não representam o trabalho realizado, mas medidas aproximadas de complexidade. Elas também são médias próprias e uma tarefa de ponto baixo pode exigir mais tempo do que uma tarefa de ponto mais alto. Parece um pouco sem sentido pedir "mais" e representa um mal-entendido fundamental. O gerente está basicamente pedindo um prazo fixo.
Ricardo Gladwell
3
@ RicardoGladwell - Quando eu disse "a solicitação está obviamente errada", reconheci que essa era uma compreensão incorreta de como os pontos da história funcionam. Eu estava apenas sugerindo que o que o gerente realmente quer é que a equipe melhore a produtividade, e o Scrum fornece um meio para fazer isso. Além disso, existem diferentes pontos de vista sobre o que os pontos da história representam - a complexidade é uma das mais comuns. A maioria das equipes com as quais trabalhei fez com que correspondessem um pouco ao nível de esforço. Uma tarefa simples com muita quantidade não é mais considerada simples.
Matthew Flynn
1
Você menciona que um aumento de velocidade de "5-10% é um começo", mas isso parece compartilhar o mal-entendido do gerente sobre o que "velocidade crescente" significa que eu descrevi.
Ricardo Gladwell
26

TL; DR

O Velocity é muito útil para estimar cronogramas ou gerar valores de planejamento e também pode ser um controle de detetive significativo para avaliar gargalos do processo ou alterações na capacidade da equipe. No entanto, não é uma medida válida de produtividade.

Quando o Velocity está confuso com os objetivos de gerenciamento

"Velocidade" é um intervalo que expressa a capacidade média de uma equipe durante um período histórico. É uma análise estatística do desempenho passado, que pode ser usada para projetar estimativas probabilísticas da capacidade futura da carga de trabalho ou tempos de ciclo. Isso contrasta fortemente com um "objetivo de agendamento", que é um objetivo gerencial que define uma linha do tempo ou uma meta para fins de planejamento.

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

Avalie suas opções políticas

Temos uma velocidade média de 50 pontos na história ... Me pediram para aumentá-la de 40% para 70 pontos na história (sem aumento de membros da equipe).

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 de estimativa ou definir metas de gerenciamento que não sejam baseadas no desempenho histórico. Como você apontou corretamente, isso é fundamentalmente um problema de capacidade .

O limite de capacidade pode estar relacionado ao número de pessoas em sua equipe ou pode ser uma limitação de seus processos organizacionais. Obviamente, adicionar mais pessoas nem sempre aumenta a capacidade real do projeto; consulte a Lei de Brooks para obter mais informações sobre esse equívoco comum.

O problema que você enfrenta é político. Pelo tom da sua postagem, parece que seu gerente deseja 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 de natureza amplamente educacional.

Se você é uma loja Scrum, peça ao seu Scrum Master para resolver esse problema através dos canais de estrutura apropriados. Retrospectivas de preparação e sprint da lista de pendências costumam ser as oportunidades ideais de inspeção e adaptação para esse problema em particular.

Se você não é uma loja Scrum, deve decidir qual a maneira correta de abordar suas preocupações na sua organização. Se você estiver em boas relações com seu gerente, pode até emprestar-lhe uma cópia do Agile Estimating and Planning para que vocês discutam durante o almoço.

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

CodeGnome
fonte
qualidade não é uma variável de ajuste: é por isso que falamos em triângulo de ferro, não em quadrado de ferro. Em outras palavras, quando alguém tenta diminuir a "qualidade", causa estragos em atrasos (entregas mais longas), escopo (os recursos não estão funcionando e, portanto, não são realizados) ... e recursos (os desenvolvedores estão frustrados e estão saindo). Boa resposta além desse ponto.
kriss
1
Qualidade @kriss pode, de fato, fazer parte do triângulo. Às vezes, é considerado parte do "escopo" ou, em alguns triângulos, é um vértice real, indicando que é uma restrição primária. Veja o triângulo azul no PMBOK Star como um exemplo concreto, ou a Evolução do Modelo de Restrições do Projeto para obter mais detalhes sobre esse problema. Por favor, traga isso à PMSE para mais informações.
CodeGnome
esta é uma discussão que eu já tive com colegas agilistas. Resumidamente, o que discordamos é que o PMBOK é um recurso Ágil válido. Originou-se com o modelo em cascata e é ortogonal a ágil. É principalmente compatível, mas ainda existem alguns problemas. Considerar a Qualidade como uma variável de ajuste é uma delas. Pelo que vejo (e não estou sozinho), usar (tentar usar) Qualidade como uma variável de ajuste interrompe todo o processo Agile. Mas deve ser uma questão própria.
kriss
Pergunta postada aqui pm.stackexchange.com/questions/11489/…
kriss
21

Não estou entendendo qual o papel do seu gerente na equipe Scrum? Ele é um treinador? Ele é dono de um produto?

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

Mais provável: ele está fora da equipe, talvez o proprietário do produto? Nesse caso, ele deveria entender fazer um pedido tão estúpido, apenas 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 fazer isso leva ao círculo de ferro clássico e bem conhecido: recursos, velocidade, características. Escolhe dois! Você não pode escolher três deles de uma só vez (e lembre-se: a qualidade não é uma variável de ajuste, tentar reduzir custos com baixa qualidade tornará as coisas ainda piores).

Se ele não quiser mudar a meta atual, talvez seja possível alcançar um aumento de 40% na produtividade recrutando 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 através 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 de quarto.

Você não tem um Scrum Master ou outras pessoas com conhecimentos básicos de Scrum que poderiam explicar isso para ele?

kriss
fonte
15

Nesse caso, o gerente mudou de direção após obter uma estimativa honesta e fiel da equipe. O gerente deve recorrer às partes interessadas e informá-las que seus requisitos não podem ser concluídos no tempo solicitado. O gerente / analista deve priorizar quais dos recursos DEVEM ser incluídos e os outros que podem esperar (mesmo que apenas algumas semanas). Se a parte interessada não estiver sendo razoável, pode ser necessário que os gerentes superiores se envolvam, o que geralmente pode ser desafiador e exigir um conjunto de discussões totalmente diferente.

Se eu estivesse no seu lugar eu iria chegar a um caso detalhado a respeito de porque o projeto ESTÁ vai demorar tanto tempo como foi estimada. Tente também identificar itens de baixo retorno. Encontre os itens que não agregam muito valor e exigem esforços substanciais de programação e lembre-se de removê-los do sprint. Crie também uma abordagem iterativa que forneça "X" na data "Y" e verifique se é viável; em seguida, crie uma iteração de acompanhamento que fornecerá os itens restantes.

Basicamente, alguém precisa dizer à parte interessada o que ela espera receber até o prazo final e que isso inclui a maioria de seus requisitos. e que no próximo lançamento eles terão os itens restantes. Se o cliente não é razoável, a gerência superior precisa estar envolvida, o gerente deve poder fazer isso acontecer.

No entanto, se o cliente tiver prometido demais e ninguém falou até agora, será uma batalha difícil. Infelizmente, essa não é uma situação incomum.

hanzolo
fonte
1
"estimativa honesta e fiel" pode ser o problema.
Jeffo
@JeffO - Pode ser, é por isso que eu recomendei fazendo o caso para justificar as estimativas .. quando eles tentam fazer que eles nem percebem que inflado suas estimativas ou que eles realmente não têm a capacidade
hanzolo
9

Parece que você enfrenta dois problemas.

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

A outra questão é que, com base na sua conta, seu gerente esperava um aumento de 40% na produtividade. Não foi declarado na sua pergunta o contexto dessa solicitação. Pode ser um desejo bem-humorado, se bem que desejável, de sua equipe melhorar. Ou pode ser uma indicação não tão sutil que seu gerente acredita que sua equipe está com baixo desempenho.

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

Aaron Kurtzhals
fonte
3
Infelizmente, foi um pedido sério, formulado de acordo com as linhas de Não vejo razão para que você não consiga isso (mas não vou lhe dizer como!). Portanto, a implicação é que ele não acredita que estejam trabalhando duro o suficiente ou que não sejam tão competentes quanto deveriam. A situação piorou quando eu estava de férias e o Dono do produto disse à equipe que haveria sérias repercussões se não o conseguissem. Então agora eu também tenho uma equipe muito preocupada (com quem realmente acredito ser uma ótima equipe) para me preocupar.
P2l 16/09/13
4
+1 para "sair do Dodge". Às vezes, é o único caminho (embora, quanto menos frequentemente, melhor).
Michael
9

Demita ele. Ou seja, exagere e explique que ele perdeu toda a confiança de sua equipe e explique que ele não tem valor para os negócios. 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 aturar esse gerente, mas isso não significa automaticamente que os desenvolvedores devem renunciar. Não há necessariamente algo errado com o negócio, apenas com esse indivíduo. Corrija esse problema.

E para impedir qualquer fuga da alta gerência, deixe claro que este não é um erro perdoável. Isso indica que o gerente responsável não entende a equipe que está gerenciando. Isso não se presta à correção, nem é necessário no atual mercado de trabalho. Os gerentes são eminentemente substituíveis, assim como os treinadores esportivos. Proprietários não despedem equipes.

Agora, isso pode parecer uma estratégia que pode sair pela culatra. Mas considere: se a alta gerência estiver do lado do gerente, você já estaria em uma posição perdida. Portanto, se você considerar apenas as situações em que ainda não está nessa posição perdida, o resultado provavelmente será muito mais positivo. O risco real é que a alta gerência apenas despeda toda a equipe, incluindo o gerente. Somente você pode estimar esse risco. Aparentemente, sua produção é desejada, senão eles não pediriam mais, mas a que preço?

MSalters
fonte
5
Em outras palavras, levante as mãos para o alto, lamente e dê uma surra. Esse tipo de atitude nunca resolve problemas. Existem maneiras muito melhores de lidar com a situação.
MrFox 17/09/2013
Não. Lamentar ou dar um ataque são ações dramáticas. Isso pode ser ignorado. O que proponho é um ultimato. Esse gerente vai ou a equipe vai. Sem drama, apenas lógica de negócios fria. Ele não está apto para o trabalho, e é tarefa da alta gerência agir sobre isso. Mas sua opção preferida pode ser ignorar a situação, se você permitir. É por isso que você precisa tirar essa escolha.
MSalters
@nathanhayfield Típico? Eu acho que a equipe seria formada por uma variedade de personalidades e pessoas. Os preguiçosos devem ser endereçados individualmente e não uma solicitação geral para a equipe.
James Khoury
1
@MSalters Existem muitas pessoas em diferentes camadas de negócios que não entendem certas coisas. A abordagem correta é mitigar conflitos e educar todos os envolvidos. Talvez esse gerente não entenda o Agile, mas eles podem ter outras qualidades redentoras (o que pode ser bem mais importante). Como profissional, você deve tirar o melhor proveito de todas as situações e trabalhar com todos os tipos de personalidade - porque isso é realmente construtivo e útil a longo prazo. Fazer o que você está sugerindo não aumenta.
precisa saber é o seguinte
3
@ MrFox: Os gerentes diretos devem entender a programação; na verdade, eles são a camada mais diretamente responsável por isso. Os membros da equipe devem ser especialistas no assunto e a gerência de nível superior está mais afastada da ação. Portanto, esse gerente, em uma posição em que está fazendo reclamações sobre horários, prova que não entende qual é talvez a sua tarefa mais importante. Se o mercado de trabalho estivesse apertado, conseguir um gerente melhor pode ser problemático. Mas hoje você pode encontrar alguém melhor.
MSalters
6

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

Onde eu pude obter aumentos, é uma questão de:

  • limpar dívidas técnicas; garantir que tudo esteja executando a versão correta (não necessariamente a mais recente!), que o código seja bem fatorado e que não haja redundância no sistema (código duplicado, código não utilizado etc.)

  • melhorar práticas; emparelhar sempre que possível (sim, descobri que aumenta a velocidade), dedicar um tempo para refatorar agressivamente (idem!) e ser implacável quanto ao escopo e ao 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 aqui que dizem que seu gerente solicitando um aumento arbitrário na velocidade é uma bandeira vermelha. Eu estaria procurando outro emprego como alta prioridade.

Duncan Bayne
fonte
3

Seu gerente está pedindo (ou informando) que sua equipe trabalhe horas extras. Embora remover gargalos e obter ganhos de eficiência possa melhorar um pouco sua velocidade, a única maneira de obter esse aumento (40%) é trabalhando mais horas, pois você precisa colocar mais unidades de trabalho nesse período.

Vamos dar uma olhada.

Por uma interação de duas semanas, digamos 10 dias. A utopia seria de 8 horas por dia, com um argumento sendo abstraído para um dia de trabalho. Então, de cima, sua velcoidade seria 8. Mas, relisticamente, as pessoas provavelmente estão recebendo 6 boas horas por dia com e-mail, reuniões, intervalos para ir ao banheiro etc. Então, agora você está com 6 por desenvolvedor. Portanto, sua linha de base é 6. Digamos que você queira que as pessoas trabalhem horas extras, agora lá 10 horas por dia. Então, isso seria 10 pontos de velocidade por desenvolvedor.

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

Mas se você estiver em 50 estáveis, realmente chegar a 70 exigirá horas extras.

Jon Raynor
fonte
2

O problema com a velocidade é que é uma variável dependente, uma saída medida do seu processo de desenvolvimento. Exigir aumentar a velocidade em 40% é como tentar trabalhar mais cedo, gritando para os carros irem mais rápido. A velocidade aumenta alimentando mais combustível e ar no motor ou adquirindo 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ê a medir adequadamente, digamos em pontos de recurso por desenvolvedor-hora. Só funciona se você medir pontos por dia e depois redefinir o que é um "dia" no meio da medição. Isso fornece apenas a ilusão de velocidade.

Um aumento na velocidade requer a melhoria das variáveis ​​independentes no processo dev; computadores e compiladores mais rápidos, sistema de compilação mais eficiente, melhor processo de design, desenvolvedores mais capazes, melhor espaço de trabalho, motivação para supervisor. Uma melhoria de 40% exigiria mudanças muito significativas.

Pergunte se o seu gerente consideraria co-localizar sua equipe em escritórios fechados em torno de uma sala de trabalho comum, comprar equipamentos novos para desenvolvedores ou contratar alguns desenvolvedores realmente seniores para orientar a equipe, se isso lhe desse 40%. Se não houver recursos disponíveis para melhorar as entradas do seu processo de desenvolvimento, isso praticamente exclui o interesse sincero em melhorar. Isso deixa a engenharia reversa do seu gerente para descobrir o que realmente o está motivando, o que seria o assunto de toda uma discussão.

SeattleCplusplus
fonte
1

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 a primeira coisa sobre desenvolvimento de software.

Ainda gosto de ler Phil Factor sobre este tópico:

Existem duas rotas básicas para o gerenciamento de TI. Você pode aprender seu ofício com sangue, suor e lágrimas e subir a escada gradualmente, com base na credibilidade que você ganhou com o know-how técnico e os projetos bem-sucedidos. Como alternativa, você pode vestir um terno e gravata afiados, aprender a linguagem e conversar suavemente até o topo.

Ambas as rotas parecem igualmente eficazes. Lidar com a última raça certamente pode causar alguns momentos de desânimo e incredulidade ... até desespero ... e parte disso está documentada nessas histórias.

No entanto, é fácil ficar triste e amargurado quando se encontra incompetência técnica em posições de poder e atribuir a todos os gerentes o mesmo poder. Phil desaconselha. A maioria dos gerentes trabalha duro e contribui bem para a empresa, e mesmo os gerentes ruins podem ser treinados até o padrão exigido, se você seguir apenas algumas orientações simples. Faz parte da responsabilidade da sua equipe ajudar seu gerente a funcionar de uma maneira que traga benefícios a todos.

Por fim, se você não pode treiná-los, promovê-los ou evitá-los, talvez possa aprender a amá-los apenas por sua contribuição não intencional à rica comédia do local de trabalho.

O conselho para não ficar "triste e amargurado" é o melhor que você pode obter. Não lute contra um chefe tecnicamente incompetente por questões técnicas. Ele verá isso como um ataque pessoal.

Andomar
fonte
Bem, acho que isso depende de qual modelo de gerenciamento você assina. Líder de Coaching: um especialista reconhecido que suja as mãos e ensina os outros a melhorar, mas geralmente permanece "o Guru". Diretor de Liderança: o "especialista" que sabe tudo (ou pensa que sabe) e apenas dá ordens e diz às pessoas o que fazer. Liderança por delegação: pode não ser o especialista, confia em seus conhecimentos e facilita. Liderança de suporte: a líder de torcida do grupo ajuda a desenvolvê-los, motivacional, convence a equipe de que eles podem fazê-lo e os ajuda a alcançá-lo.
Curtis Reed
0

Seu gerente não entendeu o uso da velocidade. Não é uma métrica e não é um destino. Seu objetivo é a calibração da carga de trabalho da equipe por sprint.
Se você pensar bem, sua velocidade surge de uma melhor estimativa, que você mede após cada corrida. Geralmente, à medida que o tempo avança, ele deve se tornar um pouco estável. Mas isso não muda o fato de ser um subproduto do que sua equipe está realmente fazendo: criando valor para seus clientes.

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

Stefan Billiet
fonte
até onde sei, isso já está explicado em outra resposta : "um intervalo que expressa a capacidade média de uma equipe durante um período histórico. É uma análise estatística do desempenho passado, que pode ser usada para projetar estimativas probabilísticas de carga de trabalho futura. capacidade ou tempos de ciclo ... "
gnat
@gnat parte disso sim, embora essa resposta não diga nada sobre o uso da velocidade como uma métrica de vaidade, o que ainda é importante, porque para muitos gerentes fazem coisas estúpidas com base em números de proxy. O OP disse que achava errado, mas não conseguia explicar. Eu senti que o termo métrica vaidade (de The Lean Startup) ofereceu uma boa explicação.
Stefan Billiet
-1

Quanto à minha experiência e ir direto ao ponto.

Primeiro, você pode aumentar 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 decisões difíceis em relação à construção do aplicativo e 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 vem a seguir para eles?

Isso não é "sou empurrado para os limites" ... é mais como uma pergunta para toda a equipe "estamos nos limites?" e "Como podemos empurrar os limites?" ...

Tenho líderes de equipes de alto desempenho (para primeiras construções e / ou migrações) ... a motivação da equipe é a chave do sucesso ... e planejar como seria a base do aplicativo é essencial. Às vezes, eu ou um colega de chá assumimos o papel de arquiteto de sistemas e decido como e para onde a "coisa" deve ir.

Às vezes, quando vejo que meus colegas de chá estão perdendo eficiência, tento quebrar e convido-os a sair para tomar uma cerveja ou algo do que gostam. Isso resolve todos os conflitos e, no dia seguinte, eles voltam a se concentrar.

VENDENDO ...

Se explique os motivos pelos quais você não pode aumentar a velocidade, use o ROI.

O Scrum se concentra no que é mais importante para o cliente. Teoricamente, as tarefas mais lucrativas.

Se o seu problema é vender o esforço de desenvolvimento, o que você acha que vender, qual é o ROI do esforço de desenvolvimento, converte diretamente os pontos da história no "preço". Se você pode provar que sua equipe trabalha com um ROI alto, quem vai questionar você? Além disso, toda equipe tem limites se a equipe encontrou seu "tamanho de conforto", tente um aumento mês a mês, se não puderem concluir todas as tarefas, esse é (provavelmente) o limite.

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

Marcos Lima
fonte