Que maravilha!!! Muita coisa boa sendo dita desde a hora que sai do escritório.
Resolvi fazer um apanhado do que foi dito e expor o que estou concluindo, então lá vai.
"o curso com Mike Cohn e Ken Schwaber, no qual defendem o uso de estimativas de tarefas em horas... 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" (Eric Cavalcanti)
Eric. Não estou certo se o que eles defendem é o acompanhamento como estou propondo. Preciso realmente ler o livro do Schwaber para tirar mais conclusões, mas até onde tenho visto internamente, o acompanhamento de horas é apenas o de "quanto estimamos que falta para concluir o Sprint, diante do cenário de riscos que estamos inseridos agora". Bem... sua dica já vai me abrir os olhos quando ler o livro dele.
"Micro-management fere o Scrum" (Rodrigo Yoshima)
Concordo que micro gerenciamento não ande ao lado dos princípios do Scrum, mas avaliar horas planejadas e horas executadas não seria tão micro quanto avaliar pontos planejados e pontos executados, como alguns sujerem para avaliar a variação na velocidade de sua equipe? Quero deixar claro que já não estou mais defendendo o acompanhamento x ou y, mas fazendo uma avaliação crítica do que o mercado está usando e defendendo.
"então acho que a Scrum Alliance deveria entrar em um acordo sobre isso no conteúdo que é dado" (Eric Cavalcanti)
Eric... Essa sua afirmação reforça o que eu disse sobre pouco se discutir a cerca de questões práticas. Tenho visto muita gente defender isso ou aquilo, mas quando se expoe uma dificuldade real, acabam por se apoiar em princípios sem mostrar a aplicação dos mesmos. Princípios são bons e devem ser seguidos, mas eu preciso de ajuda para saber como aplicá-los, entende?
"Quando eu digo que uma tarefa X foi estimada em 3 horas mas levou 5 horas pra ser realizada, qual o valor dessa informação?
Erramos a estimativa? Atrasamos em 2 horas? Tendo essa informação, da próxima vez que eu estimar uma tarefa eu vou acertar mais por conta disso?...errando pra cima as estimativas, o que poderia ser feito?...estimativa precisa, é aquela dada no final do projeto" (Sigmar Siqueira)
Sigmar... O valor dessa informação não seria a resposta de perguntas do tipo "Minha equipe precisa de treinamento técnico?" ou "Meu preço reflete minhas capacidade de produção?".
Concordo que estimativa precisa é aquela dada no final do projeto, então talvez o problema não seja a forma de contrato que estamos praticando? Contratos do tipo Custo Remunerado, pelo PMI (agora cutuquei a onça), são os mais adequados para cenários com pouca definição de escopo. O risco passa para o comprador, mas isso é outro papo. Na verdade vou criar outro tópico para discutir custos e não embolar o assunto.
"o que fere o Scrum é perder muito tempo discutindo este tipo de assunto...Ao final da próxima sprint o time avalia se o experimento foi bom" (Rodrigo de Toledo)
Rodrigo... Eu entendi o que você quis dizer, mas como eu disse antes, há tantas dúvidas do mercado que envolvem custos, precificação, etc, que discutir esses assuntos é muito importante para que o mercado passe a entender esses novos paradigmas.
Vou agora mesmo criar um tópico sobre custos e precificação, pois minhas dúvidas iniciais já foram resolvidas. Isso não impede de continuarmos a discutir, mas já me dou por satisfeito e agradeço muitissimo a todos que contribuiram.
Carlos.
2009/7/14 Rodrigo de Toledo <rodrigodetoledo@...>
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 Toledo2009/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
Offline 
Enviar e-mail