Gobernanza de codesarrollo
Establecer un marco de gobernanza de codesarrollo eficaz es una parte impotante para garantizar la coherencia y la repetibilidad en los proyectos definidos por los fabricantes y los equipos de Fusion. Este artículo describe un enfoque para definir un diagrama de flujo de gobernanza.
Definición del proceso de principio a fin
Puede usar el siguiente proceso como ejemplo y personalizarlo según las mejores prácticas de su organización. No es necesario completar todos los pasos, siempre que logre el resultado requerido.
Agregar funciones a la cartera de pedidos
Los trabajos pendientes le permiten planificar su proyecto al agregar funciones que impulsan la experiencia general. El backlog también proporciona la hoja de ruta general que el equipo tiene la intención de entregar.
Al agregar una nueva función al backlog, el objetivo es describir el alcance general. Luego, cada función define el valor comercial, los títulos de las historias preliminares, el alcance y los cambios en el modelo de datos que impulsan los esfuerzos de desarrollo del código.
Además, al agregar una función crítica para el negocio, se recomienda identificar cualquier escenario crítico para automatizar sus pruebas. Una vez que haya agregado sus características, puede programar su reunión de alineación de alcance.
Reunión de alineación del alcance
El enfoque de esta reunión debe limitarse a revisar cada nueva característica propuesta y luego verificar si hay aplicaciones, escenarios o modelos de datos existentes que ya brinden esta funcionalidad para evitar la duplicación de esfuerzos. Esta reunión también brinda la oportunidad de discutir el impacto en otras aplicaciones. Finalmente, debe verificar si esta función requiere una revisión de experiencia.
Agregue historias y guiones gráficos a la cartera de pedidos
Después de la reunión de alineación del alcance, cualquier borrador de título de historia de usuario se puede agregar a la función. En este punto, no se requieren detalles y el estado de la historia de usuario es "Nuevo". Puede ver las historias en la vista de trabajos pendientes o en el tablero.
La siguiente figura muestra una historia de usuario de muestra agregada a un trabajo pendiente.
En este punto, es vital mantener la calidad organizando el trabajo por flujo de trabajo y aplicación. Este enfoque ayuda a mantener juntos los elementos de trabajo relacionados y permite a los expertos en cada flujo de trabajo desarrollar y mantener una comprensión profunda de la funcionalidad y el uso de datos dentro de cada aplicación.
Revisión de la experiencia
Las revisiones de experiencia deben centrarse en la experiencia del usuario final y garantizar que su equipo siga las mejores prácticas de la organización. Esta consistencia garantiza que todas sus aplicaciones brinden una experiencia confiable y repetible para los usuarios finales y los equipos de soporte.
Agregar detalles de historial
Agregar una historia de usuario típica puede incorporar la siguiente información:
- Título: Como <persona>, puedo <do something> de modo que <impact/priority/value>
- Descripción: la descripción incluye (aunque no se limita a) ciertos detalles clave, como:
- Breve descripción del escenario que resume el resultado deseado
- Narrativa: describe las acciones que los usuarios realizarán para navegar y lograr el escenario
- Narrativa alternativa: describe otras formas en que los usuarios pueden lograr el mismo resultado
- Notas de diseño: registra la entidad, los campos, las vistas, las pantallas de maqueta y las reglas comerciales asociadas con la historia de usuario
- Roles de seguridad afectados: enumera todos los roles de seguridad afectados o que son relevantes para la historia de usuario.
Después de agregar todos estos detalles, cambiaría el estado de la historia de usuario a "Listo para revisión". En la mayoría de los casos, el equipo de funciones y el equipo comercial (si corresponde) revisan las historias de los usuarios.
Revisión de la historia
Las revisiones de la historia generalmente ocurren dentro del equipo de fusión para garantizar que todos los detalles se mencionen en la historia y que no haya ambigüedad. Después de completar todas las revisiones, la recomendación es asignar la historia de usuario a un miembro del equipo. Asegurarse de que su equipo se mantenga alineado durante el proceso de desarrollo es vital para lograr sus objetivos generales.
Agregar tareas y casos de prueba
Después de revisar las historias, los miembros del equipo crean tareas en Azure DevOps. El proceso general para agregar tareas y casos de prueba es el siguiente:
- Abra una acumulación de sprint. Alternativamente, cree un nuevo sprint.
- Agregue elementos de trabajo existentes al sprint. Si ya agregó elementos de trabajo que no aparecen en el sprint, debe verificar su área y rutas de iteración. Recuerde asignar cualquier tarea sin padres a los elementos de trabajo relevantes.
- Agregue tareas a los elementos pendientes. Si no tiene elementos del backlog asignados a su sprint, hágalo ahora. También establezca las fechas de inicio y finalización del sprint.
- Rellene el formulario de la tarea. Como regla general, las tareas no deberían tardar más de un día en completarse. Las tareas que son más grandes que esta escala de tiempo deben desglosarse.
- Realice un seguimiento o integre cualquier tarea sin padres. Puede realizar un seguimiento de las tareas no relacionadas como otras tareas o arrastrarlas a un elemento pendiente existente para crear un elemento principal.
Después de agregar tareas y casos de prueba, puede continuar para establecer la capacidad de sprint.
Para obtener más información sobre cómo agregar tareas, consulte Añadir tareas a la cartera de pedidos para apoyar la planificación de sprints.
Preparar soluciones
Un aspecto importante para el desarrollo conjunto exitoso es un proceso estructurado de administración de versiones. Las soluciones son el mecanismo para implementar la administración del ciclo de vida de la aplicación (ALM); se usan para distribuir componentes entre entornos mediante exportación e importación. Un componente de representa un artefacto usado en su aplicación y algo que puede personalizar. Todo lo que se puede incluir en una solución es un componente, como tablas, columnas, lienzos y aplicaciones basadas en modelos, flujos de Power Automate, bots de chat, gráficos y complementos.
Importante
Durante la planificación del lanzamiento, determine la estrategia para administrar soluciones en tu proyecto Utilice soluciones para administrar su proyecto y encontrar fácilmente los componentes que ha creado para luego distribuirlos a otros entornos.
Implementaciones
Los componentes pueden requerir varios sprints para completarse según la complejidad y la velocidad del equipo. Los componentes se deben añadir a una solución en un entorno de desarrollo a medida que se completan las tareas. Luego, las soluciones se importan a un entorno de producción después de que se prueban. Le recomendamos que también mantenga un entorno de prueba para realizar pruebas de extremo a extremo y probar la implementación de la solución antes de pasar a producción.
Entornos de Power Platform
Los entornos son un espacio para almacenar, administrar y compartir datos profesionales, aplicaciones y procesos empresariales de su organización. También sirven como contenedor para separar las aplicaciones que pueden tener distintos roles, requisitos de seguridad o públicos objetivos.
Si su organización tiene una configuración de fusión de varios equipos en la que cada equipo desarrolla sus propias soluciones, es importante coordinar la duración de los sprints y los lanzamientos. Los sprints no tienen que tener una duración constante a lo largo de un cronograma del proyecto y pueden variar en duración entre equipos, según las preferencias de cada grupo. Sin embargo, la cadencia de lanzamiento no puede ser menor que la duración del sprint más corto en todos los equipos.
Control de código fuente
Pensar en la posibilidad de adoptar un sistema de control de código fuente como Azure DevOps. Azure DevOps proporciona servicios de desarrollador para equipos de soporte para planificar el trabajo, colaborar en el desarrollo de código y crear e implementar aplicaciones.
Exporte una solución de su entorno de desarrollo que contenga sus aplicaciones y personalizaciones, desempaquete su solución y almacene los componentes en su sistema de control de código fuente.
Avanzado tema: Revisiones de solicitud de extracción (PR)
Solo debe crear relaciones públicas para historias que estén activas y cuyas funciones se hayan revisado y aprobado. Debe asegurarse de que el control de versiones de la solución sea preciso, siguiendo las pautas de sprint y desarrollo establecidas en Implementar prácticas Scrum para su equipo en Azure Boards. Los resultados de la prueba del PR pueden ser capturas de pantalla o videos que representan la funcionalidad que se está construyendo.
La automatización del proceso de gobierno de relaciones públicas ayuda a garantizar la calidad del código sin necesidad de revisar manualmente las comprobaciones básicas, como las versiones de la solución.
Nota
Utilizar la Herramienta de verificación de relaciones públicas para automatizar el proceso de verificación de solicitud de extracción.
Plantillas y estandarización
Las plantillas y la estandarización brindan eficiencia al ayudar a promover la coherencia dentro del equipo. Todos los aspectos de las operaciones del equipo— ya sean tareas de incorporación, presentaciones de revisión de historias o plantillas de elementos de trabajo que ayudan a ahorrar tiempo y brindan orientación a los equipos. al definir historias de usuario, características, errores o tareas— benefíciese de la estandarización y la simplificación.
Implementación de un modelo de apoyo eficaz
Un modelo de soporte efectivo es esencial para el éxito a largo plazo de una aplicación después de su implementación, como se destacó en la sección anterior sobre la generación de una matriz de soporte. Los errores y las interrupciones son inevitables, por lo que es vital que el equipo tenga un enfoque estructurado para manejar estos casos, y la matriz de soporte proporciona el marco necesario.
Crear el acuerdo de nivel de servicio
Un factor clave en cualquier modelo de soporte es la definición del Acuerdo de Nivel de Servicio (SLA). El SLA debe ser un documento formal elaborado por el equipo que contenga secciones que cubran los siguientes elementos:
- Apagones – qué nivel de interrupción del servicio es aceptable, a quién informar, qué acciones tomar, confirmación de la reanudación del servicio y acciones para evitar que se repita. Cualquier procedimiento de prueba automatizado que utilice el equipo debe alinearse con la tolerancia de interrupción esperada y el SLA aplicable.
- Errores – quién puede notificar, asignación de niveles de gravedad, clasificación, actuaciones en caso de detección, responsable de resolver y dar de alta.
- Escalaciones – niveles de escalamiento, asignación de personal a niveles, responsabilidades en cada nivel, listas de distribución para cada nivel, etc.
El SLA debe almacenarse en el portal de documentación del equipo y actualizarse según sea necesario.
Ofrecer soporte de la aplicación
El mejor enfoque para brindar el soporte de aplicaciones especificado en el SLA es que el equipo que creó la solución también sea responsable de brindarle soporte. Las ventajas de este sistema son:
- Fomenta un desarrollo de mejor calidad, porque quienes crearon la aplicación saben que tendrán que apoyarla.
- Los creadores podrán encontrar y corregir errores más rápido que un equipo externo, simplemente porque conocen mejor la aplicación.
- Delegar la reparación de software potencialmente crítico para la misión a otro grupo puede ser desmoralizador y llevar mucho tiempo para ese grupo. Al igual que con otras fases de creación, desarrollo e implementación de aplicaciones, el equipo de fusión debe asociarse con TI para obtener asistencia cuando sea necesario.
Monitoreo de la satisfacción y usabilidad de la aplicación
La parte final del esfuerzo de soporte es monitorear y evaluar la satisfacción y la usabilidad de la aplicación implementada. Las métricas son útiles aquí, junto con métodos más tradicionales, como sondeos y cuestionarios. Para obtener más información sobre cómo monitorear el uso de la aplicación, consulte Análisis de administración para Power Apps.
En última instancia, si los clientes no usan una aplicación publicada, esa aplicación no está cumpliendo su propósito. Las reuniones de revisión periódicas pueden verificar estas métricas de satisfacción y usabilidad para crear un ciclo de retroalimentación positiva que puede modificar o agregar historias al trabajo pendiente para generar y luego implementar una versión actualizada de la aplicación.
Resumen
El desarrollo de herramientas sin código y de bajo código como Power Apps ha ampliado las opciones para que los tecnólogos o creadores de negocios creen, desarrollen e implementen aplicaciones. Este desarrollo funciona mejor dentro de un entorno de equipo de fusión, compuesto por un propietario del producto, un experto en el dominio, un desarrollador profesional y un Administrador, con este equipo aportando otros recursos según sea necesario.
La integración de enfoques de desarrollo ágiles y scrum dentro de los equipos de Fusion da como resultado un desarrollo de aplicaciones más rápido y una mayor probabilidad de implementación exitosa con un conjunto de funciones que marca una diferencia significativa para el negocio. Al aplicar estas mejores prácticas, pautas y recomendaciones, su equipo de fusión podrá usar Power Apps para abordar los desafíos de transformación digital de su organización.