Preguntas frecuentes sobre Azure Boards

Como miembro de un proyecto de Azure Boards, puede usar la mayoría de las características para realizar un seguimiento del trabajo. Las limitaciones para seleccionar características se basan en el nivel de acceso y el grupo de seguridad al que se asigna un usuario. Otras limitaciones se pueden imponer en función de los permisos de seguimiento de trabajo o las reglas personalizadas. Para más información, consulte Permisos predeterminados y asignaciones de Azure Boards.

Para restringir el acceso, establezca permisos para una ruta de acceso de área. Para más información, consulte los siguientes artículos.

• Establecimiento de permisos de planeamiento y seguimiento del trabajo
• Conceder o restringir permisos para seleccionar tareas

Sí. Las reglas condicionales basadas en la pertenencia a usuarios o grupos se almacenan en la caché para el explorador web. Si se topa con restricciones para actualizar un elemento de trabajo, es probable que se haya encontrado con una de estas reglas. Para más información sobre las reglas condicionales, consulte Reglas y evaluación de reglas. Si la caché almacena reglas obsoletas, puede esperar a que la memoria caché del cliente expire en un plazo de tres días, o bien puede borrar la memoria caché.
Para borrar la memoria caché, ejecute el siguiente comando en la ventana de comandos del explorador y, a continuación, actualice el explorador: window.indexedDB.deleteDatabase("wit")

Consulte Herramientas y clientes que se conectan a Azure DevOps.

Para obtener una introducción a los elementos de trabajo, consulte Acerca de los elementos de trabajo.

Para ver todos los elementos de trabajo definidos en un proyecto, abra una consulta y agregue dos cláusulas:

• Work Item Type = [Any]
• State = [Any]

Desde ahí, puede agregar filtros para refinar la consulta. Para más información, consulte Creación y almacenamiento de consultas administradas con el editor de consultas.

No. Los elementos de trabajo solo se pueden asignar a usuarios individuales. Además, solo se puede agregar un usuario que esté disponible en el selector de personas.

El método principal para agrupar el trabajo es asignarlo a la misma ruta de acceso de área. Las rutas de acceso de área se usan para agrupar elementos de trabajo por producto, características o área empresarial y para admitir a los equipos responsables del trabajo asignado a esas áreas. Además, puede agrupar el trabajo en un elemento de trabajo principal mediante vínculos principales y secundarios, lo que se denomina agrupación jerárquica.

Para ver una explicación de estos dos usos y las herramientas que admiten, consulte Configuración y personalización de Azure Boards, rutas de acceso de área, equipos de productos y administración de carteras.

Los marcadores de hitos no se usan en el seguimiento de trabajos de Azure Boards, salvo en los planes de entrega. Los planes de entrega proporcionan una vista de calendario y permiten definir un marcador de hitos. Para más información, consulte Revisión de los planes de entrega de un equipo.

Sin embargo, puede utilizar una o varias de las siguientes opciones para marcar un elemento de trabajo como un hito:

• Anteponga o añada la palabra Hito al título de su elemento de trabajo.
• Agregue una etiqueta de elemento de trabajo con la etiqueta Hito.
• Agregue un campo personalizado con la etiqueta Hito y rellénelo con una lista de selección de hitos.
• Vincule elementos de trabajo mediante los tipos de vínculo Predecesor/Sucesor o Relacionado a un elemento de trabajo de hito
• Asigne el elemento de trabajo de hito al sprint en el que está destinado para su finalización.

Para realizar un seguimiento de las dependencias entre elementos de trabajo, vincúlelos mediante un tipo de vínculo relacionado, o cualquier otro tipo de vínculo. Vea Vinculación de elementos de trabajo a otros objetos.

Si va a realizar el seguimiento de las dependencias en una o varias organizaciones, puede usar la extensión Seguimiento de dependencias.

Cada proceso define cuatro niveles de trabajo pendiente predeterminados: el trabajo pendiente de iteración, el trabajo pendiente de requisitos, los trabajos pendientes en cartera de características y epopeyas. Los tipos de elemento de trabajo que se agregan a cada nivel de trabajo pendiente son los naturales para formar una relación principal-secundario y agrupar elementos de trabajo en una jerarquía. Para más información, consulte Organización del trabajo pendiente y asignación de elementos de trabajo secundarios a elementos principales. Para personalizar el proceso, consulte Personalización de trabajos pendientes o paneles, Edición o cambio de nombre del trabajo pendiente de requisitos.

