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.
Muy importantes tus comentarios, las empresas si no se concientizan de lo importante que es el aplicar una correcta gestión de proyectos y de procesos creo que no van a poder explotar al máximo las capacidades que TFS, si bien es cierto no se logrará un cambio de la noche a la mañana, es un proceso que ya debe empezarse ahora, actualmente existen muchas empresas que ni siquiera conocen a fondo sus procesos y menos la forma de trabajo que hay en cada uno de sus proyectos dentro de la misma, te comento que acá en perú muchas empresas han emprendido el camino hacia la certificación CMMI y eso se aplaude ya que sigifica que se está tomando conciencia de lo importante que es el implantar sus áreas de proceso correctamente y del valor agregado que le da a la empresa el uso de métricas y herramientas que ayuden a conocerse a si mismas :).
Un saludo desde perú.
Ivan Mostacero.
Buenas Rodrigooo! Totalmente de acuerdo contigo, llevo un año formando en TS con TFS y me llevo la misma impresion siempre. Las herramientas de TS Suite estan bien, pero no sirven de nada si no aceptas los principios que han derivado en esto… y eso solo lo puedes conseguir si alguien te evangeliza lo suficiente como para hacerte verlo.
Ahora, no estoy de acuerdo con que las herramientas de Team System son mas potentes que las open source… llevo casi 4 años currando con agile, unit testing, refactoring, etc… y te puedo asegurar y aseguro que unit testing de team system no llega aun a la version 2.0 de lo que es NUnit; refactoring de Team System es una full comparado con Resharper; Team Build es un mero compilador al lado de Cruise Control; y por ultimo, MSBuild no puede competir con NAnt a estas alturas y tal y como se entrega con Team System, a menos que te bajes las Task Libraries.
Eso si, es de Microsoft y tiene lo que siempre aporta (tarde) Microsoft: Integración con tus herramientas. Y si ahroa todo el mundo esta descubriendo esto es porque esta en Team System, y como tu decias: las herramientas son muy viejas, si no las has descubierto hasta ahroa es que no te interesaba ni sabias que aportaban.
Sin rencor 😉
Aupa Miguel!!!
Yo no hecho en falta nada de lo hago con NUnit (de hecho migré los test sin más), quizas si falta algo similar a NMock. En lo de Resharper totalmente de acuerdo. A mi me gusta más MSBuild que NAnt, y es bastante más estable y menos ‘tricky’.
El tema de la integración es clave. El programador medio descubre las cosas a base de clicks en menus, no ha base de leer how-to’s. Además esa integración hace posibles los excelentes informes de TS, y eso es algo que estarás de acuerdo conmigo no consigues a base de NUnit + NAnt + CC.net. Además de que el esfuerzo para establecer un entorno básico con testeo unitario, integración y construcción frecuente y construcción automatizadas es mucho menor con TS y eso es vital para que estas técnicas lleguen al gran público. Microsoft una vez más no ha inventado nada, pero creo que va a ser otra vez quien lo popularize.
Pero vamos la esencia es enterder el porque de esas prácticas, que problemas solucionan y que nos aportan, luego la heramienta es lo de menos.
Me ha gustado todo el artículo pero en especial me gustaría saber de donde has sacado la metodología ASM (A Salto de Mataby Miguel Egea). Porque esa esa debe de ser la metodología más extendida del mundo. Debrían dar certificaciones oficiales con cuadros que lo expecifiquen para colgarlas en las entradas de las empresas para que los clientes sepan donde se meten.
Saludos.
La metología ASM (A Salto de Mata) se la escuche por primera vez Miguel Egea, MVP de SQL Server, comentando como era la única que podía aplicar en sus tiempos de Jefe de Proyecto, absorvido por la boragine de gestionar proyectos. La verdad es que es un tio muy gracioso jejejeje…
Pues bueno, me he ‘adueñado de la frase’, pero siempre le cito a el gran Miguel como autor eh!!!!
Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además
Hola, acabo de graduarme de mi universidad y me acaban de contratar en un empresa para hacer funciones de ingeniera de calidad… La empresa actualmente utiliza TFS pero solo para mantener copias de seguridad y otras pocas cosas… hoy estuve leyendo todos tus post y me doy cuenta que hay muchas cosas que se estan desaprovechando y en eso consiste mi trabajo en mejorar todo eso. No soy experta como te comente antes estoy recien graduada pero estoy poniendo todo mi empeño.. gracias por todas las explicaciones … es bueno saber que no te guardas todos tus conocimientos para ti mismo sino que nos ayudas a los demas..