Govern de desenvolupament conjunt

Establir un marc de treball de govern de desenvolupament conjunt efectiu és important per garantir la coherència i la repetició en projectes definits per creadors i equips de fusió. En aquest article es descriu una manera de definir un diagrama de flux de govern.

Definició del procés d'extrem a extrem

Podeu utilitzar el procés següent com a exemple i personalitzar-lo per a les pràctiques recomanades de l'organització. No cal que completeu cada pas individual si aconseguiu el resultat necessari.

Addició de característiques al treball pendent

Els treballs pendents permeten planificar el projecte afegint característiques que impulsen l'experiència global. El treball pendent també proporciona el mapa de ruta global que l'equip vol lliurar.

Quan s'afegeix una característica nova al treball pendent, l'objectiu és descriure l'àmbit general. A continuació, cada característica defineix els canvis del valor de l'empresa, els títols de l'esborrany de la història, l'àmbit i el model de dades que impulsen els projectes de desenvolupament de codi.

A més, quan afegiu una característica crítica per a l'empresa, es recomana identificar escenaris fonamentals per automatitzar les proves. Un cop hàgiu afegit les característiques, podeu planificar la reunió de definició d'àmbit.

Reunió de definició d'àmbit

L'enfocament d'aquesta reunió s'ha de limitar a revisar cada característica nova proposada i, a continuació, comprovar si hi ha aplicacions, escenaris o models de dades existents que ja ofereixin aquesta funcionalitat per evitar la duplicitat dels esforços. Aquesta reunió també proporciona l'oportunitat de discutir l'impacte en altres aplicacions. Finalment, heu de comprovar si aquesta característica requereix una revisió de l'experiència.

Addició d'històries i guions il·lustrats als treballs pendents

Després de la reunió de definició de l'àmbit, es poden afegir tots els esborranys de títols d'històries de l'usuari a la característica. En aquest moment, els detalls no són necessaris i l'estat de la història de l'usuari és "Nou". Podeu visualitzar-les als treballs pendents o la visualització de tauler.

A la figura següent es mostra una història de mostra de l'usuari afegida als treballs pendents.

En aquest moment, és vital mantenir la qualitat organitzant la feina per seqüència de treball i per aplicació. Aquest mètode ajuda a mantenir junts els elements de treball relacionats i permet als experts de cada flux de treball desenvolupar i mantenir una comprensió completa de la funcionalitat i l'ús de dades dins de cada aplicació.

Revisió d'experiència

Les revisions d'experiència s'haurien de centrar en l'experiència de l'usuari final i garantir que l'equip segueixi les pràctiques recomanades de l'organització. Aquesta coherència garanteix que totes les aplicacions ofereixin una experiència fiable i repetible per als usuaris finals i els equips de suport.

Addició de detalls de la història

Si afegiu una història típica de l'usuari, pot incloure la informació següent:

1. Títol: com a <persona>, puc <do something> de manera que <impact/priority/value>
2. Descripció: la descripció inclou (tot i que no està limitada a) alguns detalls clau, com ara:
   • Descripció breu de l'escenari que resumeix el resultat desitjat
   • Narrativa: descriu les accions que els usuaris portaran a terme per navegar i aconseguir l'escenari
   • Narrativa alternativa: descriu altres maneres com els usuaris poden aconseguir el mateix resultat
   • Notes de disseny: registra l'entitat, els camps, les visualitzacions, les pantalles de mostra i les regles de negoci associades amb la història de l'usuari
   • Funcions de seguretat afectades: mostra totes les funcions de seguretat afectades o rellevants per a la història de l'usuari.

Després d'afegir tots aquests detalls, canviaríeu l'estat de la història de l'usuari a "A punt per a la revisió". En la majoria dels casos, l'equip de característiques i l'equip de negocis (si escau) revisen les històries de l'usuari.

Revisió d'històries

Les revisions d'històries es produeixen generalment dins de l'equip de fusions per assegurar-se que tots els detalls s'anomenen a la història i que no hi ha cap ambigüitat. Un cop completades totes les revisions, es recomana assignar un membre de l'equip a la història de l'usuari. Assegurar-vos de què l'equip es mantingui alineat durant el procés de desenvolupament és vital per aconseguir els objectius globals.

Adició de tasques i casos de prova

