velocidad usuario tutorial team proyecto metodologia historias español ejemplo tfs tfs2012 scrum backlog sprint

tfs - usuario - velocidad agile



TFS y Scrum: configuración de mejores prácticas para áreas, iteraciones, iteración de pedidos pendientes, iteración de sprint (2)

Espero que hayas encontrado uso de mi publicación, y también te recomendaría que eches un vistazo a One Team Project para gobernarlos a todos y TFS vNext: configuración de tu proyecto para tener un backlog maestro y sub-equipos .

Aquí está mi mejor esfuerzo para responder a sus preguntas:

Pregunta 1) Pensamos que debido a que nuestros equipos no son tan grandes y para que la administración sea más manejable, no queríamos definir equipos por producto, ya que físicamente tenemos equipos por cliente y supervisan todos los productos para ese cliente. ¿Es esto un error, o está bien?

Esto está bien y te permitirá crecer como lo hacen tus equipos. Si los miembros de su equipo trabajan con múltiples Clientes, es posible que tenga problemas de priorización y cambio de contexto que puede minimizar al elevar el nivel de su equipo, o tener un único backlog unificado y sub equipos separados, pero aún centrándose en el trabajo del cliente y no en el trabajo del producto. De hecho, recomendaría este enfoque para el diseño que tiene.

Pregunta 2) Suponiendo que la configuración del equipo anterior sea correcta, ¿es correcto corregir el "mapa" de cada una de las áreas anteriores a cada equipo? Es decir, para el equipo "Cliente A Equipo" especifique el área "Cliente A" (y todas las subáreas) como Las áreas a ser propiedad de ese equipo. ¿Qué pasa con el área predeterminada, está bien establecer la raíz del área "Cliente A" como la predeterminada para el equipo?

Eso es correcto y debería dar como resultado que todos sus elementos de trabajo se creen cuando ese equipo se selecciona con esos valores predeterminados. Muchas organizaciones también crean un registro principal o maestro en el que se crean, ordenan y dividen elementos misceláneos en el trabajo atrasado del equipo apropiado como Greg Boer, propietario del producto del blog de herramientas de planificación ágil de TFS en su publicación TFS vNext: Configuración de su proyecto para tener un atraso maestro y sub-equipos .

El diseño de las iteraciones se ve bien, siempre y cuando sus Equipos no crucen el límite entre los clientes o comenzarán a relacionar las Áreas e Iteraciones de los Equipos con dificultad. Si cree que puede necesitar que un solo Equipo o grupo de equipos se asignen a más de un cliente, entonces puede que necesite algo más como:

-> Team Project (Iteration root) |—> Team Boundary (This could be one or more teams) |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) |---> Product A | |---> Release 1 | |---> Release 2 | |---> Release 3 | |---> Product B | |---> Release 1 | |---> Release 2 | | (ETC) |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B) |---> Product C | |---> Release 1 | |---> Release 2 | | (ETC)

Si bien todavía no es dinámico, esto permitiría ese escenario. Sin embargo, aún conservaría mi estructura de control de origen $ / TeamProject / Client A / ProductA y no filtraría esto. Es simplemente una compartimentación del proceso de planificación y no debe necesariamente extenderse a las otras partes de su Solución ALM.

Pregunta 3) Esto parece ser más complicado para hacer las iteraciones correctas, especialmente cuando se trata de TFS que muestra la acumulación. Específicamente, para la configuración de TFS Scrum 2 Iteration, parece que debería seleccionar (casilla de verificación) solo las iteraciones de nivel de hoja que son para la planificación y el desarrollo posterior. Entonces, extendiendo el ejemplo anterior, podríamos tener que el "Equipo del Cliente A" estará disponible para comenzar a trabajar en un nuevo Producto B durante las próximas 4 semanas (supongamos que son 2 semanas de sprints). ¿Entonces solo seleccionaríamos (casilla de verificación) "Sprint 1" y "Sprint 2" del lanzamiento 1? ¿Lo estoy entendiendo / utilizando correctamente?

Lo estás, pero realmente estás mirando 3 Sprints para tener un backlog ejecutable como parte del proceso Scrum. Recomendaría que numeren secuencialmente sus sprints consecutivos para que en la interfaz de usuario no se confunda con Sprint 2 cuando también marque Sprint 4 si se llama Sprint 1. También es bueno mantener un conteo del nivel de experiencia del equipo actual. .

-> Team Project (Iteration root) |—> Team Boundary (This could be one or more teams) |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) |---> Product A | |---> Release 1 | | |---> Sprint 1 | | |---> Sprint 2 | | |---> Sprint 3 | |---> Release 2 | | |---> Sprint 4 | | |---> Sprint 5 | | |---> Sprint 6 | |---> Release 3 | | |---> Sprint 7 | | |---> Sprint 8 | | |---> Sprint 9 | | (ETC)

Pero es fundamentalmente correcto sobre el proceso técnico involucrado y el resultado que logrará.

Pregunta 4) Selección de la iteración de la acumulación de equipos: esto puede ser problemático debido a nuestro concepto de tener equipos por cliente y no por producto, pero tal vez lo entiendo mal. En la configuración de Áreas TFS, especifique qué iteraciones son las "iteraciones de backlog para el equipo". Mi problema es que nuestros PBI (elementos de la cartera de productos) serán específicos del producto y no desean mezclarlos con PBI de otro producto. Entonces, lo que no puedo entender es cuál será el impacto si seleccionamos el área "Cliente A" como la "iteración de acumulación de trabajo para el equipo" en lugar de tal vez "Producto B". Creo que me estoy confundiendo aquí, ¿cuál sería una opción sensata?

No se está confundiendo y la persona que ingresa algo en el trabajo pendiente del equipo deberá cambiar la configuración predeterminada para que sea la iteración / área del producto en el que desea que se realice el cambio. Al menos, de manera predeterminada, está obteniendo el Equipo correcto y esto debe ser algo fácil para la persona que ingresa el artículo, el Propietario del producto o un Miembro del equipo para categorizar esto correctamente.

Todo lo que se encuentre debajo del área que usted especifique como Predeterminado del Equipo se incluye por defecto en los elementos que ve. Puede hacer clic con el botón derecho en su área predeterminada para un equipo y deseleccionar "Incluir subáreas" para que solo vea el nivel superior y esta es la técnica que se usa para el Master Backlog de Greg. Sin embargo, le sugiero que desee mantener una configuración de "Incluir subáreas" para visibilidad y transparencia dentro de su equipo.

No sé si tener un proyecto de equipo y múltiples áreas para productos (como se recomienda en general) está complicando el problema.

Puede. Algunas organizaciones prefieren agregar una lista desplegable para "Equipo" a sus elementos de trabajo (como la plantilla de Conchango / EMC) y usarla como la designación de su equipo, que puede configurarse en la configuración de las Herramientas de planificación ágil como predeterminada. De esa manera, no necesitas una designación de Equipo en Área o Iteración si te estás enfrentando a eso. No tengo recomendaciones de ninguna manera sin más información sobre cómo está configurada su organización.

Pregunta 5) Sitio web de TFS Web Access: para cualquier equipo en "TRABAJO | elementos de trabajo | Consultas compartidas" hay consultas predefinidas en una carpeta llamada "Sprint actual" (Tareas bloqueadas; Registro de Sprint; etc.), pero parece que estas consultas están codificados contra "Root Project / Release 1 / Sprint 1" - ¿no deberían descubrir automáticamente cuál es el sprint actual dadas las fechas definidas contra iteraciones? Si no es así, ¿cuál es la mejor práctica para mantener estas consultas?

Opción 1: Cada Sprint dedica los 2 minutos que lleva cambiar las consultas.

Opción 2: crear una herramienta para hacer eso por ti

Opción 3: tener un nodo de iteración "actual" adicional dentro de su versión y mover la iteración actualmente activa a debajo de ese nodo. Luego configure las consultas para que apunten a "Bajo" ese "Cliente A / Producto A / Lanzamiento 1 / Actual". Entonces es más rápido cambiar la iteración anidada una vez y todas las consultas funcionan. Entonces solo necesita cambiar la corriente, pero una vez por lanzamiento.

¿Conoce algunos cursos / tutoriales específicos de calidad de TFS 2012 y Scrum 2 que puedan ayudar a abordar estas preguntas, o brinda alguna orientación para una configuración exitosa de Scrum 2 TFS?

Recomendaría la capacitación de Professional Scrum Developer de Scrum.org y / o participar con un Consultor de ALM.

Este conjunto de preguntas intenta obtener una respuesta de práctica recomendada sobre cómo configurar las áreas e iteraciones de TFS 2012 con Scrum 2.

Contexto: hemos estado usando Team System desde TFS 2005 y habíamos creado inicialmente un Proyecto de Equipo para cada producto que tenemos y luego usamos la plantilla de proceso MSF 4.2 que finalmente modificamos ligeramente (solo agregamos algunos campos a algunos tipos de elementos de trabajo).

Continúe hasta el día de hoy y ahora ejecutamos TFS 2012 y VS 2012. Teniendo en cuenta las experiencias pasadas y los comentarios de la comunidad, pasaremos a un solo Proyecto de Equipo y Scrum 2.1 y luego usaremos áreas para separar productos y equipos. Los siguientes enlaces hacen una buena lectura para este enfoque:

Un diseño típico que planeamos aplicar para las áreas sería el siguiente:

