Meça a produtividade de times ágeis antes que seja tarde demais! - Parte III

Por Felipe Brito, Diretor de Negócios e Fernando Ostanelli, Head de Operações, da CI&T.

“Por mais que seja bela a estratégia, devemos ocasionalmente olhar para os resultados.”

-- Winston Churchill.

Parte III - Descobertas interessantes e melhoria contínua 

Na Parte II desse artitgo compartilhamos um método para se normalizar a complexidade (ou tamanho) funcional do software de forma clara, padronizada e objetiva.

Nessa terceira e última parte compartilharemos as lições que aprendemos ao longo dessa jornada. 

Também vamos falar sobre como usar a Régua de Complexidade Funcional para gerenciar produtividade e promover melhoria contínua. 

Onde estamos atualmente

Usamos a nossa Régua de Complexidade Funcional em projetos que já havíamos entregue (para uma variedade bastante abrangente de verticais de negócio) a fim de confirmar que o método proposto para normalização de complexidade funcional poderia ser aplicado a qualquer tipo de contexto e que seria capaz de garantir estimativas consistentes de tamanho funcional para as histórias em todo o nosso portifólio de projetos. 

Vários programas de diferentes setores (educação, serviços financeiros, mineração, petróleo e gás, e farmacêutico) e diferentes tecnologias e plataformas (Java, Microsoft .NET, Sharepoint, PHP, Drupal, para citar alguns) têm utilizado a ferramenta de forma consistente e com bastante sucesso, observando o conjunto de critérios que havíamos proposto inicialmente. Até o final de 2014 havíamos treinado mais de 700 pessoas, incluindo os times de alguns clientes, e esse número não para de crescer desde então. 

Eis algumas descobertas importantes que fizemos: 

• o método promove um melhor alinhamento corporativo através de um processo de estimativas totalmente orientado a negócios (independente da tecnologia ou segmento de indústria);
  
• a clareza das regras torna o processo de estimativas muito mais simples, direto e fácil de replicar entre os vários time, contribuindo para que sobre mais tempo disponível para o desenvolvimento de software com qualidade dentro dos sprints (quanto mais economico for o processo de estimativas, mais tempo sobra para o time focar no desenvolvimento);
  
• a régua de comlexidade manteve-se estável e imutável apesar de ter sido constantemente desafiada. Ela se mostrou muito robusta e adequada em todas as situações onde foi utilizada. Não houve necessidade de se incluir novos itens de complexidade, nem tampouco adaptar os existentes para acomodar necessidades específicas;
  
• times experientes perceberam que sem a ferramenta eles não estavam sendo consistentes em termos de velocity (mesmo quando os times se mantinham estáveis e trabalhando nos mesmos projetos com os mesmos contextos de negócio ou tecnologia) e que também não estavam sendo capazes de perceber as oportunidades de melhoria; 

Também observamos resultados bastante relevantes: 

• o uso da régua resulta numa base de conhecimento poderosa pois preserva o racional e as premissas que foram consideradas nas estimativas que foram realizadas quando ainda não se dispunha de detalhes suficientes sobre as histórias / funcionalidades;
  
• variações na forma de se interpretar e estimar um mesmo requisito resultaram em diferenças muito pouco significativas em termos do número final de Business Complexity Points estimado para a história em questão;
  
• o desvio padrão das estimativas utilizando-se a Régua de Complexidade foi 70% menor quando comparado com as mesmas estimativas realizadas através de Análise de Pontos de Função. É importante enfatizar que não utilizamos APF, nem tampouco recomendamos sua adoção. Essa estimativa 'paralela' foi realizada apenas para permitir uma análise comparativa com um método que, por mais deficiente que seja, foi bastante utilizado no passado e sustentava a reputação de 'norma'.
  
• eliminação de suspeitas / dúvidas sobre as estimativas de tamanho, uma vez que todos os interessados na história podem estimá-la, com garantia de estarem aplicando exatamente o mesmo método e racional de estimativas;
  
• simplicidade e objetividade para se detectar mudanças no escopo (novas histórias, mudanças nas histórias existentes) por preservar uma 'memória' do racional de estimativas e premissas de escopo e, com isso, permitir uma rápida navegação nos detalhes do requisito que havia sido estimado. 

