Livro do Mês Passado - Software Estimation

Steve McConnell é autor dos conhecidos livros Code Complete (que ainda não li) e Rapid Develpment (que li e recomendo).

Neste seu mais novo livro Software Estimation: Demystifying the Black Art (lançado agora em 2006) ele aborda a arte de estimar tamanho, esforço e prazo de projetos de software.

É um livro relativamente pequeno, cerca de 300 páginas, dividido em capítulos curtos, ideal para ler aos poucos. O livro é impresso em duas cores (preto e azul), o que é muito bem aproveitado nas tabelas, gráficos e figuras. Espero que a Microsoft Press utilize com mais frequência este tipo de recurso.

Além da experiência própria do autor (que fornece consultoria no assunto e desenvolveu um software para fazer estimativas), o livro utiliza uma quantidade imensa de dados reais coletados por diversos pesquisadores. Embora a maior parte das técnicas seja voltada para projetos de porte médio a grande, muito pode ser também aproveitado para projetos pequenos.

A utilidade deste livro não está limitada às pessoas cuja função é estimar software. O entendimento dos conceitos de estimativa pode reduzir o stress normalmente associado às estimativas e ao próprio desenvolvimento de software.

O livro está dividido em três partes:

• Conceitos Críticos
• Técnicas Fundamentais
• Desafios Específicos

Ao longo do livro são apresentadas 118 "dicas" (eu não contei, elas são reproduzidas em destaque no final do livro). Reproduzo algumas abaixo:

• Diferencie estimativas, alvos e compromissos. [Uma estimativa é um resultado obtido por uma avaliação, um alvo é um resultado desejado e um compromisso é um resultado acordado entre os envolvidos.]
• Quando uma estimativa é fornecida como um valor único (ao invés de uma faixa) existe implicitamente uma probabilidade associada.
• A penalidade para estimar para baixo é normalmente maior que estimar para cima. [Intuitivamente achamos que é o contrário]
• Existe um "Cone de Incerteza": á medida que um projeto avança, as estimativas podem ser mais precisas (desde que o projeto esteja sendo gerenciado adequadamente). [É tolice querer ser mais preciso que o estágio do projeto permite. Se o projeto não convergir, as estimativas não vão convergir - isto é um problema de gerenciamento e não de estimativa]
• Não dê estimativas de "bate-pronto". [Pensar um pouco, mesmo que alguns minutos, vai gerar uma estimativa mais precisa]
• O número de dígitos significativos e a unidade usada da estimativa deve ser compatível com a sua precisão. [Por exemplo, considere a diferença entre dizer 2 dias e dizer 16 horas]
• O tamanho do software é o fator mais significativo (mas não o único) na determinação do esforço e prazo.
• O esforço não cresce linearmente com o tamanho.
• As técnicas de estimativa devem ser escolhidas em função do que você quer estimar, o tamanho do projeto, o estágio do desenvolvimento, o estilo do desenvolvimento (interativo ou sequencial) e a precisão desejada.
• Contar quando possível. Se não for possível contar, calcular. Somente em último caso opinar. Não usar a opinião de especialistas para ajustar estimativas obtidas por cálculos.
• Guarde dados históricos dos projetos. A performance passada é o melhor indicador da performance futura. [Como otimistas, achamos sempre que os problemas anteriores não vão se repetir]
• Não discuta o resultado de uma estimativa [feita com método]. Mude o resultado somente alterando as entradas e recalculando.

Resumindo, altamente recomendado.