Consulte Modificación en masa de elementos de trabajo, Modificación masiva de campos de texto enriquecido.

Sí, puede establecer el nivel de trabajo pendiente para que incluya dos reglas distintas. La primera regla es para establecer el elemento primario como activo cuando cualquiera de sus elementos secundarios esté activo. La segunda regla consiste en establecer el elemento primario como resuelto o cerrado cuando todos los elementos secundarios estén cerrados. Estas reglas se pueden configurar para el nivel de trabajo pendiente. Para obtener más información, consulte Automatización de transiciones de estado de elementos de trabajo.

Los elementos de trabajo cambian de estado automáticamente después de que el administrador del equipo configura reglas de automatización en el trabajo pendiente. Cree reglas para establecer automáticamente el estado como activo o cerrado en función del cambio de estado de sus elementos secundarios. Para obtener más información, consulte Automatización de transiciones de estado de elementos de trabajo.

Las reglas solo se activan cuando el estado del elemento secundario pasa de Nuevo a Activo o a Cerrado. Las reglas no se activan cuando el estado del elemento secundario pasa de Cerrado a Activo. Actualmente, este comportamiento es así por diseño.

No, las reglas se aplican a todos los tipos de elemento de trabajo de ese nivel de trabajo pendiente. Usamos categorías de estado en lugar de estados porque las categorías de estado son coherentes para todos los tipos de elemento de trabajo.

Sí, las reglas se configuran por nivel de trabajo pendiente. Las reglas de automatización en el trabajo pendiente de casos de usuarios no afectan a las características ni épicas. Pero también puede configurar reglas independientes para características y épicas. Para obtener más información, consulte Automatización de transiciones de estado de elementos de trabajo.

Las reglas solo se desencadenan si los elementos primarios y secundarios pertenecen al mismo equipo. No queremos que las reglas se desencadenen automáticamente para los elementos que pertenecen a otros equipos. Para obtener más información, consulte Automatización de transiciones de estado de elementos de trabajo.

Cada trabajo pendiente y panel representa un conjunto filtrado de elementos de trabajo en función de las asignaciones de ruta de acceso de área de equipo y ruta de acceso de iteración del equipo. Los trabajos pendientes muestran elementos de trabajo, mientras que los paneles muestran los elementos de trabajo en forma de tarjetas. Para saber cómo se aplica el filtrado, consulte Acerca de los equipos y las herramientas de Agile, Valores predeterminados del equipo a los que hacen referencia los trabajos pendientes y los paneles.

Para agregar un trabajo pendiente o un panel, agregue un equipo. Cada equipo se configura con su propio conjunto de trabajos pendientes y paneles, tal como se describe en Acerca de los equipos y las herramientas de Agile. Cada equipo puede personalizar estas herramientas de Agile.

Azure DevOps impone muchos límites, como el número de elementos de trabajo que se muestran en un trabajo pendiente o panel, el número de equipos que se pueden definir, etc. Para ver una lista completa, consulte Seguimiento del trabajo, procesos y límites de proyectos.

Consulte Migración e integración de Azure Boards.

Cada trabajo pendiente enumera un conjunto filtrado de elementos de trabajo en función de la ruta de acceso de área seleccionada, las rutas de acceso de iteración y los tipos de elementos de trabajo del equipo.

• Trabajo pendiente: de forma predeterminada enumeran casos de usuario (Agile), problemas (Basic), elementos de trabajo pendiente y errores (Scrum) o requisitos (CMMI). Proporciona opciones para mostrar Elementos principales, Previsión y En curso o elementos secundarios completados.
• Trabajo pendiente en cartera: de forma predeterminada enumera características (todos los modelos de proceso) para el trabajo pendiente de características y epopeyas (Agile, Scrum y CMMI) para el trabajo pendiente de Epic. Proporciona opciones para mostrar Elementos principales y En curso, o elementos secundarios completados.
• Trabajo pendiente de sprint: de forma predeterminada enumera todos los elementos de trabajo pendiente asignados a la iteración seleccionada, independientemente del estado. Proporciona opciones para mostrar detalles del trabajo.

Sí. Puede asignar sprints a elementos de trabajo y filtrar un panel Kanban en función de la ruta de acceso de iteración. Para más información, consulte Filtrado del panel Kanban.

No. Las listas de comprobación de tareas solo admiten el tipo de elemento de trabajo de tarea.

