Elegir un flujo de proceso o una plantilla de proceso para trabajar en Azure Boards

  • Artículo
  • Tiempo de lectura: 12 minutos

Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019 | TFS 2018

Cada vez que cree un proyecto, debe elegir una plantilla de proceso o proceso basada en el modelo de proceso seleccionado para su organización o colección. Al elegir un proceso para el proyecto, es importante comprender los siguientes términos:

  • Un modelo de proceso hace referencia al modelo usado para admitir proyectos creados para una organización (Azure DevOps Services) o colección de proyectos (Azure DevOps Server). Solo se admite un modelo de proceso para un proyecto a la vez. En Personalizar el seguimiento del trabajo se proporciona una comparación de los tres modelos de proceso( Herencia, XML local y XML hospedado).
  • Un proceso define los bloques de creación del sistema de seguimiento de elementos de trabajo y admite el modelo de proceso de herencia para Azure Boards. Este modelo admite la personalización de proyectos a través de una interfaz de usuario WYSIWYG.
  • Una plantilla de proceso define los bloques de creación del sistema de seguimiento de elementos de trabajo y otros subsistemas a los que accede a través de Azure DevOps. Las plantillas de proceso solo se usan con los modelos de proceso XML hospedado y XML local. Los proyectos se personalizan modificando e importando archivos de definición XML de plantilla de proceso.

Nota

Para obtener instrucciones sobre cómo configurar y personalizar el proyecto y los equipos para satisfacer sus necesidades empresariales, revise Configuración y personalización de Azure Boards.

Para obtener más información sobre cómo crear un proyecto mediante el proceso que prefiera, consulte Creación de un proyecto. Para más información sobre los modelos de proceso, consulte Personalización de la experiencia de seguimiento del trabajo.

Sugerencia

Con Azure DevOps Server, puede elegir entre usar el modelo de proceso heredado o el modelo de proceso XML local. Para obtener más información, consulte Personalización de la experiencia de seguimiento del trabajo, Elija el modelo de proceso para la colección de proyectos. Para acceder a las versiones más recientes de las plantillas de procesos o procesos predeterminadas:

Sugerencia

Para acceder a las versiones más recientes de las plantillas de proceso predeterminadas:

Los objetos de seguimiento de trabajo contenidos en los procesos predeterminados y las plantillas de proceso (Basic, Agile, CMMI y Scrum) son los mismos y se resumen a continuación. El proceso Básico está disponible en Azure DevOps Server 2019.1 y versiones posteriores. Por motivos de simplicidad, se les conoce como un "proceso".

Sugerencia

Para ver y administrar los modelos de procesos heredados, consulte Administración de procesos.

Elegir un proceso básico, Ágil, Scrum y CMMI

Los procesos predeterminados difieren principalmente en los tipos de elementos de trabajo (WIT) que proporcionan para el planeamiento y el seguimiento del trabajo.

Basic es el más ligero y está en una versión preliminar selectiva. Scrum es el siguiente más ligero. Agile admite muchos términos de método agile y CMMI, que significa La integración del modelo de madurez de funcionalidad, proporciona la mayor compatibilidad con los procesos formales y la administración de cambios.

Nota

El proceso Básico está disponible con Azure DevOps Server 2019 Update 1 y versiones posteriores.

Elija el proceso que proporcione la mejor opción para su equipo.

Basic

Elija Básico cuando el equipo quiera el modelo más sencillo que usa Problemas, Tareas y Epopeyas para realizar un seguimiento del trabajo.

Las tareas admiten el seguimiento del trabajo restante.

Tipos de elementos de trabajo básicos

Ágil

Elija Agile cuando el equipo use métodos de planeamiento ágil, incluido Scrum, y realice un seguimiento de las actividades de desarrollo y pruebas por separado. Este proceso funciona bien si desea realizar un seguimiento de los casos de usuario y (opcionalmente) errores en el panel Kanban, o realizar un seguimiento de errores y tareas en el panel de tareas.

Puede obtener más información sobre las metodologías de Agile en Agile Alliance.

Las tareas admiten el seguimiento de la estimación original, el trabajo restante y el trabajo completado.

Tipos de elemento de trabajo de Agile

Scrum

Elige Scrum cuando tu equipo practica Scrum. Este proceso funciona muy bien si desea realizar un seguimiento de los elementos de trabajo pendiente del producto (PBIs) y errores en el panel Kanban, o desglosar los PBIs y los errores en las tareas del panel de tareas.

Este proceso es compatible con la metodología scrum definida por la organización Scrum.

Las tareas solo admiten el seguimiento del trabajo restante.

Tipos de elemento de trabajo Scrum

CMMI

