BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Aprendemos com a história? Ideias antigas mostram que não

Aprendemos com a história? Ideias antigas mostram que não

Favoritos

[Este texto foi adaptado e otimizado pela equipe editorial do InfoQ Brasil]

O autor e consultor Gerald M.Weinberg esteve envolvido ativamente com a indústria da computação durante mais de meio século; é uma figura reconhecida e reverenciada, que escreveu alguns dos livros mais influentes da área de informática.

Em seu blog Segredos da Consultoria, escreveu recentemente sobre a falta de atenção à história e sobre como parece se repetir o ciclo de modismos envolvendo inovações e avanços no nosso modo de trabalho – sem que as empresas e profissionais aprendam as lições dos ciclos anteriores.

Weinberg estava reformatando seu livro “Repensando a Análise e o Projeto de Sistemas” como um e-book e decidiu atualizar a seção “Além da Programação Estruturada”. Embora o texto tenha sido escrito há décadas, descobriu que bastaria substituir a frase “programação estruturada” por “Agile”, para que o conteúdo e a mensagem do texto se aplicassem a métodos ágeis:

Embora o artigo tenha sido escrito há uma geração e a “revolução” da programação ágil já tenha saído de moda para a maioria dos programadores, muitos dos pontos de que trata o artigo continuam válidos ainda hoje — e continuarão válidos quando surgir o próximo modismo de programação, e o próximo, e o próximo, pois, para não ficar entediada, nossa indústria parece precisar de um novo modismo a cada década. Portanto, ao ler este artigo, simplesmente aplique essas lições para qualquer que seja a moda dominante na mídia de computação atual.

Weinberg passa então a discutir sobre como muitas organizações adotam novas práticas de modo relapso e tentam seguir regras cegamente, ou adotam as práticas mais fáceis, sem seguir a disciplina exigida para se obter uma mudança eficaz. 

Segundo ele, quando os casos de adoção de métodos ágeis são examinados em detalhes, as organizações se enquadrariam nos seguintes níveis de eficácia:

a. Apenas 5% podem ser consideradas ágeis de ponta a ponta.

b. 20% seguem práticas ágeis com de forma suficiente para obter melhorias sobre o padrão médio de codificação da década de 90.

c. 50% apresentam evidências de tentativas de seguir algumas “regras ágeis”, mas não têm a compreensão dessas regras, obtendo pouco ou nenhum sucesso.

d. 25% não apresentam evidências de terem sido influenciadas por qualquer ideia referente à programação (não apenas pelos métodos ágeis) que tenha surgido nos últimos 20 anos .

Recomenda uma adoção cuidadosa e bem-pensada das práticas ágeis:

As organizações e indivíduos que tiveram sucesso em alcançar os benefícios prometidos pela programação ágil tendem a ser os que geralmente não são levados pelas tendências do momento em software ou hardware. São os que analisam o que está sendo oferecido e extraem aquilo que necessitam para resolver seus problemas. Pensam por conta própria, inclusive usando ideias de outras pessoas ou empresas, se forem apropriadas. Esses indíviduos e organizações foram, geralmente, os mais bem-sucedidas na solução de problemas antes da programação ágil, e têm ainda mais sucesso hoje.

Wenberg conclui a seção com um convite à ação, mas com prudência:

Nossa profissão nos oferece poucas oportunidades para soluções triviais. O sucesso na resolução de problemas vem para aqueles que acreditam pouco na “mágica” mais recente; que estão dispostos a experimentar ideias por si mesmos, ainda que estas ideias estejam perdidas em meio a um mar de afirmações vazias de equipes de marketing.

Com base neste aprendizado, proponho uma nova “religião da programação”, uma religião baseada nos seguintes mandamentos:

  • Não existe substituto genérico para um entendimento minucioso do seu problema. 
  • Não existe uma solução aplicável a todo tipo de problema. O que para um caso pode ser a melhor abordagem, em outros pode ser até mesmo a pior.
  • Existem muitas abordagens úteis e aplicáveis a mais de um tipo de problema; por isso é vantajoso familiarizar-se com o que já funcionou antes.
  • O segredo para a resolução de problemas não é apenas saber como fazer, e sim quando fazer. Isso permite que o método para solução seja adaptado ao problema, e não o inverso.
  • Não importa o quanto se sabe sobre como e quando fazer; alguns problemas não serão solucionáveis usando o conhecimento atual. E ninguém será capaz de compreender alguns aspectos do problema naquele momento. Portanto, a humildade é sempre recomendada.

Recorde que este artigo foi escrito originalmente vinte anos atrás, sobre o tema da programação estruturada, e que a única alteração realizada foi substituir o termo “programação estruturada” por “ágil” nois trechos citados. E a mensagem continua tão válida hoje quanto era em 1990.

Seguindo linha similar, Elisabeth Hendrickson publicou um artigo “Retrocesso em Agile? Ou chamada para rever a carreira?” em que discute (anti)padrões para a adoção de métodos ágeis que parecem estar se firmando na indústria:

O primeiro antipadrão (antipattern) envolve pessoas que se queimaram com uma versão deturpada dos “métodos ágeis”, apresentada por gerentes sem noção atuando em organizações disfuncionais. Com “sem noção”, quero dizer o tipo de gerente que acredita que o caminho para se encontrar um coach de Agile qualificado é encontrar alguém que possua uma certificação de Scrum Master, obtida depois de um curso de dois dias. Ou então, que acredita que, se for feita uma busca e substituição global, substituindo as palavras-chave na documentação de processos, isto seria suficiente para tornar a organização “ágil”, como nesses exemplos:

  • Fase -> Iteração
  • Gerente de Projeto  -> Scrum Master
  • Requisitos -> Histórias
  • Horas estimadas -> Pontos
  • Reunião de acompanhamento -> Stand-up meeting

Infelizmente, mas não há nada que possamos fazer para evitar essa banalização do termo Agile. Isto acontece com todo padrão, tecnologia, prática que vira a "expressão do momento", como ISO, CMM, CMMi, RUP, e tantos outros.

O segundo antipadrão é o que mais preocupa Hendrickson:

Há um segundo padrão de reação que acho ao mesmo tempo fascinante e perturbador. São reações que não parecem ser motivadas por um entendimento incorreto de Agile, mas sim por fortes críticas às práticas ágeis; por exemplo, reuniões stand up, programação em pares, equipes colaborativas, salas abertas para as equipes, entre outras.

Suspeito que algumas das pessoas que reagem assim sejam introvertidos, trabalhando em um ambiente de pessoas extrovertidas que assimilaram facilmente a natureza social das práticas ágeis. Pessoas introvertidas precisam de tempo sozinhas para o processamento de informações e ideias. Sem tempo suficiente para si mesmas durante o expediente, ficarão estafadas. Se esta descrição se parece com você, tenho esperança de que, em vez de julgar as práticas ágeis como maléficas, consiga trabalhar com sua equipe para atingir um equilíbrio adequado entre o tempo em colaboração e o tempo sozinho.

Ela destaca também o número de comportamentos antes aceitáveis que deixaram de ser aceitos em equipes ágeis, e como a maturidade emocional e social são aspectos importantes para as equipes de hoje.

Na verdade, a criação de um software, mesmo de baixa complexidade, é necessariamente uma atividade social, um esporte de equipe. Não é suficiente ser brilhante e nunca foi. Membros eficazes de uma equipe têm habilidades sociais. Escutam, colaboram, compartilham e contribuem.

Então, a indústria de computação aprendeu alguma coisa dos padrões recorrentes da história, ou estamos condenados a repetir o ciclo de modismos com toda nova ideia?

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT