Ágil, Scrum, palavras sofisticadas para escrever software que entrega
Não importa como você olhe, em termos gerais, os desenvolvedores de software de aplicativos de negócios têm uma má reputação. Os sistemas são quase inevitavelmente entregues com atraso ou até mesmo não são entregues. O usuário médio de uma empresa média passa literalmente horas todas as semanas reclamando dos sistemas de computador que é forçado a suportar. “Por que isso foi feito?”, “O que diabos isso significa?” são algumas das coisas que ouço diariamente.
Passei anos escrevendo sistemas de negócios, na maioria dos casos os usuários eram positivos sobre o que estavam obtendo e usando. Sistemas escritos de acordo com uma especificação inicial, testados até o fim e depois adaptados como e quando necessário, a um custo acordado, se necessário. Suporte contínuo ao cliente e receita sustentada para a empresa de software foi uma combinação vencedora. A especificação inicial baseada em uma análise detalhada de requisitos seria sempre uma visão geral funcional e não conteria nenhuma especificação de código. Acho que usei pseudocódigo uma vez (quando estava escrevendo jogos). “É isso que precisamos fazer”, geralmente era bom o suficiente para mim. Fora isso, foram alguns modelos de interface de usuário e muito design de banco de dados e pronto. A fase de testes e ajustes do ciclo de vida de desenvolvimento foi muito importante. Os sistemas geralmente foram entregues no prazo e funcionaram.
Hoje em dia (nunca pensei que diria isso), tudo relacionado a sistemas é uma questão de planejamento, mais planejamento e depois reutilização. O que me parece tão estranho é que grande parte desse planejamento não visa atender a um requisito funcional, mas sim detalhar como e por que escreveremos o que escrevemos quando o escrevemos. Espero que isso faça sentido? Por que escrever algo em 10 linhas que você poderia fazer em 1000, na hipótese de “poder” precisar reutilizá-lo 2 anos depois? A nível pessoal, nunca escrevi nada que não pudesse reescrever melhor dois anos depois. Estou sempre aprendendo e melhorando, quando olho para o código com 12 meses de idade, muitas vezes me encolho. Olhando anúncios de emprego é fácil perder-se nas metodologias e competências que são solicitadas. Será humanamente possível que uma pessoa saiba tanto que muitas vezes me pergunto? Outra questão é: eles alguma vez produzem um produto? Com todo esse planejamento e preocupação com a reutilização de código, alguma coisa é feita? Conheço uma empresa que contratou desenvolvedores acadêmicos que estavam tão ocupados concentrando-se no design que a empresa faliu antes que qualquer produto estivesse quase pronto, sério! Quantos atrasos podemos esperar que as pessoas tolerem, a fase de testes nunca foi um problema lá! Por que a empresa que nos paga por um produto deveria pagar pelo código que será usado repetidamente em projetos posteriores, e não por eles?
Não me interpretem mal, não estou dizendo que o planejamento seja ruim, é uma parte essencial do desenvolvimento de sistemas, mas não é a única. Talvez eu seja da velha escola, mas a parte que gosto é escrever o sistema e fazê-lo funcionar. Ok, eu sei que os sistemas estão ficando cada vez maiores e mais complexos. Grandes equipes de desenvolvedores são a norma. É que eu acho que por mais que você planeje, visualize e faça um brainstorming algo sempre vai faltar. Estamos nos esforçando para alcançar sistemas impossíveis e perfeitos, mas, nos piores casos, não estamos entregando nenhum sistema. Não acredite em mim? Veja a Microsoft. Imagine as horas de trabalho gastas no planejamento de qualquer uma de suas aplicações? Com que frequência um novo bug ou vulnerabilidade é descoberto? Por que eles não foram discutidos na fase de design? Nunca passou pela cabeça da equipe de desenvolvimento que a “vulnerabilidade X” pudesse ocorrer. Simplificando, com qualquer coisa além do mais básico dos sistemas, é quase impossível planejar todas as eventualidades, não importa quão lógico você seja. Por que eles não são encontrados durante os testes? A solução aqui é o desenvolvimento da velha escola, menos tempo planejando (conversando), mais tempo escrevendo e testando? Menos tempo se preocupando em reutilizar o código e mais tempo fornecendo ao cliente um produto funcional? A Microsoft seria melhor ou pior se gastasse menos tempo planejando e mais tempo testando? Em defesa da Microsoft, eles são muito bons em patches, suponho que eles poderiam ser vistos como nós como testadores. Talvez se eles passassem mais tempo fazendo testes adequados, não precisaríamos testá-los?
O pior exemplo de planejamento excessivo que ainda não encontrei é um sistema financeiro que uso diariamente. A implementação deste sistema custou milhões de dólares, anos de planejamento e sabe-se lá quantos consultores. Foi escrito por um dos maiores players da indústria de software, adaptado por uma consultoria especializada em software. O resultado final disso é um sistema que é praticamente inutilizável e não está muito longe de ser substituído por um produto de prateleira. É tão ruim no nível mais baixo que mesmo um clique errado do mouse travará o aplicativo. Não posso acreditar que este sistema tenha sido testado antes de ser entregue. A entrega demorou muito para ser entregue, devido ao “ciclo de planejamento” mais longo do que o esperado. O que faz não é assim tão complexo, apenas foi obviamente planeado ao ponto de a implementação ter sido pensada às pressas. Todo esse planejamento nem sequer resultou em um sistema que atendesse aos requisitos funcionais básicos de seus usuários, mas, heh, tenho certeza de que eles reutilizarão esse código em algum momento no futuro.
De qualquer forma, acabei de começar um diploma para me ajudar a entender por que é tão importante usar diversas estratégias de planejamento diferentes. Por que escrever em 1 dia o que eu poderia passar um mês fazendo “corretamente”? Eu sei que vou ler isso daqui a alguns anos e me pergunto o que estava pensando; ou isso ou direi para mim mesmo “nossa, foi quando eu realmente terminei o que estava escrevendo”. Sério, tenho certeza que no final perceberei onde estou errando, enquanto isso continuarei escrevendo aplicativos usando meu estilo RAD (ainda bem que ele tem um nome!) que embora não seja do gosto de todos, funciona muito bem para mim.
nb Quem poderia imaginar que minha abordagem de desenvolvimento tem um nome, é classificada como uma Metodologia Ágil! Aqui está um excelente artigo que explica Metodologias ágeis com algum detalhe.