Elija CMMI cuando el equipo siga métodos de proyecto más formales que requieran un marco para la mejora de procesos y un registro auditable de decisiones. Con este proceso, puede realizar un seguimiento de los requisitos, las solicitudes de cambio, los riesgos y las revisiones.

Este proceso admite actividades formales de administración de cambios. Las tareas admiten el seguimiento de la estimación original, el trabajo restante y el trabajo completado.

Tipos de elemento de trabajo de CMMI

Si necesita más de dos o tres niveles de trabajo pendiente, puede agregar más en función del modelo de proceso que use:

Diferencias principales entre los procesos predeterminados

Los procesos predeterminados están diseñados para satisfacer las necesidades de la mayoría de los equipos. Si el equipo tiene necesidades inusuales y se conecta a un servidor local, puede personalizar un proceso y, a continuación, crear el proyecto. O bien, puede crear un proyecto a partir de un proceso y, a continuación, personalizar el proyecto.

En la tabla siguiente se resumen las diferencias principales entre los WIT y los estados usados por los cuatro procesos predeterminados.

Área de seguimiento

Basic

Ágil

Scrum

CMMI

Estados de flujo de trabajo

  • To Do
  • En curso
  • Listo
  • Nuevo
  • Activo
  • Resuelto
  • Cerrado
  • Quitado
  • Nuevo
  • Aprobado
  • Confirmado
  • Listo
  • Quitado
  • Propuesto
  • Activo
  • Resuelto
  • Cerrado

Planeación del producto (vea la nota 1)

  • Problema
  • Caso de usuario
  • Error (opcional)
  • Elemento de trabajo pendiente del producto
  • Error (opcional)
  • Requisito
  • Error (opcional)

Trabajos pendientes de cartera (2)

  • Epopeya
  • Epopeya
  • Característica
  • Epopeya
  • Característica
  • Epopeya
  • Característica

Planificación de tareas y sprints (3)

  • Tarea
  • Tarea
  • Error (opcional)
  • Tarea
  • Error (opcional)
  • Tarea
  • Error (opcional)

Administración del trabajo pendiente de errores (1)

  • Problema
  • Error
  • Error
  • Error

Administración de problemas y riesgos

  • Problema
  • Problema
  • Impedimento
  • Problema
  • Riesgo
  • Revisar

Nota

  1. Puede agregar estas WIT desde el trabajo pendiente del producto o la placa Kanban. El trabajo pendiente del producto muestra una sola vista del trabajo pendiente actual que se puede volver a ordenar y agrupar dinámicamente. Los propietarios de productos pueden priorizar rápidamente el trabajo y describir las dependencias y las relaciones.
    Además, cada equipo puede configurar cómo quieren que se muestren errores en sus trabajos pendientes y paneles.
  2. Con los trabajos pendientes de cartera, se puede definir una jerarquía de trabajos pendientes para entender el ámbito de trabajo en diferentes equipos y ver cómo ese trabajo da lugar a iniciativas más amplias. Cada equipo puede configurar qué trabajos pendientes de cartera aparecen para su uso.
  3. Puede definir tareas desde el trabajo pendiente de sprint y el panel de tareas. Con el planeamiento de la capacidad, los equipos pueden determinar rápidamente si están por encima o por debajo de la capacidad de un sprint.

Estados, transiciones y motivos de flujo de trabajo

Los estados del flujo de trabajo admiten el seguimiento del estado del trabajo conforme se desplaza de un estado Nuevo a un estado Cerrado o Listo. Cada flujo de trabajo consta de un conjunto de estados, las transiciones válidas entre los estados y los motivos para realizar la transición del elemento de trabajo al estado seleccionado.

Importante

Para Azure DevOps Services y Azure DevOps Server 2019, las transiciones de flujo de trabajo predeterminadas admiten cualquier estado a cualquier transición de estado. Puede personalizar estos flujos de trabajo para restringir algunas transiciones. Consulte Personalización de objetos de seguimiento de trabajo para admitir los procesos de su equipo.

Además, puede ver las transiciones de flujo de trabajo admitidas para cada tipo de elemento de trabajo mediante la instalación de la extensión Markeplace de visualización del modelo de estado. Esta extensión agrega un nuevo centro en Boards con la etiqueta State Visualizer. En esa página puede elegir un tipo de elemento de trabajo y ver el modelo de estado de flujo de trabajo.

En los diagramas siguientes se muestra la progresión hacia delante típica de esas REDES WIT usadas para realizar un seguimiento del trabajo y los defectos de código de los tres procesos predeterminados. También muestran algunas de las regresiones a estados y transiciones anteriores a estados Quitado. Cada imagen solo muestra el motivo predeterminado asociado a la transición.

Caso de usuario

Estados de flujo de trabajo de caso de usuario, proceso ágil

Característica

Estados de flujo de trabajo de características, proceso ágil

Epopeya

Estados de flujo de trabajo épicos, proceso ágil

