Desenvolvimento ágil baseado com contrato que tenha sido aceito por advogados parece impossível. A natureza de processos tradicionais de compra e contratação não coincide com os princípios ágeis. Quando um projeto é pequeno você até consegue dar um jeitinho, mas para um projeto grande com altos riscos a situação é diferente. O cliente quer saber o que ele vai ter pelo dinheiro que vai pagar, embora ele, de fato, não consiga detalhar suficientemente suas necessidades. Tendo anos atrás adotado princípios de trabalho ágeis, em algum momento temos que encarar esse desafio. E parece que como certa vez disse Nelson Mandela: “sempre parece impossível até que seja feito”. Permita-nos compartilhar nossas experiências em uma empresa de seguros.

Era uma situação incomum. Uma empresa de seguros queria introduzir no mercado um novo serviço de seguro saúde no prazo de seis meses. As aplicações de suporte de workflow e de comunicações deveriam ser desenvolvidas do zero enquanto a integração com a aplicação de registro de apólices existente era mandatório. Faltavam especificações claras. Ao todo era um projeto muito ambicioso e arriscado. Vários fornecedores apresentaram propostas, as quais o cliente não confiou por causa da altíssima faixa de preço. Eles, felizmente, compreenderam que uma abordagem ágil tinha que ser seguida para ter uma solução funcionando dentro de seis meses. Essa foi nossa sorte, porque em muitos outros casos precisamos de muito esforço para convencer o cliente que uma abordagem ágil seria a melhor.

As RFPs trazem um monte de informação, mas a maioria delas não é realmente necessária.

A RFP consistia em várias páginas de requisitos técnicos e funcionais. Imediatamente ficou claro porque os outros fornecedores prepararam propostas tão diferentes. Apesar de todo o trabalho feito pelos analistas de negócio do cliente sobravam incertezas e faltavam funcionalidades essenciais e descrições de integrações.

Por ser claro que faltava informação propusemos introduzir três semanas de brainstorms para conhecer os analista e os especialistas no domínio (incluindo vários usuários finais).

Juntos discutimos as diferentes funções e tarefas, definimos papéis de usuários, que no final resultaram no “escopo do projeto”. Sumarizamos a discussão através de épicos e, quando possível estórias de usuários para mostrar que havíamos entendido suas necessidades.

Depois desses workshops até mesmo o cliente entendeu a complexidade de seus próprios processos.

Estimando para preparar a proposta

Seria razoável concordar em um orçamento e data limite se não entende muito bem o que deve ser entregue? A resposta é sim – mas apenas se usa métodos de projetos apropriados para esses tipos de desafios. Ágil é um deles. Embora tenhamos dado um jeito de concordar com o escopo, ainda tínhamos pela frente um dos maiores desafios: definir e formalizar todos os compromissos. Hoje em dia existe um framework para contratos ágeis, mas não enquanto estávamos preparando nossa oferta.

Decidimos estimar de duas formas diferentes. Primeiramente, estimamos de uma forma mais tradicional discutindo quanto tempo uma determinada estória de usuário levaria. Checamos essas premissas “chutando” quanta capacidade de design, desenvolvimento, testes e implementação seriam necessários para fazer o projeto dentro do prazo acordado. A segunda forma foi baseada em “Planning Poker”. A equipe basicamente define a complexidade dos épicos e estórias de usuários por comparação. Baseado em nossa experiência com projetos similares, mais ou menos sabíamos qual velocidade (quantidade de horas de desenvolvimento por pontos de história) poderíamos presumir.

É claro que esses métodos geram estimativas diferentes, mas tendo estimativas feitas com métodos diferentes nos tornamos mais capazes de definir o total de projeto que assumimos ser necessário para entregar a solução requisitada. Também incluímos um fator de risco, porque consideramos que um grande gerenciamento adicional seria necessário para tocar o projeto.

Então, as negociações de preço começaram.

Para o cliente, nosso orçamento era muito alto (como sempre, devo dizer). Graças à nossa estimativa de projeto totalmente transparente, o cliente estava plenamente ciente da forma como havíamos estimado o projeto. Graças a essa transparência, sabíamos que tudo que foi incluso era o que realmente era necessário.

