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 Backlog 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.
