Tipos de elementos de trabajo y flujo de trabajo de procesos de CMMI en Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Los equipos usan los tipos de elemento de trabajo (WIT) proporcionados con el proceso de MSF para CMMI Process Improvement 2015 (CMMI) para planear y hacer un seguimiento del progreso de los proyectos de software. Los equipos definen requisitos para administrar el trabajo pendiente y, a continuación, mediante el panel kanban, hacen un seguimiento del progreso actualizando el estado de los requisitos.
Para comprender mejor una cartera de requisitos, los propietarios del producto pueden asignar requisitos a las características. Cuando los equipos trabajan en iteraciones, definen tareas que se vinculan automáticamente a los requisitos.
Con Microsoft Test Manager y el portal web, los evaluadores crean y ejecutan casos de prueba y definen errores para realizar un seguimiento de los defectos de código.
Para admitir los procesos adicionales de CMMI, los equipos pueden realizar el seguimiento de solicitudes de cambio, riesgos, problemas y notas capturadas en las reuniones de revisión. Si no está familiarizado con el proceso de CMMI, revise la sección Planeación y seguimiento del trabajo con CMMI para empezar.
Definición de los requisitos
Cree los requisitos desde el panel de adición rápida en la página de trabajo pendiente del producto. Después, puede abrir cada requisito para proporcionar más detalles y estimar su tamaño.
O bien, puede agregar requisitos de forma masiva mediante un archivo cvs.
Importante
La integración de Microsoft Project y el comando TFSFieldMapping no son compatibles con:
- Visual Studio 2019 y Azure DevOps Office Integration 2019.
- Azure DevOps Server 2019 y versiones posteriores, incluido Azure DevOps Services.
Hay total compatibilidad con la integración de Microsoft Excel y se admite la importación y actualización masiva de elementos de trabajo. Entre las alternativas a usar Microsoft Project, están las siguientes:
- Planes de entrega.
- Una extensión de Marketplace, como Project Connect o GANTT chart.
Los requisitos especifican las funciones y elementos de producto que deben crear los equipos. Los propietarios del producto suelen definir y establecer el rango en la pila de los requisitos en la página de trabajo pendiente del producto. A continuación, el equipo establece el tamaño del trabajo necesario para entregar los elementos de prioridad máxima.
Use las siguientes instrucciones y las que se proporcionan para los campos que se usan en común en los tipos de elementos de trabajo al rellenar el formulario. Para más información, consulte Planeación de un proyecto.
Campo
Uso
Proporcione detalles suficientes para calcular la cantidad de trabajo que será necesario para implementar el requisito. Céntrese en quién utilizará el requisito, qué se desea lograr y por qué. No describa el modo en que se debe desarrollar el requisito. Proporcione detalles suficientes para que el equipo pueda escribir tareas y casos de prueba para implementar el elemento.
En los campos HTML, puede agregar texto enriquecido e imágenes.
El impacto en el cliente si no se implementa este requisito. Se podrán incluir detalles del modelo de Kano para indicar si este requisito forma parte de la categoría de requisitos sorpresa, obligatorios u obvios. Esta información se captura en el campo HTML de texto enriquecido que corresponde a Valoración del impacto.
Tipo de requisito (obligatorio)
El tipo de requisito que se va a implementar. Puede especificar uno de los siguientes valores:
- Objetivo del negocio
- Característica (valor predeterminado)
- Funcional
- Interface
- Operativos
- Calidad de servicio
- Seguridad
- Escenario
- Seguridad
Área del valor de cliente dirigida por la epopeya, la característica, el requisito o el elemento de trabajo pendiente. Estos valores incluyen:
- De arquitectura: servicios técnicos para implementar las características de negocio que ofrecen soluciones
- Negocio: servicios que cumplen las necesidades de los clientes o de las partes interesadas, que ofrecen directamente el valor de cliente para satisfacer las necesidades empresariales (valor predeterminado)
Estime el trabajo necesario para completar un requisito mediante la unidad de medida numérica que el equipo prefiera. Al definir el Tamaño para los requisitos, los equipos pueden usar las herramientas de gráficos de velocidad y previsión para estimar futuras iteraciones o esfuerzos de trabajo. El diagrama de flujo acumulado Kanban hace referencia a los valores de este campo. Para más información, consulte las notas del producto Estimaciones.
La cantidad de trabajo estimada requerida para completar una tarea. Normalmente, este campo no cambia una vez asignado.
Puede especificar el trabajo en horas o en días. No hay unidades de tiempo inherentes asociadas a este campo.
las fechas en las que se iniciará o finalizará el trabajo.
Prioridad (obligatorio)
Una calificación subjetiva del requisito respecto al negocio. Los valores permitidos son:
- 1: el producto no se puede distribuir sin el elemento.
- 2: (predeterminado) el producto no se puede distribuir sin el elemento, pero no es necesario solucionarlo inmediatamente.
- 3: la implementación del elemento es opcional en función de los recursos, el tiempo y el riesgo.
Evaluación de prioridades (obligatorio)
Indica el tipo de decisión de evaluación de prioridades que está pendiente para el elemento de trabajo. Use este campo cuando el elemento de trabajo esté en el estado Propuesto y especifique uno de los siguientes valores: Pendiente (valor predeterminado), Más información, Información recibida y Evaluado.
Indica si un miembro del equipo no puede progresar hacia la implementación de un requisito o tarea, o la resolución de un error, problema, solicitud de cambio o riesgo. Si se ha detectado un problema al realizar el seguimiento de un problema de bloqueo, puede crear un vínculo al problema. Puede especificar Sí o No.
Confirmado (obligatorio)
Indica si el requisito se confirma o no en el proyecto. Puede especificar Sí o No (predeterminado).
número de compilación del producto que incorpora el requisito o la solicitud de cambio o que corrige un error.
Prueba de aceptación de usuario (obligatorio)
Estado de la prueba de aceptación del usuario para un requisito. Puede especificar uno de los siguientes valores:
- Correcto
- Error
- No está listo (valor predeterminado)
- Ready
- Se omitió
- Información recibida
Especifique No está listo cuando el requisito esté en el estado Activo y Listo cuando el requisito esté en el estado Resuelto.
los nombres de los miembros del equipo que están familiarizados con el área de cliente que representa este requisito.
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 del trabajo
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 de flujo de trabajo de CMMI
Estos diagramas muestran los principales estados de progresión y regresión de los WIT de Requisito, Error y Tarea.
| Requisito | Error | Tarea |
|---|---|---|
 |
 |
 |