Alguns agilistas podem argumentar e defender que não é importante avaliar ou quantificar as mudanças de escopo mas a maioria das empresas com quem estivemos trabalhando querem e precisam entender a quantidade de pontos que seremos capazes de entregar nos projetos. Os orçamentos dos projetos, via de regra, são definidos de ante-mão, como pré-condição para que possam ter sua viabilidade analisada e, então, aprovados. Essa é uma realidade e uma necessidade de nossos clientes que não podemos ignorar. 

Em última análise, a Regra de Complexidade Funcional se mostrou extremamente aderente a todos os requisitos que tínhamos em mente quando decidimos criá-la e pudemos comprovar que ela nos permite determinar a pontuação de complexidade de cada história tem de acordo com variáveis de negócio e os aspectos de engenharia de software. 

Com esta ferramenta podemos controlar o tamanho, esforço, evoluir médias móveis de performance e buscar melhorias de produtividade. 

Implementando um programa de medição e melhora de produtividade 

Nosso programa de medição de produtividade tem uma mentalidade de melhoria contínua e abrange as seguintes etapas: 

Coleta de dados 

Esse é o primeiro passo. 

Coletamos dados relacionados a esforço realizado durante cada sprint e ao tamanho do software sendo construído. Usando nossa Régua de Complexidade Funcional, somos capazes de determinar o número de Business Complexity Points (ou seja, a pontuação normalizada para a complexidade funcional) de cada história e, por extensão, o tamanho total do backlog ou do projeto como um todo. 

Vale lembrar que tais pontos de complexidade são usados aqui conforme descrito na parte II desse mesmo artigo. 

Também é importante mencionar que continuamos utilizando todas as técnicas ágeis já tão bem difundidas e comprovadas, bem como todo o conjunto de ferramentas derivadas (gráficos de burndown, velocity, cycle time, etc ...). 

O benefício adicional que aproveitamos aqui é o da normalização e padronização das estimativas de tamanho e, em decorrência disso, a possibilidade de se criar análises, comparações e insights para oportunidades de melhoria futuras. 

O esforço (em horas) realizado para executar cada tarefa dos projetos também é registrado de forma organizada e padronizada para permitir rastreamento das diferentes disciplinas envolvidas (desenvolvimento, testes, correção de bugs, resolução de blocks, etc) possibilitando análises bem mais poderosas. Também registramos informações de qualidade (número de defeitos durante as fases de desenvolvimento, homologação ou aceitação do usuário e produção).} 

Análise 

Não há coleta de métricas sem propósito. 

Somos criteriosos na escolha do conjunto de métricas que vamos coletar, focando apenas nas métricas que importam de verdade (isto é, que podem realmente nos ajudar a enxergar problemas e oportunidades de melhoria). 

Com dados de múltiplos sprints e projetos é possível indentificarmos tendências, correlações e oportunidades de melhoria ou replicação de boas práticas entre os diversos times. 

A análise de um trabalho específico nos leva a uma compreensão mais profunda das condições atuais e nos traz insights sobre como implementar melhorias alinhadas aos objetivos de negócios. Também nos ajuda a identificar as causas reais dos problemas para que possamos ser mais eficazes nas ações corretivas. 

Ação de Melhoria 

Com os insights somos capazes de planejar e implementar ações bem focadas. Isso pode ser uma análise mais profunda sobre como uma determinada equipe está conseguindo resultados de desempenho melhores do que a média sprint após sprint. Ou pode signficar trabalhar com top performers para propagar a aprendizagem que tiveram e as melhores práticas que já validaram para resolver problemas que podem ser comuns a outras equipes ou, ainda, para ajudar e prover melhor suporte técnico aos times que estejam sofrendo com algum desafio. 

O objetivo é identificar inovação ou oportunidades de ajustes que possam ser aproveitados consistentemente dentro de um time em específico ou, ainda, que possam ser replicados a múltiplos times e, com isso, atingir um nível superior de performance global. 

Verificação de resultados e eficácia 

E então, procuramos validar muito rapidamente o resultado desse ciclo de melhoria! O potencial ou a eficácia das hipóteses de melhoria que surgiram a partir dos insights nos passos descritos acima precisam ser confirmados (ou não) no sprint seguinte de modo que outras ações possam ser rapidamente tomadas e a melhoria contínua seja reforçada. 

