Estratégias de Planejamento 31

Como dito anteriormente, um dos aspectos fundamentais do planejamento e gerenciamento de projetos é a previsão de quanto tempo o desenvolvimento de um projeto irá durar. Estabelecer estimativas de prazos e custos mais realistas se torna um problema muito mais grave no contexto de empresas de pequeno porte que lidam diariamente com a pressão do mercado para construir sistemas de qualidade com prazos restritos.

No sentido de obter estimativas mais precisas, combinando planejamento e controle, de forma a manter o planejamento constantemente ajustado, Sanchez (2008) propôs a Estratégia de Ajuste por Pontos por Caso de Uso Baseada no PSP (PCU|PSP). Essa estratégia foi construída com base no aprendizado obtido na empresa de desenvolvimento de software Linkway, pelo uso constante da técnica Pontos por Caso de Uso – PCU (KARNER, 1993) e da utilização do Personal Software Process - PSP (HUMPHREY, 1995).

A Linkway é uma empresa de pequeno porte localizada na cidade São Carlos que busca constantemente a melhoria do processo de software. Essa preocupação fez com que a empresa adotasse o uso do PSP. Assim, a equipe de desenvolvedores usa as principais práticas do PSP 1.1, relacionadas à estimativa de projeto, juntamente com a ferramenta Process Dashboard (DASHBOARD, 2010) que dá suporte ao PSP.

A estratégia PCU|PSP consiste na combinação do PSP com o PCU, sendo que o PCU fornece as estimativas de tamanho (complexidade) e de tempo para a codificação do software, enquanto o PSP determina as bases disciplinadas de um processo pessoal de desenvolvimento que visa à melhoria da qualidade e da produtividade (SANCHEZ, 2008).

A estratégia PCU|PSP apresentada na Figura 2.3 é composta de 9 etapas agrupadas em dois grandes blocos de atividades que são executados constantemente e que se completam, um de planejamento e outro de controle; por meio do feedback das atividades executadas nestes blocos, o planejamento é constantemente ajustado. O bloco de planejamento permite que estimativas adequadas de tamanho, prazo e custos sejam determinadas antes do desenvolvimento do sistema. O bloco de controle verifica se o planejamento estabelecido está sendo obedecido e, caso não esteja, determina os motivos desse fato.

Figura 2.3 - Estratégia PCU|PSP (SANCHEZ, 2008)

Na etapa 1 o Gerente realiza, juntamente com os desenvolvedores, a Reunião de Planejamento em que são discutidos todos os cenários dos Casos de Uso existentes. Nessa reunião é determinada a complexidade dos Casos de Uso, os níveis de influência dos Fatores de Complexidade Técnica e níveis dos Fatores Ambientais.

Na etapa 2 o Gerente realiza o Planejamento de alto nível de todo o projeto baseado no consenso obtido na etapa anterior, sobre os casos de uso. Nessa etapa, através da aplicação do método PCU é possível ter uma estimativa do tamanho do sistema por meio da soma dos Pontos por Caso de Uso. Para determinar o custo e o tempo de desenvolvimento, devem ser multiplicados os PCU atribuídos a cada

desenvolvedor pela variável de Nível de Esforço (NDE) definido individualmente utilizando o PSP.

Na etapa 3 o Planejamento de alto nível da etapa 2 é usado para montar o planejamento detalhado de cada cenário. Os casos de uso são decompostos em cenários sendo que cada cenário pode ser decomposto em rotinas menores. Cada Desenvolvedor deve realizar o planejamento de cada uma das rotinas, de acordo com o PSP Nível 1.1, incluindo um cronograma detalhado de desenvolvimento limitado a duas semanas.

Na etapa 4 o desenvolvedor inicia a atividade de desenvolvimento incluindo codificação, testes e correções. Ao finalizar o ciclo de desenvolvimento de cada rotina inicia-se a etapa 5. Nessa etapa, chamada no PSP de postmortem, o desenvolvedor analisa seu desempenho em comparação ao desempenho estimado durante o planejamento realizado na etapa 3.

Durante a etapa 6 o Desenvolvedor, ao finalizar um conjunto de rotinas que caracteriza um cenário, deve informar esse fato ao Gerente que, por sua vez, deve comparar o desempenho real do desenvolvedor com o desempenho especificado no planejamento de alto nível. Ao concluir a etapa 6, caso haja grande diferença entre o desempenho estimado e realizado, o fluxo de execução muda para a etapa 8, onde deve haver uma reunião de Controle a fim de encontrar possíveis causas e meios de resolver o problema. Os Fatores Ambientais são ajustados e o próximo cenário é selecionado para execução.

