Abraço,
p-msg p#attach-count span { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight: normal; } #ygrp-msg p a { font-family: Verdana; font-size: 10px; } #ygrp-mlmsg a { color: #1E66AE; } div.attach-table div div a { text-decoration: none; } div.attach-table { width: 400px; } -->Ok Rodrigo, se "fere" o Scrum então acho que a Scrum Alliance deveria entrar em um acordo sobre isso no conteúdoque é 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@gmail.com >
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@gmail.com >: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