Agora que já sabemos por que usamos métricas e como medimos e estimamos através de PCU, resta saber como é o dia-a-dia trabalhando com isso. Vamos abordar aqui como estimamos o tamanho de um projeto novo, como a métrica se comporta ao longo do projeto, o que apresentamos aos clientes, como fazemos as cobranças e mais alguns temas afins.

Como estimamos o tamanho de um sistema novo

Podemos nos enganar achando que numa fase de inception, no início do projeto, conseguiremos levantar 80% dos UC’s que serão trabalhados. Mas a verdade é que tanto o cliente quanto nós ainda iremos aprender muito sobre o projeto ao longo dele, e ainda vamos mudar muito de idéia a respeito do que deve ou não fazer parte do sistema. E isso é muito bom! O que precisamos mesmo é de um mecanismo para servir de base para começarmos o trabalho e podermos negociar. Termos uma primeira idéia com nível de incerteza aceitável.

Se houver liberdade para trabalhar assim, o que fazemos é levantar e modelar os casos de uso do sistema, assim como explicado no post anterior; casos de uso pequenos, procurando por relações 1xN, procuramos por relatórios, grandes cadastros, includes e extends ocultos e o que mais pudermos. Não é necessário detalhar nenhum caso de uso, apenas contar os casos de uso e atores conhecidos até o momento.

Após esse cuidadoso levantamento, consideramos todos os casos de uso como médios e fazemos a contagem. Essa estratégia é parecida com a proposta da NESMA, usada em APF. Ao longo do projeto, novos cenários e casos de uso vão surgir, alguns casos de uso serão simples, outros se tornarão complexos. Alguns irão desaparecer também. O que criamos é um tipo de “crédito” em funcionalidades do sistema, um número plausível com que o cliente pode trabalhar.

Se ao longo do projeto o cliente perceber que precisava de menos coisas, só paga pelos créditos utilizados. E se percebe que não vai caber tudo, vai ter boa parte entregue, funcional e vai ter consciência das razões da estimativa não ter contemplado tudo. É uma questão de método de trabalho. Estimativas por definição sempre incluem um certo grau de incerteza. O que fazemos é torná-lo gerenciável e claro.

E isso tem funcionado muito bem por conta de algumas das maiores vantagens e principais características da métrica de PCU: transparência, simplicidade e facilidade de comunicação. Ora, é tão fácil para os clientes se acostumarem ao linguajar de cenários, casos de uso e atores que fica fácil negociar. Eles compreendem muito bem a dimensão dessas coisas, aprendem rapidamente a fazer a contagem e podem gerenciar seus recursos e desejos ao longo do projeto. É muito menos abstrato que ALI’s, EE’s, CE’s e muito mais fácil de se trabalhar pois não precisamos decompor campos e/ou tabelas. O próprio cliente se capacita em fazer estimativas velozes do sistema pra saber o que mais pode caber, quanto mais gastaria para adicionar alguma coisa e assim por diante. Sentem-se com o escopo sob controle. Temos clientes que têm até preferido mudar de APF para PCU por conta disso.

Como a métrica se comporta ao longo do projeto

Quando falamos de performance média no post anterior, usamos a palavra “média” por uma razão bem importante: ela não será sempre a mesma ao longo de todo o projeto. Observem os gráficos de performance em horas/PCU desses 2 projetos em que estamos trabalhando atualmente:

 
Horas/PCU - Projeto 2

Como a empresa normalmente pega projetos começando do zero, a performance inicial tende a ser baixa, resultando num alto número de horas/PCU. No começo, muitas questões do ambiente têm que ser resolvidas, os frameworks definidos e estudados, boa parte do negócio deve ser aprendida, a equipe pode estar “fria”, enfim, vários fatores contribuem para a baixa performance.

Mas não se assuste! Ao longo do tempo, a performance tende a estabilizar num número menor. Quando falamos em performance média para o projeto, estamos levando em consideração essas variações inclusive. Isso quer dizer que podemos num projeto aferir uma performance menor que 15 hs/PCU ou até maior que 40 hs/PCU, mas na média do projeto todo, ficaria nesse intervalo.  (Observem no projeto 2 também, o efeito de pesada documentação feita ao final do projeto. Espera-se o mesmo efeito no projeto 1).

Se a equipe já tiver trabalhado no projeto (por conseqüência ele já teria sido iniciado), já conhecer bem o negócio e o código, essa curva tende ser bem mais suave. Isso deve ser considerado ao gerar uma estimativa de performance para o projeto. (Assim como a natureza das próximas funcionalidades: seriam parecidas ou totalmente diferentes das feitas anteriormente? Se forem diferentes, provavelmente a performance média não será a mesma.).

Medidas, cobranças, melhorias e manutenções: o dia-a-dia no projeto

Agora que já sabemos como estimar e como medir software com PCU, resta saber como tratamos isso no dia-a-dia de um projeto.

Normalmente sustentamos alguns modelos de casos de uso ao longo do projeto. Alguns com a visão geral do projeto e alguns que evoluem ao longo das entregas. A visão geral nos mostra o tamanho atual do projeto, conforme o conhecemos.

