En un mundo ágil ideal, construye rápidamente 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 determina qué agregarle, construye eso y repite hasta que se acabe el tiempo.
Recientemente tuve un par de proyectos que implicaron reemplazar algún tipo de sistema de trabajo. El modelo anterior simplemente no funcionó en absoluto: hasta que haya construido un sistema que incluyera prácticamente toda la funcionalidad del sistema existente, los usuarios no tenían ningún interés en absoluto. No lo usarían.
¿Cómo se aplica Agile cuando "el subconjunto útil más pequeño" es "todo"?
agile
scrum
users
iterative-development
Steve Bennett
fuente
fuente
Respuestas:
La solución ágil podría ser no reemplazar todo de una vez, sino escalonar el reemplazo gradualmente.
Introduzca el nuevo sistema gradualmente, poco a poco, manteniendo partes del antiguo sistema en funcionamiento. El viejo sistema no se apaga de una 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 100% de trabajo en todo momento.
fuente
En lugar de volver a escribir el sistema existente (que, como mencionó, tomará bastante esfuerzo antes de que el nuevo sistema coincida con la funcionalidad existente), considere el enfoque de estrangulamiento de la vid . Básicamente, implementa una nueva funcionalidad utilizando su nuevo enfoque sobre la aplicación existente. Eventualmente, a medida que aborde las deficiencias del sistema anterior para abordar la nueva funcionalidad, el nuevo código reemplazará por completo al anterior.
Esto requiere más precisión y esfuerzo que un "reinicio" de la aplicación anterior. Pero obtienes un tiempo más corto para el ROI. Además, siguiendo el proceso, puede colocar ganchos en su lugar para permitir que el "nuevo" sistema estrangule más fácilmente el "nuevo" sistema.
fuente
Publicar pequeños incrementos en el mundo podría funcionar para proyectos nuevos, pero incluso entonces el pequeño número de características podría no ser demasiado útil.
Scrum defiende que, después de cada sprint, el producto sea "potencialmente enviable". No tiene que enviarse, pero 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, Beta y, a continuación, Liberar versiones candidatas, mientras todavía se utiliza la aplicación de Producción real.
Es posible que se agreguen nuevas funciones y se eliminen las antiguas si incorpora comentarios de los usuarios.
fuente
Trabajé en una línea masiva de reemplazo de aplicaciones comerciales para una importante red nacional de televisión por cable. El desarrollo del nuevo sistema se realizó con SCRUM, se trataba de un proyecto de desarrollo de 18-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 consideró SCRUM. Aquí es donde el propietario del producto escribió tiendas de alto nivel y epopeyas después del análisis del sistema existente y de entrevistar a los clientes.
El sistema existente era extremadamente estable cuando entró en modo de mantenimiento crítico; solo se corrigieron los problemas de show stopper, todo se registró para fines históricos y para asegurarse de que no aparecieran los mismos problemas en el nuevo sistema.
El nuevo sistema evolucionó como se describe en un proceso ágil, fue extremadamente suave en su mayor parte. Cuando el sistema de reemplazo alcanzó la partición característica, no entró en producción, sino en pruebas de producción paralelas. Un subconjunto de trabajadores no críticos comenzó a usar ambos sistemas para validar que el nuevo sistema se comportaba como el anterior; con los viejos errores corregidos, por supuesto.
Cuando el nuevo sistema logró casi el 100% de nuevas características completas, se implementó para ejecuciones de producción paralelas generales, que duraron un par de meses.
Una vez que el cliente consideraba que satisfacía sus necesidades, se hacía una copia de seguridad del sistema antiguo, se apagaba y se sentaba. Supongo que han vuelto a utilizar el hardware del sistema anterior porque nunca necesitaron volver al sistema anterior después del corte.
fuente
Todavía creo que ágil agrega mucho valor en este escenario.
Es solo que tiene un objetivo final muy definido de 'reemplazar el sistema actual'.
Las técnicas y procesos ágiles aún pueden llevarlo allí de manera más efectiva.
Por ejemplo:
Todavía puede entregar en el sistema de forma iterativa y en pequeños sprints.
Todavía puede usar técnicas ágiles para priorizar el trabajo después de comunicarse con las personas clave.
Todavía puede usar ágil para planificar en función de la velocidad observada.
Todavía 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 no están 'interesadas' en el proyecto y no se involucran con el proyecto hasta que tengan un reemplazo perfecto, tiene un problema mayor independientemente de si está utilizando una cascada, un proceso ágil o de hecho algún proceso.
fuente
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 que no quieran ser interrumpidos con pruebas periódicas. Quieren esperar el mayor tiempo posible y luego probarlo al final. La mayoría de los usuarios se sienten así hasta cierto punto, pero depende de los encargados educarlos. En su opinión, está trabajando con una aplicación existente, por lo que debe 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 sientes solo usando un proceso de cascada. Será una mejor aplicación a largo plazo.
Un punto de venta clave puede ser implementar ese cambio durante la construcción de la nueva aplicación que siempre han querido, pero que nunca pudieron entrar en el sistema anterior.
fuente
Si tengo un auto oxidado que necesito conducir para ir a trabajar, voy al concesionario a comprar un auto nuevo. El modelo que quiero está agotado, por lo que tienen que pedirlo en la fábrica y pasará un tiempo antes de que entre.
El concesionario entonces, de 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 auto oxidado.
De acuerdo, hay una diferencia muy diferente entre construir un automóvil y crear un software personalizado, pero ignoremos eso en aras de la discusión. El punto de la historia no es dejar perplejo que el cliente no encuentre uso para cambios incrementales cuando ya tienen un software que es lo suficientemente bueno como 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 avanza antes de los principales hitos y entregables. Pueden identificar problemas y problemas potenciales antes de que sea 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 obtendrá lo que esperaba. ¡Vaya, en realidad quería un motor de 6 cilindros en lugar del motor de 4 cilindros! ¿No te dije eso antes? No hay problema, pongamos un cambio en el pedido de fábrica.
Venda la idea a los clientes de que lo mejor para ellos es utilizar las nuevas versiones de software no como un reemplazo todavía, sino para evaluarlo y asegurarse de que estén contentos con cada paso del camino.
fuente