Verificação de Escopo Método Tradicional x Metodologia Ágil Scrum

Definição: "A verificação do escopo é o processo de obtenção da aceitação formal pelas partes interessadas do escopo do projeto terminado e das entregas associadas. A verificação do escopo do projeto inclui a revisão das entregas para garantir que cada uma delas foi terminada de forma satisfatória. Se o projeto foi finalizado antes do término (abortado), o processo de verificação do escopo do projeto deve determinar e documentar o nível e a extensão do término.

A verificação do escopo do projeto ocorre em determinados momentos:

* No final do projeto
* No final de fase do projeto
* Na entrega dos principais produtos finais dentro do projeto. “

Fonte: http://www.tenstep.com.br/br/TenStepPB/open/5.4.htm


A verificação de escopo, é uma das partes mais importantes, necessárias e por muitas vezes mais esquecidas de um projeto.

A seguir uma comparação de verificação de escopo em projetos de desenvolvimento de Software utilizando abordagens diferentes.

Analisando o contexto baseado no método tradicional.

A verificação de escopo no método tradicional é focada na assinatura do cliente.

Podemos considerar a verificação do Escopo feita quando o documento está assinado?

Caros colegas e profissionais, sejamos coerentes e realistas. Quantos de nós paramos pra pensar que dependendo do tipo de documento, enviado ao cliente, ele não entende nada do que foi dito/escrito?

Por exemplo, algumas verificações de escopo das que já vi e participei são feitas através de documentos de casos de uso. Agora eu me pergunto, quantos clientes nossos sabem o que são casos de uso? O que vocês acham que uma pessoa leiga pensa quando os vê? "Oh, o que são essas bolinhas e estes bonecos aqui? Tem descrição, mas não estou entendendo nada. Vou assinar pra pular este parte chata e depois tento entender". Cômico, mas infelizmente verdadeiro. Não acontece assim em vossos projetos?

Se uma verificação de escopo feita através de documentação é realizada, devemos nos concentrar em fazer uma apresentação clara e sucinta do que queremos aprovar.

Utilizando o caso anterior, por que não reunir com o cliente e realizar uma apresentação visual do que signifa cada parte da descrição do documento?

Não falo em encher o cliente lendo 300 páginas, mas sim mostrar as funcionalidades do produto, o que vai gerar, quem irá interagir, como, quantos relatórios poderão ser emitidos, quando, etc.

Você pode me dizer: Também fazemos verificações de escopo com protótipos do produto. Sim, mas o protótipo já aparece em uma fase que o documento de requisitos e de casos de uso já foram validados, podendo assim termos perdido alguma informação importante da visão do cliente, causando assim modificações grandes no projeto.

Não devemos nos prender SÓ na assinatura da documentação, é importante sim e muito, pois temos que ter a prova de que o escopo foi aprovado, mas o mais importante é termos em mente que, para que o documento seja assinado, o que estamos querendo passar na realidade ao cliente, deve ser entendido e se, dúvidas houverem, que as mesmas sejam clarificadas, para somente depois, pegarmos a assinatura formal.

Passando para a análise em cima do método Ágil.

Verificação de escopo no método ágil é focada, na aprovação seja ela formal ou informal do cliente com o que foi mostrado(Parte do produto pronto) ao final de cada sprint.

O gerenciamento de Escopo no Scrum, não está descrito como entrega de aceitação formal, escrita, assinada, carimbada, mas vocês querem ver como funciona?

Vejam bem, no Scrum existe uma fase no meio processo que é exigida e sem ela o projeto não continua, ela se chama Sprint Review Meeting e deve ser obrigatoriamente realizada ao final de cada Sprint, seja ele de uma semana ou um mês, de acordo como o time definiu. Esta fase é mais tradicionalmente conhecido como “Verificação de Escopo”, não é legal?

Definição: “Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting.”

Fonte: http://improveit.com.br/scrum/sprint_review_meeting

O que isso significa? Reunir com o cliente ao final de cada sprint, mostrar os requisitos planejados para a sprint, os que foram realizados em forma de produto e checar se está tudo como ele imaginava. Caso não esteja, preparar os ajustes para os próximos sprints, caso apareçam novas features, inserir no Product Backlog e repriorizar.

Qual o diferencial da verificação de Escopo no Scrum? Ele não te prende a documentação, mas sim na aceitação do cliente em uma reunião em que o mesmo deve estar presente, e o mais importante, te força a não passar para um outro sprint sem que o cliente, tenha visto e aceitado o produto desenvolvido.

Não é mais fácil e inteligente termos o cliente por perto sempre, tirando as dúvidas e clarificando constantemente os requisitos presencialmente? Ao invés de escrevermos os requisitos uma vez, revisarmos e aprovarmos, e quando chegarmos no fim, descobrirmos que não fizemos o que o cliente esperava.

Pensem comigo, quantos clientes, sabem exatamente o que querem logo de primeira? Podemos revisar os requistos com ele a cada três meses ou conforme definido, a verdade é que ele nunca tem certeza do produto final esperado.
Então, não é melhor acompanharmos a evolução de suas idéias em um período de tempo mais curto e constante?

Por outro lado, temos que nos preocupar neste caso, em encontrarmos uma forma mais "amigável" de aceitação formal com o cliente. Muitas vezes clientes do Scrum confundem agilidade com falta de documentação e isso deve ser tratado logo que possível.


Conclusões

Nesses moldes e nas experiências que tive, considero que hoje em muitos dos casos utilizando o tradicional, seria bom pararmos de olhar para o Scrum com olhos desconfiados e aplicarmos as boas práticas quando necessário. O mesmo vale para os seguidores fiéis do Scrum, que já olham assustados para o tradicional e pensando em documentação desnecessária.

Os dois métodos funcionam e muito bem, mas devem ser analisados e melhorados em cada organização onde o método escolhido é aplicado, para que possamos ter a garantia de que não estamos preenchendo/assinando documento, ou reunindo com o cliente apenas com o intuito de seguir o processo obrigatório em sua empresa.

Olhemos para nossas organizações e sejamos coerentes, sugerindo ajustes ou melhorias de acordo com os objetivos de cada uma.