¿Es posible usar Agile en proyectos de infraestructura donde el alcance se conoce por adelantado?

¿Cómo utilizar metodología ágil para proyectos de Infraestructura donde se conoce el Alcance de antemano?

Ejemplos de proyectos

  1. Migración/reubicación del centro de datos
  2. Migración SAN
  3. Para la solución de telepresencia de Cisco
  4. Proyectos de telefonía

El alcance no cambia, la mayor parte del proyecto se ejecutará desde Runbook.

Si no es posible, ¿eso significa que los proyectos de infraestructura se realizan principalmente con Waterfall?

No hay información suficiente para responder a su pregunta tal como está escrita. Por ejemplo, ¿dónde está su WBS para la migración del centro de datos? Casi cualquier cosa puede ser un proyecto ágil si se estructura de esa manera.
La respuesta corta es sí, por supuesto. faltan demasiados detalles.
Publiqué mis opiniones sobre este aquí: linkedin.com/pulse/…
Al decir que se conoce el alcance, está dando a entender que se conoce la implementación. Si este es el caso, no tiene necesidad de pivotar, adaptarse o aprender. Aún puede obtener beneficios de la entrega de valor iterativo, pero eso es todo. Has eliminado todos los riesgos posibles. Si ese es el caso, claro, el enfoque adaptativo de Agile no le dará nada y le costará más, pero nunca en mi carrera había visto un proyecto de infraestructura como este, así que tengo miedo de la premisa.
Los valores y prácticas ágiles pueden ayudar a cualquier proyecto, pero las colas de soporte y el trabajo no iterativo no encajan de forma natural. ¿Qué problemas está tratando de resolver con su marco seleccionado? Hago proyectos de infraestructura ágiles todo el tiempo, pero estoy optimizando el alcance, la transparencia y los circuitos de retroalimentación estrechos.
Habiendo estado involucrado en varios proyectos de infraestructura, tratando de calzarlos en uno de los marcos iterativos populares (normalmente Scrum), el equipo del proyecto puede volverse loco. Intentan ajustar plazos arbitrarios que no coinciden con las actividades de migración y adoptan el formato de historia de usuario, lo cual es muy difícil. Sin embargo, la pregunta es demasiado amplia en la actualidad. La agilidad es, sobre todas las cosas, un sentido de escala. Incluso los proyectos de infraestructura utilizan un formato MVP para probar y aprender. No migramos TODOS los datos; migramos una aplicación de prueba o un cubo de datos y aprendemos de ellos.

Respuestas (3)

Agile/Scrum no es adecuado para el trabajo predecible

Por favor vea mi respuesta a una pregunta similar anterior .

Las metodologías y los marcos ágiles se adaptan mejor cuando los requisitos no se pueden establecer completamente por adelantado o tienden a cambiar con frecuencia.

Como usted mismo ha señalado:

el alcance no cambia, la mayor parte del proyecto se ejecutará desde Runbook

Todos sus ejemplos son proyectos predictivos:

  1. Migración/reubicación del centro de datos
  2. Migración SAN
  3. Para la solución de telepresencia de Cisco
  4. Proyectos de telefonía

No se trata de si la agilidad es posible:

Si no es posible, ¿eso significa que el proyecto de infraestructura lo realiza principalmente Waterfall?

Es una cuestión de qué proceso es el más adecuado. Si puede crear una WBS (estructura de descomposición del trabajo), identificar dependencias, asignar recursos y hacer que sigan el plan, el proceso en cascada es el más adecuado para ese tipo de trabajo.

¿Es posible usar Agile en proyectos donde el alcance se conoce por adelantado ? Sí.

¿Es el mejor enfoque ? Quizás.

Todo se reduce a cuánta incertidumbre enfrentará a lo largo de la implementación y cuánto valor puede ofrecer de forma incremental .

Por ejemplo, al configurar un proyecto de video conf, ¿sabes...?

  • si la red será capaz de soportar la nueva demanda?
  • esta nueva demanda será estable en diferentes oficinas?
  • en caso de que necesite cambiar su proveedor de red en una ubicación determinada, ¿sabe cómo proceder?

Si todo lo anterior va a ser entregado "por el libro", entonces vaya con cascada. Por otro lado, puede encontrar beneficios en el enfoque incremental que ofrece Agile, ya que puede configurar una parte inicial de la estructura para algunas oficinas mientras aborda los problemas en otras oficinas.

Tómese esto con pinzas: ágil se trata de entregas incrementales . Si hay una fecha de compromiso firme (debido a algún factor externo, por ejemplo), es posible que desee ceñirse a la Cascada que le dará más capacidad para cubrir su parte del proyecto de eventuales dependencias externas.

El enfoque Lean Agile Kanban se adapta mejor a las operaciones y el mantenimiento que un enfoque Scrum. Una gran diferencia es que Kanban no tiene casillas de tiempo fijas. El trabajo pasa de un trabajo atrasado a Trabajo en progreso a Terminado. El concepto clave es limitar el trabajo en curso. Esto evita que ocurran demasiadas tareas simultáneas a la vez. Haz 2 o 3 cosas a la vez, no 17 cosas a la vez. Reduzca el cambio de contexto y realice cada tarea más rápido.

Como ejemplo: El Departamento de Vehículos Motorizados tiene una cola de entrada única, luego 1 WIP para cada empleado, luego Listo. Un empleado lo lleva desde su solicitud inicial hasta el final. Sin limitar WIP, cada empleado atendería a todos en la fila a la vez. Su tiempo en el DMV sería mucho más largo.

¿Es posible usar Agile en proyectos de infraestructura donde el alcance se conoce por adelantado?
RespuestasAquíPolítica de privacidad1y, 0v