Definición, captura, evaluación de prioridades y administración de los errores de software en Azure Boards

  • Artículo

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

¿Cómo realiza el seguimiento y la administración de los defectos de código? ¿Cómo se asegura de que se aborden rápidamente los problemas de software y los comentarios de los clientes para posibilitar implementaciones de software de alta calidad? Y, ¿cómo realiza avances en las nuevas características y aborda la deuda técnica?

Como mínimo, necesita una manera de capturar las incidencias de software, clasificarlos por orden de prioridad, asignarlos a un miembro del equipo y realizar un seguimiento del progreso. Además, querrá administrar los defectos de código de maneras que se alineen con sus prácticas Agile.

Para admitir estos escenarios, Azure Boards proporciona un tipo de elemento de trabajo específico para realizar un seguimiento de los defectos de código llamado Error. Los elementos de trabajo de error comparten todas las características estándar de otros tipos de elementos de trabajo con algunos más. Para obtener información general sobre las características estándar, consulte Seguimiento del trabajo con casos de usuario, incidencias, errores, características y epopeyas.

Los errores también proporcionan las siguientes características adicionales:

  • Opciones para que cada equipo elija cómo quiere realizar el seguimiento de los errores
  • Herramientas de prueba para capturar errores
  • Integración integrada en Azure DevOps para realizar un seguimiento de los errores vinculados a compilaciones, versiones y pruebas

Nota:

Los tipos de elementos de trabajo de error no están disponibles con el proceso Básico. El proceso Básico realiza un seguimiento de los errores como Incidencias y está disponible al crear un proyecto en Azure DevOps Services o Azure DevOps Server 2019.1 o versiones posteriores.

Requisitos previos

  • Debe estar agregado a un proyecto.
  • Para ver o modificar los elementos de trabajo, debe tener los permisos de Ver los elementos de trabajo en este nodo y Editar elementos de trabajo de este nodo establecidos en Permitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo.
  • Con el fin de agregar nuevas etiquetas para agregar elementos de trabajo, debe tener acceso Básico o superior, y tener establecido el conjunto de permisos de nivel de proyecto Crear nueva definición de etiqueta en Permitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Incluso si se establece explícitamente el permiso para una parte interesada, no tiene permiso para agregar nuevas etiquetas, ya que están prohibidas en su nivel de acceso. Para obtener más información, consulte Referencia rápida sobre el acceso de parte interesada.
  • Todos los miembros del proyecto, incluso los del grupo Lectores, pueden enviar correos electrónicos que contengan elementos de trabajo.
  • Debe estar agregado a un proyecto.
  • Para ver o modificar los elementos de trabajo, debe tener los permisos de Ver los elementos de trabajo en este nodo y Editar elementos de trabajo de este nodo establecidos en Permitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo.
  • Con el fin de agregar nuevas etiquetas para agregar elementos de trabajo, debe tener acceso Básico o superior, y tener establecido el conjunto de permisos de nivel de proyecto Crear nueva definición de etiqueta en Permitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Incluso si se establece explícitamente el permiso para una parte interesada, no tiene permiso para agregar nuevas etiquetas, ya que están prohibidas en su nivel de acceso. Para obtener más información, consulte Referencia rápida sobre el acceso de parte interesada.
  • Todos los miembros del proyecto, incluso los del grupo Lectores, pueden enviar correos electrónicos que contengan elementos de trabajo.

Sugerencia

Para notificar un error, un usuario debe tener como mínimo el acceso de parte interesada y el permiso Editar los elementos de trabajo de este nodo establecido en Permitir para la ruta de acceso del área donde se agrega el error. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo

Tipo de elemento de trabajo de error

En la siguiente imagen, se muestra el tipo de elemento de trabajo de error para el proceso Scrum. El tipo de elemento de trabajo de error para los procesos Agile y CMMI realiza un seguimiento de información similar. Está diseñado para aparecer en el trabajo pendiente junto con los requisitos o en el panel de tareas junto con las tareas.

Nota:

Las imágenes que ve desde el portal web pueden diferir de las imágenes que se ven en este artículo. Estas diferencias se derivan de las actualizaciones realizadas en la aplicación web, las opciones que usted o el administrador han habilitado y qué proceso se eligió al crear el proyecto: Agile, Básico, Scrum o CMMI. El proceso Básico está disponible con la Actualización 1 de Azure DevOps Server 2019 y versiones posteriores.

