¿Debería una organización de desarrollo adoptar un modelo de proceso único para todo su desarrollo de software?

Una organización que desarrolle el mismo tipo de software para el mismo tipo de entorno operativo, una y otra vez, utilizando equipos de aproximadamente el mismo tamaño cada vez, debe estandarizar un modelo de proceso apropiado. Esto permite que los equipos y los miembros del equipo se muevan de un proyecto a otro sin una curva de aprendizaje del proceso, lo que mejora la eficiencia de la organización y su capacidad de nivel de carga.

No muchas organizaciones realmente desarrollan el mismo tipo de software para el mismo tipo de entorno operativo, una y otra vez, utilizando equipos del mismo tamaño cada vez. Considere una organización que construye juegos para teléfonos celulares, como un ejemplo.

• En la primera etapa de desarrollo, un equipo multifuncional muy pequeño prototipa la mecánica del juego, los estilos artísticos y los arcos de historias que intentan “encontrar la diversión” y ganar la aprobación para la producción del juego. El equipo no conoce, y no puede saber, los requisitos firmes durante esta etapa. Generalmente hay un límite de tiempo artificial en esta etapa. Es una buena opción para un modelo de proceso de creación de prototipos.
• Mientras se produce el juego, el equipo crece. Puede implicar múltiples ubicaciones, lo que requiere la compartimentación del diseño y la documentación de las interfaces. El proceso debe ser lo suficientemente estable y simple como para que los nuevos miembros del equipo sean efectivos rápidamente, y debe responder a los cambios en el alcance y los cambios en los requisitos descubiertos durante el desarrollo. Es una buena opción para un modelo de proceso ágil.
• Una vez que el juego está a punto de ser lanzado, el equipo del cliente móvil y el equipo del servidor tienen restricciones de proceso muy diferentes.

• El equipo del cliente móvil solo puede enviar cambios al juego a los usuarios aproximadamente una vez cada dos semanas debido a restricciones externas (proceso de lanzamiento impuesto por Apple / Google / Amazon / Microsoft / etc.), y luego tiene que esperar a que los usuarios descarguen y Instalar los cambios. Tiene que abandonar la iteración experimental / rápida en este punto a favor de un proceso que garantice versiones estables. Los modelos que se ajustan bien aquí enfatizan una fuerte relación entre diseño y prueba, ya sea a través de un “modelo V” o un modelo basado en pruebas.
• El equipo del servidor aún puede iterar rápidamente y puede impulsar múltiples cambios por día si lo desea; Debido a que es mucho más sensible al cliente que el equipo del cliente móvil en este punto, necesita un proceso que tenga en cuenta la necesidad de reparar o parchear rápidamente los sistemas en vivo en el servidor sin interrumpir a los usuarios, incluso si el verdadero problema está en el cliente móvil.

• Los equipos que trabajan en las características y el contenido del juego deben seguir un modelo en cascada que establezca y mantenga la cadencia de lanzamiento. Eso significa características bien definidas, bien entendidas y estimaciones de tiempo confiables, así como decisiones para cortar o posponer características que no serán el próximo “tren de lanzamiento”.
• La mayoría de las veces, los equipos que trabajan en operaciones en vivo están “luchando contra incendios” (reparando fallas en el juego, errores, fallas en el servidor, comportamiento emergente, exploits, etc.). En el espacio entre incendios probablemente necesiten reducir de manera oportunista la deuda técnica. No pueden predecir en qué trabajarán día a día, pero pueden predecir su capacidad de ingeniería típica y máxima. Necesitan algo como kanban con ingenieros fungibles de full stack para lograrlo.
• Los equipos que trabajan en plataformas tecnológicas compartidas / TechOps necesitan continuar el trabajo relacionado con la hoja de ruta tecnológica en segundo plano, pero ese trabajo debe ser interrumpible para responder a problemas de operaciones en vivo. El proceso para esto es un híbrido; Dependiendo de la organización, puede ser mayormente ágil o mayormente en cascada, pero es probable que se realice una prueba para mitigar el riesgo.

¡Tú decides si acabo de describir una organización u ocho organizaciones!

Creo que hay una serie de factores que deben tenerse en cuenta, como si su equipo es remoto o no, la representación de diferentes culturas, etc.

Las ventajas evidentes de un solo proceso son:

Menos trabajo inicial

