You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Plans help to guide investment decisions (this project is worth to begin?), know who needs to be available to work on a project during a given period and know if a project is on track.
Planning – especially an ongoing iterative approach for planning – is a quest for value, planning is an attempt to answer the question: “What should we build?”
A good planning must:
Reduce risk
Planning increases the likelihood of project success by providing insights into the project's risks
Reduce uncertainty
Iterative planning helps the team to factor knowledge about the software, for building the right software
Support better decision making
Cost and schedule estimates help to decide if start a project or not
Help on trade-off decisions (cost x time, functionality x effort)
Establish trust
Reliable estimates enable reliable delivery; frequent reliable delivery builds trust. Trustworthy estimates enable customers to make both prioritization and trade-off decisions
Convey information
A plan communicates and establishes a set of baseline expectations. A plan provides confidence and verifiability for the estimates.
A good plan is one that stakeholders find sufficiently reliable that they can use it as the basis for making decisions.
Planning is an activity, not a document.
Agile planning balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project.
An agile plan is one that is easy to change.
Agile planning:
is focused more on planning than the plan
encourages change
results in plans that are easily changed
is spread throughout the project
beautiful quote #1:
“If I were to define a failed project, one of my criteria would certainly be 'a project on which no one came up with any better ideas than what was on the initial list of requirements.'” (p. 6)
beautiful quote #2:
“An agile plan is one that we are not only willing but anxious to change. We don't want to change the plan just for the sake of changing, but we want to change because change means we've learned something or that we've avoided a mistake.” (p. 9)
2.1. Planejamento por atividade e não por funcionalidade
Um problema crítico com as metodologias tradicionais é que elas focam em medir o progresso do projeto por meio do acompanhamento de atividades (análise, projeto, arquitetura, testes, etc. que não agregam valor direto ao cliente) e não funcionalidades (requisitos do usuário, que são aquilo que o cliente deseja). O planejamento por atividades tem os seguintes problemas: atividades demoram a terminar, os atrasos são passados adiante no cronograma e atividades não são independentes.
2.1.1. Atividades demoram a terminar (granularidade alta demais)
Como gráficos de Gantt e similares reservam um razoável espaço de tempo para certas atividades, isto faz com que o desenvolvedor use, no mínimo, todo o tempo, mesmo que a atividade possa ser terminada em menos tempo. Muitas vezes são adicionadas funcionalidades desnecessárias ou preciosistas para cumprir o tempo restante. Em alguns ambientes, terminar antes do tempo pode até mesmo causar problemas ao desenvolvedor (acusações de estimativas altas demais, exigências por prazos menores).
2.1.2. Os atrasos são passados adiante no cronograma
Como as atividades são tipicamente dependentes entre si, atrasos se propagam no cronograma. Um atraso em qualquer uma das tarefas se traduz em atraso geral.
2.1.3. Atividades não são independentes
Atividades não são independentes e seguem uma ordem pré-estabelecida (waterfall-like), o que acumula os atrasos (2.1.2) e diminui a capacidade de responder a mudanças.
2.2. Multitarefa causa mais atrasos
Um gráfico mostra que estar comprometido com duas tarefas simultaneamente aumenta um pouco a quantidade de tempo gasto com tarefas que agregam valor. Com mais de duas, este tempo útil começa a diminuir velozmente. Com mais de duas tarefas, o tempo de troca de contexto mental torna-se um gargalo. A multitarefa adia a data de término de cada tarefa individualmente e aumenta o work-in-progress, além de levar a um nível de trabalho mais alto do que o aconselhável, sem espaço para acomodar incertezas.
2.3 Funcionalidades não são desenvolvidas por prioridade
Planos tradicionais partem do pressuposto que TODAS as atividades previstas serão completadas. Neste contexto a priorização e a sequência de atividades são feitas de acordo com a conveniência da equipe de desenvolvimento.
Isto pode levar a que tarefas importantes para o cliente sejam deixadas para o final, podendo ter sua implementação prejudicada se ocorrer atrasos (ser implementada com qualidade baixa devido à pressa ou mesmo não ser implementada).
2.4. Nós ignoramos as incertezas
Abordagens tradicionais ignoram a incerteza, crendo que:
- requisitos iniciais levam a especificações completas
- usuários não irão refinar suas opiniões nem mudar de idéia
- não surgirão novas necessidades no período coberto pelo plano
- é possível definir estimativas precisas para trabalho impreciso
Se um plano tentar a priori tudo que será necessário ao longo do projeto, fatalmente irá falhar.
Estimativas iniciais não devem marcar datas mas um período provável, pois o início do projeto é o período de maior incerteza. À medida que o projeto progride, as estimativas se tornam mais precisas.
2.5. Estimativas tornam-se compromissos
Toda estimativa é acompanhada, implícita ou explicitamente, de uma probabilidade de acerto. Tradicionalmente, este fato é negligenciado e estimativas são tomadas como compromissos.
No Manifesto Ágil, seus autores conferem maior valor a:
Indivíduos e interações do que processos e ferramentas
Uma equipe bem afinada com grandes profissionais e ferramentas medíocres tem melhor desempenho do que uma equipe disfuncional com profissionais medíocres e grandes ferramentas e processos A abordagem ágil busca reconhecer e trabalhar as qualidades e fraquezas individuais ao invés de tentar homogeneizar a todos
Software funcionando do que documentação abrangente
Software liberado incrementalmente e em curtos espaços de tempo torna possível obter feedback rápido, foco nas funcionalidades de maior valor e melhor satisfação do cliente.
Colaboração com o cliente do que negociação de contratos
Tradicionalmente, clientes e desenvolvedores, cuja relação é baseada em contratos de escopo fechado, estão em campos opostos; a abordagem ágil, reconhecendo que ambos têm objetivo comum (software de qualidade), procura alinhar os interesses.
Responder a mudanças do que seguir o plano
Foco principal é entregar valor ao cliente; é inevitável que os clientes tenham novas idéias ou que descartem idéias iniciais no decorrer do processo de aprendizado do software O início do projeto é o ponto de menor conhecimento. À medida que o projeto avança, mais conhecimento é adquirido e torna-se possível melhorar o plano
3.1. Uma abordagem ágil a projetos
3.1.1. Uma equipe ágil trabalha como uma unidade
Em uma equipe ágil a responsabilidade é distribuída e o time trabalha de modo coeso, não havendo subequipes (analistas, programadores, equipe de testes etc)
Papéis em uma equipe ágil:
product owner
assegurar-se que todos no projeto tenham uma visão unificada a respeito do projeto
estabelecer prioridades de modo que a funcionalidade de maior valor seja aquela sendo trabalhada no momento
tomar decisões que maximizem o ROI
#quote:
“In commercial software development, the product owner is often someone from the marketing or product management side of the company. When developing software for internal use, the product owner may instead be a user, the users' manager, an analyst, or the person funding the project”
cliente
quem financia o software
pode ou não ser o product owner
desenvolvedor
qualquer um que participa do desenvolvimento do software: programadores, analistas, testadores, DBAs, designers, arquitetos, especialistas em usabilidade, redatores técnicos etc
gerente de projeto
diferente do tradicional, foca em liderança e remoção de impedimentos ao invés de gerenciamento
em vários projetos, acumula outras funções como product owner ou desenvolvedor
3.1.2. Uma equipe ágil trabalha em iterações curtas
Em um projeto ágil não há fases bem definidas. Exceto algum período bem curto de modelagem e/ou projeto iniciais pregado por algumas metodologias, quando o projeto se inicia realmente, todas as atividades acontecem de modo concorrente dentro da iteração.
Iterações são timeboxed, mesmo se nem todas as funcionalidades foram terminadas. Iterações devem ser curtas. A maioria das equipes ágeis trabalha com iterações de 2 a 4 semanas. A maioria das equipes usa uma duração fixa por todo o projeto; outras definem uma duração a cada iteração.
3.1.3. Uma equipe ágil entrega alguma coisa ao final de cada iteração
A cada iteração, requisitos são transformados em software codificado, testado e potencialmente entregável. Ainda que nem toda iteração gere um release, é importante que o software esteja em um estado em que isto possa ser feito.
Como nem toda iteração gera uma entrega, foi introduzido o conceito de release, que é o resultado de um conjunto de iterações que juntas completam um conjunto de funcionalidades relacionadas. Um release tem tipicamente a duração de 2 a 6 meses. Em alguns casos o primeiro release é maior que os subsequentes.
3.1.4. Uma equipe ágil tem foco em prioridades do negócio
Uma equipe ágil entrega software na ordem estabelecida pelo product owner, de quem se espera que as priorize de modo a maximizar o ROI. Para dar flexibilidade do product owner na priorização, as funcionalidades devem ter pouca ou nenhuma dependência entre si.
Uma equipe ágil deve focar em completar tarefas que façam sentido do ponto de vista do negócio, ao invés de tarefas isoladas que só farão sentido para o cliente algum tempo depois. Uma das melhores maneiras de fazer isto é guiar-se por user stories.
Uma história é uma descrição breve de uma funcionalidade conforme vista pelo cliente ou usuário. Embora não haja uma sintaxe específica para histórias, é útil colocá-la no formato As a/I want/so that. Uma história é apenas um registro do requisito, o qual só é detalhado na iteração na qual será implementado (abordagem just-in-time).
3.1.5. Uma equipe ágil inspeciona e adapta
Um plano criado no início de um projeto não é uma garantia do que ocorrerá. Na prática, muita coisa pode mudar: pessoal pode sair, tecnologias podem trabalhar melhor ou pior que o esperado, usuários podem mudar de idéia, a concorrência pode forçar a empresa a mudar a estratégia etc. Equipes ágeis vêem a mudança como oportunidade de
melhorar o plano.
Ao início de cada iteração, a equipe e o product owner procura, incorporar o conhecimento já obtido nas iterações anteriores. Se este conhecimento afeta o plano, a equipe o altera sem pestanejar de modo a melhor atender à nova visão.
3.2. Uma abordagem ágil ao planejamento
Um projeto não deve ser visto como a execução de um conjunto de passos, mas como a geração contínua de um fluxo de novas capacidades e novo conhecimento. As novas capacidades são incorporadas ao produto; o novo conhecimento possibilita fazer do produto o melhor que ele pode ser. O conhecimento gerado pode ser sobre o produto (o que o produto deve ser) ou sobre o projeto (equipe, tecnologias utilizadas, riscos). Falhas em reconhecer estes novos conhecimentos levam a estratégias que buscam conhecer tudo no início do projeto.
Na visão tradicional, se um projeto fosse uma corrida de 10 quilômetros onde a linha de chegada é conhecida e a meta é chegar a ela o mais rápido possível. Em um projeto ágil, a linha de chegada é um ponto no tempo. Neste sentido se parece mais com uma corrida baseada em tempo: chegar o mais distante possível em 60 minutos. Quando se reconhece que o resultado final é desconhecido – e mesmo impossível de ser conhecido – o planejamento se torna um processo de definição e revisão de metas que leva a um objetivo maior de longo prazo.
3.2.1. Planejamento em múltiplos níveis
É arriscado planejar para mais distante do que o horizonte visível. É preciso estabelecer marcos a partir dos quais se pode vislumbrar o novo horizonte e realizar os ajustes necessários ao plano.
A "cebola do planejamento" é uma figura que mostra 6 níveis decrescentes de planejamento: estratégico, portfolio, produto, release, iteração e diário.
Equipes ágeis focam, assim, em três níveis de planejamento: diário, iteração e release.
O planejamento de release considera as histórias ou temas que serão incluídos no próximo release. É feito no início do projeto, sendo atualizado no decorrer dele, normalmente ao início de cada iteração, para que reflita as expectativas atuais em relação ao que será entregue.
O planejamento da iteração é feito no início de cada iteração, baseando-se nos resultados da iteração anterior. O product owner deve priorizar as funcionalidades para a iteração dada a capacidade da equipe. Durante o planejamento da iteração são definidas as tarefas necessárias.
O planejamento diário não é um planejamento no sentido formal, mas uma rápida reunião para coordenar e sincronizar os trabalhos do dia. O foco é no planejamento das tarefas e na sincronização de atividades individuais.
As outras formas de planejamento mostradas na “cebola do planejamento” normalmente estão fora do escopo de uma equipe ágil.
3.2.2. Condições de satisfação
Condições de satisfação são os critérios adotados pelo product owner para medir o sucesso de um projeto.
No início do planejamento do release, a equipe e o product owner colaborativamente exploram as condições de satisfação, que normalmente incluem os itens usuais: escopo, prazo, custo e qualidade. No planejamento da iteração também são definidas as condições de satisfação para histórias individualmente. Por exemplo, para uma história “Como um usuário eu quero ser capaz de cancelar uma reserva”, as condições de satisfação poderiam ser:
Um usuário que cancela uma reserva com mais de 24 horas de antecedência recebe a restituição integral do que foi pago
Um usuário que cancela uma reserva com menos de 24 horas de antecedência recebe a restituição menos 25% a título de taxa de cancelamento
Um código de cancelamento é mostrado no site e enviado por e-mail ao usuário
O feedback obtido ao fim de cada iteração pode ser utilizado para melhorias tanto no plano do release quanto no plano da próxima iteração.
Pode-se fazer uma analogia de estimativas de user stories ou funcionalidades em projetos ágeis com a expectativa que se tem a respeito do tamanho de um prato a ser servido em um restaurante: porção completa ou meia-porção de um prato; refrigerante pequeno, médio ou grande. Ou seja, estimativa por comparação. O mais importante é saber se uma funcionalidade ou story é maior ou menor que outra.
4.1. Story points são relativos
Story points são uma unidade de medida para expressar o tamanho de uma história ou funcionalidade. Ao estimar uma história, deve-se atribuir a ela um valor em pontos. O valor em si não é importante, o que importa é um valor relativo a outro. Uma história de dois pontos deve ser o dobro de uma com 1 ponto e 2/3 de uma com 3 pontos.
Não há uma fórmula para se calcular o tamanho de uma história, mas devem ser consideradas características como o esforço estimado, a complexidade do desenvolvimento, o risco e outras.
Há duas abordagens comuns para se iniciar: (1) escolhe-se aquela que se acredita ser a menor história e esta recebe o valor 1; e (2) escolhe-se uma história que se acredita ter o tamanho na média, atribuindo-se a ela um valor que esteja na média da faixa esperada de tamanhos (o autor prefere histórias entre 1 e 10 pontos). Em ambas as abordagens, as outras histórias são estimadas com base nesta primeira escolhida.
Como exemplo, imagine que tamanhos de raças de cachorros são medidos em dog points. As raças são:
Labrador retriever
Terrier
Dogue alemão
Poodle
Dachshund
Pastor alemão
São Bernardo
Bulldog
O labrador retriever é escolhido como o tamanho médio e lhe são atribuídos 5 pontos. Uma distribuição possível de dog points é mostrada a seguir:
É comum que algumas histórias não estejam completamente definidas no início da iteração, sendo o restante definido no decorrer desta. Mesmo assim estas histórias devem ser estimadas: defina algumas premissas, levante uma hipótese e vá em frente.
4.2. Velocidade
Velocidade é a medida da taxa de progresso de uma equipe, consistindo na soma do número de story points atribuídos a cada história completada na iteração. Se a equipe completou 3 histórias de 5 pontos na última iteração, a velocidade da equipe é de 15.
Se uma equipe completou 10 story points na última iteração, podemos acreditar que ela completará 10 story points na iteração atual (a idéia de "yesterday weather" do XP).
Se forem somadas as estimativas em story points de todas as funcionalidades desejadas, teremos a estimativa do tamanho total do projeto. Se a velocidade da equipe é conhecida, podemos dividir o tamanho do projeto pela velocidade e estimar o número de iterações e, consequentemente, uma duração para o projeto.
Esta explicação de planejamento de releases é bastante simplista mas funcionará por enquanto (o livro traz, mais a frente, maiores detalhes a este respeito).
4.2.1. A velocidade corrige erros de estimativa
A beleza desta abordagem é que a aplicação do conceito de velocidade auto-corrige erros de estimativa. Suponha que um projeto é estimado para 200 pontos e o time acredita que sua velocidade é de 25 pontos por iteração, o que significa que a duração estimada é de 8 iterações. Contudo, uma vez que o projeto se inicia, verifica-se que a velocidade da equipe é de 20 pontos. Sem fazer nenhuma reestimativa, pode-se identificar que com esta velocidade o projeto terá então 10 iterações em lugar de 8.
A estimativa por pontos tem a boa característica de separar completamente a estimativa de esforço da estimativa de duração. Evidentemente, esforço e duração são relacionados, mas separá-los permite que possam ser pensados separadamente. Note que a duração do projeto não é estimada, mas calculada. A distinção é sutil, mas importante.
Se nos perguntarmos quanto tempo dura um jogo de futebol, há duas respostas possíveis:
dois tempos de 45 minutos, ou seja, 90 minutos, 1 hora e meia
cerca de 2 horas, se contarmos 15 minutos de intervalo e os eventuais acréscimos aos dois tempos.
A diferença está no modo de medir. A primeira é o tempo ideal, medido levando-se em conta apenas o tempo regulamentar e nada mais. A segunda é o tempo decorrido, que leva em conta o tempo conforme contado no relógio. Cada forma de medir serve a um propósito: a primeira, para os árbitros, geração de estatísticas e demais questões técnicas; a segunda, para a grade de programação das emissoras e para o público.
Normalmente, é bem mais fácil estimar por tempo ideal, pois não é necessário levar em conta a complexidade e as incertezas do mundo real.
Ainda na analogia do futebol, imagine que um jogo transmitido pela televisão, e na programação foi atribuído um tempo de 2 horas para a transmissão. Este tempo é evidentemente uma estimativa. Se houver, por exemplo, uma briga generalizada entre os dois times no meio da partida o jogo atrasará e, digamos que o tempo decorrido entre o início e o fim do jogo seja de 2 horas e 20 minutos. A parte do público da TV que deseja assistir ao programa após o futebol terá seu entretenimento atrasado. Podem ficar chateadas ou aborrecidas com isto, mas nunca surpresas, pois a duração do jogo de futebol é uma estimativa. Do mesmo modo, não é de surpreender quando um projeto de software estimado para 12 semanas gasta, por exemplo, 13.
5.1. Tempo ideal e desenvolvimento de software
Em um projeto de software, o tempo ideal difere do tempo decorrido devido ao overhead natural do dia-a-dia. Além da história corrente, um desenvolvedor típico eventualmente gasta tempo com outras coisas tais como suporte e manutenção dos releases em produção, reuniões, apresentações, questões pessoais, telefone, estudo e treinamento, e-mail, alternância entre tarefas, pequenas questões administrativas etc.
É comum um gerente perguntar a um desenvolvedor quanto tempo uma determinada tarefa irá levar e o desenvolvedor responder “Cinco dias”, o que o gerente toma como um compromisso. Porém, a realidade, muitas vezes não percebida claramente, é: “Cinco dias se eu fizer apenas isso. Como faço outras coisas, provavelmente ficará pronto em 2 semanas”.
Para o cálculo dos dias ideais, assume-se que:
a história sendo estimada é a única coisa com a qual o desenvolvedor irá se ocupar
tudo o que o desenvolvedor necessitar estará à mão quando ele começar
não haverá interrupções
5.2. Dias ideais como uma métrica de tamanho
Ao estimar por dias ideais, não é necessário levar em consideração todo o eventual overhead. Dependendo do ambiente e da cultura da organização, a diferença entre dias ideais e dias decorridos poderá ser maior ou menor.
Quando não se levando em conta o overhead do mundo real, dias ideais são uma estimativa de tamanho, exatamente como os story points. Também como estes, um tamanho expresso em dias ideais pode ser utilizado para se obter uma estimativa de duração do projeto usando a velocidade.
5.3. Uma estimativa, não muitas
Quando se escolhe estimar por dias ideais, apenas uma estimativa deve ser agregada a cada história. Algumas equipes estimam histórias por papel: x dias ideais para o programador, y dias ideais para o DBA, z dias ideais para o webdesigner e por aí vai. Na imensa maioria dos casos, isto não é aconselhável, pois remove o foco na idéia de “estamos todos juntos nisto” que agile traz. Além disto, a adoção desta estratégia complica bastante o planejamento dos releases e das iterações, além de gerar uma velocidade para cada papel. O autor, por outro lado, cita um caso onde isto foi justificado: uma equipe teria que gerar três versões funcionalmente idênticas de um produto, para Windows, MacOS e handhelds. Como os indivíduos não tinham condições técnicas de atuar em mais de uma frente destas três, optou-se por estimar separadamente os tamanhos em dias ideais.
Nem sempre dedicar o máximo esforço possível a uma determinada tarefa é a melhor coisa a fazer. Muitas vezes, por apenas uma fração deste esforço é possível obter resultados adequados. Isto vale para o esforço despendido em estimativas. Para o autor, a curva precisão da estimativa por esforço é como uma parábola, ou seja, ele argumenta que há uma certa quantidade de esforço até a qual a qualidade das estimativas é crescente. Desta quantidade de esforço em diante, a precisão da estimativa passa a decair. Além disto, mesmo o ponto máximo da parábola não chega a 100% de precisão, talvez nem a 80%.
A ilusão da previsibilidade é uma armadilha para muitos projetos, que visando obter uma estimativa de máxima precisão realiza uma grande quantidade de trabalho up-front e ainda assim as estimativas não são as desejadas.
Uma equipe ágil prefere ficar na metade crescente da parábola, reconhecendo que é impossível eliminar a incerteza e buscando a dose correta onde pequenos esforços trazem grandes resultados (p. ex. a regra 20-80). Mesmo recusando um grande esforço de planejamento, planos ágeis tendem a ser mais confiáveis no decorrer do tempo, pois são norteados por entrega de frequente de pequenos incrementos código completamente funcional, testado e integrado
6.1. Estimativas são compartilhadas
Equipes ágeis estimam em grupo, por todos os membros, pois normalmente não se sabe a priori quem será responsável pela implementação de nenhuma história em particular. Além disto, a diversidade de opiniões tende a minimizar vícios individuais, tanto de demasiado otimismo quanto de pessimismo.
6.2. A escala de estimativa
Nós somos melhores em estimar coisas dentro de 1 ordem de magnitude. Assim, estimativas ágeis são feitas dentro de uma faixa. O autor tem tido sucesso com duas escalas:
1, 2, 3, 5 e 8 (fibonacci)
1, 2, 4 e 8 (dobro)
Embora ambas funcionem bem, o autor tem ligeira preferência pela primeira. Tomando esta como base, caso uma história seja vista como um pouco maior que outra à qual foi atribuído 5, não há problemas em atribuí-la 5 também. Por outro lado, uma história que mereceria um 7 poderia perfeitamente ser aproximada para 8.
É útil permitir que zero seja um valor válido para estimativas. Como as estimativas são relativas e estamos em uma escala de 8x, definir 1 para histórias minúsculas pode limitar muito o tamanho máximo das histórias. Além disto, se uma história é muito mais próxima de zero que de 1, atribuir 1 poderia trazer ruído ao cálculo da velocidade.
Se a equipe adota zero na escala, é preciso fazer todos na equipe (principalmente o product owner) entender que 15 vezes zero não é igual a zero. Uma história de zero pontos pode ser vista como gratuita, mas 10 delas não. Uma alternativa o uso de zero é definir uma estimativa única para um grupo de histórias minúsculas.
Algumas equipes preferem valores como 10, 20, 30, 50 e 100. Não há problema, pois estão todos na mesma ordem de magnitude. Contudo deve-se estabelecer, assim como com números pequenos, os valores aceitáveis. Não se pode permitir uma história estimada como 66 e outra como 67, pois é um nível de precisão falso, já que não é possível discernir a 1%.
6.3. Histórias, épicos e temas
Embora sempre seja preferível estimar histórias cujos tamanhos sejam pequenos, nem sempre isto é possível, pois nem todos os requisitos se apresentam em uma granularidade tão fina. Estimativas iniciais, por exemplo, para requisitos de alto nível que não serão implementados no futuro próximo, por exemplo. Ou quando se está analisando a viabilidade de se implementar um módulo. Para estes casos, é desejável ter uma grande história, que normalmente é chamda de épico.
Além disto, um conjunto de histórias relacionadas pode ser combinada e tratada, para fins de estimativa ou planejamento de release, como um todo. Este conjunto normalmente é chamado de tema.
É necessário sempre ter em mente que estimativas para épicos ou temas sempre terão um grau de incerteza muito maior do que estimativas para histórias comuns.
Histórias que serão abordadas em um futuro próximo (ou seja, nas próximas iterações) precisam ser pequenas o suficiente para caber em uma iteração, devendo ser estimadas com números pequenos (1, 2, 3, 5, 8, por exemplo). Histórias cuja implementação está mais distante podem ser mantidas como épicos. O autor utiliza os valores de 13, 20, 40 e 100 para estes casos.
6.4. Derivando uma estimativa
As técnicas mais comuns (que podem ser usadas isoladamente ou em conjunto) são:
opinião de especialista
analogia
desagregação
6.4.1. Opinião de especialista
Esta abordagem é simplesmente perguntar a alguém que conheça bem o assunto em questão. Isto é mais útil em histórias que não envolvem conhecimentos que não possam ser dominados por uma só pessoa. Embora seja baseada em intuição, há evidências que dizem que este tipo de abordagem costuma ser mais precisa do que abordagens mais analíticas (Phillip Johnson et al., Empirically Guided Software Effort Estimation. IEEE Software, 17(6), pp. 51-56, 2000).
6.4.2. Analogia
Nesta abordagem, uma história é estimada comparativamente a outras. Uma técnica útil é a triangulação: uma história estimada como 5 deve ser maior que uma estimada como 3 e menor que uma de 8. Há evidências de que estimamos melhor usando comparações do que tamanhos absolutos.
6.4.3. Desagregação
Na desagregação, uma história é dividida em outras menores e mais fáceis de estimar. É mais simples estimar coisas pequenas que grandes. Mais adiante no livro há um capítulo específico sobre como dividir histórias.
6.5. Planning poker
Uma das melhores técnicas para estimativas ágeis é o planning poker. Planning poker combina opinião do especialista, analogia e desagregação em uma abordagem agradável que resulta em estimativas rápidas, porém confiáveis.
Todos os desenvolvedores participam do planning poker. Lembrando que por “desenvolvedores” entende-se toda a equipe. Em um projeto ágil, isto normalmente não ultrapassa 10 pessoas. Caso aconteça, é normalmente melhor dividir a equipe em duas, com cada equipe estimando individualmente. O product owner participa do planning poker mas não estima.
No início do planning poker, cada estimador recebe um conjunto de cartas, com cada uma contendo o número de um dos valores válidos para estimativas (por exemplo, 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100). Os cartões devem ser preparados antes do PP e os números devem ser grandes o suficiente para serem vistos por todos quando estiverem sobre a mesa.
Cada história a ser estimada tem sua descrição lida por um moderador. O moderador normalmente é o product owner, embora nada impeça que seja qualquer outro. O product owner responde a qualquer dúvida que os estimadores eventualmente tenham. Contudo, todos são lembrados da curva de esforço por precisão. A meta do PP é chegar a uma estimativa adequada rapidamente.
Após todas as questões serem respondidas, cada estimador seleciona um cartão contendo a sua estimativa. Nenhum cartão escolhido é mostrado até que todos os estimadores tenham terminado. Quando todos terminam, todos os cartões são colocados ao mesmo tempo sobre a mesa para que todos possam ver cada estimativa.
É comum e mesmo desejável que as estimativas sejam bem diferentes, o que levará a que os estimadores das extremidades expliquem suas posições. É importante que o espírito não seja de disputa ou ataques pessoais, mas de aprendizado mútuo.
O grupo tem poucos minutos para discutir, após o que cada estimador reestima com base nos argumentos fornecidos. Novamente, os cartões só são mostrados após todos reestimarem. A maioria das estimativas se resolve no segundo round; raramente alguma ultrapassa o terceiro. A regra geral não é precisão absoluta, mas bom senso.
6.5.1. A medida certa de discussão
É importante que as discussões sigam fielmente um timebox. O autor considera que dois minutos seja um tempo razoável e recomenda que seja adquirida uma ampulheta que marque este tempo. Quando o tempo se esgota, um novo round se inicia.
6.5.2. Sessões com menos gente
É possível, embora não seja o ideal, que o PP seja feito com um subconjunto dos membros do projeto. Porém, pode ser útil quando há uma grande quantidade de histórias a serem estimadas, o que normalmente acontece no início dos projetos.
Quando isto ocorrer, é importante que os subgrupos não tenham menos de 3 estimadores e que as estimativas sejam consistentes entre os grupos. Uma boa abordagem é estimar de 10 a 20 histórias com a equipe completa e os subgrupos estimarem as restantes a partir daí com base naquelas estimadas pelo grupo completo.
6.5.4. Por que planning poker funciona?
Primeiro, devido a presença da equipe inteira, com pessoas com habilidades diversas. Segundo, porque os estimadores são levados a justificar suas estimativas para o grupo, o que contribui para aumentar a precisão da estimativa, especialmente quando há níveis altos de incerteza. Além disto, PP combina as abordagens individual e coletiva de se realizar estimativas.
Por fim, planning poker funciona porque é divertido.
