Acerca de los procesos predeterminados y las plantillas de proceso
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:
- 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:
- Instale o actualice a la versión más reciente de Azure DevOps Server.
- Descargue el archivo de plantilla comprimido mediante el administrador de plantillas de proceso. Deberá usar 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:
- 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.
Á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.
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.
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: personalizar 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 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:
- 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.
- 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. 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
Característica
Epopeya
Error
Tarea
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 estadoClosedyDone.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.
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.
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.