A armadilha da previsibilidade - Parte I - CIO
A armadilha da previsibilidade - Parte I
A previsibilidade é incompatível com o desenvolvimento de software por uma série de motivos. Confira alguns deles
José Fernando Madureira Guedes *
Publicada em 25 de junho de 2014 às 08h19
Mais recentemente, um conjunto de metodologias ágeis, como Scrum e XP, vêm surgindo como uma alternativa para os processos mais tradicionais. Estas metodologias têm em sua base a visão de que o processo de desenvolvimento de software não é algo de todo previsível, e portanto definem um modo de trabalho que permita tirar o melhor resultado do processo, sem exigir que o resultado final seja o que se imaginava no princípio (até porque consideram que isto é impossível).
Estas metodologias têm provado ser extremamente efetivas e são atualmente utilizadas pela grande maioria de empresas baseadas em software (como Google, Microsoft, SAP e Facebook, só para ficar em exemplos "pequenos"). Mas com o sucesso destas técnicas, muitas vezes seus princípios têm sido esquecidos, e tem sido comum encontrarmos empresas buscando ao mesmo tempo adotar métodos ágeis, mas exigindo previsibilidade destes mesmos processos.
● A nossa capacidade de imaginar um novo software é bastante limitada. Um sistema de computador automatiza geralmente um ou mais processos complexos em uma empresa. Para isto, precisa lidar com um conjunto enorme de situações e cenários. Quando "imaginamos" um novo sistema, geralmente pensamos de maneira "geral" no processo, mas não somos capazes de antever todas as situações que o software vai ter que tratar. Num caso mais real, o sistema vai ter que atender a diversos stakeholders, e a "integração" entre estas visões é mais um ponto onde naturalmente vão ocorrer "gaps", que apenas o processo meticuloso de desenvolvimento vai conseguir trazer à tona, e que precisarão ainda ser definidos e tratados.
● Outra questão que se mostra crítica no desenvolvimento de software é a nossa própria linguagem. O português (assim como qualquer outra língua) permite sempre várias interpretações diferentes para um mesmo texto. A própria beleza da língua vem em parte desta flexibilidade. Se somamos a isto a tendência natural do ser humano de sempre buscar a confirmação do que ele já sabe, não é difícil entender porque temos sempre tantos mal-entendidos com as especificações de sistemas.
● A parte técnica do trabalho também traz um bom grau de incerteza. É importante lembrar que todo trabalho de desenvolvimento é fundamentalmente fazer algo novo, e por isso todo desenvolvedor já se deparou com atividades que ele mesmo previa que durariam poucas horas, e acabam durando dias. Qual é o erro de uma estimativa que temos em um caso como este? É fácil termos situações em que a diferença chega a 800%! É viável tentar ter estimativas precisas de projetos quando temos este nível de discrepância em atividades individuais?
● Finalmente, outra constatação importante é o aprendizado gerado por um projeto de desenvolvimento de software. Justamente pela necessidade de se detalhar e definir diversos pontos que eram "cegos" para os envolvidos no projeto, o projeto acaba trazendo para todos um grande aprendizado sobre o sistema, e até mesmo sobre o negócio que se busca informatizar. Isto faz com que a visão sobre o que o sistema deve fazer evolua durante o projeto, e é no mínimo um grande desperdício não aproveitar todo este aprendizado. Atrelado ao fato de que o próprio ambiente de negócios está mudando, não permitir que o projeto evolua durante o trabalho diminui tremendamente a capacidade de geração de valor.