Regulación do desenvolvemento conxunto

Establecer un marco de goberno de desenvolvemento conxunto eficaz é unha parte importante de garantir a coherencia e a repetibilidade en proxectos e equipos de fusión definidos polo creador. Este artigo describe un enfoque para definir un diagrama de fluxo de goberno.

Definición do proceso integral

Pode usar o seguinte proceso como exemplo e personalizalo segundo as prácticas recomendadas da súa organización. Non é necesario completar todos os pasos, sempre que consiga o resultado necesario.

Engadir funcións ao traballo pendente

Os traballos pendentes permítenlle planificar o seu proxecto engadindo funcións que impulsan a experiencia global. O traballo pendente tamén proporciona a folla de ruta xeral que o equipo pretende entregar.

Ao engadir unha nova función ao traballo pendente, o obxectivo é describir o alcance xeral. A continuación, cada función define o valor comercial, os borradores dos títulos das historias, o alcance e os cambios no modelo de datos que impulsan os esforzos de desenvolvemento do código.

Ademais, ao engadir unha función crítica para a empresa, recoméndase que identifique os escenarios críticos para automatizar as probas. Despois de engadir as súas funcións, pode programar a súa reunión de aliñamento de alcance.

Reunión de alineación de ámbitos

O foco desta reunión debería limitarse a revisar cada función nova proposta e, a continuación, comprobar se hai aplicacións, escenarios ou modelos de datos existentes que xa fornecen esta funcionalidade para evitar a duplicación de esforzos. Esta reunión tamén ofrece a oportunidade de discutir o impacto noutras aplicacións. Finalmente, debe comprobar se esta función require unha revisión da experiencia.

Engada historias e un guión gráfico ao traballo pendente

Despois da reunión de aliñamento do ámbito, pódese engadir calquera borrador de títulos de historias de usuarios baixo a función. Neste momento, os detalles non son necesarios e o estado da historia do usuario é "Novo". Pode ver as historias na vista do traballo pendente ou na vista de panel.

A seguinte figura mostra unha historia de usuario de exemplo engadida a un traballo pendente.

Neste punto, é vital manter a calidade organizando o traballo por fluxo de traballo e aplicación. Este enfoque axuda a manter xuntos os elementos de traballo relacionados e permite que os expertos en cada fluxo de traballo desenvolvan e manteñan unha comprensión profunda da funcionalidade e do uso de datos dentro de cada aplicación.

Opinión sobre a experiencia

As opinións sobre a experiencia deben centrarse na experiencia do usuario final e asegurarse de que o seu equipo siga as prácticas recomendadas da organización. Esta coherencia garante que todas as súas aplicacións proporcionen unha experiencia fiable e repetible para os usuarios finais e os equipos de asistencia.

Engadir detalles do historial

Engadir unha historia de usuario típica pode incorporar a seguinte información:

1. Título: como <persona>, podo <do something> para que <impact/priority/value>
2. Descrición: a descrición inclúe (aínda que non se limita a) certos detalles clave, como:
   • Breve descrición do escenario que resume o resultado desexado
   • Narrativa: describe as accións que os usuarios realizarán para navegar e realizar o escenario
   • Narrativa alternativa: describe outras formas en que os usuarios poden lograr o mesmo resultado
   • Notas de deseño: rexistra a entidade, os campos, as vistas, as pantallas de maquetas e as regras comerciais asociadas á historia do usuario
   • Roles de seguranza afectados: enumera todos os roles de seguranza afectados ou que son relevantes para a historia do usuario.

Despois de engadir todos estes detalles, cambiaría o estado da historia do usuario a "Listo para revisar". Na maioría dos casos, o equipo de funcións e o equipo empresarial (se procede) revisan as historias dos usuarios.

Revisión da historia

As revisións da historia adoitan ocorrer dentro do equipo de fusión para asegurarse de que todos os detalles están descritos na historia e de que non haxa ambigüidade. Despois de completar todas as revisións, a recomendación é asignar a historia do usuario a un membro do equipo. Asegurar que o seu equipo estea aliñado durante o proceso de desenvolvemento é vital para acadar os seus obxectivos xerais.

Engadir tarefas e casos de proba

