Mi resumen de antecedentes: TFS Architect/Admin desde 2005 hasta la actualidad. Muchas organizaciones de desarrollo grandes y pequeñas de 20 a 7,000. Sector público y privado. Cumplimiento con HIPAA, FDA y SOX. ALM, SCM, RM.
Las respuestas actualmente proporcionadas intentan responder a la pregunta desde una perspectiva a nivel de proyecto, que es típica, en lugar de desde una perspectiva de organización y mantenimiento. Y también aliarse con uno u otro campo, lo cual debe evitarse.
La respuesta a su pregunta depende de su situación. ¿Qué tipo de consultas o informes se necesitan o quisieran ver en el proyecto? Y para reiterar cuál es la mejor respuesta: la herramienta no debe dictar scrum y, para estar de acuerdo con eso, ¿el proyecto debe ser algo flexible?
Un alejamiento de los escenarios del mundo real que he experimentado con varios clientes, es que generalmente comienzan con la plantilla básica de Microsoft Visual Studio Scrum 1.0 y luego le agregan cosas. es decir: consultas, informes, elementos de trabajo, paneles, etc. Lo que inevitablemente los lleva de vuelta a la plantilla Agile o CMMI con los informes/consultas/elementos de trabajo que se están agregando. Lo he visto varias veces, independientemente del tamaño de la organización.
No importaría si el dios del scrum descendiera y creara la plantilla de scrum para TFS. Una pregunta más importante es '¿Qué soporte tiene tu proceso? cuán disciplinado es el personal para seguir el proceso; y pueden ellos estar de acuerdo con la semántica? Si es una verdadera molestia que los nombres no coincidan, los tipos/nombres de los elementos de trabajo se pueden cambiar/agregar/eliminar, sigue siendo el proceso que lo maneja todo lo que importa.
Un aspecto realmente importante de las plantillas, desde una perspectiva pura de TFS, es que los elementos de trabajo scrum 1.0 pueden agregarse a los elementos de trabajo ágiles 5.0 más fácilmente que al revés. ¿Por qué? Los campos y los puntos de entrada de datos ya existen en ágil donde no están en scrum. Lo cual, a su vez, reduce la cantidad de tiempo para descubrir qué campos existen en el sistema para reutilizar sin causar conflictos.
Sin sonar falaces, y no lo intento, es similar a afirmar que usar Microsoft Word es confundir a las personas porque hay demasiadas características/funciones. La mayoría de las personas ignoran estas características/funciones hasta que hay curiosidad o necesidad de usarlas. De lo contrario, las empresas no deberían tener el gasto adicional de pagar licencias de Microsoft Word y simplemente usar WordPad. La curiosidad y la necesidad es lo que promueve la comprensión y el conocimiento.
Cualquiera que sea la respuesta, no debe permitir que una herramienta dicte la forma de implementar Scrum (que es también la razón por la cual los equipos de Scrum deberían comenzar con herramientas simples como tarjetas y excel y aprender primero cómo usar el framework Scrum, no las herramientas). La herramienta no es lo que hará que su implementación de Scrum sea exitosa y si está contento con Trac, quédese con ella. –