Desenvolvimento de Software: A História (Parte 1)
Se você já trabalhou em algum projeto de software ou já ouviu alguém falando sobre isso, certamente já deve ter ouvido algumas palavrinhas mágicas: “ágil”, “SCRUM”, “cascata”. De forma geral, o espírito de desenvolvimento de sistemas hoje em dia é presente em quase todo tipo de negócio, porque acabou emprestando suas tendências pra diversas áreas, como administração, estatística, marketing.
Mas pra conseguir entender isso, é preciso voltar um pouco no tempo pegar um pouco da alegria que era o ciclo de desenvolvimento de software nos tempos longínquos (ou não tão longínquos, existem empresas que ainda praticam as formas mais tradicionais de desenvolvimento).
É estranho pensar no mundo sem computadores, né? Tipo, eu mesmo já me perguntei “Se não existisse a computação, o que eu estaria fazendo da vida hoje?”. Apesar de pensar que se fosse jovem nos anos 80 eu seria MUITO feliz com a cultura da época (aquelas músicas, aquelas roupas…), eu realmente não faço ideia do que seria quando crescesse. Mas a questão é que a computação não surgiu do nada, ela praticamente veio como uma ramificação da Engenharia, principalmente a Elétrica.
Naqueles dias, a computação meio que se resumia à programação, e a programação era o mais baixo nível possível, praticamente você fazia o bit passar corrente tendo um 1 ou cortava a corrente dele tendo um 0. Olhando por esse lado, você já consegue perceber que processo, planejamento todos esses detalhes e pormenores eram beeeem secundários, não? Pois é…
Com o tempo, ocorreu uma automatização (um pouco sobre isso aqui) na atividade de programar, o que acabou moldando a computação do jeito que a gente conhece mais ela hoje em dia. Só é legal lembrar que: a computação surgiu como um braço de engenharia (e de Telecom), portanto, herdou muitas práticas de lá.
Quando os analistas de sistemas começaram a se livrar de só programar, eles começaram a ter mais tempo pra planejar, analisar, executar e entregar os sistemas, que começavam a ficar mais complexos porque a tecnologia começava a permitir isso. Com isso, o desenvolvimento de software acabou ganhando forma, e um processo foi desenhado. Basicamente, o desenvolvimento funcionava assim:
- Requisitos: tudo começava com a descoberta do que tinha que ser feito. Alguns amiguinhos entrevistavam o cliente, viam o que ele precisava e documentavam tudo bonitinho;
- Planejamento: depois disso, acontecia a etapa de reunir os mestres do universo para ver como seria feita a coisa, em termos de que código seria desenvolvido, quando, por quem;
- Implementação: agora vai! Já tava tudo desenhado, hora de botar a mão na massa e fazer a mágica da programação acontecer;
- Verificação: o que foi feito vai ser verificado (ou testado, adoro), o que estiver errado vai ser corrigido e aí só vai faltar uma coisa;
- Manutenção: toma, que o filho é teu! Hora de entregar o sistema pro cliente e só ir dando manutenção quando algo de ruim acontecer por lá.
Perceba, Ivair, que cada etapa gera um resultado, e esse resultado funciona pra alimentar a etapa seguinte. Colocando de uma forma gráfica, a gente consegue ver facilmente o porque do nome desse modelo de desenvolvimento: Cascata.
Perceba mais uma coisa, Ivair: o Cascata evidencia muito bem a raiz ‘engenheira’ da computação, porque seguindo essa receita de bolo trocando uma coisa aqui e ali, você consegue construir uma casa! Bom, mais ou menos… Mas o importante aqui é perceber que, no modelo tradicional, você tem etapas bem definidas, gerando saídas e dependendo de entradas, de forma muito estruturada.
Existem muitas e muitas e muitas análises, padrões e variações de desenvolvimento tradicional, sobre os quais eu vou dizer que não sou exatamente especialista então não vou falar pra não fingir que sei. De qualquer forma, deixo referências no fim do texto pra quem se interessar!
O tempo passou (“e eu sofri calado, não deu pra tirar ela do pensamento”), e a tecnologia continuou evoluindo, a automatização foi ficando mais e mais presente em cada etapa do desenvolvimento e isso foi possibilitando que as etapas que não eram implementação fossem sendo aprimoradas e ficassem cada vez mais sofisticadas.
MAAAAAAAAAS, como tudo na vida, sempre é legal existir um certo equilíbrio e bom-senso quando se está melhorando algo, pensando “O esforço que eu tô tendo pra fazer essa melhoria vai trazer um retorno que justifique?”. Pois é, o que acabou acontecendo é que ficou evidente que, na maioria dos casos, não justificava.
Pega, por exemplo, uma coleta de requisitos porreta, espetacular, feita nos trinques. Aí, beleza, já tá na fase de implementação, todo programador sabendo direitinho o que precisa fazer… e então, acontece: o escopo muda! O cliente não quer mais a tela azul com botões brancos, ele quer ela vermelha, com botões roxos e gifs em todo lugar possível. E agora?
Existem diversos outros tipos de problemas que o Cascata enfrentava, apesar de que ainda hoje ele possa ser aplicado! Por exemplo, em projetos críticos e que tenham pouca ou nenhuma variação de escopo. Contudo a grande maioria dos cenários são variáveis, e exigem uma forma melhor de lidar com mudanças.
Eis que então, uma galerinha da pesada aprontou todas numa Sessão da Tarde e acabou se juntando e discutindo sobre como lidar com esses problemas, procurando qual a melhor forma de desenvolver software. A história completa desse episódio é bem interessante, mas pra não delongar muito vou deixar pro próximo post. Acompanha aí que garanto que vai valer a pena!
Não se esqueça de comentar, falar suas experiências com desenvolvimento ou dúvidas!
Referências:
