Prepararse para el taller

Completado

Normalmente, el taller de rendimiento de soluciones suele llevar entre 2 y 4 horas en realizarse. El tiempo puede variar según el nivel de detalle disponible para su revisión y la amplitud de la solución general. El arquitecto de soluciones trabajará con la dirección del equipo de implementación para planificar el taller en función de los detalles de la solución que se está revisando.

Antes del taller de rendimiento de soluciones, los participantes deberían estar lo más familiarizados posible con su estructura y los tipos de temas y requisitos previos a tratar. El arquitecto de soluciones proporcionará un orden del día con temas y requisitos previos antes del taller.

Nota

Esencialmente, el taller de rendimiento de soluciones es una conversación; no pretende ser un cuestionario que pueda completarse y revisarse en modo sin conexión. Si bien los requisitos previos se definen y proporcionan de antemano, no es posible encapsular la amplitud de direcciones a las que podría desembocar la conversación.

El arquitecto de soluciones se preparará de antemano para el taller revisando los artefactos del proyecto existente con antelación. Entre los artefactos útiles del proyecto se encuentran los siguientes:

  • Revisión de planos técnicos de soluciones: como requisito previo para el taller de rendimiento de soluciones, ya debería haberse completado un taller de revisión de planos técnicos de soluciones. La información que se captura para áreas como el plan del proyecto, el diagrama de la arquitectura de la solución, los procesos comerciales, la estrategia de integración, la estrategia del entorno, la cantidad de usuarios, la estrategia de migración de datos y otra información de la solución puede llevarse directamente a este taller.
  • Plan/programación del proyecto: documento o diagramas de Gantt que representan la programación general y la dependencia de las fases clave del proyecto y sus actividades asociadas.
  • Perfiles de uso del sistema: programaciones de procesos operativos y volúmenes transaccionales máximos por tipo de carga de trabajo.
  • Estrategia de entorno: diagramas de bloques o de flujo que describen los tipos de entornos que se implementarán, cómo y cuándo se usarán, y cómo el código y la configuración fluirán a través de ellos.
  • Ubicaciones de implementación: diagramas o registros que muestran las ubicaciones físicas donde se implementará la solución junto con los requisitos de idioma y localización.
  • Registro de interfaces: listas de interfaces con requisitos no funcionales y patrones de diseño que documenten el ámbito y el enfoque para implementar esas interfaces.
  • Diagramas de flujo de datos: en una solución que incluye múltiples aplicaciones de Dynamics 365, servicios y componentes heredados o externos, que es útil poder identificar dónde se originan los datos y cómo se mueven y utilizan en la solución.
  • Estrategia de migración de datos: documentos o registros que muestran las entidades que se van a migrar, los orígenes de dónde provendrán, los volúmenes, la temporización y los métodos de migración. En la fase de planos técnicos de diseño de la solución, es clave asegurarse de disponer de ámbito (tablas y orígenes).
  • Estrategia de pruebas de rendimiento: cualquier documentación preexistente sobre la estrategia de pruebas de rendimiento que describa áreas como objetivos de rendimiento, KPI, herramientas de prueba, entorno a utilizar y otros factores que sean consistentes con las pruebas de rendimiento.

Esta lista de entregables del proyecto no es exhaustiva, pero es un buen punto de partida para la revisión del rendimiento de soluciones. Los formatos, la composición y los nombres de cada entregable pueden variar de un proyecto a otro. El formato no es el elemento más importante; lo que es esencial es la información que está disponible y se ha acordado con todo el equipo.

Cuando está llevando a cabo una revisión de rendimiento de la solución al principio del proyecto, muchos de estos documentos no estarán completamente conformados, lo cual es aceptable en la mayoría de los casos. Es más importante que se haya determinado el ámbito y que exista un plan conceptual para saber cómo la solución apoyará ese ámbito. Si el ámbito y el enfoque de la solución conceptual están establecidos, la revisión del rendimiento de la solución puede centrarse en el enfoque conceptual y luego, a continuación, los talleres de seguimiento más profundos pueden centrarse en los detalles en el momento en que estén disponibles.

Es aceptable si el proyecto utiliza diferentes formas de administrar o seguir la información del proyecto que no sean las que aparecían en la lista anterior. Por lo general, el formato no es crítico si la información está fácilmente disponible para los miembros del proyecto. Si la información de la lista anterior no está documentada en su proyecto, o si está documentada de manera que no es fácilmente accesible, debe priorizar la producción de los artefactos relevantes.

Consejo

Se recomienda usar diagramas y representaciones visuales para proporcionar resúmenes generales en la implementación, siempre que sea posible. Estos diagramas, cuadros y gráficos proporcionan un medio de comunicación listo para todo el equipo y los ejecutivos acerca de los planes y diseños.