Error

Estados de flujo de trabajo de errores, proceso ágil

Tarea

Estados de flujo de trabajo de tareas, proceso ágil

La mayoría de las WIT usadas por las herramientas de Agile, las que aparecen en trabajos pendientes y paneles, admiten transiciones cualquiera a cualquier. Puede actualizar el estado de un elemento de trabajo mediante el panel Kanban o el panel de tareas arrastrándolo a su columna de estado correspondiente.

Puede cambiar el flujo de trabajo para admitir otros estados, transiciones y motivos. Para más información, consulte Personalización de la experiencia de seguimiento del trabajo.

Estados Quitado, Cerrado y Listo

Cuando cambia el estado de un elemento de trabajo a Quitado, Cerrado o Listo, el sistema responde así:

  • Cerrado o hecho: los elementos de trabajo de este estado no aparecen en las páginas de trabajo pendiente y trabajo pendiente de cartera. Sin embargo, aparecen en las páginas de trabajos pendientes de sprint, el panel Kanban y el panel de tareas. Además, al cambiar la vista de trabajo pendiente de cartera para mostrar elementos de trabajo pendiente, por ejemplo, para ver características en Elementos de trabajo pendientes del producto, aparecen elementos de trabajo en el estado cerrado y terminado.
  • Quitado: los elementos de trabajo de este estado no aparecen en ningún trabajo pendiente o panel.

Los elementos de trabajo se mantienen en un proyecto siempre que el proyecto esté activo. Aunque los configure como Cerrado, Listo o Quitado, se mantiene un registro en el almacén de datos. Puede usar un registro para crear consultas o informes.

Nota

Los elementos de trabajo completados o cerrados no se muestran en los trabajos pendientes y paneles una vez que su fecha modificada es superior a 183 días (aproximadamente medio año). Todavía puede enumerar estos elementos mediante una consulta. Si quiere que aparezcan en un trabajo pendiente o en un panel, puede realizar un cambio menor en ellos que restablezca el reloj.

Nota

Los elementos de trabajo completados o cerrados no se muestran en los trabajos pendientes y paneles una vez que su fecha de cambio es mayor que un año de antigüedad. Todavía puede enumerar estos elementos mediante una consulta. Si quiere que aparezcan en un trabajo pendiente o en un panel, puede realizar un cambio menor en ellos que restablezca el reloj.

Si necesita eliminar permanentemente elementos de trabajo, consulte Quitar o eliminar elementos de trabajo.

Tipos de elementos de trabajo agregados a todos los procesos

Los siguientes WIT se agregan a todos los procesos, excepto el proceso básico.

Tipos de elementos de trabajo usados por Test Plans, Administradores de pruebas de Microsoft, Mi trabajo y Comentarios

Los equipos crean y trabajan con estos tipos utilizando la herramienta correspondiente:

  • Plan de pruebas, Conjunto de pruebas, pasos compartidos de casos de prueba y parámetros compartidos: Microsoft Test Manager.
  • Solicitud de comentarios y respuesta de comentarios: Solicitar comentarios.
  • Solicitud de revisión de código y respuesta de revisión de código: Mi trabajo (en Team Explorer) y Solicitud de revisión de código.

Los elementos de trabajo de estas definiciones de tipo no están diseñados para crearse manualmente y, a continuación, se agregan a la categoría Tipos ocultos. Los tipos de elemento de trabajo agregados a la categoría Tipos ocultos no aparecen en los menús que crean nuevos elementos de trabajo.

WIT que admiten la experiencia de prueba

Los WIT que admiten la experiencia de prueba y funcionan con el Administrador de pruebas y el portal web se vinculan conjuntamente mediante los tipos de vínculo que se muestran en la siguiente imagen.

tipos de elemento de trabajo de administración de pruebas

Desde el portal web o Microsoft Test Manager, puede ver qué casos de prueba se definen para un conjunto de pruebas. Además, puede ver qué conjuntos de pruebas se definen para un plan de prueba. Sin embargo, estos objetos no están conectados entre sí a través de tipos de vínculo. Personalice estas WIT como haría con cualquier otro WIT. Consulte Personalización de objetos de seguimiento de trabajo para admitir los procesos de su equipo.

Si cambia el flujo de trabajo para el Plan de pruebas y el Conjunto de pruebas, deberá actualizar la configuración del proceso, tal como se describe aquí. Para ver las definiciones de cada campo de prueba, consulte Consulta basada en campos de integración de compilación y prueba.

Puede personalizar un proceso antes o después de crear un proyecto que use el proceso. Los métodos que use dependen del modelo de proceso que use. Para más información, consulte Personalización de la experiencia de seguimiento del trabajo.

Si tiene más preguntas, consulte la página de soporte técnico de Azure DevOps.