Pregunta

Actualmente estamos utilizando Visual Source Safe y bugnet y mirando a migrar hacia arriba y lejos de VSS. He estado presionando para que sea SVN (a) somos una tienda de ASP.NET, b) DCVS no es una opción - no importa cuánto me gusta ;-) Hg o TFS. Así finalmente conseguimos un nuevo servidor dev, así que hablé el jefe en la instalación de TFS en él (prueba de 30 días). Mientras tanto, habíamos comenzado a experimentar con FogBugz. Nos gusta mucho FogBugz alrededor del 80% de lo que queremos hacer, y el otro 20% es probablemente cosas que no sabemos lo que queremos.

Estoy empujando para TFS, ya que permite IDE integrado todo (en su mayoría).

Está presionando para FogBugz porque puede agrupar tareas por cliente y luego proyectar y gestionar todo, desde un tablero de instrumentos. (Lo que significa que pierden la mayor parte de mi integración IDE - sin gran pérdida estoy de acuerdo)

¿El TFS admite un único panel de control que abarcaría todas nuestras soluciones (en este caso cada solución es una aplicación completa que vendemos a un cliente de mercado vertical) y nos dejó workitems asignar a cada grupo una solución que abarca?

Así, por ejemplo, creo que nos imaginamos algo como esto:

PROJECT1 - Bugtracker y elementos de trabajo Project2 - Bugtracker y elementos de trabajo Proyecto3 - Bugtracker y elementos de trabajo

Customer1 - programaciones de distribución, las características requeridas, notas específicas (Usos PROJECT1, project2) Customer2 - programaciones de distribución, las características requeridas, notas específicas (Usos project2, proyecto 3) CUSTOMER3 - programaciones de distribución, las características requeridas, notas específicas (Usos PROJECT1, proyecto3)

Con suerte que tiene sentido. naturalmente, es más complicado que esto, pero creo que he dado los detalles suficientes para pintar un cuadro.

Me ofrecieron la opción de crear proyectos ficticios por cliente pero no lo hace así y no nos da realmente el punto de vista único panel de control que estamos con la esperanza de terminar con (y que FogBugz como hemos sorta cosas implmented Qué hace ahora).

¿Alguien tiene una buena sugerencia en una aplicación de gestión que lograría lo que ambos queremos?

EDIT: desde que tengo algunas buenas respuestas (aunque no lo que quería) Voy a cerrar esta por ahora. Sin embargo, creo que esto es algo que sería una buena thirdparty mercado y / o de una pieza en un comunicado de TF próxima. Siéntase libre de publicar con más ideas si se encuentra con esto más adelante.

¿Fue útil?

Solución

TFS le permite tener múltiples proyectos de equipo. Cada uno es efectivamente una carpeta raíz para control de código fuente. Sin embargo, puede mover los archivos / carpetas entre los proyectos de control de código fuente, y los elementos de trabajo son globales (compartido en todos los proyectos de equipo). Elementos de trabajo para todos los proyectos de hacer es proporcionar un nivel en el que puede filtrar los elementos de trabajo (por lo que nos fijamos en los errores sólo para este proyecto, etc.).

lo que los proyectos del equipo le permiten compartimentar muy bien sus proyectos, pero son sólo compartimentos virtuales, con pocas limitaciones en mover elementos entre los compartimentos.

El único problema que he encontrado con varios proyectos de equipo es que usted tiene que diversificarse una carpeta (y no se puede bifurcar un proyecto de equipo) por lo que si usted desea hacer una rama que se extiende por varios proyectos que tienen que tienen varias ramas, que medios asignaciones de espacio de trabajo severwal y varios fusiona para cada operación.

Para los clientes que se limitaba a añadir un campo personalizado "cliente" a nuestros elementos de trabajo que nos permitió relacionar un elemento de trabajo a un cliente spacific.

Cuando nos fijamos en los elementos de trabajo que puede entonces aplicar SQL-como la filtración (por ejemplo TeamProject = @ proyecto y del cliente = "BiggsAndCo" Y WorkItemType = "Bug" sería encontrar todos los errores reportados por BiggsAndCo en el TeamProject actual)

Hay un montón de terceros add-ins para VSTS para mejorar la experiencia de TFS (por suerte, como TFS cruda proporciona la interfaz de usuario muy básico y torpe), y se puede utilizar la API para escribir sus propias herramientas para consultar la base de datos de TFS también, lo que no debería tener demasiado de un problema para conseguir un tablero de instrumentos, que le resultan útiles. Tendrá que hacer algunas búsquedas para ver si las soluciones por ahí, aunque cumplen con sus criterios.

Otros consejos

Una forma de hacer esto es sería tener un solo proyecto de equipo que cubre todas sus soluciones y uso subcarpetas de control de origen y artículos caminos en sus elementos de trabajo para separar los requisitos de características, insectos, y así sucesivamente por el proyecto.

Es la información específica del cliente a través de un subconjunto de proyectos que es probable que tengas que hacer algún tipo de personalización con el fin de informar sobre ya que tiene una relación de muchos a muchos que los elementos de trabajo TFS no son compatibles fuera de la caja .

Espero que ayude

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top