menu

Previsão probabilística

Por

Pessoal, vamos finalmente falar de Previsão probabilística. Demoramos para falar dela porque precisávamos primeiro criar toda uma base de conceitos.

Bom, talvez você ainda não tenha ouvido falar de previsão probabilística, mas na verdade não é nada muito complicado conceitualmente.

Previsão probabilística

A previsão probabilística nada mais é que o uso de um modelo para simular diversas vezes algum aspecto da realidade para então analisar os resultados.

image00

A previsão do tempo, por exemplo, funciona exatamente dessa forma. Existe um modelo computacional bastante sofisticado que simula os possíveis comportamentos do tempo dadas as variáveis de um passado recente. Esse simulador não simula uma única vez, mas roda uma quantidade imensa de vezes e se 80% destas simulações, por exemplo, apresentarem situação de chuva para o dia, é algo assim que você deve ouvir no noticiário:

“Então Chico, estamos vendo aqui a formação dessa área de instabilidade sobre a capital, com grandes possibilidades de chuva forte no período da tarde”.

No desenvolvimento de software seu modelo não precisa ser tão sofisticado, basta ser capaz de simular algum comportamento do seu processo.

Com o simulador em mãos é preciso ter alguma forma de rodar seu modelo centenas ou milhares de vezes, sempre com um elemento de aleatoriedade.

Por fim, compilam-se os dados e verifica-se o percentual de simulações que atendem a algum parâmetro.

Um modelo básico

Os modelos usados na previsão probabilística podem ser muito sofisticados, mas vamos começar com um bastante simples e suficientemente bom e compreensível 😉

Esse primeiro modelo utiliza a vazão histórica de itens de trabalho (saídas do sistema ou throughput) de um período recente.

Entendendo as simulações

Cada vez que os dados entram em nosso modelo e geram um resultado, chamamos isso de simulação. O que queremos é ter um número suficiente de simulações para obter uma distribuição probabilística. No fundo o que queremos é saber o percentual de simulações que atendem (ou não) algum parâmetro.

Imagine seus dados históricos de vazão como sendo:

Dia 1 |

Dia 2 | Dia 3 | Dia 4 | Dia 5 |

Dia 6

2 itens | 2 itens | 3 itens | 1 itens | 5 itens | 2 itens

 

Sorteamos, então, números aleatoriamente desse histórico. Utilizei apenas seis dias de histórico no exemplo no caso de você querer jogar um dado (esse de jogos de tabuleiro) para simular as ocorrências da simulação:

Nesse nosso exemplo, queremos simular os próximos sete dias, pois vamos imaginar que prometemos entregar 21 itens de trabalho dentro desse período.

A simulação significa jogar o dado, pegar o número correspondente no histórico e então anotá-los até termos o número de dias que queremos simular.

image02

Se os resultados dos lances de dado tivessem sido os seguintes:

5, 1, 1, 1, 1, 3, 1

A sequência dos sete dias simulados teriam sido:

5 itens | 2 itens | 2 itens | 2 itens | 2 itens | 3 itens | 2 itens

 

Nessa simulação, sua semana teria produzido 18 itens de trabalho.

Exemplo de modelo no excel

image04

Veja no modelo anexo que temos o histórico de vazão nas colunas A e B.

Logo abaixo, podemos ver as 1000 simulações, cada linha representa um possível andamento do projeto nos sete dias seguintes.

Tirando informações dos dados gerados

Lembre-se, no exemplo você prometeu entregar uma funcionalidade daqui a sete dias, para essa funcionalidade ficar completa ainda faltam 21 itens de trabalho, será que vai dar? Qual a chance disso acontecer? Qual seria sua atitude com os resultados em mãos?

Agora, veja os percentis (colunas D e E). Acho que a maneira mais fácil de explicar o que queremos com os percentis é entender o exemplo da imagem acima. Veja que apenas 15% das simulações atingiram o resultado desejado de 21 itens, já metade das simulações resultaram em pelo menos 17 itens entregues. 85% das simulações deram pelo menos 14 itens entregues, portanto sua margem de segurança seria alta (85%) se você tivesse que entregar 14 itens, mas muito baixa tendo que entregar 21 (15%).

image01

O que fazer?