-> Team Project (Area root) |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) |---> Product A | |---> Feature Area 1 | |---> Feature Area 2 | |---> Feature Area 3 | |---> Product B | |---> Feature Area 1 | |---> Feature Area 2 | | (ETC) |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B) |---> Product C | |---> Feature Area 1 | |---> Feature Area 2 | | (ETC)

Conceptualmente estamos muy contentos con lo anterior ya que es lógico para nuestro entorno. De acuerdo con lo anterior, tendríamos los siguientes equipos: * "Equipo del cliente A" * "Equipo del cliente B"

Pregunta 1) Pensamos que debido a que nuestros equipos no son tan grandes y para que la administración sea más manejable, no queríamos definir equipos por producto, ya que físicamente tenemos equipos por cliente y supervisan todos los productos para ese cliente. ¿Es esto un error, o está bien?

Pregunta 2) Suponiendo que la configuración del equipo anterior es correcta, ¿es correcto "mapear" cada una de las áreas anteriores a cada equipo, es decir, para el equipo "Cliente A Equipo", especifique el área "Cliente A" (y todas las subáreas) como Las áreas a ser propiedad de ese equipo. ¿Qué pasa con el área predeterminada, está bien establecer la raíz del área "Cliente A" como la predeterminada para el equipo?

En cuanto al diseño de iteraciones planeamos algo similar, como este:

-> Team Project (iteration root) |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) |---> Product A | |---> Release 1 | | |---> Sprint 1 | | |---> Sprint 2 | | |---> Sprint 3 | | | |---> Release 2 | | |---> Sprint 1 | | |---> Sprint 2 | | |---> Sprint 3 | | | |---> Release 3 | |---> Product B | |---> Release 1 | | |---> Sprint 1 | | |---> Sprint 2 | | | |---> Release 2 | | |---> Sprint 1 | | |---> Sprint 2 | | (ETC) |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B) |---> Product C | |---> Release 1 | | |---> Sprint 1 | | |---> Sprint 2 | | | |---> Release 2 | | |---> Sprint 1 | | |---> Sprint 2 | | (ETC)

Pregunta 3) Esto parece ser más complicado para hacer las iteraciones correctas, especialmente cuando se trata de TFS que muestra la acumulación. Específicamente, para la configuración de TFS Scrum 2 Iteration, parece que debería seleccionar (casilla de verificación) solo las iteraciones de nivel de hoja que son para la planificación y el desarrollo posterior. Entonces, extendiendo el ejemplo anterior, podríamos tener que el "Equipo del Cliente A" estará disponible para comenzar a trabajar en un nuevo Producto B durante las próximas 4 semanas (supongamos que son 2 semanas de sprints). ¿Entonces solo seleccionaríamos (casilla de verificación) "Sprint 1" y "Sprint 2" del lanzamiento 1? ¿Lo estoy entendiendo / utilizando correctamente?

Pregunta 4) Selección de la iteración de la acumulación de equipos: esto puede ser problemático debido a nuestro concepto de tener equipos por cliente y no por producto, pero tal vez lo entiendo mal. En la configuración de Áreas TFS, usted especifica qué iteración es la "iteración de backlog para el equipo". Mi problema es que nuestros PBI (elementos de la cartera de productos) serán específicos del producto y no desean mezclarlos con PBI de otro producto. Entonces, lo que no puedo entender es cuál será el impacto si seleccionamos el área "Cliente A" como la "iteración de acumulación de trabajo para el equipo" en lugar de tal vez "Producto B". Creo que me estoy confundiendo aquí, ¿cuál sería una opción sensata?

Las preguntas anteriores derivan de mi falta de comprensión sobre el impacto que tendrán estas selecciones para las iteraciones, las áreas, las iteraciones de la acumulación de equipos y las áreas predeterminadas para cada equipo TFS 2012 definido. Algunos de los problemas que tengo con esta configuración es que TFS identifique correctamente la acumulación del producto y la acumulación de sprint para un equipo.

No sé si tener un proyecto de equipo y múltiples áreas para productos (como se recomienda en general) está complicando el problema.

Pregunta 5) Sitio web de TFS Web Access: para cualquier equipo en "TRABAJO | elementos de trabajo | Consultas compartidas" hay consultas predefinidas en una carpeta llamada "Sprint actual" (Tareas bloqueadas; Registro de Sprint; etc.), pero parece que estas consultas están codificados contra "Root Project / Release 1 / Sprint 1" - ¿no deberían descubrir automáticamente cuál es el sprint actual dadas las fechas definidas contra iteraciones? Si no es así, ¿cuál es la mejor práctica para mantener estas consultas?

¿Conoce algunos cursos / tutoriales específicos de calidad de TFS 2012 y Scrum 2 que puedan ayudar a abordar estas preguntas, o brinda alguna orientación para una configuración exitosa de Scrum 2 TFS?