Projetos de TI e Estimação

“O problema é que o desenvolvimento de software é um importante esforço, mas não amadureceu como processo de engenharia, ainda é uma forma de arte”.

Craig Mundie
Executivo-chefe de pesquisa e estratégia da Microsoft
http://idgnow.uol.com.br/computacao_corporativa/2007/06/05/idgnoticia.2007-06-05.7937781119/

Normalmente, definem-se indicadores de desempenho sobre pessoas, artefatos (produtos) e atividades, procurando estimar tempo ou gasto financeiro. No caso de projetos de TI, entretanto, surge um agravante: processo, seja ele de desenvolvimento ou de gerência. Dependendo do processo, ocorre uma variação muito grande nos parâmetros pessoas-artefatos-atividades, tornando os indicadores de pouca valia (em parte, daí surgem os 400% de erro do Boehm...) Supondo-se uma maturidade do processo (no sentido CMM, por exemplo) os parâmetros passam a ter um comportamento mais estável (embora o parâmetro pessoa seja fortemente influenciado pelo paradigma de programação, que é outro elemento com marcante influência na definição de indicadores).

Mas aí um novo desafio surge. Os modelos de indicadores tradicionais são definidos acentuadamente em termos das atividades realizadas. Em projetos de TI, no entanto, como medir o andamento de uma atividade de análise? Quanto da análise já foi realizada? Essa pergunta faz sentido? A resposta é: não! Sem acompanhar a realização de uma atividade, como averiguar a performance da pessoa que a realiza? A possibilidade é observar o progresso do artefato... Mas o artefato-alvo de um projeto de TI chama-se: computação. Tal artefato é intangível e móvel (transforma-se com a velocidade das alterações dos requisitos). Assim, como acompanhar o progresso de um alvo intangível e móvel? Nem PMBOK consegue!

Obviamente, muitas pesquisas têm sido realizadas no sentido de se encontrar indicadores para projetos de TI: até agora nada. Apenas para ilustrar, Pontos de Função (IBM, 1979) pressupõem um paradigma de programação centrado em modelagem por decomposição funcional, mas tal paradigma entra em conflito com o paradigma de programação centrado em implementação por objetos, por exemplo, e os indicadores perdem seu sentido de existência. Mesmo com a "reciclagem" da proposta, a instabilidade dos requisitos dificulta o cálculo de indicadores úteis para estimações de projetos de TI.

Outra situação ocorre se houver a tentativa de se empregar algum processo ágil. Já chegamos em "Kanban para software": linha de produção? Ainda não conseguimos responder porque 70% dos projetos de TI fracassam (vide relatórios do Standish, que apenas observam se o projeto foi encerrado dentro do prazo e do orçamento e se os requisitos foram atendidos e controvérsias...)!!!

Resultado: existem muitos modelos de indicadores de desempenho para projetos de TI. Podem e devem ser utilizados para estimação, hoje?

Projetos de Jogos: Aspectos Gerenciais

INTRODUÇÃO

Seguindo a proposta do Unified Process, um projeto de desenvolvimento de software deve se preocupar com dois importantes aspectos: (i) a engenharia do software (tudo aquilo relacionado com a fabricação e o software -- processo e produto) e (ii) a gerência do projeto (tudo aquilo que se refere à infra-estrutura necessária para a fabricação).

Em cada determinado projeto, a engenharia do software deve ser conduzida de acordo com um processo de trabalho. Ao longo dos anos, diversos modelos de processos foram investigados e experimentados. Três grandes categorias de modelos de processos podem ser identificadas: (i) lineares, como o Waterfall, (ii) espiral, como o Spiral, (iii) iterativos e incrementais, como o Unified Process. Recentemente, percebeu-se que aqueles modelos de processos da categoria (iii) apresentavam melhores resultados finais (conseguia-se fabricar o software do projeto com uma alta taxa de sucesso, quando comparada às demais categorias de processos).

PROJETO DE SW DE JOGOS

A realização do projeto de software de um jogo é diretamente influenciado pela natureza do software. Intangibilidade é parte dessa natureza. Volatilidade de requisitos também. Particularmente, esses dois aspectos da natureza de um software conduzem a uma grande dificuldade para a gestão do projeto em si. Esses ingredientes tornam não-convencional a gerência do projeto exigindo modelos gerenciais específicos, sob pena de ocorrer uma divergência da gestão em relação ao processo e ao produto do projeto.

Risco é um aspecto vital para a gerência de projetos. A questão "O que pode dar errado?" quase que impõe uma atividade gerencial conhecida por planejamento. No caso de produtos de software, a pergunta ainda embute, de forma implícita, a intangibilidade e volatilidade daquilo que pode dar errado (enquanto produto) e das atividades mentais de fabricação, que pouco podem ser rastreadas sem um registro apropriado. Em um projeto de jogo, isso exige daqueles diretamente envolvidos no software considerem as implicações de todas as suas atividades. Sempre que um novo elemento do jogo é integrado no software, ocorre um progresso na conclusão do projeto. Entretanto, isso provoca um aumento da complexidade (do software), cuja lei de crescimento tem forma exponencial. Ou seja, a introdução de erros de implementação ao longo do tempo torna cada vez mais cara a sua localização e subsequente correção (em diversas unidades de medida, não apenas a financeira).

VISÃO PESSOAL

Não conheço, em profundidade, literatura específica sobre o tema "Projetos de Desenvolvimento de Jogos, visão de Software". Irei estudar a respeito. Entretanto, acredito que diversos elementos do P(FTP)L devam ser contextualizados e experimentados. (P(FTP)L: Processos, (Ferramentas, Técnicas, Práticas), Linguagens, by Ítalo.)

SUGESTÃO

Em um curso sobre Produção de Jogos, seria interessante trabalhar com:

1) Linha temática suplementar: Gestão de Projetos de Implementação de Jogos.

2) Técnicas e práticas de gestão:

- Apresentação e crítica técnica dos projetos conduzidas pelos próprios alunos. Professor atua como moderador das participações dos alunos, incentivando a percepção de características (positivas e negativas) dos projetos, pontos de melhorias e adaptações, sugestões, etc.. Professor também deve assumir o papel de crítico, quando for apropriado.

- Organização do tempo do projeto. Professor ajuda na elaboração de calendários (cronogramas) de intenções e de comprometimentos. Cada fator de risco do projeto deve ser avaliado quanto a sua investigação e prioridade.

- Etc.

BIBLIOGRAFIA PRELIMINAR

• Flynt, J. P.; Salem, O. Software Engineering for Game Developers. Course Technology PTR, 2004.
• Braude, Eric. Software Design: From Programming to Architecture. John Wiley & Sons, 2004.
• Martin, Robert C. Agile Software Development: Principles, Patterns, and Practices. Pearson Education, Inc, 2003.