"Toda verdade passa por três estágios.
No primeiro, ela é ridicularizada.No segundo, é rejeitada com violência.No terceiro, é aceita como evidente por si própria.” -- Arthur Schopenhauer
Na Parte I desse artigo  exploramos as falsas dicotomias que impedem times ágeis de medirem sua própria produtividade e compartilhamos as razões pelas quais a indústria deveria dar o próximo passo.
Nessa segunda parte, compartilhamos um método para se normalizar a complexidade (ou tamanho) funcional do software de forma clara, padronizada e objetiva.

Pensando fora da caixa

As pessoas sempre tiveram o sonho de simplificar e padronizar o desenvolvimento de software com a intenção  de maximizar as chances de sucesso de seus projetos. Diferentes escolas de pensamento escolheram caminhos distintos e tem utilizado diferentes processos para atingir o objetivo de melhorar os resultados para os negócios. Medição de software é, sem dúvida, uma parte relevante dessa história e um grande desafio nesta área é como medir o tamanho e complexidade, dada a natureza do software.
Para se acompanhar produtividade no desenvolvimento de software é fundamental, antes, que se consiga resolver o desafio de se determinar o tamanho funcional do software a ser desenvolvido.
Nesse sentido, ao longo da nossa história de desenvolvimento de software, tivemos oportunidade de usar e experimentar extensivamente diversas abordagens - primeiramente SLOCs (linhas de código) e Pontos de Função, durante os nossos dias de RUP, e, em seguida, Story Points, depois que a organização abraçou o Agile em 2006.
Como nunca estivemos satisfeitos com as fragilidades e com os inconvenientes decorrentes dessas abordagens, continuamos experimentando e desafiando-nos sempre para tentarmos chegar a um modelo que nos permitisse determinar a complexidade / tamanho funcional do software a ser construído e que fosse:
  1. prático / viável e simples de entender (abrangendo múltiplos times e evitando falhas de comunicação);
  2. padronizado e estável o suficiente para ser aplicado em diferentes sprints de diferentes projetos (permitindo comparar evoluções/mudanças durante os projetos/programas);
  3. independente de aspectos técnicos, linguagens de programação, plataformas de desenvolvimento ... (caso contrário, seria uma comparação de maçãs com bananas);
  4. baseado em requisitos de negócios e práticas de engenharia de software universais;
  5. não influenciável pela experiência no cliente ou pela qualidade técnica.
Criamos então a primeira versão uma ferramenta que batizamos de  “Régua de Complexidade” e que nos permitia desmembrar (ou quebrar) as features/histórias do backlog em elementos básicos que deveriam  ser desenvolvidos. Essa primeira versão estava ainda muito baseada em aspéctos técnicos e não demorou para percebermos a sua fragilidade: ela era totalmente dependente e acoplada à tecnologia de desenvolvimento em questão. E essa fragilidade comprometia em muito a nossa intenção de promover aprendizado corporativo permitindo que os times de diferentes programas pudessem se comparar uns aos outros e compartilhar seus aprendizados e melhores práticas.
Além disso detectamos outro ponto fraco nessa primeira versão: uma determinada história acabava sendo muito dependente de um único item (ou categoria) de complexidade da régua e isso fazia com que a produtividade variasse muito em função da natureza do requisito, criando uma falsa impressão de que um determinado projeto estava ganhando produtividade ou velocidade enquanto ele estava apenas tendo “sorte” na escolha do escopo que estava desenvolvendo  nos sprints em questão.

Para piorar, ela ainda não nos permitia isolar a complexidade funcional de outros aspectos como tecnologia, processo interdependências entre times, tarefas relacionadas a infraestrutura, etc. Devido a essa imperfeição,  diferentes times, usando diferentes tecnologias, chegariam a estimativas diferentes de tamanho do software. E os times confundiriam esforço com complexidade. Incertezas e aceleradores de performance também seriam levados em conta nas estimativas de tamanho, tornando as histórias mais ou menos complexas, respectivamente. A mesma história, então, poderia ter diferentes estimativas de tamanho/complexidade dependendo da plataforma de desenvolvimento usada e isso trouxe à tona um grande inconveniente e uma séria ameaça para nosso objetivo maior.
Acreditamos que qualquer coisa que possa otimizar e agilizar o desenvolvimento de software (aceleradores, reutilização, componentes) deve contribuir para a melhoria da produtividade, mas não deve afetar o racional de dimensionamento do software que está sendo desenvolvido (tornando-o menor ou maior).
No fim das contas só eramos capazes de usar essa régua para um cenário muito específico de tecnologia e isso demandava a criação várias versões da régua, uma para cada um dos diferentes contextos de nossas equipes.  
Essa última limitação foi um fator determinante para que abandonássemos essa versão e decidimos voltar para a prancheta.

O momento “Eureka”

