Olas,
Na minha opinião (IMHO, como diria o meu xará), o que fere o Scrum é perder muito tempo discutindo este tipo de assunto.
Deixa eu me explicar...
Carlos, o mais interessante do Scrum é o fato do processo ser de iterações curtas com melhoria contínua.
Em geral, a retrospectiva é o grande passo para a melhoria contínua. Ao fim de cada sprint o time decide por "unanimidade" alterar algo no processo e experimentar por UMA sprint.
Ao final da próxima sprint o time avalia se o experimento foi bom.
Ou seja, qualquer alteração do processo anterior pode ser testada e no máximo irá prejudicar o projeto por 2 semanas (ou quantas vc estiver usando <=4).
Então: TENTE e depois coletivamente avalie o que foi tentado.
"Mas a decisão não deve ser unânime?" Sim, mas o grande argumento para todos toparem é esse: "vamos tentar, qualquer coisa na próxima sprint a gente volta atrás!".
Usando esse argumento você transforma maioria (ou mesmo minoria) em unanimidade, considerando que são pessoas de bom senso, senão é um outro problema.
Poderia ficar argumentando porque sou contra medir horas de trabalho, mas nada vai valer mais do que você mesmo experimentar em seu próprio contexto e chegar a uma conclusão.
(Bom, é claro que vale a pena perguntar a opinião de pessoas mais experientes e ler um pouco como outros resolveram o mesmo problema).
Não se esqueça de avaliar o seu processo como um todo, desde o seu modelo de contrato até a medição de horas gastas medindo horas.
[]s,
Rodrigo de Toledo
2009/7/14 Eric Cavalcanti <ecavalcanti@...>
Ok Rodrigo, se "fere" o Scrum então acho que a Scrum Alliance deveria entrar em um acordo sobre isso no conteúdo que é dado como Certified Scrum Master, porque passar princípios que ferem o Scrum em um Curso Certificado ao meu ver é algo bastante grave.Não quero entrar aqui na discussão de o que é melhor. Já trabalhei com as duas formas, e em alguns casos, assim como o do Carlos, mas sendo por outros motivos, tivemos que usar a abordagem em horas, e colhemos bons resultados.
Abs,Eric CavalcantiCSM2009/7/14 Rodrigo Yoshima <rodrigoy@...>
Micro-management fere o Scrum, você não vai achar citação sobre isso,
é bem IMHO, mas mecanismos de gerenciamento podem oferecer problemas
para sua implementação. O fato das ferramentas permitirem apontar
horas e permitir estimativas em horas de tarefas não isso
automaticamente ser uma boa idéia.
Eu não aplica estimativas em horas de tarefas por duas razões:
A. Ao dar prazos particulares automaticamente você está sofrendo de
sindrome do estudante
B. Existe coisas mais importantes para fazer no planning do que ficar
estimando horas nas tarefas, que é uma das coisas mais enfadonhas e
inúteis que eu fiz na vida
Como o Shoes falou no blog dele, dá para gerenciar comando-controle
com qualquer metodologia...
2009/7/13 Eric Cavalcanti <ecavalcanti@...>:Rodrigo Yoshima
>
>
> Carlos,
>
> Estimar tarefas em horas não é errado.
> Uma confusão muito comum é que algumas pessoas ao fazer um curso de Scrum,
> onde o instrutor, por motivos de preferência, defende o uso de tarefas em
> dias e não em horas, entendem que isso é uma premissa do Scrum.
> Definitivamente não é. Descobri isso pois conversei com algumas pessoas que
> realizaram o curso com Mike Cohn e Ken Schwaber, no qual defendem o uso de
> estimativas de tarefas em horas, depois de ler os livros deles confirmei
> esse fato. Isso explica o motivo da maioria das ferramentas para Scrum
> estimarem tarefas em horas.
> Um outro fato é que a informação de quanto foi gasto também não é proibida
> pela Scrum, ela só deve ser evitada. Mas entendo que existem cenários que
> esta informação é relevante e deve sim ser considerada. E isso também é
> considerado em algumas ferramentas como por exemplo ScrumWorks Pro e
> TargetProcess. E ao atualizar uma tarefa diariamente além de informar o
> quanto falta, dizer o quanto gastou no dia não gera um "overhead"
> considerável.
> Tendo o cuidado em não transforma o Scrum em um ScrumBUT, o que não vejo
> isso no seu caso, o Scrum pode ser adaptado a sua realidade.
> Abs,
> Eric Cavalcanti
> CSM
>
www.ASPERCOM.com.br