Having problems with message search?
1) Velocidade não é boa nem ruim. Cada equipe estima de um jeito e a velocidade é uma forma dela entender o quanto consegue entregar em cada iteração. É uma cadência de trabalho.
2) Bugs são indesejados e XP tenta fazer o máximo para evitá-los. No entanto, eles sempre aparecem. Torná-los visíveis e permitir que o cliente priorize o que quer pronto na próxima iteração é uma forma transparente e responsável de trabalhar. Como muitos disseram, alguns bugs são críticos e devem ser corrigidos rapidamente (provavelmente impactarão no valor percebido do software entregue). Outros não são tão prioritários e podem esperar um pouco para ser resolvido. Quem deve fazer esse julgamento? Se a equipe consegue corrigir todos os bugs assim que eles aparecem, perfeito! Mas nem sempre esse é o caso.
3) Juntando as duas coisas: corrigir bug pode ser algo trivial ou algo que exige esforço. Se exige esforço, é trabalho realizado e, portanto, influencia na velocidade (independente de entregar valor ou não, essa é outra discussão). Dessa forma, acredito que o melhor é tratar bugs como histórias que são estimadas normalmente pela equipe e priorizadas pelo cliente. Dessa forma, se a equipe gastar 3 pontos (ou 10 triângulos, ou 2 horas-ideais, ou o que for) corrigindo bug difícil ou 3 pontos entregando funcionalidades novas, a velocidade não muda e eles continuam conhecendo sua cadência de trabalho. Melhorar a cadência de trabalho (velocidade) pode ou não melhorar a qualidade percebida do software. São duas coisas separadas, como o Alessandro falou.
4) Métricas são delicadas quando utilizadas para avaliar o desempenho de uma equipe. Minha dissertação de mestrado é exatamente sobre esse tema e, se alguém se interessar, podemos abrir outra discussão sobre o assunto. Para resumir: precisamos saber diferenciar métricas de avaliação (ou organizacionais), de métricas de acompanhamento (ou de diagnóstico). Velocidade é uma métrica de acompanhamento e, como tal, não deve ser utilizada como medida de produtividade (vejam: http://www.jamesshore.com/Agile-Book/reporting.html)
Abs,
--
Danilo Sato
MSc. student in Computer Science - University of São Paulo - Brazil
www.dtsato.com
On 6/15/07, Charles Abreu <charlesabreu@...> wrote:
Você pode precisar saber quantos bugs corrigiu ou quanto tempo gastou corrigindo bugs para melhorar o seu trabalho e qualidade do seu produto. Mas para o cliente, talvez só interesse, em termos de métrica, saber o quanto de funcionalidade você produz em um determinado tempo. Essa é a pergunta que você precisa responder. E quando o cliente pensa em funcionalidades, ele pensa em funcionalidades sem defeitos, certo?
No exemplo do muro, na primeira semana o pedreiro construiu 100 m2 e na segunda semana construiu 150 m2. Em duas semanas ele construiu 250 m2 de muro (somando muro torto com muro bom), mas você olha e só vê 150 m2 de muro construídos. São esses 150 que importam para você. Então a métrica é: o pedreiro consegue fazer 75 m2 de muro bom por semana (150 m2 de muro bom / 2 semanas).
Se levasse em consideração os 100 m2 de muro mal feitos que ele derrubou e fez de novo na segunda semana como parte da métrica de velocidade, você teria 250 / 2 = 125 m2 de muro por semana.
Assim, pelas duas métricas que você tem até o momento, você estima que ele faria quantos metros de muro bom (você não quer muro torto, quer?) na próxima semana?
Qual métrica informa melhor?
Quando se trata de métricas, acho que tudo parte das perguntas que você quer responder.
[]'s
Charles Abreu
On 6/15/07, Alessandro Camara <alessandrocamara@...> wrote:Charles e Tales,
aqui vai entao uma duvida. A velocidade não é para medir a produtividade e poder estimar melhor a próxima iteracao?
Medir a qualidade nao seria outra coisa? talvez pela qtde de bugs encontrados, medindo-se inclusive quando tempo se gastou para corrigir esses bugs, etc.
Alessandro
To: xprio@yahoogroups.com
From: charlesabreu@ gmail.com
Date: Fri, 15 Jun 2007 14:42:48 -0300
Subject: Re: [xprio] Bugs vs. Funcionalidades (foi: Cartoes Vs Software)
Alessandro,
Peço licença para tentar contribuir...
Em seu exemplo, a equipe gastou 80% do tempo removendo defeitos. Talvez isso seja uma evidência de que a qualidade do que está sendo produzido não está muito boa e é preciso tomar alguma providência.
Em projetos tradicionais é comum "cantar vitória" quando o prazo acaba, mesmo que o produto esteja em um estado inutilizável, instável, inviável de se manter, com uma qualidade muito ruim. Isso ocorre em parte porque a organização do trabalho não dá mecanismos nem incentivos para que as pessoas identifiquem e trabalhem nos problemas que vão surgindo ao longo do projeto. E em parte - e muito mais grave, na minha opinião - porque não incentiva as pessoas a, antes de tudo, evitar que os problemas sequer surjam. Acho que é uma falha muito grande de abordagem, você não acha?
Metodologias ágeis, por outro lado, organizam o trabalho de forma que os problemas sejam evidenciados tão logo apareçam. E mais importante que isso, criam incentivos para que as pessoas evitem que os problemas sequer apareçam. Assim todos -cliente e equipe de desenvolvimento - têm uma visão mais realista de como realmente está indo o projeto e podem tomar decisões mais informadas o tempo todo.
Contar esses 80% do tempo com correção de defeitos como aumento de velocidade não poderia transmitir uma mensagem errônea para os clientes de que o projeto está indo muito bem e o dinheiro está sendo bem gasto? E criar um incentivo para equipe de que os bugs não são desperdício de tempo e dinheiro quando, na verdade, a situação é justamente o oposto disso?
[]'s
Charles AbreuOn 6/15/07, Alessandro Camara < alessandrocamara@... > wrote:Ola Talles.
Já conhecia sim o conceito de velocidade.
Mas o conceito de velocidade nao é para medir a produtividade da equipe? Baseda na qtde de pontos a mesma conseguiu realizar na iteracao? Isso independe do tipo de historia, se foi uma funcionalidade ou correcao de bug.
Nesse seu exemplo, ou em outro um pouco menos desastroso. Vamos imaginar que a equipe passar 80 % do tempo apenas corrigindo bug. Se nao considerar isso no calculo da velocidade, na iteracao seguinte a velocidade para se basear vai ser extremamente baixa. Ou seja, eles irao apenas estimar fazer 20 % do que realmente tem condicao de fazer?
Aqui na empresa estou tentando fazer da seguinte forma. Coloco os bugs como estorias e estimo o priorizo elas juntamente com as funcionalidades. Porém defini um percentual máximo dos pontos que podem ser gastos com correcoes de bugs. Claro, salvo um caso de alguns bugs que tem urgencia pela criticidade. Isso é para evitar a não evolução do produto.
Abracos
Alessandro
To: xprio@yahoogroups.com
From: tales@grupofortes . com.br
Date: Fri, 15 Jun 2007 12:19:57 -0300
Subject: Re: [xprio] Bugs vs. Funcionalidades (foi: Cartoes Vs Software)
Alessandro,Para entender o que os colegas estão dizendo, é preciso compreender o conceito de "velocidade". Você conhece esse conceito? Vou expor uma situação absurda para tentar melhorar o entendimento. Imagine que uma semana da equipe foi tomada exclusivamente para a correção de "bugs". Nesse caso, sua velocidade naquela semana - e que seria a velocidade presumida para a semana seguinte - seria igual a zero. Se os "bugs" são tratados como histórias, eles são estimados e conseqüentemente comporão a velocidade da equipe. Ou seja, numa semana desastrosa como essa, o indicador de velocidade não seria afetado. Teríamos um indicador dizendo que estava tudo normal, sem estar.Deu para entender?Um abraço.Tales----- Original Message -----From: Ricardo MitranoSent: Friday, June 15, 2007 10:07 AMSubject: Re: [xprio] Bugs vs. Funcionalidades (foi: Cartoes Vs Software)Olá pessoal,
Tenho pouca experiência com o XP, mas vou me arriscar a opinar. Lá vai....
Vejo que os Bugs não devem ser tratados como estórias pois, como o Carlos Miranda disse, são correções de estórias anteriores e impactam na Velocity da equipe. A correção de bugs "mina" o tempo disponível da equipe para desenvolver novas funcionalidades. Se não fizermos assim, na iteração seguinte teremos uma velocity irreal que nos diz que podemos selecionar mais estórias que provavelmente poderemos desenvolver.
Na iteração temos o desenvolvimento das estórias e as atividades extras: produzir um documento, reuniões, instalar um servidor etc. Vejo que a correção de bugs deve ser tratada como uma dessas atividades que também tem seu tempo estimado e controlado a sua maneira. Ou não, as vezes são atividades que a precisão da estimativa é tão ruim (devido a característica obscura da atividade) que praticamente não sabemos quanto tempo vai levar aquela atividade. Alguns bugs tem essa característica, fazemos um trabalho de detetive de investigação pra descobrir que "raio" de erro é aquele :-)
Mas a questão principal é mesmo manter o controle da Velocity da equipe atualizada e real. Usar ou não cartões para os bugs fica a critério da equipe. O tempo gasto na correção do bug é que não deveria ser tratado como tempo de desenvolvimento de estórias.
Um abraço
Ricardo Mitrano
Em 15/06/07, Alessandro Camara <alessandrocamara@... > escreveu:O problema de nao tratar os bugs como cartoes e fazer estimativa dos mesmo, na minha opiniao, é complicado pelo fato da equipe ter que trabalhar de duas formas diferente na mesma iteracao. Quando for bug se orientar apenas por uma ferramenta e quando for funcionalidade olhar apenas pelos cartoes.
Aqui tambem estimamos e priorizamos os bugs, pois existem alguns bugs que nao tem impacto no sistema e o cliente prefere que saia determinada funcionalidade muito importante pra ele do que a correcao daquele bug.
Claro, a intencao é trabalharmos para minimizar ao maximo os bugs, e tenho certeza que se utilizando algumas praticas do XP isso ocorra. Mas para gerenciar projetos de produtos, desenvolvidos ha anos, sem utilizacao de uma metodologia bem definida, gerenciar bugs é uma necessidade.
Abracos
Alessandro
To: xprio@yahoogroups.com
From: cevmiranda@yahoo. com.br
Date: Thu, 14 Jun 2007 20:36:24 -0300
Subject: [xprio] Bugs vs. Funcionalidades (foi: Cartoes Vs Software)
Olá, Alessandro.> To: xprio@yahoogroups.com
On 6/13/07, Alessandro Camara < alessandrocamara@...> wrote:
>
> Na verdade nao sao lancadas novamente. Nessa ferramente já contem todas as solicitacoes de clientes e/ou bugs reportados pelos mesmos. Porém, além disso, nas versoes implementamos funcionalidades que nao foram solicitadas nem sao correcoes de bugs. Essas apenas que sao lancadas para entrar no fluxo de trabalho.
Penso que devemos tratar de forma diferenciada os bugs das
solicitações/novas funcionalidades. Ao contrário das novas
funcionalidades, bugs contribuem negativamente para a velocity. Os
bugs selecionados para a iteração devem sempre ter prioridade sobre as
funcionalidades. Bugs não precisam ser representados por cartões, pois
na verdade eles são a "continuação" de algum cartão desenvolvido em
iteração anterior. Minha realidade é diferente da sua pois não
mantenho produtos, mas costumo nem mesmo estimar as correções de bug.
Procuro apenas reportar o tempo gasto com as correções como um
registro do impacto sobre a velocity.
Seriam interessantes comentários do grupo de como tratar bugs em
relação a estimativas, priorização e velocity.
Um abraço,
Carlos Miranda.
> Abracos
>
> Alessandro
>
>
> ________________________________
To: xprio@yahoogroups.com
> From: tales@...
> Date: Wed, 13 Jun 2007 10:52:44 -0300
> Subject: Re: [xprio] Cartoes Vs Software
>
>
>
>
>
> ----- Original Message -----
> From: Alessandro Camara
> Sent: Tuesday, June 12, 2007 9:59 AM
> Subject: [xprio] Cartoes Vs Software
>
> > Depois de detalhadas todas as historias no planejamento da iteracao, elas
> > (alem do cartao) sao lancadas nessa ferramenta
>
> Se as histórias já são coletadas nessa ferramenta, por que são nela lançadas
> novamente?
>
> > juntamente com os casos de teste
>
> Você lança os casos de teste na ferramenta? Não entendi.
>
> A despeito dessas dúvidas, vamos às minhas considerações baseadas no que
> inferi.
>
> A principal vantagem dos cartões é a facilidade de manipulação. A dinâmica
> de priorização, por exemplo, não pode ser comparada entre cartões e um
> "software". Quanto à vantagem do "release notes", ele realmente existe. Mas
> também existe uma questão que você poderia pensar a respeito: eu gosto de
> deixar para elaborar o "release notes" somente no fim do ciclo. Dois
> motivos: primeiro - eu não preciso me preocupar em elaborar um texto numa
> linguagem adequada para o cliente no início do ciclo; segundo - durante o
> ciclo, algumas coisas podem mudar, novas idéias podem ser incorporadas de
> tal forma que o "release notes", se escrito no início do ciclo, precisaria
> ser atualizado.
>
> Um abraço.
>
> Tales
>
>
>
> ________________________________
Encontre o que procura com mais eficiência! Instale já a Barra de
Ferramentas com Windows Desktop Search GRÁTIS! Experimente já!
>
>
Receba as últimas notícias do Brasil e do mundo direto no seu Messenger com Alertas MSN! É GRÁTIS! Assine já!
--
Ricardo Mitrano
Encontre o que procura com mais eficiência! Instale já a Barra de Ferramentas com Windows Desktop Search GRÁTIS! Experimente já!
Conheça o Windows Live Spaces, a rede de relacionamentos conectada ao Messenger! Crie já o seu!
Offline 
Send Email