Depois de várias tentativas e uma boa quantidade de frustração - com desafios vindo de diferentes direções - finalmente fomos capazes de criar uma ferramenta poderosa!  O momento "Eureka" veio quando percebemos que deveríamos tentar determinar as semelhanças funcionais entre histórias de diversos projetos que usavam tecnologias distintas. Nos colocamos na pele de um Product Owner hipotético para todos aqueles projetos e nos fizemos a seguinte pergunta: “Se eu fosse um PO para todos esses projetos, tão diferentes uns dos outros, e precisasse explicar seus requisitos para novas equipes ágeis que irão desenvolvê-los, como faria ? “. E a resposta surgiu, tão óbvia e tão mágica ao mesmo tempo: “Usaria a linguagem de negócios para contar as histórias e descrever seus aspectos funcionais e de negócios”.
A linguagem de negócios  !! Esse é o elemento chave que nos permitiu finalmente normalizar a complexidade entre diferentes histórias, mantendo-as coerentes independentemente de qualquer outro fator, seja ele de natureza tecnológica ou humana.
Em seguida, para validar essa hipótese, selecionamos uma extensa e abrangente amostra de histórias de diversos projetos, tomando o cuidado para garantir diversidade e quantidade suficientes (projetos de diferentes tamanhos e complexidade, diferentes contextos e verticais de negócios e várias tecnologias e plataformas). A amostra foi cuidadosamente selecionada para abranger tanto projetos muito simples, como por exemplo,  criação de sites brochura paramarketing digital quanto projetos extremamente complexos e de missão crítica como, por exemplo, projetos de gestão logística para empresas mineradoras ou projetos de gestão de fluxo e transporte de óleo e gás para empresas do setor de energia. 

 Então, estudamos minuciosamente cada uma das histórias dessa amostra, confirmando que a descrição das mesmas pelos Products Owners era sempre feita através de uma linguagem bastante comum entre todas elas e que era baseada em um conjunto relativamente restrito de aspectos funcionais.

 Também pudemos confirmar que os POs raramente ou nunca demonstravam estar  preocupados com aspectos técnicos, versões de framework ou mecanismos arquiteturais. Obviamente, existem POs com um forte background técnico e que acabam adotando uma abordagem mais híbrida, combinando aspéctos funcionais com elementos técnicos, para detalharem as histórias do projeto. Mesmo assim, nos poucos casos onde detectamos essa particularidade, pudemos confirmar que uma abordagem puramente funcional teria sido plausível, suficiente e muito mais adequada para detalhar as histórias uma vez que,  para a grande maioria delas, quando foram priorizadas para implementação, os times acabaram implementando uma solução técnica drasticamente diferente daquela que havia sido “rascunhada” inicialmente pelo PO, para poderem endereçar aspectos importantes como desacoplamento e minimização de dependências,  bem como tratamento de requisitos não funcionais de disponibilidade e performance da aplicação, por exemplo, que não faziam parte do escopo de preocupações do PO quando havia escrito a história.

Nossa conclusão é que em todos esses casos, teria sido melhor se o PO tivesse focado exclusivamente em aspéctos funcionais.
Voltando para nossas descobertas, percebemos que as descrições das histórias sempre incluiam os mesmos tipos de elementos básicos para representar aspectos funcionais, como :
  • regras de negócios (desde a aplicação de fórmulas simples até processos iterativos em vários níveis e com muitos pontos de decisão);
  • elementos de interface com o usuário (desde inclusão de “x” elementos simples em um formulário específico e existente até a criação de um novo formulário complexo com diversos elementos sofisticados de interface com comportamento dinâmico);
  • entidades de negócio (desde a manipulação ou evolução de entidades de negócio já existentes até a criação de novas entidades necessárias para a implementação de novos conceitos / criação de novos contextos de negócio)
  • interface entre diferentes entidades; etc
Então, organizamos todas essas categorias de itens funcionais  num formato de tabela, criando a nova versão da nossa “Régua de Complexidade de Negócios” (você pode solicitar o acesso à planilha aqui).
Nas linhas da tabela estão os elementos funcionais básicos (regras de negócio, elementos de interface com o usuário, permissões, etc), que denominamos de “Itens de Complexidade”.
E nas colunas estão as diferentes classificações de tamanho (XS, S, M, L, XL) organizadas em escala para garantir complexidade relativa. Para cada tamanho, existe uma pontuação correspondente, usando como base a sequência de Fibonacci.

Cada item de complexidade (linhas) da tabela possui uma descrição correspondente para cada classificação de tamanho (colunas) para guiar a parametrização de dimensionamento daquele item.  Assim, por exemplo, para o item  "Regras de Negócio",  o conteúdo da coluna relacionada com o tamanho XSestá definido como "aplicação direta de fórmulas", enquanto o conteúdo da coluna relacionada ao tamanho XL está como "processos iterativos de várias etapas com muitos pontos de decisão ".

É importante destacar que a forma com que a régua foi definida e organizada permite que se mantenha compatibilidade e coerência entre estimativas de mesmo tamanho, independentemente do item de complexidade que está sendo estimado.
Em outras palavras, essa abordagem possibilita “normalização” das estimativas de complexidade funcional pois visa garantir que 1 (um) ponto de um determinado item de complexidade seja equivalente a 1 (um) ponto de qualquer outro item de complexidade da régua.
A essa unidade de tamanho funcional normalizada, chamamos de Business Complexity Point (ou Ponto de Complexidade de Negócio).
Essa régua de complexidade, então, é composta de apenas 10 itens de complexidade e cada um deles possui 5 tamanhos, com suas parametrizações de pontuação correspondentes.  

E, vale mencionar, ela é abrangente o suficiente para ser aplicada com sucesso nas estimativas de projetos de qualquer natureza e tamanho para as mais diversas verticais de negócios.

 A estimativa de tamanho funcional normalizado de uma história se dá através do desmembramento dos requisitos da mesma em elementos funcionais mais básicos, ou seja, nos itens de complexidade da régua. Para cada item de complexidade identificado deve ser atribuída uma pontuação, de acordo com a avaliação de tamanho do mesmo.
Como resultado final, o total de Business Complexity Points da história que está sendo estimada será calculado através da soma ponderada das pontuações de todos os itens de complexidade que a compõem.

Na terceira parte deste artigo compartilhamos descobertas interessantes sobre este programa de medição. Também discutimos como usar essa Régua de Complexidade para gerenciar produtividade e promover melhoria contínua.

Nota: Agradecimentos especiais a Gilson Gaseorowski por sua grande contribuição para esse artigo.