Hace dos años, estudié el impacto del agotamiento de los desarrolladores en los ingenieros de software y descubrí . En los últimos meses, he estado trabajando en más investigaciones sobre las percepciones del desarrollo de software para una variedad de organizaciones, incluidos los hallazgos de que el 75% de los ingenieros de software y que el 89% de los líderes empresariales estaban . que el 83% sufría agotamiento enfrentaron represalias la última vez que informaron sobre irregularidades preocupados por las Entrega puntual del software El equipo DORA de Google lleva varios años realizando su propia encuesta entre ingenieros de software y los autores originales del marco de medición han producido ahora otros marcos, incluidos SPACE y DevEx. Si bien originalmente confié en la investigación producida por estos equipos, a medida que realicé más investigaciones, las fallas se hicieron evidentes. Durante el período de vacaciones he estado leyendo el libro del Dr. Andrew Jenkinson "Por qué comemos (demasiado): la nueva ciencia del apetito", en el libro el Dr. Jenkinson critica un estudio conocido como el Estudio de los Siete Países realizado por el Dr. Ancel Keys. El Dr. Jenkinson describe el éxito del Dr. Keys de la siguiente manera: “Había ganado la discusión sobre su mayor rival, derrotándolo con hechos indiscutibles, exponiendo su lógica defectuosa. La adulación de la multitud lo llenó de alegría y éxtasis. El trabajo de su vida había llegado a buen término. La financiación para su investigación llegaría rápidamente y su reputación como científico líder en su campo estaría asegurada durante años. La fama era buena, pero ahora se había asegurado los dos premios principales: poder e influencia”. Sin embargo, el Dr. Jenkinson señala: “No había sido deshonesto en su investigación; eso habría sido poco ético y lo habría desacreditado. Técnicamente lo que había presentado era la verdad. Pero él sabía muy bien que no era toda la verdad”. A medida que estudié los resultados de la investigación de DORA y luego trabajé con más detalle, los paralelos entre esta descripción y el rigor de la investigación en el Informe sobre el estado de DevOps de DORA y el posterior marco SPACE y DevEx se han vuelto evidentes. ¿Dónde están los datos? En primer lugar, la investigación de DORA se lleva a cabo mediante un muestreo de miles de desarrolladores mediante el uso de encuestas subjetivas. Esta investigación la lleva a cabo internamente el equipo de DORA. Por lo general, quienes se ganan la vida realizando este tipo de investigaciones se han unido a organizaciones como la Market Research Society (MRS) y el British Polling Council (BPC) para garantizar que el público pueda tener confianza en las investigaciones realizadas por las organizaciones que son miembros. Por ejemplo; Las reglas del BPC imponen reglas estrictas de divulgación a sus miembros, exigiendo que revelen tablas de datos completas con las preguntas formuladas dentro de los 2 días hábiles posteriores a la publicación de la investigación. Aquí reside nuestro primer problema; El equipo de DORA no publica sus datos sin procesar, solo publica su Informe sobre el estado de DevOps. Metodología defectuosa La investigación DORA de Google y los marcos SPACE y DevEx utilizados en la configuración del equipo utilizan encuestas subjetivas para crear mediciones. Al utilizar encuestas subjetivas, es importante tomar medidas para garantizar que no entren en juego sesgos. Sin embargo, DORA utiliza cuatro métricas clave para medir los resultados: tiempo de entrega de cambios, frecuencia de implementación, tasa de fallas de cambios y tiempo de recuperación (anteriormente tiempo medio de recuperación). Estas son esencialmente medidas de la velocidad para implementar nuevas funciones y la velocidad para resolver problemas. Imagínese que le preguntara a algunas personas: "¿Tus colegas comen muchas verduras?". y “¿Tus compañeros hacen mucho ejercicio?”. Aquellos que se sienten mejor acerca de su lugar de trabajo probablemente sean más propensos a responder "sí" a ambas preguntas; esto no significa que comer más verduras siempre conducirá a mayores niveles de asistencia al gimnasio. Si bien puede haber una correlación, no hemos creado una relación de causa y efecto. La investigación de DORA sostiene que la velocidad y la confiabilidad van de la mano; sin embargo, lo hacen basándose en medidas de resultados que se basan completamente en la velocidad. Además, el uso de encuestas subjetivas puede inducir a los destinatarios que se sienten mejor con su trabajo a responder “sí” a ambas preguntas. Y aunque las empresas que son más competentes inevitablemente pueden serlo en ambos factores, esto no crea una relación causal. Por ejemplo; Consideremos cuán altamente considerada es la confiabilidad del software de aviación, en comparación con la implementación poco frecuente de software en las aeronaves. O considere cómo Toyota, el pionero de las metodologías ágiles, en el caso de confiabilidad del software “Bookout v. Toyota” sobre un error de aceleración involuntario que provocó muertes admitió en comunicación interna que "En verdad, la tecnología como la seguridad contra fallas no es parte del sistema Toyota". El ADN de la división de ingeniería". O considere cómo durante el escándalo de Horizon IT (culpado de múltiples suicidios y de lo que se ha descrito como “el error judicial más extendido en la historia del Reino Unido”, en el que entre los encarcelados injustamente se encontraba una mujer embarazada) el desarrollador de software Fujitsu fue pionero en el uso de un Metodología ágil para desarrollar software, concretamente . Desarrollo Rápido de Aplicaciones Resultados de medición defectuosos Como se mencionó, la investigación de DORA se comparó con cuatro métricas clave que evalúan la velocidad para implementar nuevos trabajos y corregir errores para evaluar el rendimiento. Sin embargo, estas métricas sólo importan en la medida en que sean resultados útiles para medir. Realicé (con la firma de investigación Survation) y descubrí que ambos coinciden en que la velocidad es el factor menos importante. En cambio, el público se preocupa más por la seguridad y la precisión de los datos y por la prevención de errores graves. Es difícil encontrar una hipótesis que conecte las Cuatro Métricas Clave con estos resultados que los desarrolladores de software y el público consideran más importantes, especialmente teniendo en cuenta que prevenir errores graves es una prioridad menor que corregir errores rápidamente o trabajar rápidamente. Incluso para otros factores como la seguridad de los datos, es difícil ver cómo se conectan con cualquiera de las cuatro métricas clave. una investigación tanto de ingenieros de software como de una muestra representativa del público en general Incluso entre los responsables de la toma de decisiones empresariales, parece que la entrega a tiempo es más importante que la entrega rápida. Según una investigación que realicé con JL Partners, el 98% de los tomadores de decisiones empresariales en el Reino Unido y el 96% en los EE.UU. están de acuerdo con la afirmación "El objetivo de un equipo de ingeniería de software es entregar software de alta calidad a tiempo", con El 65% en el Reino Unido y el 62% en Estados Unidos están totalmente de acuerdo. Finalmente; La investigación que realicé con Survation encontró que la confianza en los ingenieros de software y las expectativas de confiabilidad del público pueden variar considerablemente de una industria a otra, lo que significa que se debe desalentar un enfoque único para todos en favor de lo que sugiere el Engineering Council UK en su informe. : “adoptar un enfoque de toma de decisiones que sea proporcional al riesgo y consistente con el apetito de riesgo definido por su organización”. Orientación sobre Riesgos Sigue el dinero Al igual que el Dr. Keys recibió financiación de la industria azucarera para su investigación; en muchas investigaciones, es importante seguir el dinero para comprender dónde se encuentran los incentivos. El equipo de DORA comenzó originalmente a realizar informes sobre el estado de DevOps para Puppet, una empresa centrada en la automatización de la infraestructura de TI, y ahora hacen este trabajo para Google Cloud. Ambos tienen un gran interés en que los desarrolladores puedan implementar el trabajo lo más rápido posible. Sin embargo, esto no significa que sea la solución a todos nuestros problemas. DORA ha hecho una contribución al mundo de la ingeniería de software al agregar un grado de evaluación empírica al proceso. Sin embargo, debemos evitar confundir el material de marketing con toda la verdad y reconocer los defectos de dicha investigación.
