Estimativa

Por Mitch Lacey.Proprietário, Mitch Lacey & associados, Inc, uma empresa de consultoria especializada em adoções e aprimoramentos de agile e scrum.

Janeiro de 2012

Mitch Lacey discute a dificuldade em torno da estimativa do projeto do software, e fornece dicas e truques para usar duas técnicas de estimativa de software Agile ao estimar projetos.

Aplica-se a

Gerenciamento do ciclo de vida do aplicativo; Team Foundation Server

Sumário

• Introdução

• Porque a avaliação é difícil

• Técnicas de estimativa

• Pontos de história como unidade de medição

• Planning Poker

• Avaliação de parede

• Estimativa

• Priorização

• Conclusão

O trabalho de estimativa criativo e imprevisível é apenas difícil.Escolha uma maneira de fazê-lo pode ser igualmente fiscalizado.Fred Brooks dize melhor: “É muito difícil fazer uma defesa de risco do trabalho vigorosa e plausível de uma estimativa derivada por qualquer método não quantitativo, suportada por poucos dados e certificada especialmente por palpites dos gerentes”.

Ainda assim, somos solicitados a dar avaliações para nossos projetos de software de forma honesta e adiantada–– e independentemente de todos os nossos esforços para lembrar à administração de que essas avaliações são rudes, com muita frequência vezes nossas avaliações iniciais se transformam em comprometimentos.

Neste artigo, eu mostrarei a você porque é um desafio estimar projetos iniciais, como ajuda de técnicas de estimativa de software Agile, e como estimar sua lista de pendência do produto usando planejamento de pôquer e pontos de artigo.

Porque a avaliação é difícil

Na maioria dos projetos, somos solicitados a estimar na frente.Para entender porque isto é um problema, nós devemos examinar o Cone de Incerteza, o qual foi introduzido por Barry Boehm em 1981 e Steve McConnell o reintroduziu em 1997 no livro Guia de Sobrevivência de Projeto de Software.

O cone demonstra que temos a maioria de incerteza no início de qualquer projeto (uma variação de 4x a 0,25x no intervalo).Essa variação significa que o que nós estimamos para ser um projeto de um ano pode, na verdade, terminar levando de 3 a 48 meses.O início de qualquer projeto é a hora em que estamos menos certos sobre o projeto, mas também é quando somos solicitados a fornecer estimativas muito precisas.

Em Agile, tentamos passar da incerteza para a certeza em um ciclo o mais curto possível.Isso é feito maximizando os primeiros ensinamentos sobre o sistema e como ele deve ser criado.Para fazer isso, nós criaremos um único caminho com o sistema, um artigo completo e funcional.Usamos isto para eliminar as conjecturas sobre requisitos e design no início, o que nos permite chegar à certeza muito mais rapidamente e com muito mais confiança.

Técnicas de estimativa

Há uma ampla variedade de técnicas de avaliação válidas, incluindo a contagem, o julgamento de especialistas (individuais e de grupo), a decomposição, a analogia, a avaliação de proxy, o planning poker e a avaliação de mural.Também podemos usar ferramentas como o Cocomo II.Todas essas técnicas exigem que nós escolhemos uma unidade de avaliação - hora, dias, semanas, meses, dias ideais, dimensionamento de camiseta ou pontos - ou todas elas.Se nós não compreendemos a unidade, a estimativa não significa nada.Considerando tudo isso, não é de se duvidar porque nós nos esforçamos com a avaliação.

Embora as equipes ágeis gravitem em direção a um determinado sabor de unidades de estimativa e técnicas para estimar a reserva do produto (pontos de histórico e pôquer de planejamento), sua equipe deve se sentir livre para usar o método que funciona melhor para suas necessidades.Na minha experiência, expressar estimativas em termos de pontos do artigo, usando o planejamento de pôquer ou estimativa de parede, produz os melhores resultados.Nos parágrafos seguintes, você aprenderá sobre pontos do artigo como uma unidade de medida e duas técnicas de estimativa que eu prefiro: planejamento de pôquer e estimativa de parede.

Pontos de história como unidade de medição

