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

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? ¿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. Querrá administrar los defectos de código de maneras que se alineen con sus prácticas ágiles.

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 Acerca de los elementos de trabajo y los tipos de elementos de trabajo.

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

• 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

Requisitos previos

• Acceso al proyecto: Ser añadido a un proyecto.

• Permisos:

  • Tener los permisos Ver los elementos de trabajo en este nodo y Editar elementos de trabajo en este nodo establecidos en Permitir. De forma predeterminada, el grupo Colaboradores dispone de estos permisos. Para obtener más información, consulte Establecimiento de permisos para el seguimiento del trabajo.

  • Para agregar nuevas etiquetas a elementos de trabajo, debe tener acceso Básico o superior y debe tener el permiso Crear nueva definición de etiqueta establecido en Permitir. De forma predeterminada, el grupo Colaboradores tiene este permiso.

    Nota:

    Las partes interesadas no pueden agregar nuevas etiquetas, incluso si el permiso se establece explícitamente, debido a su nivel de acceso. Para obtener más información, consulte Referencia rápida sobre el acceso de parte interesada.

• Enviar elementos de trabajo por correo electrónico: todos los miembros del proyecto, incluidos los del grupo Lectores , pueden enviar correos electrónicos que contengan elementos de 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 ágiles y de Integración de modelo de madurez y de capacidad (CMMI) realiza un seguimiento de información similar. Aparece en el trabajo pendiente junto con los requisitos o en el panel de tareas junto con las tareas.

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 sistemaSe encuentra en la 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 Configuración de canalizaciones clásicas.

---

Prioridad¹

• 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.

---

Gravedad¹

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 (una experiencia grave para el cliente), 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. 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. 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.

---

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

¹ 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.
• Organización del trabajo de su equipo. 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

• Clasificar por orden de prioridad los errores junto con los requisitos
• Estimar el esfuerzo de los errores para la previsión
• Actualizar el estado de los errores en el panel
• Incluir los errores en gráficos de velocidad y diagramas de flujo acumulativos
• Poder usar la herramienta Previsión para admitir la planificación de sprints
• Arrastre los errores al panel Planificación para asignarlos a un sprint
• Ver errores en los planes de entrega

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
• Arrastre los errores al panel Planificación para asignarlos 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 Planificación 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. Para 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 Acerca de la configuración y personalización de Azure Boards.

Adición o captura de errores

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

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. Para obtener más información, consulte Creación del trabajo pendiente del producto o Uso del panel.

• Adición de un error desde el trabajo pendiente

  

• Adición de un error desde el panel

  

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, 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.

• Adición de un error secundario vinculado desde el trabajo pendiente de sprint

  Un error se agrega de la misma manera que se agrega una tarea a un trabajo pendiente de sprint. Para más información, consulte Adición de tareas a elementos de trabajo pendiente para admitir el planeamiento de sprints.

  

• Adición de un error secundario vinculado desde el panel

  Un error se agrega de la misma manera que se agrega una tarea a un elemento de trabajo pendiente. Para más información, consulte Adición de tareas o elementos secundarios como elementos de lista de comprobación.

  

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.

• Test Runner: al ejecutar pruebas manuales, puede elegir Crear error. Para más información, consulte Ejecutar pruebas manuales.

  

• Extensión Prueba y comentarios: al ejecutar pruebas exploratorias, puede elegir Crear error o Crear tarea. Para obtener más información, consulte Pruebas exploratorias con 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

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 encuentra más trabajo después de resolver o cerrar un error, vuelva a activarlo estableciendo el Estado en Confirmado o Activo.

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

Cierra un error cuando un miembro del equipo lo comprueba como corregido. Sin embargo, también puede cerrar un error por uno de los siguientes motivos. Los motivos disponibles 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.

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.

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. 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, como 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 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.

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:

• Organización de errores en el trabajo pendiente Clasificación por orden de prioridad con otros elementos. La clasificación por orden de prioridad está deshabilitada al habilitar el filtrado.
• Asignar errores a un sprint desde el trabajo pendiente mediante el panel Planificación.
• Asignar errores a características u otros elementos de trabajo pendiente en cartera mediante el panel Asignación.
• Ver el resumen del trabajo en los elementos de trabajo pendiente en cartera

Si el equipo realiza el seguimiento de los errores como tareas, use consultas administradas para enumerar y evaluar las prioridades de los errores. 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:

• La tarea o el error no se han vinculado a un elemento de trabajo pendiente primario. Solo aparecen en la página de trabajo pendiente de sprint los errores y las tareas que ha vinculado a un elemento de trabajo pendiente principal (Scrum), un caso de usuario (Agile) o un requisito (CMMI) cuya ruta de acceso de iteración esté establecida en el sprint.
• La tarea o el error son un elemento primario de otra tarea o error, o el caso del usuario es un elemento primario de otro caso de usuario. Si ha creado una jerarquía de tareas, errores o casos de usuario, solo aparecen las tareas de nivel secundario o los casos de nivel secundario en la parte inferior de la jerarquía. Para obtener más información, consulte Solucionar problemas de problemas de reordenación y anidamiento.
• El elemento primario vinculado de una tarea o un error se corresponde con un elemento de trabajo pendiente definido para otro equipo. O bien, la ruta de acceso del área del elemento de trabajo pendiente primario de la tarea o el error difiere de la ruta de acceso del área de la tarea o el error.

Creación de pruebas insertadas vinculadas a errores

Cuando el equipo realiza el seguimiento de los errores como requisitos, puede usar el panel para agregar pruebas para comprobar las correcciones de los 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.

• Si el equipo realiza el seguimiento de los errores como requisitos, use el panel como se muestra en la siguiente imagen. Para obtener más información, consulte Actualización del estado del elemento de trabajo.

  

• Si el equipo realiza el seguimiento de los errores como tareas, use el Panel de tareas. Para más información, consulte Actualización y supervisión del panel de tareas.

  

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. Vea los siguientes artículos para más información:

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 cuando un miembro del equipo lo resuelve. 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).

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

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.

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

Vinculación de elementos de trabajo al desarrollo

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. 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.

Vinculación de elementos de trabajo a versiones

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.

Vinculación de elementos de trabajo a ejecuciones de canalización

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.

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 obtener más información, consulte Creación de un elemento de trabajo en caso de error.

Supervisión del estado de los errores, las asignaciones y las tendencias

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.

Para obtener más información sobre consultas, gráficos y paneles, consulte consultas administradas, gráficos y paneles.

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

Artículos relacionados

• Eliminación, supresión o restauración de elementos de trabajo
• Copiar o clonar un elemento de trabajo

Trabajo pendiente y panel de productos

• Uso de trabajos pendientes para administrar proyectos
• Crear el trabajo pendiente
• Definir las características y epopeyas, organizar los trabajos pendientes en cartera y del producto en Azure Boards
• Organizar el trabajo pendiente y asignar elementos de trabajo secundarios a los elementos principales
• Filtrado interactivo de trabajos pendientes, paneles, consultas y planes en Azure Boards
• Previsión del trabajo pendiente

Placa

• Acerca de los paneles y Kanban
• Uso del panel
• Volver a ordenar tarjetas
• Adición de tareas o elementos secundarios como listas de comprobación

Trabajo pendiente de sprint y panel de tareas

• Obtenga más información sobre los procedimientos recomendados de Scrum.
• Asignar elementos de trabajo pendiente a un sprint
• Adición de tareas
• Actualización del Panel de tareas

Integración en Azure DevOps

• Vincular casos de usuario, incidencias, errores y otros elementos de trabajo en Azure Boards
• Seguimiento de los cambios realizados en un caso de usuario, un error u otro elemento de trabajo o solicitud de incorporación de cambios
• Configuración de números de compilación o ejecución

Recursos del sector

• Deuda técnica buena y mala (y cómo ayuda TDD) por Henrik Kniberg
• Administración de deuda técnica publicada por Sven Johann y Eberhard Wolff