Tipo de elemento de trabajo de error, formulario para el proceso Scrum, Azure DevOps Server 2020 y servicio en la nube.

Captura de pantalla del tipo de elemento de trabajo de error, formulario para el proceso Scrum, Azure DevOps Server 2019 y TFS 2018.

Campos específicos para errores

El tipo de elemento de trabajo de error usa algunos campos específicos de errores. Para capturar la incidencia inicial y las detecciones en curso, use los campos que se describen en la tabla siguiente. Para obtener información sobre los campos específicos del error definidos para el proceso de integración del Modelo de madurez y de capacidad (CMMI), consulte Errores, incidencias y riesgos en Azure Boards. Para obtener información sobre los demás campos, consulte Descripciones de campos para campos predeterminados y de elementos de trabajo usados en plantillas de proceso.

Campo, grupo o pestaña

Uso

Pasos para reproducir
(nombre descriptivo = pasos de reproducción)

Se utiliza para capturar información suficiente para que otros miembros del equipo puedan comprender completamente el defecto del código. Incluya las acciones realizadas para buscar o reproducir el error y el comportamiento previsto.

Información del sistema
Encontrado en compilación

Información sobre el software y la configuración del sistema que sea pertinente para el error y las pruebas que se van a aplicar. Los campos Información del sistema y Encontrado en compilación se rellenan automáticamente al crear un error mediante una herramienta de pruebas. Estos campos especifican información sobre el entorno de software y la compilación donde se produjo el error. Para obtener más información, consulte Probar configuraciones diferentes.

Criterios de aceptación

Proporcione los criterios que se deben cumplir para que se pueda cerrar el error. Antes de que el trabajo comience, describa los criterios de aceptación del cliente con tanta claridad como sea posible. Los equipos deben usar estos criterios como base para las pruebas de aceptación y para evaluar si un elemento se ha completado satisfactoriamente.

Integrado en la compilación

Especifica el nombre de la compilación que incorpora el código que corrige el error. Este campo se debe especificar al resolver el error. En el caso de Azure DevOps en el entorno local, para acceder a un menú desplegable de todas las compilaciones que se han ejecutado, puede actualizar las definiciones del elemento FIELD correspondientes a Encontrado en compilación e Integrado en la compilación para hacer referencia a una lista global. La lista global se actualiza automáticamente con cada compilación que se ejecuta. Para más información, consulte Creación de una consulta basada en campos de integración de compilación y prueba.
Para obtener información sobre cómo definir números de compilación, consulte Opciones de compilación.

Prioridad1

  • 1: el producto requiere una resolución temprana y correcta del elemento de trabajo antes de que se pueda distribuir.
  • 2: el producto requiere una resolución correcta del elemento de trabajo antes de su distribución, pero no es necesario abordarlo inmediatamente.
  • 3: la resolución del elemento de trabajo es opcional en función de los recursos, el tiempo y el riesgo.

Gravedad1

Una clasificación objetiva del impacto de un error o elemento de trabajo en el proyecto o sistema de software. Por ejemplo: si un vínculo remoto de la interfaz de usuario (un evento poco frecuente) hace que una aplicación o una página web se bloquee, puede especificar Gravedad = 2 - Alta y Prioridad = 3. Los valores permitidos y las directrices sugeridas son:

  • 1. Crítico: se debe corregir. Un defecto que provoca la terminación de uno o varios componentes del sistema o del sistema completo, o provoca daños extensos en los datos. Además, no hay métodos alternativos aceptables para lograr los resultados necesarios.
  • 2. Alto: considere la posibilidad de corregirlo. Un defecto que provoca la terminación de uno o varios componentes del sistema o del sistema completo, o provoca daños extensos en los datos. Sin embargo, existe un método alternativo aceptable para lograr los resultados necesarios.
  • 3. Medio: (valor predeterminado) defecto que hace que el sistema genere resultados incorrectos, incompletos o incoherentes.
  • 4. Bajo: defectos menores o estéticos que tienen soluciones alternativas aceptables para lograr los resultados necesarios.

Implementación

