Afinal, o que é essencialismo na engenharia de software? Como esse conceito impacta na rotina de profissionais da área? Quais os benefícios que pode trazer para as entregas? Conheça mais sobre a metodologia do essencialismo no artigo de hoje!
Bem, no ano passado, gostei de ler um livro novo e provocativo que explora uma nova maneira de pensar não apenas sobre alguns aspectos da vida, mas sobre tudo. Essentialism: The Disciplined Pursuit of Less, de Greg McKeown, traz essa nova perspectiva, mas será que está certo? Podemos aplicá-lo ao desenvolvimento de software? A resposta curta é sim!
Quando falamos em engenharia de software, ela pode ter várias abordagens e definições. Este post usará o meu livro favorito, Modern Software Engineering de Dave Farley, que diz: “Engenharia de software é a aplicação de uma abordagem empírica e científica para encontrar soluções eficientes e econômicas para problemas práticos de software”.
Onde a eficiência não é uma parte opcional do processo de desenvolvimento de software e, quando falamos de eficiência, incluímos também evitar o desperdício de diversos recursos como computadores poderosos e o tempo das pessoas.
É aí que o essencialismo ajuda no processo, principalmente porque parte de três princípios básicos:
- Escolha individual: podemos escolher como gastar nossa energia e tempo;
- A prevalência do ruído: quase tudo é ruído e muitas poucas coisas são preciosas;
- A realidade dos trade-offs: não podemos ter tudo ou fazer tudo.
Complicou? Vamos dar um passo para trás e falar sobre os inimigos do bom desenvolvimento de software.
Obstáculos ao processo de software
No ano passado, a Forbes enumerou 16 obstáculos para a criação de um software promissor, destacamos alguns a seguir:
- Planejamento e design hiperfocados;
- Expectativas de clientes pouco claras ou indefinidas;
- Negligenciar requisitos não funcionais;
- Não alinhar desde o início os “must-haves”.
Parece um problema paradoxal? Como podemos gastar tanto tempo planejando algo que não entendemos? Estamos colocando energia em algo que não nos ajuda a resolver o problema ou a impulsionar o alvo certo.
Essa é a questão número um: como gastar tempo e energia no problema correto e no que importa. É aí que o desenvolvimento de software precisa de essencialismo. Precisamos encontrar o ponto mais alto de contribuição: a interseção da coisa certa, do tempo e da razão.
Clareza faz parte do processo de sucesso do arquivo no desenvolvimento de software e o poder de escolha é fundamental para isso, é uma ação que define onde você vai colocar a sua energia. A otimização dessas opções pode ajudar a se aproximar do objetivo.
A ação de escolha é rigorosa, principalmente porque precisamos refletir mais sobre quando dizemos “sim” ou “não”. Esse foi um dos pontos mais desafiadores da minha vida, inicialmente relacionei o “sim” com oportunidades abertas como o filme Yes Man.
É uma batalha entre o medo de perder (FOMO) e o foco. Isso pode afetar você também. Por isso, recomendo experimentar e ver se você é como eu, que o “não” te dá liberdade. Novamente, não é fácil. Eu ainda luto contra isso, mas acho necessário – na verdade, essencial.
Como engenheiro de software, às vezes dizer “não” inclui evitar a tecnologia mais nova do mercado, pois essa aliada pode se tornar uma inimiga e complicar as coisas mais do que o necessário.
O essencialismo está dizendo “não” a muitas coisas, incluindo a superengenharia
Quando comparamos as ferramentas de desenvolvimento de software com 10 anos atrás, temos muitas opções que supostamente facilitam nossa vida, incluindo metodologias, frameworks e ferramentas como Kubernetes, microsserviços, etc.
Mas por que eu uso a palavra “supostamente”? Com muitas ferramentas, são oferecidas opções que tornam nossa vida mais difícil e explorar a ferramenta errada torna as coisas mais complexas (consulte “A complexidade está matando os desenvolvedores de software”, de Scott Carey).
No desenvolvimento de software não há bala de prata. Portanto, não há problema em usar microsserviços, Kubernetes e arquitetura de modelo hexagonal e uniforme o tempo todo.
Quando falamos em microsserviços, só é possível pensar nos dois livros sobre o tema de Sam Newman, mas até ele escreveu “Devo usar microsserviços?”, onde ele não recomenda o uso em novos produtos.
Como estamos falando sobre microsserviços e overengineering, temos um Zup Insights que pode ser interessante para você. Assista:
O tema aqui não é culpar novas tendências ou tecnologias, que são incríveis e ajudam na hora certa. A primeira questão é quão longe eles estão de nossos objetivos. O essencialismo pode nos ajudar a fazer isso com simplicidade.
As necessidades básicas
Quando falamos sobre decisões e design de software, pensamos em arquitetura de software que possui duas leis:
- O porquê é mais importante do que o como;
- Tudo tem compensações.
Depois de encontrar o objetivo e onde deseja colocar a sua energia e a de sua equipe, a simplicidade pode ajudar a diminuir o risco desnecessário do desenvolvimento de software. Não sou contra a inovação, adoro, mas explorar a ferramenta errada pode te impactar e levar à falha.
Começar a não usar essas tecnologias novas e sofisticadas e explorar maneiras mais diretas e rápidas, como monólito ou não usar o Kubernetes, pode ser uma boa solução para o começo.
Ser adaptativo é a parte fundamental do processo Agile e o software em produção faz parte disso. Lembre-se: não começar com microsserviços não significa não usá-los em breve, você pode explorá-los quando necessário. Isso também acontece com o modelo hexagonal. Você precisa de todas essas camadas para começar? Vamos começar com três, como um MVC.
Começar simples e evoluir seu software e arquitetura faz parte da arquitetura evolutiva. O software precisa ser adaptável e não ver o futuro.
Em resumo, olhar para as necessidades básicas, como diria a música do Balu, é uma boa escolha para sua arquitetura de software. Exploramos a decisão, mas em relação às metodologias também temos interações humanas, que incluem reuniões, por exemplo. Esse é exatamente o próximo tópico!
Dizendo “Hasta la Vista, Baby” para reuniões intermináveis
Quando falamos de desenvolvimento de software, precisamos incluir o recurso que mais vale a pena, principalmente porque não podemos recuperar o tempo quando o desperdiçamos.
Quando falamos de tempo, por um lado, temos uma superengenharia; do outro, reuniões, reuniões e mais reuniões. Devemos lembrar que é um grupo de pessoas parando suas atividades e deixando de fazer suas entregas.
Por essa razão, quero compartilhar boas práticas de reuniões que podem ajudar muito no seu dia a dia:
- economize tempo das pessoas certificando-se de que os pré-requisitos da reunião estejam na descrição do convite;
- explore as notas disponíveis no evento para registrar as decisões mais importantes;
- atente-se ao horário das sessões, não extrapole o horário combinado e nem preencha um turno do dia com inúmeras reuniões;
- valorize a comunicação assíncrona, repense se aquela reunião não poderia ser um e-mail ou uma mensagem no chat.
Lembre-se que existe a Lei de Parkinson, que diz que o trabalho se expandirá para preencher o tempo alocado para sua conclusão.
Resumo
Quando falamos de desenvolvimento de software, garantir que você esteja fazendo a coisa certa na hora certa é crucial para a entrega. O essencialismo é um grande parceiro para fazer acontecer, principalmente porque diminui a chance de superengenharia, reuniões intermináveis e desperdícios.
Mesmo categorizado como um livro não relacionado a TI, “Essentialism: The Disciplined Pursuit of Less” ajuda a fornecer orientações para atender à simplicidade e confiar mais no que uma solução descomplicada funciona, uma vez que um software suave é um software com menos risco de ser mal-entendido e se torna um código legado mais rapidamente do que o habitual. Espero que gostem do livro tanto quanto eu!
Gostou do artigo sobre Essencialismo na engenharia de software? Continue acompanhando nossos conteúdos aqui pelo blog, nosso canal no YouTube e newsletter. Falando nisso, inscreva-se para receber nossos e-mails na sua caixa de entrada!