Lembre-se que no Agile falamos que um projeto é um fluxo constante de descobertas e portanto precisamos de comunicação ativa, constante e bidirecional entre o negócio e o desenvolvimento. Avalie as possibilidades de renegociar o prazo ou o escopo, talvez seja necessário fazer horas extras (arrrrg), será que é possível delegar alguma parte do escopo ou até assumir dívidas técnicas em prol do prazo (duplo arrrrg), ou será que dá para fazer uma mistura de algumas dessas alternativas?

Bom, demos um exemplo com pouco histórico apenas para facilitar o entendimento. Na verdade, em geral vamos usar um histórico bem maior (se tivermos) e devemos falar de como selecionar e validar o histórico nos próximos posts. De qualquer forma, no post Trabalhando com poucos dados, mostramos que ainda que não tenhamos tanto histórico, ainda é possível ter alguma segurança nele. Também fizemos uso de algumas técnicas estatísticas, como Bootstraping, vale a pena dar uma olhada.

“Although it does not seem like you would be able to improve upon the estimate of a population statistic by reusing the same sample over and over again, bootstrapping can in fact do this.” Courtney Taylor

Neste post vimos se um prazo é possível, mas ainda não falamos em como descobrir qual seria o prazo a partir do número de itens de trabalho sugerido. Vamos falar como resolver esse desafio em nosso próximo post sobre Previsão Probabilística. E aí, como fazer? Alguma sugestão?

Esperamos você na próxima 😉

