DNM+ Online
dotnetmania 2.0
Iterando con Team Foundation Server 2010
El uso de iteraciones en el ciclo de vida de los desarrollos es, a día de hoy, algo indiscutible y que todas las metodologías utilizan y tienen en cuenta. En Team Foundation Server 2010 dispondremos de herramientas basadas en los work items jerárquicos, así como de hojas de cálculo Excel que nos van a simplificar la tarea de la gestión de iteraciones.

Durante el ciclo de vida, iremos desarrollando nuestro proyecto a lo largo de iteraciones, que debemos planificar sabiendo qué capacidad de desarrollo tenemos durante esa iteración, contrastando con iteraciones anteriores. Igualmente podremos tenerlas bajo control, disponiendo en todo momento de la información de si estamos excediendo la capacidad de la iteración, o si tenemos más "hueco" disponible.
Antes de meternos en materia con TFS 2010, le recomiendo descargar la máquinas virtuales de Visual Studio 2010 Beta 1, que contienen todo lo necesario para que pueda hacer pruebas sin necesidad de instalar un servidor de TFS 2010 entero. En mi blog (http://bit.ly/VS2010VPC) tiene a su disposición los enlaces a las tres distintas versiones de las máquinas virtuales de prueba.

Definiendo los requerimientos Para empezar a trabajar con nuestras iteraciones, veamos cómo definir los requerimientos en TFS 2010 usando la plantilla de MSF Agile 5.0, que es una de las dos plantillas que vienen por defecto en TFS 2010, y que se corresponde con el marco de trabajo ágil propuesto por Microsoft Solutions Framework (MSF). En esta plantilla, los requerimientos se definen como historias de usuario, en las que vamos a describir, desde la perspectiva de un usuario, cada uno de los requerimientos del software que vamos a construir. Este sería el equivalente del Product Back­log de Scrum, que también se define en forma de historias de usuario. Las historias de usuario son un modo de definir requerimientos desde la perspectiva de un usuario que vienen dados por la siguiente estructura: Yo, como <tipo de usuario del sistema>, quiero <objetivo del requerimiento> para <razonamiento de su necesidad>. De este modo, tenemos una estructura básica y sencilla de tomar y transmitir los requerimientos. Estas historias de usuario son utilizadas en multitud de metodologías; para saber más acerca de ellas, un libro muy recomendado es User Stories Applied: For Agile Software Development, de Mike Cohn. Vamos a crear algunas historias de usuario en nuestro TFS 2010. Para ello, abrimos Visual Studio 2010 Beta 1 y conectamos con el servidor de TFS de la propia máquina virtual; utilizaremos el proyecto ya existente Agile, que está creado con la plantilla de MSF Agile 5.0. Si lo prefiere, puede usar un servidor propio que haya montado de TFS 2010, con un proyecto creado con MSF Agile 5.0, y que no sea un TFS de instalación básica, ya que las hojas Excel de gestión de iteraciones están en el sitio SharePoint que se crea durante la creación de proyectos, y la instalación básica de TFS no dispone de SharePoint. Para crear una nueva historia de usuario, basta con pulsar el botón derecho del ratón en la sección Work Items del team project, en Team Explorer, e indicar que se desea crear un nuevo work item de tipo User Story. En la figura 1 puede ver la interfaz de creación de una historia de usuario. Observe que el título ya se solicita con la estructura que especificábamos antes. Para este ejemplo voy a crear un par de historias distintas; con esto no hacemos un proyecto, pero sí una pequeña demo. Una de las historias la vamos a asignar a la iteración 1 y otra a la iteración 2. Lo habitual es que dentro de una iteración de, por ejemplo, un mes, nos quepan varias historias de usuario, que han de ser lo suficientemente pequeñas como para caber dentro de una iteración, salvo fallos en la estimación o imprevistos. Lo ideal es que las historias de usuario se empiecen y se finalicen dentro de la misma iteración. El siguiente dato a rellenar son los llamados story points. Este dato nos da una idea acerca de la complejidad de la historia de usuario; no es ninguna medida en concreto, pero nos valdrá para hacernos una idea de la complejidad del requerimiento con respecto a otros. Lo más recomendable es usar magnitudes de 10 en 10; así, una historia de 20 puntos es más compleja que una de 10, dejando huecos intermedios si es necesario afinar. Sobre esto también se puede escribir mucho, pero para nuestro ejemplo este pequeño resumen es suficiente. Otro dato muy importante, aunque no lo vamos a tratar aquí, es cuándo se da por realizada una historia de usuario. En los work items tenemos, dentro de la pestaña Details, un campo de descripción, donde se han de incluir los criterios de aceptación de fin del requerimiento.

Definiendo la iteración Para definir la iteración, lo primero que vamos a hacer es seleccionar, de nuestras historias de usuario, las que se hayan definido por el cliente, con nuestra ayuda, como más prioritarias y que serían deseables para una primera iteración. Estas historias de usuario las vamos a dividir en tareas, y aquí entra en juego una nueva funcionalidad que son los work items jerárquicos, que nos permiten definir nuevos tipos de relaciones, de tipo padre-hijo, que van más allá de los simples enlaces que ofrecía TFS 2008. Para agregar una tarea relacionada (padre-hijo) a una historia de usuario, en el listado de historias de usuario (consulta Open User Stories) pulsamos botón derecho sobre la elegida, y del menú contextual seleccionamos New Linked Work Item. En la figura 2 vemos cómo tenemos que crear esta relación. Una vez seleccionadas las opciones Child en Link Type, y Task en Work Item Type, le damos un título al nuevo work item, y el sistema nos llevará al formulario de creación de la nueva tarea. Esta nueva tarea ya estará asignada a la misma iteración que la historia de usuario, se habrá asignado al mismo usuario, y lo único que nos quedará será darle la duración estimada, lo que nos queda para completarla, y las horas completadas, como se muestra en la figura 3. Recuerde que las estimaciones de las tareas siempre las hace el equipo, cuyos miembros después las van a implementar. Daremos de alta varias tareas para cada una de las historias de usuario creadas, de este mismo modo, y ahora vamos ya a ver la planificación de nuestra iteración. Dentro de las librerías de documentos que se nos crean en el team project, en la carpeta Samples And Templates\Project Management, hay un documento llamado Document Template - Iteration Backlog.xlsm que nos va a servir de plantilla; lo abrimos, y lo vamos a grabar por ahora en local, con el nombre, por ejemplo, Iteracion1.xlsm (es muy importante guardarlo como .xlsm con macros). Para poder habilitar correctamente las macros que son necesarias, cerramos el fichero y lo volvemos a abrir habilitando las macros. Recuerde que para trabajar con esta hoja de Excel vamos a necesitar conexión con el servidor TFS. Por defecto, al abrir esta hoja Excel, la consulta que nos muestra es el listado de historias de usuario, con las correspondientes tareas hijas en jerarquía, de la iteración 1; por ahora vamos a trabajar con ésta. Todas las tareas que hemos creado hasta ahora estaban asignadas al mismo usuario: cambie la asignación de las tareas, ya que lógicamente no las ejecutará todas el mismo desarrollador, a varios de los usuarios de la máquina virtual; luego veremos cómo jugar con las asignaciones y ver qué personas tienen demasiadas tareas y cuáles tienen pocas. Esto es para el ejemplo; en proyectos reales, debería ser el propio equipo en conjunto el que se reparta las tareas. En la siguiente pestaña, Settings, simplemente seleccionaremos la iteración con la que vamos a trabajar (la 1), y establecemos una fecha de inicio y de fin (¡cuidado: en las máquinas virtuales tiene formato inglés mm/dd/aaaa!), e inmediatamente se nos dirá cuantos días tiene nuestra iteración, quitando los fines de semana. Por supuesto, la gente tiene vacaciones, formación, días libres, días festivos, etc. Toda esa información la introduciremos en la pestaña Interruptions, tanto las de los miembros individuales del equipo como las del equipo en general; con esto se afinará el número de días de la iteración. Por último, vamos a la pestaña Capacity, en la que tenemos que rellenar las horas de trabajo por día para cada uno de los miembros del equipo que tienen asignadas tareas en esta iteración. Recuerde que, aunque la jornada laboral es de ocho horas, no se está las ocho horas concentrado al cien por cien, ya que existen interrupciones, descansos, etc. Sea cauto y realista a la hora de poner este dato, ya que poner una información falsa lo que provocará es que no completemos la iteración a tiempo; una buena estimación suele ser 5 ó 6 horas por día como máximo. Una vez que rellenéis esa información, veréis como la hoja Excel cambia y nos muestra claramente la información del equipo, como en la figura 4, que nos informa que en nuestra planificación nos faltan 22 horas en esta iteración para completar todas las tareas, con lo que tendríamos que reajustar las historias de usuario que incluimos en esta iteración. También se nos muestra la distribución en horas de las tareas entre los miembros del equipo. En la figura 5 podemos ver como al desarrollador Doris Krieger "le faltan" 44 horas en esta iteración, y a los demás en total les sobran 22 horas, con lo que tendríamos que reajustar la distribución de las tareas e incluir algún desarrollador más. Como podéis ver, una vez introducidos los work items con sus estimaciones y relaciones oportunas, y simplemente rellenando la información de las fechas de la iteración en la hoja Excel, podemos obtener rápidamente la visión global de la iteración. En caso de querer realizar este mismo proceso para otra iteración, lo primero es cambiar la consulta de la primera pestaña, para obtener los ítems de la segunda iteración. Esto lo hacemos dentro de la lista de la primera pestaña mediante el botón Configure/List, y seleccionando, por ejemplo, la consulta Iteration 2 Backlog de las disponibles; y por supuesto, poniendo nuevas fechas y datos en el resto de pestañas.

Definiendo futuras iteraciones Bien, ya hemos acabado nuestra primera iteración, y tenemos la información de lo que habíamos estimado inicialmente, y de cómo ha ido todo finalmente, sabiendo cuántas historias de usuario hemos cerrado. Lo más habitual es que no se hayan cumplido las estimaciones al pie de la letra; esto es normal, son estimaciones, que tendremos que ir ajustando para las siguientes iteraciones. Precisamente ahora es el momento de realizar ajustes, para que en la siguiente iteración los cálculos de tiempo sean más aproximados a la realidad. ¿Recuerda los story points? Pues ha llegado el momento de usarlos. En la misma librería de SharePoint que la hoja Excel anterior, tenemos el fichero Document Template - Product Backlog.xlsm, que nos va ayudar a seleccionar qué historias de usuario nos entran en una iteración. Seguimos el mismo proceso que antes para poder habilitar correctamente las macros: guardar el documento en local y volverlo a abrir (hay otros métodos, pero éste es el rápido). Aunque esto deberíamos de hacerlo siempre antes de empezar a planificar iteraciones, vamos a hacerlo con la primera iteración ya cerrada. Cuando abrimos esta hoja Excel, se nos mostrará un listado con todas las historias de usuario del team project al que pertenece el documento. En la segunda pestaña, Iteration Planning¸ se nos mostrarán los story points totales de las iteraciones que tengan historias asignadas; ahora podremos asignar fechas a las iteraciones, así como el tamaño del equipo, y aquí es donde podremos sacar la información para planificar siguientes iteraciones en función de sus story points (recuerde que son una medida comparativa de magnitud, con la que podemos estimar qué historias de usuario nos caben en las iteraciones en función de los días disponibles). Por ejemplo, en la figura 6 podemos ver que en la primera iteración, con tres personas y 21 días disponibles, hemos conseguido completar 15 story points. A la hora de planificar las historias de la segunda iteración, vemos que por ahora solo hemos asignado historias con una suma total de 10 story points (5 menos que la anterior); pero sin embargo tenemos menos personas disponibles, aunque tengamos un día más, por lo que tenemos bastante información para decidir cuántas y cuáles historias de usuario abordar en la iteración 2.

Conclusiones Por supuesto, la planificación y estimación de iteraciones incluye muchos más factores de los aquí descritos; pero el objetivo de este artículo no es otro que el de mostraros, desde una perspectiva agnóstica de la metodología usada, cómo con el uso de los work items y una simple plantilla de Excel, tenemos bastante información de base a la hora de definir la duración y tareas de las iteraciones, cosa en la que creo que la práctica totalidad de las metodologías coinciden: el desarrollo iterativo.

blog comments powered by Disqus
autor
referencias