El Bruno

Buenas,

este post no comentará nada nuevo, asi que si quieres ahorrarte el tiempo de leer obviedades, es buen momento para darle a la [J] en el Google Reader o al [CTRL+F4] si has llegado directamente hasta aquí. Si por otra parte esperas encontrarte con un buen contenido técnico sobre las tripas de Team Foundation Server 2010 o con algún truco mágico que te salve el final de un proyecto ajustado, pues de nuevo [J] o [CTRL+F4].

Ahora que ya he aplicado una técnica de disperción basada en ser borde como House (aunque no tanto, que todavía no tengo bastón); pues soltaré el siguiente cubo de agua fría en todos aquellos productos que tienen a su alcance una excelente herramienta combinación de herramientas de trabajo, como Visual Studio 20XX + Team Foundation Server 20XX y no las aprovechan.

En mi día a día como consultor, ya he perdido la cuenta de la cantidad de veces que me he encontrado con equipos de trabajo, de gente muy capaz que utiliza “sólo” a Team Foundation Server como gestor de código fuente; vamos que han migrado de Visual Source Safe a Team Foundation Server, pero no han sabido aprovechar las capacidades de la nueva herramienta para mejorar el trabajo diario.

Un gran ejemplo, es el que se puede ver en la figura a la derecha, donde la base de Team Foundaiton Server es explotar las relaciones entre

• WorkItems
• Builds
• Source Control

Muchas veces he escuchado, que es muy tedioso gestionar las tareas, bugs, etc.; o que trabajar con una estregia de Branching y Merging es muy complicado; y que automatizar la compilación y empaquetado de software requiere mucho esfuerzo; pero el gran problema frente a estos argumentos, es que las ventajas que dá el comenzar a trabajar con diferentes principios, no tiene una métrica con la que comparar. Si actualmente no es posible conocer aspectos como los siguientes, pues lo tendremos muy díficil si queremos cambiar:

• Cuánto trabajo no planificado estoy agregando a mi pila de trabajo?
• Puedo mantener un esquema de desarrollo correctivo y desarrollo evolutivo en paralelo?
• Soy capaz de empaquetar y probar mi software o aplicación rápidamente?

Estas preguntas son un pequeño ejemplo, pero si queremos realmente hacer un análisis del estado de nuestro software deberíamos pensar en por ejemplo, aplicarnos el test de las 12 preguntas de Joel Spolsky (lectura altamente recomendada si no conoces a este personaje del mundo de la informática).

Un ejemplo que veo muchas veces es el siguiente:

Supongamos que tenemos a un equipo de desarrollo que trabaja desarrollando un sitio web (silverlight, asp.net mvc, webforms, o lo que esté de moda); y el día lunes ponen una versión 1.0 del website en producción. El proyecto ha sido todo un éxito, y como durante la fase de testing no se encontró ningún error, pues el equipo de desarrollo comienza a trabajar en los cambios para la versión 2.0 del website. Uno de estos cambios supone un cambio muy grande en la arquitectura del mismo, asi que es uno de los primeros cambios; y una vez implementado se continua con los demás. Cuando ha pasado un tiempo, los usuarios reportan un error muy grave en el website; y claro –> suenan las alarmas. El jefe del equipo de desarrollo, analiza el problema, y da con el error; pero para implementar la solución, va a tener que llevar además una serie de nuevas features y cambios muy grandes a producción, ya que la forma en la que trabaja con el gestor de código fuente no le permite implementar este cambio aisladamente de  elos nuevos desarrollos.

Este ejemplo, que parece muy trivial, es bastante común y la verdad con las capacidades de los gestores de código fuente que tenemos actualmente, pues es una pena no adoptar una estrategia de Branching y Merging, que permita dar soporte como mínimo a los desarrollos evolutivos y a los desarrollos correctivos. Para esto, solo hay que leer algún documento que nos enseñe a aprovechar las capacidades de las herramientas. La guía de Branchng y Merging de TFS2010 en Codeplex es un buen ejemplo (http://tfsbranchingguideiii.codeplex.com/)

Agora bien, volvamos a Team Foundation Server 2010 o versiones anteriores –> es una gran herramienta, no es solo una evolución de Visual Source Safe; y una de las grandes ventajas que nos propone es que, una vez que decidmos cambiar la forma de trabajo, toda la información relacionada entre Source Control, Builds y WorkItems, está disponible para analizar y ver la realidad del estado de nuestros proyectos. Yo usualmente comento, que para lo bueno y para lo malo, TFS es transparente en la información que muestra. Y además en la que no muestra, porque por ejemplo: si no somos constantes en seguir una línea de trabajo y organizar nuestros WorkItems, pues al tiempo veremos que los informes de proyectos muestran información que puede parecer errónea; pero que realidad es una foto de como trabaja nuestro equipo.

En algún próximo post, explicaré lo que yo llamo [baby steps] sobre como comenzar con Team Foundation Server; tratando de no atarme a ninguna metodología de procesos; pero si criticando a quienes tienen la herramienta y no la utilizan correctamente

Saludos @ Home

El Bruno

• PD: como en el post anterior, una vez más he tratado de ser independiente de la metodología de procesos con la que trabajemos