5 comments

  1. Éverton Bueno Lima

    Olá Leonardo, parabéns pelo post, gostei muito do assunto, porque é um assunto que todos que estão conhecendo o SCRUM, ou querendo mudar para o SCRUM, me fazem, como posso definir uma data de entrega do meu produto? Eu sempre digo que, se você não tem uma base de conhecimento, ou não conhece seu time, é impossível passar uma data provável para entrega, só aós a primeira Sprint que nós teremos uma pequena informação, que poderá começar a ser utilizada, após várias outras, fica mais fácil a definição de uma data. Mas isso depende de projeto, equipe e outros fatores, primeiro se os projetos são diferentes, não adianta eu prever uma data provável, certamente vamos errar, e também se a equipe não é a mesma, também certamente vamos errar essa data provável, ou seja com sabermos o “Prazo está errado”, então eu sempre tento convencer os clientes que no decorrer das entregas posso passar uma data provável para ele, essa assunto até li recentemente no livro “Scrum – A Arte de Faze o Dobro de Trabalho na Metade do Tempo”, ele tem um visão totalmente diferente das entregas, que se fosse debatida entre grupo geraria várias discussões, resumindo, no livro a empresa x não define data de entrega do produto, ela por exemplo pega um projeto de 1 anos e o dinheiro é pago por esse projeto de até 1 ano, mas o projeto, é entregue em 3 meses, a empresa então devolve o dinheiro para o cliente dos 9 meses, e para eles funcionam.

    Portanto queria te fazer um pergunta, igual a todos me fazem, como posso definir um tempo de entrega do meu projeto ou pacote que tenho no meu Product Backlog se nunca usei o SCRUM? Porque no SCRUM não existe essa atividade, por isso mesmo ele é um framework, que podemos adicionar recursos(ferramentas), quais recursos(ferramentas) usaríamos para esse caso? ou explicação? porque o projeto é por histórias e não temos o projeto completo em mãos?

    Porque faço essa pergunta, não é que estou focando somente no SCRUM estou falando do agile mesmo, porque algumas perguntas não conseguimos responder, podemos mostrar algumas ferramentas, mas essas perguntas não conseguirmos responde-las, as perguntas abaixo são de um artigo publicado pelo Prof. José Finoccio:

    Quanto tempo vai demorar o projeto de construção da ponte?
    Qual o orçamento a ser aprovado para a construção da ponte?
    Qual a avaliação geral do risco de construção da ponte?

    Você pode ler todos os livros de Scrum do mundo e não encontrará ferramentas que respondam essas perguntas fundamentais, o que seguramente impede sua adoção em um grande número de culturas e organizações.(José finoccio).

    https://www.linkedin.com/pulse/ponte-e-o-scrum-jos%C3%A9-finocchio-jr?forceNoSplash=true

    Posted on abril 13, 2016
    • Éverton Bueno Lima

      Desculpe pelos erros de português, eu enviei sem querer, só uma correção, onde está realizando a pergunta, esse trecho “porque o projeto é por histórias e não temos o projeto completo em mãos?” não é uma pergunta.

      Posted on abril 13, 2016
  2. Leonardo Campos

    Obrigado, Éverton,

    Eu tava escrevendo a resposta e vi que tava virando um novo post, hehehehe. Vou resumir o que eu estava escrevendo em alguns tópicos.

    Apesar do que eu achei que o Finoccio quis insinuar, não importa se você usa Agile, tradicional ou o que seja, nunca foi fácil dizer quando algum software ficaria pronto. Isso porque desenvolvimento de software é complexo:
    http://blog.kudoos.com.br/gestao/teoria-da-complexidade-na-copa-de-2014/

    Vamos dizer que concordamos que desenvolvimento de software está no universo do complexo, então o melhor é olhar a saída (output) para entender seu comportamento. É isso que essa técnica da previsão probabilística tenta fazer. Ela olha as saídas do seu processo e simula um monte de vezes para vez as chances de algo acontecer no futuro.

    Quanto às perguntas do Finoccio:
    É totalmente possível estabelecer uma data de fim do projeto (http://blog.kudoos.com.br/agile/comecando-a-estimar-a-duracao-de-um-projeto/) e assim um valor, que provavelmente será o valor da equipe durante o tempo. Acontece que se a grana ou o tempo terminarem antes do escopo ter sido concluído, a maior parte do valor de negócio já terá sido entregue.

    Já em relação aos riscos, acho legal práticas do PMBok, como por exemplo o método Delphi, ou mesmo práticas ágeis, como “Velório do projeto”. Mas no fundo, o maior risco de todos é o projeto resolver um problema inexistente ou que ninguém se importa. Além do custo do próprio projeto, tem o custo de oportunidade de deixar de fazer outras coisas que poderiam ter resolvido algum problema real que as pessoas se importassem.
    No livro Lean Enterprise, o autor cita que os números da Amazon mostram que aproximadamente 2/3 das ideias de funcionalidade que pareciam muito boas e promissoras tiveram nenhum efeito ou pior, tiveram efeito negativo sobre as métricas que eles queriam afetar. Ah, só para deixar claro, lá na Amazon eles fazem experimentos para validar as hipóteses antes de sair desenvolvendo 😉

    O que fazer?
    Siga o exemplo da Amazon, nenhum pedaço de software é desenvolvido sem ter sido validado com um experimento. PDCA na veia! Com experimentos, eliminam-se riscos de negócio e riscos técnicos. Melhor descobrir logo que uma ideia que parecia ótima não vai dar certo que depois de investir milhões nela 😉

    O que você acha?

    Posted on abril 13, 2016
    • Éverton Bueno Lima

      Obrigado pela resposta, eu nunca tinha ouvido falar sobre “Velório do projeto”, vou até pesquisa sobre o assunto, se tiver alguma indicação ficaria agradecido, sobre a Amazon, acho muito valido, se eu entendi direito poderia dizer que realizam protótipos para que o projeto seja validado e tenha continuidade, antes de investirem milhões.

      Só voltando um pouquinho do assunto, é que muitos que estão querendo migrar para o Agile, me perguntando “Mas como eu calculo a data de entrega”, eu sempre respondo “Qual a forma que você utiliza hoje? E a forma que está utilizando, você está entregando na data, atrasando a entrega ou se está adiantando a entrega do seu projeto?”, a resposta geralmente é “Geralmente não entregamos na data combinada, na maioria das vezes é entregado atrasado o projeto”, ai que eu tento mostrar a diferença de usar o Agile, entre o modelo atual que está sendo usado porque a única certeza que temos que “A data sempre está errada”, agora será que você não consultando sua equipe, eles estão mesmo engajados na entrega do projeto? Tipo, será que não está existindo muita procrastinação, porque a data foi muito longa, ou muito stress se a data foi muito apertada, ai mostro a diferença de usar algo que pode ser viável para o dois lados, porque todos queremos entregar os projetos com a melhor qualidade possível, não ficar estressado por causa de uma data calculada errada, entre muitos outros fatores que poderia citar que geraria mais discussão sobre o assunto, muito bom o blog e compartilhar e aprender novas experiencias.

      Posted on abril 17, 2016
  3. Diego Eis

    Sensacional e bem didático.
    Fico aguardando o próximo post sobre prever a data de entrega.

    Posted on novembro 24, 2016

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top

O kudoos busca melhorar a gestão ágil no Brasil por meio da criação e promoção de conteúdo e eventos de qualidade. Veja nossos conteúdos e vídeos e participe dos eventos que promovemos para troca de ideias e experiências.

Close