Després de revisar les històries, els membres de l'equip creen tasques a l'Azure DevOps. El procés global per afegir tasques i casos de prova és el següent:

1. Obriu un treball pendent d'esprint. O bé, creeu un nou esprint.
2. Afegeix elements de treball existents a l'esprint. Si ja heu afegit elements de treball que no apareixen a l'esprint, comproveu les seves rutes d'iteració i d'àrea. Recordeu-vos d'assignar les tasques sense objecte principal als elements de treball rellevants.
3. Addició de tasques dels elements de treball pendents. Si no teniu elements de treball pendents assignats a l'esprint, feu-ho ara. A més, definiu les dates d'inici i finalització de l'esprint.
4. Empleneu el formulari de la tasca. Com a regla general, les tasques no haurien de trigar més d'un dia en completar-se. Les tasques més grans que aquesta escala de temps s'han de dividir.
5. Feu el seguiment o integreu les tasques sense element principal. Podeu fer el seguiment de les tasques sense elements principals de la mateixa manera que la resta de tasques o arrossegar-les a un element de treball pendent existent per asignar-hi un element principal.

Després d'afegir tasques i casos de prova, podeu passar a definir la capacitat de l'esprint.

Per obtenir més informació sobre com afegir tasques, vegeu Addició de tasques a les tasques pendents per donar suport a la planificació de l'esprint.

Preparació de solucions

Un aspecte important per al co-desenvolupament correcte és un procés d'administració de versions estructurada. Les solucions són el mecanisme per implementar la gestió del cicle de vida de l'aplicació (ALM); utilitzeu solucions per distribuir components en diversos entorns mitjançant activitats d'exportació i importació. Un component representa un artefacte utilitzat en l'aplicació que es podria personalitzar. Tot el que es pot incloure en una solució és un component, com ara taules, columnes, llenços i aplicacions basades en models, fluxos del Power Automate, bots de xat, gràfics i complements.

Implementacions

Els components poden trigar molts esprints a completar-se en funció de la complexitat i velocitat de l'equip. Els components s'han d'afegir a una solució d'un entorn de desenvolupament com a tasques finalitzades. A continuació, les solucions s'importen a un entorn de producció un cop provades. Es recomana que també manteniu un entorn de prova per dur a terme proves d'extrem a extrem i provar la implementació de la solució abans d'anar a l'entorn de producció.

Entorns del Power Platform

Els entorns són espais on s'emmagatzemen, administren i comparteixen les dades d'empresa, les aplicacions i processos empresarials. També serveixen com a contenidors per separar aplicacions que podrien tenir diferents funcions, requisits de seguretat o públic objectiu.

Si la vostra organització té una configuració de fusions amb diversos equips on cada equip està desenvolupant les seves pròpies solucions, és important coordinar la duració dels esprints i les versions. Els esprints no han de tenir una longitud coherent al llarg d'una cronologia del projecte i la seva duració pot variar entre els equips, segons les preferències de cada grup. Tanmateix, la cadència de versions no pot ser inferior a la duració de l'esprint més breu de tots els equips.

Control d'origen

Considerar la possibilitat d'adoptar un sistema de control de codi font, com ara l'Azure DevOps. L'Azure DevOps proporciona serveis als desenvolupadors perquè puguin donar suport als equips per planificar la feina, col·laborar en el desenvolupament de codi i crear i implementar aplicacions.

Exporteu una solució des del vostre entorn de desenvolupament que contingui les vostres aplicacions i personalitzacions, desempaqueteu la solució i emmagatzemeu els components del sistema de control d'origen.

Tema avançat: Revisió de sol·licituds d'extracció (PR)

Només heu de crear sol·licituds d'extració per a les històries que són actives i tenen característiques revisades i aprovades. Cal que us assegureu que la versió de la solució sigui correcta i seguiu les directrius d'esprint i desenvolupament que s'indiquen a les pràctiques d'implementació de Scrum per al vostre equip a l'Azure Boards. Els resultats de prova de les sol·licituds d'extracció poden ser captures de pantalla o vídeos que representen la funcionalitat que s'està dissenyant.

L'automatització del procés de govern de les sol·licituds d'extracció ajuda a garantir la qualitat del codi sense haver de revisar manualment els controls bàsics, com ara les versions de la solució.

Plantilles i estandardització