Despois de revisar as historias, os membros do equipo crean tarefas en Azure DevOps. O proceso xeral para engadir tarefas e casos de proba é o seguinte:

1. Abra un traballo pendente de sprint. Tamén pode crear un novo sprint.
2. Engada elementos de traballo existentes ao sprint. Se xa engadiu elementos de traballo que non aparecen no sprint, debería comprobar a súa área e as rutas de iteración. Lembre asignarlle as tarefas non asociadas aos elementos de traballo relevantes.
3. Engada tarefas aos elementos de traballo pendente. Se non ten elementos de traballo pendente asignados ao seu sprint, fágao agora. Tamén estableza as datas de inicio e finalización do sprint.
4. Encha o formulario da tarefa. Como regra xeral, as tarefas non deberían tardar máis dun día en completarse. As tarefas que superen esta escala temporal deberían desglosarse.
5. Rastrexe ou integre as tarefas non asociadas. Pode facer un seguimento das tarefas non asociadas do mesmo xeito que outras tarefas ou arrastralas a un elemento de atraso existente para asocialas.

Despois de engadir tarefas e casos de proba, pode pasar a configurar a capacidade de sprint.

Para obter máis información sobre como engadir tarefas, consulte elementos de Engadir tarefas ao traballo pendente para apoiar a planificación do sprint.

Preparar solucións

Un aspecto importante para o desenvolvemento conxunto exitoso é un proceso estruturado de xestión de versións. As solucións son o mecanismo para implementar a xestión do ciclo de vida das aplicacións (ALM); vostede usa solucións para distribuír compoñentes en ambientes mediante a exportación e a importación de actividades. Un compoñente representa un artefacto usado na súa aplicación e algo que potencialmente pode personalizar. Todo o que se pode incluír nunha solución é un compoñente, como táboas, columnas, aplicacións de lenzo e controladas por modelos, fluxos de Power Automate, bots de chat, gráficos e complementos.

Despregamentos

Os compoñentes poden levar varios sprints para completar dependendo da complexidade e da velocidade do equipo. Os compoñentes deben ser engadidos a unha solución nun ambiente de desenvolvemento a medida que se completan as tarefas. As solucións son entón importadas a un ambiente de produción despois de ser probadas. Recomendamos que tamén manteña un ambiente de proba para realizar probas de extremo a extremo e probar a implantación da solución antes de pasar á produción.

Ambientes de Power Platform

Os ambientes son un espazo para almacenar, xestionar e compartir datos empresariais, aplicacións e procesos empresariais da súa organización. Tamén serven como contedores para separar aplicacións que poidan ter diferentes funcións, requisitos de seguranza ou audiencias obxectivo.

Se a súa organización ten unha configuración de fusión de varios equipos onde cada equipo está a desenvolver as súas propias solucións, é importante coordinar a duración dos sprints e dos lanzamentos. Os sprints non teñen que ter unha duración consistente ao longo dun cronograma do proxecto e poden variar en duración entre os equipos, segundo as preferencias de cada grupo. Non obstante, a cadencia de lanzamento non pode ser inferior á duración máis curta do sprint en todos os equipos.

Control de orixe

Considere adoptar un sistema de control de código fonte como Azure DevOps. Azure DevOps fornece servizos de programadores para axudar aos equipos a planificar o traballo, colaborar no desenvolvemento de códigos e crear e implementar aplicacións.

Exporte unha solución do seu contorno de desenvolvemento que conteña as súas aplicacións e personalizacións, desempaquete a súa solución e garde os compoñentes no seu sistema de control de orixe.

Tema avanzado: comentarios de solicitudes de extracción (PR).

Só debe crear PR para historias que estean activas e que teñan funcións revisadas e aprobadas. Debe asegurarse de que a versión da solución sexa precisa, seguindo as directrices de sprint e desenvolvemento establecidas en Implementar prácticas de Scrum para o seu equipo en Azure Boards. Os resultados das probas do PR poden ser capturas de pantalla ou vídeos que mostren a funcionalidade que se está a construír.

A automatización do proceso de goberno das RP axuda a garantir a calidade do código sen requirir unha revisión manual das comprobacións básicas, como as versións da solución.

Modelos e estandarización

