Olá pesoal!

Temos publicado aqui no blog uma série de posts referentes às dificuldades encontradas pelos usuários na adoção do Scrum.

Uma dessas dificuldades está relacionada à definição de um cronograma macro do projeto, já que no Scrum o “cronograma” é definido por versões.

Nossa experiência prática também nos defronta com essa questão em projetos de nossos clientes, com os quais desenvolvemos um trabalho de capacitação e implantação do Scrum em seus processos de desenvolvimento de software.

Muito bem! Sabemos que no gerenciamento de projetos de software o planejamento é um aspecto essencial para o seu sucesso. Por outro lado, também sabemos que cronogramas irreais são provavelmente um dos principais vetores que influenciam no aumento das taxas de projetos rotulados como contestados ou fracassados.

A alocação dos recursos e a definição do cronograma são algumas dessas atividades de planejamento consideradas muito importantes, porém complexas, pois abrangem aspectos como prazos, custos, dependências entre as atividades, estimativas e alocação direta de recursos humanos.

Mesmo com as ferramentas e as técnicas disponíveis, os gerentes de projetos continuam responsáveis por soluções de qualidade alinhadas aos objetivos das organizações. Via de regra, tais soluções ainda observam as boas práticas, o sentimento, o conhecimento e a experiência pregressa desses gerentes.

No PMBoK, conhecido guia de boas práticas da gerência de projetos, esta atividade enquadra-se no processo denominado desenvolvimento do cronograma.

Do lado do Scrum, ele vem sendo utilizado para o desenvolvimento de produtos complexos desde o início dos anos 90 e o Guia do Scrum descreve como usar o Scrum para desenvolver esses produtos.

Lá encontramos também que o Scrum é fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos: a transparência, a inspeção e a adaptação.

 

Pois bem! E as Versões Scrum e Cronogramas Macros de Projetos como ficam?

Ainda nos reportando ao Guia do Scrum podemos aprender que:

 

Os Eventos com Duração Fixa (Time-Boxes) no Scrum são a Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Reunião Diária.

Destacamos aqui a Reunião de Planejamento da Versão para Entrega, que é a que mais nos interessa no momento.

O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e comunicar.

Uma das questões a serem respondidas pelo planejamento da versão para entrega é:

Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?

O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para entrega a cada Sprint.

Muitas organizações já possuem um processo de planejamento de versão para entrega, e na maior parte desses processos o planejamento é feito no início do trabalho da versão e não é modificado com o passar do tempo. No planejamento de versão para entrega do Scrum, são definidos uma meta geral e resultados prováveis.

Esse planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava utilizar para produzir um plano de versão para entrega tradicional. No entanto, uma versão com Scrum realiza planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada Reunião Diária.

De forma geral, os esforços para uma versão para entrega com Scrum provavelmente consomem ligeiramente mais esforço do que os esforços para um planejamento de versão para entrega tradicional.

Planejamento de versão para entrega requer estimar e priorizar o Backlog do Produto para a Versão. Há diversas técnicas para fazê-lo que estão fora do alcance do Scrum, mas que apesar disso são úteis quando usadas com ele.

 

Esse é um assunto interessante a ser tratado, pois para algumas pessoas há a impressão de que quando trabalhamos com o Scrum, não podemos lançar mão de outros recursos por falta de compatibilidade ou por alguma outra razão.

No Scrum, normalmente após a definição e estimativa do backlog inicial, podemos estimar o tempo restante com base na velocidade da equipe para a primeira sprint. E nada nos impede de elaborar um cronograma com essas estimativas.

Os projetos são planejados para semanas, meses ou anos e, em nenhuma das abordagens (tradicional ou ágil) sabemos exatamente o que acontecerá no final.

Como exemplo, num projeto com prazo de seis meses fixos com orçamento pré-definido, podemos estabelecer o número máximo de sprints para o esse período. Pode ocorrer do projeto terminar antes desse número máximo de Sprints ou algumas funcionalidades serem replanejadas ou mesmo excluídas do Backlog do produto, como já ocorreu, de fato, em alguns dos nossos projetos.

Com o Scrum, o Product Owner pode saber e corrigir periodicamente erros e acertos do projeto, visto que as entregas são parciais (transparência, inspeção e adaptação.

Voltando ao Guia do Scrum:

 

Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo.

Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.

 

E finalmente, mas não menos importante, não podemos nos esquecer que o Scrum não é um processo ou uma técnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro do qual você pode empregar diversos processos e técnicas. O papel do Scrum é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro do qual produtos complexos podem ser desenvolvidos.

 

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Não esqueçam que, se precisarem, estamos prontos e experientes para ajudá-los nessa transição. Fale conosco em http://gpetec.com.br/informacoes.asp.

Encontro vocês num próximo post. Até lá!