O escopo é dos componentes mais importantes de um projeto. Ele representa o trabalho a ser entregue, e é com base nele que as demais variáveis do projeto são definidas, como custo, tempo, risco e qualidade. Desta forma, é fundamental para o sucesso do projeto, que exista uma definição clara e inequívoca de seu escopo. Neste artigo , quero falar mais especificamente sobre a definição de escopo em projetos de desenvolvimento de software, compartilhando algumas dicas, ferramentas e técnicas que podem contribuir em definições e refinamentos assertivos do escopo de um projeto.
O conceito de escopo, conforme definido no PMBoK 4 ª Edição[1] é: “O trabalho que precisa ser realizado para entregar um produto , serviço ou resultado com as características e funções especificadas “. Esta definição de escopo é genérica, e pode ser adota em qualquer indústria: tecnologia, engenharia, construção civil, etc.
Quando se trata do desenvolvimento de software, entretanto, a definição do escopo pode ser difícil, especialmente porque software é em si um conceito abstrato. Diferente da definição de escopo em um projeto de construção civil, por exemplo, onde se pode dizer “Eu preciso de uma casa de 5 comodos, sendo 3 quartos, uma sala e uma cozinha, com área total de 100 m²”, e você terá uma imagem mental de como a casa deverá ser, quanto se trata de um projeto de software, é difícil concretizar e imaginar com precisão, o que se espera do software, e como ele dever ser construído.
Devido a estas características específicas, é que se faz importante a adoção de técnicas e ferramentas que ajudem a ter uma definição mais clara, precisa e concreta dos entregáveis do projeto. Algumas destas técnicas e instrumentos estão descritos no PMBoK , outros são boas práticas usadas na indústria de desenvolvimento de software, as quais gostaria de citar abaixo, algumas das quais considero mais importantes.
EAP é a sigla para Estrutura Analítica do Projeto. Ela é criada por meio da decomposição de entregáveis em pequenos pacotes, e cada pacote, em um conjunto de pequenos componentes. O objetivo da EAP é fornecer um “mapa” de todo o trabalho necessário, e somente o necessário, para entregar o projeto. A soma dos componentes e dos pacotes de entrega deve representrar exatamente (nem mais nem menos), o que é esperado como entrega do projeto. Esta estrutura decomposta é muito útil para extratificar o desejo do usuário, expresso em palavras, em elementos concretos, que podem gerenciados, construídos e implantados.
O conceito do modelo de desenvolvimento iterativo[2] se fundamenta na premissa de que, por ser o software uma concepção abstrata, ele pode ser melhor compreendido, projetado e implementado, através de entregas parciais de partes do escopo, de maneira contínua. Desta forma, a medida em que o usuário recebe um pacote de funcionalidades e as valida, a próxima entrega é planejada e executada com maior assertividade e maturidade, sendo possíveis ajustes e revisões em um espaço de tempo mais curto.
Um protótipo é “uma amostra inicial, modelo ou versão de um produto construído para testar um conceito ou processo”[3] . Este artefato é criado pelo desenvolvedor / engenheiro de software, com base na especificação de requisitos. Através dos protótipos, usuários e desenvolvedores podem validar mais facilmente se a “tradução” de requisitos de negócio em artefatos de software, como telas e funcionalidades, estão aderentes.
As metodologias de desenvolvimento ágil surgiram como uma ideologia, um conjunto de práticas e abordagens visando a tornar o desenvolvimento de software menos documental e inflexível, em relação aos modelos tradicionais (RUP, WaterFall). Dentre as principais características deste modelo, podemos citar resumidamente : ciclos iterativos, forte interação entre usuários de negócio e time de desenvolvimento, pequenos pacotes de entrega, ciclos curtos de implementação e implantação, priorização e revisões (lições aprendidas). Um dos principais pontos fortes que considero nesta abordagem, além das já citadas acima, é a maior proximidade e envolvimento do usuário de negócio (chamado aqui de “Product Owner”), ao longo do ciclo de vida das entregas. Esta estratégia permite que o usuário, ao mesmo tempo em que suporta o time de desenvolvimento, esclarecendo dúvidas e fornecendo feedback contínuo, receba rapidamente requisitos prontos para utilização, podendo repriorizar as entregas subsequentes, de uma maneira flexível e ativa.
As técnicas e ferramentas aqui expostas superficialmente, são apenas algumas daquelas que podem ser adotadas para se alcançar um maior nível de sucesso em projetos de implementação de software. Oportunamente, apresentaremos outras técnicas, bem como aprofundaremos as já descritas aqui.
Referências
[1] A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition. Project Management Institute, 2008. ISBN 978-1-933890-51-7
[2] http://en.wikipedia.org/wiki/Iterative_and_incremental_development
[3] http://en.wikipedia.org/wiki/Prototype
[Crédito da Imagem: Escopo – ShutterStock]
Gerente de Projetos com 15 anos de experiência na área de TI, certificado PMP em Gerenciamento de Projetos pelo Project Management Institute. Formado em Gestão de Tecnologia pela Unisul e cursando MBA Executivo Internacional em Gestão Empresarial Estratégica pela Fundação Getúlio Vargas em parceria com a Ohio University - EUA. Carreira profissional construída ao longo de diversas e ricas experiências profissionais em companhias e médio e grande porte em diferentes segmentos de mercado, dentre os quais Financeiro, Serviços e Tecnologia.
You must be logged in to post a comment.
5:52:12 pm
Sem dúvida, dos itens citados anteriormente o que mais trouxe grandes benefícios dos projetos que participei foi a prototipagem e o desenvolvimento ágil. A simulação do sistema em um protótipo é interessante porque alinha as expectativas do cliente com o que é necessário fazer, porém este mesmo cliente participando como Product Owner no desenvolvimento ágil é algo que faz muita diferença. Este papel deixa claro o comprometimento do cliente com o projeto e a sua contribuição para que o projeto siga uma trajetória assertiva.
10:28:21 pm
Olá Marcos,
Obrigado pela sua contribuição. Concordo com você. A participação do cliente como Product Owner é uma característica marcante e muito positiva do modelo Ágil.
Um abraço,
Luis Henrique Soares