Na etapa 7, quando todos os cenários de um Caso de Uso foram desenvolvidos o gerente deve comparar o esforço estimado para o desenvolvimento desse Caso de Uso com o tempo real gasto para tal atividade. Dessa forma, na etapa 9, o NDE de cada desenvolvedor pode ser ajustado logo no primeiro Caso de Uso concluído, para que seja possível refletir sobre a relação entre Pontos por Casos de Uso e o esforço em horas/homens, para cada desenvolvedor individualmente. Para realizar este ajuste é necessário dividir o tempo real gasto, fornecido pelo PSP após a conclusão do Caso de Uso, pela soma dos Pontos dos Casos de Uso já desenvolvidos pelo desenvolvedor. Este mecanismo deve ser repetido sempre que um Caso de Uso seja finalizado, ou seja, acumulam-se o tempo gasto e os Pontos por Caso de Uso já realizados e divide-se o primeiro pelo segundo.

Para se aplicar a estratégia PCU|PSP a uma equipe com vários Desenvolvedores, o gerente deve montar o cronograma geral do projeto aplicando a Estratégia PCU|PSP para cada desenvolvedor.

Com as informações geradas pelo uso do PSP o gerente pode avaliar o desempenho dos desenvolvedores e ajustar o planejamento do software. As informações utilizadas pelo gerente são derivadas do uso do PSP até o nível 1.1.

Segundo Sanchez (2008), a implantação do PSP deve se dar de forma gradual, de acordo com os níveis estabelecidos no processo. Assim, a primeira coisa a ser feita é implantar o Processo de Medição Pessoal, que comporta os níveis 0 e 0.1 do PSP. Com isso, o desenvolvedor se habitua a registrar os tempos e passa a ter um maior conhecimento de seu próprio processo de desenvolvimento.

No nível PSP 0, são executados o Processo Atual (Análise, Projeto, Codificação, Compilação, Testes e Postmortem), o Registro de Tempos, o Registro de Defeitos e o Padrão de Tipos de Defeitos. Após o completo entendimento do PSP 0, o gerente pode mudar para o nível PSP 0.1 em que as atividades padrão de Codificação, Medida de Tamanho e PIP (Process Improvement Proposals) são acrescentadas ao cotidiano do desenvolvedor.

Após a incorporação dos níveis PSP 0 e PSP 0.1 Sanchez sugere ainda que o gerente continue a motivar a utilização dos outros níveis do PSP, como o PSP 1.0 e o PSP 1.1. No PSP 1.0 o desenvolvedor realiza as atividades de Estimativa de Tamanho que equivale no PCU|PSP à atividade de planejamento das rotinas dos Casos de Uso, realizada na Etapa 3. É nessa etapa também que os requisitos do PSP 1.1 são atendidos e o desenvolvedor realiza o Planejamento das Tarefas e o Cronograma, de forma que o desenvolvedor faz as estimativas do tempo para o desenvolvimento de cada rotina de um Caso de Uso e planeja as tarefas a executar. Baseando-se no planejamento de cada rotina o cronograma é montado e o gerente pode avaliar se o cronograma e o tempo alocados pelo desenvolvedor estão condizentes com a realidade.

Dessa forma, a estratégia PCU|PSP apresentada por Sanchez, provê auxílio à gerência de projetos, baseando-se no ajuste dos Pontos por Caso de Uso com dados provenientes do uso do PSP. Essa estratégia aborda tanto o planejamento obtido com a aplicação do método PCU, como o tempo gasto com o desenvolvimento e o acompanhamento do progresso do projeto, obtido com o suporte do PSP. Em especial, o PSP supre a deficiência do PCU em estimular a

melhoria pessoal do desenvolvedor para que ele aprenda a estabelecer processos mais eficientes. A estratégia propõe também a coleta de dados estatísticos existentes nas fases de desenvolvimento de software e provê cobertura ao modelo de processo PSP até o nível 1.1. Permanece a lacuna de possibilitar suporte às fases posteriores do PSP e ao ciclo completo de detecção e remoção de defeitos existente no PSP, bem como a coleta de dados relativos a tempo e custo relacionados a esses defeitos.