Da perseguição às tentativas de hacking, desde que comecei a pesquisar a de projetos Agile e iniciativas de transformação, fiquei cara a cara com o fundamentalismo que existe entre os seguidores mais devotos do Agile. alta taxa de fracasso Quando os pacientes vulneráveis de um curandeiro sucumbem a uma doença como resultado de um tratamento falso que não funciona (tendo geralmente “doado” uma quantia considerável de dinheiro), o “curandeiro” muitas vezes alegará que a culpa é do paciente, pois eles não oraram muito suficiente. Este foi um tópico explorado extensamente por Derren Brown no especial de TV e teatralmente em seu especial da Netflix, . Tal falácia é frequentemente descrita como uma versão da falácia “ ” ou um “ ”. Miracles for Sale Miracle Nenhum escocês verdadeiro apelo à pureza Os fundamentalistas da comunidade Ágil costumam usar afirmações semelhantes quando os projetos Ágeis falham. Por exemplo, no artigo “ “, Greg Kihlstrom escreve: Failing at Agile? Você está fazendo errado Por exemplo, você poderia ter o Scrum Master mais entusiasmado possível em sua equipe, mas se a equipe de produto tiver alguns pessimistas ou aqueles que simplesmente não seguem ou entendem o que precisa ser feito, você terá desafios. Às vezes é uma questão de educação ou coaching, e às vezes é uma questão de dinâmica e cultura da equipe. Determine qual é a causa e lide com ela de acordo. No entanto, a base científica para tal crença não existe. Um artigo de novembro de 2021 intitulado ' ' conduziu uma meta-análise de inúmeras revisões de estudos científicos Ágeis e descobriu: “O resultado do estudo terciário é que, de fato, a evidência para o A metodologia ágil é, na melhor das hipóteses, escassa.” “Melhores Práticas” sem Evidência – Metodologia Ágil de Software como Exemplo Contudo, este está longe de ser o único viés cognitivo adotado por aqueles que assumem uma postura fundamentalista quando o assunto é Agile. Neste artigo, gostaria de focar nos espantalhos que são frequentemente usados para justificar a metodologia Ágil. O que é um espantalho ágil? Na comunidade Agile do LinkedIn, não é incomum ver postagens como as seguintes - aparentemente uma conversa que faz um praticante Agile parecer perspicaz e defender a metodologia diante de um engenheiro de software que ousa questioná-la. É minha opinião pessoal que essas conversas parecem geralmente fictícias: O Oxford English Dictionary fornece o seguinte como definição de espantalho: Em uma discussão, debate, etc.: uma proposição intencionalmente fraca ou deturpada, criada porque é mais fácil de derrotar ou desvia a atenção do argumento real de um oponente, dando a impressão superficial de que a acusação original foi refutada ou derrotada . No entanto, existem espantalhos muito mais enraizados que parecem ir ao cerne da proposta Ágil. Um artigo no site SecretGeek levantou a questão: “ ”. Embora o autor tenha afirmado que os outros elementos dogmáticos do Agile estavam de fato em vigor, desde os rituais até a doutrina, a única área sobre a qual eles estavam em dúvida era se havia uma “mitologia” no Agile. 'Agile' é uma religião? (ou apenas um culto) Acredito que esses espantalhos são fundamentalmente o que forma a mitologia do Agile. O mito da cachoeira É difícil ver o Agile discutido sem a discussão do Waterfall. Uma suposta metodologia de gerenciamento de projetos com a qual o Agile contrasta. Uma metodologia que requer etapas rigorosamente documentadas e nunca fazendo alterações. No entanto, isso levanta a questão: onde estão as conferências ou grupos de usuários em cascata, mesmo historicamente? Talvez as origens da metodologia nos forneçam algumas pistas. Nas de Jon Pearce na San Jose State University, ele afirma: “ ” notas de palestra O modelo de ciclo de vida em cascata é o espantalho dos modelos de ciclo de vida. Foi descrito pela primeira vez em 1970 por Wynn Royce como um exemplo de um processo falho… O desenvolvedor de software Christian Findlay fez uma afirmação semelhante em : . uma postagem no X afirmando “A abordagem em cascata é um espantalho que nunca existiu realmente” No entanto, a situação fica mais obscura à medida que nos aprofundamos na história do Agile. O mito da Toyota O Sistema Toyota de Produção (TPS) é o berço espiritual da metodologia Ágil. Apesar da esmagadora maioria das iniciativas de transformação falharem, muitos apontarão para a metodologia utilizada pela Toyota. No entanto, a própria Toyota tem uma história nada ideal quando se trata de engenharia de software. Um que, “Sem admitir responsabilidade, a Toyota desde 2014 resolveu 537 reclamações culpando a aceleração repentina por acidentes que mataram ou feriram gravemente pessoas, de acordo com um documento judicial que a Toyota apresentou” em setembro de 2019. relatório do Capitol Weekly afirma Esses defeitos de aceleração não intencionais não foram apenas fatais em numerosos casos, mas no caso de Koua Fong Lee, o defeito levou não apenas a um acidente de carro que matou três pessoas e feriu outras quando levava sua esposa grávida e filhos da igreja para casa, mas também levou para ele ser culpado e condenado à prisão. Em processos judiciais, a Toyota tentou contestar uma teoria de por que o veículo se comportou de forma errática com alegações de protocolos de testes robustos, mas pouco antes do julgamento, a Toyota apresentou uma declaração desse engenheiro afirmando que . a empresa na verdade não realizou tais testes Depois de que o teria libertado, mas o teria deixado rotulado como criminoso, Lee foi finalmente libertado depois que um novo julgamento foi ordenado, e a promotoria se recusou a levar o caso de volta ao tribunal. se recusar a aceitar um acordo judicial O caso do Bookout V. Toyota trouxe o foco às práticas de engenharia de software da Toyota depois que outro defeito de aceleração não intencional levou a fatalidades. Durante estes procedimentos, que finalmente concluíram que os sistemas de software poderiam causar aceleração não intencional, foram apresentadas evidências, incluindo comunicação interna dentro da Toyota afirmando que “na verdade, tecnologia como a failsafe não faz parte do DNA da divisão de Engenharia da Toyota”: Após este caso, que a Toyota adotou uma abordagem tradicional de engenharia de software para projetos de alta confiabilidade, usando a linguagem SPARK Ada, onde contratos de design rigorosos ajudam a verificar matematicamente a correção do software - uma abordagem adotada em ambientes de alta confiabilidade, como a aviação. e defesa. foi relatado Essa abordagem, conhecida como “design por contrato”, foi originalmente inventada pelo engenheiro de software francês Bertrand Meyer, que escreveu o livro “ ”. Entre as críticas de Meyer ao Agile estão a descontinuação do design inicial e o foco nas histórias de usuários em vez de especificações generalizáveis. Agile!: The Good, the Hype and the Ugly Essas críticas são descritas com mais detalhes no vídeo – “ ” do Edensoft Labs: The Ugly of Agile (with Dr. Bertrand Meyer) https://youtube.com/watch?v=Xi4WG-FVT6Q Conclusão Os vários espantalhos do Agile nos destacam a importância que todos devemos ter em sermos críticos antes de adotarmos soluções que ainda não comprovaram sua eficácia. Não me interpretem mal, não precisamos de meta-análises de revisões sistemáticas de ensaios clínicos randomizados para fazer todos os julgamentos na vida, mas devemos ter cuidado ao descartar evidências de uma base evidencial mais elevada do que aquelas de uma base evidencial mais baixa ( como aqueles que nos são apresentados como verdades dogmáticas por figuras de autoridade). Como humanos, as histórias de transformação, apesar das probabilidades, tocam nossos corações, e todos nós queremos acreditar que existem super-heróis que podem nos curar. No entanto, o cinismo cego também pode muitas vezes levar-nos a proteger-nos dos avanços que fazem progredir a sociedade. Ao procurar ignorar estes aspectos emocionais em vez de reconhecê-los, ficamos mais à sua mercê quando tentamos tomar decisões racionais. Uma das coisas que achei mais notável desde que escrevi o livro “ ” é como os mais dogmáticos de ambos os lados da divisão de opinião ágil ignoram os aspectos emocionais e psicológicos que de fato constituem a maior parte do o livro e são, como as evidências me mostram, está no cerne de iniciativas de transformação verdadeiramente bem-sucedidas. Engenharia de Impacto: Transformando além do gerenciamento ágil de projetos Isto constitui um lembrete claro de que, antes de irmos demasiado fundo na toca do coelho, temos de nos lembrar que as lições da ciência e da engenharia são que o questionamento da ortodoxia e a recolha de provas estão no cerne de descobertas verdadeiramente notáveis.
