Gouvernance du co-développement

Établir un cadre de gouvernance de co-développement efficace est une partie essentielle pour assurer la cohérence et la répétabilité des projets définis par les créateurs et Fusion Teams. Cet article décrit une approche pour définir un organigramme de gouvernance.

Définir le processus de bout en bout

Vous pouvez utiliser le processus suivant comme exemple et le personnaliser en fonction des bonnes pratiques de votre organisation. Il n’est pas nécessaire de terminer chaque étape, tant que vous atteignez le résultat requis.

Ajouter des fonctionnalités au backlog

Les backlogs vous permettent de planifier votre projet en ajoutant des fonctionnalités qui pilotent l’expérience globale. Le backlog fournit également la feuille de route globale que l’équipe a l’intention de livrer.

Au moment de l’ajout d’une nouvelle fonctionnalité au backlog, l’objectif est de décrire la portée générale. Chaque fonctionnalité définit ensuite la valeur commerciale, les projets de titres d’histoire, la portée et les modifications du modèle de données qui orientent les efforts de développement du code.

De plus, lors de l’ajout d’une fonctionnalité critique pour l’entreprise, il est recommandé d’identifier tous les scénarios critiques pour automatiser vos tests. Après avoir ajouté vos fonctionnalités, vous pouvez programmer votre réunion d’alignement de portée.

Réunion d’alignement de la portée

L’objectif de cette réunion doit être limité à l’examen de chaque nouvelle fonctionnalité proposée, puis à la vérification des applications, scénarios ou modèles de données existants qui fournissent déjà cette fonctionnalité afin d’éviter la duplication des efforts. Cette réunion est également l’occasion de discuter de l’impact sur d’autres applications. Enfin, vous devez vérifier si cette fonctionnalité nécessite un bilan d’expérience.

Ajouter des récits et un plan conceptuel au backlog

Après la réunion d’alignement de la portée, tous les projets de titres de témoignage utilisateur peuvent être ajoutés sous la fonctionnalité. À ce stade, les détails ne sont pas requis et le statut du témoignage utilisateur est « Nouveau ». Vous pouvez afficher les récits dans la vue de backlog ou de tableau.

La figure suivante montre un exemple de témoignage utilisateur ajouté à un backlog.

À ce stade, il est essentiel de maintenir la qualité en organisant le travail par flux de travail et application. Cette approche permet de regrouper les éléments de travail associés et permet aux experts de chaque flux de travail de développer et de maintenir une compréhension approfondie des fonctionnalités et de l’utilisation des données dans chaque application.

Évaluation de l’expérience

Les évaluations d’expérience doivent se concentrer sur l’expérience de l’utilisateur final et garantir que votre équipe suit les bonnes pratiques organisationnelles. Cette cohérence garantit que toutes vos applications offrent une expérience fiable et reproductible aux utilisateurs finaux et aux équipes d’assistance.

Ajouter des détails au récit

L’ajout d’un témoignage utilisateur classique peut incorporer les informations suivantes :

1. Titre : En tant que <persona>, je peux <do something> afin que <impact/priority/value>
2. Description : La description inclut (mais sans s’y limiter) certains détails clés, tels que :
   • Brève description du scénario qui résume le résultat souhaité
   • Description - décrit les actions que les utilisateurs entreprendront pour naviguer et accomplir le scénario
   • Autre description - décrit d’autres façons dont les utilisateurs peuvent atteindre le même résultat
   • Notes de conception - enregistre l’entité, les champs, les vues, les écrans de maquette et les règles métier associées au témoignage utilisateur
   • Rôles de sécurité concernés - répertorie tous les rôles de sécurité concernés ou pertinents pour le témoignage utilisateur.

Après avoir ajouté tous ces détails, vous devez changer l’état du témoignage utilisateur sur « Prêt pour examen ». Dans la plupart des cas, l’équipe technique et l’équipe commerciale (le cas échéant) examinent les témoignages utilisateur.

Examen du récit

Les examens de récit se produisent généralement au sein de l’équipe de fusion pour s’assurer que tous les détails sont mentionnés dans le récit et qu’il n’y a pas d’ambiguïté. Une fois tous les examens terminés, il est recommandé d’attribuer le témoignage utilisateur à un membre de l’équipe. S’assurer que votre équipe reste alignée pendant le processus de développement est essentiel pour atteindre vos objectifs globaux.

Ajouter des tâches et des cas de test

Après avoir examiné les récits, les membres de l’équipe créent des tâches dans Azure DevOps. Le processus global d’ajout de tâches et de cas de test est le suivant :

1. Ouvrez un backlog de sprint. Vous pouvez également créer un sprint.
2. Ajoutez des éléments de travail existants au sprint. Si vous avez déjà ajouté des éléments de travail qui n’apparaissent pas dans le sprint, vous devez vérifier leur zone et leurs chemins d’itération. N’oubliez pas d’attribuer toutes les tâches non apparentées aux éléments de travail pertinents.
3. Ajoutez des tâches aux éléments du backlog. Si vous n’avez pas d’éléments de backlog affectés à votre sprint, faites-le maintenant. Définissez également les dates de début et de fin du sprint.
4. Complétez le formulaire de tâche. En règle générale, les tâches ne devraient pas prendre plus d’une journée. Les tâches qui dépassent cette échelle de temps doivent être décomposées.
5. Suivez ou intégrez toutes les tâches non apparentées. Vous pouvez suivre les tâches non apparentées comme les autres tâches ou les faire glisser vers un élément de backlog existant pour les parenter.

Après avoir ajouté des tâches et des cas de test, vous pouvez ensuite définir la capacité de sprint.

Pour plus d’informations sur l’ajout de tâches, voir les éléments Ajouter des tâches au backlog pour soutenir la planification de sprint.

Préparer des solutions

Un aspect important d’un co-développement réussi est un processus structuré de gestion des versions. Les solutions sont le mécanisme de mise en œuvre de la gestion de cycle de vie de l’application (ALM) ; vous les utilisez pour distribuer des composants dans des environnements via des activités d’exportation et d’importation. Un composant représente un artefact utilisé dans votre application et un élément que vous pouvez vous permettre de personnaliser. Tout ce qui peut être inclus dans une solution est un composant, tel que des tables, des colonnes, des canevas et des applications pilotées par modèle, des flux Power Automate, chatbots, graphiques et plug-ins.

Déploiements

Les composants peuvent prendre plusieurs sprints pour se terminer en fonction de la complexité et de la vitesse de l’équipe. Les composants doivent être ajoutés à une solution dans un environnement de développement au fur et à mesure que les tâches sont terminées. Les solutions sont ensuite importées dans un environnement de production après avoir été testées. Nous vous recommandons également de gérer un environnement de test pour effectuer des tests de bout en bout et tester le déploiement de la solution avant de passer en production.

Environnements Power Platform

Les environnements sont un espace pour stocker, gérer et partager les données métier, les applications et les processus métier. Ils servent également de conteneurs pour séparer des applications qui pourraient avoir différents rôles, exigences de sécurité ou publics cibles.

Si votre organisation a une configuration de fusion multi-équipes où chaque équipe développe ses propres solutions, il est important de coordonner la durée des sprints et des versions. Les sprints n’ont pas besoin d’être d’une durée constante le long d’un calendrier de projet et peuvent varier en durée entre les équipes, selon les préférences de chaque groupe. Cependant, la cadence de publication ne peut pas être inférieure à la durée de sprint la plus courte pour toutes les équipes.

Contrôle de source

Envisagez d’adopter un système de contrôle du code source comme Azure DevOps. Azure DevOps fournit des services de développement pour que les équipes de support planifient le travail, collaborent au développement de code et créent et déploient des applications.

Exportez une solution de votre environnement de développement contenant vos applications et personnalisations, décompressez votre solution et stockez les composants dans votre système de contrôle de code source.

Avancé sujet : Examens des demandes d’extraction (PR)

Vous ne devez créer des relations publiques que pour les histoires actives et dont les fonctionnalités ont été examinées et approuvées. Vous devez vous assurer que la gestion des versions de la solution est exacte, en suivant les directives de sprint et de développement définies dans Implémenter les pratiques Scrum pour votre équipe dans Azure Boards. Les résultats des tests du PR peuvent être des captures d’écran ou des vidéos qui décrivent la fonctionnalité en cours de construction.

L’automatisation du processus de gouvernance des relations publiques permet de garantir la qualité du code sans nécessiter un examen manuel des vérifications de base telles que les versions de la solution.