Convencemos o cliente a aumentar o orçamento para se aproximar da nossa estimativa. Concordamos que o orçamento do cliente seria chamado de orçamento “alvo” para o projeto. Além disso, adicionamos 40% que gerou um orçamento máximo. Assim que o orçamento cruzasse o orçamento alvo, o cliente seria cobrado pela metade da tarifa de hora de um desenvolvedor. Também concordamos que, no caso de conseguirmos realizar o escopo acordado dentro do orçamento máximo, compartilharíamos as sobras.

Nesse caso, um processo padrão de controle de mudanças deveria ser estabelecido. A abordagem Custo-Alvo-Com-Limite-Máximo foi inspirado pelo artigo de John Rask “Contratos de Custo-Alvo“.

Havendo chegado a um acordo verbal, a execução do projeto começou. As formalidades ainda tomariam dois meses, mas não podíamos esperar mais. Baseado num acordo de cavalheiros, o projeto teve seu kick-off.

Advogados são necessários …

Rascunhar um acordo de negócio é uma coisa, mas colocá-lo no papel de uma forma que os processos administrativos de negócio ficassem satisfeitos, sem emperrar a execução de um projeto ágil é um grande desafio. A nosso pedido, o cliente nos enviou as condições da compra. E eles estavam longe de serem ágeis.

Nosso advogado, que já havia aprendido a ser mais ágil, preparou um acordo, que continha várias das condições do cliente, e lhes enviamos de volta. Seus advogados revisaram o documento e basicamente todas nossas propostas foram removidas.

Concluímos que essas interações legais não levariam a nada e, portanto, organizamos uma reunião entre diretores representantes do “lado do negócio” e advogados dos dois lados para explicar ao advogado do cliente qual era o objetivo do projeto, porque ele precisava ser ágil e o que agilidade significava.

Isso ajudou.

A construção do contrato

Uma estrutura contratual estava sendo esboçada. Além de condições gerais de compra, essa estrutura contratual incluía regras como:

• O escopo do acordo ser de desenvolvimento de sistema. Manutenção e administração, documentação do usuário, treinamentos, etc, eram, por exemplo, excluídas;
• Divisão do projeto em releases;
• O planejamento de alto nível dos releases;
• A explicação do processo ágil, incluindo divisão por interações, uso de estórias de usuários para definir o escopo dos releases;
• O processo de aceite por release baseado em critérios de aceite e no aceite final do sistema após o release final e da satisfação do cliente. O documento de aceite estava sendo incluído como um anexo;
• Procedimentos de tratamento de falhas;
• Comunicação entre cliente e fornecedor e do poder de tomada de decisão das pessoas chave envolvidas;
• Templates e documentos a serem usados durante o processo de desenvolvimento;
• Termos de pagamento baseados na divisão do projeto.

Por questões administrativas do lado do cliente foi preciso de uma razoável papelada e acordamos que os seguintes documentos fluiriam pelo projeto.

Dividindo o projeto em pedaços menores

O sistema completo foi dividido em dez releases para melhor definir e gerenciar o escopo. Cada release tinha seu próprio orçamento, baseado nas estimativas de alto nível dos épicos e das estórias de usuários. Graças à abordagem “story points” e “planning poker” fomos capazes de determinar o tempo necessário para realizar alguns releases.

Conseguimos rascunhar um arcabouço contratual com as “regras” da nossa cooperação. Além de que cada release tem seu próprio acordo e protocolos de aceitação.

Por release, uma equipe de analistas e consultores definia o escopo, resultando em um “Backlog de Release de Produto”. O Backlog de Release de Produto continha todos os casos de uso que deveriam ser implementados juntos com critérios de aceitação apropriados e a definição de pronto, com o que cada caso de uso deveria ter. Graças a isso, conhecíamos exatamente o que precisava ser feito, bem como quando estava pronto. Juntos, isso formava a “definição de release”.

Então a equipe de desenvolvimento quebrariam o release em várias e estórias de usuários detalhadas. Prioridades são estipuladas juntamente com o product owner resultando em um planejamento por iteração. Isso foi tudo formalizado através de um “acordo de iteração”. Além disso, a equipe definia a velocidade esperada por iteração, o que era usado como um indicador para medir o sucesso da iteração.

Durante o desenvolvimento o product owner era frequentemente informado sobre o status do desenvolvimento, bem como os especialistas do domínio, entre outros, para prover informações mais detalhadas, para rever designs de interface de usuário e para testar funcionalidades novas ou que sofreram alteração.

