As Leis de Lehman são um conjunto de princípios que descrevem a evolução da Engenharia de Software. Elas foram desenvolvidas por Meir Lehman e László Bélyády na década de 1970, sendo consideradas um dos fundamentos da área.
Entretanto, com a evolução do mercado de software e a criação novas abordagens complementares como os Métodos Ágeis, as Leis de Lehman foram quase totalmente esquecidas pelos profissionais da área. Mas será que elas ainda têm alguma importância e podem trazer benefícios ao Desenvolvimento de Software?.
Vamos descobrir. Continue sua leitura!
As Leis de Lehman: um pioneirismo no século 20
As 8 Leis de Lehman emergiram da necessidade de definir padrões para uma área que se adapta e evolui conforme as demandas e transformações do mundo.
Entretanto, quando Meir Lehman as estabeleceu, sua abordagem predominantemente técnica não considerava os aspectos humanos da tecnologia.
Com o posterior avanço da área para outras camadas sociais, e o crescimento de soluções tecnológicas em diversos setores empresariais, a visão de software se voltou ao fator humano, com uma abordagem cada vez mais holística e interativa.
Essa visão contemporânea, no entanto, não foi suficiente para excluir a importância das Leis de Lehman, principalmente considerando seu contexto histórico. Elas foram pioneiras na expansão e evolução da complexidade de Desenvolvimento de Software, permitindo que a área continuasse a ser relevante e satisfatória ao longo do tempo.
Quais são as 8 Leis de Lehman?
As Leis Lehman oferecem uma estrutura robusta para entender a complexidade e a natureza evolutiva do software. Ao reconhecer e compreender essas leis, os times de desenvolvimento estão melhor equipados para navegar pelos desafios e incertezas inerentes ao ciclo de vida dos sistemas. São elas:
1. Mudança contínua:
Um software precisa se adaptar continuamente. Se não se adaptar, sua utilidade e satisfação diminuirão com o tempo, à medida que o ambiente e as necessidades dos usuários evoluem.
Um sistema operacional, como o Windows ou o macOS, por exemplo, precisa ser constantemente atualizado com novos recursos e correções de bugs para atender às mudanças nas necessidades dos usuários e nas tecnologias disponíveis.
Leia mais:
- Como contratar flutter: guia completo para empresas e recrutadores
- Por que contratar um MSP para Cloud?
- Desenvolvimento de MVP: uma estratégia eficaz para novos produtos
- Cloud e DevOps: entenda os benefícios e desafios de integrar as estratégias
- Migrar Google Cloud para AWS: como fazer uma transição sem complicações
2. Complexidade crescente:
Com cada alteração em um software, sua complexidade tende a aumentar, a menos que esforços específicos sejam feitos para contrabalançar esse crescimento. Isso pode levar a um aumento nos custos de manutenção e desenvolvimento ao longo do tempo.
Por exemplo, um sistema de gerenciamento de relacionamento com clientes (CRM) é projetado para atender às necessidades de uma ampla gama de clientes. À medida que o sistema é ampliado para atender a mais clientes, sua complexidade aumenta. Deve-se conter ou manter esse nível de complexidade, trabalhando em melhorias simultâneas que solucionem problemas.
3. Autorregulação:
A evolução de software tende a ser autorregulada, seguindo padrões previsíveis e comportamentos disciplinados, principalmente quando há controles estabelecidos para garantir a conformidade com objetivos organizacionais mais amplos.
Exemplos disso são evoluções de software desencadeadas por fatores externos, como as mudanças nas necessidades dos usuários ou nas tecnologias disponíveis. Há ainda a evolução influenciada por fatores internos, como a arquitetura do sistema e a cultura da organização que o desenvolve.
4. Conservação da estabilidade organizacional:
Contrário às expectativas, a atividade global em um software em evolução tende a se estabilizar em um nível constante ao longo do tempo, determinado mais pelas necessidades dos usuários do que por decisões gerenciais isoladas.
Por exemplo, a equipe de desenvolvimento de software pode ser alterada ao longo do tempo, mas a quantidade de esforço necessária para manter o sistema funcional permanece relativamente estável. Isso ocorre porque a equipe nova deve aprender com a equipe anterior e adotar as práticas e padrões estabelecidos.
5. Conservação da familiaridade:
Mudanças excessivas em um software podem diminuir a familiaridade da equipe com os objetivos do projeto, afetando a eficiência e a eficácia. A taxa de mudança deve ser gerenciada para manter a coesão e a compreensão entre os membros da equipe.
Essa familiaridade facilita o desenvolvimento e a manutenção do sistema. Quanto maior a compreensão da equipe sobre a estrutura e a evolução gradativa de um software, mais propriedade ela tem sobre seu funcionamento.
6. Crescimento contínuo:
Para manter a satisfação do usuário, o conteúdo funcional de um software precisa ser constantemente expandido ao longo de sua vida útil, seja por adições, correções ou melhorias.
Um aplicativo de mídia social precisa ser constantemente atualizado com novos recursos e conteúdo, por exemplo, para se manter satisfazendo as necessidades dos usuários, que mudam continuamente.
7. Qualidade decrescente:
Sem uma manutenção e adaptação rigorosas às mudanças no ambiente operacional, a qualidade do software tende a declinar ao longo do tempo, à medida que as expectativas dos usuários e as demandas do mercado evoluem.
Um software que não é mantido adequadamente pode se tornar vulnerável a ataques de segurança, por exemplo. Isso põe usuários em risco e a própria manutenção da solução.
8. Sistema de retorno:
O Desenvolvimento de Software é um processo cíclico de feedback, onde cada versão gera novas informações e ajustes. O fracasso em adaptar-se a esse feedback pode levar ao desuso e à substituição do software.
Exemplos disso é como os dados de uso do software são coletados e analisados para identificar áreas que podem ser melhoradas. Essa análise é usada para orientar a evolução do software.
O surgimento do Método Ágil
O Método Ágil, que revolucionou como as equipes desenvolvem software trabalham, surgiu oficialmente no início do século 21. A necessidade de uma abordagem mais adaptável, colaborativa e centrada no cliente levou à formulação do Manifesto Ágil em 2001, durante uma reunião de dezessete desenvolvedores de software em Utah, nos Estados Unidos.
Esse manifesto foi uma resposta às limitações percebidas nas metodologias tradicionais de Desenvolvimento de Software, que eram frequentemente rígidas, excessivamente técnicas, burocráticas e não se adaptavam bem às mudanças rápidas do mercado e às necessidades dos clientes. Entre elas, as Leis de Lehman.
Enquanto Meir criou um uma abordagem que focou-se em regras técnicas, o Manifesto Ágil criou formas menos rígidas de avaliar e evoluir no Desenvolvimento de Software, considerando fatores mais complexos e abstratos como comportamentos e experiência do usuário.
Isso significa que as Leis de Lehman não devem ser consideradas hoje? Não necessariamente. Para ambientes de desenvolvimento mais focados em sustentação e evolução, as 8 Leis servem como boas práticas a serem seguidas, ainda que com olhar crítico. Compreender a sua limitação é também uma forma de utilizar o melhor delas e adaptá-las a cada contexto.
Agora, em ambientes mais dinâmicos, de criação de novas soluções digitais que tem como fim o encantamento do usuário, sem dúvida os Métodos Ágeis tem melhor adequação. Portanto, se quiser saber mais sobre o tema, leia nosso artigo completo!