Cada melhoria implementada pelos times leva a resultados diretos. Pode ser uma melhoria de qualidade, de aprendizado corporativo ou produtividade geral. O time passa a trabalhar melhor e de forma cada vez mais inteligente ao invés de trabalhar mais e na força bruta. Quando a produtividade melhora, as médias históricas melhoram e novos benchmarks surgem para se executar determinados tipos de tarefa. E nos projetos seguintes nos tornamos capazes de entregar um volume maior de software funcionando e melhores resultados para os negócios de nossos clientes. A satisfação e o senso de propósito do time crescem na mesma razão! 

À medida que ganha maturidade nesse processo, o time também se torna capaz de trabalhar com planejamentos muito mais factíveis e realistas, pois pode usar a sua própria base história de desempenho para projetar ou validar estimativas futuras. 

Medindo Produtividade com Business Complexity Points - Um estudo de caso real 

Planejamento do projeto e compromissos de troughput e datas de entrega

Em outubro de 2013, assumimos a responsabilidade de desenvolver um grande sistema para uma empresa do segmento de energia. Durante as primeiras semanas o time de Analistas de Negócios e os Product Owners analisaram obacklog do projeto utilizando a nossa Régua de Complexidade. Isso garantiu um alinhamento comum e também bastante clareza sobre o throughput (vazão e rítimo de entrega) necessário para concluir o projeto em outubro de 2014 - um marco crítico para a área de negócios, cujo atingimento era crucial para a continuidade da iniciativa. 

A partir dessa visão bastante compreensiva de throughput projetado, fomos capazes de criar um plano bastante detalhado e factível (estimativas, estrutura de time, estratégia de onboarding e capacitação dos membros do time, etc). 

Além disso, a equipe conseguiu estabelecer hipóteses específicas que deveriam ser validadas ao longo do projeto e se planejou para mitigar os riscos a essa estratégia durante a sua execução. Nos podíamos ser bastante flexíveis em termos do que seria entregue - alinhado com as prioridades de negócios - e conseguimos planejar um compromisso bastante sólido em termos da taxa de pontos de complexidade a serem entregues por sprint. 

Melhorias de Produtividade ao longo do projeto 

Tivemos os 3 primeiros meses para fazer o setup do projeto e o realizar o onboarding de 50 pessoas. Desde o primeiro dia do projeto coletamos o número de BCPs entregues por sprint, o esforço realizado para entregar cada tarefa do backolog, número de bugs, etc. Com esse conjunto de métricas o time (não apenas os gestores) foi capaz de entender sua própria performance, compará-la com as métricas dos sprints anteriores, realizar análises de causa raiz dos problemas, planejar e implementar ações corretivas e confirmar as hipóteses das ações de melhoria que vinham sendo implementadas. Claro que tivemos muitos percalços ao longo do caminho, mas as métricas ajudaram incrivelmente o time a ajustar o curso rapidamente e todos ficamos muito satisfeitos com a tendência e com os resultados decorrentes que pudemos observar. 

Algus números: 

• Sprint #1 (Outubro-2013): Produtividade 10.34 horas/Business Complexity Points 
• Sprint #15 (Maio-2014): Produtividade 3.59 horas/BCP 
• Produtividade média do Q4/2013: 6.33 h/BCP 
• Produtividade média do Q1/2014: 4.13 h/BCP 

O que vem pela frente ? 

Eis alguns desafios e objetivos que temos para o futuro próximo: 

• continuarmos construindo e aprimorando nosso sistema de métricas para que possamos intensificar o aprendizado corporativo, criando correlações poderosas e gerando insights de acordo com clientes, verticais de negócios, tecnologia, maturidade do time, etc;
  
• reforçar a mentalidade orientada a negócios da Régua de Complexidade Funcional : ocasionalmente percebemos que as pessoas ainda se confundem ao interpretar os itens de complexidade da régua pois ainda são influenciadas por um longo e forte histórico de pensamentos orientados a termos mais técnicos;
  
• convidar nossos clientes a ampliarem o uso da régua para que possam adotá-la também como uma estratégia corporativa e sejam capazes de materializar os mesmos benefícios, tanto internamente quanto com outros parceiros;
  
• trabalhar em parceria com a comunidade ágil, globalmente, para evoluir esse modelo e discutir desafios que possivelmente a nossa régua ainda não endereçe.

Se você tiver interesse em conversar sobre isso, por favor, entre em contato conosco!

#agile #enterpriseagile #ciandt #produtividade