Modèles et standardisation

Les modèles et la standardisation assurent l’efficacité en aidant à promouvoir la cohérence au sein de l’équipe. Tous les aspects des opérations de l’équipe, qu’il s’agisse de tâches d’intégration, de présentations de révision de récit ou de modèles d’élément de travail qui permettent de gagner du temps et de fournir des conseils aux équipes au moment de la définition des témoignages utilisateur, des fonctionnalités, des bugs ou des tâches - bénéficiez de la standardisation et de la simplification.

Mettre en place un modèle d’accompagnement efficace

Un modèle de support efficace est essentiel pour le succès à long terme d’une application après son déploiement, comme souligné dans la section précédente sur la génération d’une matrice de support. Les bugs et les pannes sont inévitables, il est donc essentiel que l’équipe ait une approche structurée pour faire face à ces événements, et la matrice de support fournit le cadre nécessaire.

Créer le contrat de niveau de service

Un facteur clé dans tout modèle de support est la définition du contrat de niveau de service (SLA). Le SLA doit être un document formel rédigé par l’équipe et contenant des sections couvrant les éléments suivants :

• Pannes : quel niveau d’interruption de service est acceptable, qui informer, quelles actions entreprendre, confirmation de la reprise du service et actions pour empêcher une répétition. Toutes les procédures de test automatisées utilisées par l’équipe doivent s’aligner sur la tolérance aux pannes attendue et sur le SLA applicable.
• Bogues : qui peut notifier, attribution des niveaux de gravité, classification, actions en cas de détection, qui est responsable de la résolution et de la signature.
• Escalades : niveaux d’escalade, affectation du personnel aux niveaux, responsabilités à chaque niveau, listes de distribution pour chaque niveau, etc.

Le SLA doit être stocké dans le portail de documentation de l’équipe et mis à jour si nécessaire.

Livraison du support pour les applications

La meilleure approche pour fournir le support applicatif spécifié dans le SLA est que l’équipe qui a créé la solution soit également responsable de son support. Les avantages de ce système sont :

1. Cela encourage un développement de meilleure qualité, car ceux qui ont créé l’application savent qu’ils vont devoir la supporter.
2. Les créateurs pourront trouver et corriger les bogues plus rapidement qu’une équipe tierce, simplement parce qu’ils connaissent mieux l’application.
3. Déléguer la réparation de logiciels potentiellement critiques à un autre groupe peut être démoralisant et chronophage pour ce groupe. Comme pour les autres phases de création, de développement et de déploiement d’applications, l’équipe de fusion doit s’associer au service informatique pour obtenir de l’aide si nécessaire.

Suivi de la satisfaction et de l’utilisabilité des applications

La dernière partie de l’effort de support consiste à surveiller et à évaluer la satisfaction et la convivialité de l’application déployée. Les métriques sont utiles ici, ainsi que des méthodes plus traditionnelles, telles que les sondages et les questionnaires. Pour plus d’informations sur la surveillance de l’utilisation des applications, consultez Analyse de l’administrateur pour Power Apps.

En fin de compte, si les clients n’utilisent pas une application publiée, cette application ne remplit pas son objectif. Des réunions d’examen régulières peuvent vérifier ces mesures de satisfaction et d’utilisabilité pour créer une boucle de rétroaction positive qui peut modifier ou ajouter des récits au backlog pour générer puis déployer une version mise à jour de l’application.

Synthèse

Le développement d’outils no-code et low-code tels que Power Apps a élargi les options pour les spécialistes des technologies d’entreprise ou les fabricants pour créer, développer et déployer des applications. Ce développement fonctionne mieux dans un environnement d’équipe de fusion, comprenant un propriétaire de produit, un expert du domaine, un développeur professionnel et un administrateur, cette équipe apportant d’autres ressources selon les besoins.

L’intégration d’approches de développement Agile et Scrum dans Fusion Teams se traduit par un développement d’applications plus rapide et une probabilité plus élevée de déploiement réussi avec un ensemble de fonctionnalités qui fait une différence significative pour l’entreprise. En appliquant ces bonnes pratiques, lignes directrices et recommandations, votre équipe de fusion pourra utiliser Power Apps pour répondre aux enjeux de transformation numérique de votre organisation.