trabajar - TFS tipos de elementos de trabajo: tareas frente a escenarios, o el uso de ambos?
trabajar con ramas tfs (4)
En la configuración predeterminada de TFS hay tres tipos de elementos de trabajo: escenario, tarea y error. El último es bastante sencillo, y la tarea también: es un trabajo específico que debe completar un miembro del equipo. Pero creo que el escenario es un poco vago.
Normalmente creo un escenario para unidades de trabajo más grandes y más generales: por ejemplo, "Crear funcionalidad para agregar líneas de empleados a un empleador". Los elementos de trabajo más pequeños y específicos serían entonces tareas, por ejemplo: "Crear formulario de detalle", "Crear método de salvar en el servidor", etc.
Cuando controlo los cambios, vinculo el conjunto de cambios al escenario Y a la tarea específica. ¿Es este un buen hábito? ¿Cómo manejas las tareas y los escenarios? ¿Algún recurso a las mejores prácticas?
También he escuchado que los escenarios están diseñados para casos de uso, ¿es así?
En la plantilla Agile de MSF, los escenarios también pueden considerarse como " historia de usuario ", como un caso de uso ágil y liviano.
El Escenario detalla la imagen general de la funcionalidad que se desea implementar, registrando una única ruta de la interacción de un usuario con una parte del sistema. Por ejemplo, en , un par de escenarios podrían ser "Hacer una pregunta" o "Responder una pregunta". Escenarios y requisitos de calidad de servicio se pueden considerar como elementos de trabajo de nivel superior en MSF Agile (es decir, los elementos de trabajo que definen el sistema) con Escenarios que son requisitos funcionales y Calidad de servicio que no son requisitos funcionales.
Tiendo a crear múltiples tareas de cada escenario y, por lo general, solo registro mi check-in contra la tarea. En TFS 2010 están llegando correctamente elementos de trabajo jerárquicos que facilitarán el informe de esta forma de trabajo. Actualmente, las asociaciones de elementos de trabajo son bidireccionales (es decir, se puede decir que una tarea está asociada a un escenario, pero no se puede decir que sea un elemento secundario).
No hay nada de malo en marcar su check-in contra la tarea y el escenario, solo que crea más trabajo para usted cuando realiza el check-in. Además, el escenario podría ser entregado por una cantidad de desarrolladores, ya que una tarea tiende a ser inaceptable. en la granularidad de las actividades de la persona individual.
Si realiza una gran cantidad de asociaciones de un elemento de trabajo con un escenario, entonces el siguiente consejo podría ser útil para usted ( http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html ). Le muestra cómo modificar la plantilla de proceso MSF Agile estándar para eliminar la capacidad de los check-in para resolver el escenario, pero solo asocie el check-in con ese elemento de trabajo. La resolución del check-in para un elemento de trabajo de larga ejecución, como un Escenario, casi nunca es lo que quiere que suceda, pero es el comportamiento predeterminado de fábrica.
Espero que ayude.
Los escenarios pueden ser cualquier historia de usuario.
Solo necesita registrarse en la tarea. Cuando se crean tareas, primero deben vincularse a un escenario antes de asignárselas a los desarrolladores.
De esta forma, la asociación entre checkins y escenario es automática (e informable).
Sin punto de doble manejo
Puede pensar en escenarios que representan la perspectiva de los usuarios, mientras que las tareas son la perspectiva de los desarrolladores. Según la documentación de MSF Agile, un escenario "representa una ruta única de interacción del usuario a través del sistema que está creando" y una tarea "identifica un elemento de trabajo específico para que lo realice un miembro del equipo".
Las tareas se pueden vincular a escenarios. Al registrarte, como desarrollador, has resuelto una tarea, no el escenario, por lo que debes relacionar el conjunto de cambios con esta tarea.
Si por "configuración predeterminada de TFS" se entiende la plantilla de proyecto "MSF para desarrollo ágil de software", entonces un escenario se define de la siguiente manera:
Un escenario es un tipo de elemento de trabajo que registra una única ruta de interacción del usuario a través del sistema. A medida que la persona intenta alcanzar un objetivo, el escenario registra los pasos específicos que darán para intentar alcanzar ese objetivo. Algunos escenarios registrarán una ruta exitosa; otros grabarán uno sin éxito. Al escribir escenarios, sea específico ya que hay muchos caminos posibles.
Para obtener un poco más de información sobre esto, eche un vistazo a la carpeta "Documents / Process Guidance" bajo el proyecto en Team Explorer - explica el proceso recomendado bastante bien