Muitos acreditam que agile em projetos de escopo fechado não funciona. Será?
Um projeto de escopo fechado contém a descrição mais completa possível do software que deverá ser construído, com a qual stakeholders e áreas técnicas concordam. Chegar a esse nível de detalhe dá trabalho: times se reúnem por semanas, estudando o mercado, usuários e questões técnicas, equalizando todos esses fatos a demandas e interesses das partes, para obter itens, prever esforço, prazos e orçamento.
O resultado, no entanto, é compensador: requisitos definidos, projeto planejado em alto nível de detalhe em termos de orçamento, entregas, prazo e equipe. Tudo pensado antes de que qualquer linha de código seja escrita, para que nada dê errado, nenhum problema surja pelo caminho, dada a clareza do direcionamento.
Mas, como todos sabem, mesmo com todo o preparo do escopo fechado, o desenvolvimento não é livre de problemas, sobretudo os oriundos de um detalhamento pouco realista e limitações contratuais, que acabam restringindo a margem para modificações.
Para muitos, o único remédio para tais problemas é o agile. Só que, então, envolver agile com escopo fechado inviabilizaria completamente os projetos de escopo fechado. Será mesmo?
É o que discutiremos neste artigo.
Os problemas do escopo fechado
A experiência mostra da pior maneira os problemas do escopo fechado. Já vimos projetos de 3.800 horas com apenas 63% de execução. Isso significa que 37% do trabalho previsto não foi executado. É uma perda para o cliente e para a fábrica de software. Por que isso ocorre?
A falta de detalhamento de requisitos, aliada a pouca flexibilidade dos contratos para mudanças, é responsável por tais resultados. Para citar alguns problemas: suposições baseadas em hipóteses que se mostram erradas, salto irrefletido e direto para programação e mudanças no código que poderiam ser evitadas facilmente, mas que o deixam mais frágil.
Como os projetos de escopo fechado são baseados em estimativas, não é raro que sejam pouco realistas. Então, mesmo que tanta energia e tempo sejam dedicados a obtê-lo, no final não é raro que a entrega contratada não aconteça dentro do prazo e do orçamento previsto.
Um pouco sobre agile
O agile surge com a pretensão de ser um remédio para os problemas dos projetos de escopo fechado.
Suas práticas se montam sobre quatro valores fundamentais, expressos no Manifesto pelo Desenvolvimento Ágil de Softwares:
- Indivíduos e interações acima de processos e ferramentas
- Software funcional acima de documentação
- Colaboração com o cliente acima de negociação de contrato
- Resposta à mudança acima de seguir um plano.
Basta uma leitura dos valores do agile para compreender que se contrapõem diretamente ao que ocorre no projeto de software de escopo fechado.
Do ponto de vista ágil, por que se manter apegado a uma negociação obsoleta se ela está levando a um produto que ninguém deseja? Por que se manter em um plano se você já percebeu que não houve precisão na definição do escopo e os clientes não estão satisfeitos com o projeto?
Então, a pergunta é: é possível ser ágil em um projeto de escopo fechado? Não podemos simplesmente ir executando e cobrando?
Agile em projetos de escopo fechado: é possível?
Acima, dissemos que muitos times trabalham bem com projetos de escopo fechado. Mas eles são ágeis?
De acordo com Andrew Stellman & Jennifer Greene, autores do livro Learning Agile, o sucesso do escopo fechado não se deve apenas à aplicação correta dele ao tipo de projeto. Para os autores, há mais.
O time geralmente tem uma comunicação boa e contínua com usuários e stakeholders ao longo do projeto e adota boas práticas de desenvolvimento (como testes automatizados).
Para os autores, esses times, por fim, adotam muitos dos valores, princípios e práticas ágeis. Veja que eles não afirmam que times com projetos de escopo fechado adotam ferramentas e técnicas agile apenas, mas valores e princípios.
Isso parte da consciência de que o escopo aberto ou fechado não é o que importa em última instância. Times que simplesmente usam agile em projetos de escopo aberto normalmente caem nos mesmos problemas que os times que não usam agile em projetos de escopo fechado.
Mas o que os times bem-sucedidos em projetos de escopo fechado fazem?
Agile em projetos de escopo fechado: como funciona?
Nesse tipo de projeto de software, existe um escopo fechado, porém o time se beneficia de princípios e práticas ágeis sabidamente úteis: como os releases contínuos, entrega de software funcional ao fim de cada iteração e abertura a mudança.
Afinal, mesmo no escopo fechado, equipes técnicas e de negócios já entenderam que selar o projeto depois que ele foi aprovado e só discuti-lo de novo quando ele for entregue pronto não é uma decisão inteligente, quando se quer construir um bom produto.
Vejamos o que os times fazem.
1. Entram no universo do cliente
A primeira atitude agile em projetos fechados é entender que agradar o cliente não significa agir sob comando-e-controle: você diz e eu faço.
A experiência de uma fábrica de software, acumulada ao longo de inúmeros projetos, de vários tamanhos e em vários clientes, mune-a com não só com boas práticas de gestão, mas com conhecimentos de mercado, tecnologias e ferramentas etc.
Então, mergulhar no universo do cliente e de suas necessidades e expectativas com todo esse conhecimento na bagagem, praticando a escuta aberta, mas crítica, é uma forma de evitar os problemas do escopo fechado.
De acordo com Matheus Jaschke, Gerente de Projetos aqui na Supero:
Nós entramos no mundo do cliente. Não ficamos limitados ao que estava no projeto. Nós tomamos um café com nossos clientes; fazemos reuniões; entendemos o negócio deles; pesquisamos sobre o negócio; fazemos relacionamento com demais stakeholders, não apenas os diretamente envolvidos no projeto; e questionamos os objetivos do projeto, para entender aonde os clientes querem chegar.
2. Sabem que tipo de escopo é de fato a melhor opção para o projeto
Partimos da premissa de que todo projeto precisa de um escopo. A diferença entre escopo fechado e aberto é o quão definido esse projeto vai ser em termos de itens, prazo e orçamento.
Sabemos que o escopo fechado é útil em projetos com requisitos bem conhecidos e estáveis, sem grande margem para decisões distintas ou mudanças e de escopo pequeno.
Já projetos com escopo aberto se adequam a iniciativas grandes ou contínuas, com funcionalidades que podem variar de acordo com a necessidade. Por isso, esse tipo de projeto é construído para abrigar essas mudanças em seu escopo, design e arquitetura, desde o princípio.
O cliente precisa entender e reconhecer com clareza de que tipo é o seu projeto e que tipo de abordagem melhor o atende. Com base nesse entendimento, ele terá subsídios e confiança para decidir de acordo com o seu mindset.
3. Trabalham com o metodologias de construção de MVP
Por mais que o projeto tenha requisitos e escopo claros, trabalhar com o conceito de MVP, partindo das metodologias de qualidade comprovada para chegar a ele – como Design Sprint, Lean Inception e Product Backlog Building etc. – é mais uma maneira de se munir contra possíveis desperdícios, sejam eles de quaisquer ordem.
Além disso, partir de um MVP tem outras vantagens. O processo de obtenção dos itens é bem mais curto e efetivo.
Já na execução, construir o product backlog priorizando histórias dos usuários em ciclos de desenvolvimento coroados com entregas de software funcional para receber feedback de stakeholders e clientes, gerando aprendizado validado, é a maneira certa de garantir que o curso do projeto é o certo, sendo de escopo fechado ou aberto.
4. Comunicação constante com clientes
Se mesmo para times que se comunicam constantemente é possível que cada um tenha uma impressão diferente do que foi discutido e do resultado de uma reunião, que dirá se essa comunicação sequer ocorrer?
Não é incomum que equipes de projetos de escopo fechado se comuniquem com menos frequência com stakeholders e clientes, já que o ritmo de desenvolvimento – não baseado em ciclos iterativos incrementais – é distinto.
Há casos em que os líderes sequer querem ser incomodados com questões de dia a dia sobre o software.
O agile cria mecanismos para que a comunicação aconteça constantemente, tanto retrospectivamente – sobre o caminho já percorrido – quanto em relação aos próximos passos – validando em tempo decisões tomadas no início do projeto e sobre questões não previstas. Na Supero, como explica Matheus Jaschke, Gerente de Projetos:
Apresentamos toda a equipe para o cliente, chamamos o cliente para participar de plannings, para que ele enxergue como que é a metodologia ágil. Então, nós trazemos o cliente para o projeto.
5. Abertura à mudança
Andrew Stellman & Jennifer Greene, no Learning Agile, dizem: projetos de escopo fechado sem uma pegada agile podem ser bem-sucedidos no primeiro release. Já depois.... Com um software criado em um ambiente de mudanças controladas, o time não tem muito incentivo para desenhá-lo para ser modificado posteriormente.
Assim, nos demais releases, quando se trata de modificar o produto com base no feedback dos usuários e de implementar com o software já em funcionamento, o que acontece com um software construído de um modo mais difícil de mudar?
Um grande impacto no código-base. Então, pequenas mudanças tornam-se a reescrita completa do código. Retrabalho é, segundo os autores, a maior fonte de bugs em projetos de escopo fechado.
Por isso, não é raro que times que trabalhem em projetos desse tipo sejam menos afeitos a mudanças, sobretudo quando as demandas surgem lá na frente, com boa parte do caminho andado.
Trazer a mudança como uma premissa faz com que o time prepare a arquitetura e o código para isso.
6. Mantém-se no prazo, não no escopo
Normalmente, em projetos de software, o escopo é fixo e se negocia o prazo, em virtude do qual a qualidade pode ser sacrificada.
Dentro de uma pegada agile, pode-se fixar o prazo, mas negociar o escopo. Para Matheus Jaschke, isso significa:
No decorrer do projeto, estabelecemos acordos e fazemos muitas trocas. Não geramos impedimentos. Realizamos trocas de itens e de definições, resolvendo os problemas do cliente. Você entende o problema e age rápido. Você faz uma mudança rápida porque tem um prazo. E mostra que você consegue mudar de rota rapidamente, com uma limitação de contrato.
Agile em projetos de escopo fechado
Embora tampouco seja uma bola de prata, o agile mostrou o seu valor por meio dos benefícios que produz em projetos. Mas, como vimos, mais do que suas práticas, seus valores se mostram fundamentais em projetos de escopo fechado.
Praticar agile em projetos de escopo fechado, dentro da Supero, tem levado à mudança da execução de projetos para o escopo aberto com muitos clientes.
E na sua empresa? Como os projetos de software são desenvolvidos, com escopo fechado ou aberto?
Conheça nossa fábrica de softwares e entenda como fizemos para entregar 900 mil horas de projetos bem-sucedidos.
