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

Depois da publicação do artigo na Mundo PM sobre uso métricas para venda de projetos utilizando metodologias ágeis, vamos falar um pouco mais do que aprendemos sobre Pontos de Casos de Uso. Como utilizamos para medir, para estimar, os problemas e algumas soluções adotadas.

Começamos a utilizar PCU’s na metade de 2006, utilizando como base principalmente o artigo de Gustav Karner, de 1993. Não vamos explicar como se faz a contagem aqui, pois já existe uma grande quantidade de artigos e sites na internet que explicam isso muito bem (Caso não conheça a métrica, recomendo que se familiarize antes de ler o resto do texto.). No entanto, existem 3 partes que geram muita polêmica e merecem maiores explicações: a medida de complexidade dos casos de uso, os fatores de ajuste e a performance sugerida.

Como medimos complexidade de Casos de Uso

Para medir complexidade dos UC’s, o artigo de Karner menciona contagem de transações ou de classes de análise, mas isso realmente é subjetivo e muito dependente da modelagem dos casos de uso. Essa parte, inclusive, é a origem das maiores críticas à métrica. E com razão!

Há uma grande confusão sobre o que deve ser contado nessas transações: Cenários? Passos? Qual o nível de detalhe de cada caso de uso? E de cada passo?

Nós levamos um tempo pra descobrir a melhor forma de se trabalhar com isso. Hoje, trabalhamos contando apenas os cenários com processamento significativo dos casos de uso, não importando a quantidade de passos que eles tenham, nem o nível de detalhamento de cada passo. Um cenário com processamento significativo é aquele relacionado ao que o ator quer fazer através da funcionalidade especificada no caso de uso e tenha funcionalidades relevantes e observáveis pra ele. Na prática, isso quer dizer que não contamos cenários com mensagens de aviso, apresentação de mensagens de erro ou cancelamento de transações que não efetuem processamento ou não mudem estados de um processo. São os mais comuns de aparecerem.

Mas e o que fazemos em relação à modelagem? A orientação é modelar casos de uso “pequenos”, que façam apenas uma coisa que traga resultado relevante ao ator. Antes, tínhamos o costume de fundir casos de uso semelhantes em casos de uso cheios de cenários, complexos, grandes e genéricos, mas isso não era bom para a métrica. Observamos que na maioria dos sistemas que desenvolvemos, em um nível mais abstrato, fazemos sempre as mesmas tarefas: entramos com dados, trabalhamos com esses dados e os recuperamos – fazendo algum processamento ou não. Um caso de uso deve ter apenas uma dessas tarefas.

O CRUD (Create, Retrieve, Update, Delete) seria a única exceção à essa regra, e apesar de parecer ter 4 cenários, contamos apenas 3: Listar os dados para (1) Selecionar para Editar, (1) Selecionar para Excluir e (1) Cadastrar um novo. Reparem que a listagem não é considerada como um cenário normalmente pois assumimos que não traz resultado relevante ao ator, isto é, o ator não entra no UC para ver uma listagem dos dados com que quer trabalhar e se dá por satisfeito com isso. Ele entra pra incluir, excluir ou editar eles. Se a idéia era consultar ou pesquisar as informações, talvez o ideal seja escrever um novo caso de uso de relatório para ele, com filtros, ordenações, formatações e etc.

Existem algumas dicas que nos oferecem sintomas para sabermos quando a modelagem deve ser revista. Elas não querem dizer que necessariamente algo esteja errado, mas que pode haver alguma necessidade de remodelagem. Vejam esses exemplos:

Ex1: Um sistema que cadastra dados de acidentes automobilísticos. No UC “cadastrar acidente”, os dados de cada automóvel envolvido no acidente podem ser inseridos, depois editados ou excluídos. Em seguida, os dados de cada uma das vítimas e assim por diante.
Desconfiem! Quando aparece uma relação de 1 pra N dentro de um UC, provavelmente estamos trabalhando com mais de um UC. Provavelmente temos alguns outros UC’s (normalmente CRUD’s) sendo incluídos ou estendidos a partir de um “centralizador”. Reparem que fazemos forte uso de includes e extends, inclusive  contabilizando os Ucs incluídos e estendidos na métrica, contrariando alguns guidelines do artigo original. Vejam como ficaria a modelagem deste exemplo a seguir:

