Services MR - Moniteur de courriel, ID personnalisé, Drapeau sale
Les fonctionnalités supplémentaires de Modern Requirements4DevOps
Dans cet article, nous abordons certaines des fonctionnalités supplémentaires disponibles dans l’édition Enterprise Plus de Modern Requirements4DevOps. Ces fonctionnalités sont appelées services MR.
Ces fonctionnalités offrent un contrôle accru sur les modifications apportées aux éléments du travail, vous permettent de connecter votre projet à un service de courriel et vous aident à augmenter la traçabilité et l’utilisabilité de votre projet.
Service moderne de surveillance des besoins par courriel
La fonction Email Monitor permet d’accéder à votre projet via un support qui n’existe pas dans Azure DevOps. C’est-à-dire que cela vous permet de communiquer avec votre projet par courriel. Les équipes se retrouvent souvent dans des situations où elles envoient des courriels à propos d’un élément de travail qui devrait être créé, et elles peuvent souvent utiliser les courriels pour atteindre une exigence concluante qui devrait être ajoutée à leur projet.
Avec la fonction Surveillance des courriels, votre équipe peut maintenant transformer cette communication externe en un élément de travail directement.
En activant la fonction Email Monitor dans le panneau d’extension Modern Requirements4DevOps, vous pouvez spécifier une adresse courriel capable d’intercepter et de construire toutes les exigences qui lui sont envoyées par courriel.
Cas d’utilisation du service de surveillance de courriels
Le cas d’utilisation le plus courant de la fonction Email Monitor est le suivant :
J’ai une grande organisation et j’aimerais que tous les membres de mon organisation ajoutent tout bogue qu’ils trouvent dans mon logiciel à mon projet Azure DevOps.
Avec Email Monitor entièrement configuré avec le bugs@myorganization.com, n’importe quel membre de mon organisation peut simplement envoyer un courriel à bugs@myorganization.com et je peux spécifier qu’un bogue doit être créé dans mon projet.
En même temps, le courriel qui a déclenché la création du bogue est aussi envoyé aux personnes concernées de ce projet. Les membres concernés peuvent maintenant participer à la discussion de cet élément de travail par courriel, et toutes les communications par courriel seront ajoutées aux propriétés de discussion de cet élément de travail dans votre projet.
Cette fonctionnalité unique permet aux gens de contribuer au succès de votre projet sans avoir à accéder pleinement à votre projet Azure DevOps. Des parties externes peuvent maintenant participer à la discussion sur un Élément de Travail, et ne vous obligent plus à donner accès à votre projet.
Liens Drapeau Sale / Suspects
La fonctionnalité Drapeau Sale / Lien suspect contribue au succès de vos projets en rendant l’impact des modifications des éléments de travail à la fois interrogeable et, en général, plus visible.
Cette fonctionnalité vise implicitement à mettre en évidence toute exigence qui pourrait être affectée par le changement d’une exigence liée. Vous pouvez considérer cette fonctionnalité comme une méthode pour évaluer l’impact sur l’évolution des exigences au sein de votre projet.
Comment fonctionnent Dirty Flag / Suspect Links?
Cette fonctionnalité vous permet de surveiller les éléments de travail qui respectent certaines conditions. Lorsque ces éléments de travail changent, la fonction de surveillance marque tous les éléments de travail liés.
Prenons un exemple :
L’histoire utilisateur 1 vient d’être déplacée en état « Terminé ». Si les liens Dirty Flag / Suspect peuvent être configurés pour déclencher un drapeau si des modifications sont apportées aux histoires utilisateur dans un état « Terminé » (c’est-à-dire un changement à un champ comme « Description »)
Cela signifie que si le champ Description de l’Histoire d’utilisateur 1 est modifié à l’avenir, il marquera toutes les exigences qui y sont liées avec un Drapeau Sale.
Cela permet à votre équipe d’identifier facilement si une exigence correspondant à un certain ensemble de critères (que vous spécifiez) change. Une fois identifiés, tous les éléments de travail directement liés seront signalés par la capacité Signal Sale / Lien suspect.
Pour poursuivre notre exemple, si le champ Description de l’Histoire utilisateur 1 changeait, nous pourrions signaler un Dirty Flag de tous les cas de test directement liés qui pourraient devoir être modifiés pour tester les nouveaux critères.
Les drapeaux sales qui s’activent sur ces cas de test prendraient la forme d’une étiquette Objet de travail.
Les balises apparaissent dans l’éditeur Standard Work Item d’Azure DevOps.
Dans le cas de l’étiquette Dirty Flag qui est définie sur les éléments de travail, l’étiquette appliquée inclut à la fois l’ID de l’élément de travail modifié et la révision, afin que votre équipe puisse facilement identifier quelle exigence a modifié et déclenché la fonctionnalité Dirty Tag / Suspect Link.
Identifiants personnalisés
De nombreuses applications offrent la possibilité d’ajouter des identifiants personnalisés aux éléments de travail. L’objectif de ce type de fonctionnalité est de rendre un champ plus lisible et reconnaissable.
Notre fonctionnalité ID personnalisé offre les mêmes avantages, tout comme les avantages supplémentaires d’utiliser le module Requêtes.
Les identifiants personnalisés peuvent être configurés comme une propriété personnalisée qui existe sur chacun de vos éléments de travail.
La propriété ID personnalisé offre une méthode simple pour identifier toutes les informations nécessaires d’un élément de travail donné, toutes dans un seul champ. Il s’avère aussi être un outil incroyablement utile pour identifier une source d’exigences dans les requêtes inter-projets.
En vous permettant de consolider l’information dans un seul champ, vous rendez un élément de travail plus accessible aux utilisateurs moins impliqués. La capacité Custom ID suit les directives suivantes :
- Les éléments de travail peuvent se voir attribuer un code unique. Par exemple, le code d’un type d’élément de travail d’exigence serait REQ et le code d’un élément d’histoire utilisateur serait US.
- Vous pouvez créer le nombre de départ que vos types d’articles de travail augmenteront par la suite. Par exemple, vous pouvez dicter que la numérotation des identifiants personnalisés des histoires utilisateur commence à 00001 et qu’elle incrémentera l’ID personnalisé de chaque histoire utilisateur par la suite.
- Vous pouvez aussi ajouter un préfixe de projet optionnel pour n’importe quel ID personnalisé. Par exemple, un nom de projet comme « Projet X » pourrait avoir le préfixe PX.
- Enfin, vous pouvez choisir d’inclure la portée de tout élément de travail. Le numéro ID n’est pas répété dans le scope; la portée peut être Équipe, Projet ou Collection.
En utilisant l’exemple présenté dans la directive ci-dessus, un identifiant personnalisé pour le premier élément de travail (00001) dans le projet X serait « PX-REQ-00001 » – qui est une concaténation du préfixe du projet + code de l’élément + numéro
Demandez une démonstration!
- Planifiez une démonstration avec l’un de nos experts produits formés.
- Recevez une démo personnalisée qui imite le processus de votre équipe
- Engagez nos experts sur des sujets tels que le flux de travail ou les meilleures pratiques.
Réduire les efforts de l’UAT
Réduction de 50% des efforts de l’UAT
Économie de temps éprouvée
80% de gain de temps sur la création d’une analyse de traces
Approbations simplifiées
Réduction significative des délais d’approbation
Augmenter la performance
50% des besoins d’amélioration de la productivité
Réduction de la refonte
Réduction de 10 fois dans la refonte du développement
Simplifier la conformité
Réduction de 40% des efforts de rapport sur la conformité
