Les entreprises de dispositifs médicaux d’aujourd’hui sont mises au défi comme jamais auparavant. Le marché des dispositifs médicaux croît d’environ 5% composé chaque année. KPMG, dans un rapport récent, a estimé que ce marché atteindra environ 800 milliards de dollars d’ici 2030.
Continuer la lecture
Les clients Microsoft Azure dans le monde entier ont maintenant accès à Modern Requirements4DevOps pour profiter de l’évolutivité, de la fiabilité et de l’agilité d’Azure afin de stimuler le développement d’applications et d’orienter les stratégies d’affaires.
Continuer la lecture
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lecture
Dans ce blogue, nous allons partager quelques points saillants apportés à certains de nos modules ainsi que quelques améliorations d’outils dans Modern Requirements, pour votre commodité.
Continuer la lecture
Dans cet article, nous allons vous montrer comment certaines entreprises éliminent tous les défis du développement de produits grâce à une solution simple de gestion des exigences : Modern Requirements4DevOps.
Continuer la lecture
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lecture
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lecture
En tant qu’administrateur, vous pouvez contrôler la façon dont les utilisateurs accèdent et interagissent avec leurs projets Modern Requirements4DevOps en appliquant des paramètres administrateurs.
Continuer la lecture
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.
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.
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.
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.
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.
End-to-end requirements management in Azure DevOps.
AI-powered assistance for DevOps workflows.
Autonomous AI agents for DevOps execution.
Real-time data sync across tools and systems.
