Porque a medição muda o comportamento do desenvolvedor, essa mudança importa mais do que a medição em si. Ou seja, os benefícios da medição não se restringem ao número resultante.
A natureza da mudança pela medição, assim como em toda tecnologia, depende de como a usar e, em especial, de como a comunicar. Eu posso iniciar a explicação sobre a necessidade da mudança pela paixão.
A paixão no comportamento do desenvolvedor
A paixão é sentimento intenso, que possui a capacidade de alterar o comportamento, o pensamento. Paixão é sofrimento. Eu vejo os desenvolvedores apaixonados pelas linguagens e frameworks com que trabalham. E isso, é bom. Mas como tudo, essa paixão carrega consigo o seu oposto.
Por exemplo, eu vejo iniciativas de negócio se arrastarem por avanços, que não entregam resultados para o negócio no tempo em que poderiam ser .
Avanços, que dilatam resultados para o negócio, é um exemplo de quando essa paixão não é boa.
De uma possível infinidade de causas, duas em especial chamam mais a minha atenção. São elas:
- A busca por se reinventar a roda, porque fazer a ferramenta dá mais satisfação do que usá-la.
- A influência na priorização, porque o desenvolvedor valoriza um ordenamento natural de sua lógica própria, inviolável em seu mindset.
Eu pensei sobre esse assunto quando vi essa tirinha aqui.
Uma ressalva. Sobre o comportamento do desenvolvedor, toda generalização falha em um caso concreto pontual. No entanto, ela ajuda a identificar padrões e dar insights na gestão de software.
O comportamento do desenvolvedor ao “se reinventar a roda”
A busca por “se reinventar a roda” surge, porque os desenvolvedores apaixonam-se pelo software de suporte às funcionalidades do usuário. Consequentemente, acabam se dedicando a investir tempo e trabalho nisso. Hoje em dia existem soluções prontas, que já oferecem praticamente tudo o que se necessita em termos de suporte às funcionalidades; sejam aplicações ou APIs.
Talvez um dos apelos pelo desenvolvimento low-code e a esperança, que se deposita nas ferramentas low-code, seja resolver esse problema. No entanto, tenho visto que tanto o desenvolvimento low-code e as ferramentas low-code não são balas de prata.
O investimento na reinvenção da roda implica em deixar de investir tempo na entrega das funcionalidades do usuário.
O comportamento do desenvolvedor ao influenciar a priorização
O esquema de priorização é um segundo ponto onde há influência do desenvolvedor; nem sempre na direção mais adequada ao negócio.
Em uma visão na “lógica do desenvolvedor” antes de entregar um cômodo funcional, é necessário entregar os cômodos de acesso. Por exemplo, para entregarmos a sala de estar, deve-se antes entregar o vestíbulo. Antes de entregarmos um quarto de hóspedes, deve-se entregar o corredor de acesso ao quarto.
E assim, priorizam-se o vestíbulo e o corredor em detrimento da sala de estar e do quarto de hóspedes.
Em nosso paralelo, a sala de estar pode ser vista como uma funcionalidade de vendas e o vestíbulo como as transações com a manutenção de dados de referência ou de código (CRUDs) necessários ao próprio cadastramento da venda.
Opa! Se são necessários, então está ai a precedência intrínseca e o motivo de sua priorização antes das funcionalidades de venda. Não. Observe que a precedência é de haver os dados disponíveis e não necessariamente as funcionalidades que os mantém.
Entendo que ainda não tenha visto o nexo entre esses pontos e a questão da medição mudar esse comportamento. Ele não é tão óbvio. Por isso, vou tentar explorar melhor esse nexo.
A medição e como influi no comportamento do desenvolvedor
Ao não medir ou ao medir a produção de software por meio da contagem de “histórias” ou “cartões”, você coloca no desenvolvedor o poder de criar unidades de produto. Ele decide, ainda que com a ajuda do usuário sobre essas histórias e cartões. Mas o entendimento do usuário é limitado no que se refere às tecnologias de desenvolvimento. A ele resta confiar. E nisso, as horas vão aumentando, os custos vão aumentando e, gradativamente, cada vez menos funcionalidades são entregues ou aperfeiçoadas.
Se colocamos a medição no controle do usuário, ou melhor, na intercessão entre o desenho de seus fluxos operacionais e as aplicações e serviços que os suportam, então o esforço de desenvolvimento mais facilmente se dirige a entregar as funcionalidades nessa intercessão.
As regras de processo elementar, componente funcional básico da medição em Pontos de Função Simples, evitam que uma mesma funcionalidade seja fragmentada incontáveis vezes em um escopo de uma mesma liberação (Release). Elas são padronizadas e há critérios para sua aplicação. Identificar processos elementares não exige entrar nos detalhes internos ao desenvolvimento e o que importa na medição é a funcionalidade entregue ou as novas features impactando as funcionalidades existentes.
Resultado: temas de discussões em um plano compreensível
Consequentemente, eleva-se o nível das discussões para um patamar onde os usuários do negócio podem efetivamente colaborar. Sem isso, é altíssimo o risco de ficarem perdidos em um oceano de tecnicidades, que não entendem e deles não deveria se exigir entender. Os usuários passam a navegar em um universo de transações inseridas em seu cotidiano e parte do seu repertório de conhecimento ao tocar e, hoje mais importante do que nunca, de criar negócios com base em uma tecnologia profundamente transformadora.
Conclusão
Em resumo, com o Ponto de Função Simples você pode obter os benefícios da medição funcional, já consagrada pela Análise de Pontos de Função do IFPUG. Isso com um nível de informação muito menor, o que melhor permite colocar ênfase no que importa durante a medição.
Mas observe, o Ponto de Função Simples é uma medida de quilômetro. Não vá medir a distância entre a sala de estar e o vestíbulo em quilômetros!
O objetivo de medições em Pontos de Função Simples é avaliar a soma de todas as histórias ou cartões entregues e não avaliar cada cartão ou história.
Eventualmente, o escopo de medição é pequeno. Mas devemos usar as medições em um conjunto de casos; cada um com o seu próprio escopo de medição.
A comunicação sobre como funciona a medição e sobre como utilizam-se seus resultados é fundamental para o tiro não sair pela culatra e, como resultado, a influência no comportamento do desenvolvedor ser no sentido oposto.
A gente tem muita experiência nessa transformação. Entre em contato comigo cadu@fattocs.com e não deixe de conhecer o nosso Centro de Orçamento e Fábrica de Métricas. A FATTO tem mais de 20 anos de experiência e eu uns 30. Medição, Análise e Gestão de Requisitos e Qualidade são assuntos fundamentais para o sucesso na Gestão de Software e nós temos como ajudá-lo nisso.
