Estamos numa espécie de cruzada na resolução deste problema, tão maior que a gente, que é o de se trabalhar utilizando metodologias ágeis no governo. As dificuldades são enormes, e ainda não há solução satisfatória, mas em que ponto estamos no momento?

No Ágiles 2009, fizemos uma apresentação sobre este tema (abaixo).

Seguida pela entrevista do Alê pelo Luiz, da Bluesoft:

Entrevista com Alexandre Gomes da SEA Tecnologia no Ágiles 2009 from Bluesoft on Vimeo.

Resumindo a conversa, devido a uma combinação de várias Leis e acórdãos do TCU, o Governo passou a considerar desenvolvimento de software como sendo um serviço comum, sendo obrigado a ser adquirido via pregão. E a unidade de software licitada é normalmente baseada numa métrica, a maioria Pontos por Função.

Uma das conseqüências do uso de pregões para aquisição de software tem sido a diminuição da necessidade de comprovações técnicas, que ocorriam nas licitações do tipo técnica e preço. Por exemplo, onde antes se pedia MPS.BR nível A, hoje aceita-se qualquer certificação MPS.BR. O mesmo vale para o CMMI. E também já faz algum tempo que certificações de profissionais não são mais pedidas como critérios de pontuação técnica, visto que a empresa não precisa ter o profissional contratado antes do início do projeto. As comprovações técnicas dos profissionais são pedidas no momento do contrato, já definido o ganhador do pregão.

Um dos objetivos dos órgãos públicos estarem diminuindo esses critérios para participação é permitir a concorrência entre mais empresas e diminuir o preço do serviço, visto que este é considerado serviço comum. Isso tende a diminuir a força e a fatia de mercado de médias e grandes empresas dentro das áreas de Tecnologia da Informação do governo (será que estavam satisfeitos com elas?). Mas vamos analisar a questão de serviço comum por um instante.

A Lei nº 10.520/02, define que bens e serviços comuns são aqueles cujos padrões de desempenho e qualidade possam ser objetivamente descritos no edital, por meio de especificações usuais no mercado. Mas observem nos slides os “objetivos” padrões de desempenho e qualidade que caracterizam software como serviço comum (e tirem suas próprias conclusões).

Acreditamos que ainda existem algumas fragilidades nessas definições para podermos considerar desenvolvimento de software como serviço comum. Por exemplo: concordamos que haver mecanismos de gestão do projeto favorece que os projetos estejam mais sob controle e que documentação aumente as chances do sistema ser melhor manutenível, mas e se forem mal planejados? Quais são os critérios de qualidade de um plano? Ou de um documento de visão? Ou de um documento de arquitetura? Quando existem, são caracterizados pela presença de tópicos (ex: documento de visão ter definição do problema, necessidades, características e definição dos usuários) e validação de um profissional. Mas isso não seria ainda muito subjetivo? Você pode definir mal o problema, as necessidades e mesmo assim esses tópicos constarem no documento. E a documentação também pode ficar obsoleta. O profissional vai usar quais critérios objetivos para validar a documentação? O mesmo vale para os questionários e aceites normalmente utilizados.

Reiterando: consideramos todos esses mecanismos válidos para aumentar as chances da qualidade do resultado, mas ainda não podem ser considerados como definitivos para tal finalidade. Por isso proporemos novos critérios, baseados em métricas de qualidade como cobertura de testes e taxa de duplicidade do código que, assim como os atuais, também favorecerão a qualidade do software entregue, bem como manutenibilidade e documentação do código.

É claro que pode-se ter um software 100% coberto por testes e ainda assim estes testes serem ruins. Nenhuma métrica totalmente objetiva jamais será perfeita. O fato é que haver testes automatizados no software aumenta as chances de ele ter qualidade, ser melhor documentado e mais manutenível ao longo do tempo.

Observe que estes critérios não resolveriam o problema da qualidade no momento da contratação, pois as métricas só seriam aferidas nas entregas. Mas, ao longo do tempo, descartando-se as empresas que não entregam software com qualidade (por exemplo, numa eventual fase de homologação), haveria uma adaptação dos produtos e do mercado para uma realidade melhor.

Por que o interesse nesses novos critérios? Porque apesar das boas intenções, as conseqüências desse formato de contratação não têm sido boas. Os preços de fato caíram muito, mas muitas empresas não estão conseguindo entregar os sistemas. E muitas delas entregam sistemas de qualidade muito ruim, o que em muitos casos deverá resultar em nova contratação para o mesmo projeto (Isso já foi noticiado na imprensa.). Ou seja, não está havendo economia de fato. Acreditamos que esse modelo tende a colapsar. Ainda há necessidade de adaptação a esse novo formato, e acreditamos que estas métricas de qualidade de código contribuem para isso.

Outra razão (mais particular), é que nós trabalhamos com testes automatizados, sabemos que isso favorece a qualidade dos sistemas e sabemos o quanto isso melhoraria os sistemas que têm sido desenvolvidos para a população. Só que até então, não observamos nenhum retorno desse diferencial. O desenvolvimento está nivelado por baixo. Então a idéia é tangibilizar essa qualidade para que seja valorizada e requerida em editais, para que todos que trabalham como trabalhamos e agregam o valor que agregamos no código possam se beneficiar disso.

Portanto, nossa próxima batalha é essa: tangibilizar a qualidade que dizemos agregar, de forma a contribuir para aumentar a qualidade do serviço de desenvolvimento de software prestado ao Estado. Depois, tentar sensibilizar o governo em quanto a isso, para que possa melhorar seus editais de contratação (quiçá, Acórdãos e Leis!). Quem tá junto nessa?
Já existe um grupo discutindo isso. Se tiver interesse em participar, mande um e-mail para renato ponto willi arromba seatecnologia ponto com ponto br.

[]s
Willi

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