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.
Azure DevOps Services | 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 del proyecto y a garantizar el éxito del proyecto. En este artículo, explore los distintos procesos disponibles con Azure Boards. En este artículo se proporcionan instrucciones 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:
| 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 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 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. Se resumen más adelante en este artículo.
Tip
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 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 que esté 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.
- Puede acceder a las versiones más recientes de las plantillas de proceso predeterminadas 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 elementos de trabajo que se usan para la planificación y el seguimiento del trabajo. Los procesos predeterminados son:
- Básico: es el más ligero.
- 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.
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 el proceso predeterminado
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
Agile
Scrum
CMMI
Estados de flujo de trabajo
- Tareas pendientes
- Doing
- Done
- New
- Active
- Resolved
- Closed
- Removed
- New
- Approved
- Committed
- Done
- Removed
- Proposed
- Active
- Resolved
- Closed
Planificación del producto (consulte Nota 1)
- Issue
- Caso de usuario
- Error (opcional)
- Elemento de trabajo pendiente del producto
- Error (opcional)
- Requirement
- Error (opcional)
Trabajos pendientes en cartera (consulte Nota 2)
- Epic
- Epic
- Feature
- Epic
- Feature
- Epic
- Feature
Planificación de tareas y sprints (consulte Nota 3)
- Task
- Task
- Error (opcional)
- Task
- Error (opcional)
- Task
- Error (opcional)
Administración de trabajos pendientes de errores (consulte Nota 1)
- Issue
- Bug
- Bug
- Bug
Administración de incidencias y riesgos
- Issue
- Issue
- Impediment
- Issue
- Risk
- Review
Notes:
- 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: Las transiciones de flujo de trabajo predeterminadas admiten cualquier estado a cualquier transición de estado para Azure DevOps. 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.
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:
-
ClosedoDone: los elementos de trabajo con este estado no aparecen en las páginas de trabajo pendiente en cartera y trabajo pendiente. Sin embargo, aparecen en las páginas de trabajos pendientes de sprint, el panel y el panel de tareas. Cuando se cambia la vista del trabajo pendiente en cartera a Mostrar elementos de trabajo pendiente, por ejemplo, para ver las características de los elementos de trabajo pendiente del producto, aparecerán elementos de trabajo con el estadoClosedyDone. -
Removed: los elementos de trabajo con este estado no aparecen en ningún trabajo pendiente ni tablero.
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.
| Tool | 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.
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 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, deberá actualizar la configuración del proceso, tal como se describe aquí. 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.