Arbeitselementtypen und Workflow von CMMI-Prozessen in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Teams verwenden die Arbeitselementtypen (Work Item Types, WITs), die mit dem Prozess „MSF for CMMI Process Improvement 2015 (CMMI)“ bereitgestellt werden, um den Fortschritt von Softwareprojekten zu planen und nachzuverfolgen. Teams definieren Anforderungen zur Verwaltung des Arbeitsbacklogs und verwenden dann Ihr Kanban-Board, um den Fortschritt nachzuverfolgen, indem sie den Anforderungsstatus aktualisieren.
Um Einblick in ein Anforderungsportfolio zu erhalten, können Produktbesitzer Funktionen Zuordnungsanforderungen zuordnen. Wenn Teams in Iterationen arbeiten, definieren sie Aufgaben, die automatisch mit Anforderungen verknüpft sind.
Mithilfe von Microsoft Test Manager und dem Webportal können Tester*innen Testfälle erstellen und ausführen sowie Fehler definieren, mit denen sich defekter Code nachverfolgen lässt.
Um weitere CMMI-Prozesse zu unterstützen, können Teams Änderungsanforderungen, Risiken, Issues und Hinweise, die in den Reviewbesprechungen erfasst wurden nachverfolgen. Wenn Sie noch nicht mit dem CMMI-Prozess vertraut sind, lesen Sie zunächst den Abschnitt Planen und Nachverfolgen der Arbeit mit CMMI.
Definieren von Anforderungen
Erstellen Sie Anforderungen im Bereich zum schnellen Hinzufügen auf der Product Backlog-Seite. Später können Sie jede Anforderung öffnen, um weitere Details bereitzustellen und die Größe zu schätzen.
Sie können Anforderungen auch per Massenvorgang mithilfe einer CVS-Datei hinzufügen.
Wichtig
Microsoft Project Integration und der Befehl TFSFieldMapping
werden nicht unterstützt für:
- Visual Studio 2019 und Azure DevOps Office-Integration 2019.
- Azure DevOps Server 2019 und höher, einschließlich Azure DevOps Services.
Die volle Unterstützung für die Integration von Microsoft Excel wird beibehalten und erlaubt den Massenimport und die Aktualisierung von Arbeitsaufgaben. Alternativen zur Verwendung von Microsoft Project sind:
- Lieferpläne
- Marketplace-Erweiterungen wie Project Connect oder GANTT-Diagramm.
Anforderungen geben Funktionen und Produktelemente an, die die Teams erstellen müssen. Produktbesitzer definieren und priorisieren Anforderungen auf der Product Backlog-Seite. Das Team schätzt dann den erforderlichen Aufwand zur Bereitstellung der Elemente mit der höchsten Priorität.
Orientieren Sie sich beim Ausfüllen des Formulars am folgenden Leitfaden und am Leitfaden für Felder, die in allen Arbeitselementtypen verwendet werden. Weitere Informationen finden Sie unter Planen eines Projekts.
Feld
Verwendung
Geben Sie genug Details zur Einschätzung des Arbeitsaufwands zur Implementierung der Anforderung an. Konzentrieren Sie sich auf die vorgesehenen Anwender der Anforderung: Was soll erreicht werden, und weshalb? Beschreiben Sie nicht, wie die Anforderung entwickelt werden soll. Stellen Sie ausreichende Informationen bereit, damit das Team Aufgaben und Testfälle schreiben kann, um das Element zu implementieren.
In HTML-Felder können Sie Rich Text und Images hinzufügen.
Die Auswirkungen für Kunden, wenn die Anforderung nicht implementiert wird. Sie können auch Details zum Kano-Modell einschließen, um anzugeben, ob es sich um eine Basis-, Leistungs- oder Begeisterungsanforderung handelt. Erfassen Sie diese Informationen im Rich Text-HTML-Feld, das der Bewertung der Auswirkungen entspricht.
Anforderungstyp (erforderlich)
Die Art der Anforderung, die implementiert werden soll. Sie können einen der folgenden Werte angeben:
- Geschäftszielvorstellung
- Feature (Standard)
- Funktionsbereit
- Schnittstelle
- Betriebsbereit
- Servicequalität
- Schutz
- Szenario
- Security
Der Bereich des Kundennutzens, der durch das Epic, das Feature, die Anforderung oder das Backlog Item abgedeckt wird. Mögliche Werte:
- Architektonisch: Technische Dienste zur Implementierung von Business-Funktionen zur Lösung
- Geschäft: Dienste, die die Anforderungen von Kund*innen und Projektbeteiligten erfüllen und so direkt einen Mehrwert für Kund*innen schaffen und zur Unterstützung des Unternehmens beitragen (Standardwert)
Geben Sie den geschätzten Arbeitsaufwand zum Abschließen einer Anforderung in der vom Team bevorzugten numerischen Maßeinheit an. Durch Definieren der Größe für Anforderungen können Teams anhand der Agile-Geschwindigkeitsdiagramme und Vorhersagetools zukünftige Iterationen oder den Arbeitsaufwand einschätzen. Das kumulative Flussdiagramm verweist auf die Werte in diesem Feld. Weitere Informationen finden Sie im Whitepaper zur Schätzung.
Der geschätzte Arbeitsaufwand, der zum Abschluss einer Aufgabe erforderlich ist. In der Regel wird dieses Feld nicht geändert, nachdem es zugewiesen ist.
Sie können die Arbeit in Stunden oder in Tagen angeben. Es gibt keine inhärenten Zeiteinheiten, die diesem Feld zugeordnet sind.
Die Stichdaten für den Beginn bzw. das Ende der Arbeit.
Priorität (erforderlich)
Eine subjektive Bewertung der Anforderung und ihrer Auswirkungen auf das Geschäft. Zulässige Werte sind:
- 1: Das Produkt darf nicht ohne das Element ausgeliefert werden.
- 2: (Standard) Das Produkt darf nicht ohne das Element ausgeliefert werden, das Problem muss jedoch nicht unmittelbar behandelt werden.
- 3: Die Implementierung des Elements ist optional und hängt von Ressourcen, Zeit und Risiko ab.
Selektierung (erforderlich)
Gibt den Typ der Selektierungsentscheidung an, die für das Arbeitselement ausstehend ist. Verwenden Sie dieses Feld, wenn das Arbeitselement den Zustand „Vorgeschlagen“ aufweist, und geben Sie einen der folgenden Werte an: Ausstehend (Standard), Weitere Informationen, Informationen empfangen und Selektiert.
Gibt an, ob ein Teammitglied daran gehindert wird, Fortschritte bei der Implementierung einer Anforderung oder Aufgabe oder beim Beheben eines Fehlers, Problems, einer Änderungsanforderung oder eines Risikos zu machen. Wenn ein Problem geöffnet wurde, um ein Blockierungsproblem nachzuverfolgen, können Sie einen Link zum betreffenden Problem erstellen. Sie können Ja oder Nein angeben.
Zugesichert (erforderlich)
Gibt an, ob ein Commit für die Anforderung im Projekt ausgeführt wird. Sie können Ja oder Nein (Standardwert) angeben.
Nummer des Produktbuilds, der die Anforderung bzw. die Änderungsanforderung enthält oder einen Fehler behebt.
Benutzerakzeptanztest (erforderlich)
Der Status des Benutzerakzeptanztests für eine Anforderung. Sie können einen der folgenden Werte angeben:
- Erfolgreich
- Fehler
- Nicht bereit (Standard)
- Bereit
- Übersprungen
- Informationen empfangen
Geben Sie Nicht bereit an, wenn die Anforderung den Zustand Aktiv aufweist, und Bereit, wenn die Anforderung den Zustand Gelöst aufweist.
Die Namen von Teammitgliedern, die vertraut sind mit dem Kundenbereich, den diese Anforderung darstellt.
Erfassen von Kommentaren im Abschnitt „Diskussion“
Im Abschnitt Diskussion können Sie Kommentare zur durchgeführten Arbeit hinzufügen und überprüfen.
Die Symbolleiste des Rich-Text-Editors wird unter dem Texteingabebereich angezeigt, wenn Sie den Cursor in ein Textfeld setzen, das die Textformatierung unterstützt.
Hinweis
Es gibt kein Arbeitselementfeld „Diskussion”. Filtern Sie zum Abfragen von Arbeitselementen mit Kommentaren aus dem Bereich „Diskussion“ nach dem Feld Verlauf. Der gesamte Inhalt des Texts, der in das Textfeld „Diskussion“ eingegeben wurde, wird dem Feld „Verlauf“ hinzugefügt.
Erwähnen einer Person, einer Gruppe, eines Arbeitselements oder eines Pull Requests
Wählen Sie eines der folgenden Symbole aus, um ein Menü der letzten Einträge zu öffnen, in denen Sie jemanden erwähnt, ein Arbeitselement oder einen Pull Request verknüpft haben. Alternativ können Sie dasselbe Menü öffnen, indem Sie @
, #
oder !
eingeben.
Geben Sie einen Namen oder eine Nummer ein, um die Menüliste nach Ihrem Eintrag zu filtern. Wählen Sie den Eintrag aus, den Sie hinzufügen möchten. Um eine Gruppe in die Diskussion zu bringen, geben Sie @
gefolgt vom Gruppennamen ein (z. B. ein Team oder eine Sicherheitsgruppe).
Bearbeiten oder Löschen eines Kommentars
Um Ihre Diskussionskommentare zu bearbeiten oder zu löschen, wählen Sie Bearbeiten oder das Aktionssymbol () und dann Löschen aus.
Hinweis
Zum Bearbeiten und Löschen von Kommentaren ist Azure DevOps Server 2019 Update 1 oder höher erforderlich.
Nachdem Sie den Kommentar aktualisiert haben, wählen Sie Aktualisieren aus. Um den Kommentar zu löschen, bestätigen Sie, dass Sie ihn löschen möchten. Auf der Registerkarte Verlauf im Arbeitselementformular wird ein vollständiger Überwachungspfad aller bearbeiteten und gelöschten Kommentare beibehalten.
Wichtig
Bei einer lokalen Azure DevOps Server-Bereitstellung konfigurieren Sie einen SMTP-Server, damit Teammitglieder Benachrichtigungen empfangen.
Hinzufügen einer Reaktion auf einen Kommentar
Fügen Sie einem Kommentar Reaktionen hinzu, indem Sie in der oberen rechten Ecke des Kommentars ein Smileysymbol auswählen. Alternativ können Sie die Symbole am unteren Rand eines Kommentars auswählen, die neben vorhandenen Reaktionen angezeigt werden. Um Ihre Reaktion zu entfernen, wählen Sie die Reaktion unten im Kommentar aus. Die folgende Abbildung zeigt ein Beispiel für das Hinzufügen einer Reaktion und die Anzeige von Reaktionen zu einem Kommentar.
Speichern eines Kommentars ohne Speichern des Arbeitselements
Hinweis
Diese Funktion ist ab Azure DevOps Server 2022.1 verfügbar.
Wenn Sie nur die Berechtigung haben, Kommentare zur Diskussion für ein Arbeitselement hinzuzufügen, können Sie dies tun, indem Sie Kommentare speichern. Diese Berechtigung wird über Bereichspfadknoten und die Berechtigung zum Bearbeiten von Arbeitselementkommentaren in diesem Knoten gesteuert. Weitere Informationen finden Sie unter Festlegen von Berechtigungen für die Arbeitsnachverfolgung – Erstellen untergeordneter Knoten, Ändern von Arbeitselementen unter einem Bereichs- oder Iterationspfad.
Nachdem Sie die Kommentare gespeichert haben, müssen Sie das Arbeitselement nicht mehr speichern.
Hinweis
Wenn Sie Änderungen am Steuerelement Diskussion speichern, wird nur der Kommentar gespeichert. Es werden keine Arbeitselementregeln ausgeführt, die für den Arbeitselementtyp definiert sind.
Nachverfolgen des Arbeitsfortschritts
Im Verlauf der Arbeit ändern Sie das Feld „Zustand“, um den Status zu aktualisieren. Optional können Sie einen Grund angeben. Die Felder „Zustand“ und „Grund“ werden im Kopf des Arbeitselementformulars angezeigt.
CMMI-Workflowstatus
Diese Diagramme zeigen die wichtigsten Fortschritts- und Regressionszustände für die Anforderung, den Fehler und Aufgaben-WITs.
Anforderung | Bug | Aufgabe |
---|---|---|
Der typischer Workflowablauf für eine Anforderung ist:
- Produktbesitzer*innen erstellen eine Anforderung mit dem Zustand Vorgeschlagen mit dem Standardgrund Neue Anforderung.
- Produktbesitzer*innen aktualisieren den Status auf Aktiv, wenn mit der Implementierung begonnen wird.
- Das Team aktualisiert den Status auf Gelöst, wenn die Codeentwicklung abgeschlossen ist und Systemtests bestanden wurden.
- Abschließend verschiebt das Team oder ein*e Produktbesitzer*in die Anforderung in Geschlossen, wenn die jeweiligen Produktbesitzer*innen zustimmen, dass sie entsprechend den Akzeptanzkriterien implementiert wurde und alle Validierungstests bestanden wurden.
Aktualisieren des Arbeitsstatus mit einem Board oder Taskboards
Teams können auf dem Board den Status von Anforderungen und auf dem Sprint-Taskboard den Status von Aufgaben aktualisieren. Wenn Elemente in eine neue Zustandsspalte gezogen werden, werden sowohl das Feld „Zustand“ als auch das Feld „Grund“ aktualisiert.
Sie können das Board anpassen, um weitere Swimlanes oder Spalten zu unterstützen.
Zuordnen von Anforderungen zu Funktionen
Wenn Sie eine Sammlung von Produkten oder Benutzererfahrungen verwalten, sollten Sie den Umfang und den Status der Arbeit für das Produktportfolio anzeigen. Sie können den Anzeigebereich festlegen, in dem Sie Features definieren und diesen Features Anforderungen zuordnen.
Mithilfe von Portfolio Backlogs können Sie einen Drilldown zwischen Backlogs durchführen, um den gewünschten Detailgrad anzuzeigen. Außerdem können Sie Portfolio Backlogs verwenden, um einen teamübergreifenden Rollup der in Bearbeitung befindlichen Aufgaben anzuzeigen, wenn Sie eine Hierarchie von Teams einrichten.
Das Featurearbeitselement enthält ähnliche Felder, die für Anforderungen bereitgestellt werden, und umfasst weitere Felder, wie in der folgenden Tabelle beschrieben.
Definieren von Aufgaben
Wenn das Team die Arbeiten in Sprints verwaltet, können sie die Sprint-Backlog-Seite verwenden, um die Arbeit in verschiedene Aufgaben zu untergliedern.
Geben Sie der Aufgabe einen Namen und schätzen Sie die dafür erforderliche Arbeit.
Wenn Teams den Arbeitsaufwand einschätzen, definieren sie Aufgaben und schätzen die Stunden oder die Tage, die zum Abschließen der Aufgaben erforderlich sind. Die Teams planen die Arbeit und definieren die Aufgaben zu Beginn jeder Iteration. Dabei führt jedes Teammitglied einen Teil dieser Aufgaben aus. Zu Aufgaben zählen Entwicklung, Tests und andere Arbeitsschritte. Zum Beispiel kann ein Entwickler Aufgaben definieren, um Anforderungen zu implementieren, und ein Tester kann Aufgaben definieren, um Testfälle zu schreiben und auszuführen. Das Verknüpfen von Aufgaben mit Anforderungen und Fehlern ergibt Informationen zum Fortschritt dieser Elemente. Weitere Informationen finden Sie unter Iterationsaktivitäten.
Feld
Verwendung
Wählen Sie die Art der zu implementierenden Aufgabe aus folgenden zulässigen Werten aus:
Korrekturmaßnahme
Entschärfungsaktion
Geplant
Wählen Sie die Fachrichtung aus, die diese Aufgabe darstellt, wenn das Team die Sprintkapazität nach Aktivität schätzt.
Analyse
Entwicklung
Test
Dokumentation/Hilfe
Benutzerfreundlichkeit
Dieses Feld wird auch zur Berechnung der Kapazität nach Fachrichtung verwendet. Es wird type="Activity"
in der ProcessConfiguration-Datei zugewiesen. (2)
Weitere Informationen finden Sie unter Implementieren von Entwicklungsaufgaben.
Der geschätzte Arbeitsaufwand, der zum Abschluss einer Aufgabe erforderlich ist. In der Regel wird dieses Feld nicht geändert, nachdem es zugewiesen ist.
Der Arbeitsaufwand, der zum Abschluss einer Aufgabe noch erforderlich ist. Aktualisieren Sie dieses Feld im Verlauf der Arbeit. Es wird zum Berechnen von Kapazitätsdiagrammen, des Sprint-Burndowndiagramm und des Sprint-Burndownberichts verwendet. Wenn Sie eine Aufgabe in Unteraufgaben unterteilen, geben Sie Stunden nur für die Unteraufgaben an. Sie können die Arbeit in einer die oft ausgegebene Befehlszeilen Maßeinheit angeben, ganz nach Wunsch des Teams.
Der Arbeitsaufwand, der zum Implementieren einer Aufgabe erforderlich war.
Nachverfolgen des Teststatus
Testanforderungen
Über das Webportal oder Test Manager können Sie Testfälle erstellen, die automatisch mit einer Anforderung oder einem Fehler verknüpft werden. Alternativ können Sie eine Anforderung über (Registerkarte „Links“) mit einem Testfall verknüpfen.
Der Testfall enthält zahlreiche Felder, von denen viele automatisiert und in Test Manager und den Buildprozess integriert sind. Eine Beschreibung der einzelnen Felder finden Sie unter Erstellen einer Abfrage basierend auf Build- und Testintegrationsfeldern.
Auf (Registerkarte „Links“) werden alle Anforderungen und Fehler in einem Testfall aufgelistet. Durch die Verwendung von Verknüpfungen kann das Team den Fortschritt beim Testen der einzelnen Elemente verfolgen und unterstützt die Informationen, die im Bericht zur Anforderungsübersicht angezeigt werden.
Nachverfolgen von Codefehlern
Sie können Fehler über das Webportal, Visual Studio oder beim Testen mit Test Manager erstellen.
Nachverfolgen von Änderungsanforderungen, Risiken, Problemen und Anmerkungen, die in den Überprüfungsbesprechungen erfasst werden
Zusammen mit den Anforderungs-, Feature-, Aufgaben- und Fehler-WITs können Sie die vom CMMI-Prozess empfohlenen Informationen mit den folgenden WITs nachverfolgen.
- Änderungsanforderung zum Verwalten vorgeschlagener Änderungen an einem Arbeitsprodukt, das sich unter der Änderungssteuerung befindet.
- Issue zum Nachverfolgen eines Ereignisses oder einer Situation, das bzw. die die Arbeit am Produkt blockieren könnte oder derzeit blockiert. Issues unterscheiden sich von Risiken dahingehend, dass Teams Issues in der Regel spontan, z. B. während der täglichen Teambesprechung, feststellen.
- Risiko zum Nachverfolgen der Wahrscheinlichkeit und des Ausmaßes der Abweichung zwischen tatsächlichen und gewünschten Ergebnissen. Wenn Sie Risiken managen, minimieren Sie strategisch die Abweichung zwischen dem gewünschten Ergebnis und dem tatsächlichen Ergebnis.
- Bewertung zum Dokumentieren der Ergebnisse einer Entwurfsüberprüfung oder eines Code Reviews. Teammitglieder können Details zur Einhaltung von Standards durch den Entwurf oder Code im Hinblick auf Namenskorrektheit, Coderelevanz, Erweiterbarkeit, Codekomplexität, algorithmische Komplexität und Codesicherheit erfassen.
Sie können ein Issue über das Widget „Neues Arbeitselement“, das einem Teamdashboard hinzugefügt wurde, oder über das Menü Neu auf der Seite „Abfragen“ hinzufügen.
Arbeitselemente, die Sie über das Widget hinzufügen, werden automatisch auf den Standardbereich und die Iterationspfade Ihres Teams beschränkt. Informationen zum Ändern des Teamkontexts finden Sie im Artikel zum Wechseln des Teamkontexts.
Definitionen für allgemeine Felder zur Arbeitsnachverfolgung
In den meisten Arbeitselementen werden folgende Felder und Registerkarten angezeigt. Auf jeder Registerkarte werden bestimmte Informationen nachverfolgt, z. B. Verlauf, Links oder Anhänge. Diese drei Registerkarten enthalten einen Änderungsverlauf, eine Ansicht der verknüpften Arbeitselemente sowie Funktionen zum Anzeigen und Anfügen von Dateien.
Das einzige Pflichtfeld für alle Arbeitselementtypen ist Titel. Wenn Sie eine Arbeitsaufgabe speichern, weist das System ihr eine eindeutige ID zu. Das Pflichtfeld ist im Formular gelb hervorgehoben. Informationen zu allen anderen Feldern finden Sie im Index der Arbeitselementfelder.
Hinweis
Je nach Anpassungen, die Sie an Ihrem Prozess und Projekt vornehmen, gibt es möglicherweise weitere Pflichtfelder.
Feld/Registerkarte
Verwendung
Geben Sie eine höchstens 255 Zeichen lange Beschreibung ein. Sie können den Titel später jederzeit ändern.
Weisen Sie die Arbeitsaufgabe dem für die Bearbeitung zuständigen Teammitglied zu.
Wenn das Arbeitselement erstellt wird, wird für den Zustand standardmäßig der erste Zustand im Workflow festgelegt. Aktualisieren Sie den Wert im Verlauf der Arbeit mit dem aktuellen Zustand.
Verwenden Sie zunächst die Standardeinstellung. Aktualisieren Sie den Wert bei Zustandsänderungen. Jeder Zustand ist einem Standardgrund zugeordnet.
Wählen Sie den zum Produkt oder Team gehörenden Bereichspfad aus, oder lassen Sie dieses Feld leer, bis ein entsprechender Pfad bei einer Planungsbesprechung zugewiesen wird. Informationen zum Ändern der Dropdownliste mit den Bereichen finden Sie unter Definieren von Bereichspfaden und Zuweisen zu einem Team.
Wählen Sie den Sprint oder die Iteration aus, in dem bzw. der die Arbeit abgeschlossen werden soll, oder lassen Sie dieses Feld leer, und legen Sie es später bei einer Planungsbesprechung fest. Informationen zum Ändern der Dropdownliste mit den Iterationen finden Sie unter Definieren von Iterationspfaden (Sprints) und Konfigurieren von Teamiterationen.
Überprüfen Sie den vom System erfassten Audit-Trail, und zeichnen Sie zusätzliche Informationen auf.
Bei jeder Aktualisierung des Arbeitselements werden dem Verlauf Informationen hinzugefügt. Der Verlauf enthält das Datum der Änderung, die Person, die die Änderung vorgenommen hat, sowie die geänderten Felder. Sie können dem Verlaufsfeld auch formatierten Text hinzufügen.
Fügen Sie beliebige Linktypen hinzu, z. B. Hyperlinks, Changesets, Quelldateien usw.
Auf dieser Registerkarte werden auch alle Links aufgeführt, die für das Arbeitselement definiert sind.
Geben Sie ausführlichere Informationen frei, indem Sie der Arbeitsaufgabe Dateien hinzufügen, z. B. E-Mail-Threads, Dokumente, Bilder, Protokolldateien oder andere Dateitypen.
Anpassen von Arbeitsaufgabentypen
Bei den meisten Arbeitselementtypen können Sie Felder hinzufügen, den Workflow ändern, benutzerdefinierte Regeln hinzufügen und dem Arbeitselementformular benutzerdefinierte Seiten hinzufügen. Sie können auch benutzerdefinierte Arbeitselementtypen hinzufügen. Weitere Informationen finden Sie unter Anpassen eines Vererbungsprozesses.
Bei den meisten Arbeitselementtypen können Sie Felder hinzufügen, den Workflow ändern, benutzerdefinierte Regeln hinzufügen und dem Arbeitselementformular benutzerdefinierte Seiten hinzufügen. Sie können auch benutzerdefinierte Arbeitselementtypen hinzufügen. Weitere Informationen finden Sie je nach Prozessmodell Ihres Projekts unter Anpassen eines Vererbungsprozesses oder Anpassen des lokalen XML-Prozessmodells.
Verwandte Artikel
- Erstellen eines Projekts
- Hinzufügen von Arbeitsaufgaben zum Verwalten eines Projekts
- Erstellen eines Backlogs
- Verwalten des Zugriffs auf bestimmte Features
- Informationen zu Standardberechtigungen und Zugriffsebenen für Azure Boards
Reihenfolge der Backlogliste
Das Feld Stapelrang wird verwendet, um die relative Rangfolge von Anforderungen, Features oder Epics nachzuverfolgen. Standardmäßig wird es jedoch nicht im Arbeitselementformular angezeigt. Die Reihenfolge der Elemente auf der Backlogseite richtet sich danach, wo die Elemente auf der Seite hinzugefügt bzw. wohin sie verschoben wurden. Wenn Sie Elemente durch Ziehen verschieben, aktualisiert ein Hintergrundprozess dieses Feld.
Dieses Feld wird nicht im Arbeitselementformular angezeigt.