A ilusão da previsibilidade

Às vezes alguns projetos de software são medidos pelo tempo de entrega ou pelo tempo de atraso no desenvolvimento do software. Verdade é que essa é uma vertente muito perigosa da forma tradicional de gestão de projetos. Fato é que, projetos em geral, não apenas tradicionais, são geridos muitas e muitas vezes pela entrega no prazo, com custo e escopo mantido.Verdade é, que nem sempre conseguimos prever de antemão tudo o que pode ocorrer dentro de um projeto. Por exemplo, é possível prever uma greve de ônibus que faz com que metade ou mais da sua equipe não consiga simplesmente chegar à empresa durante uma semana? Ou prever uma enfermidade que afaste justamente o líder técnico do projeto por um determinado tempo, comprometendo assim todos os prazos que foram previstos.

Uma boa comparação é a previsão do tempo (broadcast): Se eu te perguntar sobre a possibilidade de chover amanhã, você poderia me dizer que, analisando o clima de hoje, há ou não esta possibilidade. Pois bem, aumentemos agora nossa janela para a semana que vem, pronto! Mesmo analisando as condições meteorológicas não podemos precisar se choverá ou se esfriará ou fará calor. Mesmo o instituto de pesquisas meteorológicas é incapaz de precisar como será o tempo daqui a 06 meses, mesmo com todos os equipamentos que possuem, no máximo irão dizer que há uma tendência a um determinado tipo de clima, levando em consideração, veja só, o histórico do clima nessa época do ano, conforme os anos anteriores. Bingo!

Em ambientes ágeis, com Scrum, trabalhamos com o horizonte de no máximo 30 dias justamente para que possamos focar o esforço naquilo que é mais palpável para este período. Todo o trabalho já realizado serve de histórico para auxiliar-nos durante a estimativa. Mas, lembre-se do que eu disse em um dos meus posts anteriores sobre estimativas, elas variam, e podem variar para mais ou para menos. Nós agilistas aceitamos as mudanças, mesmo que tardias, e entendemos que toda mudança traz consigo algum impacto no projeto, normalmente é necessário reajustar nossas estimativas, seja para mais ou para menos, pois com o tempo, passamos a visualizar melhor o contexto, entender mais do negócio, conhecer nossa própria velocidade, os tornando assim melhores quando estimamos.

Porque projetos tradicionais normalmente atrasam?

Normal é, em projetos geridos de forma tradicional, que tais atrasem pelo simples motivo de que seus gestores/gerentes imaginam muitas vezes que podem prever todos os eventos impactantes, antes mesmo de iniciar os projetos. Quantas horas/dia cada um dos seus “recursos” irão trabalhar no projeto e também são conhecedores de todo o escopo previamente. Já disse aqui que, é impossível prever tudo no início do projeto, mas é altamente necessário ajustar desvios, positivos ou negativos durante o desenvolvimento. Projetos tradicionais tendem a trabalhar um horizonte muito distante, tornando assim, nula suas expectativas de cumprimento dos prazos preestabelecidos. Quem nunca passou por fases de planejamento altamente detalhadas inclusive nos aspectos técnicos do projeto, ao nível das tarefas a serem executadas e toda a arquitetura definida no início do projeto (Big Desing Up Front). Pergunto agora, quem nunca atrasou um projeto nestas condições? O próprio Wiston Royce (criador do modelo Waterfall) alerta quando do surgimento do modelo de desenvolvimento em cascata quanto as possíveis falhas, e mesmo assim, seus utilizadores insistem que tudo pode ser previsto de antemão. Responda-me agora a seguinte pergunta: E se o Negócio do seu cliente exigir uma grande mudança de rumo? Permito-me responder da seguinte forma: O projeto irá atrasar! Simples assim.

Imaginar que se pode prever tudo é simplesmente uma falácia da era escura do desenvolvimento do software. Hoje temos a certeza que as coisas irão mudar, e aceitamos tais mudanças, se possível for ainda, fazemos proveito delas em prol ao produto do software que estamos desenvolvendo. Medir uma equipe pelos prazos que ela executa é sentencia-la a fazer qualquer coisa que julgar necessário para cumprir o prazo, mesmo que isso signifique queda nos níveis de qualidade, já que a equipe é medida pelo tempo, ao invés de produto pronto e número reduzido de bugs e como consequência, baixo retrabalho.