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étricasdel proyecto.
Fuente: http://geeks.ms/blogs/rcorral/archive/2006/11/27/aacute-reas-e-iteraciones-en-tfs-i.aspx
# re: [DSL] Como consumir un DSL a traves de codigo (extremo … extremo)
Excelente ElBruno, esta serie está realmente fantástica!. Ahora, una consulta, en tiempos recientes solo he visto 2 DSLs, uno era un diseñador de clases que te permitía relacionar las propiedades con campos de la DB y te generaba el código y otra era una DTE que también te generaba el código. No se si es porque esos son los ejemplos de dsls que provee microsoft o que, pero no he visto hecho nada muy novedoso con estos. Tenes idea de algúna DSL para encarar algún problema específico un poco mas
creativos que los que te comenté y que se esté usando realmente?
Fuente: http://geeks.ms/blogs/elbruno/archive/2007/10/09/dsl-como-consumir-un-dsl-a-traves-de-codigo-extremo-extremo.aspx