Iteraciones en Team Foundation Server

Un punto de confusión habitual en las implantaciones de Team Foundation Server son las áreas y las iteraciones. ¿Qué son? ¿Para qué sirven? ¿Cúantas defino? ¿Cuales defino?.


En este primer post voy a abordar las iteraciones y en uno posterior las areas.

MSF define las iteraciones como un periodo fijo de tiempo en el que programar tareas. Una iteración es generalmente un periodo fijo de entre dos y seis semanas. Las iteraciones generalmente son numeradas consecutivamente y siguen una a otra de manera continua.

A parte de esta definición, que puede ser más o menos acertada, las iteraciones son siempre puntos de control, aprendizaje y planificación. Con independencia de la metodología utilizada, lo que todas las metodologías populares tienen en común, es que al principio de una iteración se planifica el trabajo que se va a abordar a corto plazo y al final de una iteración se sacan conclusiones de la iteración reciente terminada. Este proceso de mirar atrás se debe hacer siempre con el afán de que nos sirva para ir hacia adelante. El final de una iteración siempre coincide con el comienzo de otra, de manera que en ese punto lo que vemos al mirar atrás son los resultados de una iteración y estos resultados son los que nos deben guiar a la hora de planificar la siguiente iteración.

Evidentemente, el proceso descrito, se puede aplicar de manera anidada. Una iteración puede contener a otras. Esto es así porque al principio de un proyecto es habitual no tener claro en un alto nivel de detalle c uales serán nuestras iteraciones, y por lo tanto podemos definir 3 o 4 iteraciones que luego iremos refinando en subiteraciones. Otro motivo para anidar iteraciones es la posibilidad de tener, en desarrollos grandes, diferentes equipos en diferentes iteraciones, pero esto no es habitual.

A veces se tiende a definir iteraciones en función de hitos en lugar de en función de un horizonte temporal. En mi opinión esto es una mala práctica. Supongamos que definimos una iteración cómo «Implementación de los servicios del backend». Si acumulamos retraso, lo que ocurre es, que cuando a ese punto de control y planificación que es el fin de una iteración, es cuando vemos que estamos retrasados y poco podemos hacer ya. Es claro que parece conveniente realizar periódicamente actividades explicitas de control, aprendizaje y planificación detalla. A la hora de establecer iteraciones es conveniente establecer una meta, «Completar la implementación de los servicios del backend» es sin duda un buen objetivo para una iteración, suponiendo que sea realista para la duración de la iteración.

La duración de las iteraciones es fija en algunas metodologías como Scrum, en otras como MSF se decide como parte de la planificación de la misma.


En la planificación de una iteración debemos:



  • Decidir cuanto durará

  • Establecer que trabajos se realizaran

  • Estimar en detalle estos trabajos

  • Asignar quien realizará estos

  • Establecer una meta para la iteración

Todo ello sin perder de vista los que logramos en la iteración anterior.


Es útil que las iteraciones sean todas de la misma duración en días laborables, porque esto las hace directamente comparables entre sí. Si en la iteración anterior se descubrieron 20 bugs y en la actual 30, algo ha pasado con la calidad de mi proyecto o su control. De todos modos nada en Team Foundation Server liga iteraciones y tiempo.

Un factor que no debemos perder de vista es que la gran mayoría de los informes de Team Foundation Server nos permiten filtrar los datos por iteración. En consecuencia, otro aspecto a tener en cuenta a la hora de definir las iteraciones en Team Foundation Server es con que granularidad nos resultará cómodo manejar las métricas del proyecto.


En un siguiente post abordaré el tema de las áreas y su utilidad.

4 comentarios sobre “Iteraciones en Team Foundation Server”

  1. Por fin entiendo de una manera clara las iteraciónes en las metodologías. Mi duda sobre TFS es como podriamos superponer las estimaciones y la duración real de las tareas de manera gráfica, a parte de los KPIs que tan de moda están!!! Pero bueno eso quizas sea apartarse un poco del tema introducido ya se…

    Saludos.

  2. Hombre, esos datos estan en el datawarehouse de Team Foundation Server, así que no debería ser demasiado complicado el realizar un informe que mostrase esos datos.

    Para MSF for CMMI bastaría comparar el campo Estimate, con el valor que tengamos en Completed Work
    cuado cerremos la tarea, tanto las tareas como los requisitos tienen estos campos.

    Para MSF Agile, la cosa cambia un poco. Habría que cojer el primer valor dado para Remaining Work y tomarlo como estamación base.

    De todos modos la información que obtendrías, desde el punto de vista de gestión del proyecto no es que tenga muchísimo valor. Solo sirve para tratar de refinar tu proceso de estimación, pero claro, puede ser precisamente esto lo que te interese.

    Ya que hablas de los KPI, no esta de más leer y ver el video de Eric Lee sobre el tema: https://blogs.msdn.com/ericlee/archive/2006/07/07/659574.aspx

    De todos formas ojo con los KPI pues tienden a convertirse en métricas prescriptivas y estas pierden su utilidad muy pronto.

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *