template - tfs agile
¿Diferencia entre VS2010 Scrum v1.0 vs MSF para el desarrollo de software Agile v5.0 o este último es el superconjunto? (5)
¡No estas solo! Hemos utilizado ambos, empezando por error con la plantilla Agile 5.0 de MSF. Si está utilizando Scrum específicamente, yo usaría la plantilla Scrum 1.0. La plantilla Scrum 1.0 fue creada con Ken Schwaber, uno de los fundadores de Scrum.
La plantilla MSF Agile 5.0 contiene libros de trabajo que permiten un gran control sobre los datos de informes con excel. Pero, hay muchas más desventajas. No tiene un informe de quema de liberación. Para producir un sprint utilizable, necesita registrar datos reales en sus tareas. La cartera de productos es difícil de mantener arreglado. La historia del usuario es el único elemento de la cartera de pedidos, por lo que el seguimiento de los picos de ingeniería o los requisitos no funcionales es incómodo.
El Sprint 1.0 utiliza un tipo de elemento de trabajo "Sprint" que hace que la velocidad y las quemaduras sean un chasquido.
Entonces, en cuanto a las herramientas, es bastante bueno.
¿Qué tan significativas son las diferencias entre las plantillas de proceso de Visual Studio Scrum 1.0 y MSF for Agile Software Development v5.0?
¿Alguien ha usado uno sobre el otro?
Actualmente estamos usando herramientas externas ( TRAC ) para implementar Scrum en nuestro proceso de desarrollo, ya que MS creó una guía de proceso adicional en TFS2010, ¡estas dos cosas me confunden en lo esencial!
Inseguro, cuál adoptar!
Esta página de MSDN podría ser útil: elija una plantilla de proceso .
Hace un trabajo decente al resaltar las diferencias entre las siguientes 3 plantillas de proceso predeterminadas.
- Scrum Process Template para Visual Studio ALM
- MSF para el desarrollo de software ágil v6.0
- MSF para la mejora del proceso CMMI v6.0
Tenga en cuenta que está dirigido a la suite de herramientas Visual Studio 2012.
La plantilla SCRUM sigue algunos de los términos y artefactos de SCRUM. Tiene sprints en lugar de iteraciones, tiene historias de usuario en lugar de requisitos, tareas, gráficos de quemado, etc. Pero, en mi opinión, TFS es difícil de usar porque no es muy productivo.
Estamos utilizando una plantilla similar no MS para Visual Studio TFS 2008. Durante mi primer proyecto SCRUM, usamos directamente TFS y Excel para recopilar historias de usuarios, preparar tareas, etc. Fue extremadamente lento. La creación de tareas para 4-5 desarrolladores y 4 semanas de sprint (nunca volveré a utilizar un sprint tan largo) me llevó dos días aproximadamente. Un desperdicio. Por otra parte, no se construyó soporte para imprimir tarjetas para el panel de tareas. Otra desventaja de la plantilla que no es MS (no estoy seguro si esto es lo mismo para MS one) es que cada error reportado se agrega inmediatamente a la cartera de productos (es una nueva historia de usuario), no hay forma de recopilar restricciones, las historias de usuario no lo hacen. tiene un campo predefinido para los criterios de aceptación y las tareas no tienen un campo para el tiempo real empleado en la finalización de la tarea (bueno para retrospectiva de estimaciones). Probablemente se pueden agregar campos si tiene TFS bajo su control, pero no es mi caso.
Todavía tengo que usar TFS (política de la empresa) pero trabajo con historias de usuarios y tareas lo más posible fuera de TFS: el lápiz y el papel funcionan mejor. Aún así, TFS es bueno para rastrear el progreso del sprint y los gráficos de quema generados automáticamente, pero tiene que encontrar un buen equilibrio entre la cantidad de tareas, la complejidad de las tareas y la longitud del sprint.
La plantilla de Visual Studio Scrum 1.0 se construyó desde cero para ser compatible con Scrum, utilizando la terminología de Scrum tanto como sea posible. Se está desarrollando en coordinación con Scrum.org y el programa Scrum Professional Developer. Si está utilizando Scrum, la plantilla VSS 1.0 le ofrecerá menos fricción que la plantilla Agile.
Dicho esto, debe ser comprensivo y cuestionar si la adopción de TFS y la plantilla VSS 1.0 podría proporcionarle un mejor valor que el uso de la herramienta actual que está utilizando ahora. Las preguntas que debe hacer aquí son: ¿se beneficiará con la integración de los elementos de la cartera de productos, las tareas de Sprint, los controles de código, las compilaciones de CI, las pruebas manuales, las pruebas codificadas, los resultados de las pruebas unitarias, etc.
Quizás algunos de los informes estándar le permiten obtener una mejor perspectiva de la Calidad del Incremento del Producto. Por ejemplo, ¿has terminado? Pruebas unitarias y reportes de cobertura de código, informes de pruebas, informes de compilación. ¿Ayudan estos a responder mejor esa pregunta?
Quizás nada de esto sea aplicable y usar su solución actual es la mejor manera de mejorar para su equipo. Depende de ti experimentar y decidir.
(O puede contratarme y con gusto lo ayudaré a decidir después de haber trabajado en el equipo y averiguar qué problemas podrían mejorar su equipo ;-)
Mi resumen de antecedentes: TFS Architect / Admin desde 2005 hasta el presente. Muchas organizaciones de desarrollo grandes y pequeñas de 20 a 7,000. Sector público y privado. Cumplimiento de HIPAA, FDA, SOX. ALM, SCM, RM.
Las respuestas proporcionadas actualmente intentan responder la pregunta desde una perspectiva a nivel de proyecto, lo cual es típico, más que desde una perspectiva de organización y mantenimiento. Y también al lado de un campamento u otro, lo que debe evitarse.
La respuesta a tu pregunta depende de tu situación. ¿Qué tipo de consultas o informes se necesitan o les gustaría ver en el proyecto? Y para reiterar cuál es la respuesta principal: la herramienta no debe dictar el scrum y, en concordancia con eso, ¿debe el proyecto ser algo flexible?
Una alternativa a los escenarios del mundo real que he experimentado con varios clientes, es que generalmente comienzan con la plantilla básica Microsoft Visual Studio Scrum 1.0 y luego le agregan cosas. es decir: consultas, informes, elementos de trabajo, paneles de control, etc. Lo que inevitablemente los lleva de vuelta a la plantilla Agile o CMMI con los informes / consultas / elementos de trabajo de quemado que se agregan. He visto esto varias veces sin importar el tamaño de la organización.
No importaría si el dios del scrum bajó y creó la plantilla de scrum para TFS. Una pregunta más importante es ''¿Qué es lo que apoya su proceso; cuán disciplinado es el personal para seguir el proceso; ¿Y pueden ponerse de acuerdo sobre la semántica? Si es realmente molesto que los nombres no coincidan, los tipos / nombres de los elementos de trabajo se pueden cambiar / agregar / eliminar, sigue siendo el proceso el que conduce todo lo que importa.
Un aspecto realmente importante de las plantillas, desde un punto de vista puro 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 lo hacen en scrum. Lo que a su vez reduce la cantidad de tiempo que determina qué campos existen en el sistema para reutilizarlos sin causar conflictos.
Sin sonar engañosos, y tampoco lo estoy intentando, es similar a afirmar que usar Microsoft Word es confundir a la gente porque hay demasiadas características / funciones. La mayoría de las personas ignoran estas características / funciones hasta que haya curiosidad o necesidad de usarlas. De lo contrario, las empresas no deberían tener el gasto adicional de pagar por las licencias de Microsoft Word y simplemente usar WordPad. La curiosidad y la necesidad es lo que promueve la comprensión y el conocimiento.