Solucione problemas na definição de contratos de Métodos Ágeis

As metodologias ágeis já são uma realidade, adotadas por grande parte das organizações e colecionando inúmeros cases de sucesso. Entretanto, quando olhamos para os contratos de desenvolvimento de software que as organizações têm usado, vemos que eles ainda não foram adequados à nova forma de trabalho introduzida pelas práticas ágeis. Além disso, essa falta de sinergia entre os contratos e os modelos de desenvolvimento é um dos fatores que pode impactar no sucesso do projeto. Tanto o cliente quanto o fornecedor têm desvantagens consequentes dessa falta de alinhamento entre a metodologia de desenvolvimento utilizada e as cláusulas do contrato assinado.

Este artigo tem o objetivo de expor o problema relacionado às divergências entre os contratos e as metodologias de desenvolvimento, mergulhando em suas causas e consequências. Relacionadas a esse problema, algumas questões são comuns:

· “Por que projetos falham ou atrasam mesmo utilizando modernas metodologias ágeis?”;

· “Por que algumas organizações ainda têm resistência para adotar métodos ágeis?”;

· “Como melhorar a relação entre o cliente (solicitante do projeto) e o fornecedor (quem vai desenvolver o projeto)?”.

As respostas para essas perguntas ficam mais claras no decorrer desse artigo. Para que seja possível entender o problema abordado, é necessário apresentar alguns conceitos e premissas das metodologias ágeis. Isso é importante para que o leitor possa entender a diferença entre as necessidades de um projeto tradicional e de um projeto ágil. Com os conceitos de agilidade apresentados, será explicado o problema dos contratos tradicionais. Exposto o problema, a seção seguinte abordará individualmente cada modelo de contrato, divididos nas categorias tradicional e ágil, e explicará mais detalhadamente suas principais características. Nesse artigo o principal critério para categorizar um contrato como tradicional ou ágil é a forma como o contrato trata o escopo. Caso o contrato defina que o escopo do desenvolvimento é fechado (dificultando mudanças de requisitos), é categorizado como tradicional. Se o contrato trabalhar com escopo flexível, permitindo e facilitando mudanças de escopo durante o projeto, fica sob a categoria ágil.

É importante citar que apesar deste artigo estar contextualizado para contratos entre empresas privadas, diversas práticas aqui apresentadas podem ser de grande valor para profissionais envolvidos com contratações na esfera governamental, desde que avaliada a compatibilidade com as leis em vigor. Já há uma mobilização para a modificação dessas leis de contratação de desenvolvimento de software brasileiro, que atualmente é fortemente ligada a pontos de função. Porém, esse não é o escopo desse artigo, apesar de ser uma área de estudo muito relevante atualmente.

Histórico das metodologias ágeis

Ao olhar uma linha do tempo da história da computação, é possível perceber a evolução no uso de metodologias de desenvolvimento de software. No início da informática, não existia metodologia de desenvolvimento definida. Levantavam requisitos, desenvolviam e entregavam tudo ao mesmo tempo, sem nenhuma organização clara. Visando organizar esse caos, criou-se o modelo Cascata (Waterfall), que representou um grande avanço na área de engenharia de software. O processo de desenvolvimento era dividido em fases sequenciais, cada uma deve ser concluída para que a seguinte seja iniciada. Dessa forma, foram criadas fases como Requisitos (levantamento dos requisitos do projeto), Elaboração (design e modelagem do projeto), Construção (codificação do projeto), Teste, e Manutenção do Sistema.

Apesar da melhora no processo, novos problemas surgiram. Com o entendimento que uma fase tem que terminar para que a outra comece, torna-se fundamental um levantamento de requisitos perfeito para que a construção ocorra sem muitos problemas. Surgiu posteriormente a metodologia RUP, desenvolvida pela empresa Rational Software Corporation, que é uma divisão da IBM. Essa metodologia passou a sugerir a implementação de iterações dentro das fases do modelo Cascata. A partir daí, surgiu o modelo Iterativo-Incremental, que prevê iterações nas fases e incrementos no produto, criando entregas parciais durante o ciclo de vida.

Muita coisa melhorou, mas alguns problemas persistiam. Ainda era comum os projetos falharem, atrasarem, estourarem o orçamento, ou ainda, implementarem funcionalidades que nem eram usadas. Ainda era difícil modificar um requisito e se comunicar com o cliente. Os projetos acabavam não atendendo as reais necessidades do cliente, que normalmente tinham que pagar um valor elevado pelo produto, e provavelmente usariam menos de 20% das funcionalidades implementadas. Pensando nesses problemas, os métodos ágeis começaram a aparecer.

As metodologias ágeis trouxeram diversas quebras de paradigma que modificaram a forma de pensar e de desenvolver software no mundo inteiro. Elas começaram a surgir no final dos anos 90, tendo como inspiração as ideias de produção da Toyota (Toyota ...