Como todo início de projeto, recebemos apenas uma visão Macro do projeto, porém,para todo projeto existe um contrato e todo contrato é assinado na origem e não durante o desenvolvimento. Com isso, como iremos passar um custo e prazo plausível para o cliente?
Rafael, tudo bom?
Contrato por hora de trabalho da equipe. O mindset do cliente também deve ser outro para que não haja divergências durante o trabalho. Quando um cliente procura uma consultoria e aceita trabalhar com Ágil precisa entender que tem em mãos um projeto complexo e o que ele imagina no início pode não ser o resultado final, pois seu projeto vai ser guiado por feedbacks dos usuários.
Algumas consultorias vendem de forma errada o Ágil, por n motivos. Com isso acabam não fazendo Ágil, apenas adaptando o método tradicional e dessa forma têm dificuldades em manter uma forma diferente de receita. No Ágil o cliente não fica preso a um contrato, por isso a consultoria tem que mostrar serviço e garantir seus recebimentos.
Como fazer então um contrato assinado com escopo fechado mas o cliente quer o desenvolvimento ágil, ou seja, quer que seja entregue o que estava no contrato mesmo tendo diversas mudanças de escopo durante o desenvolvimento?
Renato, com um contrato assinado e um escopo fechado dessa forma não estamos fazendo Ágil certo? O cliente finge que tem uma mentalidade Ágil e a equipe finge que faz Ágil. Simples assim.
Mas calma, tentando achar uma solução. Vocês podem definir um Roadmap com as funcionalidades que serão entregues, e as ondas (releases) em que essas funcionalidades serão entregues. Com isso você pode organizar um Kanban com esse backlog ou mesmo usar algumas práticas do Scrum. Talvez com o tempo o cliente veja valor nessas entregas e comece a ponderar.
O que precisa ser deixado claro, isso não é Ágil. O cliente pode se enganar, a equipe pode se enganar, mas não é um mindset Ágil.