Mike Cohn resume os pontos dos melhores artigos: "Os pontos do artigo são uma unidade de medida para expressar o tamanho total de um artigo do usuário, recurso ou outra parte do trabalho." Os pontos da história nos dizem o tamanho da história, em relação a outras, em termos de tamanho ou complexidade.Mike geralmente refere-se a "perseguir pontos" quando as equipes ajudam a compreender o conceito de dimensionamento relativo.Um cachorro de 2 pontos (pequeno) seria um Chihuahua.Um cachorro de 13 pontos (grande) seria um Cachorro Dinamarquês.Com esses dois guias em mente, é relativamente fácil dimensionar as outras raças de cachorro relacionadas a um chiuaua ou a um dinamarquês.Um Beagle, que é aproximadamente duas vezes maior que um Chihuahua, pode ser um 5.Um Labrador, que é maior do que um Beagle, mas menor do que Cachorro Dinamarquês, pode ser um 8.

Quando você estiver inicialmente aprendendo a usar pontos de artigo, sua equipe precisará estabelecer seus próprios pontos fixos de comparação.Para fazer isso, escolha um artigo de sua reserva de produto que pode concordar que é pequeno (em termos de tamanho ou de complexidade) e que todos vocês concordam que é enorme.Eu gosto de ter meu pequeno artigo como um artigo de dois pontos, porque se eu precisar diminuir o tamanho (dizer que eu descobri um Chihuahua Toy), eu posso.Se eu limitar meu pequeno artigo conhecido para um artigo de um ponto e eu preciso de ir para um menor, estou com problemas.As outras histórias podem ser dimensionadas de acordo com estas.

Quando se trata da escolha de números para representar esses tamanhos, eu localizo a sequência de Fibonacci para funcionar melhor.Fibonacci é a soma de dois números anteriores.Portanto 1 e 2, o seguinte é 3.3 e 2, o seguinte é 5.5 e 3, o seguinte é 8 e assim por diante.Eu prefiro Fibonacci sobre, por exemplo, tamanho de camiseta ou crescimento exponencial (4/8/16/32/64/128/256, etc.) porque nós, seres humanos, somos bons na base dez.Quando saímos desse intervalo, mesmo que estejamos nele com, por exemplo, xs, s, m, l, xl–– isso se torna confuso.Os números de Fibonacci são simples, fácil de compreender e fornecem precisão suficiente para nos levar ao objetivo - fornecendo estimativas relativas.Você pode escolher um conjunto diferente de números, mas lembre-se que o importante é ser consistente.

Os pontos de história são valores relativos, não fixos.Não há nenhuma correlação direta entre horas e pontos.Por exemplo, nós não podemos dizer com qualquer grau de certeza que uma história de dois pontos é igual a 12,2 horas porque as histórias no intervalo de dois pontos irá variar muito em quanto tempo realmente leva para concluir.De forma semelhante, você não pode comparar os pontos de história de uma equipe com a de outra pessoa com qualquer grau de certeza.Os pontos de história são criados e específicos para equipe que os estimou, provavelmente incluirá um grau de complexidade compreendido somente pela equipe e não são absolutos.

Planning Poker

Depois de escolher sua unidade de medida e estabelecer sua escala, é hora de estimar.A maioria das equipes do Agile usam o método de planning poker para estimar o tamanho relativo das histórias.É popular com equipes Agile, porque é uma medida objetiva que inclui várias técnicas de estimativa subjetivas, incluindo a analogia e o julgamento do especialista.A chave do planning poker é a participação.Todos na equipe precisam o participar - sim, todos.Os testadores funcionais estimarão as tarefas de desenvolvimento e vice-versa.Gerentes de projeto funcionais também podem estimar tarefas de desenvolvimento.Fazer isso garante que seus números objetivos incluam o máximo da estimativa subjetiva possível.

Inicie com um conjunto de cartas de pôquer de planejamento.As cartas de planning poker podem ser facilmente feitas com fichas, criadas com cartas de baralho ou compradas (o Visual Studio as faz).Cada cartão possui um dos números no seu intervalo escolhido de pontos da história (1, 2, 5, 8, 13, etc.).Cada participante é negociado com uma “mão” que contém o intervalo completo de pontos de história disponíveis.

