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

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…

Continue Reading…

¿Agile en el canal Dynamics? ¿Locura?

Insanity: doing the same thing over and over again and expecting different results.- Albert Einstein
(Locura es hacer lo mismo una y otra vez y esperar resultados diferentes)

Como expuse en mi anterior post: ¿Sure Step vs Agile? Condenados a entendernos, estoy convencido de que un cambio de filosofía hacia el mundo ágil no sólo es positivo sino que es totalmente posible dentro del mundo de los grandes ERP en general, y del canal Dynamics en particular.

Como exponía en ese artículo, hay varios handicap que superar como la resistencia al cambio (hay que cambiar la mentalidad de muchas personas involucradas), la falta de confianza en el sistema para proyectos de largo alcance o incluso la falta de colaboración del cliente. Sin embargo hay ciertos trabajos muy típicos de esta industria que son ideales para empezar a experimentar con este cambio, a pesar de que el proyecto, en general, se gestione con Sure Step:

  • Migraciones (cambios de versión): Una migración es un proceso totalmente acotado con tareas claramente definidas y planificables, pero lo importante es que en este proceso no es tan importante la documentación (a menudo no es para nada importante) como la implicación del cliente en el proceso tanto para la realización de diversas pruebas al finalizar cada tarea, como para solucionar consultas sobre la marcha en caso de imprevistos (en las migraciones siempre hay imprevistos). Lo de “ágil” se vuelve literal ya que cuando el proceso de migración termina se tiene que implantar en tiempos de parada del cliente, casi siempre en un fin de semana.
  • Soporte post-arranque: Cuando se da por finalizada una implantación nueva y el cliente empieza a utilizar el sistema, a menudo se dará cuenta de que hay pequeños (o grandes) detalles que quiere modificar porque no se habían previsto durante las fases previas. La buena gestión de estas modificaciones puede diferenciar el éxito o el fracaso de una implantación ya que una cosa es que el proyecto finalice, y otra que el cliente de por cubiertas sus necesidades (o las que cree que lo son). Hacerle participe del coste y el esfuerzo de esos “extra” puede ser determinante para cerrar la implantación con todas las partes satisfechas.
  • Actualciones de mantenimiento: De la misma manera que en el punto anterior, trabajar con un sistema programable como lo son todos los grandes ERP’s hace que siempre haya pequeños o grandes cambios a realizar para optimizar el trabajo diario. La buena gestión de las necesidades, el desarrollo y la implantación de los cambios sin interferir el trabajo de los usuarios es determinante para que los mantenimientos se finalicen con éxito y sin fricciones.

