Aumentando la granulariad de las políticas en Team Foundation Server

Una necesidad que nos surge a menudo cuando establecemos políticas en Team Foundation Server, es establecer diferentes póliticas a diferentes proyectos o incluso a diferentes partes de un proyecto. Las motivaciones de esta necesidad pueden tener su origen en diferentes apectos, por ejemplo en partes de nuestro proyecto sometidas a fuerte investigación nos puede interesar relajar algunas de las politicas. O en partes más sensibles a seguridad por ejemplo nos puede interesar establecer unas politicas propias más fuertes.

Para aquellos que no estén familiarizados, las políticas que por defecto nos proporciona Team Foundation Server son:

Análisis de código (Code Analysis): Esta política obliga a ejecutar un análisis de código antes de poder subir las fuentes al gestor de fuentes.

Política de pruebas (Testing Policy): Asegura que las pruebas especificadas en unas determinadas listas de pruebas (asociadas a la política) se ejecutan satisfactoriamente antes de poder integrar el código en el gestor de fuentes.

Elementos de Trabajo (Work Items): Exije que los antes de subir cambios al gestor de fuentes, estos se asocien con uno o varios.

Volviendo a lo que nos ocupa, aplicar diferentes políticas a diferentes partes de nuestro proyecto, debemos saber que no es algo que Team Foundation Server nos permita por defecto, para ello debemos instalar TFS Custom Path CheckIn Policy.

La política Custom Path CheckIn Policy trabaja con las políticas existentes en Team Foundation Server y proporciona un mecanismo que permite especificar que políticas se aplican a cada carpeta del gestor de fuentes. Tambien permite filtrar a que archivos (por extensión se aplicarán las políticas), por ejemplo para forzar un Work Item relacionada cuando se haga Check In de un archivo *.vb, *.cs, o *.*proj. Además como esta pólitica se distribuye como código fuente es un excelente ejemplo de como implementar una.

En cualquier caso, mi recomendación es utilizar esta herramienta para establecer políticas más ferreas para ciertas partes y no para relajar las políticas de algunos componente del proyecto.

Estaré en el Tech Ed

La proxima semana estaré en el Tech Ed de Barcelona. Mi tercer Tech Ed. Es un evento que me encanta, en el que dedico 4 días a formarme, a tiempo completo. Todos los lectores que vayan por allí que por favor me saluden, me encanta conocer a la gente que lee este blog y charlar con ellos, siempre surgen temas interesantes.

Quizá me guste tanto este evento por que es la única formación explicita que hago para mí año tras año, despues de dedicar gran parte de mi tiempo a formar a otros.

Del Tech Ed de este año espero sacar una completa compresión de las consecuencias que tiene a nivel arquitéctonico la llegada de .Net 3.0. Tambien iré a alguna sesión sobre Sharepoint y SQL Server, y alguna más 'geek' de bajo nivel, dedicada a C++, depuración avanzada, optimización o aspectos internos de Windows que me suelen gustar mucho. Tambien ire a alguna sesión de Rafal Lukawieski solo por el placer de verle dar una charla, hable de lo que hable (sin duda le vere en la sesión Microsoft Solutions Framework 4.0 Core and its Family).  Kimberly Tripp hablando de SQL Server es tambien otro de los 'imperdibles'.

Tambien quiero ver a Ivar Jacobson uno de los padres de RUP, hablando de Ess UP, la metodología 'ágil' derivada de RUP e integrada en TS (presentan esta integración en el Tech Ed). Si relamente han logrado librar de toda la burocracia a RUP e integrar decentemente el resultado con Team System, habrá que tener en cuenta esta metodología.

Sobre Team System no he visto casi nada nuevo en la agenda, a parte de lo ya comentado, procuraré ver alguna sesión sobre Visual Studio for Database Professional y, si hay, alguna avanzada sobre testeo de aplicaciones.

Estad atentos… prometo un post diario contandoos lo más relevante de las sesiones a las que asista.

Métricas mal entendidas

Vuelvo a leer a Antonio Quiros explicando su visión sobre la gestión de proyectos, en el número de Noviembre de dotNetMania, la revista de referencia en el mundo .Net en castellano. Ya comente lo poco que compartía su visión de la gestión de proyectos de software en un anterior post: ¿Nos podemos caer de maduros?. Pero no me resisto a comentar de nuevo sobre este tema.

Este més le toca a las métricas. Ya desde el propio título del artículo empiezo a disentir de la visión de la gestión de proyectos de Antonio Quiros: Métricas para la EVALUACIÓN de procesos de contrucción de software.

Que nadie piense que menosprecio el valor de la métricas. Las metricas son una arma de suma importancia para ganar información sobre los proyectos que nos permita gestionarlos mejor y reaccionar antes a los problemas.