El control Implementación admite la presentación de las versiones que contienen los elementos de trabajo y vínculos a estas versiones. Para usar el control, debe habilitar la configuración de la versión. Para más información, consulte Vinculación de elementos de trabajo a versiones más adelante en este artículo.

Desarrollo

El control Desarrollo admite la presentación de los vínculos realizados a objetos de desarrollo y vínculos a ellos. Estos objetos incluyen confirmaciones de Git y solicitudes de incorporación de cambios, o conjuntos de cambios de TFVC y elementos con versiones. Puede definir vínculos desde el elemento de trabajo o desde las confirmaciones, las solicitudes de incorporación de cambios u otros objetos de desarrollo. Para más información, consulte Vinculación de elementos de trabajo al desarrollo más adelante en este artículo.

Notas:

1 Para cambiar la selección del menú o la lista de selección, consulte Personalización de la experiencia de seguimiento del trabajo. El método de personalización depende del modelo de proceso usado por el proyecto.

Elección del modo en que el equipo realiza un seguimiento de los errores

El equipo puede realizar un seguimiento de los errores como requisitos o como tareas. Para admitir la elección del equipo, tenga en cuenta los siguientes factores.

  • Tamaño del equipo. Los equipos más pequeños pueden mantener una superficie ligera mediante el seguimiento de los errores como requisitos.
  • Requisitos de la organización para realizar el seguimiento del trabajo. Si es necesario que el equipo realice un seguimiento de las horas, elija realizar el seguimiento de errores como tareas.
  • Cómo organiza el equipo el trabajo. Si el equipo se basa en el trabajo pendiente para clasificar por orden de prioridad el trabajo y agregar errores, realice un seguimiento de los errores como requisitos.
  • Herramientas que el equipo quiere usar, como el panel Planeamiento, el gráfico de velocidad, la previsión, la acumulación y los planes de entrega. El seguimiento de errores como tareas impide el uso de varias de estas herramientas.

En la tabla siguiente, se resumen las tres opciones que tienen los equipos para realizar el seguimiento de los errores. Para obtener más información y establecer la opción para el equipo, consulte Mostrar los errores en trabajos pendientes y paneles.

Opción

Elija esta opción cuando quiera...

Seguimiento de los errores como requisitos

Nota:

  • Los errores se asignan a la categoría de requisitos.

Seguimiento de los errores como tareas

  • Estimar el trabajo necesario para los errores de forma similar a las tareas
  • Actualizar el estado de los errores en los paneles de tareas de sprint
  • Vincular los errores a los requisitos como elementos secundarios
  • Poder arrastrar y colocar errores en el panel Planeamiento para asignar errores a un sprint

Nota:

  • Los errores se asignan a la categoría de tareas.
  • Los casos de usuario (Agile), los elementos de trabajo pendiente (Scrum) o los requisitos (CMMI) son el tipo de elemento de trabajo primario natural para los errores.
  • Los errores no estarán visibles en los planes de entrega.

Los errores no aparecen en los trabajos pendientes ni los paneles.

  • Administrar los errores mediante consultas

Nota:

  • Los errores están asociados a la categoría de errores y no aparecerán en los trabajos pendientes ni en los paneles.
  • Los errores no estarán visibles en los trabajos pendientes, los paneles, los trabajos pendientes de sprint, los paneles de tareas ni los planes de entrega.
  • No se puede arrastrar y colocar errores en el panel Planeamiento para asignar errores a un sprint.

Personalización del tipo de elemento de trabajo

Puede personalizar el error y otros tipos de elementos de trabajo. O bien, cree tipos personalizados para realizar el seguimiento de las incidencias de software o los comentarios de los clientes. Con todos los tipos de elementos de trabajo, puede personalizar los siguientes elementos:

  • Agregar o quitar campos personalizados
  • Agregar controles personalizados o pestañas personalizadas dentro del formulario de elementos de trabajo
  • Personalizar los estados de flujo de trabajo
  • Agregar reglas condicionales
  • Elegir el nivel de trabajo pendiente en el que aparecen los elementos de trabajo

Antes de personalizar el proyecto, se recomienda que revise Configuración y personalización de Azure Boards.

Para personalizar su proceso en particular, consulte Acerca de la personalización de procesos y de procesos heredados.

Adición o captura de errores

