Seu cliente precisa saber o andamento do projeto

Sintoma: no dia a dia o cliente envia emails perguntando a situação de determinada história e o andamento do projeto completo. Os desenvolvedores tem grande parte de seu tempo diário consumido para fazer um relatório de situação, ao invés de focarem em seu trabalho principal, o desenvolvimento.

Ação: como cliente sempre surge um desejo natural de entender a situação atual do que foi contratado: desejamos ter uma previsibilidade do que irá acontecer a curto prazo, mesmo que imprecisa.

Ao contratarmos um serviço de reforma, desejamos saber se o encanamento está pronto para que passemos a execução da pintura da parede. Se algum problema mais grave ocorrer, é importante que o cliente saiba logo para não ser pego de surpresa quando do atraso do projeto.

Em todos os cenários, é importante para o cliente conhecer o andamento do projeto para que, quando o mesmo não esteja andando, isto é, um impedimento esteja presente, possa ajudar a resolver o problema de alguma forma.

Tudo isso acelera o ciclo de feedback da situação do projeto para o cliente e um dos recursos mais comuns para isso é o uso do gráfico de Burndown. Nele plotamos os pontos a serem desenvolvidos na iteração atual, e decrescemos o mesmo a medida que as histórias são aprovadas de acordo com o conceito de pronto.

Na iteração atual desenhamos a linha média de acordo com a velocidade esperada. Enquanto estivermos acima da média.

Da mesma maneira, no lado positivo, caso o andamento seja melhor do que o esperado, o cliente pode rapidamente se preparar para dar novas informações sobre o que será feito durante o tempo livre nessa iteração.

Em uma iteração comum, o início da aprovação demora um pouco pois as histórias tem que ser terminadas e a partir de então os pontos são entregues.

Por fim, o gráfico pode indicar diversos impedimentos e basta bater o olho para perceber algum tipo de problema. O que há de estranho na iteração a seguir?

Nesse exemplo, as histórias finalizadas demoram para ser aprovadas: repare a barra horizontal onde as histórias podem estar terminadas aguardando aprovação.

A barra horizontal indica um momento de pausa na entrega, que estava indo bem até então: diversos fatores podem causar essa pausa. No caso dessa equipe e iteração, podemos verificar em um outro gráfico que as histórias eram entregues mas o tempo para aprovação era longo.

O perigo dessa pausa é chegar muito próximo ao fim da iteração e a entrega ser sempre parcial, nunca completa pois após a avaliação ser feita não há mais tempo na iteração para fazer as correções devidas.

Outro motivo comum para uma linha parada é a história não ser aprovada por falta de compreensão no momento da execução. Em uma equipe que segue Scrum, o Scrum Master é responsável por acompanhar e detectar tais impedimentos, além de ajudar a equipe a resolvê-los.

Equipes maduras que gerenciam seu próprio trabalho e lidam com seus próprios problemas são responsáveis por fazer tal acompanhamento, identificar e solucionar os problemas e seus impedimentos através de praticas ágeis que visam entregas de qualidade.

Ter esses gráficos em mãos no momento necessário e ser capaz de entender o que eles dizem é fundamental para um time tirar seus impedimentos da frente: seja através de seu scrum master ou de suas próprias mãos.

