Participez à la création d’exigences en utilisant Email Monitor

Participez à la création d’exigences en utilisant Email Monitor

La fonction Email Monitor permet d’accéder à la création d’éléments de travail dans votre projet Azure DevOps via un support qui n’est pas natif à 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 concernant des exigences, des demandes de modification ou des bogues à créer, 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.

Pour les cas d’utilisation et le processus de configuration d’Email Monitor, veuillez regarder la vidéo.

 

Vous pouvez accéder à la page de configuration de Email Monitor en allant dans les paramètres Collection/Admin – Modern Requirement4DevOps Extension – Services – Email Monitor.

En activant la fonction Surveillance des courriels dans le panneau d’extension Modern Requirements4DevOps, vous pouvez spécifier une adresse courriel Surveiller qui peut intercepter et créer tout élément de travail qui lui est envoyé par courriel. Puisque le système essaiera de capturer chaque courriel envoyé au courriel de surveillance, il est conseillé d’utiliser votre courriel de surveillance uniquement à des fins de moniteur de courriel.

Vous devez également fournir une adresse courriel d’administrateur au cas où le système ne reconnaîtrait pas les courriels, et un courriel de notification sera envoyé à l’adresse courriel d’administration.

Vous pouvez spécifier quels types d’éléments de travail vous souhaitez créer dans votre projet à partir de ces courriels capturés.

Les titres des courriels envoyés au courriel du Moniteur seront toujours mappés dans les titres des éléments de travail à créer.

Projet d’équipe (par défaut) vous permet de choisir un projet par défaut où vous souhaitez ajouter les éléments de travail.

La création d’ajouts et la mise à jour des ajouts vous aident à configurer quand vous voulez ajouter l’exigence au projet.

Pour le champ Description :

Si la création d’ajout est cochée, cela signifie que le système utilisera le courriel initial pour créer un nouvel élément de travail et que le corps du courriel deviendra la description de l’élément de travail créé.

Si la mise à jour Ajout est cochée, cela signifie que la description existante de l’élément de travail créé sera supplantée par de futures réponses concernant le même élément de travail.

Pour le domaine de l’histoire :

Si l’option Création d’ajout est cochée, cela signifie que le corps du courriel initial sera mappé à la section Discussion de l’élément créé.

Si la mise à jour de l’ajout est cochée, alors toutes les réponses aller-retour concernant le même élément de travail seront ajoutées à la section Discussion.

Le nom de l’expéditeur, le courriel de l’expéditeur et le corps du courriel vous permettent de définir le contenu que vous souhaitez ajouter dans la description associée ou dans la section Discussion.

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, toute partie prenante concernée peut simplement envoyer un courriel à bugs@myorganization.com et je pourrais spécifier qu’un élément de travail de 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 au sein de 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.

D’autres scénarios pourraient t’intéresser

Ajout d’éléments de travail à des projets autres que le projet par défaut

Si l’expéditeur ne précise pas un nom de projet particulier dans le corps du courriel, le courriel mappé sera ajouté au projet par défaut. Si les expéditeurs souhaitent ajouter cette exigence à un autre projet de la même collection, ils devront inclure [NomProjet=GCD] dans le corps du courriel (GCD est un nom de projet exemple).

Types d’éléments multiples

Nous comprenons que vos parties prenantes de projet pourraient vouloir ajouter plusieurs types de postes de travail en utilisant Email Monitor. C’est aussi possible! Vous pouvez simplement sélectionner plusieurs types d’éléments de travail.  Par exemple, maintenant je sélectionne Histoire utilisateur en plus de Bogue. Lorsque votre équipe envoie des courriels à la boîte courriel de surveillance, elle peut utiliser [WIT=bug] ou [WIT=user story] dans le corps du courriel pour spécifier quel type d’élément de travail doit être l’exigence créée. Sans préciser le type d’élément de travail dans le corps du courriel, le système tentera de correspondre le courriel au type d’élément de travail, qui relève de la catégorie d’élément de travail que vous avez sélectionnée dans la section Catégorie WI .

Ajout de contenu supplémentaire à un élément de travail existant

