Reescribiendo software usando metodologías ágiles

13

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

Supongo que podrías escribir un gran número de historias de usuarios basadas en el comportamiento de tu sistema actual. Y luego implementarlos en pequeñas iteraciones. Pero esto no significa que tengamos los requisitos UP FRONT ??

También, ¿cuándo empezarías a lanzar? Agile dice que deberíamos lanzarlo temprano y con frecuencia, pero no tiene mucho sentido lanzarlo antes de que se complete la reescritura completa.

    
pregunta Asier Barrenetxea 31.10.2012 - 23:51

6 respuestas

15

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

Divida una épica en un grupo de historias (fragmentos utilizables, cualquier cosa que mejore la aplicación) y adminístrelos como lo haría si no tuviera una aplicación existente, con una excepción: si es posible, hágalo para que pueda implementar esa pieza de funcionalidad como parte de, o junto a, la aplicación original.

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

Una vez que hayas lanzado un componente a producción, muévete al siguiente.

    
respondido por el pdr 01.11.2012 - 00:18
10

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

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

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

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

  • Luego, agregue épicas que permitan a otra categoría de usuarios moverse al nuevo producto. Etc. hasta que tenga un registro de vuelta que cubra a todos los usuarios.

  • muy probablemente, estas epopeyas necesitarán más división. Si es posible, intente dividir para que cada parte tenga algún valor. Si eso no es posible, al menos asegúrese de que cada parte pueda demostrarse.

  • cuando tengas 20-50 épicas, haz que el equipo las calcule.

  • divide las mejores épicas en historias de usuarios que el equipo cree que son factibles dentro de un sprint. No hagas eso para todas las epopeyas, solo las que están arriba. Tendrás mucho tiempo para repartir el resto.

Cuándo lanzar externamente! Esa es una decisión de negocios. Al menos este enfoque le da la oportunidad de lanzar antes a ciertas categorías de usuarios. Eso puede ser útil si la administración se pone nerviosa por este proyecto que parece no tener fin.

    
respondido por el Kris Van Bael 01.11.2012 - 00:26
4

Liberar ahora si puedes

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

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

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

Sea un Bootstrapper de reutilización

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

¿Por qué lanzar temprano y con frecuencia?

Liberar temprano y con frecuencia es un mantra por muchas razones. Da vida a nuestras discusiones sobre lo que el producto debería convertirse, hace real donde estamos y nos da una base para cambios iterativos / incrementales. El ritmo de los lanzamientos es prácticamente invariable para Agile, con la diferencia de quién recibe los lanzamientos (sustitutos de clientes 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 gran consternación para los gerentes y otros, algunos que creen que el lanzamiento del producto es donde el software va a morir. Para ellos, todo después del lanzamiento es un trabajo y un pago por arreglar un producto que ya pagaron una vez.

La versión preliminar no es natural

Kent Beck escribe que la versión preliminar es un estado antinatural para los productos de software. Sin duda, es un momento inconveniente porque es un momento en el que no tiene clientes y está pagando por el producto en lugar de pagar por el producto.

No critique al equipo anterior

Aunque podría configurar a los desarrolladores que se encargan 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 se decidan por 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 de desarrolladores como de partes interesadas como gerentes de productos, gerentes de proyectos o clientes.
  • Si puedes hacer que funcione, puedes encontrarte recibiendo (o, peor aún, tomar crédito) por lo que hizo el equipo anterior.
  • En promedio, el equipo anterior probablemente fue promedio. En promedio, usted podría ser promedio. Tiene más trabajo que el equipo anterior porque tiene una nueva metodología que implementar además de un proyecto.
  • Si el viejo equipo era horrible, a menos que tú también seas horrible, eventualmente obtendrás crédito por ser mejor que horrible. Si fueran mejores que horribles, y usted no es notablemente mejor, decir que eran horribles podría invitar a 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 irán mejor si no has aumentado significativamente las expectativas.
  • Si esperan lo que obtuvieron, pero lo haces mejor, es una victoria para ti.
  • Abstenerse de criticar es a la vez buenos modales y muestra que tienes clase.
respondido por el DeveloperDon 01.11.2012 - 03:21
2

Lo pidieron los comentarios de @Chuck y las referencias a Netscape que básicamente dicen que no se reescriben, y que las respuestas válidas respondieron que el 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. Al utilizar el software actual como una línea de base, estos principios Agile (de Manifiesto Agile ) no se pueden cumplir con una reescritura.

  • Entrega temprana y continua de software valioso . - el cliente no obtendrá un valor inicial cuando se lo compare con lo que ya tiene
  • Entregar software en funcionamiento con frecuencia - semanas a meses - ¿qué tan grande es el proyecto? Honestamente, puede decir 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 producirá de inmediato
  • Los procesos ágiles promueven el desarrollo sostenible. - Dado que el cliente tiene una línea de base de trabajo, la presión será para proporcionar una funcionalidad mejorada. Es poco probable que esto se haga a un ritmo que sea sostenible.
  • La simplicidad, el arte de maximizar la cantidad de trabajo no hecho, es esencial. esto lo dice todo realmente ...
  

"Supongamos que tienes que reescribir una aplicación completa usando Agile   Metodologías, ¿cómo lo harías? "

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

    
respondido por el mattnz 01.11.2012 - 05:17
2

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

En particular, para las aplicaciones web, puede ser bastante fácil mover una parte de la aplicación a una nueva plataforma, y hacer que las solicitudes de ruta de su equilibrador de carga al sistema apropiado. Luego, escriba las historias que le permitirán poner su primera página en producción y envíelas 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 las responsabilidades del nuevo, sin la necesidad de una reescritura completa.

Tal vez exista alguna lógica empresarial independiente que se pueda mover a un nuevo servicio o marco web, y la aplicación antigua se puede modificar para usarla en lugar de su código antiguo. Solo sigue cortando trozos en las costuras hasta que lo que quede sea manejable en un solo bocado.

Si no puede encontrar costuras, entonces es posible que deba buscar el tipo de enfoque de Big Bang sugerido en algunas de las otras respuestas. Pero prepárese para una larga marcha antes de llegar a su destino, especialmente si se espera que continúe desarrollando el antiguo sistema en paralelo ...

    
respondido por el Bill Michell 01.11.2012 - 10:55
1
  

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 sustituya la funcionalidad del sistema anterior), mayores serán las posibilidades de que su proyecto sea exitoso. Si piensa que esto no tiene mucho sentido, piénselo bien, casi siempre hay posibilidades de liberar partes.

Probablemente signifique 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 en que la reescritura no esté completa. Pero según mi experiencia, ese trabajo adicional siempre se paga a sí mismo.

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 esperamos que reemplace más y más funcionalidades del sistema anterior en pequeños pasos.

    
respondido por el Doc Brown 01.11.2012 - 11:43

Lea otras preguntas en las etiquetas