código Ágil

Agile, Scrum, Extreme Programming , Java e mais

Archive for março \24\UTC 2009

Sprint backlog tips na Scrum Alliance

Posted by Luciano Félix em 24 março, 2009

sa2

Hoje tive a satisfação de ter um artigo publicado no site da Scrum Alliance, esse artigo foi resultado de uma revisão de um post antigo já publicado aqui no blog. Espero que seja útil a todos

Anúncios

Posted in Uncategorized | Etiquetado: , , | 1 Comment »

Estimar ou Não Estimar

Posted by Luciano Félix em 12 março, 2009

Esse é um assunto um tanto quanto polêmico dentro da comunidade, temos defensores das 2 abordagens, nos livros do Ken Schawber e Mike Cohn, vemos a recomendação de estimar as tarefas em horas, mas já a algum tempo a idéia de abrir mão das estimativas das tarefas vem crescendo e ganhando adeptos e eu particularmente sou um deles. O que acontece normalmente é que o planejamento da sprint pode tornar-se longo e cansativo quando a equipe tem de estimar cada uma das tarefas que ela acredita serem necessárias para desenvolver os itens debacklog , o que se vê normalmente são discussões intermináveis se uma tarefa vai levar 4 ou 6 horas sendo que essa informação não será de fato importante na hora de se entregar um item pronto.

Na minha opinião é totalmente possível se atingir todos os objetivos de uma sprint, tanto no que diz respeito ao incremento de software produzido quanto no que diz respeito ao processo, além de simplificar o planejamento sem prejudicar em nada seu resultado. Em seu artigo publicado pela Scrum Alliance o Alan Atlas fala muito bem sobre esse assunto.

De acordo com Alan os dois principais motivos da maioria das equipes utilizarem estimativas para tarefas:

  1. Criar um compromisso que seja exequível pela equipe em termos de incremento de software
  2. Criar um gráfico de burndown para monitorar o progresso da equipe.

Bem, esses 2 objetivos podem ser atingidos sem a necessidade de estimar as tarefas.

O compromisso da equipe pode se basear apenas na quantidade de story points que a equipe acredita ser possível entregar dentro do tempo da sprint e ao passo que a velocidade da equipe vai estabilizando as estimativas de tarefas ficam ainda mais dispensáveis.

Já o burndown chart pode passar a ser baseado apenas na quantidade de tarefas, o que exigirá da equipe uma diminuição do tamanho de suas tarefas, identificando-as mais claramente, assim o gráfico será atualizado somente quando uma tarefa for concluída completamente. Além desse gráfico também é interessante usar umburndown baseado em story points. Enquanto o burndown baseado em quantidade dá um idéia de progresso técnico, o baseado em story point da uma idéia de progresso mais voltado ao negócio.

Acredito que as estimativas de tarefas podem levar a um microgerenciamento desnecessário e custoso para a equipe e podemos de fato abandoná-las sem prejuízo ao projeto tornando o planejamento e o acompanhamento mais simples.

Posted in Uncategorized | Etiquetado: | 1 Comment »