La progresión típica de un flujo de trabajo de un requisito es:
- El propietario del producto crea un requisito con el estado Propuesto con el motivo predeterminado, Nuevo requisito.
- El propietario del producto actualiza el estado a Activo cuando empieza a trabajar para implementarlo.
- El equipo actualiza el estado a Resuelto cuando el desarrollo de código finaliza y se superan las pruebas del sistema.
- Por último, el equipo o el propietario del producto mueve el requisito a Cerrado cuando el propietario del producto acepta que se ha implementado según los criterios de aceptación y que ha superado todas las pruebas de validación.
Actualización del estado del trabajo con Kanban o paneles de tareas
Los equipos pueden utilizar el panel Kanban para actualizar el estado de los requisitos y el panel de tareas de sprint 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 que admita más carriles o columnas. Para conocer más opciones de personalización, consulte Personalización de la experiencia de seguimiento del trabajo.
Asignar requisitos a las 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. Puede hacerlo si define características y asigna requisitos a estas.
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 de cartera para ver una consolidación del trabajo en curso de varios equipos al configurar una jerarquía de equipos.
El elemento de trabajo de característica contiene campos similares proporcionados para los requisitos e incluye algunos campos adicionales, como se describe en la tabla siguiente.
Definición de tareas
Si 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 requerirá.
Cuando los equipos calculan el trabajo, definen tareas y calculan las horas o los días necesarios para completarlas. Los equipos realizan la previsión del trabajo y definen las tareas al principio de una iteración, y cada miembro del equipo realiza 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 requisitos, y un evaluador puede definir tareas para escribir y ejecutar casos de prueba. Al vincular tareas a requisitos y errores, es posible ver el progreso realizado en estos elementos. Para más información, consulte Actividades de iteración.
Campo
Uso
Seleccione el tipo de tarea que se va a implementar a partir de los valores permitidos:
Acción correctora
Acción de mitigación del riesgo
Planeado
Seleccione la materia que esta tarea representa cuando el equipo estima la capacidad de sprint por actividad.
Análisis
Desarrollo
Prueba
Datos académicos del usuario
Experiencia del usuario
Este campo también se usa para calcular la capacidad por disciplina. Se asigna a type="Activity" en el archivo ProcessConfiguration. (2)
Para más información, consulte Implementación de tareas de desarrollo.
La cantidad de trabajo estimada requerida para completar una tarea. Normalmente, este campo no cambia una vez asignado.
La cantidad de trabajo restante 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 Evolución del sprint. Si se divide una tarea en subtareas, especifique las horas solamente para las subtareas. Puede especificar el trabajo en la unidad de medida que el equipo elija.
La cantidad de trabajo que se ha empleado en la implementación de una tarea.
Realizar el seguimiento del progreso de la prueba
Requisitos de pruebas
Desde el portal web o Test Manager, puede crear casos de prueba que se vinculan automáticamente a un requisito o a un error. O bien, puede vincular un requisito a un caso de prueba desde 
(pestaña de 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 obtener una descripción de cada campo, vea Consulta basada en campos de integración de compilación y pruebas.
La pestaña (pestaña de vínculos) muestra todos los requisitos y errores de un caso de prueba. La vinculación permite al equipo seguir el progreso realizado en las pruebas de cada elemento y admite la información que aparece en el informe Información general sobre los requisitos.
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.
Realizar el seguimiento de solicitudes de cambio, riesgos, problemas y notas capturadas en las reuniones de revisión
Además de con los WIT de requisitos, características, tareas y errores, puede realizar un seguimiento de la información recomendada por el proceso de CMMI con los siguientes WIT.
- Solicitud de cambio para administrar los cambios propuestos en cualquier producto de trabajo que esté en control de cambios.
- Problema para realizar el seguimiento de un evento o situación que podría bloquear o está bloqueando el trabajo en el producto. Los problemas difieren de los riesgos en que los equipos identifican los problemas espontáneamente, en general durante las reuniones diarias del equipo.
- Riesgo para realizar un seguimiento de la probabilidad y el grado de varianza entre los resultados reales y los deseados. Al administrar riesgos, se minimiza estratégicamente la varianza entre el resultado que desea y el resultado real.
- Revisión para documentar los resultados de una revisión del diseño o del código. Los miembros del equipo pueden capturar los detalles de cómo el diseño o el código satisface las normas en las áreas de exactitud del nombre, relevancia del código, extensibilidad, complejidad del código, complejidad algorítmica y seguridad del código.
Puede agregar una incidencia 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, consulte Cambio del contexto del equipo.
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.
Artículos relacionados
- Creación de un proyecto
- Agregar elementos de trabajo para administrar un proyecto
- Crear un registro de trabajo pendiente
- Agregar un panel Kanban
- Planear un sprint
Orden de lista de trabajos pendientes
El campo Orden por prioridad se usa para realizar un seguimiento de la clasificación relativa de los requisitos, características o épicas. Sin embargo, de forma predeterminada no aparece en el formulario de 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.
Este campo no aparece en el formulario del elemento de trabajo.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de