Ex2: Um sistema que faz um cadastro completo de instituições de ensino, com informações de endereço, telefones, dados de salas de aula, dados de corpo docente, dados de corpo discente, etc, tem um caso de uso chamado “Cadastrar Instituição” para todos esses dados.
Desconfiem! Quando você tiver muita informação em um só cadastro, o que se mostra por: necessidade do uso de grande barra de rolagem, necessidade de utilização de abas para comportar todas as informações do cadastro, informações aparentemente de contextos diferentes; provavelmente você está trabalhando com mais de um caso de uso. No exemplo, o ideal seria dividir entre cadastro de informação de cada grupo de informações, como na figura abaixo:

Ex3: Um sistema para casas lotéricas que teria apenas o caso de uso “Registrar Apostas” para todos os tipos de apostas de uma casa lotérica. Hoje existem 10 tipos de jogos, cada um com pelo menos um fluxo alternativo, resultando num caso de uso de pelo menos 20 cenários.
Caso de uso de mais de 14 cenários, desconfie! Você pode estar trabalhando com mais de um caso de uso. No exemplo, o ideal seria trabalhar com um UC pra cada tipo de aposta, mesmo com muita repetição. Inclusive, seria mais fácil de gerenciar, de apresentar resultados constantes, facilitaria o entendimento, evolução e comunicação.

Ex4: Um sistema que extrai vários relatórios com indicadores a partir dos mesmos filtros tem o caso de uso “Gerar Relatórios de Indicadores” com um cenário para os filtros e mais um cenário para cada relatório.
Nessas situações normalmente ficamos confusos porque os filtros são os mesmos, e escrever um UC para cada relatório aparentemente gera muito retrabalho. O que acontece é que alguns relatórios são bastante simples e outros bem complexos, e o caso de uso acaba demorando pra ficar pronto, atrasando o feedback e atrapalhando o gerenciamento. Por padrão, utilizamos um UC para cada relatório. Utilizando-se “copy & paste”, o ônus relativo ao retrabalho com os filtros é irrisório frente ao benefício de se trabalhar neste padrão. E na média a métrica funciona muito bem assim.

Desta forma, não resolvemos totalmente o problema da subjetividade na modelagem, escrita e na contagem de cenários, mas conseguimos melhorar bastante e atingimos uma consistência bem adequada à métrica.

Como não trabalhamos com Fatores de Ajuste

A crítica aos fatores de ajuste da métrica normalmente se devem à subjetividade e falta de padrão dos critérios; as pessoas não sabem bem o que querem dizer, como atribuir uma dimensão e isso resulta no projeto poder ter as mesmas funcionalidades e tamanhos dieferentes.

Não tenho nenhuma objeção em relação a esses argumentos. Inclusive, acrescento um fator bem mais crítico: fatores de ajuste não fazem o menor sentido em termos de métrica! Nem pra PCU nem pra Análise de Pontos de Função! Isso porque os fatores considerados não devem afetar o tamanho de um sistema, mas a complexidade e o esforço para produzí-lo. Seria como dizer que um apartamento de 100 m2 seria maior que uma casa de 100m2 porque construir prédio é mais complexo. Ora, cem metros quadrados são cem metros quadrados! Independente do trabalho pra se construir, qualidade da construção, conhecimento ou qualificação da equipe de construção.

Esse erro se dá ao fato de usarmos métricas para estimarmos esforço para desenvolver um software, não para estimar ou medir o tamanho dele. Nossa proposta é apenas estimar e medir tamanho, e como o uso de fatores de ajuste é opcional, preferimos não utilizá-los. Tanto em PCU quanto em APF.

Outro perigo dos fatores de ajuste é sua determinação de antemão em um contrato. Principalmente para os fatores ambientais que determinam qualificação, motivação e conhecimento da equipe (extremamente subjetivos). Ao longo do contrato a situação pode mudar e isso afetaria a métrica (e o tamanho do software! que absurdo!), e o contrato pode não permitir o ajuste da métrica, podendo gerar prejuízos. Por isso, preferimos ignorá-los de vez! Usamos pontos de caso de uso não ajustados, tanto para estimar quanto para medir tamanho de sistemas.

Performance em Pontos de Caso de Uso