9 Comentários

  1. tarsis figueredo azevedo 21/10/2010 at 13:28 #

    Muito bom o post!

    Feedback rapido e constante é um dos pilares do agilismo. E o burndown é uma forma clara e rapida de tanto a equipe quanto o cliente saberem o estado atual do desenvolvimento.

    Abraços,

    ps: Tem algum sistema pra gerar esses graficos online?
    fazer na mao é chato d+! :P

    Eu uso o pivotal pra gerenciar algums projetos pessoais. Só que pelo que vi ele nao gera o burndown certo?

  2. Guilherme Silveira 22/10/2010 at 08:23 #

    Tudo bem Tarsis?

    Esses gráficos são do proprio pivotal. Vai em VIew, Graphs e escolhe Burndown.

    Abraço!

  3. Marcio 22/10/2010 at 09:02 #

    O que acontece se profissionais que não tem determindas especialidades são direcionados a responderem com tecnologias que nunca atuaram, algo como usar de metodologia XP para parear com um profissional Java e outro que só teve contato como Visual Basic, e pior ainda se não se tem uma colaboração para a transferência de informação.

    É incrivel como podemos enxugar papéis de processos usando Scrum algo como tornar todos homogeneos no entendimento ao Dominio mas na hora da implementação essas responsabilidades sofrem muito por profissionais que não querem negociar suas experiências e fazem atrasar o projeto, querem adotar um protencionismo pela tecnologia e desenvolverem uma anti-gerência, Gráfico de Burndown não tem como dar previsões a uma situação tão cotidiana e presente, como resolver isso, estamos progredindo !!!

  4. Marcio Duran 22/10/2010 at 18:29 #

    Por Guilherme Silveira,
    ” identificar e solucionar os problemas e seus impedimentos através de praticas ágeis que visam entregas de qualidade.”, (- De que forma ?).

    Gostaria de colocar uma abordagem de pratica Agil que considero, onde Mike Sutton faz uma “you could extend the burndown chart as a diary of the sprint, capturing not only the tasks burndown, but impediments and key events that will enable you to better retrospect.”

    Fonte: http://www.infoq.com/news/2008/12/retrospective-tips

  5. Guilherme Silveira 23/10/2010 at 09:07 #

    Perfeito, é a frase do Mike que resume o que o post tenta mostrar.

    Abraço Márcio

  6. Guilherme 27/10/2010 at 13:03 #

    “o caso dessa equipe e iteração, podemos verificar em um outro gráfico que as histórias eram entregues mas o tempo para aprovação era longo.”
    O que acontece neste caso quando o “culpado” pela demora na aprovação é o product owner ? Como argumentar e provar que foi ele quem demorou para aprovar as histórias e por isso “não há mais tempo na iteração para fazer as correções devidas.” ???

  7. Guilherme Silveira 28/10/2010 at 12:06 #

    Oi Guilherme,

    Se está ocorrendo o problema do PO/clientes (depende da metodologia) aprovar, a equipe supostamente correria atrás de conversar com eles para resolver isso. Limitando o trabalho em andamento (o wip: work in progress) como no kanban, fica muito fácil visualizar que as tarefas estão aguardando aprovação.

    Abraço!

  8. Cecilia Fernandes 28/10/2010 at 13:26 #

    Gosto de ver esse assunto como “o cliente precisa de visibilidade”, mesmo. Mas acho que precisa ficar clara a diferença entre o cliente e o P.O.. Independente de metodologia, concordo que o cliente deveria saber o andamento do projeto, mas o Scrum leva isso de uma forma um pouco diferente.

    É importante notar que nele, o gráfico de burndown serve para alarmar o time de “desvios” na estimativa e aí os próprios desenvolvedores devem avisar/renegociar o Sprint Backlog com o P.O. Um Scrum Master deveria ser desnecessário nessa tarefa porque ela é parte do autogerenciamento (atualizar as métricas e, claro, tirar informações dela).

    Como é uma métrica dos desenvolvedores, o cliente ficar sabendo dela pode alarmá-lo sem necessidade. O P.O. pode, no entanto, fazer alguma métrica pro cliente não perder visibilidade ou acompanhar com ele a leitura do Sprint Burndown pra evitar alguma ansiedade descabida. Acho até legal que ele faça isso. De qualquer forma, esse deveria, no Scrum, ser uma métrica pros pigs, não pros chickens.

    PS. de terminologia: uso “desenvolvedores” quando falando do “Team” do Scrum Guide e “time” para “Scrum Team” na mesma referência.

  9. Guilherme Moraes 01/11/2010 at 17:25 #

    Cecilia, pigs = comprometidos; chickens = envolvidos ??? :)

Deixe uma resposta