Acerca de los procesos predeterminados y las plantillas de proceso

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Azure Boards ofrece varios procesos entre los que elegir para administrar los elementos de trabajo. Es esencial seleccionar el proceso adecuado para optimizar el flujo de trabajo de un proyecto y garantizar su éxito. En este artículo, descubriremos los distintos procesos disponibles con Azure Boards. En este artículo también se dan indicaciones sobre cómo elegir el proceso más adecuado para el proyecto.

Al crear un proyecto, se elige un proceso o una plantilla de proceso en función del modelo de proceso para el que se creó la organización o la colección. Antes de elegir un proceso para el proyecto, comprenda los términos siguientes:

Término Descripción
Modelo de proceso Hace referencia al modelo utilizado para admitir proyectos creados para una organización o colección de proyectos. Solo se admite un modelo de proceso para un proyecto a la vez.
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 mediante una interfaz de usuario What You See Is What You Get (WYSIWYG).
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 . Puede personalizar proyectos modificando e importando archivos de definición XML de plantilla de proceso.

Los objetos de seguimiento del trabajo incluidos en los procesos predeterminados y las plantillas de proceso que se basan en Basic, Agile, Capability Maturity Model Integration (CMMI) y Scrum) son los mismos. Se resumen más adelante en este artículo.

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 la sección Selección del modelo de proceso para la colección de proyectos en Personalización de la experiencia de seguimiento del trabajo. Para acceder a las versiones más recientes de las plantillas de proceso y los procesos predeterminados:

Procesos predeterminados

Los procesos predeterminados difieren principalmente en los tipos de elementos de trabajo que se usan para la planificación y el seguimiento del trabajo. Los procesos predeterminados son:

  • 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 del método Agile.
  • CMMI: tiene la mayor compatibilidad para procesos formales y la gestión de cambios.

Nota:

El proceso Básico está disponible con la Actualización 1 de Azure DevOps Server 2019 y versiones posteriores.

Basic

Seleccione Basic cuando el equipo quiera el modelo más sencillo, que usa los tipos de elementos de trabajo Problema, Tarea y Epopeya para realizar un seguimiento del trabajo.

Las tareas admiten el seguimiento del trabajo restante.

Tipos de elementos de trabajo básicos

Ágil

Seleccione Agile cuando el equipo use métodos de planeamiento Agile, incluido Scrum, y realice un seguimiento de las actividades de desarrollo y pruebas por separado. Este proceso funciona muy bien a la hora de hacer un seguimiento de casos de usuario y (opcionalmente) errores en el panel Kanban. También puede realizar un seguimiento de errores y tareas en el panel de tareas.

Para obtener más información sobre las metodologías ágiles, consulte 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

Seleccione Scrum si el equipo pone en práctica Scrum. Este proceso funciona muy bien para realizar un seguimiento de los elementos de trabajo pendiente y los errores en el panel Kanban. También puede dividir los elementos de trabajo pendiente del producto y los errores en tareas en el panel de tareas.

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

Con las tareas solo se admite el seguimiento del trabajo restante.

Tipos de elemento de trabajo Scrum

CMMI

Seleccione CMMI cuando el equipo siga métodos de proyecto más formales que requieren un marco para la mejora del proceso y un registro auditable de las 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 trabajos pendientes, agregue más en función del modelo de proceso que utilice:

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 al equipo le surgen una serie de necesidades inusuales y se conecta a un servidor local, cree un proceso personalizado y después cree el proyecto. Puede también crear un proyecto a partir de un proceso y luego personalizar el proyecto.

En la siguiente tabla, se resumen las principales diferencias entre los tipos de elementos de trabajo y los estados que se utilizan en los cuatro procesos predeterminados.

Área de seguimiento

Basic

Ágil

Scrum

CMMI

Estados de flujo de trabajo

  • Tareas
  • En curso
  • Listo
  • Nuevo
  • Activo
  • Resuelto
  • Closed
  • Quitado
  • Nuevo
  • Aprobado
  • Confirmado
  • Listo
  • Quitado
  • Propuesto
  • Activo
  • Resuelto
  • Closed

Planificación del producto (consulte Nota 1)

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

Trabajos pendientes en cartera (consulte Nota 2)

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

Planificación de tareas y sprints (consulte Nota 3)

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

Administración de trabajos pendientes de errores (consulte Nota 1)

  • Problema
  • Error
  • Error
  • Error

Administración de incidencias y riesgos

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

Notas:

  1. Agregue elementos de trabajo a través del trabajo pendiente del producto o el panel Kanban. En el trabajo pendiente del producto se abre una vista única del trabajo pendiente actual que se puede reordenar y agrupar dinámicamente. Los propietarios del producto pueden dar prioridad rápidamente a un trabajo y trazar las dependencias y relaciones. Además, cada equipo puede configurar cómo quiere que se muestren los errores en los trabajos pendientes y paneles.
  2. Defina una jerarquía de trabajos pendientes de cartera para conocer las implicaciones del trabajo en varios equipos y ver cómo ese trabajo se consolida en forma de iniciativas más amplias. Cada equipo configura qué trabajos pendientes de cartera aparecen para usarlos.
  3. Defina tareas a través del trabajo pendiente del sprint y el panel de tareas. Al planificar 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 permiten el seguimiento del estado del trabajo conforme se desplaza del estado New al estado Closed y al estado Done. 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

