Desde el acoso hasta los intentos de piratería, desde que comencé a trabajar en la investigación de la de los proyectos ágiles y las iniciativas de transformación, me he encontrado cara a cara con el fundamentalismo que existe entre los seguidores más devotos de Agile. alta tasa de fracaso Cuando los pacientes vulnerables de un curandero sucumben a una enfermedad como resultado de un tratamiento falso que no funciona (generalmente habiendo "donado" una cantidad considerable de dinero), el "curandero" a menudo afirmará que es culpa del paciente, ya que no oraron mucho. suficiente. Este ha sido un tema explorado en profundidad por Derren Brown en el especial de televisión y teatralmente en su especial de Netflix . Esta falacia se describe a menudo como una versión de la falacia de “ ” o un “ ”. Miracles for Sale Miracle no es un verdadero escocés apelación a la pureza Los fundamentalistas de la comunidad Agile suelen utilizar afirmaciones similares cuando los proyectos Agile fracasan. Por ejemplo, en el artículo “ ”, escribe Greg Kihlstrom: ¿Fracasar en Agile? Lo estás haciendo mal Como ejemplo, podría tener el Scrum Master más entusiasta posible en su equipo, pero si el equipo de producto tiene algunos detractores o aquellos que simplemente no cumplen o no entienden lo que hay que hacer, tendrá desafíos. A veces esto es una cuestión de educación o entrenamiento, y otras veces es una cuestión de dinámica y cultura del equipo. Determine cuál es la causa y trátela en consecuencia. Sin embargo, la base científica para tal creencia no existe. Un artículo de noviembre de 2021 titulado ' ' realizó un metanálisis de numerosas revisiones de estudios científicos ágiles y encontró: “El resultado del estudio terciario es que, de hecho, la evidencia para la La metodología ágil es, en el mejor de los casos, escasa”. “Mejores prácticas” sin evidencia: metodología de software ágil como ejemplo Sin embargo, este está lejos de ser el único sesgo cognitivo adoptado por quienes adoptan una postura fundamentalista cuando se trata de Agile. En este artículo, me gustaría centrarme en los testaferros que se suelen utilizar para justificar la metodología Agile. ¿Qué es un hombre de paja ágil? En la comunidad Agile de LinkedIn, no es raro ver publicaciones como las siguientes: aparentemente una conversación que hace que un practicante Agile parezca ingenioso y reivindica la metodología frente a un ingeniero de software que se atreve a cuestionarla. En mi opinión personal, estas conversaciones parecen ser generalmente ficticias: El Oxford English Dictionary proporciona la siguiente definición de hombre de paja: En una discusión, debate, etc.: una proposición intencionalmente débil o tergiversada, formulada porque es más fácil de derrotar que el argumento real de un oponente, o desvía la atención de él, dando la impresión superficial de que la acusación original ha sido refutada o derrotada. . Sin embargo, hay testaferros mucho más arraigados que parecen ir al corazón mismo de la propuesta ágil. Un artículo en el sitio web SecretGeek planteó la pregunta: “ ”. Si bien el autor afirmó que los otros elementos dogmáticos de Agile estaban efectivamente vigentes, desde los rituales hasta la doctrina, el único área sobre la que estaban indecisos era si había una "mitología" en Agile. ¿Es 'Agile' una religión? (o simplemente una secta) Creo que estos muñecos de paja son fundamentalmente lo que forma la mitología de Agile. El mito de la cascada Es difícil ver cómo se habla de Agile sin hablar de Waterfall. Una supuesta metodología de gestión de proyectos con la que contrasta Agile. Una metodología que requiere pasos estrictamente documentados y nunca realizar cambios. Sin embargo, esto plantea la pregunta: ¿dónde están las conferencias o grupos de usuarios de Waterfall, incluso históricamente? Quizás los orígenes de la metodología nos proporcionen algunas pistas. En de Jon Pearce en la Universidad Estatal de San José, afirma: “ ” las notas de clase El modelo de ciclo de vida en cascada es el hombre de paja de los modelos de ciclo de vida. Fue descrito por primera vez en 1970 por Wynn Royce como un ejemplo de un proceso defectuoso… El desarrollador de software Christian Findlay hizo una observación similar en : . una publicación en X afirmando “El enfoque en cascada es un hombre de paja que en realidad nunca existió” Sin embargo, la situación se vuelve más turbia a medida que profundizamos en la historia de Agile. El mito de Toyota El Sistema de Producción Toyota (TPS) es la cuna espiritual de la metodología Agile. A pesar de que la inmensa mayoría de las iniciativas de transformación fracasan, muchos señalarán la metodología utilizada por Toyota. Sin embargo, la propia Toyota tiene una historia menos que ideal en lo que respecta a la ingeniería de software. Un que, “Sin admitir responsabilidad, Toyota desde 2014 ha resuelto 537 reclamaciones que culpan a la aceleración repentina por accidentes que mataron o hirieron gravemente a personas, según un documento judicial que Toyota presentó” en septiembre de 2019. informe en Capitol Weekly afirma Estos defectos de aceleración involuntarios no sólo fueron fatales en numerosos casos, sino que en el caso de Koua Fong Lee, el defecto provocó no sólo un accidente automovilístico que mató a tres personas e hirió a otras mientras conducía a su esposa embarazada y a sus hijos a casa desde la iglesia, sino que también provocó que hasta que se le culpe y se le condene a prisión. En los procedimientos judiciales, Toyota había intentado contrarrestar una teoría de por qué el vehículo se comportaba de manera errática con afirmaciones de protocolos de prueba sólidos, pero poco antes del juicio, Toyota presentó una declaración de ese ingeniero afirmando que . la compañía en realidad no realizó tales pruebas Después de que lo habría liberado pero lo habría dejado tildado de criminal, Lee finalmente fue liberado después de que se ordenó un nuevo juicio y la fiscalía se negó a devolver el caso a los tribunales. negarse a aceptar un acuerdo El caso Bookout V. Toyota puso de relieve las prácticas de ingeniería de software de Toyota después de que otro defecto de aceleración involuntario provocara muertes. Durante estos procedimientos, que finalmente encontraron que los sistemas de software podrían causar una aceleración involuntaria, se mostraron pruebas, incluida una comunicación interna dentro de Toyota que afirmaba que "en verdad, tecnología como la seguridad contra fallas no es parte del ADN de la división de Ingeniería de Toyota": Después de este caso, que Toyota había adoptado un enfoque tradicional de ingeniería de software para proyectos de alta confiabilidad, utilizando el lenguaje SPARK Ada donde los contratos de diseño estrictos ayudan a verificar matemáticamente la corrección del software, un enfoque adoptado en entornos de alta confiabilidad como la aviación. y defensa. se informó Este enfoque, conocido como “diseño por contrato”, fue inventado originalmente por el ingeniero de software francés Bertrand Meyer, quien escribió el libro “ ”. Entre las críticas de Meyer a Agile se encuentran la desaprobación del diseño inicial y el enfoque en las historias de los usuarios sobre las especificaciones generalizables. Agile!: The Good, the Hype and the Ugly Estas críticas se describen con más detalle en el vídeo " " de Edensoft Labs: The Ugly of Agile (with Dr. Bertrand Meyer) https://youtube.com/watch?v=Xi4WG-FVT6Q Conclusión Los distintos testaferros de Agile nos destacan la importancia que todos debemos tener en ser críticos antes de adoptar soluciones que aún no han demostrado su eficacia. No me malinterpreten, no necesitamos metanálisis de revisiones sistemáticas de ensayos controlados aleatorios para emitir todos los juicios en la vida, pero debemos tener cuidado al descartar evidencia con una base probatoria más alta que la de una base probatoria más baja ( como los que nos presentan como verdades dogmáticas las figuras de autoridad). Como seres humanos, las historias de transformación, a pesar de las probabilidades, nos tocan la fibra sensible y todos queremos creer que hay superhéroes que pueden curarnos. Sin embargo, el cinismo ciego también puede llevarnos a menudo a protegernos de los avances que hacen progresar a la sociedad. Al tratar de ignorar estos aspectos emocionales en lugar de reconocerlos, nos encontramos más a su merced cuando intentamos tomar decisiones racionales. Una de las cosas que encontré más notable desde que escribí el libro “ ” es cómo los más dogmáticos de ambos lados de la división de opinión ágil ignorarán los aspectos emocionales y psicológicos que de hecho forman la mayor parte de la discusión. El libro y lo que son, lo que me muestra la evidencia, se encuentra en el corazón de iniciativas de transformación verdaderamente exitosas. Ingeniería de impacto: Transformando más allá de la gestión ágil de proyectos Esto presenta un crudo recordatorio de que antes de ir demasiado lejos en la madriguera del conejo, debemos recordar que las lecciones de la ciencia y la ingeniería son que cuestionar la ortodoxia y recopilar evidencia son la base de los descubrimientos verdaderamente notables.
