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.

About The Author

rodrigoy

Instrutor e Consultor Sênior - ASPERCOM

Deixe sua opinião!

5 Comments

  • Rafajagua

    Reply Reply 30/09/2009

    Olá Rodrigo, tudo bom?
    Primeiro, digo que fiz um curso com você (UML 2.0 e OO). Muito bom curso e você ministrou muito bem.
    Como analista de requisitos que atua em uma empresa que utiliza metódologia ágil (adapta SCRUM, mediante as necessidades da empresa, mantendo as principais conceitos do manifesto ágil [mas nem tanto né]) onde o Owner é interno, está sempre ao lado da equipe, o que você sugere que possa ser o papel/ação ativo de um Analista de Requisitos?
    Últimamente, estou mais voltado a aplicar meus conhecimentos em desenvolvimento, para ajudar em outras ocasiões e em testes de aceitação.
    Qual argumento posso usar para convecer a se usar ferramentas de rastreamento de requisitos, manter um mapeamento de requisitos para mediantes manutenções no sistema (independentemente de ferramenta ou metodo).
    Grato.

  • Rafa, se há um Product Owner ativo e presente, infelizmente sobra muito pouco para Analistas de Requisitos neste contexto. Você poderia auxiliá-lo dando idéias para o negócio e capturando critérios de aceite, mas se ele está sempre presente, domina o negócio e não dá margem para vc participar, vc precisaria achar outra função.

    Não entendí direito sobre o que vc quis dizer com ferramentas de rastreamento e etc…

  • Marco Hisatomi

    Reply Reply 01/10/2009

    Rodrigo-san, este blog tem um foco excepcional. Gostei!
    Inclusive utiliza links para os assuntos relacionados, ajuda muito na compreensão.
    Requisitos são necessidades solicitadas, mas para solucionar o problema do negócio do usuário é necessário entendimento e estabelecimento de prioridades. Tudo deve ser desenvolvido, porém no devido momento.

    Vlw!
    Marco Hisatomi

  • Rafajagua

    Reply Reply 01/10/2009

    Olá Rodrigo, agradeço as respostas.
    A segunda pergunta seria o seguinte: Estou tentando convencer o Owner ( que também é o Gerente e o Diretor) a utilizar uma ferramenta de rastreamento de requisitos (requisitos gerados no EA a partir de engenharia reversa), pois na empresa, o produto se aplica a vários clientes, em várias versões e vários segmentos. Creio que um mapeamento entre requisito/funcionalidade ajudaria a entender as alterações e melhoraria o processo, ao invés de contar com a memória de quem desenvolveu e só descobrir se algo quebrou, quando utilizar o produto após a alteração.
    Porém, o Owner cre que isto é mais burocratico e toma mais tempo.
    Qual seria sua opinião?

    Grato.

Leave A Response

* Denotes Required Field