DevSecOps

13 nov, 2012

Escopo dinâmico de projetos de sistema através de uma abordagem ágil

Publicidade

Confira algumas dicas para um escopo dinâmico de projetos de sistema por meio de uma abordagem ágil.

1. Definindo um escopo de projeto de software

Um conjunto de definições que especificam as funcionalidades de um software a ser desenvolvido constitui um escopo de projeto de software. Esse escopo deve considerar o contexto no qual o software será utilizado, seus objetivos, funções e seu desempenho. Para isso, ele deve ser bem definido e claro, além de procurar especificar com detalhes as funcionalidades e as restrições do projeto.

Se buscarmos analisar de uma maneira mais objetiva, um escopo de projeto de software prevê e delimita situações relacionadas ao cotidiano do cliente e por isso propõe uma solução para melhoria da produtividade do mesmo.

Delimitar funcionalidades e prever melhorias no processo de trabalho do cliente faz com que ele seja informado sobre custos, prazo e o que será realmente entregue. Isso fará com que a proposta se torne mais atraente, uma vez que essas informações possibilitarão uma adequação do seu trabalho em função do que será gasto e do software que lhe será entregue. Paralelamente, se adotarmos a ótica de quem desenvolve o software, esse contexto também se torna interessante já que haverá uma previsão de receita, prazo e demanda. Por isso, o desenvolvedor possui um roteiro do que deve ser feito, quanto irá ganhar e quando estará livre para assumir um novo projeto. Ou seja, o cliente sabe o que precisa desde o início do projeto, e o desenvolvedor calcula com exatidão o dia em que será entregue o software com todas as funcionalidades solicitadas.

2. A previsão e a realidade

O contexto descrito anteriormente é na maioria das vezes irreal devido às mudanças resultantes do mundo dinâmico. Além disso, na grande maioria das vezes, o cliente não sabe com exatidão o que ele realmente precisa para melhorar o seu processo de trabalho. Em geral, ele sabe apenas indicar o problema e as suas consequências para a empresa. Ele sabe também que a solução pode vir através de um software.

Analisando desse ponto de vista, a possibilidade de definição de um escopo de projeto de software é inviabilizada em função das indefinições do cliente e da inconstância do ambiente em que o negócio do cliente está contextualizado.

Diante da indefinição de um escopo de projeto de software devido a esses aspectos, como é possível mensurar custos, prazo e as funcionalidades que serão entregues?

Partindo da premissa de que o cliente tenha um total conhecimento das suas necessidades e por isso não solicite mudanças ao longo do projeto, então a equipe poderá fazer um bom trabalho de estimativa para que o escopo seja previsível. Correto? Não. Tendo em vista esse contexto, haverá ainda a dependência de que o cliente comunique todos os detalhes do seu processo para a equipe e que ela entenda com exatidão o que lhe foi transmitido pelo cliente. Sabemos que o cliente não expõe detalhadamente suas necessidades, já que elas possuem um alto número de detalhes que fazem diferença no processo de desenvolvimento. Mesmo considerando que todos os detalhes serão passados pelo cliente de maneira escrita, o desenvolvedor poderá interpretar o que leu de várias formas, e isso irá resultar em inadequações no processo de desenvolvimento.

3. Consequências da definição de escopo

Na grande maioria dos projetos de software, definir previamente um escopo de projeto de software, buscando obter seu prazo e seu custo, não possui qualquer validade, já que o cliente será enganado com prazos e custos irreais, e a equipe de desenvolvimento não terá noção exata sobre prazo, escopo e esforço necessário para desenvolvimento do software. É importante que o cliente saiba que fixar um escopo, na maioria das vezes, é inviável e poderá prejudicá-lo. Se mesmo assim o cliente optar por um escopo fixo, o mesmo estará assumindo que nenhum conhecimento lhe será acrescentado no decorrer do projeto e, além do mais, estará garantindo que não haverá mudanças no seu processo de negócio. Por isso, essa opção significa correr alto risco em relação ao software não atender as suas reais necessidades quando lhe for entregue.

