Olá tudo bem?

Você usa cronograma em seus projetos?

Certamente já deve ter usado…
…ou pelo menos já te pediram para criar um 🙂

Neste artigo eu vou falar sobre o uso de cronogramas em projetos ágeis, mais precisamente, projetos que usam Scrum.

Mas é possível isso?

Sim, é possível…

Ok, mas é útil?

Claro!

Principalmente se sua empresa, seu chefe ou seu cliente tiverem uma cultura tradicional e, consequentemente, uma expectativa tradicional em relação aos projetos que delegou para você e sua equipe.

O Cronograma Ágil

Existem algumas perguntas que eu recebo com frequência dos meus alunos e leitores com relação aos uso cronogramas no universo dos projetos ágeis:

• Como faço um cronograma para o meu projeto sem infringir os valores do Scrum?
• Apesar de explicar como é um projeto ágil, meu chefe pediu um Cronograma do Projeto, o que eu faço?
• Se eu não devo detalhar ou fixar todo o escopo no início projeto (projeto Scrum), como posso fazer um cronograma detalhado do mesmo?
• Projeto Scrum = Projeto sem cronograma?

Vamos lá, vamos responder esta e outras questões aqui!

Projeto Ágil = Projeto sem Cronograma?

Existe este mito na comunidade de gerenciamento de projetos que precisa ser desmistificado.

Como não existe a figura do Gerente de Projetos formalmente descrita no Scrum (e é o Gerente de Projetos quem normalmente fica a cargo de fazer o cronograma do projeto) é comum que as pessoas achem que não pode haver um cronograma também.

Todo projeto ágil é igual a projeto sem cronograma? Não necessariamente!

Claro que em empresas com uma cultura ágil bem solidificada, normalmente a gente não vê esta necessidade constante por cronogramas.

É comum até que estes nem sejam feitos nestas empresas…
… o que não quer dizer que o projeto não tenha controle!

O cronograma é uma ferramenta de gestão como qualquer outra. O que o pessoal acaba fazendo é substituindo esta ferramenta por outras para fazer a gestão do andamento do projeto, como por exemplo, um quadro de tarefas (Kanban Board), um gráfico de Burndown ou qualquer outra.

Mas como faço para gerenciar as expectativas dos envolvidos sem um cronograma?

Uma das principais razões que fazem as pessoas gostarem tanto dos cronogramas é a sensação de controle sobre o que está acontecendo.

Isso faz parte do ser humano, esta necessidade de estar no controlar da situação, de “prever” o que vai acontecer antes que aconteça para que possamos nos preparar para eventuais contratempos.

Como em projetos tradicionais o que mais vemos historicamente são contratempos destruindo todos os planos meticulosamente desenhados, o pessoal acostumado com esta abordagem entra em uma espiral contra producente.

Eu chamaria até de Espiral Destrutiva!

Pois ao tentar prever de início todos os contratempos possíveis para tentar criar um plano muito bem detalhado e infalível o que normalmente acontece é a frustração do Gerente de Projetos por descobrir que o seu plano não sobrevive ao campo de batalha.

E quanto mais detalhado o plano, maior a dificuldade de mantê-lo atualizado.

Ok, talvez você já entenda isso…
…a ideia aqui não é te convencer dos benefícios da abordagem ágil (existe um post dedicado a isso aqui).

O ponto é que, mesmo sabendo que um cronograma detalhado é uma utopia que só vai te dar trabalho para criar e manter atualizado, existe uma expectativa dos seus chefes ou cliente por datas.

E essa expectativa é legítima!

Muitas vezes ela pode ser uma data inegociável, como por exemplo em projetos que envolvam entregas legais, onde uma Lei ou uma Medida Provisória impõe uma data para que algo seja entregue.

Como resolver isso no Scrum?

Planejando suas Macro Entregas (o famoso Release Plan)

No planejamento de um projeto ágil, existe uma etapa muito importante que é chamada de Release Plan.

É onde planejamos as macro entregas do projeto… ou em português mais claro:

Quando vai ser entregue o que!

É aqui que nos suprimos a expectativa de datas dos envolvidos.

E é aqui que você pode criar um cronograma de marcos do projeto… não vou entrar em detalhes sobre como fazer o Release Plan neste artigo, pois o assunto é denso (temos algumas aulas exclusivas para este tema em nosso curso de Scrum).

O cronograma de marcos é ótimo para sanar as expectativas de datas dos envolvidos.

Mas talvez isso ainda não resolva o seu problema pois muitas vezes nos é solicitado um cronograma detalhado dos próximos passos. E isso, no Scrum, se resolve no Sprint Planning.

E o desafio principal é conseguir mostrar que o cronograma deve ser flexível da mesma forma que o escopo dos sprints são flexíveis.

Cronograma Flexível

Nos cronogramas de projetos tradicionais é comum vermos uma tentativa de se prever em detalhes todas as atividades que serão necessárias para a entrega de determinado item, ou determinada fase do projeto, com responsáveis, datas de início e término, relacionamentos entre tarefas, etc

