Olá, pessoal!
Recentemente acompanhei uma discussão no LinkedIn que trazia o seguinte enunciado: “Como sabemos se uma empresa é escalável e sustentável?”. Apesar de interessante, poucas respostas foram postadas e os membros não chegaram a um consenso unânime.
Diante dessa dúvida, decidi elaborar um artigo com a minha perspectiva sobre o assunto e, talvez, contribuir com a base de conhecimento de profissionais ágeis. Acompanhe-me!
Para compreender melhor o contexto do artigo, vale esclarecer as definições dos termos “sustentável” e “escalável”, e os motivos que os fazem importantes em uma empresa de desenvolvimento.
O termo “sustentável”, assim como utilizado na área de meio ambiente, refere-se à capacidade de manter um software com uma arquitetura bem definida, com componentes reutilizáveis e códigos-fonte de fácil manutenção para não comprometer o ciclo de vida futuro do projeto. Ao contrário do que alguns inferem, sustentabilidade não significa construir um software com uma taxa inexistente de erros. Atividades de correção sempre serão necessárias, naturalmente. No entanto, a diferença é que um projeto sustentável facilita a correção de erros com um mínimo (ou nenhum) impacto paralelo. Quando um novo incidente é encontrado no software, tanto o rastreamento quanto a correção devem ser factíveis, utilizando o menor tempo possível e o menor número de pessoas envolvidas.
Escalabilidade, por sua vez, está relacionada com o nível de maturidade e coordenação de uma empresa durante a evolução do projeto. É uma questão técnica e administrativa. Assim como a arquitetura do software deve estar sempre disponível para “receber” novas funcionalidades, as equipes e a gerência também devem estar “preparadas” para desenvolvê-las. Em outras palavras, à medida que o software cresce, em dimensão e em número de usuários, a empresa deve oportunizar o recrutamento e integração de novos programadores, como também manter o projeto ampliável.
Pois bem, leitores, alcançar níveis satisfatórios de sustentabilidade e escalabilidade, como sabemos, não é algo trivial. Todavia, há algumas orientações que podem colaborar para a busca dessas características.
No quesito sustentabilidade, continuo batendo na mesma tecla: Engenharia de Software. Um projeto só se torna sustentável quando apresenta práticas dessa disciplina, como os princípios SOLID, criação de bibliotecas de código reaproveitáveis e muita, muita Orientação a Objetos, em conjunto, claro, com as diretrizes de Clean Code. Código sustentável é sinônimo de código de fácil manutenção.
É muita coisa? Calma! Utilizar todas essas práticas de uma só vez nos levará à frustração. O segredo é empregá-las gradativamente, como uma forma de melhoria contínua. Opa, melhoria contínua? Sim, para quem se recorda, esse é um ponto importante mencionado no Lean Thinking! A arquitetura do código só pode ser mantida por desenvolvedores com uma boa bagagem de conhecimento em Engenharia de Software, cada vez mais capacitados para aplicar princípios, buscar a alta coesão e empregar Design Patterns. Se esse conhecimento ainda não existe, forneça-o por meio de cursos, treinamentos, Kata e Kaizen e Coding Dojos.
Agora, não venha me dizer que a empresa “não tem tempo” para fornecer essa capacitação. O que é melhor: Alocar um tempo para capacitá-los ou conviver com a falta de sustentabilidade durante todo o ciclo de vida do projeto? Capacitá-los ou contratar o dobro de programadores para lidar com uma arquitetura gradualmente deteriorada?
Se o objetivo é atingir um nível adequado de sustentabilidade, talvez o ponto de partida seja uma evidente transformação na cultura da empresa. Em seguida, iniciar aprimoramentos arquiteturais, como a padronização de código, criação e divisão de classes, limpeza de código e aplicação de padrões de projeto, sempre priorizando a melhoria contínua. Alguns recursos também são bastante úteis para essa finalidade, como revisores de código, métricas e profilers. Por experiência própria, eu garanto um resultado positivo desse processo.
Por sua vez, a escalabilidade, como disse anteriormente, é dividida em questões técnicas e administrativas. O aspecto técnico é relacionado primariamente com a possibilidade de evoluir o software sem impactos consideráveis no código já existente e funcional. A arquitetura deve disponibilizar APIs, bibliotecas e classes-base para extensão do software, como uma ramificação de funcionalidades. Isso nos faz lembrar do princípioOpen/Closed do SOLID! 🙂
Sobre a questão administrativa, me refiro, em especial, ao gerenciamento de equipes em empresas que utilizam metodologias ágeis. Diga-se passagem, são muitas! Embora o Scrum forneça um framework eficiente para a gestão de equipes, essa metodologia, por si só, infelizmente não é escalável. Por exemplo, é nitidamente inviável conduzir reuniões de planejamento, reuniões diárias e retrospectivas em uma equipe de 100 desenvolvedores, sem falar no controle do Task Board e definição de papéis.
Como solução, podemos dividir os desenvolvedores em várias equipes ágeis distintas, certo? Sim, isso já é um indício de escalabilidade! Porém, antes mesmo de “escalarmos” as equipes, é importante mencionar que já existe um framework exclusivo para esse propósito, chamado Scaled Agile Framework (SAFe), elaborado por Dean Leffingwell. O SAFe aborda a maioria das questões de escalabilidade um uma empresa de grande porte, desde os objetivos de negócio até o desenvolvimento de funcionalidades por múltiplas equipes ágeis. Com este framework (e outros semelhantes, como o Large-Scale Scrum), a escalabilidade vai de encontro com o Desenvolvimento Ágil, produzindo células de trabalho de alta performance.
Até a próxima!
