A cascata iterada

Hoje quero contar uma história. Uma pequena história de uma raça antiga: os programadores.

No início era o caos, programas nasciam do uso de alguma variação de programe-pra-ver-no-que-dá. Na verdade alguns programas ainda conseguem nascer desse jeito. Mesmo no século XXI, mesmo depois de todas as más experiências no decorrer do século passado.

Só que a coisa começou a dar certo. Algumas pessoas notaram que aquele negócio de programar computadores poderia realmente ser útil para a humanidade. Foi nessa hora que surgiram os estudiosos.

Eles começaram a desvendar as várias habilidades necessárias para produzir um programa de computador e chamaram essas habilidades de disciplinas ou áreas de conhecimento. A noção de disciplinas ou áreas de conhecimento já levou muita gente a dividir um projeto em fases correspondentes a elas. Esta mesma noção também deve ser a responsável por grande parte da especialização funcional observada em tantas organizações. É por estas e outras que muitos separam os cargos de analista e programador, por exemplo.

Depois de muito estudar, os tais estudiosos chegaram à conclusão que programar-pra-ver-no-que-dá era passado, coisa para neandertais e para os bárbaros não iluminados. Ninguém quer ser chamado de neandertal ou bárbaro, por isso as pessoas começaram a estudar quais eram as tais áreas do conhecimento e passaram naturalmente a organizar o tempo de modo que pudessem se concentrar em uma das habilidades de cada vez. Isso permitiria também ter pessoas especializadas em cada uma das áreas do conhecimento para fazer fábricas de software com linhas de montagem. Assim poderíamos dividir o trabalho entre operários especializados como se faz nas linhas de montagem de manufatura. Ao invés de apertar parafusos, os operários analistas poderiam somente analisar o problema (o que quer que isso queira dizer) e os operários programadores poderiam se concentrar em programar.

Com as novas descobertas, as pessoas passaram a organizar o tempo dos projetos em fases e caminhavam de fase em fase sem olhar para trás. Isso foi chamado de cascata, pela analogia com o que acontece com a água quando cai de cima de uma ribanceira: ela nunca tem a chance de voltar para onde veio, só seguir em frente.

O problema do desenvolvimento em cascata é que as pessoas tinham que confiar plenamente no trabalho que havia sido feito na fase anterior. Erros eram imperdoáveis. Erros pequenos em uma fase inicial se transformavam em erros monstruosos em fases posteriores. Além disso, não era possível modificar o destino do projeto uma vez iniciado. Você só tinha uma bala e era preciso acertar o tiro de primeira. E o alvo era difícil.

O pessoal estava notando como era difícil acertar o alvo, por isso entraram em cena os estudiosos novamente. Eles descobriram que o problema não estava na mira, mas na abordagem. Não era possível atingir o alvo, porque ele ficava se mexendo, mudando de posição toda hora. Era melhor reajustar a direção de tempos em tempos, e os estudiosos fizeram o que eles fazem quando precisam resolver um problema: inventaram um novo conceito. Eles desenharam espirais e todo tipo de formas malucas e chegaram a um nome para a novidade.

O nome era desenvolvimento iterativo, que queria basicamente dizer para fazer os programas em ciclos. Todas as habilidades deveriam ser utilizadas em todos os ciclos. A idéia é boa. Ao final de cada ciclo (e início do novo) a equipe poderia ver como as coisas estavam indo e reajustar a direção, se necessário.

Mas a idéia da cascata, da linha de montagem onde o uso de cada uma das habilidades precede o uso da próxima, parece que ainda estava muito enraizada na cabeça das pessoas a este ponto. Chegamos então à cascata iterada. As pessoas, ao invés de fazerem um grande projeto em cascata, faziam as coisas em ciclos que lembravam muito o modo antigo de trabalhar, mas em uma escala de tempo menor. Este novo jeito de trabalhar era melhor que o anterior. Bem melhor na verdade, pois permitia à equipe se adaptar um pouco melhor às mudanças.

O problema com esta nova abordagem é que enxerga as habilidades através de uma lente de correção muito forte e ainda as confunde com fases e especializações. Só que são somente habilidades e quando são tratadas como fases há desperdício, o mesmo desperdício que ocorria no desenvolvimento em cascata puro, só que em escala menor.

Aquelas disciplinas e áreas do conhecimento são somente habilidades, uma divisão didática que não precisa ser materializada em fases ou cargos. Como habilidades elas devem ser utilizadas a todo o tempo, por todos. Todo mundo deve estar projetando, planejando e testando o tempo todo, mesmo que pareça que estão simplesmente 'programando'.

Aliás, alguém ainda diz que é programador hoje em dia? Ou todo mundo prefere aqueles nomes pomposos?