Na prática, (pelo menos para projetos complexos, como os projetos de software) o que acabamos vendo é que é utópico achar que conseguirá prever em detalhes, com uma certa antecedência, tudo o que poderá acontecer, quem fará o que, como será feito e em que ordem.

Mas mudanças acontecem o tempo!

Acaba que o cronograma precisa de uma atualização constante (quanto mais granular forem as atividades, mais constante deverá ser a atualização) e, depois de um tempo, descobre-se que o esforço gasto para manter este micro-gerenciamento não paga o seu benefício.

Outra questão importante é que o Gerente e Projetos, mesmo que bem assessorado, não deveria ser o responsável por ditar como a equipe deve fazer as coisas… muitas vezes ele simplesmente não sabe e suas “previsões” dificilmente acabam dando certo.

No scrum, o Product Owner decide o que deve ser feito mas quem decide como as coisas serão feitas é a equipe. E, como o processo ágil é um processo empírico, a equipe vai aprendendo e melhorando a forma de fazer conforme o projeto avança.

E, também por conta do processo ser empírico, o Product Owner pode mudar a prioridades dos itens do Product Backlog, incluir novos itens ou até mesmo excluir outros, conforme o projeto avança.

Afinal, ele também não é capaz de prever em detalhes tudo o que ele precisa no início do projeto… na prática, ele vai aprendendo conforme o projeto anda. E o processo do Scrum é feito justamente para comportar isso.

Isto posto, o que tenho a dizer é que, assim como o escopo dos Sprint é flexível, o seu cronograma também deve ser.

Mas Denisson, você não disse que ter um cronograma que demanda uma frequência alta de atualização não é muito produtivo? Um cronograma flexível significa que terei que ficar atualizando o tempo todo!

Isso mesmo, mas não com a mesma frequência e pelos mesmos motivos de quando se tenta colocar todas os detalhes do “como fazer” dentro do cronograma.

O pulo do gato aqui é detalhar no máximo até o nível de Estórias.

Um amigo meu escreveu um post muito bom falando disso… confira o post do Fábio Cruz aqui.

Como fica o cronograma então?

Conforme o projeto avança nos sprints, você atualiza o cronograma conforme a atualização de prioridades do Product Owner.

Os sprints tem duração fixa (normalmente de 2 a 4 semanas), logo em seu cronograma você deverá refletir isso.

Você vai precisar de basicamente 3 níveis no seu cronograma:

1. Release
2. Sprint
3. Estória

Algumas pessoas até se arriscam a criar cronogramas detalhados dos sprints, uma vez que durante o sprint planning temos a explosão das estórias em tarefas, mas, particularmente, não vejo benefícios dessa abordagem.

Existem abordagens mais eficientes para isso, tal como o uso de um quadro de Kanban e um gráfico de Burndown.

Gerenciando as expectativas com a Velocity

Legal, você entendeu como estruturar o cronograma, mas deve estar se perguntando:

Como eu faço para saber quantos sprints serão necessários para entregar todo o Product Backlog? Afinal, como os sprints tem um tempo fixo, é a quantidade de sprints que vai determinar a data final do meu projeto!

Isso mesmo, é a quantidade de sprints que vai determinar a data final do seu projeto. E, a melhor forma de descobrir quantos Sprints serão necessários, é descobrindo a sua Velocity.

Que nada mais é do que o quando a sua equipe é capaz de entregar durante o tempo determinado para o Sprint.

E como descobrir isso?

Em empresas maduras esse número é conhecido, mas para quem está implantando Scrum agora, você vai precisar rodar pelo uns 2 Sprints, medir e registrar o quanto foi entregue, e, com base nesta média, estimar o necessário para entregar o resto.

Claro que estou simplificando um assunto que é muito maior que isso, estimativas ágeis é um tema grande que não caberia nem um único post…

(só para ter uma ideia, existem diversos livros sobre o assunto, em nosso curso Scrum Definitivo, dedicamos algumas aulas inteiras só para aprender este assunto).

Mas o que quero passar aqui é que esta abordagem é muito mais assertiva do que as abordagens tradicionais… pelo menos para projetos de natureza complexa.

Talvez não seja a melhor abordagem para um projeto de construção civil, por exemplo, onde os processos de construção são muito bem definidos e o escopo não sofre mudanças constantes conforme o projeto vai sendo desenvolvido. Mas para projetos complexos, com mudanças constantes, certamente é a melhor abordagem.

Conclusão

É possível criar um cronograma para projetos ágeis, m as não da mesma forma como o mesmo é feito para projetos tradicionais.

Não se deve tentar micro-gerenciar tarefas em cronogramas ágeis deixando os mesmos seguirem a mesma flexibilidade do Scrum.

Como eu sempre costumo dizer:

No Scrum, não cravamos o escopo na pedra!

E você, o que acha disso?

Deixe seu comentário abaixo dizendo sua opinião a respeito deste tema.