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:
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, tanto Team 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.