Como es de esperarse a estas alturas, existe infinidad de blogs que enumeran las características que vienen con la nueva versión de Team Foundation Server.
Para no caer en la misma situación, la idea de este post es que nos enfoquemos solamente en algunas pocas de esas nuevas características a las que el nombre de “feature” le queda un poco chico, ya que implican un cambio más de fondo y que va un poco más allá de una simple “nueva funcionalidad”.
Project Collections
Las colecciones de proyectos brindan una capa adicional de indirección que permite el agrupamiento de proyectos según el criterio que a nosotros más nos convenga. Esta agrupación podría ser por tipo de arquitectura, por equipo o área de la empresa, o por ejemplo, separando proyectos de desarrollo de aquellos otros de consultoría.
Lo interesante de este agrupamiento es que no es solamente a nivel lógico, sino que también lo es a nivel físico. Esto permite lograr un mejor nivel de aislamiento entre proyectos, y ese aislamiento impacta en el aspecto de seguridad, ya que cada colección equivale a una nueva instancia de TFS en términos de sus versiones 2005/2008.
El lector atento dirá a esta altura “… pero ojo… acá la cosa se complica …”.
Y si, como en cualquier otro caso, nos encontraremos con ventajas y desventajas en la implementación de colecciones de proyectos. Vamos a enumerar las más importantes:
Ventajas:
- Aunque parezca obvio, no deja de ser una ventaja el hecho de poder seguir trabajando como en las versiones anteriores de TFS si no tenemos ganas de complicarnos la vida con estas colecciones, con la única salvedad de que nuestros proyectos estarán ahora dentro de una “Default Collection”.
- Como cada colección maneja su propia base de datos, tenemos muchas más opciones a la hora de escalar y manejar balanceo de carga.
- En grandes organizaciones (y no tanto), este nivel de aislamiento permite una administración de seguridad mucho más granular.
- Tenemos la posibilidad de hacer respaldo/restauración de grupos de proyectos de manera independiente.
Desventajas:
- Lo que para algunos pueda ser una ventaja, es lo contrario para otros, ya que se podrá argumentar que ante una gran cantidad de colecciones se complicará seguramente la tarea del administrador al momento de configurar permisos de acceso a cada uno de los proyectos.
- A raíz de que cada colección usa su propia base de datos, nos encontraremos con una tarea más ardua al momento de administrar copias de resguardo de toda esa información adicional.
En el blog de Steve Lange podrán encontrar un diagrama de flujo muy interesante que les ayudará a decidir si necesitan o no manejar Project Collections.
Nuevos templates de Proyectos
Al momento de crear un nuevo proyecto en TFS en la versión 2010, nos encontraremos con un par de nuevos templates, entre ellos la versión 5.0 de MSF for Agile (aquí podrán encontrar una comparativa con la versión anterior).
No quisiera centrarme en describir el proceso que intenta implementar, sino en la funcionalidad que aportan sus nuevos tipos de Work Item, Workflows y por sobre todo, las nuevas relaciones que se pueden establecer entre ellos.
Cabe recordar que TFS 2010 permite establecer jerarquías de work items y además crear relaciones mucho más ricas que una simple dependencia de ida y vuelta entre uno y otro. Valiéndose de esto último, el nuevo template permitirá documentar por ejemplo “Historias de Usuario” y “Casos de Test” vinculados por una relación de tipo “Testea a …” o “Testeado por …” entre otras.
Este es, indudablemente, un modelo mucho más rico que el anterior, ya que permite ser explotado por queries mucho más intuitivas, muchas de las cuales ya vienen incluidas en el propio template.
Podríamos consultar, por ejemplo, Historias de Usuario que no cuentan con casos de test asociados para tener rápidamente un acceso a partes de nuestra aplicación que no tienen las pruebas mínimas necesarias.
Dashboards
Gracias a su integración con las últimas versiones de Sharepoint, los portales de proyectos creados con TFS 2010 mejoran su capacidad de reporting incluyendo Dashboards.
La idea de un Dashboard (o tablero de control) es contar con una consola que incluya diferentes indicadores que muestren rápidamente la situación actual del proyecto en un único lugar pero a un nivel más “macro” y que, además, permita a las áreas gerenciales determinar que tan en línea está un determinado proyecto con las políticas de su negocio.
Los Sharepoint Dashboard son la materialización de lo que se conoce como Balance Scorecards, es decir, sistemas de gestión y planificación estratégica que intentan alinear las actividades diarias del desarrollo con la visión de la empresa.
Obviamente estos Dashboards son altamente personalizables, pero de manera inmediata podremos contar con la siguiente información:
- Reporte de Task Burndown
- Lista de cantidades de Work Items en sus diferentes posibles estados (Activos, Cerrados, Resolved, etc.)
- Lista de fechas importantes
- Lista de los últimos Builds
- Lista de los últimos checkins realizados y sus comentarios
- Vista rápida del Product backlog donde se ve el estados de sus items
Cada uno de estos indicadores no es más que un wepbart embebido en el portal Sharepoint, por lo que contando con MOSS podremos personalizarlos y/o extenderlos de una manera muy flexible.
Hasta la próxima.