a dialética do escopo

Hoje em dia não sei se a proposta da prática do XP de contrato de escopo negociável foi uma boa. Não pela prática em si, que é excelente, mas pela forma como ela é normalmente entendida e os efeitos negativos desse entendimento. Muitos a interpretam como ausência de escopo definido. Em Planning Extreme Programming, Beck e Fowler mostram claramente que o escopo é sim definido. A principal questão da prática é um modelo simples e fácil de alterar o escopo, em contrapartida à tradicional Change Request e toda a parafernália normalmente associada a ela.

Definir o escopo é interessante por dois grandes motivos: dá aos envolvidos uma noção de custo e prazo do projeto e o mantém focado naquilo que deve ser entregue. O problema é que muita gente pensa que definir o escopo é o mesmo que fixá-lo. Além de achar que não dá para trabalhar com desenvolvimento ágil definindo escopo. Pelo contrário: é recomendável. O problema mesmo é a forma como o escopo é definido.

Antes de falar sobre isso, uma explicação: uma coisa é o escopo, outra é o detalhamento dos requisitos. De forma simples, escopo é apenas a lista de requisitos, sem seus detalhamentos.

Em métodos tradicionais, define-se o escopo habitualmente através de um documento de requisitos bem detalhados. Ou seja, um documento de requisitos normalmente contém tanto o escopo quanto o detalhamento dos requisitos. Esse tipo de abordagem tem dois grandes problemas:

Primeiro:

Como o documento de requisitos é muito detalhado, sua manutenção se torna bastante trabalhosa.

Quando o escopo muda, o documento deve ser atualizado. Devem ser retirados os requisitos que não são mais necessários e incluídos os novos, com seus detalhamentos. Além disso, uma mudança de escopo pode implicar numa mudança do detalhamento dos requisitos já existentes. Por exemplo: imagine um sistema tradicional de controle de ponto. No decorrer do projeto, o cliente decide incluir no sistema a possibilidade de controlar também escalas de revezamento. Isso vai promover alterações no cadastro de empregados, para indicar se o horário do empregado é tradicional ou é escala e qual sua escala de revezamento. No caso, então, seria necessário atualizar o detalhamento do cadastro de empregados no documento de requisitos. Há ainda as fusões de requisitos. Exemplos: dois relatórios com informações comuns que são condensados num só; duas telas que realizam operações similares que são condensadas numa só. Ou seja, mais atualização do documento.

Quando o detalhamento de um requisito muda, o documento deve ser atualizado. Exemplo simples: incluir mais três colunas num relatório.

Como as mudanças são mais custosas, normalmente o processo de mudança é mais elaborado, com documentos de solitações de mudanças, de avaliação de impacto, de aprovação de mudança, etc.

Segundo:

Promove uma indução ao congelamento dos requisitos com seus detalhamentos. Como o trabalho inicial de elaboração do documento de requisitos e extenuante, o cliente e a equipe acham que tudo sobre o projeto está no documento. O cliente então se afasta do projeto, esperando simplesmente receber o sistema no prazo acordado. A equipe desenvolve o sistema baseado no documento de requisitos. Ou seja, todo o aprendizado que poderia ser gerado com as entregas parciais é minorado.

De toda forma, os documentos tradicionais de requisitos podem trazer alguma vantagem. Tem-se um documento em linguagem humana que descreve o comportamento do sistema. Isso pode ser interessante por exemplo quando um novato chega na equipe. Mas acho que o custo não vale benefício. Até mesmo porque os aspectos mais relevantes para um programador saber normalmente não estão no documento, mas sim no código. Por isso a defesa do código expressivo.

Em XP, por exemplo, no início do projeto define-se o escopo (lista de histórias). Quando o escopo muda, basta retirar da lista os requisitos (histórias) não mais desejados e incluir os novos. No caso de uma fusão de requisitos, simples: inclue-se um novo requisito e excluem-se os dois que se fundiram.

A pergunta que normalmente se faz é: “Como estimar o projeto se as histórias não estão detalhadas?” Durante o planejamento do projeto, quando as histórias estão sendo identificadas, o cliente normalmente dá uma explicação rápida sobre cada uma. Por exemplo: num saite de oferta de empregos, há a seguinte história: “Eu como empregador quero anunciar uma vaga para que os candidatos possam encontrá-la”. Verbalmente então o cliente dá uma breve explicação: “O empregador informa o título da vaga, sua descrição, os prerrequisitos, os conhecimentos necessários e os desejáveis.” Isso é suficiente para estimar a história. Não precisa ser uma estimativa perfeita. Algumas histórias serão superestimadas, outras subestimadas. No somatório total, esses erros, para mais e para menos, acabam se equilibrando, conseguindo então um nível aceitável de precisão na estimativa total do sistema, que é o que se quer no início do projeto. Esse é o ponto: o que se quer no início do projeto é uma estimativa orçamentária do projeto, não uma estimativa precisa de cada história.

Alguns autores defendem que essa breve explicação de cada história deve ser documentada. Eu particularmente não gosto dessa abordagem, e nunca tivemos problemas com isso. Aqui na Fortes já desenvolvemos uns dez projetos utilizando essa forma de planejamento. Tivemos problema de prazo em um ou dois desses projetos, mas a causa não foi a falta da documentação dessa breve explicação. Muito menos a falta de um documento de requisitos.