¿Scrum crea gastos generales adicionales para proyectos donde los requisitos no cambian?

Estoy leyendo el Scrum - Una guía de bolsillo de Gunther Verheyen y dice:

El informe Caos de 2011 del Grupo Standish marca un punto de inflexión. Se realizó una investigación exhaustiva al comparar proyectos tradicionales con proyectos que utilizaban métodos ágiles. El informe muestra que un enfoque ágil para el desarrollo de software da como resultado un rendimiento mucho mayor, incluso contra las viejas expectativas de que el software debe entregarse a tiempo, dentro del presupuesto y con todo el alcance prometido. El informe muestra que los proyectos Ágiles fueron tres veces más exitosos, y hubo tres veces menos proyectos Ágiles fallidos en comparación con los proyectos tradicionales.

Así que tengo una discusión con uno de mis colegas que dice que para algunos proyectos (como medicina / militar donde los requisitos no cambian), Agile (y, en particular, Scrum) está sobrecargado con todas las reuniones, etc. y es más lógico usar cascada, por ejemplo.

Mi punto de vista es que Scrum debería adoptarse en tales proyectos porque hará que el proceso sea más transparente y aumente la productividad de un equipo. También creo que los eventos Scrum no tomarán mucho tiempo si no es necesario porque no necesitamos sentarnos las 8 horas completas en Sprint Planning durante 1 mes de sprint. Podemos dedicar 5 minutos solo para asegurarnos de que todos estamos en la misma página y comenzar a trabajar.

Entonces, ¿Scrum creará gastos generales adicionales para un proyecto donde los requisitos no cambian?

Creo que es una suposición errónea decir que hay proyectos en los que los requisitos no cambian. Después de haber trabajado tanto en la industria de la defensa como en la industria farmacéutica, puedo decirle que una vez que el software termina en manos de expertos en la materia (internos o externos), hay comentarios. A veces, esta retroalimentación está en la forma en que se cumplió el requisito y, en otros casos, en realidad se trata de que los requisitos en sí mismos son incorrectos o incompletos.

La agilidad consiste en reducir ese ciclo de retroalimentación y hacer que el software de trabajo llegue a las manos de alguien más rápido, obtener esa retroalimentación y decidir cuál debe ser el siguiente paso para asegurarse de que lo que se entrega agrega valor cuando el cliente decide aceptar el software. Incluso en ámbitos como los sistemas embebidos con hardware personalizado (como puede encontrar en dominios como el aeroespacial, automotriz o dispositivos médicos), la entrega de pequeños segmentos de funcionalidad para integrar rápidamente y crear prototipos puede ayudar a garantizar que el sistema de software y hardware trabajar según lo previsto y de manera que ayude al usuario final.

La reducción en la duración del ciclo de retroalimentación es un factor enorme en la reducción del riesgo. Desde la perspectiva de la gestión de proyectos, si financia un proyecto durante 2-4 semanas y obtiene una visibilidad regular del progreso, eso le asegura que está en camino. Al ser capaz de entregar pequeñas porciones de funcionalidad, trabaja gradualmente hacia el estado objetivo y puede comenzar a pronosticar cuándo llegará allí. Si el tiempo se convierte en una restricción, puede eliminar las funciones de menor valor ya que el trabajo realizado primero debe ser una función de alto valor o un habilitador para una función de alto valor. En cualquier momento, puede decidir si vale la pena continuar financiando el esfuerzo o ir en una dirección diferente y detener un proyecto antes de que sea demasiado tarde.

La respuesta muy breve es que sí, Scrum es, por diseño, un enfoque más costoso, pero si lo llama proyecto, es casi seguro que no importa y al final casi siempre dará como resultado un mejor ROI.

La respuesta más completa es esta:

En términos generales, hay tres formas de control del proceso: Control de proceso definido, Control de proceso estadístico y Control de proceso emperical. Control de proceso definido es, con mucho, el más barato. Esto es posible con el trabajo repetible con frecuencia que se ha refinado con el tiempo para encontrar la "mejor" forma de hacer el trabajo. CI / CD en desarrollo de software cae en esta categoría. No desea variaciones en su proceso de construcción, por lo que estandariza el proceso, lo ajusta hasta que esté satisfecho con él y luego lo automatiza. Ese proceso automatizado es obviamente mucho menos costoso de ejecutar que luchar manualmente a través de una implementación.

