Notícia fresquinha do front (até meio precipitada talvez, hehehe):

O swell começa a se formar para as bandas do "norte", oxente!

Ainda estamos organizando as coisas e não tem muita informação pra passar… Só estou postando porque sou "barriga fria" mesmo…

Mas veja que não sou só eu e que o pessoal já está começando a se movimentar por aí!

Aguardem!

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