Azure DevOps no proporciona una vista nativa de la ruta crítica. En parte, como las metodologías de Agile, se favorece un producto viable mínimo (MVP) sobre la administración de rutas críticas (CPM). El uso de MVP permite identificar la ruta de acceso más corta y las dependencias mediante la priorización de epopeyas, características, historias y tareas.

Dicho esto, se recomienda usar planes de entrega para ver las dependencias y una vista de calendario del trabajo.

Si su organización admite la conexión a Microsoft Project, puede encontrar más extensiones de Marketplace que admitan la conexión de Azure DevOps a Microsoft Project.

Para tener más contexto, consulte La ruta crítica en proyectos de Agile y Ejecución de un inicio basado en Azure DevOps.

No. Los datos introducidos relativos a la capacidad del equipo no se guardan en los almacenes de datos normales.

No. No se admite esta característica. Se trata de una característica sugerida, que puede invocar en nuestra página de Developer Community.

Sí, vea Consulta por cambios de asignación o flujo de trabajo, Consultas de cambio de panel Kanban.

Sí, agregando la extensión de Marketplace Query Based Boards.

Sí, agregando la extensión de Marketplace Azure Boards Kanban Tools.

Sí, puede realizar un seguimiento de los movimientos de las columnas en un panel Kanban mediante los campos Columna de panel y Columna de panel lista.

Si aparece el siguiente error al abrir el panel Kanban, debe corregir la configuración. El motivo principal de este error es que los estados de flujo de trabajo de los tipos de elementos de trabajo agregados a la categoría Requisitos no están asignados a la columna.

Seleccione Corríjalo ahora para abrir el cuadro de diálogo Configuración. En el siguiente ejemplo, se agregan dos nuevos estados: Prioridades evaluadas para errores e Investigación para el caso del usuario. Luego, cada estado se asigna a una columna existente o una nueva. Después de asignar cada estado a una columna, el panel Kanban muestra los elementos de trabajo asignados a estos estados.

Sí, puede agregar o quitar carriles en el panel Kanban. También puede configurar reglas de carriles, donde cuando se cumplen ciertas condiciones, Azure Boards mueve automáticamente los elementos de trabajo a carriles concretos.

Puede definir plantillas de elementos de trabajo para los equipos a los que pertenece. Para definir plantillas de elementos de trabajo para especificar los valores predeterminados de los campos seleccionados, consulte Usar plantillas para agregar y actualizar elementos de trabajo.

La característica para establecer una plantilla predeterminada para un equipo no se admite en este momento.

No. Esta característica no se admite en este momento.

Solicitud de ejemplo: al crear una plantilla, me gustaría que el artículo del usuario primario fuera el valor predeterminado. No hay un campo predeterminado en la plantilla. ¿Podría estar esta función en una selección definida por el usuario?

No, no hay compatibilidad nativa para crear plantillas de jerarquía. En concreto, no se puede especificar un elemento de trabajo principal predeterminado. Sin embargo, puede copiar rápidamente tareas, errores y otros elementos mediante Excel para aplicar vínculos primarios y secundarios en una lista en árbol. O bien, puede usar un panel Kanban para agregar tareas secundarias, elementos de trabajo pendiente o características. Para más información, consulte:

• Adición de listas de comprobación de tareas
• Adición, ejecución y actualización de pruebas insertadas
• Adición de características y epopeyas

En la página del tipo de elemento de trabajo, elija el icono de acciones de una plantilla existente y seleccione la opción Eliminar.

Azure Boards se integra con GitHub para Azure DevOps Server 2019 y versiones posteriores. Para más información, consulte Azure Boards y GitHub.

No. Esta característica no se admite en este momento.

La configuración y la personalización de Azure Boards se producen en el nivel de proyecto y equipo. Para obtener información general sobre lo que puede configurar y personalizar para satisfacer sus necesidades empresariales, consulte Configuración y personalización de Azure Boards.

Para ver las preguntas más frecuentes sobre la configuración y la personalización, consulte Preguntas frecuentes sobre la configuración y personalización de Azure Boards.

Artículos relacionados

• Preguntas más frecuentes sobre consultas
• Seguimiento del trabajo, proceso y límites del proyecto
• Preguntas más frecuentes sobre la configuración y la personalización de Azure Boards
• Preguntas frecuentes sobre el uso de Excel en conexión con Azure Boards
• Preguntas más frecuentes sobre el trabajo entre proyectos
• Extensiones de Azure Boards
• Acerca de los equipos y las herramientas de Agile