Puede definir errores desde varias herramientas diferentes de Azure DevOps. Entre ellas, se incluyen los trabajos pendientes, los paneles y las herramientas de pruebas.

Sugerencia

De manera predeterminada, el campo Título es el único campo obligatorio al crear un error. Puede agregar rápidamente errores de la misma manera que agrega casos de usuario o elementos de trabajo pendiente mediante Azure Boards. Si desea hacer que algunos campos sean obligatorios, agregue reglas condicionales basadas en un cambio de estado. Para más información, consulte Adición de una regla a un tipo de elemento de trabajo (proceso de herencia).

Adición de un error desde el trabajo pendiente o el panel

Si el equipo decide administrar los errores con requisitos, puede definir errores desde el trabajo pendiente o el panel Kanban. Para más información, consulte Creación del trabajo pendiente en Azure Boards o Uso del panel Kanban.

  • Adición de un error desde el trabajo pendiente

    Captura de pantalla que muestra cómo agregar un error desde el trabajo pendiente, Agregar error.

  • Adición de un error desde el trabajo pendiente

    Captura de pantalla que muestra cómo agregar un error desde el panel Kanban, Agregar error.

Sugerencia

Al agregar un error desde el trabajo pendiente o el panel Kanban, el error se asigna automáticamente a la ruta de acceso del área predeterminada y la ruta de acceso de iteración definidas para el equipo. Para más información, consulte Valores predeterminados del equipo a los que hacen referencia los trabajos pendientes y los paneles.

Adición de un error desde el trabajo pendiente de sprint o el panel de tareas

Si el equipo decide administrar los errores con tareas, puede definir errores desde el panel Kanban, el trabajo pendiente, el trabajo pendiente de sprint o el panel de tareas de sprint. Un error se agrega como elemento secundario a un elemento de trabajo pendiente.

Creación de un error desde una herramienta de pruebas

Las dos herramientas de pruebas que puede usar para agregar errores durante las pruebas incluyen Test Runner en el portal web y la extensión Prueba y comentarios.

Ciclo de vida de los errores y estados de flujo de trabajo

Al igual que con todos los demás tipos de elementos de trabajo, el tipo de elemento de trabajo Error tiene un flujo de trabajo bien definido. Cada flujo de trabajo consta de tres o más estados y un motivo. Los motivos especifican por qué el elemento ha pasado de un estado a otro. Las imágenes siguientes muestran el flujo de trabajo de errores predeterminado definido para los procesos Agile, Scrum y CMMI.

Agile Scrum CMMI
Captura de pantalla de los estados del flujo de trabajo de errores, plantilla de proceso Agile. Captura de pantalla de los estados del flujo de trabajo de errores, plantilla de proceso Scrum. Captura de pantalla de los estados del flujo de trabajo de errores, plantilla de proceso CMMI.

En el caso de los errores de Scrum, cambie el valor de Estado de Confirmado (similar a Activo) a Hecho. En Agile y CMMI, resuelva primero el error y seleccione un motivo que indique que el error se ha corregido. Normalmente, la persona que creó el error comprueba la corrección y actualiza el estado de Resuelto a Cerrado. Si se ha encontrado más trabajo después de que se haya resuelto o cerrado un error, puede reactivarlo estableciendo el estado en Confirmado o Activo.

Nota:

Anteriormente, el tipo de elemento de trabajo de error del proceso Agile tenía una regla que reasignaba el error a la persona que lo creó. Esta regla se ha quitado del proceso predeterminado del sistema. Para restablecer esta automatización, agregue una regla. En el caso de un proceso de herencia, consulte Aplicación de reglas a estados de flujo de trabajo, automatización de la reasignación en función del cambio de estado.

Comprobación de una corrección

Para comprobar una corrección, un desarrollador o un evaluador intenta reproducir el error y buscar otros comportamientos inesperados. Si es necesario, deben reactivar el error.

Al comprobar una corrección de errores, es posible que encuentre que el error no se ha corregido o podría no estar de acuerdo con la resolución. En este caso, debe hablar con la persona que resolvió el error, llegar a un acuerdo y, posiblemente, reactivar el error. Si reactiva un error, incluya los motivos para reactivar el error en la descripción del error.

Cierre de un error

