Compartir vía

Permisos y requisitos previos para acceder a Analytics en Azure DevOps

  • Artículo

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

Para trabajar con Analytics y crear informes, se deben cumplir varios requisitos previos como se resume en este artículo.

De forma predeterminada, a todos los miembros del proyecto se les proporciona acceso a los datos de Analytics para los proyectos de los que son miembros, incluidos los miembros agregados al grupo Lectores del proyecto. Los usuarios con acceso a partes interesadas no tienen acceso para ver ni editar vistas de Análisis.

Habilitación de servicios y características

En general, Analytics siempre está disponible y está disponible para los miembros de una organización o colección para ver los datos y crear un informe.

Servicio de análisis

Para Azure DevOps Services, Analytics siempre está activado. No se puede deshabilitar ni pausar.

En el caso de Azure DevOps Server 2020 y versiones posteriores locales, Analytics se instala automáticamente con cada colección de proyectos que cree.

Para Azure DevOps Server 2019, primero debe instalar Analytics en cada colección de proyectos que cree.

Puede pausar y reiniciar el servicio. Cuando se pausa, no se agregan nuevos datos a Analytics.

Para obtener más información, consulte Instalación o habilitación del servicio Analytics.

Azure DevOps Services

Para ejercer cualquier servicio de Azure DevOps, debe estar habilitado. No se puede capturar ningún dato para un servicio que se haya deshabilitado. Los servicios se pueden habilitar o deshabilitar en un proyecto por proyecto.

Para comprobar que todos los servicios están habilitados, consulte Activar o desactivar un servicio.

Vistas de análisis

Las vistas de análisis, un centro en el portal web, proporcionan una manera simplificada de especificar los criterios de filtro de un informe de Power BI basado en los datos de Analytics. Para obtener más información, consulte ¿Qué es el Servicio de análisis?

Para acceder a las vistas de Analytics, debe tenerla habilitada. El propietario de la organización o miembro del grupo Administradores de colecciones de proyectos puede habilitarlo para todos los miembros de la organización. O bien, cada miembro del proyecto puede habilitarlo para sí mismo.

Para obtener información sobre cómo hacerlo, consulte Administración o habilitación de características.

Permisos

Establezca permisos para el servicio en el nivel de proyecto y para las vistas de Análisis compartidas en el nivel de objeto.

En la tabla siguiente se resumen los permisos disponibles para establecerse y las asignaciones predeterminadas realizadas a los grupos de seguridad del proyecto.

Permiso Lectores Colaboradores Project Administrators
Ver análisis ✔️ ✔️ ✔️
Visualización de una vista de Análisis compartido ✔️ ✔️
Adición de una vista de análisis privada o compartida ✔️ ✔️
Edición y eliminación de vistas de Análisis compartidos ✔️

Requisitos previos de seguimiento de datos

Para capturar datos significativos, los equipos de software deben realizar acciones significativas. En las secciones siguientes se proporcionan recomendaciones generales basadas en el tipo de datos en los que desea informar.

Nota:

Los conjuntos de entidades branch, Pipeline y Test son compatibles con Analytics v3.0-preview y versiones posteriores. Los conjuntos de entidades de instantáneas para admitir trabajos de canalización, solicitudes de agente de tareas y tamaño del grupo de agentes de tareas se agregaron con la versión preliminar de Analytics v4.0. Asegúrese de especificar la versión de Analytics que admite el conjunto de entidades de interés.

Para comprender qué propiedades y valores de lista enumerados puede filtrar o agrupar datos, explore los metadatos de Analytics para el tipo de entidad correspondiente.

Azure Boards y seguimiento del trabajo

Para obtener una revisión de los conjuntos de entidades disponibles que puede consultar, consulte Referencia de metadatos para Azure Boards Analytics.

