Jira-Workflows: Erstellen Sie benutzerdefinierte Workflows, die zur Arbeitsweise Ihres Teams passen

1. Einführung in den Kurs: Willkommen zu diesem Kurs rund um Jira-Workflows. Mein Name ist Dan Lefeb und in diesem Kurs lernen wir, wie Sie benutzerdefinierte Workflows erstellen , die der tatsächlichen Arbeitsweise Ihres Teams entsprechen Am Ende dieses Kurses werden Sie in der Lage sein, Workflows an verschiedene Arbeitstypen wie Ideen, Aufgaben und Fehler anzupassen wie Ideen, Aufgaben und Fehler Sie können jeweils ihren eigenen Workflow in Ihren Jira Spaces haben Workflow in Ihren Jira Spaces Wir werden auch lernen , wie du Einschränkungen hinzufügst, sodass nur bestimmte Personen bestimmte Übergänge durchführen können Wir werden lernen, wie Daten validiert werden, bevor ein Übergang zwischen zwei verschiedenen Status stattfindet Wir werden auch lernen, wie Sie Aufgaben mit Aktionen und KI-Agenten automatisieren , Workflows mithilfe von Workflow-Schemata in Ihrem Bereich bereitstellen, Ihren Workflow mit agilen Boards verbinden und vieles mehr Dieser Kurs konzentriert sich auf vom Unternehmen verwaltete Bereiche, sodass Sie die volle Kontrolle über Workflows und Schemata haben. Das bedeutet auch, dass wir über globale Administratorrechte verfügen werden, um Workflows für unsere gesamte Jira-Instanz konfigurieren zu können unsere gesamte Jira-Instanz Wenn Sie nun von Teams verwaltete Bereiche verwenden, werden Sie trotzdem von den meisten Lektionen in diesem Kurs profitieren, da der Workflow-Editor in von Teams verwalteten Bereichen genauso funktioniert wie in unternehmensverwalteten Bereichen, die wir in diesem Kurs verwenden Am Ende dieses Kurses verfügen Sie über einen voll funktionsfähigen Status-Workflow mit Einschränkungen, Validierungen, automatisierten Aktionen und KI-Agenten, die in Ihrem Bereich eingesetzt werden Bevor wir uns nun mit Jira befassen, sollten wir uns einen Moment Zeit nehmen, um uns über die Kernkonzepte der Workflows von Jira zu verständigen. Darauf werden wir in unserer nächsten Lektion eingehen 2. Kernkonzepte von Jira-Workflows: In dieser Lektion werden wir uns mit den Kernkonzepten der Workflows von Jira befassen, bevor wir uns der Jira-Oberfläche selbst befassen Jeder Workflow in Jira besteht aus zwei Hauptteilen: Status und Transitionen Status geben an, wo sich ein Arbeitselement in seinem Lebenszyklus befindet Die grundlegenden Status lauten „Zu erledigen“ und „Erledigt“. Aber wir können sie erweitern, indem wir beliebige benutzerdefinierte Status erstellen, wie z. B. Codeüberprüfung, bereit für die Qualitätssicherung, QA-Tests oder blockiert, solche Dinge Vor diesem Hintergrund gehört jeder Status, unabhängig davon, welchen Status wir erstellen, zu einer von drei Kategorien Diese Kategorien sind „In Bearbeitung“ und „Erledigt“. Wir können zwar keine benutzerdefinierten Kategorien in Jira erstellen, aber sie dienen hauptsächlich der Backend-Organisation von Jira , damit sie bestimmen kann, welche Art von benutzerdefiniertem Status wir erstellen Im Grunde genommen gehört jeder benutzerdefinierte Status, den wir erstellen, zu einer dieser drei Kategorien, und das bestimmt dann, wie Jira weiß, wann bestimmte Dinge zu tun Wenn sich beispielsweise etwas in der Kategorie „Erledigt“ befindet, weiß Jira, dass die Arbeit abgeschlossen ist Egal, ob Sie den Status erledigt oder abgeschlossen oder wie auch immer wir ihn für den benutzerdefinierten Status nennen, weil er in der Kategorie erledigt ist, Jira weiß, dass die Arbeit erledigt ist Übergänge stellen die Aktion dar, ein Arbeitselement von einem Status in einen anderen verschoben Technisch gesehen handelt es sich bei einem einzelnen Übergang um eine Bewegung in eine Richtung. Wenn wir zwischen zwei Status hin und her wechseln wollen, benötigen wir zwei separate Übergänge Vor diesem Hintergrund gibt es einige Möglichkeiten, wie wir es Jira ermöglichen können , Status in jede Richtung zu ändern, und das werden wir uns in diesem Kurs ansehen Aber seien Sie sich bewusst, dass es sich im Backend technisch gesehen um zwei verschiedene Übergänge handelt, wenn wir die Arbeit von „Zu erledigen“ auf „ In Bearbeitung“ und dann wieder auf „ Zu erledigen“ verschieben erledigen wenn wir die Arbeit von „Zu erledigen“ auf „ In Bearbeitung“ und dann wieder auf „ Zu Einer von „erledigt“ zu „In Bearbeitung und dann ein anderer von „ In Bearbeitung“ zurück zu „Zu erledigen“. Das ist wichtig, weil wir Jira sagen können welche Art von Dingen wir mit jedem dieser Übergänge machen wollten mit jedem dieser Übergänge machen Wenn wir möchten, dass das Arbeitselement etwas anderes macht , wenn es von „In Bearbeitung“ zu „In Bearbeitung“ wechselt, und dann, wenn es von „ In Bearbeitung“ zurück zu „erledigt“ wechselt Wie Sie sich vorstellen können, können die Dinge ziemlich schnell komplex werden. Daher ist es wichtig , eine solide Namenskonvention für unsere Status und Übergänge zu entwickeln eine solide Namenskonvention für unsere Status und Übergänge So werden wir wissen, was jeder einzelne bedeutet und was er tut. Und hier sind ein paar Tipps für den Einstieg. Nummer eins: Verwenden Sie klare, konsistente Namen. Die Überprüfung des Codes ist besser als Überprüfungsphase oder sogar die Entwicklungsphase. Das führt zu Nummer zwei. Vermeiden Sie sich überschneidende Bedeutungen. Wenn wir beides in der Entwicklung und im Gange haben , kann das verwirrend sein Da es sich jedoch um separate Status „In Bearbeitung“ und „Codeüberprüfung“ handelt, weiß unser Team, welcher Status „aktive Entwicklung“ und welcher Status „Übergabe“ bedeutet Und als Jure-Administrator kehren wir vielleicht in Monaten oder Jahren zu einem Workflow zurück und erinnern uns nicht mehr daran , wofür er verwendet wird wenn sich diese Status Als kleinen Bonus-Tipp: Falls Sie es noch nicht getan haben, fangen Sie an, eine Dokumentation über unsere Namenskonventionen zu erstellen Auf diese Weise können wir, falls wir uns aus irgendeinem Grund dafür entscheiden, ähnlich klingende Status festzulegen, in Zukunft auf diese zurückgreifen, um zu erfahren, warum wir uns für etwas Bestimmtes entschieden haben Und wenn deine Organisation das Dokumentationstool Confluence von Atlassian verwendet , ist das ein großartiger Ort, um die gesamte Dokumentation zu Namenskonventionen zu speichern Drittens: Halte es einfach. Fügen Sie nicht eine Menge Status nur um zu versuchen, die Dinge zu überorganisieren Fügen Sie zunächst das Nötigste hinzu und holen Sie sich dann in den kommenden Wochen und Monaten Feedback von unserem Team ob wir es hilfreich finden würden , weitere zum Workflow hinzuzufügen Fügen Sie vielleicht ein oder zwei weitere Dinge hinzu und schauen Sie dann, ob das hilft Wenn nicht, Entfernung. Wenn ja, behalte es. Je mehr wir in unserem Arbeitsablauf haben, desto komplexer wird er, und wir wollen nicht, dass Dinge unwartbar werden. Wenn Sie Jira schon eine Weile verwenden, sind Sie vielleicht an eine ältere Terminologie gewöhnt, die sich Updates ein wenig geändert hat In diesem Kurs werden wir also auf vier Arten von Workflow-Regeln stoßen, und die Bedingungen für diese Regeln haben sich geändert Erstens haben wir die Restrict Transition-Regeln. Diese wurden früher Bedingungen genannt. Diese kontrollieren, wer einen Übergang sehen und nutzen kann. Wenn ein Benutzer die Einschränkung nicht erfüllt, kann er nicht zwischen den Status wechseln Als Nächstes haben wir die Regeln für die Eingabe von Anfragen , die während eines Übergangs einen Bildschirm öffnen, in dem der Benutzer aufgefordert wird, bestimmte Felder auszufüllen , bevor der Übergang fortgesetzt Darauf werden wir später in diesem Kurs eingehen Es ist wie ein freundlicherer Cousin eines Validators, der zur Eingabe von Daten auffordert, anstatt zur Eingabe von Daten Und dann haben wir die Regeln für die Validierung von Details. Diese wurden früher Validatoren genannt. Diese prüfen, ob die erforderlichen Daten vorhanden sind, bevor sie den Übergang zulassen Es ist also strenger als nur nach Eingaben zu fragen. Beispielsweise muss das Feld mit der festen Version festgelegt werden , bevor ein Arbeitselement geschlossen wird. Und das werden wir uns später in diesem Kurs noch einmal ansehen. Dann haben wir die Regeln zum Ausführen von Aktionen. Diese wurden früher als Post-Funktionen bezeichnet. Diese werden automatisch ausgeführt, nachdem ein Übergang abgeschlossen ist. Sie aktualisieren Felder, weisen Benutzer oder sie können KI-Agenten auslösen, und wir werden uns später in diesem Kurs damit befassen. Nun gibt es auch etwas, das Sie in Bezug auf Berechtigungen beachten sollten. Ein Benutzer benötigt mehr als nur Workflow-Berechtigungen , um ein Arbeitselement zu verschieben. Sie müssen auch in der Lage sein, das Arbeitselement selbst zu bearbeiten. Wenn Sie also Einschränkungen testen, stellen Sie sicher, dass Sie einen Benutzer verwenden, der mindestens über grundlegende Bearbeitungsberechtigungen für diesen Arbeitstyp verfügt . Um es noch einmal zusammenzufassen Workflows bestehen aus Status und Übergängen Jeder Status gehört zu einer Kategorie, die das Erscheinungsbild des Boards bestimmt Übergängen handelt es sich um unidirektionale Aktionen zwischen Status, und es gibt vier Arten von Regeln , die wir für Übergänge verwenden können Sie können einschränken, wer diesen Übergang durchführen kann, und können während eines Übergangs Eingaben anfordern Sie können Daten vor der Umstellung validieren und nach der Umstellung Aktionen ausführen In unserer nächsten Lektion werden wir nun zu Jira springen, um einen Standard-Workflow in einen benutzerdefinierten zu konvertieren, und dann beginnen wir mit der Entwicklung 3. Konfigurieren benutzerdefinierter Status und Übergänge: In dieser Lektion werden wir mit Jira beginnen und damit beginnen, unsere eigenen benutzerdefinierten Status und unsere eigenen benutzerdefinierten Status und Übergänge zu erstellen, um unseren Softwareentwicklungs-Workflow unseren Softwareentwicklungs-Workflow Gehen wir zunächst zum Workflow-Editor. Nun, es gibt zwei Möglichkeiten , wie wir dorthin gelangen können. Wir können unsere Raumeinstellungen durchgehen. Also können wir zu diesen drei kleinen Punkten kommen, zu den Raumeinstellungen gehen. Und das ist praktisch. Wenn wir bereits in unserem spezifischen Bereich arbeiten, können wir zu dem Workflow wechseln , den dieser Bereich verwendet. Aber da wir in diesem Kurs zum ersten Mal in Jira und wir als globaler Jira-Administrator arbeiten, gehen wir die globalen Jira-Einstellungen durch, in denen wir alle Workflows in unserer gesamten Instanz sehen und verwalten können Workflows in unserer gesamten So können wir zu den Einstellungen und zu den Arbeitselementen zurückkehren Und dann hier auf der linken Seite, wenn wir zu unseren Workflows kommen, werden uns all die Workflows angezeigt , die wir in unserer Jira-Instanz haben Jetzt arbeiten wir mit einem Bereich namens Softwareentwicklung, dieser hier. Das ist also der Arbeitsablauf, der in diesem Bereich verwendet wird. Lassen Sie uns auf drei Punkte eingehen. Kommen Sie runter zur Bearbeitung, und das bringt uns zum Workflow-Editor. Ich werde das schließen, nur um uns etwas mehr Platz zu geben , damit wir den Editor hier sehen können. Jetzt können wir hier die Standardstatus und Übergänge aus der Scrum-Vorlage sehen und Übergänge aus der Scrum-Vorlage Das ist die Vorlage, die ich verwendet habe, als ich diesen Bereich erstellt habe Wir müssen es im Gange und fertig machen. Und dann hier oben müssen wir anfangen, richtig? Also werde ich die Strg-Taste gedrückt halten und mein Mausrad benutzen, um die Ansicht zu vergrößern damit wir es etwas einfacher sehen können. Also hier haben wir den Anfang. Und das ist nicht wirklich ein Status, aber es ist der Beginn ein neues Arbeitselement gestartet wird, oder? Wenn es also anfängt, durchläuft es diese Erstellungsübergänge, und das teilt Jira mit, wenn Sie ein neues Arbeitselement erstellen, wohin es geht? In diesem Fall wird standardmäßig Status „ Zu erledigen“ zugewiesen Wenn wir das nun ändern wollten, müssten wir nur diesen Übergang hier auswählen und ihn dann in einen anderen Status verschieben. Nehmen wir an, wir möchten , dass er im Gange ist. Wenn wir nun innerhalb dieses Bereichs ein neues Arbeitselement erstellen würden , wäre es in Bearbeitung sobald wir diesen Workflow aktualisieren. Warum, realistisch betrachtet, macht das natürlich nicht viel Sinn Lassen wir das für diesen Status bei zu erledigen. Und das ist ein gutes Argument denn bevor wir viele Änderungen im Workflow-Editor vornehmen , würde ich Ihnen dringend empfehlen, sich die Zeit zu nehmen, genau das zu skizzieren , was Sie in Ihrem Workflow benötigen. Wenn Sie also hier sind, wissen Sie bereits, was Sie tun werden, oder haben eine Vorstellung davon, wie alles zusammenhängt. Wenn Sie jetzt Confluence zusammen mit Jira verwenden, können Sie deren digitale Whiteboards verwenden Das ist ein großartiger Ort, um das zu tun, indem Sie jeden Status und jede Transition sehr locker zeichnen , bevor Sie hier reinkommen und sie dann im Workflow-Editor funktionsfähig machen Natürlich können Sie die Dinge später jederzeit ändern, aber diese Vorplanung bietet Ihnen einen guten Ausgangspunkt. Trotzdem ist es manchmal hilfreich, zuerst zu sehen, wie andere Teams arbeiten. Ich habe also bereits den Prozess durchlaufen, herauszufinden, wie dieser Workflow, den wir heute verwenden, aussehen soll Workflow, den wir heute verwenden, Beginnen wir also damit, unsere neuen Status hinzuzufügen, mit denen wir arbeiten können, und wir werden sie alle auf einmal erstellen, und dann organisieren wir alles und verbinden alles miteinander Also werde ich hier oben zum Anzeigenstatus kommen , und wir wollen einige Status erstellen Kommen wir also hierher und wählen entweder einen Status aus, den wir bereits in unserer Jira-Instanz erstellt haben, oder ich komme hierher und fange an, ihn einzugeben Nein, wir haben diesen Status noch nicht, also erstellen wir ihn. Die Kategorie wird noch bearbeitet. Und dann könnten wir hier Übergänge vom Edi-Status zulassen , aber ich werde einfach weitermachen und auf Hinzufügen klicken, mich zunächst darauf konzentrieren, diese Status hinzuzufügen, und dann organisieren wir alles später Gehen wir also zu „Bereit für die Qualitätssicherung“ — unser nächster Status. Erschaffe das. Auch hier wird es sich bei der Kategorie um eine Art in Bearbeitung handeln. Bei Status werden wir reinkommen, und das wird ein QA-Test sein. Auch hier wird es sich bei der Kategorie um irgendeine Form handeln, das ist in Bearbeitung. Wir werden unseren Blockstatus hinzufügen . Und dann fügen wir hier einen weiteren Status hinzu, und wir werden einen Status hinzufügen, der nicht geht. Und das wird eine andere Form von Erledigt sein. Damit wir in der Kategorie De ein paar verschiedene Status haben in der Kategorie De ein paar verschiedene Status Und anstatt sie alle sein zu lassen, ist diese Arbeit tatsächlich getan, wenn wir hier reinkommen und einen hinzufügen, der nicht funktioniert, wenn wir Arbeit zum Status „Nicht tun“ hinzufügen, dann können wir später zu den Berichten und Filtern zurückkehren und uns die Berichte und Filter ansehen, bei denen wir bewusst entschieden haben, dass ja, das ist tatsächlich abgeschlossen, das ist erledigt, oder wir haben die Entscheidung getroffen sein zu lassen, ist diese Arbeit tatsächlich getan, wenn wir hier reinkommen und einen hinzufügen, der nicht funktioniert, wenn wir Arbeit zum Status „Nicht tun“ hinzufügen, dann können wir später zu den Berichten und Filtern zurückkehren und uns die Berichte und Filter ansehen, bei denen wir bewusst entschieden haben, dass ja, das ist tatsächlich abgeschlossen, das ist erledigt, oder wir haben die Entscheidung getroffen diese Arbeit nicht machen, aus welchem Grund auch immer. Und dann würden Sie im Arbeitselement selbst den Grund hinzufügen, aus dem Sie sich nicht entschieden haben, diese Arbeit zu erledigen. In Ordnung, jetzt haben wir unsere Status erstellt. Lass uns hier reinkommen und anfangen, einige Übergänge zu erstellen. Bei diesen Status , die wir bereits haben, ist dies der beliebige Übergang Das bedeutet, dass Arbeitselemente mit dem Status „ Erledigt“ von jedem anderen Status in diesen Status übergehen können Wenn es also in Bearbeitung ist, wenn es zu erledigen ist, wenn es eines davon hier gibt, kann es tatsächlich von diesem anderen Status in den Status Erledigt übergehen . Aber das wollen wir vielleicht nicht immer. Beginnen wir also damit, dies zu organisieren und einige neue Übergänge zwischen diesen Status zu erstellen einige neue Übergänge zwischen , denn im Moment sind diese hervorgehoben, was bedeutet, dass nichts in den Status „Code-Review“ übergehen kann Wir können keine Arbeit im Code-Review-Status haben wenn es keinen Übergang in diesen Status gibt Also werde ich kommen und einen nehmen, sagen wir, von In Bearbeitung, wir wollen, dass in Bearbeitung in den Code-Review übergeht. Und geben wir diesem Status einen Namen. Es ist immer eine gute Idee , alles zu benennen. Und hier kann die Vorplanung wirklich hilfreich sein, wie Sie die Dinge benennen werden. Das wird also zur Überprüfung eingereicht. Es geht also von „In Bearbeitung“ über die Überprüfung des Codes bis hin zur Umstellung auf „Zur Überprüfung einreichen“. Für die nächsten Übergänge werden wir sagen: Okay, wenn die Arbeit in der Codeüberprüfung ist, wird sie nach der Codeüberprüfung herauskommen, und dann werden wir sie für die Qualitätssicherung vorbereiten. Und ich sollte sagen, dieser Status oder diese Übergänge werden als genehmigt bezeichnet, oder? Es wurde also genehmigt, und dann geht es mit der Codeüberprüfung weiter. Das Code-Review wird genehmigt und es wird bereit für die Qualitätssicherung Ein weiterer möglicher Arbeitsablauf dafür ist, wenn der Code nicht genehmigt wurde, wenn etwas geändert werden muss , wir reinkommen und sagen: Okay, Codeüberprüfung, lassen Sie uns das wieder in Bearbeitung aufnehmen Und das wird der Übergang sein, bei dem Änderungen angefordert werden . Da haben wir's. Das ist also ein weiterer potenzieller Arbeitsablauf , den unsere Arbeitsaufgaben haben könnten. Und wir können das neu anordnen, wenn wir wollen , dass es ein bisschen sinnvoller ist, wie wir das alles organisiert haben Als Nächstes, wenn sich die Arbeit im Status „ Bereit für die Qualitätssicherung“ befindet, was passiert hier Okay, bereit für die Qualitätssicherung in diesem Workflow wird also im Grunde genommen der Status „Zu erledigen“ für unser QA-Team sein, oder? Sobald Code von den Entwicklern überprüft wurde, wird er bereit für die Qualitätssicherung sein. Und dann alles, was sich im Status „ Bereit für die Qualitätssicherung“ befindet, unser QA-Leiter, wird dieser Benutzer wissen können: Okay, es kann losgehen. Und dann, während sie tatsächlich daran arbeiten, können sie mit der Arbeit beginnen und sie zu den QA-Tests ziehen, um zu zeigen , dass die Tests diesbezüglich tatsächlich gestartet wurden. Und dafür, sagen wir, nennen wir das einfach Start QA. Und dann kann es aus QA-Tests kommen, und wir wollen eigentlich, dass das erledigt wird, um zu sagen, ja, okay, das ist abgeschlossen Da haben wir's. Oder, genau wie bei der Code-Überprüfung, wenn eine Änderung vorgenommen werden muss, können wir , wenn eine Änderung vorgenommen werden muss, diese vom QA-Test zurück zu „In Bearbeitung“ überführen und sagen, dass sie zur Behebung zurückgeschickt werden muss. Da haben wir's. Und was die anderen beiden Status angeht, wird es sicherlich Zeiten geben, in denen wir einen globalen Übergang von einem Status zu einem anderen durchführen wollen , und wir wollen jederzeit sagen können, dass wir die Entscheidung getroffen haben, diese Arbeit nicht zu machen Dafür werden wir also Übergänge hinzufügen, und das wird von einem beliebigen Status bis hin zu einem nicht reichen Mach weiter und erstelle das. Und das Gleiche gilt für blockiert, wir werden jederzeit sagen, dass jede Arbeit in diesem Workflow blockiert werden kann. Da haben wir's. Also haben wir unseren Workflow hier im Workflow-Editor erstellt. Und jetzt haben wir unseren Workflow einsatzbereit. In unserer nächsten Lektion werden wir uns mit einigen Regeln befassen, die wir zu unserem Workflow hinzufügen können, und beginnen damit, Übergänge einzuschränken 4. Einschränken von Übergängen: In dieser Lektion lernen wir die erste Art von Workflow-Regel kennen, die einschränkt, wer einen Übergang ausführen kann Die Regel „Übergang einschränken“ wurde in älteren Versionen von Jira früher als Bedingungen bezeichnet. Sie steuert, ob ein Übergang überhaupt verfügbar ist, je nachdem, für welche Regel wir uns entscheiden Der wahrscheinlich häufigste Anwendungsfall dafür ist die Einschränkung eines Übergangs auf der Grundlage dessen, wer der Benutzer ist Hier ist also ein gängiges Szenario, dessen Einrichtung wir in dieser Lektion lernen werden. Wir möchten nur, dass Entwickler Arbeiten zur Codeüberprüfung einreichen können . In unserem Setup ist Ethan also ein Entwickler und er gehört der Benutzergruppe des Entwicklers Maxwell ist unser QA-Leiter und er gehört nicht zur Entwicklergruppe. Wir möchten, dass Ethan Beiträge zur Überprüfung einreichen kann, um von einem Status zum anderen in den Status Code-Review überzugehen , aber Maxwell sollte nicht in der Lage sein, vom Status „In Bearbeitung“ zu diesem Code-Review-Status zu wechseln „In Bearbeitung“ zu diesem Code-Review-Status zu Lassen Sie uns das einrichten. Was wir tun möchten, ist, diesen Übergang „Senden für die Überprüfung“ zu verwenden , den wir in der vorherigen Lektion erstellt haben. Im Rahmen dieser Umstellung muss jede Arbeit, die von der Bearbeitung bis zur Codeüberprüfung erfolgt, diesen Übergang durchlaufen. Kommen wir zu unseren Regeln, beschränken wir den Übergang, fügen wir eine Regel zur Beschränkung des Übergangs hinzu. Und dann wollen wir einschränken, je nachdem, wer der Benutzer ist. Beschränken Sie also, wer ein Arbeitselement verschieben kann. Und wir können entweder bestimmte Benutzer auswählen, oder ich habe festgestellt, dass ein besserer Arbeitsablauf darin besteht, Gruppen zu verwenden. Auf diese Weise können wir Benutzer zur Gruppe hinzufügen, und all diese Regeln werden automatisch angewendet, anstatt dass es sich nur um einzelne Benutzer handelt. Also werde ich reinkommen und Gruppen auswählen, und dann wählen wir die Entwicklergruppe aus. Das bedeutet, dass nur Entwickler diesen Übergang nutzen können , um von der aktuellen Version zur Codeüberprüfung überzugehen. Drücken Sie AD, los geht's. Wir haben dies zu unseren Regeln hier auf der rechten Seite hinzugefügt . Damit dies in Kraft tritt, müssen wir den Workflow aktualisieren. Im Moment befinden wir uns also im Grunde in einem Entwurfsmodus. Wir haben das nicht wirklich aktualisiert. Damit das live geht, müssen wir den Workflow aktualisieren. Jetzt, da unser Workflow aktualisiert wurde, wollen wir uns ansehen, wie das für unser Team aussieht. Also werde ich mich zuerst als Maxwell anmelden. Dies ist als Maxwell Carter angemeldet. Er ist unser QA-Leiter , der nicht Teil der Entwicklergruppe ist, der wir gerade diese Übergangsbeschränkung hinzugefügt Wenn wir also auf eines dieser Arbeitsaufgaben stoßen , das gerade in Bearbeitung ist, können Sie sehen, dass Maxwell es nicht einmal in den Status der Codeüberprüfung bringen kann , weil die einzige Möglichkeit , dies zu tun, darin besteht, diesen Übergang zur Überprüfung einreichen zu durchlaufen diesen Übergang zur Überprüfung einreichen , den wir eingeschränkt haben Wenn ich mich nun als Ethan, einer der Entwickler in der Entwicklergruppe, anmelden würde, lasse ich das Fenster hier Ich bin hier als Ethan angemeldet. Jetzt als Ethan angemeldet. Wenn wir uns eines dieser Arbeitselemente ansehen würden, den Status ansehen. Es ist im Gange. Wenn ich das herunterziehe, können wir den Übergang „Zur Überprüfung einreichen“ verwenden, um ihn in den Status „Code-Review“ zu überführen . Und da haben wir's. Jetzt kann Ethan das Arbeitselement so ändern, dass es sich aufgrund dieses Übergangs in den Code-Review-Status der Umstellung „Zur Überprüfung einreichen“ können nur Personen in dieser Entwicklergruppe diesen Übergang durchlaufen, was die einzige Möglichkeit ist, in diesen Code-Review-Status zu gelangen in diesen Code-Review-Status zu gelangen Derselbe Status, dasselbe Arbeitselement, unterschiedliche Benutzerberechtigungen. Dies ist eine leistungsstarke Methode, um den rollenbasierten Zugriff in unserem Arbeitsablauf durchzusetzen , ohne dass wir uns darauf verlassen müssen, dass wir uns nur an die Regeln erinnern. Das System kann es für uns durchsetzen. einigen anderen häufigen Anwendungsfällen, in denen der Übergang eingeschränkt können Dinge gehören, wie zum Beispiel, dass dieser genehmigte Übergang möglicherweise nur Projektleitern oder Managern gestattet wird. Oder vielleicht, da wir ein QA-Team eingerichtet haben, kann nur das QA-Team die Qualitätssicherung tatsächlich abschließen und sie nach Abschluss der QA-Tests an Dunn schicken , oder vielleicht kann sie sogar nur mit der Qualitätssicherung beginnen Vielleicht möchten wir, dass das QA-Team erst dann mit der Qualitätssicherung beginnen kann , wenn es bereit für die Qualitätssicherung Nur das QA-Team kann tatsächlich mit den QA-Tests beginnen, die diesen QA-Übergang durchlaufen Es ist genau derselbe Prozess. Wir kommen hierher, um den Übergang einzuschränken, eine Regel hinzuzufügen, einzuschränken, wer ihn verschieben kann. Diesmal beschränken wir uns nicht auf die Gruppe der Entwickler, sondern auf den Leiter der Qualitätssicherung. Füge das hinzu. Fahren Sie fort und aktualisieren Sie diesen Workflow. Und jetzt können wir ihnen die Arbeit abnehmen , die sich in der Codeüberprüfung befindet, und sie für die Qualitätssicherung bereit machen, aber nur unsere QA wird sie testen können . Schauen wir uns also nochmal an, wie das aussieht, wenn wir hier als unser Entwickler angemeldet sind, Ethan, also sagen wir, okay, es ist im Code-Review, es wurde genehmigt Das heißt, es ist bereit für die Qualitätssicherung. Ethan kann es übernehmen, um es zur Qualitätssicherung bereit zu machen, aber es kann dann nicht genehmigt und aus dem QA-Prozess herausgenommen werden, oder? Aber wir haben es so eingerichtet, ich glaube, das liegt an diesem Übergang hier. Jep. Also, obwohl wir hier diesen Übergang haben, haben wir dieses Setup für jeden Status Wenn Sie das also entfernen möchten , könnten wir einfach reinkommen, auf Löschen klicken und den Workflow aktualisieren. Jetzt können wir das nur noch durch QA erledigen Wenn wir also wieder als unser Entwickler hier angemeldet sind, das hier reinziehen, können wir es nicht mehr auf den Status De setzen. Der einzige Weg, das zu tun, ist über das QA-Team, was bedeutet, dass wir angemeldet sind, wir werden wieder dazu wechseln , hier als Maxwell angemeldet zu sein, das ist bereit für die QA, und er kann weitermachen und das zum QA-Test mitnehmen. Ja, okay, es ist bereit für den QA-Test. Und wenn er fertig ist, kann er die UA-Tests abschließen, und das Arbeitselement wird vollständig erledigt sein , indem er den gesamten Workflow durchläuft Um noch einmal zusammenzufassen, was wir in dieser Lektion gelernt haben: Wir haben gelernt, den Übergang von bestimmten Benutzern abhängig von der Gruppe, zu der der Benutzer gehört, einzuschränken bestimmten Benutzern abhängig von der Gruppe, zu der der Benutzer gehört, Und es gibt noch so viele weitere Möglichkeiten, wie wir das Ganze noch komplexer gestalten können, wenn wir wollen Wir können dem sogar eine untergeordnete Regel hinzufügen , wenn wir, sagen wir, vielleicht den Übergang von jemandem einschränken wollen vielleicht den Übergang von jemandem einschränken , der in der Entwicklergruppe ist, und auch von jemandem, der in einer QA-Gruppe war, solche Dinge. Ich empfehle Ihnen nun, einen Test-Workflow zu erstellen und mit den Regeln zur Beschränkung des Übergangs in den Workflows herumzuspielen den Regeln zur Beschränkung des Übergangs in den Workflows um zu sehen, wie Sie diese zu Ihrem eigenen Vorteil nutzen können. Und wenn Sie bereit sind, sehen in der nächsten Lektion, in der wir etwas über eine andere Art von Regel für unsere Übergänge lernen werden etwas über eine andere Art von Regel für unsere Übergänge lernen Eingaben anfordern. Wir sehen uns dort. 5. Hinzufügen von Anforderungseingaberegeln: In der letzten Lektion haben wir uns mit der Regel „Übergang einschränken“ befasst . In dieser Lektion werden wir uns mit der zweiten Art der Eingabe von Workflow-Regelanfragen befassen. Eingabe von Anfragen wird während eines Übergangs ein Bildschirm angezeigt, in dem der Benutzer aufgefordert wird, bestimmte Felder auszufüllen , bevor der Übergang fortgesetzt Anstatt das Arbeitselement einfach von einer Größe auf eine andere zu verschieben , Jira eine Pause und sagt: Hey, bevor wir weitermachen, musst du ein paar Dinge ausfüllen Und das ist nützlich, wenn wir Daten genau in dem Moment sammeln möchten , in dem ein Übergang zwischen den Status stattfindet Also hier ist unser Szenario für diese Lektion. Wenn jemand ein Arbeitselement vom Status QA erledigt vom QA-Teststatus in den Status Erledigt verschiebt , wird der gesamte QA-Übergang verwendet. Wir möchten sicherstellen, dass das Feld „ Feste Versionen“ ausgefüllt wird , damit wir wissen welche Version unseres Codes diesen Fix enthält. Wir könnten nur hoffen, dass die Leute daran denken, es einzustellen, aber ein besserer Arbeitsablauf besteht darin anhand der Anforderungseingabe sofort aufzufordern sie anhand der Anforderungseingabe sofort aufzufordern, dieses Feld auszufüllen, wenn sie mit der Arbeit fertig sind . Gehen wir also zurück zum Workflow-Editor und richten ihn ein. Um nach dem QA-Test, wie Sie vielleicht erwarten, fertig zu werden , müssen dieser vollständigen QA-Umstellung leben. Kommen wir also zum kompletten QA-Übergang und kommen kompletten QA-Übergang wir dann dazu, Eingaben anzufordern und eine Regel für die Anforderungseingabe hinzuzufügen. Jetzt müssen wir Jira mitteilen, welcher Bildschirm angezeigt werden soll. Also gibt es hier nur eine Sache. Wir können einen Bildschirm anzeigen, den auswählen. Welchen Bildschirm wollen wir zeigen? Jetzt können wir von jedem der anderen Bildschirme abrufen. Sie können sehen, dass ich in meiner Jira-Installation viele verschiedene Bildschirme auf meiner Seite eingerichtet habe verschiedene Bildschirme auf meiner Seite Aber wenn wir noch keinen Bildschirm erstellt haben, möchten wir vielleicht reinkommen und einen neuen Bildschirm erstellen Also werde ich das tun, und es öffnet sich ein neuer Tab. Da haben wir's. Lassen Sie uns nun den Bildschirm hinzufügen. Und gib einen Namen. Benennen ist immer gut. Das wird also für unseren kompletten QA-Übergang gelten. Fordere Eingaben für fehlerfreie Versionen an. Da haben wir's. Geben Sie ihm eine Beschreibung , wenn wir wollen. Aber ich werde auf Hinzufügen klicken. Jetzt haben wir unseren Bildschirm erstellt. Wir können diesen Tab schließen, der uns zurück zu unserem Workflow-Editor bringt. Und lass uns das finden. Es war also etwas mit festen Versionen. Da haben wir's. Finde den Bildschirm und füge ihn zu unserer Regel hinzu. Und jetzt, wann immer etwas aus einem QA-Test kommt und fertig ist, wird dieser Bildschirm natürlich angezeigt , sobald wir unseren Workflow aktualisieren. Also lass uns das machen. Jetzt, wo unser Workflow aktualisiert ist, gehen wir rein und schauen uns an, wie das auf der anderen Seite aussieht. Also müssen wir uns als Maxwell anmelden. Wer ist unser QA-Leiter, richtig? Denn denken Sie daran, dass wir diese Einschränkung eingerichtet haben bei der Maxwell der Einzige ist, der das tun kann Sobald die QA-Tests abgeschlossen sind, sie abgeschlossen werden Wenn wir es jetzt auf Dunn setzen, wird dieser Übergang angezeigt Aber warte, wo ist unser Fachgebiet? Ich habe tatsächlich einen Schritt vergessen. Lass uns zurückkommen und das Ganze absagen. Es wird diesen Übergang also nicht ändern. Es ist wichtig, das im Hinterkopf zu behalten. Wenn Sie das stornieren, wird der Übergang damit nicht abgeschlossen. Und lassen Sie uns hier zurück zu unserem Bildschirm springen. Dies ist eine großartige Möglichkeit zu zeigen, wie wir dies im Nachhinein anpassen können. Also lasst uns unseren Bildschirm finden. Es wird hier der Bildschirm mit der festen Version sein. Wir haben vergessen, das eigentliche Feld hinzuzufügen , das wir auf diesem Bildschirm hinzufügen möchten . Im Moment ist also nichts für diesen Bildschirm konfiguriert. Deshalb wurde nichts angezeigt. Lassen Sie uns also reinkommen und feste Versionen hinzufügen. Da haben wir's. Da gibt es keinen Spielstand oder so. Es ist bereits gespeichert. Und da wir es bereits in unserem Workflow eingerichtet haben, wir hier zurück zu unserem Workflow-Editor , um zu zeigen, dass er bereits eingerichtet ist. Es war unser Workflow für die Softwareentwicklung, dieser hier. Es sollte also bereits eingerichtet sein, sobald die Qualitätssicherung abgeschlossen ist, ja. Okay, dieser Bildschirm wird angezeigt, und dieser Bildschirm hat jetzt dieses Feld Wenn wir also wieder als Maxwell angemeldet sind, dieses Arbeitselement nehmen und es abschließen, ist es erledigt Und jetzt haben wir dieses feste Versionsfeld. Natürlich sieht es so aus, als ob ich hier in diesem Bereich keine Versionen habe. Kommen wir also zu unseren Veröffentlichungen. Das sind die verschiedenen Versionen. Ja, wir haben gerade keine Veröffentlichungen hier drin. Und es sieht so aus, als hätte Maxwell nicht die Erlaubnis, tatsächlich eine zu erstellen. Keine große Sache Lassen Sie uns wieder als unser Administrator einsteigen und hier eine neue Version erstellen. Also gehe ich zurück in den Bereich der Softwareentwicklung, komme zu den Releases, und jetzt können wir eine Version erstellen. Sagen wir also, okay, das ist Version 1.0 unserer Software. Speichern Sie das. Das wurde geschaffen. Und jetzt bei Maxwell, wenn wir die Seite aktualisieren, wird er sehen, dass diese Version angezeigt wird. Da haben wir's. Und dann zurück zum Arbeitselement Sobald wir es im QA-Test abgeschlossen haben, wird unser Bildschirm angezeigt, und er sieht die fehlerfreie Version , der er sie und er sieht die fehlerfreie Version zuordnen kann, fügt einen beliebigen Kommentar hinzu und aktualisiert sie. Und jetzt wird das Arbeitselement in den Status De übergehen. Eine Art Zusammenfassung In dieser Lektion haben wir gelernt, dass die Regel zur Eingabe von Anfragen während eines Übergangs ein Fenster öffnet Wir lernen, wohin wir gehen müssen, um Felder zu unserem Bildschirm hinzuzufügen. Wir haben uns sogar angeschaut, wo eine neue Version in unserem Bereich einrichten können, sodass sie im Feld für feste Versionen angezeigt wird. Natürlich kann dieser Bildschirm alle gewünschten Felder enthalten. Und wir können das sogar auf die nächste Stufe heben indem wir mithilfe eines Feldkonfigurationsschemas steuern, welche Felder auf unseren Bildschirmen erforderlich sind auf unseren Bildschirmen erforderlich . gerade von Anforderungen sprechen, gehen wir zu unserem nächsten Video über in dem wir lernen, wie wir im Grunde genau dieses Szenario mit der Regel „Details überprüfen“ einrichten können . Und darüber werden wir in unserer nächsten Lektion alles erfahren. 6. Übergänge validieren: In der letzten Lektion verwenden wir Anforderungseingaben, um Benutzer während eines Übergangs zur Eingabe von Daten In dieser Lektion lernen wir, wie Sie die Regel „Details überprüfen“ verwenden. Die Regel zur Überprüfung von Details in älteren Versionen von Jira als Validatoren bezeichnet. Sie prüft, ob die erforderlichen Daten vorhanden sind, bevor die Umstellung fortgesetzt Im Gegensatz zur Anforderungseingabe , bei der der Benutzer aufgefordert wird, fehlende Daten auszufüllen, Validatoren Schlägt die Überprüfung fehl, wird der Übergang vollständig blockiert und dem Benutzer wird eine Fehlermeldung angezeigt. Stellen Sie sich das so vor. Eingabe der Anfrage stoppt den Benutzer und sagt: Hey, gib das ein, bevor wir weitermachen. In den Bestätigungsdetails steht: Nein, Sie können erst fortfahren, wenn Sie diese Schritte abgeschlossen haben. Also hier ist unser Szenario für diese Lektion. Wir werden auf dem aufbauen, was wir in der letzten Lektion getan haben , als wir einen Bildschirm hinzugefügt haben , der es einem Benutzer ermöglicht , das Feld mit den festen Versionen auszufüllen, oder? Aber anstatt während der Umstellung einfach danach zu fragen, wie wir es bei der Anforderungseingabe gemacht haben und dann erwarten, dass es ausgefüllt wird , werden wir diesen Übergang blockieren, wenn er nicht wirklich ausgefüllt ist wir diesen Übergang blockieren, wenn er nicht wirklich ausgefüllt Fügen wir also nach Abschluss des QA-Übergangs einen Validator hinzu, der überprüft, ob das Feld ausgefüllt ist, bevor der Vorgang fortgesetzt werden kann also hier in die Workflow-Bearbeitung springen, unter der Anforderungseingabe haben wir unter der Anforderungseingabe die Und in diesem Fall möchten wir sicherstellen, dass das Feld mit den festen Versionen ausgefüllt ist Wenn wir also die Regel „ Details überprüfen“ eingeben, fügen Sie diese hinzu. Es gibt eine Menge davon , die wir hier machen können. In diesem Fall wollen wir ein Feld validieren, weil, wie wir im letzten Video gesehen haben, feste Versionen ein Feld sind. Also wollen wir dieses Feld validieren, wählen Sie es jetzt aus. Wir müssen Jira mitteilen, wie wir das Feld validieren wollen Möchten wir sicherstellen, dass es einen einzigen Wert anstelle mehrerer Werte hat Oder wollen wir sicherstellen, dass es einem Ausdruck entspricht? Vielleicht beginnt die Zusammenfassung des Arbeitselements mit denselben Wörtern und was auch immer dieser Ausdruck sein mag. In diesem Fall möchten wir jedoch sicherstellen, dass das Feld überhaupt nicht leer ist. Es enthält Daten. Jetzt müssen wir Jira sagen: Okay, wenn du überprüfen willst, ein Feld nicht leer ist, welches Feld? Nun, in diesem Fall wollen wir, dass es Feld mit den festen Versionen ist, das wir zuvor hinzugefügt haben, oder? Also dieser hier. Und wir können entweder die Fehlermeldung leer lassen, wodurch eine Standardfehlermeldung hinzugefügt wird, oder wir können unsere benutzerdefinierte Fehlermeldung hinzufügen , falls dies fehlschlägt. Angenommen, Sie müssen zuerst eine feste Version hinzufügen. Da haben wir's. Mach weiter und füge das hinzu. Nun, hier ist ein wichtiger Punkt , denn die Reihenfolge dieser Regeln ist wichtig, oder? Sie laufen also tatsächlich von oben nach unten. Da wir also die Eingabe der Anfrage vor den Bestätigungsdetails haben , öffnet sich der Bildschirm , auf dem der Benutzer das Feld mit den festen Versionen hinzufügen kann, indem er den Bildschirm verwendet, den wir im letzten Video eingerichtet haben. Wenn sie das tun, wird bei dieser Überprüfung überprüft, ob Daten in diesem Feld vorhanden sind oder nicht. Sie haben also die Möglichkeit, diesem Feld Daten hinzuzufügen , bevor versucht wird, den Übergang abzuschließen. Wenn sie das nicht tun, erscheint eine Fehlermeldung mit der Meldung, dass das ausgefüllt werden muss. Dieses Feld darf nicht leer sein. Lassen Sie uns also unseren Workflow aktualisieren und dies in Aktion sehen. Ich werde den Workflow aktualisieren, sodass er jetzt live ist. Und dann lassen Sie uns einsteigen, um als Maxwell angemeldet zu sein. Denken Sie daran, er ist unser QA-Leiter und wir haben die Übergänge eingeschränkt Wir wollen also sichergehen, dass das zur Qualitätssicherung weitergeleitet wird, obwohl wir uns eigentlich zuerst als Ethan anmelden müssen, weil der Code überprüft werden muss Denken Sie daran, dass dies der Prozess ist , den wir von in Bearbeitung haben Er muss zur Code-Überprüfung übergehen Und dann von der Codeüberprüfung, sobald er durch die Codeüberprüfung genehmigt wurde , ist er bereit für A. Okay? Jetzt, wo es in der Qualitätssicherung ist, können wir uns als Maxwell in unser Qua-Team einloggen . Es ist bereit für Okay. Und es ist im QA-Test. Jetzt, wo es durch QA-Tests erledigt ist, okay, es ist abgeschlossen, es ist erledigt. Wir können hier reinkommen und es zu unserer festen Version hinzufügen. Oder wenn wir einfach herkommen und versuchen, das zu aktualisieren , wird es sagen, nein, es muss hinzugefügt werden. Wir müssen zuerst eine feste Version hinzufügen. Das ist die Fehlermeldung , die wir uns in diesem Validator gegeben Das ist unser Validator , der genau hier arbeitet. Aber sobald wir hier reinkommen und Daten zu diesem Feld hinzufügen , beobachten Sie, was passiert Ich werde das aktualisieren können, weil diese Daten im Backend validiert wurden. Noch einmal, im Workflow ist das diese Regel zur Überprüfung von Details, ist das diese Regel zur Überprüfung von Details die hier reinkommt und besagt, dass sie dieses Feld überprüft. Wenn sie nicht leer ist, enthält sie im Grunde Daten, sie lässt sie bestehen, und wenn sie uns nicht genau hier diese Fehlermeldung gegeben hat. Um es noch einmal zusammenzufassen: Die Regel „ Details überprüfen“ überprüft , ob die von uns eingerichtete Validierung erfüllt ist , damit der Übergang abgeschlossen werden kann Wenn die Validierung fehlschlägt, wird der Übergang blockiert und dem Benutzer wird ein Fehler angezeigt Natürlich können wir jedes Feld verwenden, das über das Feld mit festen Versionen hinausgeht. Und wie wir bei der Einrichtung der Regel gesehen haben, können wir noch mehr tun, als die Felder selbst zu validieren Aber hoffentlich drehen sich langsam die Weichen dafür, wie Sie dies in Ihren eigenen Workflows verwenden können Ich möchte Sie daher ermutigen, sich zwischen den Lektionen etwas Zeit zu nehmen, es auf Ihrer Seite auszuprobieren und mit einigen der verschiedenen Regeln herumzuspielen , um zu sehen, wie sie in Ihrer Organisation helfen können. Wir müssen uns noch einen weiteren Regeltyp ansehen. In unserer nächsten Lektion werden wir also lernen, wie wir darauf noch weiter aufbauen können , indem wir Aktionen in unseren Workflow-Übergängen durchführen . Wir sehen uns dort. 7. Aktionen ausführen: In dieser Lektion lernen wir die vierte Art von Workflow-Regel kennen , die Aktionen ausführt. Nun, diese Regel unterscheidet sich ein wenig von allen anderen Regeln, die wir uns bisher angesehen haben da sie ganz am Ende auftreten, nachdem alle anderen Regeln erfolgreich abgeschlossen wurden, und sie validieren nichts wirklich Wenn Sie ältere Versionen von Jira verwendet haben, wurden diese früher als Post-Funktionen bezeichnet Sie sind also anders , weil sie nicht wirklich darüber entscheiden, ob der Übergang stattfinden kann oder nicht Sie sind das Aufräumteam, das erledigt, nachdem alles bereits validiert wurde Sie machen Dinge wie das Aktualisieren von Feldern und das Zuweisen von Benutzern, solche Sachen Also hier ist unser Szenario für diese Lektion. Nachdem unser Arbeitselement erfolgreich in den Status „ Bereit für die Qualitätssicherung“ übergegangen ist, weisen wir es automatisch unserem QA-Leiter Maxwell zu Auf diese Weise erhält er eine Benachrichtigung darüber, dass ihm Arbeit zugewiesen wurde, und er weiß, dass sie bereit ist, mit dem Testen zu beginnen Gehen wir also zu Jira und richten das ein. Was wir tun wollen, ist es, sobald es von der Codeüberprüfung zur Vorbereitung für die Qualitätssicherung übergegangen ist, genau hier auf diesen genehmigten Übergang anwenden müssen genau hier auf diesen genehmigten Übergang also unter Genehmigter Übergang das aus, Wählen Sie also unter Genehmigter Übergang das aus, scrollen Sie nach unten und führen Sie die Aktion aus. Wir werden die Aktionsregel ausführen. Und es gibt ein paar verschiedene Möglichkeiten, wie wir das tun können. Wir könnten reinkommen und ein Arbeitsaufgabenfeld aktualisieren , weil Verantwortlicher ein Feld ist , das wir aktualisieren könnten Aber das ist so häufig, dass Alasian es tatsächlich aufgetaucht ist So können wir ein Arbeitselement zuweisen, ohne uns durch die verschiedenen Felder wühlen zu müssen Wählen wir das also aus. Und jetzt müssen wir Jira sagen, wem wir das zuweisen wollen, oder alternativ können wir alle Zuständigen entfernen, die derzeit zugewiesen Wenn wir das machen wollten, könnten wir das gleich hier entfernen. Wenn es bereits jemandem zugewiesen wäre, könnten wir diesen Beauftragten zu diesem Zeitpunkt des Übergangs einfach entfernen diesem Zeitpunkt des für unser heutiges Szenario Lassen Sie uns für unser heutiges Szenario herkommen und unseren QA-Leiter auswählen Das ist Maxwell. Das füge hinzu Okay, also nachdem dieser Übergang ausgeführt wurde, die Aktion am Ende darin, das Arbeitselement Maxwell Carter zuzuweisen Lassen Sie uns also unseren Workflow aktualisieren , um dies in Aktion zu sehen. In Ordnung. Also lass uns einfach mal als unser Entwickler Ethan eingeloggt sein , richtig? Lassen Sie uns also eines dieser Arbeitselemente hier betrachten. Lassen Sie uns genau diesen hier sagen. Sagen wir, okay, von „ to do“ bis „In Bearbeitung“. Und dann ist es von „In Bearbeitung “ bereit für die Codeüberprüfung. Nach der Codeüberprüfung wird der Code genehmigt und an die Qualitätssicherung gesendet. Beobachten Sie, was mit dem Beauftragten passiert , wenn der Code genehmigt und an die Qualitätssicherung weitergeleitet wird. Da haben wir's Es wurde Maxwell Carter zugewiesen. Und jetzt kann Maxwell Carter es den Rest des Weges bewältigen, weil er, wieder einmal als Ethan angemeldet, es nicht durchgehen und es tatsächlich nach der Qualitätssicherung verschieben kann Er nimmt es so weit wie möglich. Jetzt liegt es an Maxwell Carter, und es ist ihm zugewiesen. Hier reinzukommen und tatsächlich mit dem QA-Test zu beginnen und ihn durch den Rest des Workflows laufen zu lassen, den wir bereits eingerichtet haben Nun, eine Sache, die Sie beachten sollten Genau wie bei den anderen Regeln laufen die Aktionen von oben nach unten ab. Wenn wir hier also eine weitere Aktion haben , wenn wir reinkommen und sagen würden , dass wir auch eines der Felder aktualisieren wollen, könnten wir eines dieser Felder auswählen. Nehmen wir an, ich füge der Beschreibung etwas Ähnliches hinzu. Wenn wir dieses Feld aktualisieren wollen, die Reihenfolge wichtig, oder? Wenn ich das nehmen und es nach oben ziehen würde, würde das jetzt geschehen, bevor es zugewiesen wird. Nun, in diesem Fall und in diesem kleinen Szenario, das ich eingerichtet habe, dass die Beschreibung aktualisiert wird , bevor sie zugewiesen wird, wird das nicht wirklich etwas ändern. Aber es ist wichtig , dies im Hinterkopf zu behalten , denn wenn Sie mit der Aktualisierung von Feldern beginnen und diese Abfolge verschiedener Aktionen ausführen, spielt diese Reihenfolge eine Rolle. Sie können also klicken und ziehen, um diese Reihenfolge im Stapel neu zuzuweisen oder zu aktualisieren, oder? Also läuft alles sequentiell von oben nach unten. Und Sie können jederzeit hierher kommen und diese Regeln löschen, wenn Sie möchten , um alle Aktionen zu löschen, die Sie darin nicht möchten Um es noch einmal zusammenzufassen: In dieser Lektion haben wir gelernt, wie wir am Ende unseres Workflow-Übergangs Aktionen hinzufügen Ende unseres Workflow-Übergangs Zu den klassischen und gängigsten Anwendungsfällen hierfür gehören die automatische Zuweisung, die wir uns hier angesehen haben, aber auch Dinge wie das Setzen von Feldwerten, vollständige Löschen von Feldern oder das vollständige Kopieren von Feldwerten oder das Auslösen eines KI-Agenten oder Apropos KI-Agenten: Lassen Sie uns zu unserer nächsten Lektion übergehen, Lassen Sie uns zu unserer nächsten Lektion übergehen in der wir uns einen Moment Zeit nehmen, um zu untersuchen, wie wir diese bei unseren Übergängen verwenden können . Sehen wir uns dort? 8. Auslösen von KI-Agenten: In der letzten Lektion haben wir uns die Regel angesehen, die Aktionen ausführt, nachdem ein Übergang abgeschlossen ist In dieser Lektion werden wir darauf aufbauen und uns ansehen, wie KI-Agenten ausgelöst werden können. Nun, das Auslösen eines KI-Agenten ist keine Regel wie die anderen Regeln, die wir uns bisher auf der Stammebene dieser Regeln angesehen haben bisher auf der Stammebene dieser Regeln Stattdessen ist es unter „Aktionen ausführen“ zusammengefasst. Das ist derselbe Ort , an dem wir ein Arbeitselement nach dem Übergang automatisch zugewiesen haben, außer dass ein Arbeitselement nach dem Übergang automatisch zugewiesen haben, wir, anstatt ein Arbeitselement automatisch zuzuweisen, dieses Mal einen KI-Agenten veranlassen, sich das Arbeitselement anzusehen und dann auf der Grundlage der von uns bereitgestellten Aufforderung etwas zu tun auf der Grundlage der von uns bereitgestellten Aufforderung etwas Ich bin mir sicher, dass es nicht überraschend , dass, wenn wir KI auslösen, diese einige Einschränkungen hat je nachdem, welche Version von Jira Sie müssen Rovo in Ihrer Jira-Instanz aktiviert haben in Ihrer Jira-Instanz aktiviert Rovo ist die KI-Plattform von Atlassian , die die Agenteninfrastruktur, die Agenten, die Credits, die Verbindung zu Jira-Workflows und all das unterstützt die Credits, die Verbindung zu Jira-Workflows und all das Die gute Nachricht ist, dass Rovo automatisch in den kostenpflichtigen Jira Cloud-Plänen, Standard Premium- und Enterprise-Tarifen enthalten ist automatisch in den kostenpflichtigen Jira Cloud-Plänen, Standard Premium- und Enterprise-Tarifen enthalten . Es muss also keine separate Lizenz erworben werden. In meinem Fall verwende ich jetzt eine Jira Cloud-Standardlizenz ohne zusätzliche Gebühren Hier ist also unser Standard für das, wofür wir KI in dieser Lektion verwenden werden Wenn jemand Arbeit zur Codeüberprüfung einreicht, möchten wir, dass der KI-Agent automatisch eine First-Pass-Analyse des Arbeitselements für uns durchführt und alle Änderungen vorschlägt, die möglicherweise an diesem Arbeitselement vorgenommen werden müssen , sodass, wann immer jemand kommt, um den Code zu überprüfen , er einen Vorsprung hat Gehen wir also zu Jira und beginnen wir mit dem Übergang, bei dem diese Aktion tatsächlich durchgeführt werden soll Das ist dieser Übergang genau hier, zur Überprüfung einreichen, denn wenn Arbeit von „In Bearbeitung“ zur Codeüberprüfung übergeht, muss sie diese Übergänge „Zur Überprüfung einreichen“ durchlaufen diese Übergänge „Zur Überprüfung einreichen also unter dem Übergang hier auf der rechten Seite, Lassen Sie uns also unter dem Übergang hier auf der rechten Seite, genau wie wir es zuvor getan haben, die Regel „ Aktionen ausführen“ hinzufügen. Und dieses Mal werden wir eine Trigger-Agent-Aktion hinzufügen. Jetzt müssen wir Jira mitteilen, welchen Agenten wir verwenden möchten. Nun, das sind die vorinstallierten Agenten die im Lieferumfang von Rovo enthalten Wir haben einen Codierungsagenten, einen Delivery Agent oder einen Triage-Agenten, aber einige Agenten sind nur auf Premium oder Enterprise verfügbar Hier kann Ihre Tarifstufe wirklich einen Unterschied machen Sie können auch zusätzliche Agenten installieren oder sogar Ihren eigenen benutzerdefinierten Agenten erstellen, wenn Sie möchten. Für unseren heutigen Anwendungsfall möchten wir jedoch den Triage-Agenten verwenden Seine Aufgabe besteht darin, das Arbeitselement zu lesen und es dann zu sortieren, um herauszufinden, was die höchste Priorität hat und was zuerst behandelt werden muss. Jetzt hat es einen Standardsatz von Befehlen. Wir könnten das einfach hinzufügen, wenn wir wollen, aber wir können es anpassen, indem wir es in unserer eigenen Eingabeaufforderung hinzufügen. Hier nun die Aufforderung, das Arbeitselement auf seine Eignung für die Codeüberprüfung hin zu analysieren, da das in den Code-Review übergeht. Ich Arbeitselement auf seine Eignung für die Codeüberprüfung hin zu analysieren, da das in den Code-Review übergeht schlage anhand der Beschreibung eine Priorität vor, alle verwandten oder doppelten Arbeitselemente und finde und vermerke, ob die Beschreibung ausreichend detailliert ist, sodass ein Prüfer mit der Arbeit beginnen kann ausreichend detailliert ist, sodass ein Prüfer mit der Arbeit beginnen Und dann erhalten wir einen Kommentar zu der Arbeitsaufgabe mit ihren Ergebnissen um unserem Team einen Vorsprung zu verschaffen Lassen Sie uns weitermachen und das hinzufügen. Da haben wir's. Jetzt müssen wir unseren Workflow aktualisieren und dann zu Jira springen, als einer unserer Entwickler anmelden, als Ethan anmelden Wählen wir also eines dieser Arbeitselemente aus. Ich nehme diese Statusspalte und verschiebe sie hierher, damit sie etwas leichter zu sehen ist. Was die eigentliche Arbeit neben dem Status ist. Also nehmen wir nicht einen von denen, mit denen wir schon gearbeitet haben , vor diesem Gericht, das bereits erledigt ist. Nehmen wir an, okay, sagen wir, das baut API-Eingaben. Nehmen wir an, wir wollen anfangen, daran zu arbeiten. Es ist im Gange. Ethan arbeitet daran Und jetzt, okay, es ist bereit für die Überprüfung. Bevor wir das tatsächlich tun, möchte ich das öffnen, damit wir sehen können, dass das Arbeitselement selbst nichts enthält. Es ist so ziemlich nur die Zusammenfassung. Sie können sehen, dass es keine Beschreibung gibt. Es gibt keine Kommentare oder ähnliches. Aber wenn ich das nehmen und zur Überprüfung einreichen würde, beobachte, was passiert. Es wird sofort damit beginnen, diesen Agenten auszulösen, oder? Die Agenten werden anfangen, den Prozess zu durchlaufen. Es wird die Eingabeaufforderung durchgehen, die wir hinzugefügt haben. Dann geben wir ihm einfach einen Moment , um den Prozess durchzugehen. Und natürlich beobachten wir, wie es das tatsächlich tut. Wenn man etwas umstellt, passiert es normalerweise einfach im Hintergrund , wir schauen nicht wirklich zu, wie es passiert ist, und los geht's. Hier sind die Dinge, mit denen es zurückkam und die es empfohlen hat. Es heißt: Wollen wir dieses andere Arbeitselement verlinken? Es wurde ein ähnliches Arbeitselement gefunden. Das, weil es um die API-Endpunkte geht? Hm. Das könnte tatsächlich mit diesem Arbeitselement zusammenhängen, also sollten wir das vielleicht hier in Jira verlinken Vielleicht möchten wir das jetzt eher ändern als eine Idee Das hier ist eine Idee, ein Arbeitstyp. Und die Agenten sagen: Vielleicht möchten Sie das in eine Aufgabe ändern, weil es so aussieht, als würden wir tatsächlich an dieser Aufgabe arbeiten, oder? Der Inhalt beschreibt eher eine Aufgabe als eine übergeordnete Idee. Und im Moment heißt es: Oh, eigentlich, Ethan, wir sind als Ethan angemeldet. Er ist derjenige, der das macht Vielleicht möchten wir den Beauftragten nicht mehr Dan zugewiesen, Ethan zugewiesen, da er derjenige ist, der die Arbeit daran macht Und jetzt können wir reinkommen und sagen, wollen wir das wirklich akzeptieren Wollen wir das verfeinern, wodurch sich ein Rovo-Chatfenster öffnet , in dem wir Rovo sprechen und vielleicht einige dieser Vorschläge verfeinern können vielleicht einige dieser Vorschläge verfeinern Oder wir können dies mit einigen der anderen Rollen, die wir uns angesehen haben, kombinieren , indem wir sie automatisch jemandem in unserem Team zuweisen, bevor sie an sie automatisch jemandem in unserem Team zuweisen diesen Triage-Agenten weitergeleitet wird, und dann vielleicht den KI-Agenten bei unserer Umstellung darunter positionieren und dann vielleicht den KI-Agenten bei unserer Umstellung darunter positionieren und etwas in unserer Aufforderung hinzufügen , um zu prüfen , ob die von ihnen vorgeschlagene Arbeit zu der anderen Arbeit passt oder nicht vorgeschlagene Arbeit zu der anderen Arbeit passt . die sie ihnen bereits in dem Bereich zugewiesen haben Du kannst anfangen zu erkennen, wie mächtig das sein kann. Sie jedoch immer daran, dass dieser Agent solche Empfehlungen ausgibt. Es werden keine automatischen Änderungen vorgenommen. Ein Mensch muss immer noch reinkommen und überprüfen , ob er all diese Änderungen akzeptiert oder nicht. Nein, es ist erwähnenswert , dass wir in unserem Demo-Bereich nur eine Handvoll Arbeitselemente haben. Es gab wirklich keine Beschreibung oder etwas anderes , das sich der Triage-Agent ansehen würde , um einen Kommentar oder ähnliches zu unserem Arbeitselement hinzuzufügen, weil wir nicht wirklich viel in diesem Arbeitselement haben Wenn Sie an etwas arbeiten, hätten Sie normalerweise eine viel genauere Beschreibung dessen, was diese Arbeit eigentlich ist Aber wir können diese Änderungen akzeptieren, und dann wird der Agent den Prozess durchlaufen, sie tatsächlich zu aktualisieren. Und wir können sehen, dass es zugewiesen wurde, dass es verknüpft wurde. Es sieht so aus, als ob es aufgrund eines Problems eine Sache nicht aktualisieren konnte . Sie können diesen Prozess entweder durchlaufen. Es sieht so aus, als ob das Einzige, was es nicht tun konnte, war, die Art der Arbeit zu ändern, was keine große Sache ist. Wir können hier reinkommen und das hier sehr schnell aktualisieren . Und dann könnten wir entweder antworten und chatten, um das Chat-Fenster mit KI zu öffnen und zu versuchen, das Problem zu beheben, oder wir könnten das einfach schließen, um es zu schließen Sie können also sehen, wie uns das sehr schnell hilft, uns besser zu organisieren und unsere Arbeit noch besser Das Letzte, worauf ich hinweisen möchte, bevor wir diese Lektion abschließen , ist, dass, obwohl wir einen der vorinstallierten Agenten verwenden , den Triage-Agenten, der in Rovo enthalten ist, das Agenten-Ökosystem in Jira weit über diese Standardeinstellungen hinausgeht das Agenten-Ökosystem in Jira weit über Wenn wir wieder reinkommen, könnten wir sogar einen weiteren hinzufügen, wenn Sie können also wieder sehen, worauf es bei der Stapelreihenfolge ankommt, also würde diese unter der Reihenfolge liegen, die wir bereits hinzugefügt Und wenn wir einen anderen Agenten hinzufügen wollen oder wenn wir reinkommen und uns all die verschiedenen Agenten ansehen, die wir haben, können Sie sehen, dass es eine Menge verschiedener Agenten gibt Einige von ihnen basieren auf der Lizenz. Sie ist für meine aktuelle Lizenz nicht verfügbar. Aber Sie können anfangen, eine Menge verschiedener Agenten zu sehen , die wir von vielen verschiedenen Anbietern haben, oder? Viele davon sind also von Atlassian, um bestimmte Dinge zu erledigen Aber es gibt einige von vielleicht GitHub oder einem Cloud-Agenten für Wir können das sehr, sehr schnell direkt in Jira integrieren sehr schnell direkt in Jira Und wenn keine der vorgefertigten Optionen unseren Bedürfnissen entspricht, können wir natürlich einsteigen. Wir können unseren eigenen Agenten innerhalb von Rovo Studio einrichten , um wirklich alles zu tun, was wir wollen Um es noch einmal zusammenzufassen: Mit der Aktionsregel „Trigger Agent“ können wir einen KI-Agenten automatisch ausführen wenn ein Arbeitselement von einem Status zum anderen wechselt . Und in dieser Lektion haben wir gelernt, wie wir das einrichten können, indem wir den vorinstallierten Triage-Agenten verwenden , um Arbeitselemente zu analysieren und dann einige Änderungen vorzuschlagen Aber wie wir gesehen haben, nimmt er diese Änderungen erst vor, wenn wir sie genehmigt haben, und dann wird er all diese Änderungen durchgehen und implementieren Eine letzte Sache, die du beachten solltest: Je nachdem, welchen KI-Agenten wir verwenden, können sie bei jeder Ausführung Rovo-Credits verbrauchen Jetzt gibt es für jeden Jira Cloud-Plantier monatliches Kreditlimit Es ist also immer eine gute Idee, beim Testen von KI-Agenten das Kreditlimit deines Tarifs zu überprüfen Kreditlimit deines Tarifs und zu überlegen, an welche Übergänge wir sie anhängen, damit wir nicht verbrennen In unserer nächsten Lektion gehen wir nun einen Schritt vom Workflow-Editor zurück und betrachten das Gesamtbild, indem wir einen zweiten Workflow erstellen und alles mit einem Workflow-Schema verknüpfen. Wir sehen uns dort 9. Verknüpfen von Workflows mit Workflow-Schemas: In dieser Lektion erfahren wir, wie wir Workflow-Schemata verwenden können , um mehrere Workflows miteinander zu verknüpfen. Das bedeutet auch, dass wir einen anderen Workflow benötigen. Wir werden also auch lernen, wie man einen neuen Workflow erstellt. Aber lassen Sie uns zunächst ein solides Verständnis davon bekommen , was ein Workflow-Schema ist. Im Grunde ist ein Workflow-Schema eine Map, die Jira mitteilt , welcher Workflow von welchem Arbeitstyp innerhalb eines Bereichs verwendet wird von welchem Arbeitstyp innerhalb eines Bereichs verwendet Ein Workflow-Schema könnte Jira beispielsweise anweisen, den Softwareentwicklungs-Workflow zu verwenden den Softwareentwicklungs-Workflow , den wir in diesem Kurs für die Ideen und Aufgaben in unserem Bereich verwendet haben diesem Kurs für die Ideen und Aufgaben in unserem Aber vielleicht möchten wir, dass Jira für die Fehler in unserem Bereich der Softwareentwicklung einen völlig anderen Workflow verwendet für die Fehler in unserem Bereich der Softwareentwicklung einen völlig anderen Workflow Fehler in unserem Bereich der Softwareentwicklung Um das in Aktion zu sehen, benötigen wir einen anderen Workflow als den, den wir bisher verwendet haben Beginnen wir also damit, einen einfachen Workflow für unsere Bücher zu erstellen . Ich werde den Workflow-Editor , den wir verwendet haben, beenden. Und in unserem Workflow im administrativen Bereich kommen wir rein. Das ist tatsächlich in den Space-Einstellungen. Ich komme also zu unseren allgemeinen globalen Jira-Verwaltungseinstellungen und dann zu den Workflows Und dann kommen wir rein und fügen einen Workflow hinzu. Wir werden einen neuen Workflow erstellen. Gib dem einen Namen. Das wird also unser Bug-Workflow sein. Erstellen Sie das für den Typ Bug Work. Ordnung. Also das wurde geschaffen. Dies ist nur ein sehr einfacher Arbeitsablauf. Kommen wir rein, und wir werden das schnell erledigen , weil wir uns bereits angesehen haben , wie man Status hinzufügt Aber ich werde dieselben Standardstatus hinzufügen , die wir zuvor hatten Anstatt also neue zu erstellen, werden wir nur einige sehr einfache Optionen für die Bearbeitung hinzufügen und dabei Status wiederverwenden, die wir zuvor verwendet und erledigt haben Da haben wir's. Anstatt offen zu sein, wenn ein neues Werk erstellt wird, nehmen wir das für uns und wir können den Status „Offen“ entfernen. Okay. Im Grunde genommen haben wir sehr schnell einen neuen Workflow erstellt , der genau dem Arbeitsablauf entspricht, als wir diesen Kurs im Bereich Softwareentwicklung zum ersten Mal gestartet haben. Denken Sie daran, er hatte nur diese drei verschiedenen Status. Und natürlich könnten wir weitere Status, Übergänge und Regeln hinzufügen , genau wie wir es mit dem Softwareentwicklungs-Workflow in unseren früheren Lektionen getan haben dem Softwareentwicklungs-Workflow in unseren früheren Aber das gibt uns vorerst alles, was wir brauchen, um zu demonstrieren, wie ein Workflow-Schema mehrere Workflows handhaben kann Lassen Sie uns also unseren Workflow hier aktualisieren. Jetzt müssen wir das mit einem Workflow-Schema an unseren Bereich für Softwareentwicklung binden , weil Sie sehen können, dass es sich im Moment einen inaktiven Workflow handelt, um einen inaktiven Workflow handelt, was bedeutet, dass er nirgends verwendet wird. Gehen wir also zurück zu unseren Einstellungen hier und zu unseren Workflow-Schemata. So wie Jira bei der Erstellung einen Workflow für unseren Space erstellt hat, haben wir jetzt standardmäßig Erstellung einen Workflow für unseren Space erstellt hat, haben wir auch ein Workflow-Schema Spaces benötigen immer ein Schema , das ihnen mitteilt, welche Workflows verwendet werden Es ist nur so, dass es standardmäßig nur einen Workflow in jedem Schema gibt. Lass mich dir zeigen, was ich meine. Wir arbeiten mit dem Softwareentwicklungsprojekt zusammen. Das ist also das Schema, das in diesem Projekt verwendet wird. Wenn wir hier reinkommen und das bearbeiten, meisten Schemas standardmäßig in einer Jira so sind die meisten Schemas standardmäßig in einer Jira so eingerichtet Wenn Sie nur jeden einzelnen Arbeitstyp angeben, sollten Sie sich den Arbeitstyp merken, der früher als Problemtyp bezeichnet wurde, sodass Sie diese Terminologie möglicherweise immer noch irgendwo im administrativen Bereich finden irgendwo im administrativen Bereich Jeder einzelne Arbeitstyp in diesem Projekt verwendet also den Workflow, den wir in diesem Kurs erstellt haben , den Softwareentwicklungs-Workflow , mit dem wir gearbeitet haben. Wenn wir das ändern und sagen wollten: Weißt du was? Bei Bugs wollen wir einen anderen Workflow verwenden , wir können hier reinkommen einen bestehenden Workflow hinzufügen und einen bestehenden Workflow hinzufügen. Deshalb wollten wir zuerst den neuen Workflow erstellen , weil er nach einem vorhandenen Workflow sucht. Lassen Sie uns diesen BG-Workflow hinzufügen. Als Nächstes für den BG-Problemtyp oder den Arbeitstyp, wie sie jetzt heißen. Jedes Mal, wenn ein Fehler in dem Bereich auftritt, der dieses Workflow-Schema verwendet, wird der BG-Workflow verwendet, richtig? Lassen Sie uns das also veröffentlichen und es in Aktion sehen. Jetzt könnten wir auf ein kleines Problem stoßen, wenn wir irgendetwas verknüpfen, es wird durchgehen und überprüfen und sicherstellen , dass alle Status gut sind Ich bin auf ein Problem gestoßen , bei dem wir vielleicht einen Status im Workflow entfernt haben, aber es gab Arbeitselemente , die diesen Status hatten Sagen wir, wenn wir „In Bearbeitung“, aus welchem Grund auch immer, aus welchem Grund auch immer entfernt haben und es sich dabei um Arbeitsaufgaben in Bearbeitung handelt, heißt es: Hey, was möchtest du damit machen? Möchten Sie sie einem neuen Status zuordnen? Möchten Sie diese entfernen oder diese Änderung nicht vornehmen? Es will uns nur wissen lassen. In diesem Fall, weil wir das gerade eingerichtet haben, haben wir keine vorhandenen Arbeitselemente in dem Status, den wir entfernen, oder? Wir fügen einen Workflow hinzu. Wir entfernen keine Workflows aus unserem Schema. Aber wenn wir zu unserem Projekt zurückkehren, schauen wir uns das Projekt hier an, nur ein schneller Weg, um zum Projekt zurückzukehren. Möglicherweise stoßen wir auf ein Problem, das wir beheben müssen, weil ich nicht sicher bin , ob wir hier reinkommen und ein neues Arbeitselement erstellen sollten . Ich bin mir noch nicht sicher, ob wir hier Fehler haben. Nein, wir haben keine Bugs in unserem Bereich. Kommen wir also zu unseren Arbeitselementen, Typen. Und lassen Sie uns einen Arbeitstyp hinzufügen. Wir wollen also sichergehen, dass wir tatsächlich Bugs hinzufügen, damit wir Bugs in diesem Bereich verwenden können. Da haben wir's. Drücke auf Speichern. Jetzt können wir Fehler in unserer Softwareentwicklung verwenden, und jedes Mal, wenn wir Bugs verwenden, wird dieser Bug-Workflow verwendet, anstatt den Workflow mit all den anderen Arbeitselementen, die verwendet werden. Sie können den Unterschied hier sehen, oder? All diese verwenden also den Workflow, den wir erstellt haben, und an dem wir während des gesamten Kurses gearbeitet haben. Aber dieser Arbeitstyp verwendet einen anderen Workflow. Sehen wir uns das also in Aktion an. Wenn wir wieder in unseren Raum hier springen würden, kommen wir rein und schauen uns all die verschiedenen Arbeitselemente an, die wir haben. Wir werden das Menü schließen, nur damit wir hier ein bisschen mehr Platz haben , um es in den Spalten zu sehen. Das sind also die Arbeitsaufgaben, mit denen wir in diesem Kurs gearbeitet haben . Schauen wir uns das hier an, okay? Schau dir den Status an, oder? Das haben wir uns in diesem Kurs angeschaut, Block in Bearbeitung. Sobald es in Bearbeitung ist, können wir hier reinkommen und anfangen, es zu belegen. Wir haben es tatsächlich, weil wir nicht als unser Entwickler angemeldet sind. Wenn wir uns als unser Entwickler als Ethan anmelden , kann er das tatsächlich nehmen und es durch die verschiedenen Workflows laufen lassen, oder? Das ist also der Workflow , den wir eingerichtet haben. Aber wenn sich dieses Arbeitselement ändern sollte, haben wir in einem früheren Video gesehen, wie wir das Arbeitselement in einen anderen Typ ändern können . Wenn wir das von einer Idee zu einem Bug ändern würden , beobachte, was passiert. Es heißt also, okay, warte eine Minute. Das wurde geändert. Wie wollen wir das dem neuen Workflow zuordnen, oder? Okay, im Moment ist es eine Idee. Wir wollen das so ändern, dass es sich um einen Bug handelt. Und dann wird es durchgehen und sagen: Okay, was ist der Status davon? Ist das alles gut? Und weil wir uns tatsächlich im Status „In Bearbeitung“ befinden, scheint alles in Ordnung zu sein. Es gibt keine Probleme. Dies ist eine einfache Zusammenfassung dessen, was passieren wird. Es wird sich von einer Idee zu einem Bug ändern. Es wird sich von „In Bearbeitung“ in diesem Workflow zu „In Bearbeitung mit diesem Workflow“ ändern . Und jetzt, wo es Teil des Bug-Workflows ist, wird es nicht mehr denselben QA-Prozess durchlaufen , den wir im Softwareentwicklungs-Workflow eingerichtet haben. Es wird einen völlig anderen Prozess durchlaufen, was bedeutet, dass es einfach reinkommen kann. Es kann zu tun sein. Es kann getan werden. Es wird nicht den QA-Prozess durchlaufen , den wir im Softwareentwicklungs-Workflow eingerichtet haben . Und das Backend davon befindet sich im Workflow-Editor, wo wir sehen können, dass im Workflow-Editor, wo wir sehen können ich sie hier nebeneinander öffne, damit wir diese beiden verschiedenen Workflows unter den Workflows sehen können . Wir haben den Bug-Workflow. Also werde ich das in einem neuen Tab öffnen. Ich werde es außerhalb des Bildschirms öffnen, das bald hier angezeigt wird. Wir haben den Softwareentwicklungs-Workflow , mit dem wir in diesem Kurs gearbeitet haben . Los geht's. Das ist also der Workflow, der die Idee war, als sie zum ersten Mal erstellt wurde. Und als wir ihn dann änderten, änderte er sich zu diesem Workflow, dem Bug-Workflow. Das haben wir gerade erstellt, was bedeutet, dass es keinen der anderen Status durchläuft keinen der anderen Status durchläuft , die wir hier haben, oder? Im gleichen Bereich es immer noch im selben Bereich verwendet, aber es wird nur für den Arbeitstyp BG verwendet Aber hier wird dieser Workflow für alle anderen Arbeitstypen innerhalb des Bereichs verwendet . Okay, um es noch einmal zusammenzufassen. In dieser Lektion haben wir gelernt, was ein Workflow-Schema ist. Es ist eine Möglichkeit, Arbeitstypen Arbeitsabläufen in einem Bereich zuzuordnen. Wir haben auch gelernt, wie man einen neuen Workflow erstellt und ihm anhand des Schemas mitteilt, welcher Arbeitstyp damit verwendet werden soll. Und wie Sie sich vorstellen können, all diese Übergänge und Regeln und Dinge , über die wir bisher gelernt haben sind all diese Übergänge und Regeln und Dinge , über die wir bisher gelernt haben, in jedem Arbeitsablauf enthalten , sodass wir diesen Bug-Workflow noch weiter anpassen können , wenn wir das möchten. In unserer nächsten Lektion werden wir nun alles mit den agilen Prozessen unseres Teams verknüpfen, indem wir sehen, wie sich Workflows auf unsere agilen Boards in Jira auswirken 10. Verwenden von Workflows mit Agile Boards: In dieser Lektion werden wir sehen, wie Workflows und Agile-Boards zusammenarbeiten, da unser Team dort täglich am häufigsten über unser Agile-Board mit Workflows interagiert . Kurz gesagt, Agile Boards und Jira ordnen einfach die Status aus unserem Workflow einer visuellen Board-Anzeige mit Spalten zu einer visuellen Board-Anzeige Denken Sie daran, dass jeder Status zu einer der drei Kategorien „ In Bearbeitung“ oder „Erledigt“ gehört drei Kategorien „ In Bearbeitung“ oder „Erledigt Das Board gruppiert den Status auch nach diesen Kategorien, was du an den grauen, blauen und grünen Balken ganz oben erkennen kannst blauen und grünen Balken ganz oben Grau steht für „Zu erledigen“, Blau für „In Bearbeitung“ und Grün für die Status , die sich in der Kategorie „Erledigt und Grün für die Status , die “ befinden Sehen wir uns das nun in Aktion an. Ich werde auf das agile Board für unseren Raum springen. Also lass uns reinkommen, und wir werden in den Raum selbst kommen. Und dann können wir mit dem Breadcrumb in den Raum springen mit dem Breadcrumb in den Raum ein sehr schneller Weg, um dorthin zu gelangen Und das sollte uns zum gesamten Raum selbst führen. Möglicherweise müssen wir in die Board-Ansicht wechseln wenn sie uns nicht standardmäßig dorthin führt, aber es sieht so aus, als würde das Board geladen. Ordnung, das ist also das CBON-Board, das wir in unserem Bereich eingerichtet haben Nun, wenn Sie ein Scrum Board verwenden, ist es im Grunde derselbe Prozess, mit Ausnahme des Unterschieds zwischen Scrum und Cbon, bei dem Sprints auf Scrum-Boards verwendet werden und Cbun-Boards Sprints auf Scrum-Boards Aber im Backend ist die Art und Weise, wie es mit Workflows es Diese Spalten sind mit den verschiedenen Status der Arbeitsaufgaben verknüpft den verschiedenen Status der Arbeitsaufgaben Wenn wir also in die Board-Einstellungen kommen, können wir das im Backend sehen, in den Spalten Und wir können sehen, dass „Aufgaben in Bearbeitung“ und „Erledigt“ diesen verschiedenen Spalten zugeordnet sind Wir können jedoch sehen, dass viele der verschiedenen Status, die wir in unserem Workflow erstellt haben , derzeit nichts zugeordnet sind derzeit nichts zugeordnet Also können wir das auf dem Board wirklich so anpassen , wie wir wollen, und das wird es unseren Benutzern ermöglichen, den Status sehr schnell von einem zum anderen zu wechseln Lassen Sie uns das also ganz schnell einrichten. Nehmen wir an, okay, für die Codeüberprüfung, nehmen wir an, wir wollen hier einen neuen Status hinzufügen , eine neue Spalte, sollte ich sagen. Füge das hinzu. Hoppla. Überprüfung des Codes Und dann können wir diesen Status dieser Spalte hier zuordnen. Und ich möchte das tatsächlich bewegen. Es wird also in Bearbeitung sein, bis der Code überprüft wird, und dann kann das Blockieren auch unter in Bearbeitung sein. Geht nicht, hat den Status Erledigt. Lassen Sie uns für Quar tatsächlich eine einzige Spalte erstellen aus der A arbeiten kann. Wir werden das nehmen Das wird nach der Überprüfung des Codes sein. Also nochmal, mit Agile gehst du von links nach rechts. Ray for A, QA-Tests können sich in derselben Spalte befinden. Da haben wir's. Also haben wir alles im Backend konfiguriert und die Status den verschiedenen Spalten zugeordnet Mal sehen, wie das in der Praxis funktionieren wird. Lassen Sie uns also wieder als Entwickler angemeldet sein , Ethan Wenn wir also in unserem Softwareentwicklungsprojekt zum Vorstand gehen , werden wir sehen, wie das alles zusammenhängt, oder? Wir haben also diese verschiedenen Arbeitselemente, deren unterschiedliche Status mit dieser Spalte verknüpft sind Wir können uns das hier ansehen Wenn wir es öffnen, ist der Status Code-Review Aber wenn ich das ändern würde, wenn wir das ändern würden, sagen wir, es In Bearbeitung“ umstellen würden, was passiert, ist, dass das wenn wir das ändern würden, sagen wir, es auf „In Bearbeitung“ umstellen würden, was passiert, ist, dass das auf dem Board verschoben wird und jetzt in Bearbeitung ist. Das ist also der grundlegende Prozess, richtig, wenn man etwas nimmt und es von einer Spalte in eine andere, im Backend, ändert von einer Spalte in eine andere, im Backend, , alles, was Jira tut genau das Gleiche, was wir bisher gemacht haben Es durchläuft den Prozess des Übergangs zwischen den verschiedenen Status dieser Arbeitselemente Jetzt, wo wir die Spalte geändert haben, sich auch der Status dieser Arbeitsaufgabe ändert sich auch der Status dieser Arbeitsaufgabe, richtig Also das ist jetzt im Code-Review. Es wurde tatsächlich über den Agenten abgewickelt. Sie können also sehen, dass es über denselben Triage-Agenten lief , den wir eingerichtet haben , weil das Teil des Übergangs zwischen diesen verschiedenen Status So etwas passiert auch immer noch im Vorstand. Es wartet nur auf unseren Input. Wollen wir wirklich die Prioritätsstufe ändern, oder? Also das ist diesmal der Vorschlag. Ja, lassen Sie uns weitermachen und die Prioritätsstufe ändern. Das wird aktualisiert. Wir können hier auf der Tafel sogar den heißen Hintern sehen. Ich weiß nicht, ob Sie es bemerkt haben, aber genau hier steht, dass hier ein Triage-Agent ist. Wenn wir also Arbeitselemente hineinziehen, löst das den Agenten aus, was bedeutet, dass Sie wahrscheinlich da reingehen und nachschauen wollen , was er tun wird Auch hier wird der Triage-Agent eigentlich nichts tun, ohne dass ein Mensch es zuerst überprüft und sicherstellt , dass er diese Empfehlungen akzeptiert Hinter den Kulissen kontrolliert der Workflow also immer noch alles Alles, was wir eingerichtet haben, wird immer noch auf diesem Board gesteuert. Sogar die Workflow-Schemata. Beobachten Sie also, was mit diesem Fehler passiert. Es ist im Gange. Aber wir können das nicht zur Codeüberprüfung mitnehmen . Wir können das nicht zur Qualitätssicherung bringen. Wir können das nur als erledigt betrachten, denn wenn Sie sich erinnern, gab es bei der Erstellung des BG-Workflows nur drei Status , die erledigt werden müssen, nämlich entweder „In Bearbeitung “ oder „Erledigt Wir können es nicht in diese anderen Status aufnehmen , da dieser Arbeitstyp nicht mit dem Workflow verknüpft ist , in dem diese Status enthalten sind Hier können Sie also nicht nur die Workflows selbst kontrollieren, sondern auch, welche Arbeitstypen unterschiedliche Workflows verwenden, und Sie können wirklich sehen, wie Sie damit beginnen können, dies für Ihr Team anzupassen dies für Ihr Team anzupassen Hier können die Workflows also wirklich komplex werden, je nachdem, wie Sie sie eingerichtet haben. Wenn Sie sich erinnern, haben wir einige Regeln für unsere Übergänge aufgestellt. Um also von der Codeüberprüfung zu A überzugehen, obwohl wir im Backend in dieser Spalte mehrere Status zugeordnet haben Wenn wir als unser Entwickler angemeldet sind, kann er als Ethan nur in den Status Bereit für die Qualitätssicherung wechseln, was bedeutet, dass er, wenn er das hier übernehmen würde , nur in den Status Bereit für die Qualitätssicherung übergehen kann Obwohl hier in Bearbeitung ist, kann er wählen, welchen Status er für die Qualitätssicherung haben möchte. Er kann diesen Status nur sehen, weil wir Einschränkungen haben , weil er Teil der Entwicklergruppe ist, und nur Benutzer in der Entwicklergruppe können auf Ready for QA gehen. Sobald es bereit für die Qualitätssicherung ist, schauen Sie zu, dass es aktualisiert wird und automatisch MAX zugewiesen wird. Auch das haben wir in diesem Kurs eingerichtet, nämlich die automatische Zuweisung zu MAX. Wenn wir uns nun anmelden, um als MAX angemeldet zu werden, können wir dieses Element hier sehen, es wird hier angezeigt. Sie können sehen, wie das in Echtzeit aktualisiert wird, sodass es sich in der Qualitätssicherung befindet. Jetzt, wo wir als Max als Teil des QA-Teams angemeldet sind , kann er das tatsächlich übernehmen und aktualisieren. Nun, er kann das nicht zu Dunn bringen , weil es tatsächlich durchgehen muss und im nächsten Schritt in unserem Arbeitsablauf sein Wenn Sie sich daran erinnern, dass der nächste Schritt im Arbeitsablauf darin besteht, diesen Schritt auf die Einleitung der Qualitätssicherung umzustellen , oder? , wie unser Workflow eingerichtet ist, müssen Sie also tatsächlich eine starten, bevor sie durchgeführt werden kann Aufgrund der Art und Weise, wie unser Workflow eingerichtet ist, müssen Sie also tatsächlich eine starten, bevor sie durchgeführt werden kann. An dieser Stelle möchten wir vielleicht reinkommen und sagen: Okay, wollen wir eigentlich nur eine Spalte für QA oder wollen wir eine zweite Spalte , die es uns ermöglicht, QA zu starten und das da rein zu ziehen, damit Max nicht reinkommen und dieses Arbeitselement öffnen muss, wie wir es gerade getan haben . Er könnte es jetzt einfach hineinziehen, sobald es sich im Status QA-Test befindet. Es wird getestet. Es ist noch nicht bereit für das Quad. Jetzt können wir es zu Dunn ziehen , weil er diesen Prozess durchlaufen Und noch einmal, das ist alles im Backend hier in unserem Workflow, das an die Spalten auf dem Board gebunden ist Wenn wir das also verteilen wollten, könnten wir das tun. Wenn Sie möchten, könnten wir eine zweite Spalte für die Qualitätssicherung hinzufügen. hängt wirklich davon ab, was für Ihr Team am besten funktioniert und wie das alles ablaufen soll. Der Haken dabei ist natürlich, dass jetzt als Ethan die andere Kolumne auch auf seinem Board auftaucht, aber er wird nichts dorthin ziehen können. andere Kolumne auch auf seinem Board auftaucht, aber er wird nichts dorthin ziehen können Er wird nur sehen, welche Arbeitselemente gerade getestet werden Er kann das aufgrund der Einschränkungen, die wir eingerichtet haben , nicht wirklich dorthin ziehen . Sie können sehen, dass er das aufgrund der Einschränkungen in unserem Arbeitsablauf nicht dorthin ziehen kann. Um noch einmal zusammenzufassen, was wir in dieser Lektion gelernt haben Der Status ist den Agile-Board-Spalten zugeordnet Und Sie können sogar festlegen, dass sich mehrere Status dieselbe Spalte teilen Wenn wir Arbeit auf unserem Board von einer Spalte in eine andere verschieben , übertragen wir sie in unserem Workflow eigentlich von einem Status in einen anderen Und das bedeutet, dass all diese Regeln in unserem Workflow auch gelten Wenn Sie also Probleme haben, Arbeit von einer Spalte in eine andere zu verschieben , liegt das wahrscheinlich an den Regeln wie Einschränkungen oder Validatoren, die wir in diesem Kurs kennengelernt haben Wir. Das ist eine Menge, nicht wahr? Und damit sind wir fast fertig mit unserem Kurs, aber ich möchte Sie einladen, mit mir ein letztes Video zu machen , in dem wir uns einen Moment Zeit nehmen, um über alles nachzudenken , was wir in diesem Kurs gelernt haben. 11. Kursübersicht: Du hast es bis zur letzten Lektion geschafft. In diesem Kurs haben wir die Erstellung eines benutzerdefinierten Workflows von den grundlegenden Status und Übergängen über Workflow-Regeln bis hin zu KI-Agenten erklärt und dann alles wieder in unsere agilen Boards eingebunden Lassen Sie mich Ihnen die wichtigsten Dinge denen ich wirklich hoffe, dass Sie sie daraus mitnehmen. Fangen Sie einfach an. Wir haben kein Behem mit 30 Status gebaut Wir hatten ein paar Status , die unseren Bedürfnissen entsprachen. Wenn Sie noch keinen Workflow erstellt haben, beginnen Sie mit dem , was Ihr Team tatsächlich täglich tut Erhöhen Sie die Komplexität nur, wenn der Workflow beweist , dass er benötigt wird. Ordnen Sie als Nächstes die Workflows den Arbeitstypen zu. Einige Arbeitstypen haben dieselben Lebenszyklen, wie in unserem Fall die Ideen und Aufgaben, aber andere haben keinen eigenen Arbeitsablauf, und Sie müssen nicht erzwingen ein Workflow alles wenn die Lebenszyklen für diese Arbeitstypen im Allgemeinen unterschiedlich sind. Verwenden Sie Regeln außerdem, um Probleme zu lösen, nicht um neue zu erstellen. Sie können den Übergang einschränken, um zu kontrollieren, wer Arbeit verschieben kann, Details überprüfen, um sicherzustellen, dass Daten vorhanden sind, Aktionen ausführen , Aktualisierungen automatisieren, Eingaben anfordern Daten in den entscheidenden Momenten sammeln. Jeder Regeltyp hat eine Aufgabe, aber stapeln Sie sie nicht einfach so, weil Sie es können. Haben Sie für jede, die Sie verwenden, einen Zweck. Und achten Sie auf die Rovo-Credits. Wir verwenden den Triage-Agenten mit einer benutzerdefinierten Aufforderung bei einem Übergang Rovo ist ab dieser Aufzeichnung in den kostenpflichtigen Jira Cloud-Plänen, Standard Premium und Enterprise enthalten Standard Premium und Enterprise Es gibt also keine separate Lizenz, über die man sich Gedanken machen müsste, aber für jede Planstufe gibt es ein monatliches Kreditlimit pro Nutzer, und Agenten verbrauchen bei jeder Ausführung Credits Setzen Sie sie also dort ein, wo ihre Analyse einen echten Mehrwert bietet, und nicht bei jeder einzelnen Umstellung Und holen Sie sich weiterhin Feedback und aktualisieren Sie Ihre Workflows. Sie passen dies an, wenn sich Ihre Teamprozesse weiterentwickeln, fügen Status hinzu, wenn neue Übergaben auftauchen, und entfernen sie, wenn sie Testen Sie die Änderungen, bevor Sie Ihren Workflow für Ihr gesamtes Team aktualisieren Das Schwierigste beim Erstellen von Workflows besteht darin die Überzeugung zu überwinden, dass sie beim ersten Versuch perfekt sein müssen Das tut es nicht. Baue etwas , das für heute funktioniert. Iterieren Sie, wenn das Team mehr benötigt, und so erhalten Sie einen Workflow , der der tatsächlichen Arbeitsweise Ihres Teams entspricht Vielen Dank, dass Sie mich auf dieser Reise begleitet haben. ob Sie ein Jira-Administrator, ein Space-Administrator oder ein Teamleiter sind , ich hoffe, Sie haben jetzt die Tools und das Selbstvertrauen, Workflows zu erstellen, die der tatsächlichen Arbeitsweise Ihres Teams entsprechen Nochmals vielen Dank fürs Zuschauen.