Un error se cierra una vez que se comprueba como corregido. Sin embargo, también puede cerrar un error por uno de los siguientes motivos. Los motivos disponibles para seleccionar dependen del proceso del proyecto y de los estados de transición de error.

Proceso Agile:

  • Diferido: aplazar la corrección del error hasta la próxima versión del producto.
  • Corregido: el error se ha comprobado como corregido.
  • Duplicado: el error realiza un seguimiento de otro error definido actualmente. Puede vincular cada error con el tipo de vínculo Duplicado/Duplicado de y cerrar uno de los errores.
  • Por diseño: la característica funciona según lo diseñado.
  • No se puede reproducir: las pruebas demuestran que el error no se puede reproducir.
  • Obsoleto: la característica del error ya no está en el producto.
  • Copiado en trabajo pendiente: se ha abierto un caso de usuario para realizar el seguimiento del error.

Proceso Scrum:

  • No es un error: se ha comprobado que no es un error.
  • Duplicado: el error realiza un seguimiento de otro error definido actualmente. Puede vincular cada error con el tipo de vínculo Duplicado/Duplicado de y cerrar uno de los errores.
  • Eliminado del trabajo pendiente: se ha comprobado que no es un error. Quite el error del trabajo pendiente.
  • Trabajo finalizado: se ha comprobado que el error está corregido.

Proceso CMMI:

  • Diferido: aplazar la corrección del error hasta la próxima versión del producto.
  • Duplicado: el error realiza un seguimiento de otro error definido actualmente. Puede vincular cada error con el tipo de vínculo Duplicado/Duplicado de y cerrar uno de los errores.
  • Rechazado: se ha comprobado que no es un error.
  • Comprobado: el error se ha comprobado como corregido.

Sugerencia

Una vez que se ha cerrado un error y se ha liberado activamente en las implementaciones, el procedimiento recomendado es no volver a abrirlo nunca debido a la regresión. En su lugar, debe considerar la posibilidad de abrir un nuevo error y vincularlo al error cerrado anterior.

Siempre es una buena idea describir más detalles para cerrar un error en el campo Discusión para evitar confusiones futuras sobre por qué se cerró el error.

Automatización del cierre de errores al combinar solicitudes de incorporación de cambios

Si el equipo usa un repositorio de Git, puede establecer el estado de los errores vinculados y otros elementos de trabajo para que se cierre tras una combinación correcta de las solicitudes de incorporación de cambios. Para obtener más información, consulte Establecer el estado del elemento de trabajo en la solicitud de incorporación de cambios más adelante en este artículo.

Enumeración y evaluación de prioridades de los errores

La mayoría de los equipos, sea cual sea la opción que elijan para realizar el seguimiento de los errores, define una o varias consultas de errores. Con las consultas, puede enumerar errores activos, errores sin asignar, errores obsoletos, tendencias de errores, etc. Después, puede agregar consultas y gráficos de consultas a los paneles del equipo para supervisar el estado y el progreso de los errores.

Consultas de errores

Abra una consulta compartida o use el editor de consultas para crear consultas de errores útiles, como las siguientes opciones:

  • Errores activos por prioridad (State <> Done o State <> Closed)
  • Errores en curso (State = Committed o State = Active)
  • Errores que se van a corregir para una versión de destino (Tags Contains RTM)
  • Errores recientes: errores abiertos en las últimas tres semanas (Created Date > @Today-21)

Una vez que tenga las consultas de interés para su equipo, puede crear gráficos de estado o tendencias. También puede agregar el gráfico que cree a un panel.

Modo de evaluación de prioridades en los resultados de la consulta

Una vez que haya empezado a codificar y probar, querrá celebrar reuniones periódicas de evaluación de prioridades para revisar y clasificar los errores. Normalmente, el propietario del proyecto dirige las reuniones de evaluación de prioridades de los errores. Los responsables del equipo, los analistas de negocios y otras partes interesadas que pueden hablar sobre riesgos específicos del proyecto asisten a las reuniones de evaluación de prioridades.

El propietario del proyecto puede definir una consulta compartida para errores nuevos y reabiertos para enumerar los errores que se van a evaluar.

En la página de resultados de la consulta, puede subir y bajar rápidamente dentro de la lista de elementos de trabajo de errores mediante las flechas arriba y abajo. A medida que revise cada error, puede asignarlo, agregar detalles o establecer la prioridad.

