Todos desejamos que nossos projetos de software sejam entregues dentro do prazo e do orçamento*. O software é complexo e, a menos que planejemos o sucesso, é improvável que “simplesmente aconteça”. Ao planejar projetos de software, felizmente temos a experiência de falhas passadas com as quais podemos aprender. Deveríamos aproveitar o que aprendemos com esses erros para que nossos projetos possam evitar o caminho “patológico”.
O que queremos dizer com um projeto atrasado? Atraso é realmente sobre um projeto sendo entregue atrasado em relação às expectativas, ou em outras palavras, atrasado em relação à estimativa. Para evitar decepções, precisamos criar expectativas (estimativas) realistas E precisamos realizar as atividades para evitar problemas que possam levar ao não cumprimento das estimativas.
Em um estudo com 84 projetos da IBM e da AT&T, Capers Jones observou que os projetos que atrasaram 6 meses ou mais mostraram pouca evidência de problemas nos estágios iniciais. Os últimos projectos tinham poupado muitas actividades cruciais, nomeadamente: revisões de requisitos, inspecções, controlo de qualidade. Tudo isso envolve atenção precoce à qualidade.
Por que eles foram estimados incorretamente? A estimativa foi inadequada ou as atividades que poderiam mantê-la dentro do prazo não foram bem executadas.
Capers cita 10 fatores que levam à incompatibilidade estimada/real:
*Algumas partes se beneficiam dos custos extras gerados quando um projeto é estendido.
Como a IA pode ajudar
O planejamento começa cedo, conforme você conhece ou descobre os requisitos. O ScopeMaster usa IA para ajudá-lo a entender os requisitos muito rapidamente. O que leva a planos melhores.
Fatores que afetam a programação do software e estimar a confiabilidade
| Fator | Descrição | Impacto no cronograma | Mitigação |  |
|---|---|---|---|---|
Erros de métricas |
O uso de métricas inadequadas, como Story Points ou similares, levará a estimativas ruins | Até 100% | Use dimensionamento funcional, pontos de função COSMIC | O ScopeMaster automatiza o dimensionamento funcional e elimina a maioria desses erros. |
Ajuste tecnológico |
Incerteza/atraso causado na introdução de novas ferramentas/tecnologias/técnicas | Impacto observado pode causar erros de estimativa de até 150% | Aguarde pelo menos um mês para que a nova tecnologia seja incorporada ao uso, planeje isso | |
Erros de caminho crítico |
A ilusão de que o progresso está no caminho certo até que o projeto seja interrompido por um evento de bloqueio | Erro em horários de até 25% | Um melhor monitoramento do caminho crítico e a mitigação proativa de riscos técnicos podem minimizá-los. | O ScopeMaster estimula a reflexão antecipada sobre complexidades e integrações, que são causas comuns de problemas de CP |
Problemas de dimensionamento/escopo |
Subestimar mal a verdadeira magnitude de um projeto levará ao aumento do trabalho e do cronograma. A qualidade e a integridade dos requisitos também afetam a capacidade de dimensionar corretamente | Erro 15-100% | O dimensionamento funcional e a verificação automatizada de integridade ajudarão a mitigar isso. | Resolvido pelo ScopeMaster (mesmo para gerentes de projeto inexperientes). |
Requisitos crescentes do usuário |
A alteração dos requisitos (distinto dos requisitos ausentes) levará ao aumento do trabalho e do cronograma. | As taxas de erro são maiores em projetos mais longos 2-10% por mês | Isso deve ser planejado e adotado (Ágil). | O ScopeMaster ajuda de diversas maneiras: melhorando a qualidade dos requisitos iniciais, melhor elicitação e rastreamento de volatilidade |
Erros de atribuição |
Deixar de alocar pessoal adequado para uma atividade dentro de um projeto. Cada pessoa que desempenha uma determinada função tem uma capacidade finita para realizar o trabalho e precisa ser designada no momento apropriado do projeto. | Erro até 100% | Gerentes competentes que entendem as capacidades de atribuição (veja abaixo). | O ScopeMaster ajuda fornecendo um tamanho funcional a partir do qual os escopos de atribuição podem ser determinados. |
Erros de taxa de produção |
A diferença entre a taxa de produção esperada e real. | 20-100% | Medidas realistas e apropriadas da taxa de produção ajudarão, por exemplo. CFP/mês para uma determinada equipe. | O ScopeMaster ajuda fornecendo um tamanho funcional a partir do qual as taxas de produção podem ser medidas, avaliadas e monitoradas. |
Aumento de pessoal |
Não mobilizar o número certo de pessoal com as competências certas no momento certo causará atrasos. | Provavelmente terá impacto por semanas ou até meses. | Gerentes competentes devem planejar adequadamente. | O ScopeMaster ajuda fornecendo um tamanho funcional a partir do qual a atribuição e os escopos podem ser determinados. |
Seleção de Tarefas |
Deixar de considerar todas as atividades do projeto – e não apenas a codificação – levará a erros de agendamento. | Observado até 1000% | Os gestores competentes devem planear todas as atividades de forma adequada. | |
Interferência Executiva ou Política |
Os executivos decretam prazos ou outras restrições inadequadas que levam à má qualidade. | Erro até 50% para agendamento, 100% para custos | Os gestores competentes devem reagir duramente a tal interferência. | O ScopeMaster cria estimativas de tamanho funcional a partir das quais cronogramas realistas podem ser determinados e usados como defesa. |
Planejamento Baseado em Atividades com base no tamanho funcional
Planejando projetos de software
O fator mais crítico na determinação da duração de um projeto é o seu tamanho. Por tamanho estamos nos referindo ao tamanho funcional. O tamanho funcional é o meio mais confiável de dimensionar um projeto de software. Ao contrário dos pontos da história (que são uma estimativa de esforço de engenharia não linear e subjetiva), o tamanho funcional é geralmente consistente, dentro de alguns %, independentemente de quem o dimensiona.
Para determinar o quanto de cada atividade é apropriado em nosso projeto, precisamos entender tanto o escopo da atribuição (quanta capacidade um indivíduo pode suportar) e sua taxa de produção (quanta capacidade eles podem atender em um determinado período). Eles são mostrados na tabela abaixo com base no tamanho funcional do software que está sendo trabalhado nos Pontos de Função.
Existem dois padrões principais para tamanho funcional: pontos de função tradicionais (IFPUG) e pontos de função COSMIC. Recomendamos este último principalmente porque lida muito bem com requisitos incompletos, você não precisa conhecer todos os requisitos para dimensionar um software (o que geralmente é feito com o IFPUG).
Atribuições de atividades e produtividade média
Para planejamento baseado em atividades
Nem todas essas atividades são necessárias em todos os projetos. Como diretriz, quanto maior o projeto, mais projetos você precisará executar.
| Atividade | Escopo de alocação de pessoal, FP | Produção mensal, FP |
|---|---|---|
Requisitos |
333 | 175 |
Prototipagem |
500 | 150 |
Arquitetura |
1000 | 300 |
Planos de Projeto |
1000 | 500 |
Design inicial |
250 | 175 |
Projeto detalhado |
250 | 150 |
Revisões de design |
200 | 225 |
Codificação |
175 | 50 |
Aquisição de reutilização |
500 | 600 |
Compra de Pacote |
2000 | 400 |
Inspeções de código |
150 | 150 |
Verificação e validação independentes |
500 | 125 |
Gerenciamento de configuração |
1000 | 175 |
Integração |
1000 | 250 |
Documentação do usuário |
1000 | 70 |
Teste de unidade |
200 | 150 |
Teste funcional |
200 | 150 |
Teste de integração |
250 | 175 |
Teste de sistema |
250 | 200 |
Teste de campo (beta) |
1000 | 250 |
Teste de aceitação |
1000 | 350 |
Teste Independente |
750 | 200 |
Garantia da Qualidade |
1000 | 150 |
Instalação e treinamento |
2000 | 350 |
Gerenciamento de projetos |
1000 | 100 |
Não está disponível uma tabela equivalente, baseada no CFP, mas é razoável considerar que o FP e o CFP são aproximadamente equivalentes quando se utilizam estes dados para o planeamento baseado em actividades.
Uma abordagem baseada em atividades é particularmente útil porque nos ajuda a identificar o pessoal e as competências necessárias durante o projeto. Ferramentas como SRM® da análise Namcook SEER para software da Galorath, SLIM do QSM ou Verdadeiro planejamento do Unison (anteriormente Sistemas de Preços) pode ajudar ainda mais, fornecendo um perfil de pessoal adequado para um determinado projeto ao longo do tempo.
Esta é uma versão condensada da tabela 11.4 publicada em “Estimating Software Costs, second edition” por Capers Jones. Disponível para compra na Amazon. Nota: isto é apenas uma ilustração das atividades e dos seus níveis de pessoal, taxas de produtividade (custos implícitos). Você descobrirá que manter seus próprios padrões de referência para essas atividades é uma atividade que vale a pena.
Estimativa antecipada
Se você está procurando ajuda para estimar o tamanho, a duração e a equipe de um projeto antes de conhecer os requisitos, uma ferramenta adequada é o Software Risk Manager (SRM) da Namcook Analytics. Ele usa dados históricos do projeto e vários algoritmos para fornecer estimativas de tamanho, duração, pessoal e muito mais. SRM pode ser encontrado no Namcook local na rede Internet.
Conclusão
As principais conclusões deste artigo são:
- É possível criar estimativas realistas para projetos de software que são razoavelmente consistentes com o que eventualmente acontece.
- Tamanho (tamanho funcional) é o fator mais significativo afetando o esforço e a duração. A confiabilidade da estimativa do tamanho depende de vários fatores.
- Uma abordagem baseada em atividades com base no tamanho funcional pode produzir uma estimativa razoável do esforço (e, portanto, do custo).
- Conhecer o esforço e as taxas típicas de produtividade nos dá uma estimativa razoável de duração.
- Projetos muito grandes também se beneficiarão de uma ferramenta de planejamento paramétrico que pode prever o tamanho da equipe e os conjuntos de habilidades ao longo do projeto.