Pero, si algo a descubierto la ingenieria del software en los últimos tiempos, es, que las métricas no sirven para evaluar. El motivo es sencillo, las personas son mucho más inteligentes que las métricas. Los proyectos son un sistema dinámico formado por personas dinámicas. Si tu estableces una métrica del estilo % eficiencia = 100 * (horas previstas / horas reales) es facil preveer como se va a mejorar esa métrica, ¡no reportando horas reales! es decir perdiendo información. Información que es valiosa sobre tu proyecto. El punto aquí no es que las métricas propuestas por Antonio Quiros sean más o menos validas, sino que para lo que no son validas, como cualquier otra, es para evaluar. Utilizar las métricas para evaluar nos puede llevar a generar una cultura de cumplimiento, en la que pongamos el proceso sobre las personas, olvidando la importancia de estas.

La métricas prescriptivas, del estilo 'la eficiencia tiene que ser mayor de x valor' se tienden a sesgar cuando se utilizan para evaluar. Y el problema es que cuando los desarrolladores sesgan las métricas el jefe de proyecto pierde valiosa información. Otro factor dañino de utilizar las métricas para evaluar, es que los desarrolladores se las apañaran para mejorar esas métricas sobre las que evaluamos, olvidando aquellos aspectos del proceso de desarrollo que no se evaluan. Y siempre hay algún aspecto que no se evalua, sea este más o menos explicito.

Bien, si las métricas no sirven para evaluar y no pueden ser prescriptivas, ¿para qué sirven?. Sirven para recopilar información sobre nuestro proyecto, que nos permita una mejor toma de decisiones. Para ello debemos analizar las métricas no de manera prescriptiva, buscando una manera de estar en cierto rangos, sino de una manera descriptiva, viendo las métricas de una manera gráfica y multidimensional, relacionando varias de ellas, por ejemplo defectos abiertos, respecto a tareas bloqueadas, para ver que hay defectos que nos están bloqueando tareas.

El problema es que esa mirada, descriptiva, multidimensional y gráfica a las métricas, no es constante, debe cambiarse de proyecto a proyecto e incluso en diferentes momentos de un mismo proyecto. Esta visión de las métricas es la que ayuda a mejorar el proceso de desarrollo, aunque, por mucho que pese a algunos gestores no sirve para evaluar el desempeño. No es tan comoda como la visión prescriptiva, pero es mucho más ágil y nos permite detectar problemas mucho antes en aspectos sobre los que no tenemos métricas explicitamente establecidas; y lo que es más importante, evitar que los desarrolladores sesguen las métricas. El acercamiento a las métricas de manera descriptiva, multidimensional y gráfica es el que propone MSF e implementa Team System. Es cierto que es dificil de llevar a cabo sin herramientas adecuadas, pero ahora esas herramientas existen: VersionOne, Team System…

Ojo, nadie piense que este sesgo de las métricas es un proceso consciente del desarrollador, es incosciente. Pero es evidente que si a mi me evaluan por tal o cual factor es ese el que voy a tratar de maximiza, aunque probablemente me olvide de otros. Sobre este tema es especialmente esclarecedor el artículo 'Larry's rules of software engineering #2: Measuring testers by test metrics doesn't'.

En mi opinión el principal problema de las métricas que propone Antonio Quiros es que todas son subceptibles de ser sesgadas del mismo modo: trabajando horas de las que no informas. No voy a ser mal pensado y deducir que esto es precisamente lo que tratan de buscar estas métricas (y muchas otras propuestas con anterioridad). Con esta simple acción, trabajar más horas de las oficiales, mejoras todas las métricas que propone en su árticulo, y a medio plazo ¡destrozas a tu equipo de desarrollo!. Espero que en los proyectos en los que se aplican esas métricas vayan acompañadas de una clara política de ferreo control de excesos de horarios, pero, conociendo esa industria me temo que no sea así. Las métricas propuestas en el artículo caen en el error, ya descrito hace 15 años en Peopleware, de realizar el llamado 'spanish management', nombre que tiene su origen la gestión realizada por los conquistadores sobre los recusos de las tierras Americanas. Básicamente consiste en mejorar la productividad no mediante mejores prácticas sino mediante mayor utilización de recursos, práctica solo sostenible a corto plazo.

Por último me sorprende ver en el artículo métricas que hacen referencia a líneas de código. ¿Sabe Antonio Quiros cuantas lineas de código se generan en un IDE moderno con solo arrastrar un botón? (Se que lo sabe). ¿Cómo se comparan esas líneas con las necesarias para escribir una capa de acceso a datos empresarial? En los tiempos que corren la línea base se debe establecer en puntos función. Y los puntos función solo sirventras un largo proceso de ajuste por tipo de proyecto y organización. Tambien hecho de menos algunas de las métricas clasicas, por ejemplo las relativas a bugs, a cambios en los requisitos, a retrabajo, etc… realmente centradas en el desarrollo de software y no en la gestión mal entendida de recursos.

Para cerrar un poco de humor relacionado con el tema de los datos:

Estimando (no practicando la brujería)