Captura de pantalla de los resultados de la consulta, los errores activos y el panel derecho del modo de evaluación.

Organización y asignación de errores a un sprint

Si el equipo realiza el seguimiento de los errores como requisitos, puede ver la lista de errores activos desde el trabajo pendiente. Con la función de filtro, puede centrarse únicamente en los errores. Desde el trabajo pendiente, también puede realizar las siguientes tareas:

Si el equipo realiza el seguimiento de los errores como tareas, use consultas administradas para enumerar y evaluar las prioridades de los errores. A continuación, dentro de cada sprint, verá los errores asignados al sprint desde el trabajo pendiente de sprint o el Panel de tareas.

Elementos del panel de tareas frente a elementos de la lista de consultas

Es posible que observe y se pregunte por qué los elementos que se muestran en un panel de tareas de sprint pueden diferir de una lista de consultas creada en el trabajo pendiente del sprint correspondiente.

Es posible asignar tareas o errores a una iteración, pero no se pueden vincular a un elemento de trabajo pendiente primario. Estos elementos se mostrarán en la consulta creada, pero quizá no en el panel de tareas. El sistema ejecuta la consulta y, luego, aplica algunos procesos en segundo plano antes de mostrar los elementos del panel de tareas.

Estas razones pueden hacer que los elementos que pertenecen a la categoría de tarea no aparezcan en un panel de tareas o trabajo pendiente de sprint:

Creación de pruebas insertadas vinculadas a errores

Cuando el equipo realiza el seguimiento de los errores como requisitos, puede usar el panel Kanban para agregar pruebas para comprobar las correcciones de los errores.

Captura de pantalla del panel Kanban, 3 columnas que muestran pruebas insertadas agregadas y vinculadas a errores.

Actualización del estado del error

Para actualizar el estado del error, arrastre y coloque los errores en una nueva columna de un panel.

Personalización del panel para realizar el seguimiento de los estados intermedios

Puede agregar columnas intermedias para realizar el seguimiento del estado de los errores en el panel. También puede definir consultas que filtren según el estado de una columna del panel. Para más información, consulte los siguientes artículos.

Automatización de la reasignación de errores en función del estado de flujo de trabajo

Para automatizar acciones determinadas, agregue reglas personalizadas al tipo de elemento de trabajo Error. Por ejemplo, agregue una regla como se muestra en la imagen siguiente. Esta regla especifica que se reasigna un error a la persona que abrió el error una vez resuelto. Normalmente, esa persona comprueba que se haya corregido el error y cierra el error. Para más información, consulte Aplicar reglas a estados de flujo de trabajo (proceso de herencia).

Captura de pantalla de la regla definida para reasignar el error en función del estado resuelto.

Establecer el estado del elemento de trabajo en la solicitud de incorporación de cambios

Al crear una solicitud de incorporación de cambios, puede establecer el valor del estado de los elementos de trabajo vinculados en la descripción. Siga la sintaxis: {state value}: #ID. Al combinar la solicitud de incorporación de cambios, el sistema lee la descripción y actualiza el estado del elemento de trabajo. En el siguiente ejemplo, establecemos los elementos de trabajo 300 y 301 en Resuelto, y los elementos 323 y 324 en Cerrado.

Captura de pantalla que muestra cómo establecer el estado del elemento de trabajo en una solicitud de incorporación de cambios.

Nota:

Esta característica requiere la instalación de la Actualización 2020.1 de Azure DevOps Server. Para obtener más información, consulte Notas de la versión de la Actualización 1 RC1 de Azure DevOps Server 2020, paneles.

Integración en Azure DevOps

Uno de los métodos que usa Azure DevOps para admitir la integración es vincular objetos a otros objetos. Además de vincular elementos de trabajo a elementos de trabajo, también puede vincular elementos de trabajo a otros objetos. Puede vincular a objetos como compilaciones, versiones, ramas, confirmaciones y solicitudes de incorporación de cambios, como se muestra en la siguiente imagen.

Imagen conceptual que muestra los tipos de vínculo usados para vincular elementos de trabajo a objetos de compilación y versión.

Puede agregar un vínculo desde el elemento de trabajo o desde los objetos de compilación y versión.

