Microsoft Dynamics AX 2012 Application Lifecycle Management (ALM-I)

Thu, Aug 23, 2012
6-minute read

Warning: This post is over 365 days old. The information may be out of date.

Aunque pueda parecer curioso, incluso inquietante, una gran parte de los proyectos de implantación de ERP’s entre los que podemos incluir la familia Dynamics en general y Microsoft Dynamics AX en particular no se ejecutan como proyectos de software. Quizás por la cercanía del proyecto al negocio o quizás por la orientación -más a negocio que a software- de las personas implicadas en la mayor parte del tiempo consumido, una buena parte de las veces se olvida, o se obvia, que estamos tratando de implementar un software y por tanto es conveniente tratar el proyecto como un proyecto de software y aplicar conceptos propios de la ingeniería de software para gestionar el software y la gestión de proyectos para gestionar el proyecto.

Ya he hablado en artículos anteriores de diferentes metodologías de implantación como puede ser Microsoft Sure Step o las metodologías ágiles a las que cada vez se acerca más gente, incluida Microsoft. No son las únicas, cada empresa utiliza las que conoce y considera mas apropiadas para cada proyecto como PMBOK o PRINCE2 o técnicas más específicas del software y la tecnología como CMMI o ITIL, e incluso algunas empresas “diseñan” las suyas propias. El problema es que es demasiado habitual que no se utilice ninguna o que la elegida no abarque todo el ciclo de vida de una aplicación.

Alguno podrá pensar: “¿Estás criticando la utilidad de metodologías utilizadas por la mayoría de multinacionales del mundo durante años?”. No. Claro que no. Ni siquiera conozco la mayoría de ellas como para, siquiera, tener una opinión. Lo que sí esta claro, por su propia definición, es que son propuestas orientadas a la gestión del proyecto como tal (alcance, recursos, tiempo, coste, materiales,…) pero no tienen en cuenta de manera específica los problemas propios del software, que a menudo quedan olvidados al no formar parte de los procedimientos formales. En resumen, se gestionan más las limitaciones y los riesgos (lo que no se puede hacer) que lo que SÍ debe hacerse. Dicho de otra forma, se están utilizando estas metodologías (totalmente válidas) para gestionar conceptos que NO SON el software.

Para mejorar esto hemos de recurrir a la tan olvidada ingeniería del software y a un concepto que cualquier empresa dedicada exclusivamente a producir software tiene más que asumido en su operativa diaria y en su rentabilidad: El ciclo de vida de la aplicación (o Application Lifecycle Management, o simplemente ALM).

Microsoft Application Lifecycle Management

Wikipedia da una buena definición de Ingeniería del Software (traducido). Quizás no es la mejor fuente pero es la más accesible:

[…] Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al diseño, desarrollo, operación y mantenimiento de software […]

Ahora cabría plantearse si el método que estamos utilizando en nuestro entorno (soy optimista y pienso que ya se está utilizando alguno) cumple estas sencillas directivas (sistemático, disciplinado y cuantificable) a todas las áreas del ciclo de vida (desde el desarrollo al mantenimiento, sin olvidar la gestión del cambio). Si es así, enhorabuena; si no lo es, te interesa el resto del artículo y los que vendrán a continuación…

Procesos

Es importante tener en cuenta que para que funcione cualquier metodología que elijamos, se ha de poner énfasis en los procedimientos, no en las herramientas (software, documentación, …). Las herramientas son importantes pero no nos van a servir de nada, ni aportar ningún valor -sino lo contrario- si no se apoyan sobre unos métodos establecidos con una finalidad clara, concreta y medible.

¿Cuales son los procesos, a alto nivel, que deberían formar parte de una estrategia de ALM?

Gestión y planificación del proyecto
Control de métricas útiles para la planificación, control y previsión
Gestión de requerimientos
Gestión y seguimiento de funcionalidades
Gestión de código fuente
Control de versiones
Gestión y automatización de pruebas
Gestión y automatización de construcción y despliegue
Gestión de entornos y configuraciones
Gestión y seguimiento del flujo de resolución de incidencias

Ventajas

El desarrollo y seguimiento de métodos repetitivos y consistentes mejora la productividad de los equipos al poder valorar y reutilizar decisiones previas y realizar acciones de una manera mas controlada.
Una buena gestión de la aplicación desde los requerimientos hasta el soporte mejora la calidad del producto entregado.
Una colección consistente y previsible de procesos mejora la colaboración de las personas entre equipos, evitando tener que formarse en la manera en que se ha resuelto cada proyecto.
Mejora la velocidad y consistencia tanto de las instalaciones como posterior despliegue de nuevas versiones al basarse en procedimientos conocidos y probados.
Mejora los costes y plazos al evitar imprevistos, minimizando riesgos.
Incrementa la innovación de los equipos. Aprovechando el conocimiento de proyectos previos, los equipos podrán dedicar mas esfuerzo a los requerimientos concretos y la solución de problemas nuevos, evitando tener que invertir tiempo en problemas ya solucionados previamente.

Inconvenientes

Aunque parezca increíble (a mí me lo parece), todavía hay equipos que no consideran adecuada una metodología de gestión de ciclo de vida o, incluso, las consideran innecesarias y hasta contraproducentes. Hace poco leí una frase que me recordó las veces que he tenido que trabajar en uno de estos proyectos:

Nunca hay tiempo para hacer las cosas bien, pero siempre para hacerlas dos veces…

Herramientas

Las herramientas pueden ser de lo mas variopinto: desde documentos plantilla, pizarras, post-it, hasta complejos sistemas de software. Pero sobre todo deben complementar y facilitar los procesos, nunca al contrario. Las herramientas facilitan el trabajo y permiten la adopción de metodologías, pero las herramientas NO SON la metodología.

Puesto que aquí hablamos de Microsoft en general y Microsoft Dynamics AX en particular y pensando que un equipo de proyecto de estas características por fuerza debe estar compuesto por diferentes personas, a menudo distribuidas en diferentes lugares de trabajo, es casi imprescindible adoptar algún tipo de software para ayudar en la tarea (insisto: ayudar).

Existen muchas herramientas y muchos fabricantes que desarrollan productos para facilitar el proceso ALM, no es obligatorio utilizar sólo una por lo que es útil investigar la mejor opción (en nuestra empresa utilizamos JIRA, de Atlassian, con buen resultado para la gestión de incidencias). La siguiente imagen muestra el último cuadrante mágico de Gartner para ALM donde se muestra a Microsoft en el cuadrante de líderes:

Gartner Magic Quadrant ALM 2012 - ALM

Hablando directamente de Microsoft Dynamics AX, la herramienta que mejor integración permite para gran parte de las fases del ciclo de vida es Team Foundation Server (o su nueva variante online Team Foundation Service que todavía no he podido probar) que nos facilita procesos que el propio Microsoft Dynamics AX no es capaz de solventar por sí solo y también Microsoft Project Server, aunque no entraré a más detalle ya que la integración no está pensada para la gestión del proyecto de implantación sino como parte de la funcionalidad del propio Microsoft Dynamics AX en su módulo de proyectos.

Sobre estas herramientas y su aplicación a proyectos de Microsoft Dynamics AX hablaré en los siguientes capítulos :)

Posts in this series

Spanish Dynamics AX ALM DevOps