Prazo e Escopo: Uma questão de qualidade - I

Bem, em primeiro lugar um feliz 2010 a todos.

Agora, vamos direto ao assunto: O escopo precisa estar equilibrado com o prazo para que seja garantido um nível mínimo de qualidade para a aplicação. Ponto final. Não existe outra forma para isso funcionar. Não entendo como tentam formulas mágicas para economizar na análise, construção e testes, para gastar rios de dinheiro com a manutenção. Simplesmente não funciona. Vamos verificar as partes prejudicadas, quando temos muitos bug-fixes:

• Cliente: Perde dinheiro de forma indireta com os bug-fixes durante o período de garantia, pois uma aplicação que deveria estar funcionando não está. Fora da garantia, perde dinheiro diretamente;
• Consultoria: Perde workforce durante a garantia. Se ainda necessitar de muitos bug-fixes depois da garantia perde a confiança e satisfação do cliente. Poderia estar ganhando mais dinheiro e tendo menos dores de cabeça.

Frederick P. Brooks JR, em seu livro The Mythical Man-Month, no segundo capítulo, estampa o cardapio de um restaurante de Nova Orleans, o Antoine, que diz o seguinte: "Good cooking takes time. If you are made to wait, it is to serve you better, and to please you."

No livro, Brooks afirma que esta relação Homem-Mês só pode ser usada em atividades que não necessitam de constante comunicação entre as partes, como colher algodão, por exemplo. Neste tipo de atividade, contratar mais pessoas reduzirá o tempo necessário para completar as tarefas.

"Isso implica em dizer que Homem-Mês são intercambiáveis. Homem e mês só podem ser considerados intercambiáveis quando a tarefa pode ser dividida entre as pessoas, sem necessidade de comunicação entre elas."

Outro trecho interessante deste capítulo é: "The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debbugging". E continua no parágrafo seguinte: "If a task can be partitioned but which require communication among subtasks, the effort of communication must be added to the amount of work to be done."

Outro ponto considerado é a preparação necessária destas novas pessoas, totalmente alheias ao projeto. Uma boa documentação reduz esse impacto. Mas a passagem de conhecimento deve ser efetuada, e vai consumir tempo.

Dessa forma, surgiu a lei de Brook que diz o seguinte: “Adding manpower to a late software project makes it later”, e acredito que ainda teremos muito para falar sobre o livro neste espaço. Um artigo interessante pode ser encontrado aqui.