Algumas estatísticas informam que mais de 60% das funcionalidades de um software, resultante de um projeto com escopo definido, não são utilizadas em ambiente de produção. As prioridades em determinados processos do cliente podem ter mudado desde o momento da definição do escopo ou simplesmente o desenvolvimento da funcionalidade pode não ter representado um valor real para o cliente. Consequentemente, mais de 60% do valor do projeto foram desperdiçados.

4. Dinamizar o escopo é uma boa alternativa

A proposta é a definição de um escopo inicial que possui as funcionalidades mais importantes para a realidade do cliente. Dessa maneira, essas funcionalidades serão projetadas, desenvolvidas, testadas e entregues de maneira que o cliente irá percebendo e fornecendo feedbacks sobre novas necessidades do seu negócio.  Baseando-se nessa nova proposta, o cliente passa a aprender com o próprio projeto e, por isso, terá condição de redefinir suas necessidades e reorganizar suas reais prioridades sem se preocupar em redefinir o escopo do projeto. Por outro lado, a equipe de desenvolvimento passa a obter progressivamente conhecimento sobre o negócio do cliente e sobre aspectos técnicos relacionados ao projeto, podendo desenvolver uma solução de melhor qualidade.

E quanto ao custo e prazo do projeto? Esse aprendizado pode significar a redução do prazo do projeto e consequentemente a redução de custos, já que o cliente passa a ter noção de suas reais necessidades. Isso irá evitar esforço desnecessário para o desenvolvimento de uma funcionalidade que não será essencialmente importante para o processo do cliente ou até mesmo não compensará ser desenvolvida devido a sua relação custo x benefício. Dessa forma, não haverá sentido em definir antecipadamente o escopo de projeto de software expondo seu prazo e custo.

Rever as prioridades do cliente é a melhor forma de conduzir o projeto de software. Isso só é possível ao longo do projeto e na medida em que o cliente passa a entender melhor o seu negócio, e a equipe de desenvolvimento passa a entender melhor o projeto.

5. Adoção de contratos de escopo dinâmico

Trata-se de um contrato baseado na imprevisibilidade de um projeto de software. O escopo absorve as incertezas do projeto. É possível fixar custo, prazo e qualidade como variáveis. Ou seja, pode-se fixar o que o cliente irá gastar e quanto tempo irá durar, porém ele não sabe o que irá receber (escopo), da mesma forma que ele não saberia se fosse definido o escopo do projeto. No escopo definido, há apenas a ilusão de saber o que será entregue. Portanto, não há perda em relação à definição ou indefinição do escopo nesse caso.

A qualidade pode ser fixada graças a técnicas de desenvolvimento orientado a testes, refatoração, integração contínua e outras técnicas.

O entendimento do projeto pelo cliente será garantido através de cada iteração. Cada iteração irá gerar um release do sistema que irá conter novas funcionalidades. A partir da utilização dessas funcionalidades, o cliente irá perceber se elas lhe atendem suficientemente ou se precisam de ajustes. Dessa maneira, o cliente tende a ter a sensação de que o projeto está evoluindo e que suas necessidades estão sendo atendidas. A partir disso, ele passará a analisar se o que será desenvolvido possui relevância ou custo-benefício favorável. Observemos que o projeto poderá ser encerrado com um prazo relativamente baixo, já que a tendência é que o cliente sinta-se satisfeito com as funcionalidades já entregues e, por isso, o cliente passa a desembolsar um valor menor pelo software. Uma das principais vantagens é evitar o desperdício de esforço, prazo e custos no projeto.

6. Conclusões – mudança cultural

É inegável que há uma grande mudança cultural ao adotar uma visão dinâmica e flexível do projeto. É preciso especificar ao cliente os detalhes de todos os aspectos abordados anteriormente, desde a ausência de previsibilidade ao aprendizado do cliente no decorrer do processo. Esses pontos corroboram a necessidade de alterações nas formas de contratação de projetos de software. Caso haja percepção dessa necessidade por parte do cliente, é mais viável a utilização do contrato de escopo variável para atender o problema. Pode-se também comparar vantagens do contrato de escopo negociável em relação ao contrato de escopo fixo para convencimento do cliente. Certamente se perceberá o quanto esse modelo tende a enriquecer e aumentar o sucesso em projetos de desenvolvimento de software.