El control estadístico de procesos es el siguiente menos costoso, pero explica las variaciones en un proceso conocido. Los procedimientos médicos que van según el plan entran en esta categoría. No quiero reinventar una cirugía de derivación cada vez. Sigo el proceso básico y me ajusto a la variación. Esto tiene una carga cognitiva relativamente baja y una tasa de éxito bastante alta.

El siguiente es el control de proceso empírico, que es, con mucho, el más costoso porque tiene que descubrir el proceso a medida que avanza. El aprendizaje es increíblemente alto, pero a costa de la productividad y la eficiencia. Sin embargo, casi todo el trabajo del proyecto requiere esto porque pocos proyectos se han realizado antes. Hay, por supuesto, excepciones. Configurar un entorno de directorio activo grande es más estadístico porque trabaja a partir de algunas instrucciones probadas y verdaderas de las que se desvía ligeramente según lo requieran las circunstancias. Pero a menos que su proyecto sea hacer el trabajo exacto que se ha hecho antes, es casi seguro que requiera el Control de proceso emperical.

Para llevarlo de vuelta a Scrum, Scrum está diseñado para resolver problemas con el control del Proceso Emperical. Por lo tanto, sí, tiene más gastos generales que otros enfoques. Sin embargo, dado que la mayoría de los proyectos requieren este enfoque, es un argumento discutible.

Para el contrapunto sobre la medicina y los proyectos militares, parece una lógica defectuosa. Si está cumpliendo un pedido de 500 aviones, entonces sí, está recreando algo exactamente y Scrum probablemente no sea beneficioso. Si está construyendo un nuevo avión y sus requisitos nunca cambian, no volaría ese avión.

Claro, si tiene un proyecto en el que tiene requisitos cristalinos por adelantado, entonces podría dejarlos enfrente de los desarrolladores y regresar dos años después para cumplir con el software de sus sueños.

Pero la gran mayoría de los proyectos de software no es así.

Por lo general, el cliente no sabe lo que necesita. No pueden proporcionar requisitos completos y específicos. Los enfoques iterativos ayudan aquí: construir una pequeña cosa, luego pedirle al cliente comentarios. Sí, esto "desperdicia" tiempo en demostraciones y planeando la próxima iteración. Pero construir lo incorrecto para un sprint y luego corregir rápidamente los requisitos es mucho mejor que construir lo incorrecto para la totalidad del proyecto. Es decir, si bien los requisitos iniciales pueden permitir un desarrollo más eficiente , los enfoques iterativos serán más efectivos .

Los desarrolladores deben comprender los requisitos correctamente si quieren crear software útil. ¿Cuál es una buena manera de descubrir malentendidos antes de que sea demasiado tarde? Nuevamente, los enfoques iterativos pueden ayudar. Pero también es importante que los propios desarrolladores colaboren con el cliente en lugar de solo obtener información filtrada a través de un autor de documentos de requisitos.

Finalmente, el mundo no se detiene durante el proyecto. Los sistemas externos cambian, las prioridades cambian, las personas cambian. Pretender que los requisitos de un proyecto de software no cambiarán es una mala idea, excepto para proyectos cortos.

Todos estos beneficios a nivel de proceso pierden la gran ventaja del día a día de los enfoques ágiles: si se hace correctamente, ágil hace a todos más felices. El mayor de estos es que las técnicas ágiles se centran en proporcionar un valor real a corto plazo. Eso brinda visibilidad al proceso de desarrollo, brinda a las partes interesadas un nivel razonable de control sobre el proyecto y es mucho más motivador que trabajar hacia un objetivo distante. Relacionado con esto está la idea de que los equipos ágiles se autoorganizarán en gran medida. Tener el control sobre su trabajo diario hace que las personas se sientan valoradas y, por lo tanto, más propensas a dar lo mejor de sí mismas.

Su colega no está equivocado porque los proyectos de estilo cascada pueden tener su lugar. Y no está equivocado porque algunas prácticas ágiles pueden ser rituales que pierden el tiempo. Pero es completamente tonto ignorar los beneficios de los enfoques ágiles e iterativos, especialmente una mejor gestión de riesgos y respeto por las personas. Estas son cosas que desea en cada proyecto. Si es necesario, un equipo puede intentar implementar algo de esto internamente, pero los procesos funcionan mejor cuando todos están a bordo.

