Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Azure Boards ofrece varios procesos para administrar elementos de trabajo. Seleccionar el proceso adecuado ayuda a optimizar el flujo de trabajo de tu proyecto y prepara a tu equipo para el éxito. En este artículo se describen los procesos disponibles en Azure Boards y se ayuda a elegir el que se adapte al 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:
| Term | Description |
|---|---|
| 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. |
| Process | 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 un editor visual en el portal web de Azure DevOps. |
| 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 tipos de proceso predeterminados son Basic, Agile, Capability Maturity Model Integration (CMMI) y Scrum. Los objetos de seguimiento de trabajo de los procesos predeterminados y las plantillas de proceso son los mismos. En este artículo se resumen.
Tip
Con Azure DevOps Server, puede seleccionar el modelo de proceso heredado o el modelo de proceso XML local. Para obtener más información, consulte Elección del modelo de proceso para la colección de proyectos. Para acceder a las versiones más recientes de los procesos o plantillas de proceso predeterminados:
Modelo de proceso heredado: Abra la página Procesos. Para obtener más información, consulte Administración de procesos.
Modelo de proceso XML local:
- Instalar o actualizar a la versión más reciente de Azure DevOps Server.
- Descargue el archivo de plantilla comprimido mediante el Administrador de plantillas de proceso. Use una versión de Visual Studio en el mismo nivel de versión que Azure DevOps Server. Puede instalar la versión más reciente de Visual Studio Community de forma gratuita.
- Acceda a las plantillas de proceso predeterminadas más recientes instaladas en Azure DevOps Server, por ejemplo:
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033. Para obtener descripciones de cada archivo y carpeta, consulte Introducción a los archivos de plantillas de proceso.
Procesos predeterminados
Los procesos predeterminados difieren principalmente en los tipos de elemento de trabajo que proporcionan para el trabajo de planificación y seguimiento. Use la siguiente guía para elegir el proceso que se adapte a su equipo:
- Elija Básico para la experiencia más sencilla: realice un seguimiento del trabajo como epopeyas, problemas y tareas.
- Elija Agile si el equipo usa métodos Agile y desea realizar un seguimiento de casos de usuario con actividades de desarrollo y pruebas independientes.
- Elija Scrum si su equipo sigue a Scrum y realiza un seguimiento de los elementos y errores del trabajo pendiente del producto.
- Elija CMMI si su equipo necesita administración de cambios formal, un registro auditable de decisiones y el seguimiento de requisitos, solicitudes de cambio, riesgos y revisiones.
Elección del proceso adecuado
Si no está seguro de qué proceso se ajusta a su equipo, use los siguientes escenarios como punto de partida:
| Scenario | Proceso recomendado | Por qué |
|---|---|---|
| Eres nuevo en Azure Boards o quieres la forma más ligera de seguimiento. | Basic | Tres tipos de elementos de trabajo (Epic, Issue, Task) y un flujo de trabajo sencilloTo Do / Doing / Done. |
| El equipo practica Agile, realiza un seguimiento de los casos de usuario y separa el desarrollo del trabajo de prueba. | Agile | Historias de usuario con seguimiento de errores independiente; estados más completos (New, Active, Resolved, Closed, Removed). |
| Su equipo practica Scrum con sprints, artículos pendientes de producto e impedimentos. | Scrum | Elementos del trabajo pendiente del producto y errores en el tablero; los estados Approved y Committed se corresponden directamente con las ceremonias de Scrum. |
| Trabaja en un entorno regulado que requiere un control de cambios formal, un registro auditable de decisiones y seguimiento de riesgos y revisión. | CMMI | Agrega los tipos de elementos de trabajo Requisito, Solicitud de cambio, Riesgo y Revisión y admite actividades formales de administración de cambios. |
Important
No se puede cambiar el proceso base de un proyecto después de crear el proyecto. Puede personalizar un proceso heredado para agregar campos, estados y tipos de elementos de trabajo, o bien puede crear un nuevo proyecto en un proceso diferente y mover elementos de trabajo entre proyectos.
Note
Elegir o personalizar un proceso requiere ser miembro del grupo Project Collection Administrators. Para obtener más información, consulte Referencia rápida de permisos predeterminados.
| Process | Jerarquía de elementos de trabajo |
|---|---|
|
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. |
|
|
Agile 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 tablero. 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. |
|
|
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 tablero. 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. |
|
|
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. |
|
Si necesita más de dos o tres niveles de trabajos pendientes, agregue más en función del modelo de proceso que utilice:
- Herencia: Personaliza los trabajos pendientes o paneles de un proceso
- XML hospedado o XML local: Agregar trabajos pendientes en cartera
Diferencias principales entre los procesos predeterminados
Los procesos predeterminados satisfacen 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 | Agile | Scrum | CMMI |
|---|---|---|---|---|
| Estados de flujo de trabajo | - Para hacer - En curso - Listo |
- Nuevo - Activo - Resueltas - Cerrado - Quitado |
- Nuevo - Aprobado - Confirmado - Listo - Quitado |
- Propuesto - Activo - Resueltas - Cerrado |
| Planificación del producto (véase la nota 1) | -Problema | - Caso de usuario - Error (opcional) |
- Elemento de trabajo pendiente del producto - Error (opcional) |
-Requisito - Error (opcional) |
| Pendientes de cartera (véase la nota 2) | - Épica | - Épica -Característica |
- Épica -Característica |
- Épica -Característica |
| Planeación de tareas y sprint (consulte la nota 3) | -Tarea | -Tarea - Error (opcional) |
-Tarea - Error (opcional) |
-Tarea - Error (opcional) |
| Gestión del backlog de errores (véase la nota 1) | -Problema | -Bug | -Bug | -Bug |
| Administración de problemas y riesgos | -Problema | -Problema | -Impedimento | - Solicitud de cambio -Problema -Riesgo -Revisión |
Note
- Agregue elementos de trabajo a través del trabajo pendiente del producto o el tablero. 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 priorizar el trabajo y describir las dependencias y las relaciones. Cada equipo puede configurar cómo quiere que se muestren los errores en los trabajos pendientes y tableros.
- 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.
- Defina tareas a través del trabajo pendiente del sprint y el panel de tareas. Con la planificación de la capacidad, los equipos pueden determinar si están por encima o por debajo de la capacidad durante 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.
Important
Transiciones de flujo de trabajo: Los flujos de trabajo predeterminados de Azure DevOps admiten transiciones de estado a estado. Puede personalizar estos flujos de trabajo para restringir transiciones específicas en función de los requisitos del equipo. Para más información, consulte Personalización de la experiencia de seguimiento del trabajo.
Visualización de flujos de trabajo: Para ver las transiciones de flujo de trabajo admitidas para cada tipo de elemento de trabajo, instale la extensión Marketplace de visualización de modelos de estado. Esta extensión agrega un Visualizador de estados bajo Tableros donde puede seleccionar un tipo de elemento de trabajo y ver su modelo de estado de flujo de trabajo completo.
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
Feature
Epic
Bug
Task
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. Actualice el estado de un elemento de trabajo mediante el panel o el panel de tareas. Arrastre un elemento de trabajo a su 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.
Cómo se comportan los estados eliminados, cerrados y completados en las listas de trabajo pendiente
Al cambiar el estado de un elemento de trabajo a Removed, Closedo Done, el sistema responde de la siguiente manera:
-
ClosedoDone: los elementos de trabajo en este estado no aparecen en las páginas de la cola de trabajo de cartera ni en las páginas de la cola de trabajo, pero sí aparecen en las páginas de la cola de trabajo de sprint, en el tablero y en el panel de tareas. Al cambiar la vista del trabajo pendiente de cartera a Mostrar elementos del trabajo pendiente, por ejemplo, para ver las funcionalidades junto con los elementos del trabajo pendiente del producto, también aparecen los elementos de trabajo en los estadosClosedyDone. -
Removed: los elementos de trabajo con este estado no aparecen en ningún trabajo pendiente ni tablero.
Note
El flujo de trabajo predeterminado de CMMI no incluye un estado Removed. Para sacar un elemento de trabajo de CMMI fuera del seguimiento activo, establezca su estado Closed en y elija un motivo adecuado (por ejemplo, Diferido o Rechazado). Puede personalizar un proceso heredado para agregar un Removed estado si el equipo necesita uno.
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. Puede usar este registro para crear consultas o informes.
Note
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.
Note
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.
El equipo puede crear y trabajar con estos tipos mediante la herramienta correspondiente. Estos tipos de elementos de trabajo permanecen en el esquema para la compatibilidad histórica. Microsoft Test Manager y la experiencia de Team Explorer My Work son herramientas heredadas que han sido sustituidas en gran medida por el portal web.
| Tool | tipos de elemento de trabajo |
|---|---|
| Microsoft Administrador de pruebas (heredado) |
Test Plan, Test Suite, , Test Case Shared Steps, Shared Parameters |
| Solicitar comentarios |
Feedback Request, Feedback Response |
| Mi trabajo (de Team Explorer, heredado), Revisión de código |
Code Review Request, Code Review Response |
No puede crear manualmente elementos de trabajo a partir de estas definiciones de tipo. Se agregan a la Hidden Types categoría. 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 vínculo que se muestran en la siguiente imagen conectan tipos de elemento de trabajo que admiten la experiencia de prueba y funcionan con el Administrador de pruebas y el portal web.
Desde el portal web o Microsoft Administrador de pruebas, puede ver qué casos de prueba se definen para un conjunto de pruebas y ver qué conjuntos de pruebas se definen para un plan de prueba. 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 más información, consulte Personalización de la experiencia de seguimiento del trabajo.
Si cambia el flujo de trabajo para el plan de pruebas y el conjunto de pruebas, es posible que tenga que actualizar la configuración del proceso como se describe en este artículo. Para obtener definiciones de cada campo de prueba, consulte Creación de una consulta basada en campos de integración de compilación y prueba.
Contenido relacionado
- Personalización de la experiencia de seguimiento del trabajo
- Cargar y descargar plantillas de procesos
- Administrar procesos
- Creación de un proyecto
- Seguimiento de elementos de trabajo mediante GitHub Copilot
- Proceso de Agile
- Proceso Scrum
- Proceso CMMI
- Planeamiento y seguimiento del trabajo (proceso básico)