Après que le courriel initial ait été capturé par le système, par défaut, toutes les réponses futures peuvent être ajoutées sous forme de discussions sur le même élément de travail. En plus de cela, les expéditeurs peuvent ajouter [wiid=1997] (1997 est un exemple d’identifiant d’élément de travail) dans le corps du courriel pour ajouter du nouveau contenu à l’élément de travail ciblé existant.

Bien sûr, vous pouvez utiliser plus d’une de ces commandes spéciales dans un courriel selon vos besoins.

Temps de lecture : 20 minutes

Gestion des besoins suspects avec un signalement automatique

Gestion des besoins suspects avec un signalement automatique

Lien Drapeau Sale / Suspect est une composante des services de gestion des ressources humaines (anciennement appelée Agent MR) utilisée pour identifier les éléments de travail susceptibles d’être affectés par le changement d’un élément lié afin que les parties prenantes concernées puissent examiner les éléments affectés. Par exemple, si une histoire utilisateur change dans les états actifs, alors les cas de test associés seraient marqués comme suspects.
 
La fonctionnalité Lien suspect contribue au succès de votre projet en rendant l’impact des modifications des éléments de travail à la fois interrogeables et, généralement, plus visible. Vous pouvez considérer cette fonctionnalité comme une méthode pour faire une évaluation d’impact sur l’évolution des éléments de travail au sein de votre projet.

Comment fonctionne le lien Dirty Flag / Suspect?

Cette fonction vous permet de surveiller les éléments de travail qui répondent à certaines préconditions. Lorsque ces éléments de travail changent, la fonction de surveillance marquera tous les éléments liés comme suspects.

Prenons un exemple :

L’histoire utilisateur 1 vient d’être déplacée en état « Terminé ». Si le lien suspect peut être configuré pour déclencher un drapeau si des modifications sont apportées aux histoires utilisateurs dans un état « Terminé » (c’est-à-dire un changement dans un champ tel que « 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, les éléments de travail configurés directement liés seront signalés par le Sale/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. Vous pouvez aussi personnaliser les options de colonne dans le module Items de travail et backlogs pour voir un groupe d’items de travail dont certains peuvent être marqués par le drapeau Dirty.

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.

Les balises Dirty Flag pourraient être retirées manuellement lorsque les parties prenantes concernées auront examiné l’impact et effectué les mises à jour nécessaires. Les meilleures pratiques que nous recommandons ici sont d’ajouter un autre commentaire expliquant que maintenant le Dirty Flag est retiré parce que les mises à jour nécessaires ont été effectuées ou qu’aucune mise à jour n’est requise.  

Pour plus de détails et le processus de configuration du lien Dirty Flag/Suspect, veuillez regarder la vidéo.

 
Temps de lecture : 20 minutes

Comment rendre vos identifiants de besoin plus descriptifs et distinctifs à l’aide d’un ID personnalisé

Comment rendre vos identifiants de besoin plus descriptifs et distinctifs à l’aide d’un ID personnalisé

Modern Requirements4DevOps offre la fonctionnalité d’ajouter des identifiants personnalisés aux éléments de travail. L’objectif de cette fonctionnalité est de rendre un champ Élément de travail plus lisible et reconnaissable. Par exemple, « PX-REQ-00001 » pour le premier élément de travail des exigences dans le projet X.

Notre fonction ID personnalisé offre les mêmes avantages, en plus des avantages supplémentaires d’utiliser l’ID personnalisé dans 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. Les identifiants personnalisés ne sont pas conçus pour remplacer l’identifiant de l’élément de travail, ils le complètent.

La propriété ID personnalisé offre une méthode simple pour identifier plusieurs informations nécessaires d’un élément de travail donné, toutes dans un même 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 basé sur différents types d’éléments de travail. Par exemple, le code d’un type d’élément de travail d’exigence pourrait être REQ, le code d’un type d’élément d’histoire utilisateur pourrait être US, et le code d’un type d’élément de travail de bogue pourrait être BG.

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 utilisateurs commence à 1 ou 10 000 et qu’elle augmentera ensuite l’identifiant personnalisé de chaque histoire utilisateur.

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. Scope garantit que l’ID personnalisé sera unique dans ce périmètre.

En reprenant 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 type d’élément de travail + numéro.

Pour plus de détails et le processus de configuration de Custom ID, veuillez regarder la vidéo.

 
Temps de lecture : 20 minutes