Utilizamos cores para apresentar os UCs entregues (em verde) e os planejados para a próxima iteração (em azul), além de notas para indicar quais cenários foram ou não desenvolvidos. Ao longo do tempo, o cliente pode ver como evolui a compreensão dele  em relação ao sistema, bem como o que falta e o quanto já foi feito.

Este é um modelo apresentado para entrega. Os Ucs e cenários amarelados já estavam prontos. Os em azul foram os entregues e aprovados pelo cliente na mais recente iteração. Fazemos as medições e atualizações nos modelos mensalmente e os entregamos anexados à uma planilha com a diferença da contabilização dos pontos entre esta iteração e a passada => e é isto que é cobrado.

Por fim, os atores são contabilizados quando um usuário com o perfil do ator em questão já puder usar o sistema, tratadas as questões de autenticação e autorização inerentes a essa funcionalidade.

Parece simples? De fato, só complica um pouco quando você tem vários modelos para a visão geral e para a entrega, mas o princípio é o mesmo.

Se um projeto já existe e entramos para fazer evolução ou manutenção, fazemos a modelagem através do nosso método, como se fosse a visão geral (inclusive identificando os cenários com notas), e tratamos as evoluções ou manutenções como novos cenários nos UCs já existentes ou como novos UCs conforme o caso. Não importa como o projeto tenha sido ou será especificado, nem mesmo se a especificação esteja desatualizada, podemos fazer uma nova modelagem de casos de uso seguindo-se um padrão e tê-la como referência para estimar ou medir o tamanho do sistema.

O Problema com Mudanças

Há um ponto falho tanto em PCU quanto em APF que é o tratamento de mudanças. Numa casa você pode fazer uma reforma, digamos, mudar um piso ou quebrar uma parede pra instalar uma nova tomada, e o tamanho dela em m2 continua sendo o mesmo, não? Em APF ou PCU, o mesmo pode acontecer. Podemos ter mudanças que não implicam em novos UC’s, ou novos cenários, ou a quantidade de campos e operações continuar a mesma.

Mas na casa apesar do tamanho não ter mudado, a reforma gerou mais trabalho e mais custos. Logo, não seria justo refletir o mesmo nas métricas? Quando há possibilidade de se negociar isso, entramos em acordo com os clientes e tratamos as mudanças também como se fossem novos cenários ou novos UC’s. Deve-se haver muito bom senso no dimensionamento das mudanças, ou a confiança pode ser quebrada e isso é altamente prejudicial para qualquer projeto. Recomendamos total transparência nesses casos.

Na intenção de resolver esses problemas, também tenho visto manuais com padrões definidos para certos tipos de mudança, por exemplo: “alteração de botão equivalerá a 0,1 PF” (em recente edital do Min. Transportes saiu um desses).

Se não houver como negociar, o esforço de mudanças deve ser estimado e refletido na performance média. O problema é que isso pode inibir mudanças para se manter a performance estimada, o que não é desejável. Mudanças devem ser bem aceitas e são muito saudáveis para os projetos.

Observem que, ao contrário de PCU, o fato da APF ser aderente à norma ISO/IEC 14.143, que define um modelo para medição funcional de software e ter o manual padronizado pela ISO/IEC 20.926; não resolve bem este problema. Tanto as normas quanto as métricas ainda carecem de evoluções e adequações. Aqui trago apenas uma proposta, que é a forma com que trabalhamos.

Acredito que utilizar mais de uma métrica para gerar estimativas sempre agrega valor à estimativa. Se puder usar ainda outras métricas, use-as! Experimente! Combine! Existem várias. Tem uma cujo nome dá medo só de ouvir: a “Complexidade Ciclomática”, que mede a quantidade de caminhos linearmente independentes através do código fonte de um programa. Imagine seu chefe pedindo pra você estudar isso que a partir da semana seguinte a empresa vai passar a adotá-la? Eu sairia correndo gritando pela porta. Mas a idéia de verificar o tamanho programaticamente a partir do código fonte é boa! Acho que o caminho é por aí, mas primeiro haveria de se resolver a questão da qualidade (tratada no artigo da revista). Aqui todos concordamos que nenhuma métrica mede direito o que realmente dá trabalho de ser feito num software.

Organização e Certificação

De fato não existe uma organização responsável por padronizar e evoluir a métrica de PCU como o IFPUG. Tão pouco existe uma certificação na aplicação da métrica, logo, também não há um grupo de profissionais certificados que saibam comprovadamente aplicar a métrica e apoiar os demais. Isso não torna a métrica ruim. Talvez menos segura. O que existem são tímidas iniciativas independentes de uso, evolução e padronização, como a que apresentei aqui e as dos artigos indicados.

Pensando bem, até que seria uma boa criar uma organização para este fim, cobrar uma anuidade, ter um programa de certificação para valorizar o pessoal no mercado, não? Da forma que está hoje, ninguém está ganhando nada… isto não pode ser bom! :)

Espero ter contribuído de alguma forma para suas estimativas, medições e idéias! Quaisquer críticas, contribuições ou dúvidas serão bem-vindas!

[]s Willi