Mes: septiembre 2011

Una de las novedades de Team Foundation Server 11, tanto la versión Azure como la On-premise, son los dashboards, al estilo de paneles Scrum, que nos permiten hacer una gestión visual de nuestro Product Backlog y nuestros sprints. Pero, sois ya más de uno los que nos habéis preguntado dónde están estos Dashboards, ya que por defecto no aparecen, así que os vamos a explicar como empezar a usarlos.

Una vez que tenemos nuestro primer proyecto creado en TFS 11, tendremos que hacer varias cosas, en la pantalla inicial del proyecto (siempre hablando del acceso web: http://[ServidorTFS]:8080/tfs/) Si no tenemos ningún equipo creado, no aparecerán los equipos, con lo que pulsaremos en el enlace Manage teams and project groups.

En esta sección  se nos permite crear lo que necesitamos: un equipo (o varios), que no es lo mismo que un grupo de permisos de Team Foundation Server, si no que es un equipo de trabajo. Para crear uno y agregar miembros, pulsamos en la flecha al lado de actions, y creamos un equipo.

Una vez creado y asignados miembros al equipo, podemos volver al inicio, pulsando en Exit administration, arriba a la derecha, ahora ya en el inicio nos aparece nuestro equipo, y si pasamos el cursor por encima de el, veremos las opciones que tenemos.

Veremos que ya nos salen los boards, pero antes de usar los boards tenemos que hacer dos cosas:

1. Entrar a los settings y asignarles una iteración, los Dashboards nos muestran el trabajo de una iteración, con lo cual tenemos que asignar una iteración al equipo.
2. Crear  Work Items en el product backlog del equipo, esto lo podemos hacer simplemente creando Wortk Items (de historias de usuario y sus tareas asociadas), y asignándolos a la iteración del equipo.

Una vez que hayamos hecho estas dos cosas, ya podemos ir a los dashboards del equipo, y empezar a trabajar, creando nuevas historias, tareas asociadas y mover tareas entre los distintos estados mediante drag & drop.

Os iremos contando cosas más adelante acerca de como usar estos Dashboards, por ahora … os dejamos que los investigéis.

Una de las primeras cosas que hago en los despliegues de Team Foundation Server, es configurar Team Build para tener integración contínua en los proyectos, si  soy un fanático de la integración contínua, y para eso necesito Team Build.

En este caso, lo estoy haciendo para Team Foundation Service ¿cuál es la diferencia? que en este caso nuestro Team Foundation está en la nube, que es TFS 11, y que toda la autenticación funciona a través de LiveID, no a través de directorio activo, ni cuentas workgroup.

Lo primero, instalar los bits de Team Build 11, esto lo hacemos desde la instalación de Team Foundation Server, pero no como una opción, al montar la ISO de Team Foundation Server 11, no nos da la opción de instalar sólo Team Build (como si courría en 2010), instalaremos Team Foundation server 11, y en la parte de configuración, se nos mostrará la opción de configurar únicamente Team Build 11.

 

Una vez instalado Team Foundation Server, se nos muestra la pantalla de opciones de configuración, aquí seleccionaremos únicamente configurar la parte de Team Build.

En el primer paso le diremos la Project Collection a la que queremos dar servicio, aquí y como ya recordaréis del anterior post es algo así: https://[loquequieras].tfspreview.com  y recordad: conexión SSL, para cnectarnos en este momento necesitaremos una cuenta LiveID con acceso a este servidor de Team Foundation Service Preview. En este punto se nos pedirá una cuenta de LiveID, para conectarnos al Team Foundation Service, y esta cuenta tiene que tener permisos suficientes para poder registrar el servidor de Team Build en Team Foundation Service Preview, ya que es la que se usará por Team Build para autenticarse

Al igual que en Team Foundation Server 2010 podemos seleccionar el número de agentes que queremos configurar, yo lo he dejado en 1 (por defecto) y a continuación nos pide una cuenta, ojo, esta es una cuenta local que vamos a usar para el servicio local de Team Build, con lo que nos quedaría algo así:

Aquí viene la magia, recordaréis que al principio os decía que en Team Foundation Service Preview, vamos a usar cuentas de LiveID, pero lógicamente una cuenta de LiveID no la podemos configurar como cuenta de ejecución de un servicio local de Windows, con lo que es la cuenta de LiveID que hemos usado para conectar, la que nos autentica, y esto lo podemos ver, si, con este mismo usario que estamos autenticados en nuestra máquina local, nos vamos al almacen de identidades en Windows (en nuestro caso Windows 7), y podemos ver lo siguiente:

Veis como en las creedenciales genéricas se nos ha generado una nueva entrada para poder conectar con nuestro Team Foundation Service Preview.

Añadir que al termino de escribir este artículo estoy viendo que Brian Harry ha publicado un artículo en que podéis ver todo esto explicado y con muchos más detalles acerca del tema de la autenticación y las cuentas, esto me pasa por no estar al día en mi Google Reader …

http://blogs.msdn.com/b/bharry/archive/2011/09/15/configuring-a-build-server-against-your-shiny-new-hosted-tfs-account.aspx

También deciros que esto lo podéis hacer igualmente sobre una máquina virtual en Azure

Seguro que ya casi todos habéis visto los vídeos del //Build/ y vais a empezar a probar TFS11 y VS11. 
Lo primero ¿donde descargar todo? Los que tenéis suscripción MSDN podéis descargar todo de ahí.

Pero, seguro que muchos, al igual que pasó con TFS 2010 habéis visto el TFS Basic y no lo encontráis en las descargas. 

Efectivamente no está, pero es que no es una descarga a parte, TFS tiene una descarga única para todos sus «sabores», es más, tiene un único proceso de instalación. 

Así que ni en las descargas ni en el inicio de la instalación busquéis la versión Basic.

Es durante el proceso de configuración, después de la instalación, donde podremos escoger el modo en que queremos usarlo.

El próximo miércoles los chicos de Madrid.NET organizamos una mesa redonda, a la que estáis invitados todos, el debate tratará sobre la implementación de Scrum y metodologías ágiles en general con Team Foundation Server.

Será el miércoles 21, a partir de las 19:00 en el Aula Vulcan, C/ Francisco Silvela, 54 Duplicado 1ºD 28028, Madrid

Recordad que será mesa redonda todos sois bienvenidos a participar y a exponer vuestras experiencias, resolver dudas, compartir trucos, sobre cualquier cosa como puede ser:

• Estrategias de branching
• Integración continua
• Planificación
• Gestión de PBIs en iteraciones
• …

Todos los detalles y el link de inscripción lo tenéis en:

http://madriddotnet.wordpress.com/2011/09/14/evento-tienes-dudas-sobre-scrum-con-tfs-21-de-septiembre-2011/

Como seguro que muchos de vosotros ya habéis visto, en el Build (grrrr envidia tengo de los que han ido), se ha enseñado ya el nuevo Team Foundation Service Preview, que viene a ser TFS en Azure.

Para los que hayáis tenido la suerte de tener una invitación (como yo jeje), os hago un pequeño resumen de por dónde empezar.

Lo primero es recordar, que aunque con algunas diferencias, viene a ser un Team Foundation Server como los que estamos acostumbrados a ver hasta ahora, en su versión 11 eso sí.

Una vez recibida la invitación y creada la cuenta (necesitaremos la invitación y un Live ID), tendremos una URL que será: http://[loquequeramos].tfspreview.com, esta url es la que vamos a usar para conectarnos a nuestro servicio en la nube, y empezar a trabajar, y la URL que usaremos para conectar a nuestro TFS Service Preview

Al terminar de crear la cuenta, entraremos automáticamente a esa url, en la sección administration

Desde esta pantalla, lo primero que vamos a hacer es crear un Team Project con el que empezaremos a trabajar, por cierto, me encanta la interfaz Metro, que vamos a ver a lo largo de toda la aplicación de Team Foundation Server Service. Para crear el proyecto simplemente pulsamos la opción Create team project.

Al igual que en un Team Foundation Server actual, nos preguntará el nombre de proyecto que queremos, la descripción, y la plantilla, que también son nuevas y podremos escoger entre:

• Microsoft Visual Studio Scrum 2.0 – Preview 1
• Microsoft MSF for Agile Software Development 6.0 – Preview 1
• Microsoft MSF for CMMI Process Improvement – Preview 1

Una vez creado el proyecto, ya podemos pasar a conectarnos con nuestro Visual Studio 2010 (o 11 si ya lo tenéis descargado )

Antes de conectarnos a nuestro proyecto, tenemos que tener en cuenta una cosa, con Team Fountadion Server Service Preview, vamos a usar cuentas de Live ID para conectarnos, algo para que lo que NO está preparado Visual Studio 2010, por lo que tenemos que descargarnos un software adicional.

Este software lo encontraremos en nuestra página de administración del servicio de Team Foundation Server Service Preview, para acceder, si ya habéis cerrado la web, entramos a http://[loquequeramos].tfspreview.com, y pulsamos en el link Administration arriba a la derecha.

En la tercera opción vemos el link para descargar el software que necesitamos, nada más sencillo que pulsar, y descargarlo, para Visual Studio 2010, necesitaremos el Service Pack 1 for Visual Studio 2010, y el hotfix  KB2581206.

Una vez descargado e instalado, abrimos nuestro Visual Studio 2010, el procedimiento de conexión es el de siempre (menú Team opción Connect to Team Foundation Server…).

Al agregar el servidorde TEam Foundation Server Service Preview a los disponibles, tenéis que poner [loquesea].tfspreview.com y OJO seleccionar conexión por SSL, con lo que la url resultante será: https://[loquesea].tfspreview.com/tfs

Al conectar ¿qué nos va a pedir? pues una cuenta con Live ID que tenga permisos en este proyecto de Team Foundation Server para empezar a trabajar.

Terminamos de conectar y veremos que tenemos una Team Project Collection, y el proyecto que habíamos creado disponibles en nuestro Team Explorer para empezar a jugar trabajar con Team Foundation Server Service Preview …

Una diferencia que podéis ver, y que es debido a ser un servicio en la nube (y sibre todo Preview) es que no tenemos ni Reporting ni Sharepoint, y sólo tenemos nuestros queridos Work Items, Source Control y Team Build ( ya os hablaré de este último más adelante).

Y como podéis ver, nuestro TFS está ahora en tfspreview.com

Y a partir de este punto, y si el tiempo y las condiciones lo permiten, espero iros haciendo itnroducciones a esta nueva pequeña maravilla que tenemos disponible.

Volvemos con artículos de lo que yo veo, vivo y experimento con metodologías ágiles. Y hoy le toca a los equipos multidisciplinares, algo sobre lo que hay mucho escrito, y con muchas y diferentes visiones.

Si nos atenemos al concepto general, y en el que muchos piensan, un equipo multidisciplinar es un equipo de generalistas, en el que todos saben hacer cualquier tipo de tarea necesaria para completar el sprint. Esto tiene una serie de beneficios, que son obvios:

• Evitamos cuellos de botella
• Facilitamos la comunicación del conocimiento de todo el proyecto en el equipo
• Tenemos múltiples puntos de vista sobre un mismo punto

Y más beneficios que podríamos seguir enumerando.

Sin embargo, también hay cosas que perdemos, como pueda ser conocimiento especializado para algún tema concreto.

A parte, es bastante difícil encontrar un buen equipo de personas generalistas en todas las tareas que nos puedan surgir en un sprint, recordad que nos encontraremos tareas que van desde realizar front-ends de las aplicaciones, bases de datos, despliegues de aplicaciones, etc etc.

Por esto, en mi punto de vista, para conseguir un equipo multidisciplinar me baso en otra aproximación. Para mi un equipo así es el equipo en el que tengo, trabajando como uno sólo, y que tiene todos los conocimientos necesarios para el sprint, esto no quiere decir que todo el mundo sepa hacer de todo.

Aquí nos aprovechamos del conocimiento especialista de alguno de los miembros del equipo, también sería iluso creer en un equipo de sólo especialistas. En un equipo de sólo especialistas tiemblo de pensar en las posibles luchas de egos, y las luchas de cada cual en su terreno.

No está mal tener un equipo compuesto por algunos especialistas en los temas que necesitemos, y gente más generalista. Siempre y cuando trabajan como uno sólo, colaboren entre ellos, y tengan todos claro el objetivo último del sprint. Edito: y que por supuesto, y en la mayor medida posible, todos tengan un conocimiento básico para cualquiera de las cosas que hay que hacer durante un sprint.

Y ojo, cuando hablo de especialistas no hablo de gente que sólo sabe hacer una cosa, las personas, cuanto más conozcamos, mejor, aunque luego tengamos una habilidad más concreta, como decía un amigo mío, la especialización es para las moscas, los humanos debemos saber hacer muchas cosas.

El conocimiento generalista es muy enriquecedor, y cuanto más variado en cuanto a temática, más enriquecedor, pero también lo es saber mucho acerca de algo y tener mucha experiencia en ello, que nos permita no sólo salvar situaciones conocidas, si no enfrentarnos con nuestras armas a problemas desconocidos.