Si alguien ya ha empezado o esta interesado en estos cambios me encantaría recibir opiniones en los comentarios. Y si alguien quiere comentar o debatir en persona estaré en la próxima Conferencia Agile-Spain 2011 (#cas_2011)

¿Sure Step vs Agile? Condenados a entendernos

Hace unos días tuve una conversación muy interesante con un compañero de trabajo a raíz de mi anterior post El ratoncito ágil y La ruta de los elefantes. Este compañero defendía con bastante convicción la metodología de gestión de proyectos tradicional y me proponía diferentes motivos por los que en nuestro negocio no podían funcionar otras como Scrum o en general metodologías de filosofía ágil o lean (método, sin embargo, ámpliamente reconocida en el mundo de la fabricación industrial) seguro que os suenan:

Project Management

  1. Scrum (o la gestión ágil en general) no es apropiada para proyectos grandes (en tiempos, equipos, costes, …) con diferentes equipos en diferentes roles (comerciales, analistas, consultores, programadores, jefes de proyecto, …) y a menudo en diferentes ubicaciones.
  2. Para aplicar estos métodos hay que cambiar la forma de trabajar de muchas personas integrantes de la empresa, y del equipo en particular, desde el comercial hasta el programador pasando por todos los roles intermedios, y esto tiene un coste y un riesgo a menudo inasumible.
  3. A menudo ni siquiera el cliente está preparado para trabajar de manera ágil. No entiende las implicaciones o simplemente no está dispuesto o preparado para implicarse tanto durante toda la duración del proyecto. Espera pedir lo que necesita, y que se lo den todo hecho.

Hace unos días tuve una conversación muy interesante con un compañero de trabajo a raíz de mi anterior post El ratoncito ágil y La ruta de los elefantes. Este compañero defendía con bastante convicción la metodología de gestión de proyectos tradicional y me proponía diferentes motivos por los que en nuestro negocio no podían funcionar otras como Scrum o en general metodologías de filosofía ágil o lean, seguro que os suenan:

  1. Scrum (o la gestión ágil en general) no es apropiada para proyectos grandes (en tiempos, equipos, costes, …) con diferentes equipos en diferentes roles (comerciales, analistas, consultores, programadores, jefes de proyecto, …) y a menudo en diferentes ubicaciones.
  2. Para aplicar estos métodos hay que cambiar la forma de trabajar de muchas personas integrantes de la empresa, y del equipo en particular, desde el comercial hasta el programador pasando por todos los roles intermedios, y esto tiene un coste y un riesgo a menudo inasumible.
  3. A menudo ni siquiera el cliente está preparado para trabajar de manera ágil. No entiende las implicaciones o simplemente no está dispuesto o preparado para implicarse tanto durante toda la duración del proyecto. Espera pedir lo que necesita, y que se lo den todo hecho.

Los motivos son tan apropiados y recurrentes en cualquier discusión que casi tendrían que formar parte del manifiesto ágil, ya que bien argumentadas son difícilmente discutibles. Lo voy a intentar:

Partimos de la base de que como Partners de Microsoft Dynamics, trabajamos siguiendo la metodología Sure Step, que es una adaptación a diferentes tipos y tamaños de proyecto de la ya conocida Waterfall (Metodología “en cascada”) tradicional, basada en fases secuenciales (con equipos diferenciados por fase), documentación y contratos, y “entregables” (deliverables). Mientras que las filosofías ágiles se basan en el manifiesto ágil:

  • Individuos e interacciones, sobre procesos y herramientas
  • Software funcionando, sobre documentación extensiva
  • Colaboración con el cliente, sobre negociación contractual
  • Respuesta ante el cambio, sobre seguir un plan

(Esto es, aunque se valoran los elementos de la derecha, se valoran más los de la izquierda)

También existen diferencias (o eso parece) entre los diferentes roles que intervienen en ambas filosofías. En Sure Step existen muchos roles que no siempre se aplican todos, resumiendo más o menos:

  • Equipo de Ventas (ante-proyecto)
    • Comercial, Gestor de cuentas, Consultor pre-venta, …
    • Equipo de Consultoría (ejecución del proyecto)
      • Gestor de proyectos
      • Consultor de negocio, Consultor de integración, Consultor funcional, Consultor técnico
      • Programador, Consultor de desarrollo, Técnico de soporte
      • Equipo del Cliente
        • Gestor de proyectos, Responsable de proyecto, usuarios clave, usuario final, responsable de área

Mientras que, por ejemplo, en Scrum, los roles son menos y más específicos (me extenderé sobre esto en futuros artículos), orientados más al producto que al proyecto:

  • Product Owner (propietario del producto, representa al cliente)
  • Scrum Master (facilitador del Scrum Team)
  • Scrum Team (equipo que hace posible el producto)
  • Usuarios (quien utilizará el producto)

Expuesto todo esto, es fácil comprobar por qué mi compañero está tan seguro de su argumento nº 2, expuesto al principio. Intentar cambiar una organización entera y todas las personas implicadas para cambiar la filosofía y el método de trabajo sería un suicidio. Pero estamos hablando de filosofías ágiles, donde prima el proceso incremental, ¿por qué se debería cambiar todo a la vez? Es cierto que en muchos casos no se podrá utilizar una u otra metodología para gestionar todo el proyecto, pero ¿por qué no puede aplicarse sólo en un equipo, o en un área, o en una fase?

Precisamente el trabajar con metodologías Waterfall durante tantos años nos ha llevado a tener equipos muy bien diferenciados por roles y a menudo incluso por ubicación.

¿Acaso dentro de Sure Step un equipo de consultores o de desarrollo no puede auto-gestionar su propia fase de una manera ágil? Mejoraría el resultado final, probablemente los plazos, y mantendría informado de manera frecuente a su director de proyecto y al cliente (quizás a través de un product owner interno, un consultor).

¿Acaso no se puede gestionar una fase de desarrollo (Waterfall) de una manera ágil, priorizando el “core” del desarrollo (lo que el cliente considera imprescindible para su funcionamiento) y haciendo entregas parciales del mismo? Se detectarían errores en el análisis con más antelación que haciendo una única entrega final, se detectaría trabajo que ya no se debe hacer, el cliente vería progresos antes y se haría una idea de lo que va a ser su producto, antes de verlo terminado.

¿Acaso en Sure Step no tenemos ya los roles de Scrum definidos en cada fase? En análisis el Scrum Team son los analistas, existe un jefe de proyecto (Scrum Master) y se realiza directamente en el cliente (product owner). La fase de desarrollo la realizan programadores y consultores técnicos (Scrum Team), el desarrollo se entrega normalmente al equipo de consultoría para sus pruebas (product owner) y existe un director de desarrollo o de proyecto (Scrum Master). Simplemente en cada fase, el que realiza el trabajo es el equipo (Scrum Team), y el que lo espera en la fase siguiente de la “cascada” es el “cliente” (product owner) para el equipo actual.

Creo que con esto queda clara mi postura frente a los problemas nº 1 y 2 expuestos más arriba. Efectivamente hace falta un cambio, pero no creo que sea tan radical ni que necesariamente se deba hacer de manera brusca para nadie. ¿Qué no se puede o sabe gestionar un gran proyecto con gestión ágil? Tampoco es necesario hacerlo para empezar a experimentar y descubrir que hay otras formas de hacer lo de siempre.

¿Y si el cliente no entiende, no es capaz de comprometerse o de comprender un contrato ágil, sin fechas de entrega o costes grabados en piedra? Estoy convencido de que cuando el equipo de la empresa vea los resultados de una forma de trabajar más eficiente, el propio equipo comercial comprenderá la forma de explicar al cliente las ventajas de este cambio. Cuando estás en la situación de firmar un contrato de cantidades notables de dinero es normal que no quieras arriesgarte, pero ya hay mucha gente que se ha caído “cascada abajo” y que estaría dispuesta a probar métodos alternativos, es una cuestión de confianza en sí mismo, de probar, de investigar, de perder el miedo al cambio por parte de todos.

Continue Reading…