Participez à la rédaction des spécifications à l'aide d'Email Monitor

Participez à la rédaction des spécifications à l'aide d'Email Monitor

La fonctionnalité Email Monitor permet de créer des éléments de travail dans votre projet Azure DevOps via un canal qui n'est pas natif d'Azure DevOps. En d'autres termes, elle vous permet de communiquer avec votre projet par e-mail. Les équipes se retrouvent souvent confrontées à des situations où elles échangent des e-mails concernant des exigences, des demandes de modification ou des bogues qui doivent être créés, et elles parviennent souvent à utiliser ces e-mails pour aboutir à une exigence définitive qui doit être ajoutée à leur projet.

Grâce à la fonctionnalité « Email Monitor », votre équipe peut désormais transformer directement ces communications externes en tâches.

Pour découvrir les cas d'utilisation et la procédure de configuration d'Email Monitor, veuillez regarder la vidéo.

 

Vous pouvez accéder à la page de configuration d'Email Monitor en vous rendant dans Collection/Paramètres d'administration – Extension Modern Requirement4DevOps – Services – Email Monitor.

En activant la fonctionnalité « Email Monitor » dans le panneau d'extension Modern Requirements4DevOps, vous pouvez définir une adresse e-mail de surveillance capable d'intercepter et de créer tout élément de travail qui lui est envoyé par e-mail. Étant donné que le système tentera de capturer tous les e-mails envoyés à cette adresse, il est recommandé de l'utiliser exclusivement dans le cadre de la fonctionnalité « Email Monitor ».

Vous devez également fournir une adresse e-mail d'administrateur au cas où le système ne parviendrait pas à reconnaître les e-mails ; une notification sera alors envoyée à cette adresse.

Vous pouvez indiquer les types d'éléments de travail que vous souhaitez créer dans votre projet à partir de ces e-mails capturés.

Les objets des e-mails envoyés à l'adresse Monitor Email seront toujours repris dans les titres des tâches à créer.

« Projet d'équipe (par défaut) » vous permet de choisir le projet par défaut auquel vous souhaitez ajouter les éléments de travail.

Les options « Création d'extension » et « Mise à jour d'extension » vous permettent de définir à quel moment vous souhaitez ajouter l'exigence au projet.

Pour le champ « Description » :

Si la case « Créer un élément de travail » est cochée, cela signifie que le système utilisera l'e-mail initial pour créer un nouvel élément de travail et que le corps de l'e-mail deviendra la description de cet élément.

Si l'option « Ajouter lors de la mise à jour » est cochée, cela signifie que la description actuelle de l'élément de travail créé sera remplacée par les réponses ultérieures concernant ce même élément de travail.

Pour le domaine de l'histoire:

Si l'option « Ajouter lors de la création » est cochée, cela signifie que le corps du courriel initial sera associé à la section « Discussion » de l'élément de travail créé.

Si l'option « Ajouter à la mise à jour » est cochée, tous les échanges de messages concernant le même élément de travail seront ajoutés à la section « Discussion ».

Les champs « Nom de l'expéditeur », « E-mail de l'expéditeur » et « Corps du message » vous permettent de définir le contenu que vous souhaitez ajouter dans la section « Description » ou « Discussion » correspondante.

Cas d'utilisation du service de surveillance des e-mails

Le cas d'utilisation le plus courant de la fonctionnalité « Email Monitor » est le suivant :

Je dirige une grande entreprise et j'aimerais que tous les membres de mon équipe signalent les bugs qu'ils détectent dans mon logiciel dans mon projet Azure DevOps.

Une fois Email Monitor entièrement configuré avec l'adresse bugs@myorganization.com, toute personne concernée peut simplement envoyer un e-mail à bugs@myorganization.com pour que je puisse demander la création d'un ticket de bug dans mon projet.

Parallèlement, l'e-mail à l'origine de la création du bug est également envoyé aux personnes concernées par ce projet. Les membres concernés peuvent désormais participer à la discussion relative à cet élément de travail par e-mail, et tous les échanges par e-mail seront ajoutés aux propriétés « Discussion » de cet élément de travail au sein de votre projet.

Cette fonctionnalité unique permet à des personnes extérieures de contribuer à la réussite de votre projet sans avoir besoin d'un accès complet à votre projet Azure DevOps. Les intervenants externes peuvent désormais participer aux discussions relatives à un élément de travail, sans que vous ayez à leur accorder un accès à votre projet.

Voici d'autres scénarios qui pourraient vous intéresser

Ajouter des tâches à des projets autres que le projet par défaut

Si l'expéditeur n'indique pas de nom de projet spécifique dans le corps de l'e-mail, l'e-mail mappé sera ajouté au projet par défaut. Si les expéditeurs souhaitent ajouter l'exigence à un autre projet de la même collection, ils devront inclure [ProjectName=GCD] dans le corps de l'e-mail (GCD est un exemple de nom de projet).

