O desenvolvimento de produtos antes do agile era um bocado complicado, as pessoas precisavam esperar longos período para organizar requisitos, depois para construí-lo, os testes eram feitos no final. Ao idealizador do produto cabia a árdua tarefa de adivinhar todas as necessidades no começo do projeto ou pagar pelas mudanças que fizesse. Um processo que deveria ser criativo se transformava em gerenciamento de contratos, prioritariamente.

Depois disso, chegou a filosofia ágil (ou simplesmente agile), com entregas parciais e incrementais, tempo fixo, custos por ciclos e escopo variável. As mudanças passaram a não ser mais encaradas como problemas e os testes eram feitos junto aos incrementos de produto. O idealizador ganhou velocidade para pôr o produto no mercado e trabalhar em cima da reações de seus usuários.

Acontece que muitas empresas ainda vivem no modelo anterior, em que os preços são “fechados” e o risco é totalmente do fornecedor. Com isso, acabam pagando mais caro pelos projetos, que carregam expressivas “gorduras”, passam pelas mesmas extensões de contratos e sofrem atrasos, sem que se deem conta de que seria melhor receber entregas menores, testar o produto no mercado e decidir, sem custo adicional, parar ou continuar o projeto.

Para amenizar esse problema e iniciar o processo de mudança, surgiu a abordagem híbrida. Neste post, apresento alguns conceitos, benefícios e um exemplo de como tenho aplicado essa abordagem por aí afora.

O que é?

A abordagem agile híbrida procura juntar os benefícios da filosofia ágil aos projetos tradicionais (com escopo, preço e custo “fechados”), é aplicada a clientes que estão iniciando as fases de conscientização e de transição.

As principais diferenças em relação ao agile convencional são:

Abordagem Agile

• Tem escopo variável e preço por sprints
• Segue o conceito de time box
• O prazo do projeto é flexível, conforme a complexidade das estórias que entrarem/saírem
• A velocidade do time tende a crescer com o tempo
• Mudanças são bem-vindas

Abordagem Híbrida

• Tem escopo, prazo e preço fixos
  Bem,  nada na vida é fixo. A própria existência é efêmera, os continentes do planeta mudam de posição ao longo dos séculos e até o tempo sofre variações em relação os nossos relógios e calendários. Mas, em contrato, esses projetos se comprometem a cumprir uma data específica, num preço pré-determinado para cumprir certo conjunto de requisitos.
• O cronograma é montado em sprints com time box
  Sim, no começo os clientes ainda precisam de gráficos de Gantt organizados por sprints, a lista das estórias e um dicionário do que cada delas representa.
• A ordem das estórias de usuários pode ser alterada a cada sprint
  Trabalhar por sprints e poder alterar a ordem de prioridade das estórias já representa um grande benefício para o cliente. Claro que ainda há clientes desejosos de ver cadastros e integrações antes de testar o produto, mas o conceito do MVP precisa ser institucionalizado através do tempo.
• Alterações nas estórias são tratadas como Change Requests
  Para educar é preciso explicitar os impactos das decisões. Quando uma estória é substituída, às vezes, há impacto em outras e é preciso explicitar esse impacto com uma “estória de change request”. Da mesma forma, se houver retrabalho numa estória que foi modificada, especialmente se já tiver sido implementada total ou parcialmente, é preciso mostrar claramente também.
• O Product Owner pode ser assessorado por um analista funcional
  Pois é, no começo o cliente não percebe o quanto é benéfico participar do projeto (como pig), por isso aportar um analista funcional para ajudar a descrever os requisitos tem sido uma alternativa mais plausível.

Por que usar?

É muito simples, quem nunca usou agile precisa se aculturar para perder o medo. Qual gestor contrante vai arriscar seu emprego por causa dos depoimentos de outras pessoas?

O cliente precisa conhecer as vantagens e diferenças do modelo ao qual está acostumado, experimentar, adaptar à sua realidade, fazer alguns projetos e, só então, estará preparado confiar num fornecedor e se “aventurar” no agile.

As principais vantagens e desvantagens do agile híbrido, que podem ser usadas para convencer um cliente a experimentar:

Vantagens

• Permite o cálculo de um preço fixo
  Quantidade de sprints x velocidade estimada do time, que obviamente deve ser recalculada quando se modificar. O que não quer dizer que o prazo poderá se modificar, portanto seja cauteloso.
• As entregas são feitas conforme a prioridade de negócio
  É preciso auxiliar o cliente a definir suas prioridades, caso contrário fará modificações demais, receberá avisos de impactos de changes e ficará insatisfeito com o modelo.
• Mantem-se as cerimônias do Scrum (daily meeting, review e retrospectiva)
  É muito difícil fazer o cliente participar no começo, para isso, temos usado grupos de Whatsapp e agendas fixas para as cerimônias de review/retrospectiva, que acabam entrando na rotina do cliente com o tempo.
• Testes e homologação são (e devem ser) realizados em paralelo às sprints
  Esse aspecto é difícil de implementar em alguns clientes, pois estão habituados a testar apenas no final, às vezes têm até procedimentos para isso. A sugestão é iniciar com testes internos (pelo próprio time, perfil de testes) e gerir claramente o que é/não é bug e suas causas, quando o cliente começar a testar.

Desvantagens

