Sobre Estimativas de Software
Publicado em
Com certeza há muito assunto e trabalho sobre estimativas em desenvolvimento de software. Esteja você em uma grande empresa, uma pequena agência ou o famoso projeto com o “exército de um homem só”, a ideia de que você possa prever quanto tempo levará para construir um sistema é amplamente difundida e adotada por todos.
Qualquer princípio de gestão ou cronograma de projeto tem isso como um mínimo para operar. Isso é útil para que você possa planejar com antecedência e lidar com os projetos em uma ordem sã, evitando armadilhas óbvias e erros de negócios.
Editado 17/05/2025: disponibilizei um spring boot starter usando JPA para ter um mecanismo de eleição de lider. Clique aqui Editado 17/10/2024: se você procura um mecanismo real de lock para jobs, a melhor opção é Shedlock
Alerta: post técnico a frente. Tire as crianças da sala!
O framework Spring Boot tomou de assalto o mercado nos últimos anos. Spring, desde antes, com o MVC já havia absorvido a maior parte de vagas de emprego e questões online, mas com a simplicidade do Boot, praticamente definiu o novo padrão para frameworks em linguagem Java.
Então, tem essa coisa sobre o seu sistema.
Ele nasceu para morrer.
Estou falando mais especificamente sobre sistemas web, porque essa é a minha área de atuação, mas é válido para várias áreas de desenvolvimento de software. Os sistemas são criados para serem destruídos a longo prazo. E tudo bem.
Vou me explicar.
Se você já trabalhou em algum grande projeto, ou por alguns anos em uma empresa, já viu o que as pessoas chamam de código legado.
A nem tanto tempo atrás assim, o Orkut era a principal rede social. Todo mundo usou, todo mundo adorou. Acredito que foi a primeira rede social “real” massivamente popular aqui no Brasil e não havia sinais de que, poucos anos depois, seria substituída pelo Facebook.
Quando lançado, o primeiro iPhone revolucionou a indústria de smartphones. Era algo novo, todo mundo adorou, todo mundo comprou um. Hoje o Android tem uma participação de mercado maior (falando especificamente sobre o número de dispositivos).
Quando comecei minha carreira eu não entendia bem o conceito de me fixar a uma única linguagem/tecnologia. Sempre me pareceu errado fazer isso porque você precisa “usar a ferramenta certa para o trabalho” e " se não se parece com um prego, não use um martelo “, mas hoje acho que, como sempre, a realidade é um pouco mais complexa.
Eu ainda acredito que, como desenvolvedor, sou mais capaz e produtivo aprendendo cada vez mais linguagens/plataformas/ferramentas/frameworks/etc.