Agile, por ejemplo, nos enfoca en definir y priorizar problemas para resolver; es necesario colaborar con nuestros desarrolladores para diseñar, especificar y revisar el trabajo; y para ejercer solo la cantidad de esfuerzo necesario para mover un producto o proyecto a su siguiente fase.

Mayor flexibilidad en las funciones de lanzamiento

El enfoque en la entrega de software de trabajo en iteraciones de trabajo de tiempo fijo o de esfuerzo proporciona a la empresa en general una mayor flexibilidad en cuanto a cuándo se debe entregar el producto a los usuarios finales.

Ciclos de revisión más rápidos

Para que los equipos acepten la incertidumbre y respondan al cambio, es necesario realizar una iteración rápida y revisiones cíclicas y exhaustivas a medida que se completa el trabajo, para garantizar que se contemplen nuevos descubrimientos y se evalúen los esfuerzos actuales.

Los contras de un solo proceso son los siguientes:

Falta de entendimiendo

Con demasiada frecuencia, el único proceso único se adopta como una solución de adentro hacia afuera … o peor, dentro de una “burbuja” del equipo de desarrollo que descuida los impactos en otras preocupaciones comerciales y de productos.

Ajuste cultural

No todas las culturas corporativas están “listas” para los cambios que requiere una metodología, que, como muchos pretenden, no se relegan solo a los equipos de desarrollo. El tipo de flexibilidad, incertidumbre y revisiones periódicas basadas en intervalos que hacen que algunos enfoques sean exitosos requieren cantidades significativas de cambio en toda la organización.

Falta de previsibilidad

Cuando aceptamos la incertidumbre en nuestros esfuerzos y valoramos responder al cambio después de seguir un plan, sacrificamos el tipo de previsibilidad y seguridad (a menudo, una falsa sensación de seguridad) que brindan las hojas de ruta de nivel de característica de 12 a 24 meses. Esto a menudo puede ser una píldora difícil de tragar para las otras partes de la organización; complica los presupuestos, los planes de marketing, los planes de compensación de ventas e incluso los argumentos de los inversores.

La regla general es que debe ajustar la metodología a la naturaleza del problema en lugar de ajustar todos los problemas a una sola metodología predefinida. Las ventajas de utilizar una sola metodología son las siguientes:

• Requiere menos sofisticación y capacitación para que las personas sean competentes en múltiples enfoques y cómo elegir el mejor enfoque para un proyecto
• Si la naturaleza de los proyectos es similar, puede proporcionar una forma más consistente de predecir el rendimiento y una base para capturar el aprendizaje continuo para mejorar continuamente el proceso de un proyecto al siguiente

La desventaja es que el ajuste forzado de todos los proyectos a un enfoque único puede ser menos que óptimo si hay una considerable cantidad de diversidad en los proyectos.

Sugiero usar un enfoque de desarrollo ágil como base porque un enfoque ágil es adaptativo por su propia naturaleza. Es posible que deba combinar cierto nivel de un enfoque basado en un plan dependiendo de la naturaleza del proyecto.

Chuck Cobb
Autor de “La guía del administrador de proyectos para dominar Agile”
Echa un vistazo: Agile Project Management Academy (Agile Project Management Academy)

Realmente depende de quién eres, qué haces y la naturaleza del software que estás desarrollando. Si eres una gran empresa con un gran equipo trabajando en un proyecto monolítico, algún tipo de proceso iterativo tiene sentido. Si está produciendo el software para operar un marcapasos, no lo haría (los comentarios del cliente serían bastante intensos). Si eres una tienda de software que realiza un proyecto desde cero cada 90 días para diferentes clientes dentro de un espacio bien definido, tienes que ir en cascada, ya que los clientes esperarán saber cuánto tiempo llevará y cuánto costará por adelantado. Si eres una startup con un equipo pequeño, volveremos a algún tipo de proceso iterativo nuevamente.

El proceso debe ajustarse al proyecto. Como desarrollador de una tienda de software que realiza un trabajo variado en diversas capacidades, tengo que poder trabajar en múltiples metodologías. Si el cliente necesita que trabaje en un proyecto iterativo con su equipo interno, tengo que trabajar en su proceso. Si un cliente entra con un proyecto claramente definido y desea estimar el costo total para poder planificar el presupuesto del próximo año, tengo que trabajar en cascada. Y a menudo es algo intermedio, con proyectos divididos en dos o tres fases según los plazos de entrega, obteniendo la funcionalidad mínima en un enfoque en cascada y luego dando vueltas para ampliar la funcionalidad. Realmente depende mucho del proyecto.