Outra fraqueza da métrica é sugerir uma performance pra cada PCU: 20 horas. E 28 dependendo de uma combinação dos fatores de ajuste. Pesquisando em artigos, achei relatos de performance de 15 a 36 horas/PCU. É muito delicado sugerir ou estimar uma performance média sem antes levar em consideração questões importantes como linguagem de programação e ambiente. Em 93, quando Kerner fez o artigo, a maioria dos sistemas era stand-alone. E Java nem existia! Como poderíamos adotar a mesma estimativa de esforço para nossos sistemas atuais, feitos em Java para a Web?

Começar a utilizar qualquer métrica para gerar estimativas é um grande desafio para qualquer empresa, pois não se sabe sua performance. Existem vários artigos mostrando como medir sistemas em PCU, mas poucos trazem resultados das medições ou performance. A razão disso é, em parte, estratégica. Em 2006 não tínhamos muito pra onde correr, então começamos com 20hs/PCU mesmo.

Hoje sabemos, por exemplo, que a performance média da empresa em Java para sistemas Web varia de 15 a 40 horas/PCU, dependendo de várias coisas – e aqui sim os fatores de ajuste fazem sentido. Antes de entrar nesse detalhe, se imagine perguntando a um engenheiro quanto custa ou quanto tempo leva pra fazer uma casa de 100 m2? Não faz muito sentido, faz? Ele pode até dar uma estimativa baseada no valor médio do m2, mas provavelmente vai querer saber mais alguns detalhes do projeto, como quantidade de cômodos, qualidade dos materiais de construção, quantidade de andares, se é uma casa de luxo ou se é um barracão, quantos banheiros e etc. Muitas empresas andaram vendendo projetos de software baseados no custo médio do PCU ou APF, e a qualidade dos sistemas pagou o preço por isso. Agora você não vai mais fazer isso, vai?

Concluindo, para ajustar a performance ao projeto, todos os fatores de ajuste das métricas fazem sentido. Além deles, todos os que você considerar que colaborem ou prejudiquem a produtividade. Consideramos, por exemplo: metodologia de desenvolvimento, curvas de aprendizado (na linguagem, tecnologia, metodologia, sistema), se o sistema será colocado cedo em produção, se o ambiente de desenvolvimento é o mesmo que o de produção, se a equipe conhece ou já trabalhou no projeto, colaboração do cliente, utilização de testes automatizados, se uma massa real de teste será utilizada, se o ambiente de implantação é complexo, disciplina e experiência da equipe, etc.

Todos esses fatores, se bem atendidos, trarão a estimativa da performance média para próxima de 15 hs/PCU. Quanto menos critérios atendidos, mais será empurrada para 40 hs/PCU. A influência de cada critério na média ainda é pouco conhecida. Temos projetos de referência que, aliados ao conhecimento das equipes, tem nos servido bem. Mas uma boa técnica para ajustar a estimativa de performance média para o projeto é estimar seu tamanho e fazer uma sessão de planning poker com colaboradores da empresa e chegar a uma estimativa grosseira de horas. Dividindo-se as horas pela estimativa, tem-se algo pra começar a trabalhar.

As últimas dicas que gostaria de deixar aqui, são de dois artigos bem recentes, um trata de usar diferentes formatos de especificações para estimar esforço usando PCUs. Ele traz definições interessantes para passos, transações, cenários, além de “insights” para modelagem, formas de trabalhar com funcionalidades em batch. Muito bom para diminuir a subjetividade do método. É o “Use Case Points Effort Estimation based on Different Specification Formats”, de Stephan Frohnhoff e Karsten Kehler.

O outro, de 2008, faz um estudo utilizando a métrica original de UCP e propõe uma evolução para a métrica, baixando o erro de 42% para 20%. Propõe melhorias e incrementos para os fatores de ajuste, inclusive adicionando a linguagem de programação e o processo. Realmente imperdível, é o ”Revised Use Case Point Method - Effort Estimation in Development Projects for Business Applications”, de Stephan Frohnhoff e Gregor Engels.

Por fim, mostramos como medimos e como estimamos o esforço para desenvolver um software. Sabemos medir a casa, classificá-la como barraco, casa normal ou mansão e sabemos quanto trabalho teremos para construí-la. Mas ainda falta sabermos como a métrica se comporta ao longo do projeto, como fazemos estimativas e como trabalhamos com a métrica no dia-a-dia. Isso vai ficar para o próximo post.

Até a próxima!
Willi