Estimativas ágeis

mundo-agil-rodrigo-zambon-agilidade-estimativa-burndownRecentemente fui chamado para facilitar mais um treinamento de MS Project, e eu recusei. Algumas empresas se orgulham de ostentar na parede um belo gráfico de gantt para representar as relações entre as tarefas, os recursos necessários e a cronologia de entrega dos pacotes.

É impressionante a precisão. Em umas das minhas visitas consegui identificar que daqui a exatos 8 meses, ou seja, no dia 22 de novembro o recurso John Doe estará fazendo cotações de preços para compra de cadeiras, sendo que estará alocado part time no projeto e que para concluir esta atividade, ele depende do layout da sala. Vale lembrar aqui que todos os requisitos desta cadeira estão devidamente definidos aliás, todos os requisitos deste projeto já estão definidos.

Estimativas como as descritas acima são comuns e apresentam um alto grau de precisão, porém o percentual de acerto é baixíssimo. Outras questões são as seguintes: será que os requisitos permanecerão os mesmos? Será que daqui a 8 meses, ao invés de cadeiras não seria melhor comprar bancos ou sofás? E se o projeto for abortado, de que valeu todo aquele esforço de planejamento?

Estimativas sem acurácia são frequentes no planejamento tradicional. Por exemplo, se eu afirmo em meu cronograma, que determinado pacote de trabalho será entregue no dia 02, essa é uma estimativa de alta precisão, independente do dia real de entrega. Entretanto se ele ficar pronto no dia 15, essa estimativa foi completamente sem acurácia e errada.

Muitas de nossas estimativas são passadas sem se calcular o mínimo de esforço necessário para concluir a tarefa. Às vezes, passamos para agradar o cliente, ou não o perder. Talvez porque queiramos agradar o gerente ou até por medo de sair do projeto.

Uma das características do Gerenciamento Ágil de Projetos é que podemos começar o projeto com os requisitos que temos disponíveis. Podemos montar o nosso backlog à medida que avançamos no projeto. O esforço inicial de coleta de requisitos no gerenciamento tradicional leva tempo, e um esforço considerável da equipe, dependendo da complexidade do projeto.

O produto é construído em ciclos de iterações, e em cada um destes ciclos é apresentada uma pequena parte do produto. A primeira sprint, certamente representará o que gera mais valor para o cliente, pois o backlog é priorizado de acordo com o ROI. Os itens na parte superior do backlog são mais detalhados e permitem maior compreensão por parte do time.

O mais comum para se estimar tempo no scrum, mesmo que de forma relativa, são os story points. Na verdade, estão mais voltados para o esforço, do que propriamente tempo. O time de desenvolvimento é o único responsável para definir o tamanho das estórias. As melhores pessoas para estimar o esforço é quem desenvolve o produto. Parece obvio, mas isso é ainda muito ignorado em projetos. Acredite!

Uma alternativa para identificarmos o trabalho que ainda precisa ser feito, e também uma forma visual de acompanharmos o desempenho do time é o gráfico de sprint burndown. O gráfico mostra a quantidade de pontos de estórias no eixo y e no eixo x os dias relativos a sprint atual.

Muitos times ágeis optam por não marcar a linha ideal para evitar cobranças desnecessárias.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo!

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Responder a mudanças mais que seguir um plano

rodrigo-zambon-mundo-agil-responde-mudancas-mais-seguir-plano-artigo-manifesto-agil-declaracao-interdependenciaO título deste artigo é muito familiar, pois trata-se um valor ágil. Está escrito no manifesto. Não significa que não vamos ter um plano, ou ainda que não vamos segui-lo. A questão chave é que se tivermos que escolher entre aplicarmos uma mudança para gerar valor para o cliente, ou seguir cegamente um plano, vamos optar sempre pela primeira opção.

A princípio isso, para o gerenciamento tradicional isso pode soar um pouco estranho: Mas nunca teremos o escopo fechado? Como vou entregar a composição de custos deste projeto ao meu cliente? Mudar sai caro, vou ter que mudar toda hora? E a definição dos requisitos, não está fechada? Mas nós temos a assinatura no termo de abertura.

As mudanças são inevitáveis dentro de um projeto. O gerenciamento tradicional foca no acompanhamento do plano, e principalmente nas restrições de escopo, tempo e custos. O sucesso é medido pela adequação a estas variáveis, deixando para segundo plano a satisfação e o valor para o cliente. No gerenciamento ágil, estamos focados em receber e assimilar as mudanças da melhor forma, conscientes de que elas irão acontecer.

No ágil, vamos inverter a prioridade. A meta é gerar valor e entregar sempre produtos com qualidade. De preferência ao final de cada sprint, para que o cliente possa participar da construção do produto e oferecer feedback frequente. No gerenciamento tradicional a entrega é feita no final e a prioridade é seguir o plano, guiado pelas restrições.

A adaptação do processo e a inspeção do produto são pilares fundamentais para as boas práticas ágeis. Ao final de cada sprint, o time se reúne com o cliente para obter as considerações e ouvi-lo. As mudanças podem ocorrer neste momento, mas precisamos desconstruir o mito de que não há controle. O Product Owner participa e conversa. Negocia se o que o cliente está pedindo faz ou não sentido. Não é só entregar o que o cliente quer, vamos entregar o que ele precisa.

Trazendo para o cenário prático, o que vai determinar um de seus diferenciais no gerenciamento de projetos é a sua capacidade de se adaptar as mudanças. O quão rápido você consegue reagir e flexibilizar seu time para atender uma demanda não antes prevista?

A Declaração de Interdependência diz que “Esperamos incertezas e gerenciamos levando-as em conta, por meio de iterações, antecipação e adaptação.”, ou seja não vamos seguir um plano obsoleto só porque está escrito lá, se tivermos que mudar, isto será feito conforme necessário.

Ainda na Declaração de Interdependência temos a seguinte afirmação “Entregamos resultados confiáveis, engajando os clientes em interações frequentes e propriedade compartilhada”. Isto amplia a participação do cliente, engajando como parte do time, como um colaborador. Diferente do tradicional que o cliente só participa no início quando impõe um requisito, e no final quando recebe o produto, no ágil ele é parte fundamental na construção.

Para finalizar, segue abaixo a conhecida pirâmide das restrições no gerenciamento tradicional e a mudança para o gerenciamento ágil:

pirmaide-tradicional-agil-rodrigo-zambon-mundo-agil

Restrições são importantes variáveis, mas não são a meta do projeto.

Vamos tornar o Mundo mais Ágil. Até o próximo artigo.

Para saber mais:

Manifesto Ágil: http://agilemanifesto.org/

Declaração de Interdependência: http://pmdoi.org/

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.