Las estimaciones son necesarias, sin duda, para hacer una primera aproximación a la dimensión de la tarea que vamos a realizar. Sea cual sea la indole de esta tarea. Sentada esta base, me interesa comentar cómo se maneja la estimación en el 'mundo real' y que errores tendemos a cometer.

El primer punto a tener en cuenta es que las estimaciones solo son estimaciones. Esto que, a priori, es una perogrullada, se tiende a obviar. Los involucrados en los proyectos, especialmente los roles involucrados en la gestión del proyecto y la relación del cliente, tienden a olvidar esto. Tenemos que entender que cuando un desarrollador da una estimación no conoce muchos de los aspectos que con más fuerza influiran en la duraciona de la tarea, como, por ejemplo, la dificultad técnica. Además estos aspectos son mucho más dificiles de ver cuanto más lejano está el punto de incio de la tarea. Las estimaciones con estimaciones, no contratos. Cuando alguien convierte las estimaciones en contratos esta realizando un acto de brujería no de ingeniería del software. Brujería por que esta confiando en artes adivinatorias y porque esta forzando la voluntad de quien realizo la estimación. Si una estimación no nos gusta solo podemos añadir recursos o recortar características para que se ajuste a nuestras necesidades.

Si bien las estimaciones no son compromisos, solo estimaciones, todos hemos vivido situaciones, en las que se manejan como tales. ¡Hay incluso empresas que miden a sus desarrolladores por como de buenos son cumpliendo sus estimaciones!. Y lo que es peor aun ¡hay empresas que solo valoran este aspecto del trabajo!. No creo que no sea un aspecto relevante, el problema es que cuando solo se valora un aspecto del desarrollo, los desarrolladores tendemos a optimizar ese aspecto olvidandonos de otros y esto es, en mi opinión, extremadamente dañino para el proyecto. Pero eso es algo de los que hablaré en otro post. Siguiendo con lo que nos ocupa, y teniendo claro, que nuestras estimaciones se tratan a menudo como compromisos, que en nuestra imagen como desarrolladores depende de como de buenos seamos estimando, ¿qué podemos hacer?. La situación no es facil, en muchas ocasiones, ¡te van a valorar por cumplir compromisos establecidos sobre información insuficiente!. Pues bien hay ciertas reglas a la hora de comunicar estimaciones que es interesante seguir:

¡Si te piden una estimación, estima!: No des una estimación a la ligera, nunca. Si alguien te pide una estimación tomate un tiempo, directamente proporcional al tamaño de la tarea a estimar y a cuan lejos se encuentra su inicio, para realizar esta estimación. Es necesario hacer el intento consciente de lograr la mayor información posible sobre lo que estás estimando. Recuerda que tu imagen profesional, desgraciadamente, puede estar en en juego. La respuesta adecuada cuanto te pidan una estimación siempre es 'lo estudio y te comento'.

!Defiende con uñas y dientes tus estimaciones!: ¿Cuantas veces al momento de dar una estimación te la intenta cambiar?. ¿Y cuantas veces tienes que ceder?. Recuerda que ceder en una estimación no sería 'tan importante' pero estás cediendo ¡en un compromiso!, aunque no lo parezca. Para poder mantener una estimación tienes que tener argumentos, y si no has tomado tu tiempo en realizar una estimación argumentada dificilmente la vas a poder mantener.

!No olvides las tareas 'menores'¡: A menudo al estimar olvidamos las tareas menores, sin embargo estas suponen un porcentaje alto del trabajo total del proyecto.

!Recuerda que tendemos a ser optimistas¡: Está estadisticamente demostrado (pag. 168 de Rapid Application Development de Steve Mcconnell si quereís la justificación) que tendemos a ser optimistas en nuestras estimaciones. Debemos recordarlo. En el gráfico adjunto tambien se puede observar como nuestra estimaciones tienden a desviarse más hacia el lado optimista. Si X es lo que hemos estimado al principio del proyecto, lo probable es que el proyecto duré o cueste 4 veces más y solo 0,25 veces menos.

!Las estimaciones se refinan¡: Es necesario, ya que las estimaciones inciales se dan con escasa información ir refinandolas a lo largo del tiempo según vamos avanzando y ganado información sobre el problema inicialmente estimado. No es interesante saber como de buenos somo estimando, sino saber como de buenos somos haciendo que nuestras estimaciones converjan (ver el gráfico adjunto). Cuanto antes converjan, mejor estamos obteniendo la información necesaria para resolver el problema estimado y antes lo completaremos.

En un proximo post hablaré sobre como creo que debemos manejar las estimaciones cuando somos quienes las recibimos, no cuando somos quienes las damos.

Para terminar os dejo algunos recursos interesantes sobre estimación:

El Curso de Gestión de Proyecto de la Universidad de Columbia tiene bastante material sobre estimación.

Steve McConnell tiene un libro (en inglés) de obligatoria lectura:
Software Estimation: Demystifying the Black Art

Además tambien tiene una herramienta gratuita para estimación.