Tour por Visual Studio Team Services

Como sabéis, en el pasado Connect(); 2015 se anunció que Visual Studio Online pasaría a denominarse Visual Studio Team Services.

Visual Studio Team Services es una herramienta para gestionar nuestros proyectos software, poniendo a nuestra disposición un gestor de código fuente (ya sea utilizando Git o Team Foundation Version Control), reporte de tareas, gestión de requisitos, builds automáticas, testing y gestión de releases. Básicamente todo lo necesario para poder gestionar el ciclo de vida de nuestro producto.

Es posible que debido a la gran cantidad de opciones que ofrece te sientas algo abrumado. Es completamente gratuito y no necesitas un proyecto de gran escala para tener una razón para utilizarlo. ¿Tienes un proyecto personal en mente? ¿Una práctica de clase? ¡Pues ya tienes motivos más que suficientes para empezar a planificar las cosas de manera correcta!

Únicamente necesitas un Live ID para empezar a utilizarlo. ¿Ya lo tienes? ¡Pues vamos a ello!

Registrar una nueva cuenta

Lo primero que haremos será registrar una cuenta.

Nuestra cuenta básica nos dará derecho a crear todos los proyectos que deseemos, tener en el equipo hasta a 5 personas con cuenta básica (o el número de personas que queramos con suscripción MSDN), invitar a stakeholders (usuarios que pueden ver el estado del proyecto), todos los repositorios privados que deseemos... y otras muchas características que se pueden ver en detalle aquí.

Una vez tengamos nuestra cuenta, es hora de empezar a crear proyectos y ver las opciones disponibles para gestionarlos.

La pantalla principal de nuestra cuenta

Nos dirigiremos a la URL de la cuenta que hayamos creado (del tipo https://xxxxx.visualstudio.com/), y nos aparecerá el Home de nuestra cuenta.

Será desde aquí desde donde podamos crear nuevos proyectos, administrar todos los usuarios, ver salas de discusión… Es un vistazo global de lo que ocurre en los proyectos asignados a nuestra cuenta.

Si deseamos crear un nuevo proyecto, simplemente pulsaremos en New debajo de Recent projects & teams.

Creando nuestro primer proyecto

A la hora de crear el proyecto, tendremos que elegir su nombre y descripción, y, además, escogeremos una de las plantillas disponibles y uno de los sistemas de control de versiones que pone a disposición Visual Studio Team Services (VSTS de ahora en adelante).

La plantilla influye directamente en los elementos de trabajo de VSTS, de manera que se adapten a la metodología que escojamos.

Es posible que para el uso que le des en un principio, no notes las diferencias entre una plantilla u otra, pero para aquellos más avanzados o que simplemente deseen conocer en profundidad las características, aquí podéis encontrar una magnífica explicación de todas las diferencias existentes.

Nosotros nos decantaremos por Scrum, que es una de las metodologías ágiles más utilizadas a día de hoy.

En cuanto a sistema de control de versiones, nos decantaremos por Git.

¿Qué diferencia existe con Team Foundation?

Básicamente la diferencia es que al utilizar Git, trabajamos con un sistema distribuido. Cada miembro del equipo tendrá una copia del código fuente, y podrá trabajar con ese código en su local, sin afectar a lo que hagan el resto de miembros del equipo. Cuando lo consideren oportuno, subirán los cambios realizados en su repositorio al repositorio de VSTS, para evitar perderlos en caso de que ocurriese algún problema en su ordenador.

En Team Foundation se trabaja con un repositorio central, sobre el que se verán reflejados todos los cambios que realicemos. Siempre que guardemos cambios será sobre ese repositorio, con lo que tendremos los cambios sincronizados con el resto de miembros del equipo en todo momento.

Pulsamos en Create Project y, tras unos instantes, tendremos nuestro nuevo proyecto listo para empezar a trabajar en él.

Home – Personalizando nuestra pantalla principal

El Home es la página principal con los Dashboards que nos mostrarán de una manera muy visual información general (o específica, según lo configuremos) de nuestro proyecto.

Por defecto siempre tendremos el dashboard Overview, en el que se nos mostrarán diferentes widgets indicando el trabajo que hay en progreso, el número de elementos en los que se están trabajando y otros elementos. Estos elementos son los que vienen por defecto, pero no son fijos. De hecho, podemos personalizar el dashboard tal y como deseemos pulsando en . La pantalla pasará a verse de la siguiente manera:

Como vemos, podremos mover, eliminar o incluso, en algunos casos, configurar los diferentes widgets que hay. Si pulsamos en , podremos añadir nuevos widgets. Cuando tengamos el dashboard tal como queremos, simplemente pulsamos en .

Si lo deseamos, podemos añadir más dashboards:

Work – Gestionando el trabajo

Es aquí donde iremos añadiendo los requisitos de nuestro proyecto, así como las tareas que se deben llevar a cabo para completar dichos requisitos.

Nada más entrar, nos aparecerá el Product Backlog.

Como comentamos anteriormente, en función de la plantilla que escogiéramos al crear el proyecto, se nos adapta la interfaz a la metodología elegida. En nuestro caso, al seleccionar Scrum, los elementos que añadamos al backlog se denominan Product Backlog Items o Bugs.

Para ir añadiendo ítems simplemente escribimos el título de dicho ítem y le damos a Add. Añadiremos tantos como consideremos necesarios para nuestro proyecto. El backlog va a ir cambiando con el tiempo, en función de las necesidades que vayan surgiendo, por lo que no tienes que pensar absolutamente todos los elementos al principio. Es más, es posible que algunos de los que vayas añadiendo no llegues a completarlos.

Si hacemos doble click en cualquiera de ellos, podremos editar sus detalles. La idea es aportar el mayor nivel de detalle de información posible acerca de cada ítem, como su descripción, criterios de aceptación, planificación…

Cuando existen ítems en el backlog, es hora de planificar los sprints. Un sprint es un periodo de tiempo, generalmente de 1 a 4 semanas (aunque puede durar más) durante el cual el equipo se compromete a realizar un determinado número de ítems.

En un sprint no debemos introducir todos los ítems del backlog (recordemos que el backlog irá cambiando, e incluso en medio de un sprint se pueden añadir nuevos elementos), sino sólo aquellos que el equipo considera que puede implementar y tener listo para el final de éste.

Para añadir elementos a un sprint, hacemos click derecho en ellos y le damos a Move to iteration >> Sprint.

Es hora de planificar el sprint.

Es aquí donde definiremos las fechas que abarca el sprint, la capacidad del equipo y las tareas en las que dividiremos cada ítem para completarlo.

Para establecer las fechas simplemente le daremos a Set dates. Nos aparecerá una ventana para indicar la fecha de inicio y final del sprint. Para este ejemplo pondremos una semana. Cuando lo tengamos, le damos a Save and close.

Posteriormente vamos a definir la capacidad del equipo. Para ello pulsamos en Capacity. Es aquí donde estableceremos las horas que puede dedicar cada miembro del equipo al día a trabajar en las tareas del sprint. Cabe destacar que debemos poner las horas reales que se dedican a ello. Si un miembro del equipo trabaja 8 horas cada día y solamente dedica 3 al proyecto, serán esas 3 las que pondremos.

Además, podemos indicar el número de días que los miembros del equipo tendrán libres o no podrán dedicar al proyecto. Por ejemplo, por vacaciones o por algún festivo. Y, por último, a qué actividad van a dedicar sus horas en el proyecto.

Indicando todo, VSTS calculará la capacidad del equipo total para realizar tareas, así como la capacidad de cada uno de los miembros.

Por último, tendremos dividir cada ítem en tareas que se llevarán a cabo para completar dichos ítems. A cada una de esas tareas le daremos una estimación del número de horas que creemos que nos llevará completarla. Por ejemplo, para la tarea del área personal, podríamos tener dos tareas: una para diseñar y maquetar la página que mostrará los detalles del usuario, y otra tarea en el backend que accederá a dichos datos para mostrárselos al usuario.

Según las estimaciones que vayamos dando, VSTS calculará si es viable realizar las tareas en el sprint con la capacidad del equipo disponible.

Si las tareas van a llevar más horas de las que el equipo es capaz de realizar, VSTS nos lo indicará.

Si llegamos a este punto querrá decir que deberíamos intentar afinar más en las estimaciones, o, en caso de no poder hacerlo, tendríamos que pensar en quitar algún ítem del sprint, ya que probablemente no lo tengamos completado para el final del periodo.

Code – El código siempre a mano

VSTS integra también repositorios de código, con lo que podremos tener controlado todo el código que vayamos realizando de la aplicación en la misma herramienta.

Si lo deseamos, podemos ver el histórico de cambios que se han ido realizando a lo largo del tiempo.

Y, por supuesto, ver las modificaciones que se han hecho sobre el código.

En nuestro caso, el sistema de control de versiones es Git. No obstante, si hubiésemos escogido Team Foundation la interfaz sería análoga, y podríamos ver de la misma manera todas las modificaciones que se han ido realizando.

Build – Asegurándonos de que todo compila

También podemos controlar que todo el código que subamos esté compilando correctamente. Para ello VSTS nos da la posibilidad de crear definiciones de builds y ver el estado de todas las que se vayan realizando.

Crear una definición de build es tan sencillo cómo clicar en , escoger una plantilla y configurar de dónde tiene que coger el código para compilar.

¡Podemos incluso marcar que se cree una build automáticamente cuando se detecten cambios en el repositorio!

Todas las builds realizadas irán apareciendo indicándonos si se han llevado a cabo correctamente o no.

Y simplemente haciendo doble click en ellas, podremos ver todos los detalles.

Conclusión

Como hemos visto, Visual Studio Team Services ofrece absolutamente todo lo necesario para realizar un seguimiento exhaustivo de nuestro proyecto, sin que se nos escape el más mínimo detalle.

En este post hemos visto las características más generales y que a priori pueden resultarnos más útiles, pero es solo la punta del iceberg de lo que nos ofrece. Para conocer todo en detalle necesitaríamos escribir un libro, con la dificultad añadida de que cada mes habría que sacar una nueva edición, ¡puesto que Visual Studio Team Services no para de crecer!

Mantente informado de todas las novedades de Microsoft para los desarrolladores españoles a través del Twitter de MSDN, el Facebook de MSDN, el Blog de MSDN y la Newsletter MSDN Flash.

Daniel Escribano García

Technical Evangelist Intern

@daegsar90