Planejar e controlar projetos de software são atividades que boa parte das empresas tem conseguido desempenhar em seu processo de desenvolvimento. Porém, medir qual desenvolvedor é mais produtivo, re-alimentar o processo de estimativa e coletar informações para tomada de decisão quando o projeto “sai dos trilhos” é uma tarefa bastante complicada.

Neste artigo, vou apresentar a experiência que implantamos na área de Produção de Software da Agence para medição da produtividade.

Primeiro Passo: Estimativa

Qualquer planejamento de projeto de software é elaborado com base em uma estimativa, especialmente em “Fábricas de Software” que muitas vezes trabalham com projetos de escopo fechado e orçamento pré-definido.

Na Agence, usamos basicamente três métodos para estimar o tamanho de um projeto:

Para pequenos projetos, inferiores a 300 horas, usamos uma Planilha de Estimativa onde são estimadas horas de trabalho para cada uma das disciplinas da Engenharia de Software (análise e projeto, requisitos, codificação, testes, implantação, etc.). Este método é bastante simples, mas exige experiência do profissional que faz a estimativa, é bastante suscetível a falhas e é calçado em um histórico de experiências anteriores do mesmo tipo.

Para projetos maiores, usamos contagem de Pontos por Função e/ou de Pontos por Caso de Uso. Esses métodos têm o embasamento científico de várias pesquisas com projetos de empresas diferentes e devem ser calibrados pela complexidade e natureza do projeto e também pela qualidade da equipe.

Segundo Passo: Planejamento

Com a estimativa em mãos, é hora de planejar o projeto. Na Agence trabalhamos com o modelo Iterativo e Incremental de ciclo de vida. Logo, a primeira fase do planejamento é definir as iterações do projeto e quais artefatos serão entregues em cada uma.

Seguindo o princípio do Unified Process (UP), temos quatro fases no ciclo de vida do projeto: Iniciação, Elaboração, Construção e Transição.

A fase de Iniciação na maioria dos casos refere-se à prospecção do projeto junto ao cliente e não possui um planejamento formal. Nesta fase o Consultor de Negócio (figura do Analista de Requisitos) entrevista o cliente, documenta os requisitos e prototipa a solução. Nesta fase o projeto é estimado e uma proposta apresentada ao cliente. Se o cliente aprovar, o projeto continua.

Na fase de Elaboração, o planejamento do projeto como um todo é elaborado. Além disso, o Modelo de Casos de Uso é detalhado e a Arquitetura da Solução é desenvolvida. Nesta fase, existe uma maior participação do Gerente de Projeto, Analista de Requisitos e Arquiteto.

A partir da fase de Construção que o trabalho pesado começa. Nesta fase, há sempre uma versão utilizável do sistema (ou incremento) produzida por mês, independente do tamanho do projeto ou da equipe. Essa entrega da versão formaliza o término de uma iteração e início de outra.

Na fase de Transição, o software é instalado em ambiente de homologação/produção e avaliado pelo cliente e usuários final. Muitas vezes são executados testes de carga e stress, projetos pilotos da operação do sistema e treinamentos.

Terceiro passo: Controle

Diariamente, os profissionais fazem seu trabalho e registram as horas gastas em uma ferramenta de controle de projetos. No final de cada iteração o Gerente de Projeto mede os registros de trabalho dos profissionais e compara com os valores inicialmente estimados.

Naturalmente, o cliente fará uma avaliação da versão entregue no término da iteração e novas pendências podem aparecer. O tempo para os ajustes geralmente está contabilizado na estimativa para o desenvolvimento da funcionalidade.

Mas o ponto é, para medir a produtividade, é necessário dividir a quantidade de horas de trabalho pelo tamanho em pontos (de função ou casos de uso) da funcionalidade. Por exemplo, se o desenvolvedor codificou uma funcionalidade que totaliza 5 pontos de função (PF) em 40 horas (h), sua produtividade é de 40 h / 5 PF = 8 h/PF (lê-se quatro horas por ponto de função). Desta forma é possível obter uma produtividade média da equipe e avaliar os desenvolvedores que têm um desempenho menor ou maior.

É importante salientar que quando a estimativa é feita, é normal que se tenha 12 h para cada PF. Esse tempo, porém, é dividido entre todas as atividades do processo de desenvolvimento: codificação, testes, análise e projeto, requisitos, gerenciamento, implantação, etc. Logo, se for considerado apenas o tempo de codificação, consideramos de 40 a 50% do tempo estimado para cada PF. Assim, uma funcionalidade que tenha 2 PF, com a relação de 12 h por PF na estimativa, não pode gastar mais que 12 horas com codificação, incluindo os ajustes solicitados pelo cliente. Logo, um desenvolvedor com a produtividade de 8 h/PF não é uma boa média, que será, no máximo, 6 h/PF.

De posse dessas informações, é possível, já inicio do projeto, tomar atitudes para evitar atrasos no cronograma ou prejuízos financeiros. No término no projeto, essas informações servem de base para próximas estimativas, definido um fator de horas por ponto de função ou de caso de uso aplicável para a empresa em determinados tipos de projetos.

E na prática?

Em um próximo artigo, vou apresentar uma forma de medir produtividade na prática usando a ferramenta Jira. Para quem não conhece, o Jira é uma ferramenta paga, porém com preço bastante acessível, para controle de pendências e gerenciamento de projetos. Até lá!