Administración de los tipos de elementos de trabajo de proceso de Scrum y flujo de trabajo
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Para planear un proyecto de software y realizar un seguimiento de los defectos de software mediante Scrum, los equipos usan los tipos de elemento de trabajo pendiente del producto (PBI) y error (WIT). Para comprender mejor la cartera de características, los escenarios o las experiencias de usuario, los propietarios del producto y los administradores de programas pueden asignar PBI y errores a características. Cuando los equipos trabajan en sprints, definen tareas que se vinculan automáticamente a PBI y errores.
Nota:
Si no está familiarizado con el proceso de Scrum, revise Acerca de sprints, Scrum y administración de proyectos.
Los evaluadores pueden crear y ejecutar casos de prueba y crear errores para realizar un seguimiento de los defectos de código mediante el portal web o Microsoft Test Manager. Los impedimentos permiten realizar un seguimiento de los problemas de bloqueo.
Definición de los PBI y los errores
Al definir un elemento de trabajo pendiente de producto, céntrese en el valor que obtienen los clientes y evite descripciones de cómo desarrolla el equipo la característica. El propietario del producto puede asignar prioridades al trabajo pendiente de este basándose en el valor empresarial de cada elemento, el esfuerzo y la dependencia relativa en otros elementos de trabajo pendiente. A medida que los requisitos comerciales evolucionan, también lo hace el trabajo pendiente del producto. Normalmente, los equipos especifican detalles únicamente para los elementos de prioridad máxima o para los elementos asignados al sprint actual y siguiente.
Puede crear los PBI y errores desde el panel para agregar de forma rápida en la página de trabajo pendiente del producto.
Después, puede abrir cada PBI o error para proporcionar más detalles y calcular el esfuerzo. Además, al dar prioridad a los PBI y errores en la página de trabajo pendiente (que se captura en el campo Prioridad del trabajo pendiente), los propietarios del producto pueden indicar qué elementos deben tener prioridad más alta.
Al definir el esfuerzo de para PBIs y errores, puede usar los gráficos de velocidad y características de previsión para calcular los futuros sprints o esfuerzos de trabajo. Al definir la valor empresarial, los propietarios de productos pueden especificar prioridades independientes de la clasificación de la pila de trabajos pendientes modificables.
Use los siguientes campos y campos que se usan en los tipos de elementos de trabajo comunes al completar el formulario de elemento de trabajo. Para obtener más información, consulte Administrar errores.
Campo/pestaña
Uso
Estime el trabajo necesario para completar un PBI usando cualquier unidad de medida que el equipo prefiera, como los grados de dificultad del caso o el tiempo. Se requiere un valor numérico.
Los gráficos de velocidad y las herramientas de previsión de Agile hacen referencia a los valores de este campo. Para obtener más información, vea las notas del producto Estimaciones.
Especifique un número que capture el valor relativo de un PBI en comparación con otros PBI. Cuanto mayor sea el número, mayor será el valor empresarial.
Proporcione suficientes detalles para calcular la cantidad de trabajo necesaria para implementar el elemento. Céntrese en quién utilizará la característica, qué se desea lograr y por qué. No describa el modo en que se debe desarrollar la característica. Proporcione detalles suficientes para que el equipo pueda escribir tareas y casos de prueba para implementar el elemento.
Defina el significado de "Listo" al describir los criterios que el equipo debe usar para comprobar si el PBI o la corrección de errores se implementó completamente.
Antes de que el trabajo comience en un PBI o un error, describa los criterios de aceptación del cliente con tanta claridad como sea posible. Las conversaciones entre el equipo y los clientes para determinar los criterios de aceptación ayudan a asegurarse de que todo el equipo entienda cómo cumplir las expectativas de los clientes. Los criterios de aceptación se pueden usar como base para las pruebas de aceptación, con el fin de que el equipo pueda evaluar más eficazmente si un elemento se ha completado satisfactoriamente o no.
Capturar comentarios en la sección Discusión
Use la sección Discusión para agregar y revisar los comentarios realizados sobre el trabajo que se está realizando.
La barra de herramientas del editor de texto enriquecido se muestra debajo del área de entrada de texto. Aparece cuando se selecciona cada cuadro de texto que admite el formato de texto.
Nota:
No hay un campo de elemento de trabajo Discusión. Para consultar elementos de trabajo que cuentan con comentarios en el área Discusión, deberá filtrar por el campo Historial. El contenido completo del texto que se escribió en el cuadro de texto Discusión se agrega al campo Historial.
Mencionar a alguien, un grupo, un elemento de trabajo o una solicitud de incorporación de cambios
Para abrir un menú de entradas recientes que ha hecho para mencionar a alguien, vincular a un elemento de trabajo o vincular a una solicitud de incorporación de cambios, seleccione 
, 
o introduzca @, # o !.
Escriba un nombre o número y los filtros de lista de menús para que coincidan con la entrada. Elija la entrada que quiere agregar. Para incluir un grupo en la discusión, escriba @ y el nombre del grupo, como un equipo o un grupo de seguridad.
Edición o eliminación de comentarios
Para editar o eliminar cualquiera de los comentarios de la discusión, elija 
Editar o el icono de acciones 
y, después, elija Eliminar.
Nota:
La edición y eliminación de comentarios requiere Azure DevOps Server 2019 Update 1 o una versión posterior.
Después de actualizar el comentario, elija Actualizar. Para eliminar el comentario, confirme que quiere eliminarlo.
En la pestaña Historial del formulario del elemento de trabajo se mantiene un registro de auditoría completo de todos los comentarios editados y eliminados.
Importante
En el caso de Azure DevOps Server local, debe configurar un servidor SMTP para que los miembros del equipo reciban notificaciones.
Agregar una reacción a un comentario
Agregue una o varias reacciones a un comentario seleccionando el icono sonriente en la esquina superior derecha de cualquier comentario. O bien, elija entre los iconos situados en la parte inferior de un comentario junto a las reacciones existentes. Para eliminar la reacción, elija la reacción en la parte inferior del comentario. En la siguiente imagen se muestra un ejemplo de la experiencia de agregar una reacción y la visualización de reacciones en un comentario.
Guardar un comentario sin guardar el elemento de trabajo
Nota:
Esta característica está disponible a partir de Azure DevOps Server 2022.1.
Si solo tiene permisos para agregar a la discusión de un elemento de trabajo, puede hacerlo guardando comentarios. Este permiso se controla mediante nodos de ruta de área y el permiso Editar comentarios de elemento de trabajo de este nodo. Para obtener más información, vea Establecimiento de permisos de seguimiento de trabajo, Creación de nodos secundarios, Modificación de elementos de trabajo en un área o ruta de acceso de iteración.
Una vez guardados los comentarios, no es necesario guardar el elemento de trabajo.
Nota:
Al guardar los cambios realizados en el control Discusión, solo se guarda el comentario. No se han definido reglas de elementos de trabajo para la ejecución del tipo de elemento de trabajo.
Seguimiento del progreso
A medida que avanza el trabajo, el campo Estado cambia para actualizar el estado. De manera opcional, puede especificar un motivo. Los campos de estado y motivo aparecen en el formulario de elemento de trabajo en el área de encabezado.
Estados del flujo de trabajo de Scrum
Al actualizar el estado, los equipos saben qué elementos son nuevos, en curso o completados. La mayoría de los tipos de elemento de trabajo (WIT) admiten la transición tanto hacia delante como hacia atrás desde cada estado del flujo de trabajo. Estos diagramas muestran los principales estados de progresión y regresión de los WIT PBI, Error y Tarea.
| Elemento de trabajo pendiente del producto | Error | Tarea |
|---|---|---|
|
|
|
Progresión típica del flujo de trabajo para los PBI y los errores:
- El propietario del producto crea un PBI o un evaluador crear un error con el estado Nuevo con el motivo predeterminado, Nuevo elemento de trabajo pendiente.
- El propietario del producto mueve el elemento a Aprobado cuando esté lo suficientemente descrito y esté listo para que el equipo estime el nivel de trabajo. Casi siempre, los elementos cerca de la parte superior de Trabajo pendiente se encuentran en el estado Aprobado, mientras que los elementos del centro y la parte inferior se encuentran en estado Nuevo.
- El equipo actualiza el estado a Confirmado cuando decide confirmar trabajar en ello durante el sprint.
- El elemento se mueve al estado Listo cuando el equipo ha completado todas sus tareas asociadas y el propietario del producto acepta que se ha implementado según los criterios de aceptación.
Actualizar el estado con Kanban o Taskboards
Teams puede usar el Panel Kanban para actualizar el estado de los PBIs y el sprint Taskboard para actualizar el estado de las tareas. Al arrastrar elementos a una nueva columna de estado, se actualizan los campos Estado y Motivo.
Puede personalizar el panel Kanban para admitir máscarriles o columnas. Para otras opciones de personalización, consulte Personalización de la experiencia de seguimiento del trabajo.
Asignar PBI a características
Cuando administre un conjunto de productos o de experiencias de usuario, quizás desee ver el ámbito y el progreso del trabajo en la cartera de producto. Para ello, defina características y asigne PBIs a las características.
Use los trabajos pendientes en cartera para explorar en profundidad los trabajos pendientes y ver el nivel de detalle que quiera. Además, puede usar los trabajos pendientes en cartera para ver una consolidación del trabajo en curso de varios equipos al configurar una jerarquía de equipos.
Definir tareas
Cuando el equipo administra su trabajo en sprints, puede usar la página de trabajo pendiente del sprint para dividir el trabajo que se va a realizar en tareas distintas.
Asigne un nombre a la tarea y calcule el trabajo que tarda.
Teams puede prever el trabajo y definir tareas al principio de cada sprint, y cada miembro del equipo completa un subconjunto de esas tareas. Las tareas pueden incluir el desarrollo, las pruebas y otros tipos de trabajos. Por ejemplo, un desarrollador puede definir tareas para implementar PBI y un evaluador puede definir tareas para escribir y ejecutar casos de prueba.
Cuando los equipos calculan el trabajo en horas o días, definen las tareas y los campos Trabajo restante y Actividad (opcionales).
Campo/pestaña
Uso
Indique cuántas horas o días de trabajo quedan para completar una tarea. A medida que el trabajo progresa, debe actualizar este campo. Se usa para calcular los gráficos de capacidad, el gráfico de evolución del sprint y el informe de Evolución del sprint (Scrum).
Si se divide una tarea en subtareas, especifique el trabajo restante solo para las subtareas. Puede especificar el trabajo en la unidad de medida que el equipo elija.
Seleccione el tipo de actividad que esta tarea representa cuando el equipo estima la capacidad de sprint por actividad.
Realizar el seguimiento del progreso de la prueba
Prueba de los PBI
Desde el portal web o Test Manager, puede crear casos de prueba que se vinculan automáticamente a un PBI o a un error. O bien, puede vincular un PBI a un caso de prueba desde 
(pestaña Vínculos).
El caso de prueba contiene varios campos, muchos de los cuales se automatizan y se integran con Test Manager y el proceso de compilación. Para una descripción de cada campo, consulte Consulta basada en campos de integración de compilación y pruebas.
(la pestaña Vínculos) captura los vínculos a todos los PBI y errores en un caso de prueba. Al vincular PBI y errores a casos de prueba, el equipo puede realizar un seguimiento del progreso realizado en las pruebas de cada elemento.
Realizar el seguimiento de los defectos de código
Puede crear errores desde el portal web, Visual Studio o al hacer pruebas con Test Manager.
Definiciones de campos de seguimiento de trabajo comunes
Los siguientes campos y las pestañas aparecen en la mayoría de los elementos de trabajo. Cada pestaña se usa para realizar un seguimiento de información específica, como 
Historial, Vínculos o 
Datos adjuntos. Estas tres pestañas proporcionan un historial de cambios, una vista de los elementos de trabajo vinculados y la capacidad para ver y adjuntar archivos.
El único campo obligatorio para todos los tipos de elementos de trabajo es Título. Al guardar un elemento de trabajo, el sistema le asigna un identificador único. El formulario resalta el campo obligatorio en amarillo. Para obtener información sobre otros campos, vea Índice de campos de elementos de trabajo.
Nota:
Es posible que se requieran campos adicionales en función de las personalizaciones realizadas en el proceso y el proyecto.
Campo/pestaña
Uso
Escriba una descripción de 255 caracteres como máximo. Siempre puede modificar el título más tarde.
Asigne el elemento de trabajo al miembro del equipo responsable de realizar el trabajo.
Cuando se crea el elemento de trabajo, el estado cambia de forma predeterminada al primer estado del flujo de trabajo. A medida que el trabajo progresa, debe actualizarlo para reflejar el estado actual.
Utilice la configuración predeterminada primero. Actualice el campo cuando cambie el estado. Cada estado se asocia a un motivo predeterminado.
Elija la ruta de acceso de área asociada al producto o el equipo, o déjela en blanco hasta que se asigne durante una reunión de planeación. Para cambiar la lista desplegable de áreas, vea Definición de rutas de acceso de área y asignación a un equipo.
Elija el sprint o la iteración en la que debe completarse el trabajo o déjela en blanco y asígnela más tarde, durante una reunión de planeación. Para cambiar la lista desplegable de iteraciones, vea Definición de rutas de acceso de iteración (sprints) y configuración de iteraciones de equipo.
Revise el registro de auditoría que captura el sistema y capture información adicional.
Cada vez que se actualice el elemento de trabajo, se agregará información al historial. El historial incluye la fecha del cambio, el autor del cambio y los campos que se modificaron. También puede agregar texto con formato al campo Historial.
Agregue todos los tipos de vínculos como, por ejemplo, hipervínculos, conjuntos de cambios, archivos de código fuente, etc.
En esta pestaña también se enumeran todos los vínculos definidos para el elemento de trabajo.
Para compartir información más detallada, agregue archivos al elemento de trabajo, como subprocesos de correo electrónico, documentos, imágenes, archivos de registro u otros tipos de archivo.
Personalizar tipos de elemento de trabajo
Para la mayoría de los tipos de elementos de trabajo, puede agregar campos, cambiar el flujo de trabajo, agregar reglas personalizadas y agregar páginas personalizadas al formulario de elemento de trabajo. También puede agregar tipos de elementos de trabajo personalizados. Para obtener más información, consulte Personalización de un proceso de herencia.
Para la mayoría de los tipos de elementos de trabajo, puede agregar campos, cambiar el flujo de trabajo, agregar reglas personalizadas y agregar páginas personalizadas al formulario de elemento de trabajo. También puede agregar tipos de elemento de trabajo personalizados. Para más información, vea Personalización de un proceso de herencia o Personalización del modelo de proceso XML local en función del modelo de proceso usado por el proyecto.
Seguimiento de los impedimentos
Use el tipo de elemento de trabajo Impedimento para realizar un seguimiento de los eventos que pueden bloquear el progreso o enviar un PBI. Use el tipo de elemento de trabajo Error exclusivamente para realizar un seguimiento de los defectos de código.
Puede agregar un impedimento desde el widget Nuevo elemento de trabajo agregado a un panel de equipo, o desde el menú Nuevo de la página Consultas.
Los elementos de trabajo que agregue desde el widget se limitan automáticamente al área predeterminada del equipo y las rutas de acceso de iteración. Para cambiar el contexto del equipo, vea Cambio del contexto del equipo.
Orden de lista de trabajos pendientes
El campo Prioridad del trabajo pendiente se usa para realizar un seguimiento de la clasificación relativa de los PBI, los errores, las características o las epopeyas. Sin embargo, de forma predeterminada no aparece en el formulario del elemento de trabajo. La secuencia de elementos en la página del trabajo pendiente del producto se determina en función de dónde se hayan agregado o movido los elementos en la página. A medida que arrastra elementos, un proceso en segundo plano actualiza este campo.
Artículos relacionados
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de