En el caso de Azure DevOps Services y Azure DevOps Server 2019, las transiciones de flujo de trabajo predeterminadas admiten las transiciones de cualquier estado a cualquier estado. Personalice estos flujos de trabajo para restringir algunas transiciones. Para obtener más información, consulte Personalización de los objetos de seguimiento del trabajo para admitir los procesos del equipo.

Consulte también las transiciones de flujo de trabajo admitidas en cada tipo de elemento de trabajo instalando la extensión del Marketplace State Model Visualization (Visualización de modelos de estado). Esta extensión incorpora una nueva herramienta en Paneles etiquetado como Visualizador de estado. En esa página, puede elegir un tipo de elemento de trabajo y ver el modelo de estado del flujo de trabajo.

En los diagramas siguientes se muestra la progresión hacia delante típica de estos tipos de elementos de trabajo que sirven para realizar el seguimiento del trabajo y de los defectos del código en las tres plantillas de proceso predeterminadas. 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

Captura de pantalla de los estados de flujo de trabajo de Caso de usuario mediante el proceso Agile.

Característica

Captura de pantalla de los estados de flujo de trabajo de Característica mediante el proceso Agile.

Epopeya

Captura de pantalla de los estados de flujo de trabajo de Epopeya mediante el proceso Agile.

Error

Captura de pantalla de los estados de flujo de trabajo de Error mediante el proceso Agile.

Tarea

Captura de pantalla de los estados de flujo de trabajo de Tarea mediante el proceso Agile.

La mayoría de los tipos de elementos de trabajo usados por las herramientas basadas en Agile, los que aparecen en trabajos pendientes y paneles, admiten transiciones de cualquier a cualquier estado. Modifique el estado de un elemento de trabajo mediante el panel Kanban o el panel de tareas arrastrándolo a la columna de estado correspondiente.

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

Estados de un elemento de trabajo

Al cambiar el estado de un elemento de trabajo a Removed, Closedo Done, el sistema responde de la siguiente manera:

  • Closed/Done: los elementos de trabajo con este estado no aparecen en las páginas de trabajo pendiente en cartera y trabajo pendiente. Estos aparecen en las páginas de trabajo pendiente del sprint, el panel Kanban y el panel de tareas. Además, cuando se cambia la vista del trabajo pendiente en cartera para Mostrar elementos de trabajo pendiente, por ejemplo, para ver las características de los elementos de trabajo pendiente de producto, aparecerán elementos de trabajo con el estado Closed y Done.
  • Removed: los elementos de trabajo con este estado no aparecen en ningún trabajo pendiente ni panel.

El proyecto mantiene los elementos de trabajo siempre que el proyecto esté activo. Incluso si establece elementos de trabajo en Closed, Done o Removed, el almacén de datos mantiene un registro. Utilice un registro para crear consultas o informes.

Nota:

Los elementos de trabajo completados o cerrados no se muestran en los trabajos pendientes y los paneles una vez que el valor de fecha de modificación supera los 183 días (aproximadamente medio año). Puede ver estos elementos mediante una consulta. Si desea 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 los paneles una vez que ha transcurrido un año desde su fecha de modificación. Puede ver estos elementos mediante una consulta. Si desea 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 los elementos de trabajo, consulte Quitar o eliminar elementos de trabajo.

Tipos de elementos de trabajo agregados a todos los procesos

Los siguientes tipos de elementos de trabajo se agregan a todos los procesos excepto el proceso Basic.

Captura de pantalla de los tipos de elementos de trabajo usados en los planes de prueba, Microsoft Test Managers, Mi trabajo y Comentarios.

El equipo puede crear y trabajar con estos tipos mediante la herramienta correspondiente.

Herramienta tipos de elemento de trabajo
Microsoft Test Manager Test Plan, Test Suite, Test Case Shared Steps, Shared Parameters
Solicitar comentarios Feedback Request, Feedback Response
Mi trabajo (desde Team Explorer), Revisión del código Code Review Request, Code Review Response

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

Tipos de elementos de trabajo que admiten la experiencia de prueba

Los tipos de elementos de trabajo que admiten la experiencia de pruebas y que funcionan con Test Manager y el portal web están vinculados entre sí mediante los tipos de vínculo que se muestran en la siguiente imagen.

Captura de pantalla de los tipos de elementos de trabajo de administración de pruebas.

En el portal web o en Microsoft Test Manager, vea qué casos de prueba se definen en un conjunto de pruebas y qué conjuntos de pruebas se definen en un plan de pruebas. No obstante, estos objetos no están conectados entre sí mediante tipos de vínculo. Personalice estos tipos de elementos de trabajo como haría con cualquier otro tipo de elemento de trabajo. Para obtener más información, consulte Personalización de los objetos de seguimiento del trabajo para admitir los procesos del 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 obtener una definición de cada campo de pruebas, consulte Consulta basada en campos de integración de compilación y pruebas.