En Notarnet llevamos utilizando aplicaciones para la gestión de código fuente desde hace muchos años. Inicialmente comenzamos con Microsoft SourceSafe. Posteriormente, y debido a las limitaciones de SourceSafe, pasamos a una solución tipo SVN (Subversion/Tortoise).

Notarnet tiene en su portfolio varias aplicaciones con ciclos de vida bastante largos, donde además gestionamos varias versiones mayores en el mercado. Y dando una vuelta de tuerca, ciertos clientes se ven obligados a mantener alguna versión anterior, y que bajo soporte extendido, nos comprometemos a seguir manteniendo. En definitiva llegamos a tener varias versiones «mayores» instaladas a las que hay que seguir manteniendo, corrigiendo bugs y añadiendo funcionalidades obligatorias.

Reconociendo que el escenario anterior es un poco extremo, no es difícil encontrar otras situaciones similares que obligan a cualquier empresa que desarrolla software a plantearse la gestión ALM como algo crítico y, por tanto, a buscar una herramienta que aporte no sólo control de código fuente.

Team Foundation Server 2010. Nuestro primer TFS.

Después de búsquedas y pruebas, decidimos implantar TFS como solución óptima que cumplía con nuestros requisitos. Como Partners de Microsoft, y gracias a la suscripción MSDN, parecía lo correcto. Y tengo que decir que el producto nos sorprendió gratamente:

• TFS no es sólo un sistema de control de código fuente para controlar versiones de código, branching, etc. Es muchísimo más y aportaba lo que realmente necesitábamos.
• Permite llevar ALM a la práctica y además usar prácticas «ágiles».
• Gestionar bugs, impedimentos, spikes, etc.
• Incrustar los Test en las Build y recibir reportes… ¡qué maravilla!
• Realizar análisis de cobertura de código. Se ha convertido en imprescindible en nuestro equipo.
• La integración con SharePoint para colaborar de forma ágil y potente fue otro de los motivos.

Pero, claro, también había inconvenientes y algunos no menores:

• El modo desconectado nunca ha terminado de funcionar bien. Es bastante «arriesgado».
• Las plantillas de procesos estaban bastante desalineadas con nuestra estrategia Scrum cuasi-pura.
• Pero probablemente, la infraestructura es el principal problema:
  • El despliegue es todo un reto para los administradores.
  • El dimensionamiento de los servidores implicados es otra de las pesadillas.
  • Incluir toda la arquitectura implicada en la política de backups corporativas.
  • Y un largo etcétera. Quien lo haya implantado sabe de lo que hablo con toda seguridad.

Aparece Team Foundation Server 2012

Llegados a este punto se lanzan las primeras versiones preview de TFS 11 (Server, no confundir con Service). Es evidente que nos disponíamos a ver si nos solucionaba los problemas descritos arriba. Efectivamente: las nuevas plantillas de Scrum nos venían como anillo al dedo,  los TaskBoard son simplemente alucinantes, la integración con Visual Studio 11 (el futuro VS 2012) era increíble, el Team Explorer nos encantaba, perooooo… ¿qué íbamos a hacer con toda la infraestructura creada para TFS 2010? Sólo pensarlo daba dolor de cabeza; y no os cuento al dpto IT.

Teníamos la alternativa de: (1) montar un laboratorio con TFS 2012, (2) planear la migración de forma que no pudiera fallar, (2) solventar los problemas que siempre aparecen en estas migraciones, y (3) finalmente realizar la migración cuando decidiéramos que todo lo teníamos controlado y (4) rezar porque en producción no tuviéramos problemas que nos retrasaran las agendas comprometidas. Todo esto por no hablar de los detalles «sin importancia» de decirle a los de IT que hay que actualizar el Active Directory, que necesitamos Windows 2k8 R2, que hay que actualizar SQL Sever, que el almacenamiento se nos queda pequeño, bla, bla, bla…

Pero es que además, dentro de ¿3-4 años? íbamos a tener que repetir el proceso con TFS ¿2015-2016?. Realmente la pereza aumentaba exponencialmente.

Esa pereza nos llevó a buscar una alternativa… ¡y la teníamos delante de las narices! Se llama Team Foundation Service. He de confesar que hasta esos momentos no le había prestado demasiada atención al servicio hospedado online de Team Foundation Service. ¡Craso error!

Empezamos con Team Foundation Service

En la compañía ya teníamos una cierta experiencia de otros productos/servicios hospedados y, por tanto, conocíamos las ventajas y los inconvenientes inherentes que esto tiene: un ejemplo es Office365 (un gran producto, por cierto). En realidad, lo que tienes disponible es un Team Foundation Server con prácticamente toda la funcionalidad a tu disposición, aunque «algo mermado».

