TFS y las reglas de CheckIn de asociación a WorkItems

Como ya sabréis lo que desarrolláis en Microsoft .Net, se pueden establecer reglas para que las operaciones de CheckIn en el repositorio de código de TFS, exijan asociar a cada subida de código uno o más WorkItems.

Esta regla, es mucho más importante de lo que parece, ya que esconde por detrás un grave problema de gestión y visibilidad del estado del desarrollo.

¿Qué ocurre si haces un CheckIn, y no asocias ningún workitem?. Pues que la tarea no está planificada, no se puede detectar a qué se han debido los cambios. Si no es un desliz, y realmente no hay tarea (workitem) planificada,

1. estamos haciendo algo innecesario, o bien
2. estamos haciendo algo necesario no planificado, o bien
3. estamos haciendo algo necesario, planificado, pero que está oculto.

• En el primer caso,  tendríamos al típico programador que dedica su tiempo a tareas agradables, que le gustan, o que simplemente está probando algo que se le ha ocurrido. Sería un caso típico de procrastinación (ver entradas anteriores en este blog sobre este tema).
• En el caso 2, hay varias opciones, pero una típica sería cuando hemos dado algo por cerrado, y recordamos un requisito de diseño, una funcionalidad que se habló pero no se incluyó en los workitems, etc.
• En el caso 3, por ejemplo, un ejemplo habitual es cuando queriendo o sin querer, hacemos cosas planificadas en el workitem, pero se nos olvida asociarlo. Puede ser que se nos olvidara por ejemplo las pruebas unitarias, así que las pasamos, corregimos cosas de un workitem antiguo, pero no lo indicamos.

En proyectos con metodología no iterativa, muchas veces estos casos quedan ocultos, y tienen un impacto menos apreciable en la planificación (aunque no dejan de ser importantes). Sin embargo, con metodologías iterativas, tipo Scrum, el impacto es mucho mayor. El hecho de que en una iteración de 1 o 2 semanas, tengamos tareas realizadas pero no planificadas, puede suponer una desviación importante. Si ya las tareas que se realizan encima no son necesarias, el desastre está asegurado.

¿Qué tiene que ver esto con la calidad? Pues mucho, porque como veremos en un próximo post sobre cómo medir la calidad, ésta no es sólo "nº de defectos". En el desarrollo de software, un factor clave es la trazabilidad. Si no somos capaces de saber en qué partes de nuestro programa están implementados los requisitos (o las "Historias de Usuario" en terminología Scrum), una de dos:

• O alguien ha rellenado una matriz de trazabilidad (infame pero útil documento del cual algún día hablaremos)
• O simplemente, no podremos identificar dónde están implementados esos requisitos. Como supuestamente estamos abiertos al cambio, cualquier cambio en los requisitos hará que tengamos que dedicar un tiempo precioso a rastrear el código para saber cuánto hay que cambiar y dónde. Y si no somos capaces de identificar el impacto de un cambio, me rio yo de las estimaciones que haremos.