Microsoft Dynamics AX 2012 ALM Con Team Foundation Server (ALM-III)
En la anterior entrada de esta serie, vimos al detalle cómo instalar y realizar la configuración básica de un servidor Team Foundation Server 2010, y suponíamos también la instalación de un Visual Studio 2008 o 2010 configurado con las actualizaciones suficientes para conectar a este servidor. Nuestro servidor quedó instalado y configurado con una o varias colecciones de proyectos, pero ningún proyecto creado.
En esta entrada vamos a comprobar cómo un servidor de Team Foundation Server 2010 puede ayudarnos a la gestión del ciclo de vida de la aplicación a nivel funcional, sin entrar en detalles técnicos, y cómo esta funcionalidad nos ayudará desde las primeras fases del proyecto en la toma de requisitos, hasta las últimas con la gestión de incidencias o la gestión del cambio.
Lo primero que necesitamos para la gestión de nuestro proyecto es, como cabe suponer, un proyecto. La creación de un proyecto no se puede realizar desde el acceso web de TFS2010 por lo que necesitaremos conectarnos al servidor mediante Visual Studio. En este capítulo trabajaremos con Visual Studio 2010 que casi seguro tendremos instalado en nuestra máquina de desarrollo de Microsoft Dynamics AX 2012.
En la página de inicio de Visual Studio 2010 vamos a elegir la opción Connect To Team Foundation Server:
Si nunca hemos conectado a nuestro servidor (o a ninguno) no aparecerá en la lista de servidores, para añadirlo pulsamos Add y escribimos el nombre del servidor donde trabajamos en el capítulo anterior. El asistente se ocupará de completar la URL:
Al aceptar ya podremos elegir nuestro servidor y conectarnos a la colección que hayamos creado anteriormente. Una vez conectado, en Visual Studio 2010 podemos mostrar el Team Explorer, si no esta ya visible, y hacer click derecho sobre nuestra colección que ahora estará vacía. De esta manera podemos ver las opciones que tenemos disponibles para la administración de esta colección.
En principio no entraremos en detalle de estas opciones y nos limitaremos a crear un proyecto mediante la opción New Team Project.
- El asistente nos pide un nombre de proyecto (le voy a poner AX2012).
- También nos pide una plantilla a elegir entre Agile o CMMI. Esta decisión dependerá de la metodología que estemos utilizando, si utilizamos cualquier metodología ágil seleccionamos la primera y para cualquier metodología waterfall (como Sure Step) seleccionamos la segunda. Para este ejemplo voy a seleccionar CMMI.
- En la creación de un sitio de Sharepoint responderemos afirmativamente con las opciones por defecto.
- También aceptaremos las opciones por defecto en la creación de una carpeta de código fuente vacía.
El resumen de instalación será parecido al siguiente:
Al finalizar el proceso vemos como el nuevo proyecto y sus opciones aparecen en el Team Explorer así como el asistente nos guía hacia la página de la plantilla que hayamos elegido. Si desplegamos todos los nodos del proyecto recién creado podemos comprobar que las opciones son muchísimas, la mayoría son consultas preparadas para presentarnos listas de tareas en diferentes estados:
Crear elementos de trabajo
Vamos a hacer una sencilla prueba haciendo click derecho en el nodo Work Items > New Work Item > Tarea. En el formulario de nuevo Work Item vamos a rellenar algunos datos de ejemplo y pulsamos Save Work Item.
A continuación navegamos el Team Explorer en nuestro proyecto > Work Items > Consultas del equipo > Mis elementos de trabajo y comprobamos que efectivamente ahora tenemos una tarea asignada. De la misma manera podemos ir al sitio web del proyecto a través de Team Web Access y comprobar que tenemos acceso al Work Item recién creado:
Podemos ver las similitudes con otros sistemas similares, como JIRA, por ejemplo:
Y también con el nuevo servicio de TFS en la nube llamado Team Foundation Service, que se puede probar de forma gratuita en tfspreview.com:
¿Aquí no estábamos hablando de metodologías?
Efectivamente. Recordemos del primer capítulo de esta serie que las herramientas soportan a las metodologías, le dan un soporte físico, pero las herramientas no son una metodología. Ahora bien, con lo visto hasta ahora y sea cual sea la metodología que utiliza tu equipo, es fácil deducir que en cualquier caso se llegará a una lista de acciones a realizar (cosas por hacer, tareas, entregables, …) que tendrán valores como estimaciones, planificación en el tiempo, etc. Lo podemos llamar como queramos, TFS lo llama Work Items, JIRA lo llama Issues, el nombre no es lo importante sino entender que ya podemos gestionar acciones (estimadas, planificadas, …) con nuestra herramienta.
En el primer artículo hacía un esquema de las gestiones que, como mínimo debería controlar una metodología propia de la gestión del ciclo de vida del software. Ahora podemos ver cómo podemos reflejar esto en nuestra herramienta:
Gestión y planificación del proyecto: Si usamos la herramienta externa Microsoft Project, se pueden sincronizar las acciones de este software con Work Items de TFS de una manera bidireccional.
Control de métricas útiles para la planificación, control y previsión: En cada Work Item de TFS se encuentran valores como estimación, completado, pendiente… TFS lo llama Esfuerzo pero se puede utilizar para adaptarlo a cada metodología en concreto.
Gestión de requerimientos: Los requerimientos se deben registrar como Work Items que irán cambiando de estado según avancen su progreso por todas las fases.
Gestión y seguimiento de funcionalidades: Los requerimientos (Work Items) que se aprueben pasarán este estado, quedando enlazados a su requerimiento y posteriormente a sus pruebas y posibles incidencias.
Gestión de código fuente: La gestión de código fuente es una funcionalidad propia de TFS que veremos más adelante.
Control de versiones: El control de versiones es una funcionalidad propia de TFS que veremos más adelante, aunque en el propio Work Item vemos que podemos asociar cada uno a una iteración. En cada metodología esto corresponderá a un nombre diferente, por ejemplo podría ser un Sprint de SCRUM o un Stage de PRINCE2, una fase o entregable de forma mas genérica… lo que importa es el concepto, no cómo lo llamemos.
Gestión y automatización de pruebas: TFS dispone de un sistema de pruebas automáticas y manuales. Microsoft Dynamics AX 2012 también dispone de un sistema de pruebas unitarias, veremos como hacer que se entiendan y se complementen.
Gestión y automatización de construcción y despliegue: El control de despliegue automático es una funcionalidad propia de TFS que veremos más adelante.
Gestión de entornos y configuraciones: En el caso concreto de Microsoft Dynamics AX 2012 veremos posibles soluciones para manejar entornos y configuraciones (Entornos de desarrollo, pruebas, producción, etc…).
Gestión y seguimiento del flujo de resolución de incidencias: El control de incidencias se puede adaptar a cualquier metodología utilizando la herramienta TFS directamente en Visual Studio o mediante su acceso web. Se debe definir qué usuarios podrán crearlas y la manera de que se asignen a quien debe solucionarlas, así como enlazarlas a funcionalidades/requerimientos y a sus posibles pruebas.
¿Y tú, cómo lo haces?
Todos conocemos a, al menos, un jefe de proyecto que utiliza una Excel donde dispone cada requerimiento, cada incidencia, cada funcionalidad, … catalogada con una serie de columnas que denotan su estado o su avance. Esto funcionaría de maravilla si esa Excel sólo fuera relevante para la persona que la mantiene, pero lo habitual es que el fichero vaya rodando por cadenas interminables de email donde cada uno va actualizando su parte, llegando al punto en el que es difícil saber cuál es la última versión, si es que alguna realmente lo es…
Existen mejores métodos de sustentar esta información como colgar la Excel en un portal web como Sharepoint o, mejor aún, mantener la lista como una lista del propio Sharepoint. Pero en cualquier caso esa lista estaría totalmente aislada de lo que realmente se está haciendo, y supeditada a que quien debe mantenerla lo haga de una manera rápida y rigurosa.
¿No sería mejor mantener la información donde se genera? Lo bueno de una herramienta como TFS es que está presente en cada punto donde se genera la información: Un consultor puede utilizar Team Web Access para crear y estimar sus tareas; Un director de proyectos puede integrarlo con su Microsoft Project o planificar directamente sus Work Items en Team Web Access; Un programador tiene TFS integrado en su Visual Studio o directamente en Microsoft Dynamics AX y gestionará directamente sus tareas, incluso, asociando a ellas el código fuente modificado/creado para completarlas; Un tester utilizará visual Studio o la propia web del Microsoft Test Manager para realizar sus pruebas; los despliegues automáticos registrarán cualquier acción de manera automática; el propio usuario final/cliente registrará posibles incidencias mediante su acceso restringido a Team Web Access; …
En resumen: una sola herramienta, un solo dato, una sola verdad.
¿Y qué más?
En estos primeros capítulos hemos visto la necesidad de disponer de una metodología completa de gestión del ciclo de vida, hemos visto como instalar y configurar TFS para el manejo de Work Items, y en los próximos capítulos entraré más a fondo en tareas mas técnicas orientadas directamente al desarrollo en Microsoft Dynamics AX 2012 como son: control del código fuente, control de versiones, testing y despliegue.
Referencias
Posts in this series
- Procesos BUILD Automáticos Con TFS Y AX 2012 (2/2) (ALM-X)
- Procesos BUILD Automáticos Con TFS Y AX 2012 (1/2) (ALM-IX)
- Códigos De Etiquetas De Microsoft Dynamics AX 2012 Usando Ramas De Team Foundation Server (ALM-VIII)
- Control De Versiones en Microsoft Dynamics AX 2012 Mediante Ramas De Team Foundation Server (ALM-VII)
- Control Del Código Fuente Con TFS en Microsoft Dynamics AX 2012 (ALM-VI)
- Leer Elementos De Team Foundation Server Desde Microsoft Dynamics AX 2012 (ALM-V)
- Descargar Aplicación Microsoft Dynamics AX 2012 Desde Team Foundation Server (ALM-IV)
- Microsoft Dynamics AX 2012 ALM Con Team Foundation Server (ALM-III)
- Instalación De Team Foundation Server 2010 (ALM-II)
- Microsoft Dynamics AX 2012 Application Lifecycle Management (ALM-I)