Elija una plantilla Azure DevOps Server proceso o flujo de proceso para que funcione Azure Boards o Azure DevOps

  • Artículo
  • Tiempo de lectura: 12 minutos

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

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 términos siguientes:

  • Un modelo de proceso hace referencia al modelo que se usa para admitir proyectos creados para una organización (Azure DevOps Services) o una colección de proyectos (Azure DevOps Server). Solo se admite un modelo de proceso para una organización o colección a la vez. En Personalización del seguimiento de 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 Azure Boards. Este modelo admite la personalización de proyectos a través de una interfaz de usuario DEWWYG.
  • Una plantilla de proceso define los bloques de creación del sistema de seguimiento de elementos de trabajo y otros subsistemas a los que se accede a través 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, consulte Configuración y personalizaciónde Azure Boards .

Para 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 de trabajo.

Sugerencia

Con Azure DevOps Server, puede elegir entre usar el modelo de proceso heredado o el modelo de proceso XML local. Para más información, consulte Personalización de la experiencia de seguimiento de trabajo, Elección del 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 y plantillas de proceso predeterminados (Básico, 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 denominan "proceso".

Sugerencia

Para ver y administrar modelos de procesos heredados, vea Administrar procesos.

Elección de un proceso Básico, Agile, Scrum y CMMI

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

Basic es el más ligero y se encuentra en una versión preliminar selectiva. Scrum es el siguiente más ligero. Agile admite muchos términos del método Agile y CMMI, que es el nombre de integración del modelo de madurez de la capacidad, proporciona la mayor compatibilidad con procesos formales y 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 mejor se adapte a su equipo.

Nota:

Las epopeyas se admiten Azure Boards y Azure DevOps. Cada equipo puede elegir los niveles de trabajo pendiente que están activos como se describe en Selección de niveles de navegación de trabajo pendiente para el equipo.

Basic

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

Nota:

Basic está actualmente en una versión preliminar selectiva para los nuevos usuarios Azure Boards solo.

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 de Agile, incluido Scrum, y haga un seguimiento de las actividades de desarrollo y pruebas por separado. Este proceso funciona muy bien si desea realizar un seguimiento de los casos de usuario y (opcionalmente) los 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

Elija Scrum cuando el equipo entre en prácticas de Scrum. Este proceso funciona muy bien si desea realizar un seguimiento de los elementos de trabajo pendiente (PBI) y los errores del panel Kanban, o dividir los PBI y los errores en tareas en el panel de tareas.

Este proceso admite la metodología de Scrum, tal como se define en la organización de 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 del proceso 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, personalizarlo.

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

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

Planeación del producto (vea la nota 1)

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

Trabajo pendiente de cartera (2)

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

Planeamiento de tareas y sprint (3)

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

Administración de trabajo pendiente de errores (1)

  • Incidencia
  • Error
  • Error
  • Error

Administración de problemas y riesgos

  • Incidencia
  • Incidencia
  • Impedimento
  • Incidencia
  • Riesgo
  • Revisar

Nota:

  1. Puede agregar estos WIT desde el trabajo pendiente del producto o el panel Kanban. El trabajo pendiente del producto muestra una vista única 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 desea que los errores se muestren en sus paneles y trabajo pendientes.
  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é 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 instalando la extensión Markeplace de visualización del modelo de estado. Esta extensión agrega un nuevo centro en Boards con la etiqueta Visualizador de estado. 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 los WIT usados para realizar un seguimiento de los defectos de trabajo y 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.

Epopeya, Problema, Jerarquía de tareas

Jerarquía básica de elementos de trabajo de proceso

Epopeya, problema, flujo de trabajo de tareas

Flujo de trabajo de proceso básico

Nota:

El proceso Básico está disponible cuando se crea un proyecto desde Azure DevOps Services o Azure DevOps Server 2019.1. Para implementaciones locales anteriores, elija Agile, Scrum o proceso de CMMI.

La mayoría de las WIT que usan las herramientas de Agile, las que aparecen en los paneles y los trabajo pendientes, admiten transiciones de cualquier a cualquiera. 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 razones. 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 listo:los elementos de trabajo en este estado no aparecen en las páginas de trabajos pendientes y trabajos pendientes de la cartera. Sin embargo, aparecen en las páginas de trabajo pendiente de sprint, el panel Kanban y el panel de tareas. Además, al cambiar la vista de trabajos pendientes de cartera para mostrar los elementos de trabajo pendiente, por ejemplo, para ver Características en Elementos de trabajo pendientes del producto, aparecen los elementos de trabajo en estado cerrado y listo.
  • Quitado:los elementos de trabajo en este estado no aparecen en ningún trabajo pendiente o placa.

Los elementos de trabajo se mantienen en un proyecto siempre y cuando 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 la fecha de cambio es mayor que un año de antigüedad. Todavía puede enumerar estos elementos mediante una consulta. Si desea que se muestren en un trabajo pendiente o placa, puede realizar un cambio menor en ellos que restablezca el reloj.

Si necesita eliminar permanentemente elementos de trabajo, vea 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 elementos de trabajo agregados a la categoría Tipos ocultos no aparecen en los menús que crean nuevos elementos de trabajo.

Nota:

Si actualizó el proyecto de Azure DevOps 2013 o una versión anterior a una versión posterior, es posible que tenga que agregar WIT que no existían en las versiones anteriores. Para más información, consulte Configuración de características después de una actualización.

Se agregaron los siguientes WIT con la versión de software indicada:

  • Parámetros compartidos agregados con Azure Dev Ops 2013.2
  • Plan de pruebas y conjunto de pruebas agregados con Azure DevOps 2013.3

WIT que admiten la experiencia de prueba

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

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. Y puede ver qué conjuntos de pruebas se definen para un plan de pruebas. Sin embargo, estos objetos no están conectados entre sí a través de tipos de vínculo. Personalice estos WIT como lo 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 obtener definiciones de cada campo de prueba, vea 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 Azure DevOps soporte técnico.