Así que se empezaron a hacer pruebas de concepto, crear algunos proyectos de equipo y, de esta forma, analizar si realmente se ajustaba a nuestras necesidades. Y poco a poco nos fue convenciendo:

PRIMERA GRAN VENTAJA: ¡olvídate de la infraestructura! ¡olvídate de las actualizaciones! ¡olvídate de las caídas de servicio! ¡olvídate de los IT!

Es cierto que esto se debe únicamente a utilizar servicios en la nube, como cualquier otro, y no al producto persé. Pero el hecho de que TFS esté en la nube es una bendición ya que es nuestra herramienta de trabajo.

SEGUNDA GRAN VENTAJA: el portal de trabajo en la web es realmente espectacular. En la versión 2010, utilizar el portal web era un recurso de última hora más que una herramienta de verdad. Ahora es todo lo contrario: manejar el backlog, la planificación de los Sprints, el seguimiento del trabajo en tareas, la gestión de Bugs o Impedimentos, etc, es muchísimo más cómodo y rápido en la web que en el propio Visual Studio.

Esto para personas como yo con perfil de ex-PM, y ahora Product Owner y ScrumMaster, y siempre en movilidad es una necesidad imperiosa. Sólo queda dar la enhorabuena por esto.

TERCERA GRAN VENTAJA: el TaskBoard y el BacklogBoard.

• Planificar un PBI en un Sprint es seleccionarlo y arrastrarlo al CurrentSprint… y ¡listo!
• Priorizar un PBI es arrastrarlo verticalmente en la lista del CurrentSprint
• Aprobar un PBI es arrastrarlo a «Approved»
• Dar por finalizada una Task es arrastrarla a «Done»
• Estimar el esfuerzo de una Task es facilísimo
• Asignar una Task a algún miembro del equipo es inmediato

En fin… ¡francamente sorprendente! Interactividad y Visibilidad máximas. Cuando se lo muestras a la gente ¡alucina!

CUARTA GRAN VENTAJA: tienes gratis un TFS prácticamente completo a tu disposición, para equipos de hasta 5 usuarios. Y a eso le añades que es un beneficio de la suscripción Visual Studio Premiun/Ultimate/Test MSDN.

MY WORK: gran herramienta tanto a nivel de portal web como en el Team Explorer de Visual Studio. Este es un paso hacia adelante facilitando la información de las cuestiones pendientes a los miembros del equipo.

ROOMS: una de las últimas novedades en aparecer. La posibilidad de interactividad y seguimiento es muy potente. Todavía no la hemos explorado 100% pero creo que va a ser muy útil; estoy seguro que dará juego.

SOPORTE GIT: esto permitirá gestionar proyectos por ejemplo desde XCode. No está nada mal.

Hay otras muchísimas novedades que en el ecosistema Visual Studio/TFS: el nuevo Team Explorer con el control sobre los cambios pendientes, la solicitud revisión de código muy mejorada, la búsqueda de Work Items, y un larguísimo etcétera.

¿Qué le falta a TF Service?

No todo iban a ser parabienes. Es cierto que se ha hecho un producto amigable, versátil y con una potencia descomunal. También es necesario señalar que todavía no hemos explotado el 100% de la funcionalidad y que nos quedan por explorar muchas cuestiones que seguro nos serán útiles y de las cuales no quiero opinar por el momento. En cualquier caso sí que creo que le faltan algunos detalles importantes.

1. La autenticación. Tener que utilizar una cuenta Live (o similar) no es de recibo. Por ejemplo: no supe cómo explicar en la compañía porqué teníamos que crear una cuenta Live para nuestras cuentas de Office365 que son con las que accedemos a TFService.
2. No es posible renombrar un Team Project. Así que elígelo bien.
3. Llevamos ya demasiado tiempo viendo el asterisco en las secciones de Build y Test. Queda feo… 😉
4. Los gráficos de Burndown deberían evitar los días no laborables y los días definidos como no hábiles en la planificación.
5. Las plantillas de procesos (en nuestro caso Scrum 3.0) debería integrarse con Exchange Online. Sería una gran mejora: por ejemplo, si planificamos una Release de 3 meses, con 6 Sprints (duración 2 semanas), especificando las fechas evidentemente. Debería poder realizar las convocatorias de reunión de los miembros del equipo, o al menos facilitarlas, como las Sprint Meeting, las Review Meeting, etc. y llevar control sobre ellas.

En este punto podríamos pedir muchas mejoras, pero quizás estas sean las más interesantes; o al menos, las que se me han ido presentando.

Conclusiones

Esta sección del post es muy corta: Team Foundation Service es un gran producto. SIN PALIATIVOS.