Creo que esto podría estar parafraseando lo que dice @Cort Ammon, pero aquí está mi opinión:

Los requisitos externos (que describen los "entregables") no son los únicos requisitos en un proyecto. Incluso si los requisitos externos no cambian, los requisitos "internos" cambiarán, o es necesario que se les permita cambiar, mientras trabaja. Los desarrolladores descubrirán obstáculos o problemas con un enfoque, y esto afectará el trabajo de las otras personas en el equipo. Un stand-up diario mantendrá a todos actualizados con estos cambios internos.

Considere eso:

• Incluso con requisitos funcionales fijos, debe trasladarlos a requisitos técnicos. Y esto puede hacerse mejor mediante iteraciones. Puede descubrir mejores formas de resolver el problema en la mitad del proyecto.

• Algunos requisitos pueden ser demasiado genéricos o ambiguos: "ser fácil de usar", "estar seguro". Es difícil analizar la seguridad o usabilidad de un sistema que no está terminado. Algunos pueden tener implicaciones ocultas o pueden no ser bien entendidos.

• Algunos requisitos pueden ser mejorados. Responder en 200 ms puede ser bueno, pero 100 puede ser mejor. Puede apuntar al mejor resultado posible pero sacrificarlo si es necesario durante el proyecto.

• Puede descubrir algunos requisitos ocultos que no se escribirán en el contrato pero que pueden cambiar el proyecto de fracaso a éxito. Incluso si entrega el proyecto, el cliente puede no estar contento. Puede ser que incluso necesiten cambiar el contrato para agregar (y cobrar) por nuevas características que puede diseñar en el proyecto más barato en las primeras etapas.

• Puede descubrir que no puede cumplir con sus requisitos en el tiempo dado. No es como si los proyectos de software nunca llegaran tarde. Por lo tanto, ofrecer el mejor valor le permitirá renegociar qué funciones eliminar.

• Entregar algo antes ayudará a la integración y mostrará que este proyecto puede ofrecer resultados.

Se puede argumentar que si todos los requisitos se presentan perfectamente, entonces existe un enfoque de arriba hacia abajo que logra esos requisitos lo más rápido posible. Sin embargo, si estos son buenos requisitos, le dicen qué hacer, no cómo hacerlo. Si le dicen cómo hacerlo, elegiría llamarlo "instrucciones de trabajo" en lugar de "requisitos" y estaríamos discutiendo un tipo diferente de problema.

En consecuencia, siempre hay un proceso de desarrollo del "cómo" que es interno para la empresa o el equipo que implementa los requisitos. Hablando empíricamente, confiamos firmemente en un enfoque jerárquico en el que un equipo de diseñadores diseña el sistema de alto nivel para cumplir con esos requisitos, y luego utiliza los detalles de ese sistema de alto nivel para proporcionar "requisitos" a equipos más pequeños que completan nuestros detalles.

En el proceso de cascada, esto se puede ver en la flecha unidireccional entre diseño e implementación. Sin embargo, estos requisitos no se establecen en piedra, como lo fueron los requisitos del cliente. Estos están definidos internamente y tienen espacio para el proceso iterativo. En la práctica, encontramos que los diseñadores ponen un margen considerable en el proceso para dar cuenta de esta falta de iteración o buscan un proceso iterativo.

SCRUM, y muchos otros métodos ágiles relacionados, simplemente proporcionan un marco riguroso dentro del cual hacer este proceso iterativo. Una característica distintiva de los enfoques ágiles es que consideran que la optimización de este patrón iterativo es el núcleo del proceso, en lugar de centrarse en la capa externa de los requisitos difíciles. Como otros han mencionado, los requisitos fijos reales son raros, pero incluso en su presencia, SCRUM utiliza el enfoque iterativo como metodología para controlar el enfoque contractual que se ajusta dentro de él.

Si tiene éxito en hacer esto es una cuestión de debate abierto. Otros han proporcionado muchas métricas para este fin. Simplemente señalaré que depende de la fuerza del liderazgo asegurarse de que las iteraciones que ocurren debajo de ellas encajen correctamente en el sistema contractual anterior. Esto es cierto con cualquier enfoque de desarrollo, pero es más visible en los enfoques ágiles porque hemos sido educados para asumir que el enfoque más vertical es líderes "normales" y capacitados como tales.