Das Erstellen von Jira Workflows ist eine der anspruchsvollsten Tätigkeiten beim Aufsetzen eines neuen Projektes. Ein guter Workflow muss alle fachlichen und technischen Anforderungen erfüllen, gleichzeitig aber auch verständlich und selbsterklärend sein. Eine Aufgabe, die angesichts der zahlreichen Konfigurationsmöglichkeiten von Jira nicht immer leicht zu erfüllen ist. Einige der typischen Fragen, die mir in meiner Arbeit als Jira-Berater mit Workflows begegnen, habe ich im folgenden Artikel zusammengefasst.
Was ist ein Workflow / Arbeitsablauf?
Ein Jira Workflow – in der deutschen Version „Arbeitsablauf“ – beinhaltet die Status (Anm.: der Plural von Status lautet ebenfalls Status) und Statusübergänge, die ein Vorgang im Laufe seines Lebenszyklus durchlaufen kann.
- Status: die Zustände, in denen sich ein Vorgang befinden kann, z.B. „Offen“, „In Bearbeitung“, „Geschlossen“
- Statusübergänge: Die möglichen Übergänge zwischen den Status eines Vorgangs, z.B. von „Offen“ zu „In Bearbeitung“ oder von „Offen“ zu „Geschlossen“. Statusübergänge können mit bestimmten Eigenschaften (Berechtigungen, Folgefunktionen, Events) versehen werden.
Was gibt es beim Erstellen von Workflows zu beachten?
Bei der fachlichen Ausarbeitung von Workflows empfehle ich meinen Kunden meist, mit einem einfachen und nachvollziehbaren Workflow zu starten. Häufig werden Workflows fachlich „überdesigned“: ein solcher Workflow deckt zwar fachlich alle Szenarien ab, ist aber in Folge dessen sehr komplex und kann von den Anwendern letztendlich nicht nachvollzogen werden. Die Folge sind Unsicherheit, Fehlbedienung und fehlende Akzeptanz. Die Kunst eines guten Workflows besteht also darin, einen Kompromiss zwischen der Abbildung theoretischer Arbeitsabläufe und der letztendlichen Benutzbarkeit in der Praxis zu finden.
Ein weiterer Punkt, an dem es in der Praxis häufig mangelt, ist eine aktuelle und frei zugängliche Dokumentation. Diese sollte sowohl eine Übersicht über die im System vorhandenen Workflows, als auch eine fachliche Beschreibung derer Status und Statusübergänge beinhalten:
- Was bedeutet welcher Status?
- Welche Konsequenzen hat ein Statusübergang?
- Wird eine Benachrichtigung ausgelöst?
- Welche Statusübergänge darf ich in einer bestimmten Rolle durchführen?
Insbesondere bei komplexeren Workflows – in denen z.B. Statusübergänge auf bestimmte Rollen eingeschränkt sind und mit Benachrichtigungen gearbeitet wird – ist es für die Anwender enorm wichtig, die fachliche Bedeutung der Status sowie die möglichen Statusübergänge und Konsequenzen ihrer Aktionen zu kennen.
Wie sieht ein typischer Jira Workflow aus?
Ein sehr einfaches Beispiel für einen Workflow in Jira ist der Arbeitsablauf einer Aufgabe:
Der Workflow ist simpel, deckt aber eine eine erstaunliche Vielzahl von einfachen ToDo’s ab und bildet letztendlich die Grundlage für eine Vielzahl weiterer Workflows. Mit einem zusätzlichen Status „Gelöst“ und „Wiedereröffnet“ können z.B. auch Vorgänge abgebildet werden, die einen Zwischenschritt für die Qualitätssicherung benötigen:
In den meisten Fällen lässt sich das Grundgerüst eines Workflows auf das Trio Offen – In Bearbeitung – Geschlossen zurückführen. Möchte man also einen komplett neuen Workflow erstellen, sollte man auf dieser Basis beginnen und je nach Anwendungsfall weitere Status ergänzen.
Was ist ein Arbeitsablaufschema?
Ein Arbeitsablaufschema weist Vorgangstypen einen Arbeitsablauf zu. Jedem Projekt wird ein Arbeitsablaufschema zugeordnet – d.h. in jedem Projekt wird durch das Arbeitsablaufschema festgelegt, welcher Vorgangstyp welchen Workflow verwendet.
Wie kann man einen Statusübergang auf bestimmte Nutzer beschränken?
Um einen Statusübergang mit Bedingungen zu versehen, öffnet man als Administrator zunächst den Bearbeiten-Modus des gewünschten Workflows. Nun klickt man auf denjenigen Statusübergang, der mit einer Bedinung versehen werden soll. Es öffnet sich eine Maske mit folgenden Optionen:
- Bedingungen: nur bestimmte Nutzer dürfen den Statusübergang durchführen, z.B. nur der Autor, nur der aktuelle Bearbeiter, nur Nutzer mit einer bestimmten Projektrolle oder einer bestimmten Projektberechtigung
- Bestätigungen: Validierung der Bildschirmmaske, die dem Nutzer beim Statusübergang angezeigt wird, z.B. Test auf leere Felder oder Abfrage bestimmter Feldwerte
- Folgefunktionen: z.B. Vorgang zuweisen, Vorgangsfeld aktualisieren, Lösung setzen/löschen, Ereignis für Benachrichtigung auslösen
Zusätzlich kann für jeden Statusübergang eine Bildschirmmaske ausgewählt werden, die dem Nutzer beim Durchführen des Übergangs angezeigt wird. Dafür geht man wieder in den entsprechenden Statusübergang und dort auf „Diesen Übergang bearbeiten“. Unter „Anzeige des Übergangs“ kann jede vorhandene Bildschirmmaske für diesen Übergang ausgewählt werden.
[…] zum Anlegen von Arbeitsabläufen unter Jira FAQ: Workflows sowie Jira Workflows: Best Practices und typische […]
Hallo Sebastian,
danke für die super Beschreibung. Ich hätte eine Frage zu Unteraufgaben.
Ist es möglich bei der Erstellung einer Unteraufgabe nicht einen aktuellen Bearbeiter, sondern eine Gruppe auszuwählen?
Die Gruppenmitglieder sollten dann alle die Unteraufgabe bekommen?
Gruß
Sven
Hi Sven,
ein Vorgang kann leider immer nur einen konkreten Benutzer als Bearbeiter haben, keine Gruppe oder Projektrolle. Das wird sich höchstwahrscheinlich auch in Zukunft nicht ändern (siehe https://jira.atlassian.com/browse/JRA-1397).
Atlassian hat aber eine FAQ dazu: https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users
Kommt also drauf an, warum der Vorgang mehreren Benutzern zugewiesen werden soll:
– sollen alle aus der Gruppe benachrichtigt werden, dann am besten ein benutzerdefiniertes Gruppenfeld für deinen Untervorgangstyp anlegen und im Benachrichtigungsschema des Projektes dem „Wert des ben.def. Gruppenfelds“ die entsprechenden Benachrichtigungen zuweisen
– gehts um die Rechte im Arbeitsablauf, dann könntest du einen eigenen Workflow für den Untervorgangstyp anlegen und dort in den entsprechenden Schritten die Gruppen eintragen, die den Statuswechsel durchführen dürfen
– gehts um die Zuweisung als Aufgabe, dann könntest du auch ein benutzerdefiniertes Feld (Dropdown mit voreingestelltem Text) anlegen, darin für jede „Gruppe“ einen Eintrag anlegen (Developer, Tester usw.). Die Developer / Tester könnten sich dann einen Filter aufs Dashboard holen – z.B. als Developer: alle Subtasks aus Projekt X, in denen im Dropdown-Feld der Wert „Developer“ ausgewählt wurde
Das wären meine spontanen Ideen 🙂
Grüße,
Sebastian
Danke für die ausführliche Beschreibung.
Muss ich wohl doch pro Vorgang für ca 24 Benutzer jeweils eine Unteraufgabe erstellen.
Schade.
Danke Dir
Hallo Zusammen,
Ich hätte eine Frage zum Anforderunsmanagement:
Momentan arbeiten wir noch wie in der Steinzeit 😉
Soll heißen: Alles auf Papier
1. Anforderung wird vom Requestor ausgefüllt
2. Der Vorgesetzte unterschreibt
3. Anforderung landet beim Teamleiter Softwareentwicklung
4. Dieser weist die Anforderung einem freien Entwickler zu
5. Nachdem die Anforderung umgesetzt wurde, geht sie zurück zum Requestor zwecks Tests
6. Anschließend landet sie entweder beim Entwickler (bei Fehlern) oder, wenn erfolgreich getestet, beim Vorgesetzten zur erneuten Unterschrift
7. Letzter Schritt: Unterschrift Abteilungsleiter Softwareentwicklung als Freigabe zum Release
Wir suchen nun eine Software, die diesen Workflow abbilden kann.
Ist dies mit Jira überhaupt möglich ?
Gruß
Robert
Hi Robert,
der Arbeitsablauf ist mit Jira problemlos möglich, genau für Szenarien wie Anforderungsmanagement ist Jira konzipiert. In eurem Fall würde man einfach einen Workflow erstellen, der euren realen Arbeitsabläufen entspricht. Also: Requestor erstellt die Anforderung, weist diese dem Vorgesetzten zu, der genehmigt oder lehnt ab, beim Genehmigen wird sie dem Teamleiter zugewiesen usw.
Solche Arbeitsabläufe mit Verantwortlichen, Verzweigungen und Genehmigungen sind also kein Problem. Mit Jira könntet ihr dann mittelfristig auch Fehler oder Aufgaben (oder andere Vorgangstypen, je nach Art eures Unternehmens) in gleicher Weise elektronisch managen, z.B. um Fehler jeweils ihrer Anforderung zuordnen zu können.
Falls ihr Interesse an Jira habt, gib mir einfach mal hier oder unter sebastian_hoehne@web.de Bescheid, ggf. kann ich euch ja bei der Einführung unterstützen.
Grüße,
Sebastian
Hallo Sebastian,
vielen Dank für die vielen hilfreichen Texte! Bin derzeit dabei, mir einen Überblick über Confluence und Jira zu verschaffen, um zu eruieren, ob es für mein Unternehmen in Frage kommt.
Eine konkrete Frage ist mir nach den bisherigen Tests noch nicht klar: Kann ich Tasks an zwei Personen vergeben? Ich kann ja jeweils einen Assignee und einen Reporter auswählen, aber verstehe es so, dass hier nur der Workflow geregelt wird, wer an wen berichtet. Ist es möglich, einen zweiten Reporter auszuwählen?
Danke im Voraus und beste Grüße
Hallo Jan-Kristian,
zum Reporter und Assignee: der Reporter ist derjenige, der den Vorgang erstellt hat (der Autor). Der Assignee ist derjenige, dem der Vorgang gerade zugewiesen ist (der aktuelle Bearbeiter des Vorgangs). Der Assignee ändert sich meistens im Laufe des Workflows mehrmals durch Zuweisen des Vorgangs an eine andere Person; der Reporter bleibt dagegen in den meisten Fällen gleich. Trotzdem kann auch der Reporter durch Bearbeiten des Vorgangs nachträglich jederzeit geändert werden.
Wichtig: sowohl als Reporter als auch Assignee wird immer nur ein konkreter Benutzer akzeptiert, keine Gruppen oder mehrere Nutzer. Wenn es aber notwendig sein sollte, dass ein Vorgang mehreren Personen zugewiesen ist (z.B. damit mehrere Personen über einen Fortschritt im Workflow benachrichtigt werden), kann man das mit benutzerdefinierten Feldern lösen. Man legt dafür einfach zusätzliche Felder mit einer Personenauswahl an, und richtet die Benachrichtigungen und Berechtigungen entsprechend ein.
Meistens lässt sich so eine Anforderung mit dem Bordmitteln von Jira gut lösen, in deinem Fall müssten wir uns dann einfach anschauen, wofür der zweite Reporter genau benötigt wird bzw. welche Funktionalität dahinter stehen soll, dann findet sich da mit Sicherheit auch eine einfache Lösung.
Falls du noch weitere Fragen hast, jederzeit gerne – falls du Intersse an Workshops / Beratung / Schulung hast, natürlich ebenfalls jederzeit gern.
Viele Grüße,
Sebastian
Hallo Sebastian,
Ich habe eine Frage zu den Benachrichtigungen. Ist es möglich sie so zu konfigurieren, dass ich den E-Mail-Inhalt nach meinen Wünschen anpassen kann? Praktisch eine selbste-erstellte Vorlage, die auch mehr aussieht wie eine Textmail.
Grüße
Hallo Kevin,
ja das geht, allerdings nicht über die normale Administration. Dafür musst du die Velocity-Templates der Mails anpassen – wie das geht, steht auf https://confluence.atlassian.com/display/JIRA/Customizing+Email+Content. Du kannst entweder neue Email-Templates anlegen und in der Jira Admin einem Event zuweisen (und dieses Event dann in einem Statusübergang auslösen) oder die bestehenden Mailtemplates anpassen.
Dabei musst du beachten, dass du deine Anpassungen an den Templates bzw. die neuen Templates sichern musst, da du die Änderung nach einem Update wieder neu durchführen musst.
Hoffe das hilft!
Grüße,
Sebastian
Nachtrag: mir ist grad noch das „Email This Issue Plugin“ (https://marketplace.atlassian.com/plugins/com.metainf.jira.plugin.emailissue) eingefallen. Mit dem Plugin kann man aus JIRA manuell Mails nach außen schicken, zusätzlich kann man aber auch bei Statusübergängen eine Mail versenden, also wie bei den Benachrichtigungen. Bei dem Plugin kann man auch Mail-Templates erstellen und diese Templates dann Projekten und / oder Vorgangstypen zuweisen, damit sollte sich das also auch umsetzen lassen. Bei den Screenshots unter http://www.meta-inf.hu/wiki/display/PLUG/Email+Templates sieht man ganz gut, was man damit machen kann.
Grüße,
Sebastian
Hallo Sebastian,
danke für die ausführliche Erklärung.
Siehst Du eine Möglichkeit, in der Bildschirmmaske, die bei einem Statusübergang angezeigt wird, einen statischen Text anzuzeigen. um den Nutzer ausführlicher über die Folgen seines Schrittes zu informieren?
Danke im Voraus!
Beste Grüße,
Timo
Hi Timo,
da würden mir 2 Möglichkeiten einfallen:
Hoffe, das hilft dir weiter!
Grüße,
Sebastian
Hallo Sebastian,
aktuell habe ich folgendes Problem.
Ich habe selbst einen Workflow gebaut. Wenn dieser am Ende in den Status „Geschlossen“ geht, lasse ich auch eine Lösung setzen.
Frage:
Nachdem der Status „Geschlossen + Lösung“ gesetzt ist, kann der Vorgang dennoch bearbeitet / kommentiert werden.
Mein Ziel wäre es, wenn ein Vorgang geschlossen ist kann dieser weder bearbeitet noch kommentiert werden.
Könntest du mir dazu bitte einen Tipp geheb?
Danke und Gruß,
Sven
Hi Sven,
kein Problem, gerne: das Bearbeiten kannst du verhindern, indem du in deinem Workflow den Status „Geschlossen“ auswählst und dort unter „Optionen“ und „Eigenschaften“ den Schlüssel „jira.isssue.editable“ mit dem Wert „false“ einträgst. Dann kann der Vorgang in diesem Status nicht mehr bearbeitet werden – ist im Standardarbeitsablauf auch schon so eingerichtet, kannst also auch da nachschauen wie das aussehen muss.
Mit dem Kommentieren ist es genau das gleiche, nur dass du diesmal den Wert „jira.permission.comment.user“ auf „false“ setzen musst (bei Jira 5 „denied“ statt „false“).
Grüße,
Sebastian
Hallo Sebastian,
ich hätte da mal noch eine Frage zu foglendem Probelm das jetzt dadurch auftritt.
Beispiel:
Wir haben 2 Status:
„Offen“ und „Geschlossen“
An den Staus „Geschlossen“ füge ich jetzt folgenden Eigenschaften hinzu:
jira.isssue.editable = false
jira.permission.comment.user = false
Dies machen wir ja, damit der Vorgang(Es wird auch eine Lösung gesetzt) weder editierbar noch Kommentierbar ist.
Wenn wir einen Übergang machen von „Offen“ nach „Geschlossen“ lassen wir eine Bildschirmmaske anzeigen.
Auf dieser kann ein Kommentar eingegeben werden.
Leider kommt beim Übergang jetzt folgende Fehlermeldung
Vorname Nachname, Sie sind nicht berechtigt, einen Kommentar für diesen Vorgang zu verfassen.
Der User hat aber die Berechtigung zu kommentieren.
Hast Du vielleicht einen Tipp für mich?
Gruß,
Sven
Hi Sven,
da habe ich leider schlechte Nachrichten: Atlassian hat die Validierung bei Statusübergängen überarbeitet, jetzt gelten die Einstellungen des Zielstatus und nicht mehr die des Ausgangsstatus. Das hat genau das von dir beschriebene Verhalten zur Folge, es gibt unter https://jira.atlassian.com/browse/JRA-40997 auch ein Ticket dazu. So wie es aussieht, bleibt es auch bei diesem neuen Verhalten, damit ist die Einstellung so nicht mehr möglich. Es könnte noch mit dem Script Runner Plugin funktionieren (installieren und dann ein „Behaviour“ für das Comment Field erstellen, damit es im Status „Closed“ Readonly ist). Kommt aber auf einen Versuch an, ich kann nicht genau sagen ob es damit klappt.
Grüße,
Sebastian
Hallo Sebastian,
danke für die schnelle Antwort.
Also ich finde es nicht wirklich zukunftsorientiert, wenn Atlassian ständig an solchen Funktionen herumwerkelt.
Vor allem wenn man Workflows hat, die schon Jahre im Einsatz sind.
Ich habe jetzt einen Workaround für das Problem gefunden.
Dieser ist wie folgt:
Wir haben ein Textfeld(Mehrzeilig) mit dem Namen „Abschlusskommentar“ erstellt.
http://images-hochladen.de/up/pic_b/1e753840ea24dab013b46a5054284069.png
Eine Bildschirmmaske mit Namen „Abschlusskommentar“ und dem Feld „Abschlusskommentar“
http://images-hochladen.de/up/pic_b/e90be432bd2da0828972399ec2ea0c04.png
Diese lassen wir jetzt bei dem Übergang von „Offen“ nach „Geschlossen“ anzeigen.
Durch ein Plugin das wir im Einsatz haben, wird folgende Möglichkeit bei dem Reiter „Folgefunktionen“ angeboten.
Copy or parse Text to a field.
http://images-hochladen.de/up/pic_b/87e54216cf4bf0f804b9b82e1e18fa62.png
Dort können wir einstellen, dass der Wert des Feldes „Abschlusskommentar“ als ein neues Kommentar gepostet wird.
http://images-hochladen.de/up/pic_b/385a25bf5cc35f12e765e9e2d99681c2.png
http://images-hochladen.de/up/pic_b/430b8b319bf934eb495f440a15ddd8a0.png
Das geht super.
http://images-hochladen.de/up/pic_b/c1d3eddd5527d7aa1e8eaba350972ab1.png
Danke für deinen Support in der Sache.
Gruß,
Sven
Hey Sebastian,
danke für deine Unterstützung. Werde ich heute gleich mal ausprobieren.
Übrigens, vielleicht ist das Plugin ja was für deinen Blog?
http://wordpress.org/plugins/subscribe-to-comments-reloaded/
Haben gute Erfahrung damit gemacht.
Danke und Gruß,
Sven
Hallo Sebasatian,
vielen Dank für die Erklärungen. Ich habe nun einen kleinen QS Workflow dargestellt. Dieses sieht so aus:
Create->Open
Open-> Blocked oder In progress
Blocked-> Hier ist aktuell Ende
In Progress-> QS
QS-> Approve oder zurück zu Open
Nun steht Blocked da, gerne möchte ich geblockte Tickets in den Status Open zurück geben können. Füge ich also einen neuen Übergang von Status Blocked zu Status Open hinzu, meldet Jira immer: „Diese Funktion kann nicht auf einem Arbeitsablaufentwurf ausgeführt werden.“ Selbige Meldung kommt auch, von Blocked-> Approve. Sobald ich einen Arbeitsablauf aber bearbeiten möchte, wird dieser zu einem Entwurf.
Wie ist hier das richtige Vorgehen um den Arbeitsablauf nachträgliche korrekt verändern/erweitern zu können?
Danke und Gruß,
Simon
Hi Simon,
wenn du einen aktiven Workflow bearbeitest (d.h. einen Workflow, der in einem Workflow-Schema verwendet wird), erstellt Jira automatisch diese „Entwurfsversion“, in der man einige Änderungen vornehmen kann, aber eben nicht alle (siehe hier). Stattdessen musst du den Workflow kopieren – diese Kopie ist dann ein neuer, inaktiver Workflow, den du beliebig bearbeiten kannst. Wenn der neue Workflow fertig ist, gehst du in das entsprechende Arbeitsablaufschema und weist dort allen Vorgangstypen, die vorher den alten Workflow verwendet haben, den neuen Workflow zu. Ggf. erscheint dabei eine Migrationsmaske, wenn z.B. der alte Workflow Status hatte, die in dem neuen Workflow nicht mehr vorkommen.
Hoffe, das hilft dir weiter!
Grüße,
Sebastian
Hi Sebastian,
vielen Dank für die Info. Den entscheiden Textabschnitt habe ich im Wiki wohl überflogen. Ich werde es ausprobieren.
VG,
Simon
Hallo Sebastian,
das sind geniale Erklärungen vielen Dank hierfür.
Wir stehen hier vor dem Problem dass wir 2 Teams sind. Entwickler und das Kundenunternehmen. Das Kundenunternehmen ist letztendlich nicht der Endkunde und filtert praktisch für die Entwickler die Todos. Gerne würden wir das Kundenunternehmen mit in Jira nehmen damit die Ihre Aufgaben dort pflegen können – jedoch gerne die Entwicklungsissues verstecken damit der Kunde eben nicht alles mitbekommt 😉 Ist es sinnig dies über 2 Projekte abzubilden oder gibt es hierfür ein besseres , intelligenteres Vorgehen?
Viele Grüße
Micha
Hallo Micha,
ihr habt 2 Möglichkeiten: entweder ich löst das über getrennte Projekte (wie du schon geschrieben hattest) und steuert in jedem Projekt per Berechtigungsschema, wer das Projekt sehen darf. Als zweite Möglichkeit könnt ihr aber auch gemeinsam mit dem Kunden in einem Projekt arbeiten und darin ein Sicherheitsschema verwenden (siehe Artikel zu Berechtigungen). In einem Sicherheitsschema legt ihr Sicherheitsstufen an (z.B. „intern“ und „extern“) und weist jeder Stufe bestimmte Nutzer/Gruppen/Rollen zu. Im Projekt aktiviert ihr das Sicherheitsschema und könnt dann für jeden einzelnen Vorgang (!) in diesem Projekt festlegen, welche Sicherheitsstufe er haben soll. Wenn ein Vorgang z.B. auf Stufe „Intern“ steht, können nur noch die Nutzer/Gruppen/Rollen, die dieser Stufe zugeordnet sind, diesen Vorgang sehen.
Ihr müsst nur darauf achten, im Berechtigungsschema dieses Projektes das Recht „Sicherheitsstufe festlegen“ auf interne Nutzer zu beschränken und im Sicherheitsschema eine Standardstufe auszuwählen, damit niemand ausversehen Vorgänge für externe sichtbar machen kann.
Grüße,
Sebastian
P.S. Evtl. müsst ihr auch noch das (bereits vorhandene) Feld „Sicherheitsstufe“ in eure Bildschirmmasken einbauen, damit man auch eine Stufe auswählen kann.
Hallo,
bin kompletter Neuling mit Jira und wüsste gern ob man ein Ticket auch mehreren Personen zur Bearbeitung zuweisen kann? Und ob es auch möglich ist jemanden ein Ticket nur zur Kenntnissnahme zuzuweisen?
Hallo,
ein Ticket kann in Jira immer nur einem einzelnen Bearbeiter zugewiesen werden – d.h. es sieht auch immer nur eine Person dieses Ticket unter „Meine offenen Vorgänge“. Allerdings: je nachdem, was man erreichen möchte (sollen z.B. mehrere Personen über den Fortschritt des Tickets informiert werden, oder mehrere Personen sich „verantwortlich“ fühlen) kann man das auch anders erreichen.
Man kann u.a. ein benutzerdefiniertes Feld vom Typ „Benutzerauswahl“ hinzufügen, z.B. mit dem Namen „Weiterer Verantwortlicher“. In dieses Feld trägt man dann im Ticket den weiteren Verantwortlichen ein – danach kann man in Filtern, Dashboards usw. dieses Feld mit einbeziehen. Als Nutzer kann ich mir z.B. alle offenen Vorgänge anzeigen lassen, in denen ich in diesem Feld eingetragen bin. Alternativ kann man auch ein Feld vom Typ „Gruppenauswahl“ verwenden. Auf diese Weise kann man statt eines Einzelnutzers eine ganze Nutzergruppe in einen Vorgang eintragen, damit z.B. alle Nutzer dieser Gruppe über den Fortschritt des Tickets benachrichtigt werden.
Eine Kenntnisnahme könnte man am besten über den Workflow einbauen, indem man z.B. in alle gewünschten Status einen Übergang „Zur Kenntnis genommen“ einbaut. Wenn jemand diesen Übergang durchführt, wird das in der Historie protokolliert und man hat die Bestätigung, dass der Nutzer den Vorgang zur Kenntnis genommen hat.
Beste Grüße,
Sebastian Höhne
Guten Tag Herr Höhne,
ich suche nach einer Möglichkeit, den Status automatisiert ohne Klicken durch den Bearbeiter zu ändern, sobald alle Bedingungen für den Übergang erfüllt sind.
Grüße,
Simon
Hallo Simon,
das kommt ganz auf die Bedingungen an, die erfüllt sein müssen. Wenn der Statusübergang ohne Aktion eines Nutzers durchgeführt werden soll, läuft es eigentlich immer auf ein Script hinaus (https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner). Damit müsste man einen Service erstellen, der regelmäßig einen bestimmten Filter durchläuft und darin die Bedingungen prüft und ggf. Aktionen durchführt.
Beste Grüße,
Sebastian
Danke für die schnelle Rückmeldung.
Mit eigenen Skripten und Groovy bin ich leider noch nicht so vertraut.
Eine Bedingung ist beispielsweise ein bestimmter Status eines bestimmten Untervorgangs. Den entsprechenden Übergang könnte man als Push-Ereignis für die Prüfung der Bedingungen nehmen. Allerdings weiß ich nicht wie das gehen sollte, da es sich ja um einen anderen Vorgang handelt. Gibt es dafür vielleicht ein passendes Add-On?
Viele Grüße,
Simon
Hallo Simon,
du könntest dir mal die Workflow Toolbox (https://bitbucket.org/fcarmario/jira-workflow-toolbox/wiki/Full%20List%20of%20Features) und die Misc Workflow Extensions (https://marketplace.atlassian.com/plugins/com.innovalog.jmwe.jira-misc-workflow-extensions) ansehen, damit kann man zumindest Dinge wie „Bei Statusübergang X eines Untervorgangs und ggf. weiteren Bedingungen soll der Elternvorgang automatisch in Status Y übergehen“ umsetzen. In der Doku der Plugins ist das jeweils unter „Conditions“ – „Transition Parent Issue“ zu finden. Ich weiß nicht, ob das jeweils flexibel genug für deine Anforderungen ist, aber es geht zumindest in diese Richtung.
Beste Grüße,
Sebastian
Hallo, Sebastian,
eine sehr gut greifbare Übersicht über Sinn und Möglichkeiten von Workflows. Ich habe auch gerade angefangen, damit zu experimentieren und frage mich folgendes:
Ist es möglich, bei einem Übergang/Arbeitsschritt einzurichten, daß mit dem Ausführen des Schritts automatisch eine Unteraufgabe an den Vorgang angehängt wird?
Grüße
Cord
Hallo Cord,
zunächst Entschuldigung für die späte Antwort! Falls die Frage noch aktuell ist: mit Bordmitteln ist das nicht möglich, es gibt aber verschiedene Plugins dafür. Z.B. „Quick Subtasks“ und „Create on Transition„. Mit beiden Plugins können bei einem Statusübergang automatisch Unteraufgaben erstellt werden – ich persönlich finde aber „Create on Transition“ wesentlich funktionsreicher und auch besser zu bedienen. Damit können z.B. Bedingungen festgelegt werden, Feldwerte vom originalen Vorgang in den neuen Vorgang übernommen werden uvm.
Hoffe, das hilft dir weiter!
Grüße,
Sebastian
Hallo Sebastian,
ich bin gerade dabei ein neuen Projekt zu erstellen und sollte hierzu den folgenden Workflow einrichten bzw. prüfen ob dies realisierbar ist:
Ticket A ist momentan noch im Status „In Process“ und wird wird in naher Zukunft auf „Closed“ gesetzt.
Ticket B kann erst starten sobald Ticket A auf „closed“ gesetzt ist.
Gibt es eine Möglichkeit, Tickets so zu referenzieren (evtl. mit Plugins/Add-ons), dass der Status + Fälligkeitsdatum angepasst wird, wenn die vorher erforderlichen Schritte erledigt bzw. Tickets geschlossen sind?
Grüße
Johannes
Hallo Johannes,
ja das geht, dafür bräuchtest du die Workflow Toolbox oder alternativ den Script Runner. Mit der Toolbox ist es einfacher; mit dem Script Runner muss man ein entsprechendes Script schreiben.
Für die Toolbox sind das eigentlich 2 verschiedene Anforderungen:
… die Anleitung liest sich etwas kompliziert, vielleicht einfach mal in die Condition / Post-Function reinklicken, dann erklärt sich einiges auch von selbst.
Grüße,
Sebastian
Hallo Sebastian,
ich habe auch mal eine Frage, die zu den anderen Themen passt.
Ist es irgendwie mit normalen Mitteln möglich, den Statuswechsel – sowie den Inhalt eines benutzerdefinierten Feldes in einem Vorgang , bei eben diesem Workflowschritt in alle verknüpften Vorgänge zu übernehmen?
Gruß Ingo
Hallo Ingo,
sofern deine Frage noch aktuell ist: ja, das geht mit dem Plugin „Workflow Toolbox“. Daraus verwendet man die Folgefunktion „Write Field On Linked Issues“, mit der man die Feldwerte eines Vorgangs in die verknüpften Vorgänge übernehmen kann. Auf die gleiche Weise, kann man die verknüpften Vorgänge auch automatisch einen Statuswechsel durchführen lassen.
Die Doku dazu:
Write Field On Linked Issues Or Subtasks und
Make Linked Issues and Subtasks Progress through its Workflows
Grüße,
Sebastian
Hallo Sebastian,
wir haben Jira Service Desk und Jira im Einsatz. Unser Workflow sieht vor, dass wir bei einem Ticket, was uns ein Kunde über das Service Desk einstellt erst einmal evaluieren, ob es wirklich ein Fehler ist. Falls ja, erstellen wir ein verknüpftes Ticket in dem korrespondierenden Jira Projekt. Dort wird in den agilen Entwicklungsprozess überführt. Nach dem das Ticket gefixt wurde (Status Done) gibt es noch eine finale QA im Release (Status Released). Erst bei erfolgreichen NAchtest dort, geht das Ticket auf Closed.
Jetzt die Frage: Gibt es einen Automatismus, wie man mit Jira Boardmitteln das Ursprungsticket im Service Desk automatisch mit schließen kann (Also Jira Ticket geht auf Closed und das verknüpfte Ticket soll automatisch auch auf Closed gehen)?
Vielen Dank und viele Grüße,
Jörg
Hallo Jörg,
ja den gibt es: in den Projekteinstllungen des ServiceDesk – Projektes gibt es das Menü „Automatisierung“. Darin kann man eine Regel „Update when a linked issue changes“ erstellen und in dieser Regel u.a. angeben, bei welchem Verknüpfungstyp und welchem Statusübergang der Vorgang im Service Desk geschlossen/bearbeitet/kommentiert werden soll.
Beste Grüße,
Sebastian
Herzlichen Dank für die schnelle Antwort. Ich werde das mal in unserem Testsystem versuchen umzusetzen und entsprechend zu konfigurieren.
Viele Grüße,
Jörg