Scrum con TFS

En los últimos años estamos asistiendo a un cambio radical en la forma de gestionar los proyectos de desarrollo de software. Empieza a resultar extraño encontrar ofertas de trabajo en las que no se mencione scrum, o proyectos que empiecen en los que no se haya planteado el uso de metodologías ágiles. Pero de nada nos sirve una metodología, por muy buena que pueda ser, si perdemos más tiempo gestionando el proceso que programando. Por lo que nos vemos casi obligados a empezar a usar herramientas que nos ayuden con esta tarea. A lo largo de este artículo trataremos una de esas herramientas, que consideramos más potentes: TFS.

Team Foundation Server/Service

Las siglas TFS pueden significar Team Foundation Server o Team Foundation Service. En ambos casos se trata del mismo producto, pero en diferentes formas de distribución.

Este software es la herramienta que nos ayudará con la gestión del ciclo de vida de aplicaciones (ALM), propuesta por Microsoft. TFS nos aportará una serie de utilidades que nos facilitarán la gestión de los procesos, el control de versiones del código fuente, el testing de aplicaciones, el deploy, y además nos aportará diferentes informes sobre todo esto.

Las dos formas de distribución en las que podemos encontrar TFS hoy en día son:

TFS-Saas

Las diferencias entre ambas versiones sobre todo radican en que la versión on-premises permite la personalización de las plantillas de procesos y tiene una mejor herramienta de generación de informes. Pero para el proceso que vamos a describir a continuación es indiferente cual de estas utilizar.

En los ejemplos que veremos a lo largo de este artículo hemos utilizado la versión Saas: Team Foundation Service. Para ello nos dirigimos primero a la página oficial: tfs.visualstudio.com. Allí nos dimos de alta y creamos una nueva cuenta:

singup

En nuestro caso usamos el nombre de “programandonet” con una cuenta de Live ID que ya teníamos anteriormente. Una vez has finalizado el proceso, al entrar en: misitio.visualstudio.com, deberíamos encontrarnos algo parecido a esto:

portal

En nuestro caso ya tenemos algunos proyectos creados, pero si es la primera vez, para poder seguir los ejemplos, deberíamos crear un proyecto nuevo, presionando el botón de “New Team Project”, y usando la plantilla de scrum:

new-project

Para poder entender mejor la plantilla de proceso que estamos usando, primero tendremos que definir la metodología que tenemos pensado usar: scrum.

¿Qué es scrum?

Podríamos definir scrum como un marco de trabajo, un conjunto de herramientas y protocolos a seguir con el fin de obtener un objetivo común: el éxito de un proyecto. Una metodología ágil que a pesar de estar enfocada en el desarrollo de software, es aplicable también a muchos otros campos como por ejemplo, el desarrollo de un vehículo de Formula 1.

La idea de un desarrollo ágil se fundamenta en la reducción de riesgos basándose en la división de un gran problema en problemas más pequeños. Estas divisiones serán acometidas como proyectos en si mismas, que deberán ser desarrollados a lo largo de un corto espacio de tiempo. A este ciclo se le denomina iteración y está compuesto por las fases de: planificación, análisis, diseño, codificación, revisión y documentación. Una vez finalizamos una iteración, se realiza una retrospectiva de cómo han ido las cosas, y se empieza una nueva iteración con las mejoras que se han propuesto.

Básicamente se asume que en un proyecto no todo va a ser como podemos pensar en un principio. Nos vamos a encontrar problemas no previstos y los requisitos van a cambiar con el paso del tiempo. Ante estos cambios lo único que podemos hacer es adaptarnos. Por esta razón dividimos el proyecto: para que las cosas que pueden ir mal vayan mal pronto, y así podamos ir afinando el proceso antes de que sea demasiado tarde.

Dentro de scrum estas iteraciones reciben el nombre de sprints y suelen durar de 2 a 4 semanas. El objetivo de cada sprint es que al finalizarlo, el equipo haya conseguido un producto potencialmente entregable. Es decir, algo que funcione, que se pueda probar y sobre lo que se puedan proponer modificaciones.

Roles

Antes de comenzar a trabajar debemos definir los roles de los diferentes miembros del proyecto. Scrum divide en dos grandes grupos de participantes:

Los comprometidos por el proyecto:

Y los implicados con el proyecto;

En lo que respecta a la gestión que deberíamos realizar, solo serían relevantes los perfiles comprometidos con el proyecto. Para añadirlos a TFS lo primero que tendríamos que hacer es crear un equipo de trabajo. Para ello nos tendremos que dirigir al portal web principal de nuestro sitio de TFS (misitio.visualstudio.com), y dentro de este, al panel de configuración. Esto se hace presionando en el icono con forma de rueda, arriba a la derecha:

configuration

Si no lo hemos hecho ya, nos aparecerá una pantalla para que seleccionemos el proyecto que queremos configurar. Y al seleccionarlo, veremos que automáticamente el sistema nos ha creado un equipo con el mismo nombre que nuestro proyecto. Al presionar sobre este equipo podremos gestionar los miembros del mismo:

team-management

En este caso, hemos añadido a todo nuestro equipo de desarrollo que está formado por 4 personas.

Otra forma que tenemos de realizar esta operación es entrar en la página “home” (dashboard) de nuestro proyecto y fijarnos en el panel de equipo de nuestra derecha. Haciendo clic en “Manage all members…”:

dashboard-team

 

El proceso

Como hemos comentado anteriormente, scrum es iterativo. Se divide en una serie de sprints que se van realizando hasta el momento en el que el proyecto se considera terminado. Una forma rápida de explicar el proceso sería el siguiente gráfico:

scrum-proceso

Aquí se puede observar que todo el proceso se inicia con la recogida de requisitos, y terminará cuando el resultado del feedback proporcionado por las partes implicadas sea que el producto está terminado.

Gestión del backlog

Asumimos que ya están todos los roles preparados para empezar con el proyecto, o al menos ya tenemos una figura de Product Owner, el propietario del producto. Entonces es el momento de empezar a recopilar requisitos. El product owner, además de ser la voz de nuestro cliente, también debe ser la persona que ordene y priorice aquellas necesidades que el cliente le ha comunicado.

Todos los requisitos relacionados con la aplicación, se recogen en un listado priorizado que recibe el nombre de pila de producto o Backlog. Y los elementos que encontramos en este backlog se denominan “user stories” o historias de usuario. Estas historias no son más que requisitos únicos, cortos, fácilmente redactarles, y que definen un requisito de forma rápida y en el propio lenguaje del usuario.

Es muy común que una historia de usuario esté definida mediante la plantilla:

As a [user] i want [something] so that [i can achieve that]

Donde los parámetros entre corchetes son sustituidos por el rol de la persona que lo solicita, qué es lo que le gustaría que pasará y cual el el objetivo que busca con dicho comportamiento.

backlog

Para la gestión del backlog, TFS nos ofrece dos herramientas que podremos encontrar en la sección “Work > backlog”. Una es la lista de requisitos como una lista ordenada según prioridad, que podemos ver en la imagen anterior. Y la otra es en forma de tablero, en la que podremos ver visualmente la evolución de las historias de usuario:

backlog-board

En adición, en la parte superior, conforme vayan desarrollándose los sprints, tendremos dos gráficas que nos darán un claro estado del proyecto y de la velocidad de nuestro equipo. Eso siempre y cuando se siga usando TFS en el resto de las fases.

Preparando el entorno

Antes de ponernos a programar, debemos definir nuestro marco de trabajo: responder preguntas como el tiempo del que dispone cada miembro de nuestro equipo, cuanto va a durar cada sprint inicialmente o qué tipo de especialidad tiene cada uno.

Una vez tenemos respuesta a estas preguntas tendremos que introducir estos parámetros en el portal de nuestro proyecto de Team Foundation Server.  Así pues, en la página principal del proyecto buscaremos a mano derecha la opción de “Configure schedule and iterations…”:

administration-widget

Al  hacer clic en esta opción aparecerá una ventana donde podremos decidir qué días tendrán lugar los próximos sprints:

configure-iterations

Tampoco deberíamos obsesionarnos con configurar todos los sprints, ya que la duración de los mismos podría cambiar si el equipo considerara que son, o demasiado breves, o demasiado largos. En este sentido recomendamos mantener consistente la duración y que por lo general tengamos entre ninguno y un solo cambio de duración de un sprint por proyecto. Pero no obstante, creemos que es mejor ir configurando todo sprint a sprint.

Otro de los datos que serán muy útiles, sobre todo cuando nos encontramos con equipos multidisciplinares, es el cálculo de capacidades. Una vez tenemos definido el sprint, podemos seleccionarlo dentro de la pestaña “Work” e introducir para cada uno de los miembros del equipo, cual es la actividad que van a desarrollar, el tiempo que van a dedicar al trabajo por día y si tienen vacaciones durante el sprint:

capacity-planning

En realidad es una tarea que no nos tomará más de 10 minuto y a cambio, gracias a estos datos, más adelante, seremos capaces de medir el trabajo que podemos asumir a lo largo de un sprint.

Planificación del sprint

Para comenzar con las liturgias que engloban al equipo, está la reunión de planificación del sprint o “sprint planning”. El resultado de esta reunión debe ser un listado de tareas que se van a desempeñar a lo largo del sprint para conseguir un objetivo marcado.

Al principio de la reunión, el product owner deberá explicar el backlog y proponer las historias de usuario más prioritarias. Y el equipo deberá realizar preguntas sobre las dudas que puedan surgir, evaluar estos requisitos y decidir cuales son los que se compromete a entregar a final de sprint.

Desde la vista del product backlog del tfs podremos arrastrar los elementos que hemos planificado encima del sprint que les corresponda:

backlog-dragdrop

Y haciendo doble clic en la user story, podremos añadir comentarios con la información extra que recolectemos durante la exposición del product owner.

Además de esto, el equipo deberá dividir las historias en tareas. Estas tareas serán estimadas (usando el poker planning, por ejemplo) y en algunos equipos hasta se auto-asignan según las cualidades de cada uno.

Así que una vez hemos asignado los elementos del backlog al sprint actual, podemos hacer clic la etiqueta y añadir tareas que dependan de los requisitos. Haciendo doble clic en las tareas podremos añadir detalles sobre su implementación, las estimaciones e incluso a qué actividad se refiere:

task-edition

Lo interesante de asignar la actividad de una tarea es que automáticamente podremos ver en unas barras a la derecha si estamos excediendo el tiempo de trabajo de las personas dedicadas a esas actividades o por el contrario si podríamos comprometernos a realizar más trabajo.

capacity-bars

Ahora ya tememos todo preparado para que el equipo empiece a trabajar…

Trabajo diario

Dentro de un sprint, dividimos el trabajo por días. El empezar la jornada, aunque algunos equipos lo dejan para el final del día, tiene lugar la daily meeting o standup meeting. Ambas nomenclaturas definen bien este tipo de reuniones ya que se realizan de forma diaria y los asistentes deben estar de pie. Esto responde a que esta reunión tiene que durar un máximo de 15 minutos, y si permaneciéramos sentados la gente se siente cómoda y es más fácil extenderse.

A un daily meeting puede asistir cualquier persona interesada, pero solo tendrán voz los roles comprometidos por el proyecto: el equipo, el scrummaster y el product owner. Generalmente se hace una ronda en la que cada uno de los asistentes debe responder a tres preguntas: