MR-Dienste – E-Mail-Überwachung, benutzerdefinierte ID, Markierung als ungültig
Die zusätzlichen Funktionen von Modern Requirements4DevOps
In diesem Artikel stellen wir einige der zusätzlichen Funktionen vor, die in der Enterprise Plus-Edition von Modern Requirements4DevOps verfügbar sind. Diese Funktionen werden als MR Services bezeichnet.
Diese Funktionen bieten Ihnen mehr Kontrolle über Änderungen an Arbeitselementen, ermöglichen die Anbindung Ihres Projekts an einen E-Mail-Dienst und tragen dazu bei, die Rückverfolgbarkeit und Benutzerfreundlichkeit Ihres Projekts zu verbessern.
Moderner E-Mail-Überwachungsdienst
Die Funktion „E-Mail-Monitor“ ermöglicht den Zugriff auf Ihr Projekt über einen Kanal, der in Azure DevOps nicht vorhanden ist. Das heißt, Sie können per E-Mail mit Ihrem Projekt kommunizieren. Teams geraten häufig in Situationen, in denen sie per E-Mail über ein Workitem kommunizieren, das erstellt werden soll, und oft gelingt es ihnen, mithilfe von E-Mails eine endgültige Anforderung zu formulieren, die in ihr Projekt aufgenommen werden sollte.
Mit der E-Mail-Monitor-Funktion kann Ihr Team diese externe Kommunikation nun direkt in ein Arbeitselement umwandeln.
Wenn Sie die Funktion „E-Mail-Monitor“ im Erweiterungsfenster von „Modern Requirements4DevOps“ aktivieren, können Sie eine E-Mail-Adresse angeben, an die gesendete Anforderungen abgefangen und erfasst werden.
Anwendungsfall für den E-Mail-Monitor-Dienst
Der häufigste Anwendungsfall für die E-Mail-Monitor-Funktion ist folgender:
Ich leite eine große Organisation und möchte, dass alle Mitglieder meiner Organisation alle Fehler, die sie in meiner Software finden, in mein Azure DevOps-Projekt eintragen.
Sobald Email Monitor vollständig mitbugs@myorganization.com konfiguriert ist, kann jedes Mitglied meiner Organisation einfach eine E-Mail anbugs@myorganization.comsenden, und ich kann festlegen, dass in meinem Projekt ein Fehlerbericht erstellt werden soll.
Gleichzeitig wird die E-Mail, die zur Erstellung des Fehlers geführt hat, auch an die zuständigen Personen des Projekts gesendet. Die zuständigen Mitglieder können nun per E-Mail an der Diskussion zu diesem Arbeitselement teilnehmen, und die gesamte E-Mail-Kommunikation wird den Diskussionseigenschaften dieses Arbeitselements in Ihrem Projekt hinzugefügt.
Dank dieser einzigartigen Funktion können andere Personen zum Erfolg Ihres Projekts beitragen, ohne vollständigen Zugriff auf Ihr Azure DevOps-Projekt zu benötigen. Externe Personen können nun an der Diskussion zu einem Workitem teilnehmen, ohne dass Sie ihnen Zugriff auf Ihr Projekt gewähren müssen.
Verdächtige Links
Die Funktion „Dirty Flag / Suspect Link“ trägt zum Erfolg Ihres Projekts bei, indem sie die Auswirkungen von Änderungen an Arbeitselementen sowohl abfragbar als auch generell besser erkennbar macht.
Diese Funktion dient dazu, alle Anforderungen, die von der Änderung einer verknüpften Anforderung betroffen sein könnten, automatisch hervorzuheben. Sie können diese Funktion als eine Methode betrachten, um die Auswirkungen von Anforderungsänderungen in Ihrem Projekt zu bewerten.
Wie funktioniert „Dirty Flag / Verdächtige Links“?
Mit dieser Funktion können Sie Workitems überwachen, die bestimmte Bedingungen erfüllen. Wenn sich diese Workitems ändern, markiert die Überwachungsfunktion alle damit verknüpften Workitems.
Betrachten wir einmal ein Beispiel:
Die User Story 1 wurde soeben in den Status „Abgeschlossen“ versetzt. Wenn das „Dirty Flag“ bzw. die „Verdächtigen Links“ so konfiguriert werden können, dass sie eine Markierung auslösen, sobald Änderungen an User Stories im Status „Abgeschlossen“ vorgenommen werden (z. B. eine Änderung an einem Feld wie „Beschreibung“)
Das bedeutet, dass, wenn das Feld „Beschreibung“ von User Story 1 in Zukunft geändert wird, alle damit verknüpften Anforderungen mit einem „Dirty Flag“ markiert werden.
Auf diese Weise kann Ihr Team leicht erkennen, ob sich eine Anforderung, die bestimmte (von Ihnen festgelegte) Kriterien erfüllt, ändert. Sobald dies festgestellt wird, werden alle direkt damit verknüpften Arbeitselemente durch die Funktion „Dirty Flag / Suspect Link“ gekennzeichnet.
Um bei unserem Beispiel zu bleiben: Wenn sich das Feld„Beschreibung“in User Story 1 ändern würde, könnten wir alle direkt verknüpften Testfälle mit einem „Dirty Flag“ versehen, die möglicherweise geändert werden müssen, um die neuen Kriterienänderungen zu testen.
Die „Dirty Flags“, die für diese Testfälle gesetzt werden, würden die Form eines Work-Item-Tags annehmen.
Tags werden im Standard-Workitem-Editor von Azure DevOps angezeigt.
Wenn bei Arbeitselementen das „Dirty Flag“-Tag gesetzt wird, enthält dieses Tag sowohl die ID des geänderten Arbeitselements als auch dessen Revisionsnummer, sodass Ihr Team leicht erkennen kann, welche Anforderung geändert wurde und die „Dirty Flag“- bzw. „Suspect Link“-Funktion ausgelöst hat.
Benutzerdefinierte IDs
Viele Anwendungen bieten die Möglichkeit, Workitems benutzerdefinierte IDs hinzuzufügen. Der Zweck einer solchen Funktion besteht darin, ein Feld übersichtlicher und besser erkennbar zu machen.
Unsere Funktion „Benutzerdefinierte ID“ bietet dieselben Vorteile sowie die zusätzlichen Vorteile der Nutzung des Moduls „Abfragen“.
Benutzerdefinierte IDs können als benutzerdefinierte Eigenschaft eingerichtet werden, die für jedes Ihrer Arbeitselemente gilt.
Die Eigenschaft „Benutzerdefinierte ID“ bietet eine einfache Möglichkeit, alle erforderlichen Informationen zu einem bestimmten Workitem in einem einzigen Feld zusammenzufassen. Außerdem erweist sie sich als äußerst nützliches Werkzeug, um bei projektübergreifenden Abfragen die Quelle einer Anforderung zu ermitteln.
Indem Sie die Informationen in einem Feld zusammenfassen, machen Sie ein Work Item für weniger involvierte Benutzer zugänglicher. Die Funktion „Benutzerdefinierte ID” entspricht den folgenden Richtlinien:
- Arbeitsaufgaben können einen eindeutigen Code zugewiesen werden. So lautet beispielsweise der Code für den Arbeitsaufgabentyp „Anforderung“ REQ und der Code für den Arbeitsaufgabentyp „User Story“ US.
- Sie können die Startnummer festlegen, ab der Ihre Work-Item-Typen fortlaufend nummeriert werden. Sie können beispielsweise festlegen, dass die Nummerierung der benutzerdefinierten IDs für User Stories bei 00001 beginnt und die benutzerdefinierte ID jeder User Story fortlaufend erhöht wird.
- Sie können auch ein optionales Projektpräfix für jede benutzerdefinierte ID hinzufügen. Beispielsweise könnte einem Projektnamen wie „Projekt X“ das Präfix PX zugewiesen werden.
- Schließlich können Sie den Umfang eines beliebigen Arbeitselements angeben. Die ID-Nummer wird im Umfang nicht wiederholt; als Umfang kommen „Team“, „Projekt“ oder „Sammlung“ in Frage.
Anhand des in der obigen Richtlinie behandelten Beispiels würde eine benutzerdefinierte ID für das erste (00001) Anforderungs-Workitem in Projekt X „PX-REQ-00001“ lauten – dies ist eine Verkettung aus dem Projektpräfix + dem Workitem-Code + der Nummer
Fordern Sie eine Demo an!
- Vereinbaren Sie eine Vorführung mit einem unserer geschulten Produktexperten.
- Erhalten Sie eine personalisierte Demo, die den Prozess Ihres Teams nachahmt.
- Beauftragen Sie unsere Experten zu Themen wie Workflow oder Best Practices.
Reduzieren Sie den Aufwand für UAT
50 % weniger Aufwand für UAT
Bewährte Zeitersparnis
80 % Zeitersparnis bei der Erstellung von Trace-Analysen
Genehmigungen optimieren
Deutliche Verringerung der Verzögerungen bei der Genehmigung
Leistung steigern
50 % Anforderungen Produktivitätssteigerung
Nacharbeit reduzieren
10-fache Reduzierung der Entwicklungsnacharbeiten
Vereinfachung der Compliance
40 % weniger Aufwand für die Compliance-Berichterstattung