Cada release era testado pelo cliente, com base nos testes de homologação definidos previamente. No caso do cliente confirmar que o release estava mais de 85% “pronto”, o projeto continuaria, o release tinha de ser pago e o planejamento do próximo release começaria. Trabalho restante seria incluído no próximo release. Isso levaria a uma assinatura do protocolo de homologação de release, um documento necessário para a administração financeira do cliente. Caso contrário, a fatura não poderia ser paga.

Graças à grande cooperação, o nível de aceitação ultrapassava de longe os 85% em todos os releases.

Dentro do arcabouço contratual a data de início e de entrega de cada release foram definidas e isso obrigou todos os participantes do projeto a cumpri-las. O deslocamento de um prazo não seria permitido. O orçamento para cada release também tinha sido definido (tanto o orçamento alvo, quanto o máximo). A única parte variável era o alcance do release, ou seja, quais funcionalidades exatamente seriam materializadas.

Como o contrato suportava o projeto na realidade

Quando o cliente nos chamou para a RFP, não nos sentimos nem um pouco confortáveis com o projeto. Era de muito alto risco. Graças a esse processo de contratação o projeto se tornou gerenciável. Na verdade, o grande projeto foi dividido em dez projetos menores, que foram (re)contratados toda vez. A vantagem desse processo foi que cada stakeholder se encontraram entre si frequentemente para discutir o status do projeto e, se necessário, para ajustar a abordagem. A satisfação do cliente foi medida continuamente. Isso tornou o processo um pouco mais burocrático, mas muito mais previsível. O risco do projeto foi dramaticamente reduzido para os dois lados.

Todas essas vantagens também foram notadas pelo cliente. Eles perceberam que necessitavam de uma forma ágil de trabalho para alcançar o objetivo e prevenir burocracia quando quisessem introduzir mudanças durante o processo de desenvolvimento. Esse contrato fornecia os documentos essenciais para gerenciar seus processos administrativos, enquanto resguardava o desenvolvimento ágil do projeto.

O arcabouço jurídico permaneceu inalterado durante o projeto. Pequenos ajustes foram feitos em diferentes documentos usados durante o processo para torná-los melhor tanto para o cliente como para as equipes de desenvolvimento.

O contrato dava direções claras ao projeto e definia muito bem o campo de jogo. Baseado no contrato pudemos forçar o product owner a fornecer material ao projeto em tempo hábil, os estimulamos a aparecer com os critérios de aceite em tempo hábil, etc. Frequentemente tivemos que mutuamente relembrar as obrigações do contrato, mas apenas para deixar toda a equipe focada em entregar o escopo do projeto no prazo e dentro do custo aprovado.

O contrato nos protegia para sermos pagos também pelo trabalho realizado. O contrato claramente definia quando as partes do projeto deveriam ser pagas e na maioria dos casos o cliente cumpriu com essas obrigações de acordo com o planejado.

Internamente decidimos incluir o nível de satisfação do cliente nas recompensas individuais de algumas pessoas chave da equipe de desenvolvimento. Aparentemente isso foi bastante estimulante.

Flexibilidade com custos permanentemente sob controle – é possível?

A interação frequente entre ambos os lados e o teste regular de novos elementos do sistema genuinamente apóiam em caso de introdução de mudanças no escopo inicial de requisitos. Isso geralmente não é possível quando o projeto é gerenciado usando métodos tradicionais – cada mudança leva a um aumento do custo global ou a longas discussões entre os dois lados sobre se um determinado requisito foi já bem definido e nasce a partir da documentação inicial.

Saber que durante o desenvolvimento as idéias sobre o sistema ideal mudariam (e elas sempre mudam!), permitiu ao cliente ajustar tanto o âmbito e as prioridades dos releases/iterações. Enquanto ela fosse “orçamentalmente neutra” não haveria problema. Devido as novas perspectivas durante o desenvolvimento do projeto, inúmeros novos pedidos levaram a um aumento do escopo e do orçamento. Felizmente, os prazos ainda não precisaram ser ajustados. As equipes de desenvolvimento lidaram com isso adicionando mais recursos quando necessário. Isso possibilitou que o cliente explorasse de forma empírica qual funcionalidade acrescentaria mais valor ao negócio. Foi possível que eles afinassem a plataforma às suas reais necessidades.

