Uso de Scrum para la migración de clientes en productos ya activos

¿Vale la pena trabajar en sprints de 2 semanas, y al estilo Scrum, para un proyecto de migración de un cliente de un sistema heredado a un sistema que ya está activo y con otros clientes (un software de marca blanca)?

Me parece algo inútil tratar de encajar las tareas en sprints de 2 semanas, ya que se entreguen o no, nadie se quejará (dado que el cliente ya está activo en un software heredado). El único efecto será mover la fecha de migración (que ha sido establecida por un administrador de proyectos) a una fecha anterior o posterior, que se revisa cada 2 semanas.

Creo que un estilo Kanban es más apropiado, ya que se conoce la carga de trabajo (sin sorpresas ni áreas para explorar) y tomará el tiempo que sea necesario para entregar el software. No hay funcionalidad añadida como lo sería con lanzamientos incrementales en Scrum, porque el cliente todavía está en el sistema heredado. ¿Alguien puede proporcionar alguna razón a favor o en contra del uso de Scrum para la migración de clientes de productos heredados a nuevos productos en vivo?

Votado a favor. Pregunta muy interesante.
En un mundo de constante migración de sistemas, ¡me sorprende que este tema no se haya discutido lo suficiente!

Respuestas (2)

Siendo un evangelista Agile, no puedo creer que esté a punto de escribir esto, pero me pregunto si Agile en sí mismo es realmente necesario para usted. En mi opinión, el objetivo principal de Agile es hacer frente a los requisitos cambiantes. Si sabe de antemano que todos sus requisitos son estáticos, entonces... no tiene mucho sentido.

Para Scrum, ciertamente, esto podría ser excesivo. ¿Cómo crearía/priorizaría las historias el propietario del producto? ¿Cómo planearías las historias? ¿Cómo vas a obtener un producto que se pueda enviar al final de cada Sprint? ¿Cómo harías una demostración de las historias en cada Sprint? ¿A quién se los demostrarías? A menos que pueda responder a todas esas preguntas, considere la posibilidad de que Scrum sea una sobrecarga innecesaria.

Por supuesto, es posible que aún desee optar por Kanban, en lugar de abandonar Agile por completo. Sus límites de trabajo en curso aún proporcionarían beneficios, incluso en lugar de cambios en los requisitos. Del mismo modo, si su equipo está acostumbrado a Agile, también puede quedarse con él; Kanban es bastante ligero, con muy pocos gastos generales.

Gracias por tus comentarios, son muy válidos. Entonces, para responder a sus preguntas: el PO obtiene una transferencia de los BA que han firmado los requisitos comerciales con el cliente para migrar, es decir, qué elementos del software quiere. Luego pasan al PO que crea epopeyas e historias y establece la acumulación. No tenemos un producto que se pueda enviar al final del sprint, simplemente tenemos una adición, pero no todo está en vivo. Todavía demostramos historias a los encargados de la carne, es decir, BA y nuestro departamento interno que finalmente utiliza el producto.
Además, la priorización se basa en "¿qué funcionalidad necesitamos habilitar para que funcione la próxima funcionalidad?". Por ejemplo, debe habilitar la conectividad API para luego invocar el servicio. Ambos existen, solo hay que configurarlos para cada cliente.
El propósito de Agile es hacer frente a las circunstancias cambiantes , no solo a los requisitos cambiantes. ¿Qué pasa si los desarrolladores no se encuentran bien? ¿Qué pasa si una historia o tarea en particular termina siendo más complicada de lo que se pensó en un principio? E incluso con una migración como esta, algunas suposiciones e incluso requisitos inevitablemente cambiarán en algún momento.

Ciertamente hay valor en el uso del enfoque Scrum.

El propietario del producto priorizaría el trabajo pendiente en función de las características del sistema que son más valiosas.

La entrega sería frecuente y de un sistema en funcionamiento (aunque no con todas las funciones completas hasta el final).

El valor que obtienes de esto es:

  • Transparencia del progreso. A medida que el equipo ofrece funciones de trabajo, el cliente gana confianza.
  • La capacidad de brindarle al cliente un cronograma que se actualiza para que coincida con el progreso logrado en el mundo real.
  • La capacidad de realizar pruebas continuas en un entorno de producción (incluidas las pruebas de aceptación del usuario para garantizar que el nuevo sistema coincida con el sistema heredado). Ayudar a eliminar el riesgo de la entrega al evitar dejar las pruebas para el final del proyecto.
  • Todos los demás beneficios de Scrum: el equipo autoorganizado, retrospectivas, cadance, etc.
  • La priorización de características mueve las características menos valiosas al final del proyecto, haciéndolo menos crítico.
Tal vez no fui lo suficientemente claro: el software central está en vivo (con otros clientes). El cliente existente que se va a migrar no vive en este software, vive en el legado. Cuando se complete el proyecto de migración, el cliente se pondrá en marcha con el nuevo producto. Así que hasta ahora estamos construyendo iteraciones y las mantenemos en un entorno de control de calidad. El cliente son nuestros equipos internos que finalmente lo utilizarán. Ni siquiera les hacemos demostraciones porque las cosas son muy técnicas y no pueden entenderlas. Además, no hay cosas del sistema más o menos valiosas para priorizar, hay un MVP conocido.
Luego, debe llevarlos al nuevo software tge y adaptar empíricamente ese software para satisfacer sus necesidades.