Les plantilles i l'estandardització ofereixen eficiència ajudant a promoure la coherència dins de l'equip. Tots els aspectes de les operacions— de l'equip, ja siguin tasques d'incorporació, presentacions de revisió d'històries o plantilles d'elements de treball que ajuden a estalviar temps i proporcionen orientació als equips a l'hora de definir històries d'usuari, funcions, errors o tasques—, es beneficien de l'estandardització i la simplificació.

Implementació d'un model de suport efectiu

Un model de suport efectiu és essencial per a l'èxit a llarg termini d'una aplicació després de la seva implementació, tal com es destaca a la secció anterior sobre com generar una matriu de suport. Els errors i les interrupcions són inevitables, de manera que és vital que l'equip tingui un enfocament estructurat per tractar aquestes situacions, i la matriu de suport proporciona el marc de treball necessari.

Creació de l'acord de nivell de servei

Un factor clau en qualsevol model de suport és la definició de l'Acord de nivell de servei (SLA). L'SLA ha de ser un document formal elaborat per l'equip que conté seccions que cobreixen els elements següents:

• Interrupcions : quin nivell d'interrupció del servei és acceptable, a qui ha d'informar, quines accions cal dur a terme, confirmació de la represa de serveis i accions per evitar que es repeteixi. Tots els procediments de prova automatitzats que utilitza l'equip han d'alinear-se amb la tolerància d'interrupcions inesperades i l'SLA aplicable.
• Errors: qui pot notificar-los, assignació de nivells de gravetat, classificació, accions durant la detecció i qui és responsable de resoldre i tancar la sessió.
• Escalacions: nivells d'escalada, assignació de personal a nivells, responsabilitats a cada nivell, i llistes de distribució per a cada nivell, entre altres.

L'SLA s'ha d'emmagatzemar al portal de documentació de l'equip i actualitzar-se segons calgui.

Assistència tècnica per a aplicacions

La millor manera de proporcionar el suport d'aplicació especificat a l'SLA és que l'equip que ha creat la solució també sigui responsable de donar-li suport. Els avantatges d'aquest sistema són:

1. Fomenta el desenvolupament de millor qualitat, perquè els usuaris que han creat l'aplicació saben que han de proporcionar el suport.
2. Els creadors podran cercar i corregir errors més ràpidament que un equip de tercers, simplement perquè coneixen millor l'aplicació.
3. Delegar la correcció del programari potencialment crític a un altre grup pot ser desmoralitzador i una pèrdua de temps per a aquest grup. Com amb altres fases de creació, desenvolupament i implementació d'aplicacions, l'equip de fusió hauria d'associar-se amb l'equip de TI per obtenir assistència quan calgui.

Supervisió de la satisfacció i ús de l'aplicació

La part final de l'esforç de suport és supervisar i avaluar la satisfacció i l'ús de l'aplicació implementada. Les mètriques són útils aquí, juntament amb els mètodes més tradicionals, com ara el sondatge i els questionaris. Per obtenir més informació sobre la supervisió de l'ús de l'aplicació, vegeu Anàlisi d'administració per al Power Apps.

Finalment, si els clients no utilitzen una aplicació publicada, aquesta aplicació no compleix la seva finalitat. Les reunions de revisió periòdica poden comprovar aquestes mètriques de satisfacció i ús per crear un bucle de comentaris positiu que pugui modificar o afegir històries als treballs pendents per generar i després implementar una versió actualitzada de l'aplicació.

Resum

El desenvolupament d'eines sense codi i amb poc codi, com ara el Power Apps, té opcions ampliades perquè els tècnics o creadors empresarials puguin crear, desenvolupar i implementar aplicacions. Aquest desenvolupament funciona millor dins d'un entorn d'equip de fusió, que inclou un propietari de productes, un expert de domini, un desenvolupador professional i un administrador, i aquest equip aporta altres recursos segons calgui.

La integració del desenvolupament àgil i scrum dins dels equips de fusió provoca un desenvolupament més ràpid de l'aplicació i una probabilitat més alta d'implementar-la correctament amb un conjunt de característiques que marca una diferència important en el negoci. En aplicar aquestes pràctiques recomanades, directrius i recomanacions, l'equip de fusió podrà utilitzar el Power Apps per encarar els reptes de transformació digital de l'organització.