Manifesto do século XX

No século XX tínhamos as 8 leis da evolução de software, criadas por Meir Lehman na década de 70, uma abordagem condizente à época, não falava de pessoas, detinha-se a uma abordagem técnica. Por 30 anos a Lei de Lehman esteve para o Software do século XX assim como a Lei de Moore esteve para o hardware (duplicação da densidade de transistores a cada 2 anos).

Somente no final do século XX algumas empresas e profissionais de software perceberam a necessidade de uma abordagem mais humana, o software deixou de ser algo restrito a grandes empresas, adquiriu relevância estratégica à todas as empresas e disseminou-se em todos os momento da vida das pessoas. Tornou-se mais interativo, envolvente e sofisticado, exigindo uma abordagem mais holística.

Século XX – As 8 Leis de Lehman sobre evolução de software

A Lei de Lehman é uma fonte histórica de bom senso em software, Meir Lehman nasceu na Alemanha e transferiu-se para a Inglaterra na década de 30, trabalhando na IBM entre 1964 e 1972. Em 74 publicou o que seria mundialmente conhecido como as “Leis de Lehman sobre evolução de software” para sistemas do tipo E ou E-Programs.

Sistemas do tipo E são os softwares desenvolvidos para resolver problemas do mundo real, operados por pessoas que se beneficiem deles em seu dia-a-dia. Seus primeiros estudos em sistemas para OS-360 ficaram conhecidos como “leis de Lehman” porque eram generalizáveis e aplicáveis a diferentes contextos na tomada de decisão, planejamento, desenvolvimento e manutenção de software.

1. Mudança contínua – Um software deve ser continuamente adaptado, senão torna-se aos poucos, cada vez menos satisfatório. A cada alteração no ambiente em que ele roda que exija nele melhorias, não fazê-las o tornarão progressivamente menos satisfatório naquilo para o que foi construído.

2. Complexidade crescente – Se não forem tomadas medidas para reduzir ou manter a complexidade de um software, conforme ele é alterado sua complexidade irá aumentar progressivamente. Deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.

3. Auto regulação – A curva pertinente ao processo de evolução de um software em relação a seus atributos e processos são auto reguláveis e próximos a uma curva normal, subindo até um teto, quando começa a diminuir.

4. Conservação da estabilidade organizacional – A velocidade de atividade global efetiva de um software em evolução deverá se manter invariável durante todo o ciclo de vida deste produto. O mix que é levado em consideração para as tomadas de decisão que levam a evolução de um software tendem a ser constantes.

5. Conservação de familiaridade – Durante a vida útil de um software em evolução, a taxa de mudanças tende a ser proporcional ao domínio que a equipe detém. A taxa de evolução de um software está intimamente ligado ao grau de familiaridade dentre os profissionais que o mantém.

6. Crescimento Contínuo – Todo software deve ter o conteúdo funcional continuamente ampliado durante seu ciclo de vida para manter a satisfação dos seus usuários. O projeto inicial não consegue incluir absolutamente tudo o necessário e progressivamente precisará ser aumentado.

7. Qualidade diminuindo – Os softwares desenvolvidos para resolver problemas do mundo real se depreciam progressivamente se eles não receberem as mudanças necessárias para adaptar-se ao que acontece em seu ambiente operacional durante todo o tempo de seu ciclo de vida útil.

8. Sistema de feedback – Os processos de manutenção e evolução de um software refletem sistemas de feedback em múltiplos níveis, loops e agentes e devem ser assim tratados para manter-se significativos.

Até hoje as Leis de Lehman são válidas, elas não deixaram de ser provocativas, por gerarem reflexão em pontos relevantes no que diz respeito a pontos de atenção relacionados ao planejamento, construção e manutenção de software no seu aspecto tático-técnico. Mas na década de 90 iniciaram experiências para trazer ao desenvolvimento de software princípios preconizados pela indústria automobilísticas no modelo Lean Toyota.

Século XXI – Manifesto Ágil para Desenvolvimento de Software

No início do século XXI foi promulgada a proposta de uma nova “Lei” sobre evolução de software, conhecido mundialmente como “Manifesto Ágil”. Um grupo de desenvolvedores e consultores que já vinham praticando novas formas de composição de times, técnicas de elicitação, interação, análise, desenvolvimento, testes e evolução reuniram-se em uma estação de esqui em Utah (USA) e também fizeram história.

Cada um dos signatários ou em grupos menores vinham praticando a uma década métodos informalmente chamados de “lightwave”, como Crystal Clear com Cockburn, Scrum com Schwaber, Shuterland e Beedle, XP com Fowler, Beck e Jeffries, Lean Thinking com Womack e Jones, DSDM com Bennekun, FDD com De Luca e Coad, ASD com Cockburn e Highsmith, The Pragmatic Programmer com Hunt e Thomas.

O Manifesto dizia: “Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:”

• Indivíduos e interação entre eles mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, deveríamos valorizar mais os itens à esquerda. O manifesto ágil continha 12 princípios ágeis, que devem ser entendidos e trabalhados para o seu sucesso, a saber:

• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor;
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas;
• Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos;
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto;
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho;
• O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara;
• Software funcional é a medida primária de progresso;
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes;
• Contínua atenção à excelência técnica e bom design, aumenta a agilidade;
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito;
• As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis;
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

As Leis do século XX são mais genéricas que o Manifesto do século XXI, pois enquanto o primeiro apontava para pontos que tornaram-se consenso sob o aspecto técnico no desenvolvimento de software, o segundo propõe uma abordagem menos industrial ou menos comando-controle, uma abordagem sócio-técnica em que um bom artefato técnico é consequência da interação humana que o cria e mantém.

Enquanto as Leis de Lehman relatavam uma percepção técnica objetiva e prática, racional, o Manifesto Ágil sugere uma grande quebra de paradigma, para praticá-lo é preciso implementar um processo de mudança cultural onde o centro não é o artefato e as tarefas, mas a mobilização das pessoas para em conjunto e com técnicas apropriadas desenvolverem a melhor solução possível.

É bom ter opções e o primeiro passo para a tomada de decisão é o conhecimento!

Fonte: https://www.baguete.com.br/colunas/jorge-horacio-audy/17/04/2014/as-8-leis-de-lehman-foram-o-manifesto-do-seculo-xx Acesso em: 07/09/2022 às 12:37 e https://technbiz.eximia.co/as-leis-de-lehman/ 07/09/2022 às 12:53