Muchas empresas están intentando implantar Team Foundation Server, lo que es una gran noticia, pues tengo puesta mucha fe en que esto mejore el nivel metodológico de las empresas que lo implantan.
Pero intuyo, que muchas empresas están fallando en este aspecto, no están logrando mejoras en el aspecto metodológico, solo están usando mejores herramientas, no mejores prácticas.
Por los comentarios que me llegan en cursos y charlas que imparto casí todas las empresas logran sacar beneficios en lo relativo a las mejoras a nivel de herramientas de Team Foundation Server (gestión de fuentes, gestión de bugs..), que no es poco, pero muchas empresas están desperdiciando la oportunidad que ofrece Team System en lo relativo a mejorar a nivel metodológico (entendio como las prácticas que usamos para desarrollar software, no como cómo de buenos somos siguiendo un plan trazado previamente).
Creo que esto tiene dos causas: la automedicación y la resistencia a aceptar los 'mindsets' y los principios de la metología elegida.
Le llamo automedicación al hecho de que la mayoria de las empresas están intentando implantar Team System por si mismas, sin la ayuda de alguien que conozca profundamente la herramienta y, aun más importante, las bases 'teoricas' que sustentan las características que Team System y Team Foundation Server proporcionan. Es dificil que alguien saque todo el provecho a las tecnicas que TFS proporciona si no entiende la esencia des estas técnicas y por qué aportan valor. Por mucho que tengas un excelente soporte para refactoring o para construcciones diarias, solo lograrás provecho de ellas si conoces sus fundamentos y las mejoras que se derivan para tu desarrollo si las utilizas. Instalando TS y TFS obtienes las herramientas, pero tus desarrolladaros no alcanzan por arte de magia un entendimiento y un convencimiento claro de por qué deben usarlas. Por ello, en mi opinión, para garantizar que vas a exprimir todo el valor que TS y TFS puede darte, primero necesitas formarte en las técnicas que TFS y TS te facilita poner en práctica. Luego necesitas formarte en las herramientas, pero esto quiza si que puedas hacerlo por ti mismo. Quien me lea pensará, vaya ¿en la herramientas si me puede formar yo mismo (ojo que no lo recomiendo) y en las técnicas no?. El razonamiento es facil: las técnicas estaban ahí antes de TS y TFS, sino las ponias en práctica es porque no las conocias y no concias su valor. Incluso las herramientas ya existian, no tan integradas y potentes como en TFS, pero plenamente usables: NUnit (testeo unitario), NAnt (construcción automática), miles de gestores de fuentes y gestores de bugs gratuitos etc… Si no usabas ya esas herramientas no vas a comprender su importancia y las mejoras que se derivan simplemente por instalar TFS y TS, por lo tanto probablemente hagas un uso precario de lo que TFS y TS ofrece.
La resistencia a aceptar los 'mindsets' y los principios de las metodologías es algo a lo que me enfrento habitualmente. Se suele hacer patente cuanto se intenta que TFS 'sirva para hacer partes de horas'. Olvidense, las metodologías que vienen con TFS no miden nada en función de las horas trabajadas, sino en función de las características que incluye un build y su calidad. Si no eres capaz de entender esto, mejor olvidate de las metodologías de TS y sigue usando la metodología ASM (A Salto de Mata by Miguel Egea). Muchas empresas cuando usan TFS y TS, elijen una metodología porque no queda más remedio, pero no asumen los 'mindset' y los principios, no cambian sus ideas acerca del desarrollo de software. Pocas mejoras surgen de seguir haciendo lo mismo con diferentes herramientas. Las mejoras metodológicas solo surgen del convencimiento de la necesidad de hacer las cosas de otra manera, basandonos en diferentes principios. Y eso no se logra simplemente con iniciar un proyecto en Team System, es necesario un proceso paralelo de 'mentoring', por el cual, alguien que realmente conozca esos principios y lleve tiempo poniendolos en práctica, los transmita a nuestro equipo de desarrollo. Una cosa es elegir una plantilla metodológica y otra asumir que todas nuestras acciones deben ir encaminadas a trabajar siguiendo una visión común, a crear un equipo con el cliente, a logra un equipo de iguales, a ser agiles y estar preparados para el cambio (incluso en MSF CMMI!!! para sorpresa de muchos), por poner algunos ejemplos…
Mi recomendación (no digo que no sea arrimar el ascua a mi sardina): si te planteas usar TFS, contrata a alguien que sepa de Gestión de Proyectos, que lleve tiempo usando técnicas como construcciones frecuentes, testeo unitario, gestión de bugs etc… y haciendo las cosas de acuerdo a los principios que son la base de las metodologías que se incluyen con TFS. Y aun más importante, asume que tendrás que cambiar la manera en la que haces las cosas, las cosas no cambian haciendo lo mismo.