Depois que as placas são distribuídas, o jogo começa.

1. O mestre do scrum apresenta o item superior na lista de pendências do produto à equipe.

2. A equipe discute sobre o que é a história.

3. O proprietário do produto esclarece perguntas, suposições e desconhecidos — bem como os critérios de aceitação.

4. Cada membro da equipe decidir particularmente quão grande essa história é em relação à história de referência, uma série de histórias de referência ou todas as histórias no retorno do produto.

5. Na contagem de três, todos mostram seu cartão escolhido simultaneamente.

Se todos reproduzirem o mesmo cartão, a equipe pode registrar a estimativa e passar para a próxima história.

Se houver uma variação de largura (por exemplo, os números exibidos variam de um para oito), então a equipe gasta tempo discutindo o artigo.Para focalizar a discussão, o licitante baixo e o alto explicam o raciocínio para suas classificações.A conversa é valiosa aqui, não o número, porque isso é onde o aprendizado ocorre e todas as suposições são descobertas.Após uma breve discussão de 30 segundos a um minuto, a equipe repete as etapas 4 e 5.Isso continua até que a equipe entre em um acordo sobre uma estimativa para a história.

Isso parece relativamente simples, mas é importante compreender algumas regras básicas.Primeiro, se a equipe não concordar completamente em algum tipo de acordo, você não deve continuar.Por exemplo, vamos dizer que há uma pessoa na equipe que executa um oito, mas os outro escolhem cinco.Se o facilitador da reunião diz, "Perto o suficiente.Nós vamos com os cinco nisto; seguir em frente", que a pessoa que tinha os oito irá fazer?Baseado na minha experiência, a pessoa que aceitará aquilo que a equipe decidir mas parará de participar inteiramente.Talvez o planejamento seja mais rápido dessa maneira, mas algo valioso se perde.A pessoa perde parte do significado do trabalho e a equipe perde as opiniões e a perspectiva de um de seus membros.Além do mais, não há problema em discordar.Um entendimento valioso vem de discussões sobre porque uma pessoa escolhe um número maior do que todos os outros.Se você se encontrar em um impasse, o facilitador tem que tentar a técnica "Fist to Five".Ele faz maravilhas para começar as reuniões se movendo ao longo sem alienar quaisquer dos participantes.

Como planejar o pôquer expressa as avaliações nos pontos, é idealmente adequado para estiver a reserva do produto.No entanto, uma lista de pendências de sprint deve ser estimada em horas.Dito isto, pôquer de planejamento pode e deve ser usado com êxito para estimar reservas de sprint; os números no cartão, se tornam horas ao invés de pontos.Assim, regra simples –

• As estimativas da lista de pendências do produto são feitas em pontos.

• As estimativas de retorno de sprint estão em horas.

Você pode usar o pôquer de planejamento no início de qualquer projeto e ao longo do ciclo de vida à medida que a nova revela informações, prioriza as alterações, e dá clareza às superfícies.

Avaliação de parede

O planning poker é uma ferramenta fantástica para avaliar histórias de usuários, mas seria necessário muito tempo para avaliar centenas de histórias, uma de cada vez, com ele.Se você tem uma lista de pendência preenchida com centenas de artigos que não foram estimados ou priorizados, você vai precisar uma maneira mais rápida de estimar.

A avaliação de parede é criada para permitir que as equipes eliminem discussões de 2 x 3 e 5 x 8 e em vez disso agrupem itens de uma maneira puramente relativa ao longo de um continuum, pelo menos no início.Ele também permite que os participantes dêem uma priorização geral a um grande grupo de artigos sem ficar parado pendurado em se um artigo é um pouco mais importante do que outro.

Para fazer a Avaliação de Parede, primeiro você deve imprimir as histórias do usuário em cartões.Junte sua equipe e as partes interessadas em uma sala com um grande mural vazio (cerca de 4 metros de comprimento por 2,5 a 3 metros de altura); Entenda dois pontos sobre o mural:

• A altura determina a prioridade.As histórias na parte superior são mais altas; as histórias na parte inferior serão menores.A prioridade de uma história pode ser baseada no ROI, o valor de negócio ou em algo tão simples quanto “é apenas importante e eu não sei porque”.

• A largura é permitida para o tamanho.As histórias à esquerda são menores; as histórias à direita são maiores.(É possível inverter isto e mover da direita para a esquerda se você estiver, por exemplo, no Japão e é mais lógico.) O importante é prever uma linha indo na horizontal e um indo na vertical.Os membros da equipe e participantes que se perguntar, onde, em relação às outras histórias, esta se encaixa?

A equipe irá usar o mural para dimensionar todas as histórias.As partes interessadas usarão o mural para priorizar as histórias.Como com o pôquer de planejamento, estamos usando o dimensionamento relativo, mas em vez de usar duas histórias de referência para comparação, a parede se torna constante.Pequena história?Mova para a esquerda.Grande história?Mova para a direita.Artigo importante?Coloque-a no alto.Uma história que podemos viver sem no momento?Coloque-a embaixo.

Embora os participantes não precisem estar presentes enquanto suas histórias são estimadas, a equipe precisa estar no espaço quando as histórias estão sendo priorizadas.O ScrumMaster e o proprietário do produto devem atender às atividades de avaliação e de priorização.

Se já tiver uma lista de pendências estimada, você poderá fazer apenas a seção de priorização do exercício.Se os proprietários e participantes do produto já forneceram a você uma lista de pendências priorizada, você só pode fazer a seção de estimativa deste exercício.(O proprietário do produto provavelmente desejará revisitar a priorização depois que as estimativas forem realizadas.Após tudo, o custo tem um grande impacto na prioridade.) Vamos dar uma olhada em detalhes sobre como funcionaria o trabalho, começando com a função de equipe.

Estimativa

Dê a equipe a reserva do produto bruto e comece com estimativa.Instruir a equipe que a extrema esquerda da parede deve segurar os menores artigos possíveis e os da extrema direita devem conter os maiores artigos possíveis, sem levar em conta os números.A equipe coloca as histórias em algum lugar do mural com base nesses dois polos.A vantagem para fazer dessa maneira é que não há uma noção preconcebida de que uma história é de dois pontos ou três pontos; é realmente relativo com base em quão grande é a parede, que é realmente uma grande parede que é acessível.

Se sua equipe está tendo dificuldade para fazer isto, você pode fornecer mais estrutura à parede através de artigos de referência adicionais que variam de 1 a 8 pontos.Não se preocupe sobre a criação de uma história de referência maior; qualquer coisa maior será geralmente dividida conforme aumenta na prioridade.Depois que a equipe identificar as cinco histórias, coloque-as na parede em um local que correlacione com seus tamanhos (novamente movendo da esquerda para a direita).Deixe algum espaço no lado direito da parede para histórias maiores do que oito pontos.Coloque as histórias no mural e instrua a equipe a colocar as histórias restantes no mural relativo às histórias de referência, tendo em mente que as histórias menores ficam à esquerda e as histórias maiores, à direita.

Com as histórias na parede, peça à equipe para identificar as quebras lógicas entre os tamanhos da história.Grave uma linha vertical entre os grupos de histórias para ilustrar essas interrupções.Logo você terá uma parede que semelhante à parede mostrada aqui.Tudo no primeiro grupo pode ser um 2; tudo no segundo, um 3; tudo no terceiro grupo, um 5; e tudo no grupo mais recente, um 8.Os números não importa tanto quanto o fato de que todas as histórias agora sejam estimadas relativas umas às outras.

Agora que estimou as histórias, você precisará envolver os participantes para atribuir uma prioridade às histórias.

Priorização

Embora seus clientes e participantes irão desejar saber quão grande é uma história para ajudar a determinar sua prioridade, estarão muito mais focalizados em descobrir as histórias que se referem a eles e garantir que estas histórias sejam realizadas.Espere que os participantes discordem sobre a prioridade - o proprietário do produto usará essas informações para ajudá-lo a decidir a prioridade final.

