Estimar ou não estimar?

 Não perca tempo estimando e planejando tempo de execução de alguma atividade do seu projeto. A razão é simples. Não o faça. Sério, não faça isso. Por mais estranho que pareça, estimar e planejar normalmente servem para torná-lo menos previsível, não mais. Pense nisso desta forma: durante todo o tempo que você gasta em estimativa e planejamento, o que você não está fazendo? Trabalhando. Que o tempo poderia ser gasto de outra forma entregando valor do cliente. Quanto mais tempo você gasta planejando e estimando o menor valor que você é capaz de entregar. Na verdade, se você interromper o trabalho para fazer estimativa, como tantas empresas fazem, a estimativa irá realmente torná-lo menos previsível. Pense em quantas vezes você é interrompido por uma estimativa e quanto tempo isso custa. Quanto dinheiro foi ganho por você para compensar esse custo?

                  Não use pontos de história para a previsão, no entanto, as organizações passam mais e mais tempo tentando chegar a melhores e melhores esquemas de estimativa. Esquemas que, no final, não fornecem valor preditivo. Por exemplo, vamos dar uma olhada em um dos processos de estimativa mais populares do Agile: pontos de história. “Claramente,” o raciocínio vai nos conduzindo num caminho sombrio e tenebroso do desperdício de tempo, “a complexidade relativa é o melhor preditor de quanto tempo algo vai demorar para ser concluído.

Nós, como engenheiros de software, entendemos a complexidade relativa dos itens em que estamos trabalhando, então usaremos isso como nosso método preferido para estimar. " Parece bastante lógico. Apesar de tudo, não existe razão ou fato lógico-matemático que nós façamos crer que, se a história A é mais complexa do que a história B então certamente a história A tomará mais tempo para terminar do que a história B. Certo? Errado. E não apenas um pouco errado. Muito errado. Lembre-se que o que os clientes estão realmente perguntando quando eles dizem “quando vai ser feito?” é “Dê-me o tempo total decorrido a partir de agora até quando o meu pedido será concluído”.

Mas o que isso tem a ver com o debate relativo à complexidade? Acontece que há muitas vezes, pouca ou nenhuma correlação entre uma estimativa de complexidade relativa e a quantidade real de tempo decorrido (tempo de ciclo) que leva para que um item seja concluído. Vamos ver um exemplo publicado por Daniel Vacanti, que representa o que realmente acontece no mundo real para explicar o porquê.

Neste primeiro exemplo, você vê a relação de estimativas de pontos de história e tempos de ciclo real para vários itens de trabalho (esses dados são retirados de um estudo de caso da Siemens Health Services publicado por Daniel Vacanti em 2014). À primeira vista, este gráfico pode ser o que você espera. À medida que as estimativas de pontos de história ficam maiores, os tempos de ciclos ficarem maiores também. Ou não? Olhe para os dados para estimativas de 3 pontos de história. Você verá que nesta equipe um item que foi inicialmente estimado em 3 pontos poderia acabar levando algo entre 5 dias a 45 dias para ser concluído. Isso, sinceramente, não é muito previsível. Pior ainda, quando olhamos para os pontos com cycle time de 40 dias. Você verá que os itens que levaram cerca de 40 dias para completar foram originalmente estimados em torno de 2 pontos de história e 11 pontos de história. De novo, não é muito previsível.

Este gráfico mostra a relação de Pontos de História X Tempo de Ciclo.

Ao fazer uma previsão (prevendo o futuro), você tem que aceitar que há mais de um possível resultado. Portanto… Uma previsão é um cálculo sobre o futuro que inclui um Gama e um Probabilidade disso intervalo de ocorrência.

Alguns pontos: 1. Pense em trabalhar com probabilidades e não com determinismo 2. Faça previsões a curto e longo prazo com a compreensão de que as previsões de curto prazo serão mais precisas do que as mais de longo prazo. 3. Refaça suas previsões tão logo você comece a receber mais informação

Estimativas x Lead Time.

É possível ser previsível com o que este gráfico nos mostra?

“O dimensionamento inicial é um bom prognóstico para quando você consegue suas coisas?No nosso caso, a verdade surpreendente foi “não”. – Mattias Skarin, Real-World Kanban

O que está acontecendo?