Uma solução bem-ajustada no prazo

Graças à abordagem escolhida pudemos mostrar os resultados iniciais de nosso trabalho – um painel de usuário totalmente funcional – já depois da primeira iteração (duas semanas). Depois de dois meses, começamos a implantar a primeira parte do sistema e os usuários começaram a inserir dados de produção nele. Nesse período o acordo formal ainda não havia sido assinado.

Para o cliente essa forma de trabalho permitiu que eles utilizassem partes do sistema em um estágio muito inicial, ao invés de esperar pelo primeiro prazo planejado. Para seu planejamento de negócio isso trouxe um grande alívio. Eles imediatamente puderam começar a afinar o sistema baseado em experiências reais. Para eles, todo o processo de negócio era muito novo e eles não sabiam muito bem o que esperar.

A cada release novos participantes (do lado do cliente) foram introduzidos ao projeto. Representantes dos usuários finais estavam validando o sistema e forneciam feedback útil, o que permitiu à equipe de desenvolvimento aperfeiçoar o sistema e re-priorizar a implementação de algumas funcionalidades.

Essa abordagem resultou não só em um sistema funcional e estável, mas no bem otimizado, entregando o maior valor de negócio possível.

Graças à entrega iterativa, o sistema foi testado com frequência. A quantidade de problemas e de bugs potenciais foi consideravelmente reduzida por meio de testes automatizados e permitiu que a equipe teste a compatibilidade com versões anteriores.

Cada iteração terminava com a execução de testes automatizados que cobrem as versões anteriores do sistema – para se certificar de que toda nova versão não quebraria o conjunto existente de funcionalidades. Além disso foram criados novos testes automatizados para cobrir novos recursos e funcionalidades nos testes também. Adicionalmente os usuários finais estavam testando cada iteração.

Isso fez com que o aceite do sistema completo se torne uma formalidade.

Dicas para contratação ágil

Dependendo do tipo de cooperação, um contrato “burocrático” pode ser solicitado pelo cliente. Acreditamos que este não precisa bloquear uma cooperação ágil. Aproveite o tempo para chegar a um entendimento mútuo sobre as necessidades e demandas, alcance exato do projeto, abordagem de trabalho, etc. Defina as necessidades, sob a forma de estórias de usuários, porque isso estimula a todos para descrevê-las de uma forma mais compreensível do que as descrições funcionais normais.

Pode dar algum trabalho para convencer representantes dos clientes que estão apenas um pouco envolvidos no projeto. Não os “ataque”, é necessário perceber que eles podem não compreender totalmente o que significa uma abordagem ágil. Em geral, eles querem sentir que estão no controle e será necessário explicar como eles podem controlar um projeto ágil também.

Passo a passo, ao trabalhar juntos a confiança mútua crescerá e ambas as partes lucrarão com ela.

Em conjunto com o cliente, permitimos que um pouco de burocracia fizesse parte de nosso projeto ágil. Conseguimos limitá-la à papelada que o gerente de projetos conseguisse manipular. Ela suportava a governança do projeto de uma forma mais tradicional, uma forma que a parte interna da empresa do nosso cliente precisava. As equipes de desenvolvimento nunca foram incomodadas, eles desenvolveram a solução segundo o método Scrum. No final quase todo o orçamento teve que ser consumido, o que, para ser honesto, não nos surpreendeu. Já esperávamos por isso. Um significativo orçamento adicional para novos desenvolvimentos e para um acordo de manutenção de longo prazo, fez esse investimento do nosso lado mais que valer à pena. Nosso cliente ficou realmente feliz por ter uma solução funcionando muito bem ajustada no prazo e no custo aprovado.

Com base no projeto descrito, concluímos que é possível desenvolver um grande projeto de uma maneira ágil ao quebra-lo em pedaços menores. Levou algum tempo para definir esses pedaços e preparar um contrato equivalente, mas valeu à pena. Ao passar uma significativa quantidade de tempo juntos no início do projeto, compreendemos muito bem os desejos e as necessidades do outro. Esta compreensão mútua cresceu e se tornou confiança mútua quando percebemos o quão bem a cooperação acontecia, graças ao tempo inicial investido.

Agora podemos concluir que Mandela estava certo.

Fonte: InfoQ