Plusieurs types d'éléments de travail

Nous comprenons que les parties prenantes de votre projet puissent souhaiter ajouter plusieurs types d'éléments de travail à l'aide d'Email Monitor. C'est tout à fait possible ! Il vous suffit de sélectionner plusieurs types d'éléments de travail. Par exemple, je sélectionne ici « User Story » en plus de « Bug ». Lorsque votre équipe envoie des e-mails à la boîte de réception du moniteur, elle peut utiliser [WIT=bug] ou [WIT=user story] dans le corps de l'e-mail pour préciser le type d'élément de travail auquel l'exigence créée doit correspondre. Si le type de tâche n'est pas spécifié dans le corps de l'e-mail, le système tentera de mapper l'e-mail au type de tâche correspondant à la catégorie de tâches que vous avez sélectionnée dans la section « Catégorie de tâches ».

Ajouter du contenu supplémentaire à un élément de travail existant

Une fois que le système a enregistré l'e-mail initial, toutes les réponses ultérieures peuvent, par défaut, être ajoutées en tant que discussions relatives au même élément de travail. De plus, les expéditeurs peuvent ajouter [wiid=1997] (1997 étant un exemple d'identifiant d'élément de travail) dans le corps de l'e-mail pour ajouter du nouveau contenu à l'élément de travail existant concerné.

Bien sûr, vous pouvez utiliser plusieurs de ces commandes spéciales dans un e-mail, selon vos besoins.

Essayez-le dès maintenant !
Facebook Twitter LinkedIn
Durée de lecture : 20 minutes

Gestion des exigences suspectes grâce au signalement automatique

Gestion des exigences suspectes grâce au signalement automatique

« Dirty Flag / Suspect Link » est un composant de MR Services (anciennement appelé MR Agent) qui sert à identifier les éléments de travail susceptibles d'être affectés par la modification d'un élément de travail lié, afin que les parties prenantes concernées puissent examiner les éléments de travail concernés. Par exemple, si une user story passe à un état actif, les cas de test associés seront alors signalés comme suspects.
 
La fonctionnalité « Suspect Link » contribue à la réussite de votre projet en rendant l'impact des modifications apportées aux éléments de travail à la fois consultable et, de manière générale, plus visible. Vous pouvez considérer cette fonctionnalité comme un moyen d'évaluer l'impact des modifications apportées aux éléments de travail au sein de votre projet.

Comment fonctionne le système « Dirty Flag / Suspect Link » ?

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

Prenons un exemple :

L'User Story 1 vient d'être mise en état « Terminé ». Si le Suspect Link peut être configuré pour déclencher une alerte en cas de modification des User Stories en état « Terminé » (par exemple, une modification d'un champ tel que « Description »).

Cela signifie que si le champ « Description » de l'User Story 1 est modifié à l'avenir, toutes les exigences qui y sont associées seront marquées d'un indicateur « Dirty ».

Cela permet à votre équipe de détecter facilement si une exigence répondant à un certain ensemble de critères (que vous définissez) subit une modification. Une fois identifiées, les tâches configurées qui y sont directement liées seront signalées par le statut « Modifié/Suspect ».

Pour reprendre notre exemple, si le champ « Description » de l'User Story 1 venait à changer, nous pourrions marquer d'un indicateur « Dirty » tous les cas de test directement liés qui pourraient devoir être modifiés afin de tester les nouveaux critères.

Les indicateurs d'erreur activés sur ces cas de test prendraient la forme d'une balise de tâche.

Les balises s'affichent dans l'éditeur d'éléments de travail standard d'Azure DevOps. Vous pouvez également personnaliser les options de colonnes dans le module Éléments de travail et backlogs afin d'afficher un groupe d'éléments de travail dont certains peuvent être marqués par l'indicateur « Dirty ».

Lorsque le tag « Dirty Flag » est activé sur des éléments de travail, ce tag inclut à la fois l'identifiant et la révision de l'élément de travail modifié, ce qui permet à votre équipe d'identifier facilement quelle exigence a été modifiée et a déclenché la fonctionnalité « Dirty Tag / Suspect Link ».

Les balises « Dirty Flag » peuvent être supprimées manuellement une fois que les parties prenantes concernées ont examiné l'impact et procédé aux mises à jour nécessaires. Nous recommandons, dans ce cas, d'ajouter un commentaire indiquant que la balise « Dirty Flag » a été supprimée, soit parce que les mises à jour nécessaires ont été effectuées, soit parce qu'aucune mise à jour n'est requise.  

Pour plus de détails et pour connaître la procédure de configuration de Dirty Flag/Suspect Link, veuillez regarder la vidéo.

 
Essayez-le dès maintenant !
Facebook Twitter LinkedIn
Durée de lecture : 20 minutes