A baixa eficiência do processo (normalmente 5-15% na entrega de software) significa que, mesmo que tenhamos acertado as estimativas de esforço… estaríamos prevendo com precisão 5-15% do tempo de entrega decorrido! - Troy Magennis

Diversas são as fontes de variabilidade que impactam diretamente nas estimativas criadas.

Quantos você pode nomear?

• WIP alto ou sem limite • Tecnologia / domínio / produto • Composição de time • Usuário, cliente e representante do cliente • Multitarefa / fator de foco • Mercado e concorrentes • Dependências do sistema • Dependências de equipe • Especialização • Aguardando disponibilidade • Retrabalho • Etapas / handoffs (50% * 50% * 50% …) • Estágios no desenvolvimento da equipe (Tuckman) • política de seleção • Complicação essencial (quão difícil é problema é por si só)

O que você pode fazer sobre a variação? Quantos remédios você pode nomear?

• WIP baixo • ConWIP / WIP Sistema (em todo o sistema, ao invés de ser somente por coluna) • Cinco etapas de foco • Agrupamento de bloqueador • Reduza os estágios do fluxo de trabalho • Políticas explícitas • Custo de programação, sequenciamento e seleção de atrasos • Design simples e desacoplado; finas fatias verticais; emparelhamento • Identifique / faça dependências visíveis / de medida • Colaborar / Compartilhar o trabalho (Dimitar Bakardzhiev) • Pico e estabilizar (Dan North) • Reduza a complexidade acidental (Liz Keogh)

No Estimates e o Negócio

• Determinar quais ações seriam diferentes com base na estimativa • Critérios de adequação baseados no cliente • Orçamento: taxa de execução da equipe • Concentre a conversação no valor, não no custo • MVP e propriedade do produto • Criar previsão probabilística o mais rápido possível (assim que você tiver dados) - juntos! • Revisões de Serviço-entrega • Equipes: Mantenha as equipes juntas, dedicadas (reduz a mudança de contexto, estágios de Tuckman)

Manifesto No Estimates … Nós passamos a valorizar: Probabilístico sobre Deterministico Tempo de entrega sobre o tempo de desenvolvimento Escopo do MVP sobre o escopo total Dados sobre intuição * Reduzir as fontes de variação ao melhorar as estimativas Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens à esquerda.

* Neil Killick usa “empirismo sobre adivinhação”

Classes de serviço e as expectativas de entrega de serviços

Criar e gerenciar Classes de serviço é um modo de gerenciar expectativas de entrega de serviços o acordo de nível de serviço. Permite-nos espalhar o risco, agregando uma grande coleção de solicitações e prometendo apenas o desempenho agregado na forma de um desempenho percentual de vencimento. Ao evitar fazer promessas que não são possíveis de serem mantidas, evitamos o perigo de perder a confiança dos nossos clientes. Portanto, é importante comunicar que o prazo de destino na classe de serviço padrão é apenas isso, um alvo! Além disso, permitem-nos evitar atividades dispendiosas, como a estimativa; atividades de baixa confiança, como fazer compromissos.

Fique atento:

1. Nunca use uma média para comunicar uma previsão.
2. Nunca utilize o resultado mais provável para comunicar uma previsão; o resultado mais provável não é muito provável. Seus dados de tempo de ciclo não são normalmente distribuídos por isso não assuma isso ao fazer previsões.
3. Estimativa e planejamento geralmente servem para tornar seu processo menos previsível e não mais previsível.
4. Não há quase nenhuma correlação entre uma estimativa de ponto de história e o tempo decorrido que leva para que um item seja concluído.
5. Não há necessidade de itens do mesmo tamanho para a previsão. Muito, se não a maioria da imprevisibilidade, em seu processo é devido às políticas frágeis que estão implementadas no seu sistema puxado.
6. Implementado incorretamente, as políticas de sistema puxado do seu processo serão tão bem-sucedidas quanto o Titanic.

Referências, ferramentas e mais informações •noestimatesbook.com (Vasco Duarte) • focusedobjective.com (Troy Magennis) • actionableagile.com (Dan Vacanti) • infoq.com/articles/noestimates-monte-carlo (Dimitar Bakardzhiev) •mattphilip.wordpress.com/noestimates-game •When Will It Be Done? (Dan Vacanti)