Cone da Incerteza e SCRUM

Nos últimos meses eu tinha como foco implementar SCRUM na minha equipe, tudo começou com o Phillip Calçado me explicando o conceito de SCRUM, seguido de um curso com o Bloris Gloger que ele e alguns da equipe fizeram, e depois entramos em um caminho sem volta e nos focamos em implementar o SCRUM da melhor forma possível no nosso time. Acho que posso dizer que estamos muito bem neste momento, claro que ainda faltam detalhes mas o time esta andando e esta entregando software de qualidade a cada ciclo de desenvolvimento.

A próxima meta é escalar o SCRUM para toda a empresa, enquanto estava lendo sobre o assunto acabei me desviando e cai em alguns artigos muito interessantes que discutiam um tema que afeta todo e qualquer projeto de desenvolvimento de software: como estimar com precisão o tempo total para se entregar um software em produção?

Acabei caindo na teoria do Cone da Incerteza, que explica o fenômeno onde nós da indístria de software quando iniciamos um novo projeto não fazemos a menor idéia de quando vamos terminá-lo. Quanto mais o tempo passa e mais perto do fim melhor e mais preciso são as nossas estimativas, ou seja, isso culmina na conclusão de que você só tem 100% de certeza de que terminará o projeto apenas um dia antes de efetivamente terminá-lo.

Esta figura é facilmente associada ao desenvolvimento de um software, ou seja, se começa um projeto sem ter a menor idéia do tamanho dele ai vai se detalhando, escreve-se montanhas de papel com requisitos, desenha-se milhões de telas no Photoshop para fechar o design do projeto, ai finalmente depois de alguns meses é que se começa a escrever software efetivamente. Nestes casos existe uma luta constante para afunilar o cone o mais rápido possível. O grande erro das empresas é fazer um “commitment” com um projeto quando ele esta nas suas etapas iniciais, ao fazer isso elas estão aceitando uma margem de erro de 2x ou 4x nas estimativas, e é neste momento que o projeto começa a ruir.

O que é interessante em metodologias ágeis, como o SCRUM por exemplo, é que podemos observar este fenômeno invertido, explicando melhor, se vc perguntar a um desenvolvedor que já esta envolvido em um projeto o que ele consegue entregar nas próximas duas semanas a estimativa com certeza será bem precisa, mas se perguntarmos o que ele consegue entregar daqui a 6 meses, não fará a menor idéia e vai chutar uma estimativa qualquer pois não há como ter certeza do que irá acontecer. A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão mudar, os requisitos, o design, as funcionalidades e o grande trunfo dos métodos ágeis é de entregar software funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanças.

Então em um ambiente ágil temos sempre mais certeza sobre as estórias que estão priorizadas para o próximo sprint ou estamos trabalhando neste momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme o Product Backlog vai sendo entregue, mas sempre com uma visão muito clara do curto prazo e menos clara para o que esta no fim do Product Backlog. Lembrando que as estórias que estão sendo desenvolvidas no Sprint são as de maior ROI para o projeto.

Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza SCRUM teria este formato: