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:
- On-premises: la modalidad de distribución de software tradicional que podemos instalar en nuestras propias máquinas, tantas veces como licencias hayamos adquirido. En resumen, la forma en la que siempre hemos comprado software, que recibe el nombre de Team Foundation Server 2012.
- Saas: que significa Software as a service, una modalidad de venta de un software que en lugar de instalarlo, lo utilizamos directamente sin preocuparnos por la infraestructura. Por lo general esto implica que ya no tendremos que realizar un desembolso económico grande para usar un producto, solo pagaremos por lo que consumamos. Esta versión recibe el nombre de Team Foundation Service y por ahora, permanece gratuita para equipos de hasta 5 miembros.
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:
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:
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:
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:
- Product owner: representa a cliente, a las personas que han solicitado el producto resultante de este proyecto. Es quien marca los requisitos y gestiona la prioridad de estos.
- ScrumMaster: es la persona responsable de que el proceso de scrum se ejecute correctamente. Se asegura de que se respeten las reglas y aísla al equipo de cualquier influencia externa. No hay que confundir este rol con el de jefe de equipo o project manager.
- El equipo: es el grupo de personas que tiene la responsabilidad del desarrollo del producto. Se auto-organiza, por esa razón no existe ningún rol de líder o jefe. Por lo general debe ser multidisciplinario, un conjunto de no más de 8 personas que puedan abarcar todas las tareas que conlleva el proyecto: análisis, diseño, desarrollo, pruebas, …
Y los implicados con el proyecto;
- Stakeholders (partes implicadas): Es esa gente que hace el proyecto posible, los implicados de alguna manera con el resultado del desarrollo. Los clientes, vendedores, usuarios finales…
- Administradores: Es la gente que se encuentra jerárquicamente por encima del proyecto. Los gerentes y managers que establecen el ambiente para el desarrollo.
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:
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:
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…”:
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:
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.
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:
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…”:
Al hacer clic en esta opción aparecerá una ventana donde podremos decidir qué días tendrán lugar los próximos sprints:
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:
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:
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:
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.
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:
- ¿Qué hice ayer?
- ¿Qué problemas encontré?
- ¿Qué voy a hacer hoy?
Esto no se hace para controlar a las personas, si no para favorecer la comunicación entre los miembros del equipo. Casi todas las liturgias de scrum van dirigidas a este objetivo. Se sustenta en la premisa de que si hay buena comunicación, es más fácil que las cosas salgan bien.
La ubicación de esta reunión debería ser todos los días la misma y a la misma hora, para que no exista duda alguna. Y sería interesante realizarla junto a la scrumboard. Esto es una tabla sobre la que vamos a ir gestionando las tareas del sprint, de la que ya nos habló Albert Cumplido en este artículo.
Team Foundation Server nos proporciona un tablero virtual para scrum que encontraremos en las sección “Work > board”:
Como podemos observar automáticamente nos muestra el tablero del sprint actual y podemos agrupar las tareas por elemento del backlog o por miembro del equipo. La mejor parte de esta scrumboard virtual es que podemos ir moviendo las tareas y estas se irán actualizando en tiempo real. Eso si, en scrum, cuando una tarea se da por terminada (se han cumplido todos los requisitos de la definición de “hecho”), no puede volver atrás. Si por A o por B el desarrollo de esta tarea ha tenido unas consecuencias no esperadas, esto debería repercutir en la aparición de un bug o una nueva historia que subsane los problemas que hayamos generado.
Otro de los artefactos relacionados con scrum en particular, y las metodologías ágiles en general, es el burn down chart. Una gráfica que podemos ver en la parte superior derecha de la scrumboard. Al hacer clic sobre ella podremos tener una vista ampliada, en la que se observarán mejor los detalles de la gráfica:
Es importante que el equipo tenga clara esta gráfica, ya que nos muestra el estado actual del sprint. Si estamos muy por encima de la línea de tendencia ideal es que vamos con retraso y si estamos por debajo, podría significar que hemos sobre-estimado el esfuerzo de las tareas.
Pero para que TFS nos muestre todos estos datos de una forma correcta, es necesario que el equipo vaya actualizando las tareas día a día. Y el control de código fuente junto con el Team Explorer de Visual Studio, nos van a ayudar.
Bastará con que dentro de Visual Studio, cuando un programador vaya a realizar un checkin, asocie mediante drag ‘n drop, una tarea. Esto se realiza en el panel de “Peding Changes” de la ventana de “Team Explorer”:
El punto negativo y que podría resultar tedioso es que el esfuerzo que le hemos dedicado a la tarea, deberemos introducirlo manualmente. Con respecto a este tema, una práctica muy útil es que antes de irnos a casa, cada miembro del equipo debe ser responsable de haber actualizado sus tareas y la scrumboard. O al menos si sería necesario hacerlo antes de cada daily meeting.
En scrum no se aceptan tareas con una estimación de duración de más de una jornada de trabajo. Si así fuera, se debería dividir en varias tareas más pequeñas. Por lo que todos los días deberá haber movimiento en la scrumboard.
El último punto del trabajo a tener en cuenta desde el punto de vista de TFS sería el Continuous Integration, que tendría lugar con la ayuda de la configuración de los procesos de build. Aunque este punto, quizá lo podamos tratar en un futuro con mucho más detalle.
Revisión del sprint
Una vez hemos llegado a la fecha de finalización del sprint, nos encontramos en el momento de la revisión del trabajo realizado. Tanto si hemos terminado todas las tareas como si no, se deberá informar y apuntar, para tenerlo en cuenta en posteriores sprints.
En el proceso de revisión es necesario involucrar a todos lo roles definidos en el proceso de scrum, tanto los implicados como los comprometidos. Se presentará el producto tal y como está en ese momento. Se responden preguntas y se admiten sugerencias.
La forma que nos provee TFS de recolectar el feedback de las partes interesadas del proyecto es la herramienta “Microsoft Feedback Client for TFS 2012”. Todo el proceso comienza con la petición de este feedback.
Si nos dirigimos a la página “home” de nuestro proyecto de Team Foundation Service, encontraremos en el widget de “Activities”, una opción llamada “Request Feedback”. Al pulsarla, se abrirá una nueva ventana donde se nos permitirá rellenar los detalles de esta petición:
Los tres detalles que nos permite rellenar son: los invitados a dar feedback, la forma de acceder a la aplicación para poder probarla y los elementos que deben tener más en cuenta, por ser los objetivos principales del sprint, a la hora de revisar.
El resultado de enviar esta petición será un email a cada uno de los stakeholders especificados, donde se le informará de todo. En este email además encontraremos un enlace para descargar la herramienta de feedback de Microsoft de forma gratuita.
Después de instalar el “Microsoft Feedback Client”, al ejecutarlo, lo primero que nos pedirá es la conexión con el TFS:
Acto seguido la aplicación nos pedirá que abramos la demo de prueba, siguiendo las instrucciones que especificamos anteriormente. Y después irá pasando por todos los elementos que indicamos que se debían revisar, para que el usuario pueda añadir comentarios, capturas de pantalla, notas de voz, …
Después de enviar el feedback, podremos acceder a él desde el portal de TFS, “Work > work items > Feedback”:
Es muy recomendable que la reunión de revisión sea en persona y con todos los roles a la vez. No obstante, de cualquier forma, también es muy recomendable usar la herramienta de feedback para poder almacenar en TFS todos los datos y así poderlos revisar con más calma. Tanto si la persona que reporta está o no en la reunión.
Retrospectiva del sprint
La última reunión que tiene lugar en a lo largo de un sprint es la retrospectiva. Una vez tenemos el feedback, esta vez reuniremos al scrummaster y el equipo, aunque el product owner puede estar invitado de oyente.
A lo largo de esta reunión se debatirán temas como la gráfica de burn down, la velocidad del equipo, las cosas que han ido bien en el sprint, que podría haber ido mejor y lo más importante: que cosas se van a hacer de forma diferente, buscando sacar el mejor resultado, en el siguiente sprint.
En esta reunión será muy importante manejar todos los datos que hemos ido recolectando con TFS, e incluso almacenar un resumen con las conclusiones de la reunión también dentro del sistema. De esta forma todo quedará archivado y accesible por todos los miembros del equipo.
Es la reunión donde más partido sacaremos a TFS de todas.
Al finalizar esta reunión deberemos volver al primer paso del proceso y volver a empezar con el siguiente sprint. Eso si, esta vez habiendo retroalimentado el proceso con la experiencia del sprint anterior.
Conclusiones
Aún sabiendo que scrum varía en cada equipo que se aplica, hemos intentado exponer un proceso lo más aséptico que hemos podido, para observar la potencia de TFS.
Hemos de reconocer que scrum nos parece un escenario muy bueno para el desarrollo de software. Y en este sentido, tantoTeam Foundation Server 2012 como Team Foundation Service han demostrado ser dos herramientas muy completas que nos ayudarán mucho con la gestión del proceso.
Todo esto a pesar de que muchos más detalles sobre la personificación del proceso, se nos han quedado en el tintero, como por ejemplo: las builds, la entrega continua, la integración continua, los code reviews o la potencia de las herramientas de testing.
Nosotros lo hemos probado y hemos llegado a la conclusión de que nos gusta. Si aún no lo has hecho, te invitamos a que uses una cuenta gratuita de Team Foundation Service, y durante el próximo sprint, realices un seguimiento en paralelo con esta herramienta, para que saques tus propias conclusiones.
