E nesse tempo houve muitas metodologias, processos e modelos diferentes de engenharia de software propostos para ajudar os desenvolvedores de software a alcançar esse processo previsível e econômico. Mas 50 anos depois, ainda parecemos ver os mesmos tipos de problemas que sempre temos: entrega tardia, resultados insatisfatórios e falhas completas no projeto.

A razão pela qual desenvolvemos software é para atender às necessidades de algum cliente, cliente, usuário ou mercado. O objetivo da engenharia de software é tornar esse desenvolvimento previsível e econômico.

Já se passaram mais de 50 anos desde a primeira Conferência IFIP sobre Engenharia de Software, e nesse tempo houve muitas metodologias, processos e modelos diferentes de engenharia de software propostos para ajudar os desenvolvedores de software a alcançar esse processo previsível e econômico. Mas 50 anos depois, ainda parecemos ver os mesmos tipos de problemas que sempre temos: entrega tardia, resultados insatisfatórios e falhas completas no projeto.

Pegue um contrato do governo em que trabalhei anos atrás. É, sem dúvida, o projeto mais bem sucedido em que já trabalhei, pelo menos do ponto de vista das métricas habituais de gerenciamento de projetos: foi concluído mais cedo, foi concluído com orçamento, e completou um teste de aceitação programado em três dias.

Este projeto operava sob algumas restrições incomuns: o contrato era denominado e pago em moeda estrangeira e era absolutamente firme preço fixo, sem nenhum processo de gestão de mudanças no contrato. De fato, como parte do contrato, o teste de aceitação foi estabelecido como uma série de testes observáveis, do-this e isso-segue que poderiam ser verificados, sim ou não, com muito pouco espaço para disputa. Devido aos termos do contrato, todo o risco de qualquer variação nos requisitos ou nas taxas de câmbio estava na minha empresa.

O processo foi absolutamente, firmemente, a cachoeira clássica, e passamos pelas etapas com confiança, até que o sistema final foi concluído, entregue, e o teste de aceitação foi, bem, aceito.

Depois disso, passo mais 18 meses com o sistema, modificando-o até que ele realmente satisfaça as necessidades dos clientes.

No ano seguinte entre o contrato que está sendo assinado e o software sendo entregue, os formatos de relatórios mudaram, alguns componentes da plataforma de hardware foram substituídos por produtos novos e melhores, e foram feitas alterações regulatórias às quais o sistema deve responder.

Os requisitos mudam. Todos os projetos de engenharia de software enfrentarão esse problema difícil em algum momento.

Com isso em mente, todos os processos de desenvolvimento de software podem ser vistos como respostas diferentes a essa verdade essencial. O processo original (e ingênuo) da cachoeira simplesmente assumiu que você poderia começar com uma declaração firme dos requisitos a serem cumpridos.

W.W. Royce é creditado pela primeira vez observando a cachoeira em seu artigo "Gerenciando o Desenvolvimento de Grandes Sistemas de Software", e as ilustrações em centenas de artigos de engenharia de software, livros didáticos e artigos são reconhecidamente os diagramas que ele criou. Mas o que muitas vezes é esquecido no artigo original de Royce é que ele também diz que "[A] implementação [no diagrama] é arriscada e convida o fracasso". 

Combinando seu processo com seu ambiente

A observação de Royce — de que todo desenvolvimento passa por estágios reconhecíveis, desde identificar os requisitos e a solução proposta, através da construção do software e, em seguida, testá-lo para ver se satisfaz esses requisitos — foi uma boa. Na verdade, todos os programadores estão familiarizados com isso, mesmo em suas primeiras tarefas em sala de aula. Mas quando seus requisitos mudam ao longo da duração do projeto, você tem a garantia de que não será capaz de satisfazer o cliente mesmo se você satisfazer completamente os requisitos originais.

Na verdade, há apenas uma resposta para isso: você precisa encontrar uma maneira de corresponder ao ciclo de desenvolvimento-entrega de requisitos com a taxa em que os requisitos mudam. No caso do meu projeto governamental, fizemos isso artificialmente: não houve alterações de nenhuma substância, por isso foi simples construir para o teste de especificação e aceitação.

O artigo original de Royce reconheceu o problema das mudanças durante o desenvolvimento. Seu artigo descreve um modelo iterativo no qual mudanças inesperadas e decisões de design que não dão certo são alimentadas de volta através do processo de desenvolvimento.

Realismo no desenvolvimento de software

Uma vez que aceitamos a incerteza central em todo o desenvolvimento de software, que os requisitos nunca permanecem os mesmos ao longo do tempo, podemos começar a fazer o desenvolvimento de maneiras que possam lidar com as mudanças inevitáveis.

Comece aceitando que a mudança é inevitável. 

Qualquer projeto, não importa o quão bem planejado, resultará em algo que é pelo menos um pouco diferente do que foi imaginado pela primeira vez. Os processos de desenvolvimento devem aceitar isso e estar preparados para lidar com isso.

Como consequência disso, o software nunca é terminado, apenas abandonado.

Gostamos de fazer um ponto especial e nítido em que um projeto de desenvolvimento seja "concluído". A realidade, no entanto, é que qualquer tempo fixo em que dizemos "está feito" é apenas uma linha divisória artificial. Novos recursos, recursos revisados e correções de bugs começarão a chegar no momento em que o produto "acabado" for entregue. (Na verdade, haverá mudanças que ainda são necessárias, representando a dívida técnica e os requisitos diferidos, no exato momento em que o software é lançado.) Essas alterações continuarão enquanto o produto de software estiver sendo usado.

Isso significa que nenhum produto de software é exatamente, perfeitamente satisfatório. O desenvolvimento real do software é como atirar em um alvo em movimento — todas as várias variações aleatórias de pontaria, movimento do alvo, vento e vibração garantem que, embora você possa estar perto do alvo exato, você nunca alcançará a perfeição.

Fazendo nosso processo se adequar ao ambiente

Visto desta luz, o desenvolvimento de software pode parecer bastante deprimente, até mesmo sombrio. Parece que estamos dizendo que toda a noção de desenvolvimento previsível e econômico está perseguindo um sonho impossível.

Não, não é. Podemos ser desenvolvedores muito eficazes, desde que tenhamos as realidades em mente.

A primeira realidade é que, embora a perfeição seja impossível, o sucesso pragmático é bem possível. O movimento de startup LEAN tornou o MVP — "produto viável mínimo", o objetivo usual para as startups. Precisamos estender essa ideia a todo o desenvolvimento e reconhecer que cada produto é realmente um MVP — nossa melhor aproximação de uma solução para a compreensão atual do problema.

A segunda realidade é que não podemos realmente parar as mudanças nos requisitos, por isso precisamos trabalhar com as mudanças. Isso tem sido entendido há muito tempo no desenvolvimento real de software —a regra da Parnas para identificar módulos é construir módulos para ocultar requisitos que podem mudar. Ao mesmo tempo, tem havido repetidas tentativas de descrever processos de desenvolvimento de software que esperam fornecer aproximações sucessivas — processos de desenvolvimento incremental (eu o chamei de "A metodologia Uma e o Futuro").

Uma vez que aceitamos a necessidade de desenvolvimento incremental, uma vez que nos libertamos da noção de completar a solução perfeita, podemos aceitar mudanças com alguma confiança calma.

A terceira e última realidade é que todos os horários são realmente horários de tempo. Entramos em um projeto de desenvolvimento incapaz de dizer exatamente qual será o produto final. Por causa disso, nenhuma previsão antecipada de tempo para completar pode ser precisa, e todas as entregas finais serão entregas parciais.

Desenvolvimento ágil para o resgate

O Manifesto Ágil surgiu do reconhecimento desses fatos. A entrega regular de software de trabalho faz parte desse reconhecimento: um projeto verdadeiramente ágil tem implementações parciais funcionando regularmente. Relacionamentos próximos com o eventual cliente garantem que, à medida que as mudanças de requisitos se manifestem, eles podem se encaixar no plano de trabalho.

Em um projeto ágil, idealmente, há uma implementação parcial de trabalho começando muito cedo em um projeto, e progressos observáveis estão sendo feitos em direção a um produto satisfatório desde o início. Pense na metáfora do tiro ao alvo novamente — à medida que avançamos, estamos cada vez mais perto do anel central, o alvo. Podemos estar confiantes de que, quando o tempo acabar, o produto estará pelo menos perto do objetivo.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.