Sim! Nós agilistas temos escopo…

Vocês sabem que as maiores reclamações do mundo em desenvolvimento de software é a famosa correria, os atrasos e a explosão de custos no final dos projetos. Geralmente para nós agilistas o final do projeto é a coisa mais tranquila do mundo. Nós corremos nas primeiras iterações e focamos em entregar valor. Nas últimas iterações é comum sobrar as funcionalidades mais inúteis do mundo a serem desenvolvidas. Quando o cliente percebe isso é comum o projeto acabar algumas iterações antes do que foi planejado.

As maiores razões para esse correria no final do projeto é:

1. A equipe não sabe desenvolver software
2. Gestão Covarde: começar a fazer o software pelas funcionalidades inúteis.
3. Escopo mal definido (assim como as métricas)

O problema com “escopo” em software é achar que desenvolvimento em cascata (waterfall) resolve a questão. Infelizmente quando falamos de escopo dentro de qualquer metodologia de desenvolvimento (FDD, Scrum, RUP como exemplo) sempre focamos que o objetivo do projeto é RESOLVER PROBLEMAS de negócio e não implementar requisitos (isso também é uma coisa que já falei umas 10 vezes aqui).

Parando de ser repetitivo, como nós documentamos esse escopo? Como nós declaramos que problemas o projeto está focado em resolver? Qual é o nível de profundidade desse escopo?

Estabelecer a Visão de um sistema é uma arte. Para este tipo de trabalho é necessário ter um grande conjunto de conhecimentos que na maioria das vezes não é natural para uma pessoa enfiada em linhas de código. Vou colocar uma pequena lista para vocês terem uma idéia. Para estabelecer uma visão é necessário:

– Desenvoltura no ambiente empresarial
– Focar-se no problema e não na solução
– Estabelecer fronteiras claras
– Saber gerenciamento de projetos (definir envolvidos, estabelecer responsabilidades, financiamento)
– Identificar usuários
– Documentar premissas e restrições
– Compreender sobre retorno e risco
– Saber escrever bem
– Ser político (conseguir concordância de todos os envolvidos)

Essas entre outras coisas formam o conjunto de habilidades necessárias para estabelecer uma boa visão. Uma visão que deixe o escopo deslizar dentro do processo iterativo mas que ao mesmo tempo dê um objetivo claro para o propósito do projeto.

Dentre essas habilidades, estabelecer fronteiras é uma das mais importantes. Quando você está desenvolvendo um grande sistema com muitos stakeholders em um ambiente corporativo é comum que a aplicação tenha suporte de outros sistemas ou processos manuais também fora do escopo da automação. Deixar claro que essas responsabilidades externas não são escopo também é um aspecto importantíssimo da visão. Responsabilidades do processo externo e integrações com outros sistemas sempre são importantes para o refinamento do escopo, assim como premissas e restrições na avaliação dessas interfaces.

Sem essa visão clara é comum que ocorram frustrações dentro de um projeto. Uma empresa tem muitos problemas e geralmente o que estamos desenvolvendo não solucionará TODOS os problemas. O escopo delimita exatamente quais problemas serão solucionados.

[photopress:conjunto_problemas.gif,full,pp_image]

O RUP é um dos processos que mais valoriza o estabelecimento dessa visão. O OpenUP também nos fornece um bom material para estudo dessa importante tarefa.

No site da Aspercom nós também temos alguns exemplos:

Visão da HotMotors (Oficina de Tunning)
Visão da KrowCorp (Rede de Hotéis)
Visão da Clínica Anna Suiter (parte integrante do curso on-line grátis, é necessário se cadastrar no site)

Esses documentos tem algumas coisas que geralmente não existem em documentos reais. No caso da KrowCorp (Curso UML & UP) e da Clínica Anna Suiter (Curso Grátis “Entendendo Casos de Uso”) as necessidades dos usuários estão detalhadas demais (estão assim para os objetivos do curso). Já a visão da HotMotors está abrangente demais. O Documento de Visão documenta mais o problema do que a solução. Ele é um resumo executivo do projeto. É o documento que você leva para aquela reunião onde o Sponsor quer cancelar o projeto. A Visão prova a necessidade do software.

É importante ressaltar que dependendo do projeto a Visão pode ser menos ou mais abrangente. Isso depende do que você considera escopo. De qualquer forma nenhuma metodologia iterativa considera que os requisitos do software detalhados são o escopo. O escopo em software sempre é mais abrangente que “requisitos de software detalhados”. Existe diferença entre o problema, as necessidades dos usuários e os requisitos de software.

[photopress:triangulo.gif,full,pp_image]

Dean Leffingwell e Don Widrig explicam mais sobre essa diferença no livro “Managing Software Requirements“.

Um dos problemas do “Escopo de Alto Nível” é que na maioria das vezes o medo do gerente covarde ou a gestão de projetos tradicional não aceita este tipo de escopo como válido. Para eles “tudo tem que estar explicadinho e assinado” por conta de escopo, prazo e custo serem fixos no processo Waterfall. Isso nos leva ao anti-pattern “Big Requirements Up Front” e a uma dispendiosa e irracional Gerência de Mudancas.

O escopo focado no problema é suficiente para o controle dos objetivos do projeto. Determinados replanejamentos de custo, prazo ou funcionalidades podem ocorrer durante a execução. Isto é previsto no processo iterativo. Porém, se o seu cliente desejar que novos problemas façam parte do escopo aí sim teremos impactos maiores de escopo e um replanejamento geral do projeto pode ser necessário (talvez uma nova concepção/iniciação do projeto ocorra gerando impacto em custo e prazo). Isso sim seria uma mudança de escopo e não a inclusão de um campo a mais numa tela.

Muitos desses assuntos são explorados no nosso curso de Levantamento e Especificação de Requisitos.