Métricas Ágeis: Realidade ou um Sonho Distante? · gqo

Fala galerinha! Tudo jóia?

Acredito que muitos aqui, senão todos, já tiveram contato com desenvolvimento baseado em alguma prática/framework ágil (Scrum, Kanban, Lean etc). Contudo, gostaria de saber de vocês como está a saúde dessas práticas e como isso pode afetar seu trabalho como desenvolvedor. Em tempo, que "arranjo" vocês buscam realizar para sair do outro lado?

Nos últimos anos venho atuando em times ágeis utilizando principalmente práticas do Scrum e tenho percebidos os seguintes pontos negativos:

Sprints, que por mais curtas que sejam (2 semanas), sempre contam com mudanças de escopo (um bug inesperado de produção, uma nova solicitação de análise do time de produtos, problemas que muitas vezes não fazem nem parte do contexto da squad - na minha opinião esse é o pior :P)
Discovery e Refinamentos onde o time de produtos parte do suposto que todo o time de desenvolvimento já conhece como as regras do negócio funcionam, gerando épicos,features e histórias de usuário pobres.
Squads sem autonomia, sofrendo constante influência de áreas cross. Em algumas empresas que passei, colaboradores com papel de QA, Arquiteto e DevOps pertenciam à equipes transversais e não à squad. Por um lado é uma prática interessante, porém também traz alguns problemas. Podemos falar sobre alguns caso esse tópico evolua durante nossas discussões.
Vou finalizar meu relato neste tópico que foi responsável por dar o título desta thread: métricas. Apesar de já ter trabalhado em algumas empresas "ágeis", uma forte recorrência que percebo é o uso de log de horas como métrica principal para entender se um time e/ou um desenvolvedor está performando ou não. Já aconteceu com vocês? Ou foi eu que não tive tanta sorte assim? :)

Apesar do uso de práticas ágeis a nível de Operação, o que percebo é que a gestão ainda precisa deste micro-gerenciamento, a nível de horas para ler/analisar a produtividade de um time/desenvolvedor e quando subimos na hierarquia da empresa, direção, presidência, a relação horas trabalhadas x prazo de entrega de projetos é ainda mais necessária.
Como desenvolvedor procuro ser o mais resiliente possível, me adaptando a diferentes cenários, mas confesso que esse tipo de métrica baseada em log de horas me incomoda um pouco. O que vocês acham?

Bom, vou responder curto, mas se quiser, posso expandir em tópicos específicos se você quiser.

1..
Eu nunca gostei muito desta obsessão por Sprints, mas, em geral, se o escopo muda com regularidade, então o sprint tem que ser menor. Mesmo que seja um Sprint de dois ou três dias. Na minha opinião, esta ideia de Sprint está defasada e ainda se baseia nos tempos do passado onde tínhamos grandes releases. Hoje em dia, eu defendo que não tenhamos sprints e, quando uma funcionalidade estiver pronta, então que seja enviada para produção sem acumular em um Sprint.

2..
Aqui é um problema de equipe de produto. Por essa descrição, parece que o time de produto não sabe o que fazer ao certo. Ou tem ideias controversas. Aqui não tem jeito, tem que ter um bom time de produto liderando o produto. Incertezas sempre vão existir, se preciso, adicionar o time de desenvolvimento mais cedo pode ajudar ajudar nas idéias do produto, mas nem sempre essa estratégia ajuda. A realidade é que pessoas boas de produto são raras de encontrar.

3..
Aqui é um problema de gestão, depende de empresa para empresa. Mas, pela sua descrição, me passa a impressão que a gestão fica tentando copiar os modelos de outras empresas. Ao invés disso, seria melhor tentar encontrar o modelo único e específico que funciona para a empresa de vocês.

4..
Acontece comigo com muita frequência e, infelizmente, sinaliza que o gerenciamento tem uma visão muito rasa do que as métricas do Scrum (estou dizendo Scrum porque você usou os termos do Scrum, então estou assumindo que você se refere ao Scrum) significam.