Se pueden desplegar directamente entornos de Desarrollo o Build y pruebas (habrá más y mejores cambios en futuras versiones)
Mejoras en el manejo de las metodologías (adjuntar una metodología a otra existente; añadir fases y tareas)
Actualizada la hoja Excel Subscription estimator (otra vez, es un permanente work-in-progress). A partir de ahora la utilización de esta hoja es obligatoria para implementar proyectos.
Las herramientas de diagnóstico y monitorización han sido publicadas a través de LCS (podía verse cierta monitorización genérica antes a través del portal de Azure, pero la disponible en LCS es específica para AX, incluyendo las métricas de SQL Insights).
¡Integración de las tareas de procesos de negocio con Work Items de TFS (en realidad, con VSTS)! (esta funcionalidad está todavía en preview por lo que hay que activarla especificamente).
Ahora se pueden añadir requerimientos a los procesos de negocio.
Puedes ver todas las notas y ejemplos de estas novedades en el siguiente enlace:
Es posible cargar nuevas versiones de un mismo modelo en la biblioteca de activos, con la posibilidad de adjuntar un fichero extra con las notas de la versión.
Es posible seleccionar todos los modelos de la biblioteca de activos al crear un nuevo paquete con la nueva opción “Select all“.
Ahora se puede editar una Soluciónde LCS y publicar la nueva versión para que los clientes puedan ver tanto la lista de versiones como las notas de cada versión (igual que en la biblioteca de activos). Además, la versión del projecto de LCS se actualizará con la versión más reciente de la Solución.
Añadida la posibilidad de crear nuevos procesos de negocio BPM desde cero, sin necesidad de partir de un proceso existente. Además, las herramientas de edición de estos procesos han recibido muchas actualizaciones para facilitar la creación y edición de procesos existentes.
Mejoras en la manipulación de tareas dentro de una metodología. Es posible mover tareas de una fase a otra sin necesidad de recrearlas. Se han añadido algunas opciones para realizar tareas sobre grupos de tareas y fases.
Al pulsar sobre nuestro nombre de usuario, se muestra información del login utilizado para acceder a LCS. Muy util para saber con qué cuenta estamos conectados cuando utilizamos diferentes cuentas de Microsoft u Office 365.
Los clientes premiere pueden crear incidentes para un proyecto. Esta opción está disponible para AX 2012 y el nuevo Dynamics AX.
Es posible almacenar localizaciones (traducciones) para AX 2012 en la biblioteca de activos. Hasta ahora esta opción sólo estaba disponible para el nuevo Dynamics AX.
Mejoras en los proyectos de preventa para partners disponibles para el nuevo Dynamics AX.
Puedes ver todas las notas y ejemplos de estas novedades en el siguiente enlace:
En capítulos anteriores hablamos sobre cómo instalar y configurar Team Foundation Server, así como las posibilidades que ofrece para gestionar tareas y administrar el código fuente desde nuestra instancia de Microsoft Dynamics AX 2012. Comentamos las funciones básicas ,aunque imprescindibles, para proteger y desproteger el código en el servidor y las ventajas que ello suponía en cuanto a almacenar todo el histórico de cambios de los objetos, como por ejemplo: revisar el historial de cambios de un objeto, volver a una versión anterior, descartar cambios sin confirmar, etc.
Sin embargo hay ciertos problemas que una gestión básica del código fuente no es capaz de solucionar. Por ejemplo, en una instalación normal de nuestro ERP, a la vez que damos el soporte diario y realizamos pequeñas modificaciones para solucionar problemas, estamos llevando a cabo desarrollos de mayor o menor impacto. Estos desarrollos paralelos necesitan ser integrados en el código de producción de alguna forma, pero si usamos el mismo servidor para desarrollar y para hacer el mantenimiento, tendremos que llegar a un punto en el que todos los desarrollos estén totalmente terminados para pasar a producción de forma limpia y segura.
De la misma forma, si nuestra empresa desarrolla un producto final, es necesario avanzar el desarrollo de las siguientes versiones mientras damos soporte a las versiones publicadas en el pasado, incluso para diferentes versiones de AX. ¿Cómo estar seguro que un hotfix urgente desarrollado para un cliente llega a todas las versiones de nuestro producto que la necesitan, de forma limpia y estable?
Por supuesto hace falta un buen método de trabajo para que todo esto pueda realizarse de forma ordenada y sin errores, pero también hace falta la ayuda de alguna herramienta y para eso tenemos las ramas (Branches) disponibles en casi todos los sistemas de control de versiones del mercado, y por supuesto en nuestro Team Foundation Server.
Estrategias de branching
Existen infinidad de estrategias para definir las ramas que necesitamos en nuestros equipos, y ello va a depender de la cantidad de equipos que tengamos, la cantidad de productos, de versiones, etc. NO HAY una estrategia de ramas estándar o válida para todos y es algo que se debe pensar con cuidado ya que la estrategia elegida nos va a suponer ventajas e inconvenientes. Lo más recomendable es empezar por la lectura de la guía Version Control Guide escrita por el grupo Visual Studio ALM Rangers donde explican la mayoría de opciones con sus pros y sus contras.
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).
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…
Necesito precio para unos accesorios de baño para mañana {contrato a precio fijo, alcance fijo, plazo fijo}
Sin problema, le cuestan 50€ cada uno {confirmación del contrato}
Perfecto, pero los quiero colocados en la pared {ampliación de alcance no prevista}
OK, se los doy colocados en la pared {aceptación ¿? de la ampliación}
Resultado:
Obviamente, este diálogo es ficticio, pero el resultado es real. Esa “instalación” lleva así desde hace más de un mes en un baño público y nada indica que la situación vaya a mejorar a corto plazo. Alguien ha considerado que ese trabajo está “hecho“, aunque esa no es la impresión que uno percibe cuando necesitas secarte las manos.
Me gustaría analizar cómo se ha llegado hasta aquí porque es algo que vemos todos los días cuando hablamos de software, que es a lo que vamos en este blog al fin y al cabo:
Definition of Done (DoD)
El término Definition of Done está asociado normalmente a Scrum, pero no por eso tenemos que limitarlo a Scrum, ágile, o a ninguna metodología específicamente. Es un término que en cualquier caso se tiene que tener en cuenta y sobre el que vale la pena negociar en cada proyecto, ya que esta definicion va a tener un gran peso en el éxito o el fracaso de muchas entregas. Me da igual que sean entregables waterfall, sprints de scrum o como queramos llamarlo.
En un mundo ideal, un análisis -o cualquier definicion de una tarea- esta perfectamente definida y quién lo solicita (consultor, analista, product owner, … da igual) especifica detalladamente qué quiere, cuándo, dónde y cómo lo quiere. Pero nosotros no vivimos en un mundo ideal y en nuestor mundo eso rara vez ocurre. Uno o varios de esos interrogantes los vamos a tener que preguntar o suponer, y de nuestro acierto va a depender que el resultado sea el esperado o no.
Esta duda (este riesgo) se puede mitigar destallando, por ejemplo, pruebas de aceptación o similares donde se especifique un juego de pruebas que el producto tendrá que cumplir para que se de por válido (para que se considere “hecho“). Pero aun así hay detalles que no entrarán en las pruebas de aceptación. Por ejemplo, la integración con otros sitemas, la existencia de dependencias externas, hardware, etc. … siempre habrá dudas sobre cuándo podemos dar un trabajo por “hecho“.
Supongo que la comunidad ágil tendrá para discutir largo y tendido acerca de lo que debe ser DoD, lo que se debe detallar en una tarea o en la definición de un sprint. Pero visto desde un punto de vista mas general (o mas waterfall en particular), la definición exacta y pactada de qué requisitos concretos debe cumplir un desarrollo para validarse es algo a lo que se le da poca importancia en el mejor caso, o se ignora por completo en el resto, y que a mi entender es causa de muchos desacuerdos entre las partes y constantes peleas a la hora de finalizar las entregas.
Sobre este tema se habló en la pasada Conferencia Agile Spain y por eso os remito a la keynote de Xavier Quesada “El último momento responsable”:
También en la sesion sobre Contratos Agiles (de Xavier Albaladejo), aunque todavía no está disponible el vídeo. Esperemos que lo esté pronto, porque el explica mejor qué yo por qué vale la pena reflexionar sobre este tema.
