¿Cómo funciona ágil cuando se reemplaza un sistema en funcionamiento?

13

En un mundo ágil ideal, rápidamente construye un subconjunto pequeño pero útil del sistema final deseado y se lo da a los usuarios. Están entusiasmados, porque es útil, comienzan a usarlo y dan su opinión. Luego, averigua qué agregarle, construye eso y repite hasta que se te acabe el tiempo.

Recientemente he tenido un par de proyectos que implicaron reemplazar algún tipo de sistema de trabajo. El modelo anterior simplemente no funcionó en absoluto: hasta que construyó un sistema que incluía prácticamente todas las funciones del sistema existente, los usuarios no tenían ningún interés en absoluto. Ellos no lo usarían.

¿Cómo se aplica Agile cuando "el subconjunto útil más pequeño" es "todo"?

    
pregunta Steve Bennett 02.05.2012 - 06:40

7 respuestas

13

La solución ágil podría ser no para reemplazar todo de una vez, sino para ir cambiando gradualmente el reemplazo.

Introduzca el nuevo sistema gradualmente, poco a poco, manteniendo partes del antiguo sistema en funcionamiento. El sistema antiguo no se apaga de una sola vez, simplemente se desvanece. Las nuevas partes proporcionan una nueva funcionalidad u otros beneficios, por lo que los usuarios están encantados de usarlas. Esto también es menos riesgoso, ya que tiene un sistema que funciona al 100% en todo momento.

respondido por el MarkJ 02.05.2012 - 13:37
5

En lugar de volver a escribir el sistema existente (que, como usted mencionó, requerirá bastante esfuerzo antes de que el nuevo sistema coincida con la funcionalidad existente), considere la vid estranguladora enfoque. Básicamente, implementa una nueva funcionalidad utilizando su nuevo enfoque sobre la aplicación existente. Finalmente, a medida que aborda las deficiencias del sistema antiguo para abordar la nueva funcionalidad, el nuevo código reemplazará completamente al anterior.

Esto requiere más precisión y esfuerzo que un "reinicio" de la aplicación anterior. Pero tienes un tiempo más corto para ROI. Además, siguiendo el proceso, puede colocar ganchos en su lugar para permitir que el "nuevo" sistema se pueda estrangular más fácilmente con el siguiente "nuevo" sistema.

    
respondido por el Michael Brown 02.05.2012 - 14:58
4

La liberación de pequeños incrementos en el mundo podría funcionar para proyectos greenfield, pero incluso entonces la pequeña cantidad de funciones podría no ser demasiado útil.

Scrum aboga por que después de cada sprint el producto sea "Potencialmente enviable". No tiene que ser enviado, sino que debe tener la calidad de un producto que se puede enviar.

Si desea darles a los usuarios una versión incremental de la aplicación, puede clasificarla como Alfa, luego Beta y luego lanzar las versiones de Candidato mientras se sigue usando la aplicación de Producción real.

Es posible que las nuevas funciones se agreguen y las antiguas se eliminen si incorpora comentarios de los usuarios.

    
respondido por el aqwert 02.05.2012 - 07:07
2

Todavía creo que Agile agrega mucho valor en este escenario.

Es solo que tienes un objetivo final muy definido de "reemplazar el sistema actual".

Las técnicas y los procesos ágiles aún pueden llevarte allí de manera más efectiva.

Por ejemplo:

Todavía puede entregar el sistema de manera iterativa y en pequeños sprints.

Aún puedes usar técnicas ágiles para priorizar el trabajo después de comunicarte con las personas clave.

Todavía puedes usar ágil para planear basado en la velocidad observada.

Aún puede utilizar técnicas y filosofías ágiles como la difusión de conocimientos, TDD, codificación limpia para mejorar la calidad y el diseño interno del proyecto.

Si tiene personas que realmente están "no interesadas" en el proyecto y no están comprometidas con el proyecto hasta que tengan un reemplazo perfecto, tiene un problema mayor, independientemente de si está utilizando cascada, ágil o cualquier otro proceso.

    
respondido por el Benjamin Wootton 02.05.2012 - 14:13
2

Trabajé en una línea masiva de reemplazo de aplicaciones comerciales para una importante red nacional de televisión por cable. El nuevo desarrollo del sistema se realizó con SCRUM, se trató de un proyecto de desarrollo de 18 a 24 meses para volver a implementar casi todos los subsistemas principales; Que se acercaban a los 10 años.