Os modelos e a estandarización proporcionan eficiencia ao axudar a promover a coherencia dentro do equipo. Todos os aspectos das operacións do equipo— xa sexan tarefas de incorporación, presentacións de revisión de historias ou modelos de elementos de traballo que axudan a aforrar tempo e proporcionan orientación aos equipos á hora de definir historias de usuarios, funcións, erros ou tarefas— beneficiarse da normalización e simplificación.

Implantación dun modelo de apoio eficaz

Un modelo de soporte eficaz é esencial para o éxito a longo prazo dunha aplicación despois da súa implantación, como se destacou na sección anterior sobre a xeración dunha matriz de soporte. Os erros e as interrupcións son inevitables, polo que é vital que o equipo teña un enfoque estruturado para xestionar estas ocorrencias, e a matriz de soporte proporciona o marco necesario.

Creación do acordo de nivel de servizo

Un factor clave en calquera modelo de soporte é a definición do Acordo de Nivel de Servizo (SLA). O SLA debe ser un documento formal que elabore o equipo que conteña seccións que abranguen os seguintes elementos:

• Cortes – que nivel de interrupción do servizo é aceptable, a quen informar, que accións tomar, confirmación da reanudación do servizo e accións para evitar que se repita. Calquera procedemento de proba automatizado que use o equipo debe axustarse á tolerancia de interrupción esperada e ao SLA aplicable.
• Erros – quen pode notificar, asignación de niveis de gravidade, clasificación, actuacións sobre a detección, quen é o responsable de resolver e pechar.
• Escaladas – niveis de escalada, asignación de persoal a niveis, responsabilidades en cada nivel, listas de distribución para cada nivel, etc.

O SLA debe almacenarse no portal de documentación do equipo e actualizarse segundo sexa necesario.

Ofrecer asistencia de aplicación

O mellor enfoque para ofrecer o soporte de aplicación especificado no SLA é que o equipo que creou a solución sexa tamén o responsable da súa compatibilidade. As vantaxes deste sistema son:

1. Fomenta un desenvolvemento de mellor calidade, porque os que crearon a aplicación saben que terán que apoiala.
2. Os creadores poderán atopar e corrixir erros máis rápido que un equipo de terceiros, simplemente porque coñecen mellor a aplicación.
3. Delegar a reparación de software potencialmente crítico para outro grupo pode ser desmoralizador e lento para ese grupo. Do mesmo xeito que con outras fases de creación, desenvolvemento e implantación de aplicacións, o equipo de fusión debe asociarse co equipo de TI para obter asistencia cando sexa necesario.

Monitorización da satisfacción e da usabilidade da aplicación

A parte final do esforzo de soporte é supervisar e avaliar a satisfacción e a usabilidade da aplicación implantada. As métricas son útiles aquí, xunto con métodos máis tradicionais, como as enquisas e os cuestionarios. Para obter máis información sobre o seguimento do uso da aplicación, consulte Analítica administrativa para Power Apps.

En definitiva, se os clientes non están a usar unha aplicación publicada, esa aplicación non está a cumprir o seu propósito. As reunións de revisión periódicas poden comprobar estas métricas de satisfacción e usabilidade para crear un ciclo de comentarios positivos que pode alterar ou engadir historias ao traballo pendente para xerar e, a continuación, implementar unha versión actualizada da aplicación.

Resumo

O desenvolvemento de ferramentas sen código e de baixo código como Power Apps amplía as opcións para que os tecnólogos ou creadores de empresas creen, desenvolvan e despreguen aplicacións. Este desenvolvemento funciona mellor nun ambiente de equipo de fusión, formado por un propietario do produto, un experto en dominios, un desenvolvedor profesional e un administrador, e este equipo achega outros recursos segundo sexa necesario.

A integración de enfoques de desenvolvemento áxil e scrum dentro dos equipos de fusión dá como resultado un desenvolvemento de aplicacións máis rápido e unha maior probabilidade de implantación exitosa cun conxunto de funcións que marcan unha diferenza significativa para o negocio. Ao aplicar estas mellores prácticas, directrices e recomendacións, o seu equipo de fusión poderá utilizar Power Apps para abordar os retos da transformación dixital da súa organización.