Para informar sobre el seguimiento del trabajo, los equipos deben realizar varias tareas para asegurarse de que hay datos significativos disponibles. Revise las siguientes tareas antes de definir las consultas e informes de Analytics.

  • Para informar sobre errores activos o tendencias de errores, defina errores y actualice el estado del error tal como se ha corregido, comprobado y cerrado.
  • Para informar sobre el trabajo pendiente u otros tipos de elementos de trabajo, asegúrese de definir esos elementos de trabajo y de actualizar su estado a medida que pasa de nuevo a cerrado. Tenga en cuenta los campos o etiquetas que usará para filtrar o agrupar datos en un informe y asegurarse de que está bien definido y coherente.
  • Para admitir informes acumulativos, asegúrese de que existen vínculos primarios y secundarios entre los elementos de trabajo pendiente del producto y tareas o errores, o los vínculos primarios y secundarios existen entre las características o los elementos de trabajo pendiente de cartera y sus elementos secundarios. Para obtener más información, vea Organizar el trabajo pendiente y asignar elementos de trabajo secundarios a los elementos primarios.
  • Para crear informes de agotamiento o de agotamiento, como el agotamiento de sprint o la reducción de versión, asegúrese de haber pensado en cómo desea filtrar y agrupar los datos en el informe. Los informes de agotamiento o de grabación hacen referencia al WorkItemsSnapshot conjunto de entidades. Los conjuntos de entidades de instantáneas se modelan como instantáneas diarias. Los datos se agregan en función de las asignaciones realizadas a partir de la fecha en que se asignan. Esto significa que para filtrar un informe de desmación o de quema en función de las asignaciones de campos o etiquetas, debe asignar los campos o etiquetas antes del período en el que desea informar. De lo contrario, el informe no registra los campos o etiquetas hasta la fecha en que se aplican.
  • Para admitir el seguimiento de requisitos, defina casos de prueba y cree un vínculo Probado por desde cada caso de prueba a un caso de usuario, un elemento de trabajo pendiente de producto o un requisito. Defina casos de prueba y vincule los casos de prueba a sus PBIs primarios mediante el vínculo Probado por. Consulte Creación de pruebas.
  • (Recomendado) Para admitir el filtrado y la agrupación dentro de un informe, asigne ruta de acceso de área e ruta de acceso de iteración a todos los elementos de trabajo. Para obtener información sobre cómo definir rutas de acceso de iteración y área, consulte Definir rutas de acceso de área y asignarlas a un equipo o Definir rutas de iteración (sprints) y configurar iteraciones de equipo.

Nota:

Todos los campos personalizados agregados a un tipo de elemento de trabajo están disponibles para su uso en los informes. Los campos personalizados se etiquetan con Custom_DisplayNameOfField, donde se han quitado todos los espacios del nombre para mostrar.

Planes de pruebas

Para revisar el progreso del plan de prueba y la preparación de los casos de prueba, los equipos deben realizar las siguientes actividades.

  • Defina casos de prueba, planes de prueba y conjuntos de pruebas y especifique su estado actual. Para obtener más información, consulte Creación de planes de prueba y conjuntos de pruebas y Creación de casos de prueba.
  • Actualice el estado de los objetos de prueba a medida que avanzan de Diseño a Listo para cerrar.
  • Para las pruebas manuales, marque los resultados de cada paso de validación en el caso de prueba como superado o erróneo.

    Sugerencia

    Los evaluadores deben marcar un paso de prueba con un estado si es un paso de prueba de validación. El resultado general de una prueba refleja el estado de todos los pasos de prueba marcados. Por lo tanto, la prueba tendrá un estado de error si algún paso de prueba está marcado como erróneo o no marcado.

  • En el caso de las pruebas automatizadas, cada prueba se marca automáticamente como superada o con errores.
  • (Recomendado) Para admitir el filtrado y la agrupación dentro de un informe, asigne ruta de acceso de área e ruta de acceso de iteración a casos de prueba, conjuntos de pruebas y planes de prueba.

Pipelines

Para informar sobre las canalizaciones, los equipos deben definir canalizaciones mediante YAML y ejecutar canalizaciones periódicamente. Para más información, consulte Conceptos clave para los nuevos usuarios de Azure Pipelines.

Además, tenga en cuenta las siguientes acciones:

  • Tenga en cuenta los datos en los que desea informar y elija el conjunto de entidades correcto. Para obtener una revisión de los conjuntos de entidades disponibles que se van a consultar, consulte Referencia de metadatos para Azure Pipelines Analytics.
  • Tenga en cuenta las canalizaciones en las que desea informar y el intervalo de fechas del informe. Querrá filtrar los datos para cumplir los procedimientos recomendados de consulta y minimizar los problemas de rendimiento.

Canalizaciones y pruebas

Para informar sobre canalizaciones y resultados de pruebas, asegúrese de agregar tareas de prueba a la definición de canalización. Para obtener más información, consulte Build and release tasks-Test.

Si acaba de empezar, considere la posibilidad de revisar este módulo de Learn, Ejecute pruebas de calidad en la canalización de compilación mediante Azure Pipelines.