Áreas TFS, definición óptima y configuración

Question

Al haber migrado recientemente a TFS 2010, me preguntaba cuál es la definición o configuración mejor o más ampliamente aceptada para un Área.

El único artículo útil que puedo encontrar en línea es this one y es lo que habría supuesto correcto. Sin embargo, me hizo pensar si alguno de los siguientes es de hecho más ampliamente aceptado.

• Áreas de funcionalidad de negocio
• áreas de la tecnología
• Áreas de capa del sistema
• zonas de ubicación física o geográfica

Answer 1

Realmente depende del producto/proyecto que está construyendo, supongo que estaba disponible como un marcador de posición de uso general que puede obtener su significado del equipo & la misión del equipo.
Puedo imaginar proyectos, donde ignorarlo en el total general, también sería una solución perfectamente aceptable.

Nuestra estructura inicial de TeamProject hizo caso omiso de las áreas para nuestro producto estrella que construimos en una Colección de equipo. Esto resultó en una pesadilla de informes, ya que la necesitábamos a nivel de plataforma (TeamCollection), en lugar de una parte distinta de ella (Team Project). Cuando nos dimos cuenta del problema, fuimos a buscar & encontramos el artículo this, que nos hizo cambiar de rumbo: ahora estamos utilizando áreas TFS dentro de un solo proyecto de equipo &, encontramos lo que mejor se ajustaba a nuestra situación.
En nuestro universo Área = una línea de lanzamiento distinta dentro de la plataforma.

Answer 2

Áreas en mi opinión es un mecanismo de agrupación, con Áreas puede agrupar sus wortitems en el tipo que desee.

Creo que todo lo que se ajuste a su proceso de desarrollo o lo haga más productivo está bien.

Todos sus artículos en la lista son tipos válidos de áreas, los vi todos en proyectos.

Pero las jerarquías demasiado profundas no son realmente útiles, porque si crea un elemento de trabajo que tiene que elegir/seleccionar el área correcta.