Hubo una fase de planificación de unos 6 meses antes de que comenzara el desarrollo, pero también se abordó como SCRUM. Aquí es donde el propietario del producto escribió tiendas de alto nivel y épicas después del análisis del sistema existente y de las entrevistas a los clientes.

El sistema existente era extremadamente estable ya que entró en modo de mantenimiento crítico; solo se solucionaron los problemas de mostrar detenciones, todo se registraba con fines históricos y para garantizar que los mismos problemas no aparecieran en el nuevo sistema.

El nuevo sistema evolucionó como se describe en un proceso Agile, en su mayor parte fue extremadamente suave. Cuando el sistema de reemplazo alcanzó la función parcial, no entró en producción, sino en pruebas de producción paralelas. Un subconjunto de trabajadores no críticos comenzó a usar los sistemas ambos , para validar que el nuevo sistema se comportó como el anterior; con los viejos errores arreglados, por supuesto.

Cuando el nuevo sistema logró completar casi el 100% de las nuevas funciones, se implementó para ejecuciones generales de producción paralela, que duró un par de meses.

Una vez que el cliente consideró que satisfacía sus necesidades, se hizo una copia de seguridad del sistema antiguo, se apagó y se sentó. Supongo que han vuelto a utilizar el hardware del sistema anterior porque nunca tuvieron que volver al sistema anterior después de cortarlo.

    
respondido por el Jarrod Roberson 02.05.2012 - 18:52
0

Si tengo un auto viejo y oxidado que necesito conducir para ir al trabajo, y voy al concesionario a comprar un auto nuevo. El modelo que quiero está agotado, así que tienen que pedirlo de fábrica y tardará un poco en llegar.

El comerciante, entonces, por buena fe, decide darle el bloqueo del motor del automóvil hasta que entre el automóvil que ordenó. ¿Qué se supone que debe hacer con el motor de un automóvil? Claro que puedo conectar algunos componentes para probarlo y hacer que funcione, pero realmente no me ayuda a trabajar mañana, donde lo hace el viejo coche oxidado.

Concedido, hay un llanto lejos diferente entre construir un automóvil y crear software personalizado, pero ignoremos eso por el bien de la discusión. El objetivo de la historia es no dejar perplejo que el cliente no encuentre uso para cambios incrementales cuando ya tiene un software que es lo suficientemente bueno para hacer el trabajo ahora. Ya llena su necesidad por el momento.

Esto no quiere decir que Agile no sea una parte importante del proceso aquí porque permite una retroalimentación continua al cliente sobre el estado del proyecto. Pueden garantizar que se están logrando avances antes de los hitos y productos principales. Pueden identificar problemas y problemas potenciales antes de que se convierta en un error demasiado costoso de solucionar.

Tal vez, como cliente del automóvil, solo quiera mirar y evaluar el motor para asegurarse de que realmente va a obtener lo que anticipó. ¡Vaya, en realidad quería un motor de 6 cilindros en lugar del motor de 4 cilindros! ¿No te lo dije antes? No hay problema, pongamos un cambio en el pedido de fábrica.

Venda la idea a los clientes de que les interesa utilizar las nuevas versiones de software, no como un reemplazo todavía, sino para evaluarlas y asegurarse de que estén satisfechos con cada paso en el camino.

    
respondido por el maple_shaft 02.05.2012 - 13:24
0

Funciona igual, pero este enfoque será más difícil de vender a los usuarios existentes. Es posible que no quieran el nuevo sistema y no quieran interrumpirse con pruebas periódicas. Quieren esperar el mayor tiempo posible y luego simplemente probarlo al final. La mayoría de los usuarios se sienten así hasta cierto punto, pero depende de los responsables educarlos. En su opinión, estás trabajando con una aplicación existente, por lo que debes saber qué se supone que debe hacer, ¿por qué molestarlos?

Hazles entender que no quieres hacerlo de esta manera porque crees que será divertido y te sentirás solo usando un proceso de cascada. Será una mejor aplicación a largo plazo.

Un punto clave de venta puede ser implementar ese cambio durante la creación de la nueva aplicación que siempre han deseado, pero que nunca pudo ingresar al sistema anterior.

    
respondido por el JeffO 02.05.2012 - 19:40

Lea otras preguntas en las etiquetas