Reescritura de software utilizando metodologías ágiles

Supongamos que tiene que reescribir una aplicación completa utilizando metodologías ágiles, ¿cómo lo haría?

Supongo que podrías escribir una gran cantidad de historias de usuarios basadas en el comportamiento de tu sistema actual. Y luego implementarlos en pequeñas iteraciones. Pero esto no quiere decir que tenemos los requisitos en la delantera ??

Además, ¿cuándo comenzarías a lanzar? Agile dice que deberíamos lanzar temprano y con frecuencia, pero no tiene mucho sentido lanzar antes de que se haya completado la reescritura completa.

Divídalo en epopeyas de alto nivel. Tome cada área funcional de la aplicación, un paso a la vez.

Divide una epopeya en un grupo de historias (fragmentos utilizables, cualquier cosa que mejore la aplicación) y adminístralas como lo harías si no tuvieras una aplicación existente, con una excepción: si es posible, hazlo para que puedas puede implementar esa única funcionalidad como parte o junto a la aplicación original.

Cuando los agilistas dicen "liberar temprano y con frecuencia", eso no necesariamente significa producción. Si va a reemplazar una aplicación existente, debe usar un área de preparación para lanzar con frecuencia y asegurarse de que sus usuarios estén probando el sistema allí. Esto aún les dará espacio para priorizar el próximo trabajo y para asegurarse de que nada de lo que liberen a la producción deprecia el producto.

Una vez que haya lanzado un componente a producción, pase al siguiente.

acabamos de pasar por tal experiencia (yo como propietario del producto scrum). Nos llevó dos años llegar a algo liberable. Pero aún así, ágil nos trajo muchos beneficios.

Primero: una reescritura total no es, por naturaleza, ágil en absoluto. En su lugar, debería considerar refactorizar el producto existente pieza por pieza. Eso ha sido discutido en otra pregunta. Así que supongamos que tiene que ser una reescritura.

Entonces, de hecho, comienza con un registro de respaldo que cubre todos los casos de uso relevantes del producto existente. Pero por favor no lo aborde como especificaciones de escritura. Eso sería demasiado detalle. Debe estar completo (de lo contrario, no puede hacer la planificación de lanzamiento). Y no debería ser demasiado elaborado (de lo contrario, está escribiendo especificaciones por adelantado). Así es como nos acercamos a eso:

• categorizar a los usuarios del producto anterior. Identifique a los usuarios que solo necesitan una pequeña parte del producto anterior y aún así obtengan algo útil. Definen tus primeras epopeyas.

• Luego agregue epopeyas que permitirían a otra categoría de usuarios pasar al nuevo producto. Etc. hasta que tenga un registro de respaldo que cubra a todos los usuarios.

• Lo más probable es que estas epopeyas necesiten más división. Si es posible, intente dividir para que cada parte todavía tenga algún valor. Si eso no es factible, entonces al menos asegúrese de que cada parte se pueda demostrar.

• cuando tengas entre 20 y 50 epopeyas, haz que el equipo las calcule.

• divida las mejores epopeyas en Historias de usuarios que el equipo cree que son factibles dentro de un sprint. No hagas eso para todas las epopeyas todavía, solo las de arriba. Tendrás mucho tiempo para dividir el resto.

¡Cuándo liberar externamente! Esa es una decisión comercial. Al menos este enfoque le brinda la oportunidad de lanzar antes a ciertas categorías de usuarios. Eso puede ser útil si la gerencia se pone nerviosa por este proyecto aparentemente interminable.

Suelte ahora si puede

Su pregunta sobre cuándo comienza a publicar el código es excelente. Creo que se aplican dos condiciones. Primero, que tiene "calidad suficientemente buena", y segundo que cumple con los requisitos para un MVP (producto mínimo viable).

Roma (y ágil) no se construyeron en un día

Tal vez esté listo con un equipo ágil llave en mano para hacerse cargo el primer día. Para la mayoría de las organizaciones, existe el trabajo y el gasto de la capacitación, la reestructuración y el ciclo habitual de formación, asalto y normalización de la creación de un equipo. Sea directo sobre los riesgos y los costos, tenga cuidado de establecer expectativas realistas, y esté preparado para defender su enfoque.

Sé un Bootstrapper de reutilización

Al igual que el poder de fusión, la reutilización de código es y siempre será la solución futura a nuestros problemas económicos. Creo que los desarrolladores a menudo dicen que creen en la reutilización, pero solo en el tipo de reutilización que comienza después de construir un nuevo marco, en lugar del tipo en el que construyen sobre lo que otra persona ya ha hecho. ¿Cómo puede funcionar eso hasta que alguien esté dispuesto a elegir construir sobre los cimientos de otra persona? En el mejor de los casos, significa una reescritura cada pocos años cuando cambia el liderazgo del equipo.

¿Por qué liberar temprano y con frecuencia?

Salir temprano y con frecuencia es un mantra por muchas razones. Da vida a nuestras discusiones sobre en qué debería convertirse el producto, hace real dónde estamos y nos da una base para cambios iterativos / incrementales. El ritmo de los lanzamientos es prácticamente invariable para ágil, con la diferencia de quién recibe los lanzamientos (sustitutos del cliente o usuarios finales). Antes de ágil, se estimaba que el mantenimiento representaba el 60% del costo de los sistemas de software. Esta es una fuente de mucha consternación para los gerentes y otros, algunos que sienten que el lanzamiento del producto es donde el software va a morir. Para ellos, todo después del lanzamiento es volver a trabajar y pagar para arreglar un producto que ya pagaron una vez.

El prelanzamiento no es natural

Kent Beck escribe que el prelanzamiento es un estado antinatural para los productos de software. Ciertamente es un momento inconveniente porque es un momento en el que no tiene clientes y está pagando por el producto en lugar de que el producto lo pague por usted.

No critiques al equipo anterior

Si bien podría configurar a los desarrolladores que se hacen cargo de la reescritura como héroes y salvación del proyecto, creo que hay un costo en criticar los logros del equipo anterior.

• Primero, si dejas que las personas decidan sobre el equipo anterior, tienes más tiempo y energía para tu verdadera misión.
• Será incómodo si necesita trabajar con miembros del equipo anterior, tanto desarrolladores como partes interesadas, como gerentes de producto, gerentes de proyecto o clientes.
• Si puede hacer que funcione, puede encontrarse recibiendo (o peor aún, tomando) crédito por lo que hizo el equipo anterior.
• En promedio, el equipo anterior fue probablemente promedio. En promedio, puede ser promedio. Tiene más trabajo que el equipo anterior porque tiene una nueva metodología para implementar además de un proyecto.
• Si el equipo anterior era horrible, a menos que usted también sea horrible, eventualmente obtendrá crédito por ser mejor que horrible. Si fueron mejores que horribles, y usted no es notablemente mejor, decir que fueron horribles puede provocar comparaciones desagradables.
• Si el equipo anterior era mejor de lo que pensabas, y te metes en problemas porque la organización está rota o el problema está mal definido o es muy difícil, las cosas te irán mejor si no has elevado significativamente las expectativas.
• Si esperan lo que estaban obteniendo, pero lo haces mejor, es una victoria para ti.
• Abstenerse de criticar es a la vez buenos modales y demuestra que tienes clase.

Impulsado por los comentarios de @Chuck y las referencias a Netscape que esencialmente dicen no reescribir, y las respuestas válidas replican que OP no está preguntando si debería hacerlo. - Un ciclo de desarrollo de software verdaderamente ágil impide la reescritura. La reescritura casi siempre rompe muchos de los principios detrás de Agile. Usando el software actual como línea base, estos principios ágiles (del Manifiesto Ágil ) no se pueden cumplir con una reescritura.

• Entrega temprana y continua de software valioso . - el cliente no obtendrá un valor inicial cuando se compara con lo que ya tiene
• Entregue software de trabajo con frecuencia , de semanas a meses, cuán grande es el proyecto, puede decir honestamente que el cliente obtendrá algo más útil para ellos en el corto plazo.
• El software de trabajo es la medida principal del progreso : el trabajo en comparación con la línea de base no se realizará rápidamente.
• Los procesos ágiles promueven el desarrollo sostenible. - Dado que el cliente tiene una línea de base funcional, se ejercerá presión para ofrecer una funcionalidad mejorada. Es poco probable que esto se haga a un ritmo sostenible
• La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. esto lo dice todo realmente ...

"Supongamos que tiene que volver a escribir una aplicación completa utilizando metodologías ágiles, ¿cómo lo haría?"

La pregunta se basa en una premisa falsa: que una reescritura puede considerarse ágil.

Considere si puede lanzar la aplicación reescrita pieza por pieza y tenerla en producción junto con la anterior.

Para las aplicaciones web en particular, puede ser bastante fácil mover una sola parte de la aplicación a una nueva plataforma y hacer que sus solicitudes de ruta del equilibrador de carga se dirijan al sistema apropiado. Luego, escriba las historias que le permitirán poner en producción su primera página y entregarlas de manera ágil.

Las aplicaciones de escritorio pueden ser más complicadas, pero a menudo será posible.

Está buscando costuras, lugares donde es posible que el nuevo sistema asuma sus responsabilidades por el nuevo, sin necesidad de una reescritura completa.

Quizás haya una lógica empresarial autónoma que se pueda mover a un nuevo servicio web o marco, y la aplicación anterior se pueda modificar para usarla en lugar de su código anterior. Solo sigue cortando trozos en las costuras hasta que lo que quede sea manejable de una sola vez.

Si no puede encontrar ninguna costura, entonces es posible que deba buscar el tipo de enfoque de big bang sugerido en algunas de las otras respuestas. Pero prepárate para una larga marcha antes de llegar a tu destino, especialmente si se espera que sigas desarrollando el viejo sistema en paralelo ...

Agile dice que deberíamos lanzar temprano y con frecuencia, pero no tiene mucho sentido lanzar antes de que se haya completado la reescritura completa.

En realidad, en mi humilde opinión, este es el punto clave: cuanto antes obtenga partes de la aplicación reescrita en producción (e idealmente reemplace la funcionalidad del sistema anterior), mayores serán las posibilidades de que su proyecto tenga éxito. Si cree que esto no tiene mucho sentido, piense más al respecto: casi siempre hay posibilidades de liberar piezas.

Probablemente significará que alguien tiene que cambiar algo en la aplicación anterior, por ejemplo, agregar algunas interfaces nuevas para interactuar con la aplicación reescrita durante el tiempo que la reescritura no está completa. Pero, según mi experiencia, ese trabajo adicional siempre se paga solo.

Una vez que las primeras partes de la nueva aplicación estén en producción, el enfoque ágil e iterativo se hará evidente. Los requisitos cambiarán, sus historias de usuario cambiarán u obtendrán nuevas prioridades y, con suerte, reemplazará cada vez más funcionalidades del sistema antiguo en pequeños pasos.