• Planejamento detalhado
  Existem muitas expectativas diferentes sobre o projeto, pessoas que estão afim de experimentar o agile e outras não. Para atenuar a questão é preciso montar um planejamento detalhado para alinhamento das expectativas, ferramentas e processos.
• Documentação
  Se há o risco de uma entrega não ser aceita por um mal entendimento e, com isso, haja a possibilidade de prejuízo financeiro para o fornecedor, é necessário formalizar detalhadamente o escopo para garantir que permaneça sob controle.
• Modificações bruscas
  Se o projeto for modificado bruscamente,  deve-se abrir uma negociação contratual. Caso contrário, no dia da entrega, algum stakeholder menos informado poderá cobrar o escopo original.
• Alterações ou acréscimos de escopo geram cobranças adicionais
  Sim, se houver modificações é preciso fazer cobranças adicionais baseadas no impacto no tempo.

Como aplicar?

Bem, se você não surtou e fechou o texto até agora, deve estar realmente interessado em criar um mecanismo para fazer o agile acontecer ao longo do tempo. Nenhuma mudança cultural acontece da noite para o dia, é preciso ganhar a confiança das pessoas envolvidas diretamente no projeto e passar confiança às interessadas de que receberão o que adquiriram.

Um pouco de realidade

Certa vez participei de um projeto em que foram necessários 6 meses de agile híbrido até que o cliente aceitasse usar o agile convencional. Na época, aceitamos uma quantidade de story points muito alta e fomos bastante otimistas na estimativa.

Como era um “preço fechado”, foi preciso virar muitas noites para fechar a primeira fase do projeto, que levou 3 meses. O cliente estava tão desconfiado que tinha “espiões” na daily meeting e até uma bi-daily meeting, em que o Scrum Master precisava repassar o status detalhado das tarefas (sim, das tarefas) para todo o corpo executivo.

Houve tensão, conflitos e várias pessoas deixaram o projeto. Mas, no final do período, não apenas havíamos entregue o escopo combinado, mas também lidado com com incontáveis indefinições e redefinições.

O cliente percebeu que o fornecedor não fazia o projeto sozinho, entendeu que o aumento da velocidade de um time motivado era mais “lucrativa” que cobrar as estimativas originais e, no segundo ciclo de 3 meses, pudemos revisar as estimativas e trabalhar com mais qualidade e conforto.

Do sétimo mês em diante, começamos a trabalhar com agile puro e, conforme os meses passaram, o cliente pôde incorporar um aumento de velocidade bem superior a 50%, se beneficiando duplamente, tanto na velocidade quanto na flexibilidade.

Pilares do Agile

Sejamos práticos, o agile tem três pilares e devemos observar (e divulgar claramente) os impactos das mudanças metodológicas. Até então, como temos implementado?

• Transparência
  O cliente recebe status diários do andamento do seu projeto através do gráfico de burndown, além de ter acesso às estórias de usuário e tarefas através do kanban
• Inspeção
  O cliente participa do processo de inspeção (testes e homologação) logo após o término de uma sprint, evitando riscos ao final do prazo do projeto
• Adaptação
  O cliente pode fazer alterações na ordem das estórias de usuário de uma sprint e até substituí-la por outras com a mesma complexidade, mas não pode gerar retrabalho ou adicionar mais pontos que a velocidade do time por sprint. Se o fizer, deve ser conscientizado de que talvez a sprint não entregue todo o combinado.

Cerimônias e papéis

Sabemos bem que o Scrum tem fortes restrições quanto às suas cerimônias e papéis, mas o cliente ainda não sabe, então é preciso educá-lo. O quadro abaixo pode ser utilizado para ajudá-lo a lembrar no calor do dia a dia.

Prazo e Custo totais do projeto

O custo de um projeto agile é calculado a partir da quantidade de pessoas alocadas x a quantidade de sprints. Deste modo, o cálculo de prazo é o ponto mais importante na aculturação do cliente.

Já falei anteriormente sobre como calcular o prazo de um projeto Scrum e como contar story points, mas vejo como decisivo permitir que o cliente tire vantagem da curva de aprendizagem. Quanto mais um time trabalha junto no mesmo projeto, mais veloz se torna, se esta produtividade adicional for repassada para o cliente, a confiança será gerada.

Gerenciamento do Escopo

O último ponto é deixar claro o impacto das  mudanças. O que temos utilizado é um story map que permita ao cliente notar três coisas:

1. O quanto ele precisa mudar requisitos (estórias de usuário) ao longo do projeto
2. Como somos flexíveis permitindo que ele não tenha custos adicionais ao substituir uma estória e
3. Como somos justos na avaliação das pontuações, ou seja, não estamos lá para enganar ninguém.

Esse quadro é coberto por 4 regras:

1. Uma nova demanda recebe proposta em story points e entra nas sprints conforme a priorização do próprio cliente
2. O time é fixo e a periodicidade das sprints também é fixa, somente assim se pode medir a produtividade em story points
3. Sabe-se se há espaço na agenda do Scrum Team através dos story points apontados
4. Deve-se designar um Product Owner, responsável por levar estórias a ready, priorizar o funil e revisar o resultado das entregas.

Basicamente, é isso. Com o tempo, o cliente se acostuma e acaba por entender que é muito mais vantajoso começar logo o trabalho a perder tempo com planejamentos que sabe-se que irão mudar.

Eli Rodrigues