El control Desarrollo admite la presentación de los vínculos realizados a compilaciones, confirmaciones de Git y solicitudes de incorporación de cambios, y vínculos a ellos. O bien, cuando se usa un repositorio de TFVC, se admiten vínculos a conjuntos de cambios y elementos con versiones. Al elegir el vínculo se abre el elemento correspondiente en una nueva pestaña del explorador. Para más información, vea Impulso del desarrollo de Git desde un elemento de trabajo.

Control Desarrollo en el formulario de elementos de trabajo con vínculos de ejemplo a compilaciones, solicitudes de incorporación de cambios y confirmaciones.

El control Implementación admite la presentación de las versiones que contienen los elementos de trabajo y vínculos a estas versiones. Por ejemplo, la imagen siguiente muestra varias versiones que contienen vínculos al elemento de trabajo actual. Puede expandir cada versión para ver detalles sobre cada fase. Puede elegir el vínculo de cada versión y fase para abrir la versión o fase correspondientes. Para más información, vea Vinculación de elementos de trabajo a implementaciones.

Control Implementación en el formulario de elementos de trabajo con versiones de ejemplo.

Las canalizaciones se suelen definir para ejecutarse automáticamente cuando se produce una nueva confirmación en un repositorio de Git. Los elementos de trabajo asociados a las canalizaciones de confirmación se mostrarán como parte de la ejecución de canalización si personaliza la configuración de la canalización. Para obtener más información, consulte Personalización de la canalización.

Captura de pantalla de la configuración de la canalización, vincular automáticamente los elementos de trabajo de esta ejecución desde la rama seleccionada.

Creación o edición de un elemento de trabajo tras un error de compilación

Si usa canalizaciones clásicas (no YAML), puede crear elementos de trabajo en un error de compilación. Para más información, consulte Opciones de compilación, crear un elemento de trabajo en caso de error.

Puede realizar un seguimiento del estado de los errores, las asignaciones y las tendencias mediante consultas con las que, a continuación, puede crear gráficos y agregarlos a un panel. Por ejemplo, estos son dos ejemplos que muestran tendencias de errores activos por estado y errores activos por prioridad a lo largo del tiempo.

Captura de pantalla de dos gráficos de consultas de errores activos, tendencias de errores por estado y por prioridad.

Para obtener más información sobre consultas, gráficos y paneles, consulte Seguimiento del trabajo mediante consultas administradas en Azure Boards, Seguimiento del progreso con gráficos basados en consultas de estado y tendencias y Adición, cambio de nombre y eliminación de paneles en Azure DevOps.

Uso de vistas de Analytics y el servicio Analytics para crear informes de errores

El servicio Analytics es la plataforma de informes de Azure DevOps, que reemplaza la plataforma anterior basada en SQL Server Reporting Services.

Las vistas de Analytics proporcionan filtros creados previamente para ver los elementos de trabajo. Se admiten cuatro vistas de Analytics para la generación de informes de errores. Puede usar estas vistas tal y como están definidas o editarlas para crear una vista personalizada filtrada.

  • Errores: todo el historial por mes
  • Errores: últimas 26 semanas
  • Errores: últimos 30 días
  • Errores: hoy

Para obtener más información sobre el uso de vistas de Analytics, consulte Acerca de las vistas de Analytics y Creación de un informe de errores activos en Power BI basado en una vista de Analytics personalizada.

Puede usar Power BI para crear informes más complejos que lo que puede obtener de una consulta. Para más información, consulte Conexión con el conector de Power BI Data.

Informes de errores predefinidos de SQL Server

Los siguientes informes son compatibles con los procesos Agile y CMMI.

Estos informes requieren que tenga SQL Server Analysis Services y SQL Server Reporting Services configurados para el proyecto. Para obtener información sobre cómo agregar informes de SQL Server para un proyecto, consulte Adición de informes a un proyecto.

Extensiones de Marketplace

Hay varias extensiones de Marketplace relacionadas con errores. Consulte Marketplace para Azure DevOps.

Para obtener más información sobre las extensiones, consulte Introducción a las extensiones para Azure Boards.

Pasos siguientes

Usar plantillas para agregar y actualizar elementos de trabajo

Trabajo pendiente y panel Kanban

Panel kanban

Trabajo pendiente de sprint y panel de tareas

Integración en Azure DevOps

Recursos del sector