Explica a parede para os participantes.Diga que as placas na parede refletem todos os recursos que desejam ver no produto final.Explica que a equipe já estimou cada história e que podem determinar a estimativa de ponto para uma história baseada em qual coluna na parede.Lembre a todos os membros da equipe não são participantes ativos na priorização.Eles estão lá para observar, tomar nota sobre o comportamento, as interações, e as razões por que determinadas histórias estão aumentando ou diminuindo de prioridade.Eles também podem responder a todas as perguntas das partes interessadas, caso necessário.Se a equipe não pode dimensionar um ou mais artigos com confiança porque exige respostas de um participante específico, a equipe também pode fazer perguntas sobre os artigos, na medida que o tempo permite.

Solicite que os participantes ajudem a determinar a prioridade relativa de todas as histórias movendo essas histórias para cima ou para baixo dentro das colunas registradas.Lembre-os que quanto mais alta uma história estiver na parede, maior será sua prioridade para o negócio.Defina as seguintes regras:

• Se você colocar um artigo na parte superior, esteja preparado para justificar o posicionamento.

• Você pode perguntar porque uma história é mais importante do que outra.Sinta-se à vontade livre perguntar, “Quem moveu este para baixo (ou cima)?” ou para dizer alto, “Eu acho que este precisa ser movido.Quem deseja discordar?” Isso permite a conversação entre as partes interessadas, sem simplificação.

• Se você mover um artigo na parte inferior da parede de quem já fez, marcá-lo com um ponto colorido para nos alertar.

O maior benefício para priorizar como um grupo é que todos os participantes podem entender melhor as várias prioridades de histórias.Se uma discussão passa muito tempo sem resolução, o proprietário do produto deverá recolher o cartão, identificar os dois participantes que podem não concordar, e fazer uma anotação para se reunir com eles em particular posteriormente.

O exercício poderia levar de 2 a 6 horas, dependendo do número de histórias e o número de partes interessadas.Ao terminar, a parede será similar à imagem exibida abaixo.

Sua parede se dividirá em quatro quadrantes.As histórias no canto superior esquerdo são de alta prioridade e pequenas, portanto elas irão acabar no topo da lista de pendências do produto.As histórias no canto superior direito são de alta prioridade, mas também são grandes.Essas histórias devem ser divididas logo, para que possam ser trazidas nas próximas sprints.

O quadrante inferior esquerdo é composto de pequenas histórias, de menor prioridade.Eles vão provavelmente para o final da lista de pendências.O quadrante inferior direito é preenchido com grandes histórias, que também são de menor prioridade.Essas histórias são suas epopeias ou temas.Eles eventualmente irão precisar ser divididos em histórias menores, mais gerenciáveis, mas não até que subam na prioridade.

Dedique algum tempo olhando para a parede como todo com o grupo.Se um artigo está no quadrante errado, mova-o.Se um artigo de alta prioridade deve ser dividido e o tempo permitir, fazer isto enquanto todos estiverem na sala.

No final da avaliação de parede, você terá o início de um plano de versão.Se você souber a velocidade histórica da equipe, você ainda pode fornecer um intervalo aproximado de quais artigos serão finalizados no quadrante superior esquerdo.

A estimativa é difícil porque há um tanto de incerteza no início de um projeto.Os Proprietários do Produto e os gerentes de projetos Agile tentam maximizar o valor do aprendizado antecipado conversando com proprietários do produto e participantes, produzindo software de trabalho e integrando comentários sobre esse software para atingir o estado de liberação.Mas mesmo os projetos ágeis devem fornecer qualquer estimativa de quando um conjunto de recursos estará pronto para o lançamento.

As duas técnicas de avaliação que eu recomendo são planejando o Planning Poker (apropriado para conjuntos menores de histórias) ou a avaliação do mural (boa para gerenciar listas de pendências grandes de produtos brutos).Fornecerá os dados que você precisa para começar a formar um plano, que é o objetivo final da estimativa.

Consulte também

Conceitos

Planejamento ágil e iterações

Comece como equipe

Criar ou adicionar à lista de pendências de produto

Limpar e estimar a lista de pendências

1. Mike Cohn, Estimativa e Planejamento do Agile, Página 36

2. Tomada de decisão de consenso: sinais manuais (Wikipedia)