Flux de travail Jira : Créer des flux de travail personnalisés qui correspondent au travail de votre équipe

1. Introduction du cours: Bienvenue dans ce cours consacré aux flux de travail Jira. Je m'appelle Dan Lefeb et dans ce cours, nous allons apprendre à créer des flux de travail personnalisés qui correspondent à la façon dont votre équipe travaille réellement À la fin de ce cours, vous serez en mesure de personnaliser les flux de travail pour différents types de travail, tels que les idées, les tâches, les bogues. Ils peuvent chacun avoir leur propre flux de travail dans vos espaces Jira Nous allons également apprendre comment ajouter des restrictions afin que seules des personnes spécifiques puissent effectuer certaines transitions. Nous allons apprendre à valider les données avant qu'une transition ne se produise entre deux statuts différents Nous apprendrons également à automatiser les tâches à l'aide d'actions et d'agents d'intelligence artificielle, déployer des flux de travail dans votre espace à l'aide de schémas de flux de travail, connecter votre flux de travail à des tableaux agiles, et bien plus encore. Ce cours se concentre sur les espaces gérés par l' entreprise, ce qui vous donne un contrôle total sur les flux de travail et les schémas. Cela signifie également que nous disposerons autorisations administratives globales pour pouvoir configurer les flux de sur l'ensemble de notre instance Jira Désormais, si vous utilisez des espaces gérés par l' équipe, vous pourrez toujours tirer parti de la plupart des leçons de ce cours, car l'éditeur de flux de travail dans les espaces gérés par l'équipe fonctionne la même manière que dans espaces gérés par l' entreprise que nous utilisons tout au long de ce cours. À la fin de ce cours, vous disposerez d'un flux de travail de statut entièrement fonctionnel avec des restrictions, des validations, des actions automatisées agents IA déployés dans votre espace Avant de passer à Jira, prenons quelques instants pour aborder les concepts fondamentaux des flux de travail de Jira, et nous aborderons cela dans notre prochaine leçon 2. Concepts de base des flux de travail Jira: Dans cette leçon, nous aborderons les concepts fondamentaux qui sous-tendent les flux de travail de Jira avant passer à l' interface Jira elle-même Chaque flux de travail dans Jira se compose de deux parties principales : les statuts et les transitions Les statuts indiquent où se situe un élément de travail dans son cycle de vie. Les statuts de base sont à faire en cours et à terminer. Mais nous pouvons les étendre en créant les statuts personnalisés que nous voulons, tels que la révision du code, le statut prêt pour l'assurance qualité, tests d'assurance qualité ou le statut bloqué, etc. Cela dit, quel que soit le statut que nous créons, chaque statut appartient à l'une des trois catégories. Ces catégories doivent être effectuées en cours et terminées. Bien que nous ne puissions pas créer de catégories personnalisées dans Jira, elles sont principalement destinées à l'organisation principale de Jira afin de l'aider à déterminer le type de statut personnalisé que nous créons En gros, tout statut personnalisé que nous créons sera intégré à l'une de ces trois catégories, ce qui déterminera comment Jira sait quand faire certaines choses Par exemple, si un élément est dans la catégorie terminé, Jira sait que le travail est terminé Peu importe si vous appelez le statut terminé ou terminé ou quel que soit le nom que nous lui donnons pour désigner le statut personnalisé, le travail est terminé, car il appartient à la catégorie Jira sait que le travail est terminé, car il appartient à la catégorie terminé Les transitions représentent l'action qui déplace un élément de travail d' un statut à un autre. Techniquement, une transition unique est à sens unique. Si nous voulons passer d'un statut à l'autre, nous avons besoin de deux transitions distinctes Cela étant dit, il existe des moyens de permettre à Jira de transférer les statuts dans n'importe quelle direction, et nous examinerons cela dans ce cours Mais sachez simplement qu' en arrière-plan, si nous déplaçons le travail de « à faire » à en cours », puis de nouveau à « faire », il s'agit techniquement de deux transitions différentes. Un de « à faire » à « en cours », puis un autre « en cours » à «   en cours » pour revenir à « faire ». C'est important car nous pouvons dire à Jira ce que nous voulions faire pour chacune de ces transitions Si nous voulons que l'élément de travail fasse quelque chose de différent lorsqu'il passe de « à faire » à « en cours », puis lorsqu'il passe de «   en cours » à « en cours ». Comme vous pouvez l'imaginer, les choses peuvent devenir complexes assez rapidement. Il est donc important de définir une convention de dénomination solide pour nos statuts et nos transitions Nous saurons donc ce que chacun signifie et ce qu'il fait. Et voici quelques conseils pour commencer. Premièrement, utilisez des noms clairs et cohérents. La révision du code est préférable à l'étape de révision ou même au stade du développement. Cela mène au numéro deux. Évitez les chevauchements de sens. Si nous sommes à la fois en développement et en cours, cela peut être source de confusion. Mais si le processus de développement et la révision du code sont deux statuts distincts, notre équipe saura lequel représente le développement actif par rapport au transfert Et en tant qu'administrateur juré, il se peut que nous revenions à un flux de travail dans des mois ou des années et que nous ne nous souvenions plus à quoi il sert si ces statuts semblent similaires Petit conseil en prime, si ce n'est pas déjà fait, commencez à créer de la documentation sur nos conventions de dénomination. Ainsi, si, pour une raison ou une autre, nous choisissons de créer des statuts sonores similaires, nous pourrons nous y référer à l'avenir pour savoir pourquoi nous avons choisi quelque chose de spécifique Et si votre organisation utilise outil de documentation d' Atlassian appelé Confluence, c'est l'endroit idéal pour stocker toute la documentation relative aux conventions de dénomination Troisièmement, restez simple. N'ajoutez pas un tas de statuts juste pour essayer de trop organiser les choses Ajoutez le strict minimum pour commencer, puis demandez notre équipe dans les semaines et les mois à venir s' il serait utile d'ajouter d'autres éléments au flux de travail, par exemple en ajoutant un ou deux éléments supplémentaires pour voir si cela peut vous aider. Si ce n'est pas le cas, suppression. Si c'est le cas, gardez-le à portée de main. Plus notre flux de travail est important, plus il devient complexe, et nous ne voulons pas que les choses deviennent insoutenables. Maintenant, si vous utilisez Jira depuis un certain temps, vous êtes peut-être habitué à une terminologie plus ancienne qui a légèrement changé avec les dernières mises à jour Dans ce cours, nous allons donc rencontrer quatre types de règles de flux de travail, et les termes de ces règles ont changé. Tout d'abord, nous avons les règles de transition restrictives. Ces conditions étaient auparavant appelées conditions. Ils contrôlent qui peut voir et utiliser une transition. Si un utilisateur ne respecte pas la restriction, il ne peut pas passer d'un statut à l'autre. Ensuite, nous avons les règles de saisie des demandes qui font apparaître un écran pendant une transition demandant à l'utilisateur de remplir des champs spécifiques avant que la transition ne se poursuive, et nous aborderons cela plus loin dans ce cours C'est un peu comme un cousin plus sympathique d'un validateur qui demande des données au lieu de les Et puis nous avons les règles de validation des détails. Ils étaient auparavant appelés validateurs. Ils vérifient si les données requises existent avant d'autoriser cette transition. C'est donc plus strict que de simplement demander des informations. Par exemple, exiger que le champ de version fixe soit défini avant de fermer un élément de travail. Et encore une fois, nous y reviendrons plus loin dans ce cours. Ensuite, nous avons les règles d'exécution des actions. Ces fonctions étaient auparavant appelées fonctions de poste. Ils s'exécutent automatiquement une fois la transition terminée. Ils mettent à jour les champs, attribuent des utilisateurs ou peuvent déclencher des agents d'intelligence artificielle, et nous les examinerons plus loin dans ce cours. Maintenant, il y a aussi quelque chose à garder à l'esprit concernant les autorisations. Un utilisateur a besoin de bien plus que de simples autorisations de flux de travail pour déplacer un élément de travail. Ils doivent également être en mesure de modifier l'élément de travail lui-même. Ainsi, lorsque vous testez des restrictions, assurez-vous d'utiliser un utilisateur disposant au moins des autorisations de modification de base pour ce type de travail. Pour récapituler, flux de travail se composent de statuts et Chaque statut appartient à une catégorie qui détermine son apparence sur le tableau. Les transitions sont des actions à sens unique entre les statuts, et il existe quatre types de règles que nous pouvons appliquer aux transitions Ils peuvent restreindre les personnes autorisées à effectuer cette transition, peuvent demander des informations pendant une transition. Vous pouvez valider les données avant la transition et effectuer des actions après la transition Dans notre prochaine leçon, nous allons passer à Jira afin de convertir un flux de travail par défaut en un flux personnalisé, puis nous allons commencer à créer à partir de là 3. Configurer des états et des transitions personnalisés: Dans cette leçon, nous allons utiliser Jira et commencer à créer nos propres statuts et transitions personnalisés afin de développer notre flux de travail de développement logiciel Passons d'abord à l'éditeur de flux de travail. Maintenant, il y a deux façons d'y arriver. Nous pouvons passer en revue nos paramètres d'espace. Nous pouvons donc entrer dans ces trois petits points, entrer dans les paramètres de l'espace. Et c'est pratique. Si nous travaillons déjà dans notre espace spécifique, nous pouvons accéder au flux de travail utilisé par cet espace. Mais comme c'est la première fois que nous abordons Jira dans ce cours, et que nous travaillons en tant qu'administrateur global de Jira, examinons les paramètres globaux de Jira où nous pouvons voir et gérer tous les flux de travail de l'ensemble de notre instance Nous pouvons donc passer aux paramètres, passer aux éléments de travail. Et puis, sur le côté gauche, si nous en venons à nos flux de travail, cela nous montrera tous les flux de travail que nous avons dans notre instance Jira Nous travaillons maintenant avec un espace appelé développement logiciel, celui-ci ici. Il s'agit donc du flux de travail utilisé dans cet espace. Mettons-nous en trois points. Descendez pour modifier, et cela nous mènera à l'éditeur de flux de travail. Je vais fermer ceci juste pour nous donner un peu plus de place afin que nous puissions voir l'éditeur ici. Maintenant, nous pouvons voir ici les statuts et les transitions par défaut du modèle Scrum C'est le modèle que j'ai utilisé lorsque j'ai créé cet espace. Nous devons avancer et c'est fait. Et puis ici, il faut commencer, non ? Je vais donc maintenir la touche Ctrl enfoncée, utiliser la molette de ma souris pour zoomer juste pour que nous puissions voir les choses un peu plus facilement. Nous avons donc un point de départ. Et ce n'est pas vraiment un statut, mais c'est le début du démarrage d' un nouvel élément de travail, n' est-ce pas ? Ainsi, lorsqu'il démarre, il passe par cette étape de création de transitions, qui indique à Jira, lorsque vous créez un nouvel élément de travail, où il va ? Dans ce cas, et par défaut, il passe à this to do status. Maintenant, si nous voulions changer cela, il nous suffirait de sélectionner cette transition ici , puis de la déplacer vers un autre statut. Disons que nous voulons qu'il soit en cours. Maintenant, si nous devions créer un nouvel élément de travail dans cet espace, il serait en cours dès que nous mettrons à jour ce flux de travail. Pourquoi, bien sûr, de façon réaliste, cela n'a pas beaucoup de sens Laissons cela à faire pour ce statut. Cela soulève un point intéressant car avant de procéder à de nombreuses modifications dans l'éditeur de flux de travail, je vous recommande vivement de prendre le temps d' esquisser exactement ce dont vous avez besoin dans votre flux de travail. Donc, au moment où vous arrivez ici, vous savez déjà ce que vous allez faire ou avez une idée de la façon dont tout va se relier. Maintenant, si vous utilisez Confluence à côté de Jira, vous pouvez utiliser leurs tableaux blancs numériques C'est l'endroit idéal pour le faire en dessinant chaque statut et chaque transition de manière très souple avant de les intégrer ici et en les rendant réellement fonctionnels dans l'éditeur de flux de travail. Bien sûr, vous pouvez toujours changer les choses plus tard, mais ce peu de planification préalable vous donnera un bon point de départ. Cela dit, il est parfois utile de voir d'abord comment les autres équipes travaillent. J'ai donc déjà suivi le processus pour déterminer comment je voulais que se déroule le flux de travail que nous utilisons aujourd'hui Commençons donc par ajouter nos nouveaux statuts avec lesquels travailler, et nous passerons par le processus de création de tous en une seule fois, puis nous organiserons le tout et nous les puis nous organiserons le tout et nous connecterons tous ensemble Je vais donc passer ici au statut de l' annonce en haut, et nous voulons créer certains statuts Donc, entrons ici et soit nous sélectionnons un statut que nous avons déjà créé dans notre instance Jira, soit je vais entrer ici et commencer à taper Non, nous n'avons pas encore ce statut, alors créons-le. La catégorie va être en cours de création. Ensuite, nous pourrions autoriser les transitions depuis le statut Edi ici, mais je vais simplement cliquer sur Ajouter, concentrer sur l'ajout de ces statuts pour commencer, puis nous organiserons tout plus tard Passons donc à la préparation, car l' assurance qualité est notre prochain statut. Créez ça. Encore une fois, la catégorie sera en cours d'élaboration. Au niveau du statut, nous allons intervenir, et il s'agira d'un test d'assurance qualité. Encore une fois, la catégorie sera une forme de ce qui est en cours d'élaboration. Nous allons ajouter notre statut de blocage. Ensuite, nous allons ajouter un autre statut ici, et nous allons créer un statut à ne pas faire. Et ce sera une autre forme de réalisation. Nous aurons donc deux statuts différents dans la catégorie De. Et plutôt que de les faire tous , ce travail est réellement terminé, si nous venons ici et que nous en ajoutons un qui ne fonctionnera pas, si nous ajoutons du travail dans le statut « Ne pas faire », alors nous pouvons revenir plus tard sur les rapports et les filtres et voir ceux pour lesquels nous avons consciemment pris la décision que oui, cela a été fait , ou nous avons pris la décision si nous venons ici et que nous en ajoutons un qui ne fonctionnera pas, si nous ajoutons du travail dans le statut « Ne pas faire », alors nous pouvons revenir plus tard sur les rapports et les filtres et voir ceux pour lesquels nous avons consciemment pris la décision que oui, cela a été fait , ou nous avons pris la décision de ne pas faire ce travail pour quelque raison que ce soit. Ensuite, dans l'élément de travail lui-même, vous ajouteriez la raison pour laquelle vous n'avez pas décidé de faire ce travail. Très bien, nous avons maintenant créé nos statuts. Venons ici et commençons à créer des transitions. Donc, sur les statuts que nous avons déjà, il s'agit de n'importe quelle transition Cela signifie que les éléments de travail dont le statut est terminé peuvent passer de n'importe quel autre statut à ce statut à ce statut. Donc, si c'est en cours, si c'est le cas, s'il s'agit de l'un de ces éléments ici, il peut réellement passer de cet autre statut à l'état terminé. Mais il se peut que nous ne le souhaitions pas toujours. Commençons donc par organiser cela en créant nouvelles transitions entre ces statuts, car pour le moment, ils sont surlignés, ce qui signifie qu'il est impossible que quoi que ce soit passe au statut de révision du code Nous ne pouvons pas travailler dans le cadre de la révision du code s'il n'y a pas de transition vers celui-ci. Je vais donc venir en prendre une, disons, en cours, que nous voulons en cours pour passer à la révision du code. Et donnons un nom à ce statut. C'est toujours une bonne idée de tout nommer. Et c'est là que la planification préalable peut s'avérer très utile, savoir comment vous allez nommer les choses. Cela va donc être soumis pour examen. Cela passe donc du stade en cours à la révision du code, puis à la transition qui est soumise pour révision. Pour les prochaines transitions, nous allons dire : « D'accord, lorsque le travail sera consacré à la révision du code, cela découlera de la révision du code, puis nous ferons en sorte qu'il soit prêt pour l'assurance qualité. Et je dois dire que ce statut ou cette transition seront considérés comme approuvés, n'est-ce pas ? Il a donc été approuvé, puis il passe à la révision du code. La révision du code est approuvée et il est prêt pour l'assurance qualité. Maintenant, un autre flux de travail possible pour cela est que s'il n'est pas approuvé, s'il y a quelque chose à changer, nous pouvons intervenir et dire : OK, révision du code, revenons en cours. Et ce sera la transition qui consistera à demander des modifications. Nous y voilà. Il s'agit donc d'un autre flux de travail potentiel que pourraient avoir nos éléments de travail. Et nous pouvons réorganiser cela si nous voulons simplement que cela ait un peu plus de sens dans la façon dont nous avons organisé tout cela Ensuite, lorsque le travail est prêt pour l' assurance qualité, que se passe-t-il ici ? OK, donc être prête pour l'assurance qualité dans ce flux de travail sera essentiellement le statut à faire pour notre équipe d'assurance qualité, n'est-ce pas ? Une fois le code révisé par les développeurs, ils seront code révisé par les développeurs, prêts pour l'assurance qualité. Et ensuite, tout ce qui se trouve dans le statut «   prêt pour l'assurance qualité », notre responsable de l'assurance qualité, cet utilisateur sera en mesure de savoir : « OK, c'est prêt à fonctionner ». Ensuite, au fur et à mesure qu'ils y travaillent, ils peuvent passer du travail aux tests d'assurance qualité pour montrer que les tests ont réellement commencé à ce sujet. Et pour cela, disons que nous allons simplement appeler cela start QA. Ensuite, cela peut provenir de tests d'assurance qualité, et nous voulons vraiment que cela soit fait pour dire, oui, d'accord, c'est terminé Nous y voilà. Ou, comme nous l'avons fait pour la révision du code, si un changement doit être apporté, nous pouvons passer des tests d'assurance qualité à ceux en cours et dire qu'il nous pouvons passer des tests d'assurance qualité à ceux en cours et dire qu' faut le renvoyer pour qu'il soit corrigé. Nous y voilà. Et puis, pour ces deux autres statuts, il y aura certainement des moments où nous voudrons effectuer une transition globale d' un statut à un autre, et à tout moment, nous voulons être en mesure de dire que nous avons pris la décision de ne pas faire ce travail Donc, pour cela, nous allons ajouter une transition, qui proviendra de n'importe quel statut et ne fera pas l'affaire. Allez-y et créez-le. Et il en va de même pour le blocage, nous allons dire qu' à tout moment, importe quel travail peut être bloqué dans ce flux de travail. Nous y voilà. Nous avons donc créé notre flux de travail ici dans l'éditeur de flux de travail. Notre flux de travail est maintenant prêt à fonctionner. Dans notre prochaine leçon, nous allons commencer par examiner certaines des règles que nous pouvons ajouter à notre flux de travail, en commençant par restreindre les transitions. 4. Restreindre les transitions: Dans cette leçon, nous allons découvrir le premier type de règle de flux de travail limitant les personnes autorisées à exécuter une transition. La règle de restriction de transition était auparavant appelée conditions dans les anciennes versions de Jira, et elle contrôle si une transition est disponible, en fonction de la règle que nous décidons Le cas d'utilisation le plus courant consiste probablement à restreindre une transition en fonction de l'identité de l'utilisateur. Voici donc un scénario courant que nous allons apprendre à configurer dans cette leçon. Nous voulons uniquement que les développeurs puissent soumettre leur travail pour révision du code. Dans notre configuration, Ethan est un développeur, et il fait partie du groupe d'utilisateurs du développeur Maxwell est notre responsable de l'assurance qualité, il ne fait pas partie du groupe des développeurs Nous voulons qu'Ethan puisse soumettre une demande de révision pour passer d'un statut à un autre au statut de révision du code, mais Maxwell ne devrait pas être en mesure de passer du statut en cours à ce statut de révision de code Alors, configurons-le. Ce que nous voulons faire, c'est utiliser cette transition de soumission pour révision que nous avons créée dans la leçon précédente. cadre de cette transition, étant donné qu'il s'agira tout travail issu de la révision du code en cours, il doit passer par cette transition. Passons à nos règles, restreignons la transition, ajoutons une règle de restriction de transition. Ensuite, nous voulons restreindre en fonction de l'identité de l'utilisateur. Limitez donc les personnes autorisées à déplacer un élément de travail. Et nous pouvons choisir soit des utilisateurs spécifiques, soit j'ai trouvé qu'un meilleur flux de travail consiste à utiliser des groupes. De cette façon, nous pouvons ajouter des utilisateurs au groupe, et toutes ces règles seront automatiquement appliquées au lieu que ce soit uniquement des utilisateurs individuels. Je vais donc entrer et sélectionner les groupes, et nous allons sélectionner le groupe des développeurs. Cela signifie donc que seuls les développeurs pourront utiliser cette transition pour passer de la phase en cours à la révision du code. Appuyez sur AD et c'est parti. Cela a été ajouté à nos règles ici, sur le côté droit. Maintenant, pour que cela entre en vigueur, nous devons réellement mettre à jour le flux de travail. Donc, pour le moment, nous sommes essentiellement en mode brouillon. Nous ne l'avons pas réellement mis à jour. Donc, pour que cela soit disponible, nous devons mettre à jour le flux de travail. Maintenant que notre flux de travail est mis à jour, voyons à quoi cela ressemble pour notre équipe. Alors d'abord, je vais me connecter en tant que Maxwell. Ceci est connecté sous le nom de Maxwell Carter. Il est notre responsable de l'assurance qualité, qui ne fait pas partie du groupe de développeurs auquel nous venons d'ajouter cette restriction de transition. Donc, si nous devions aborder l'un de ces éléments de travail en cours, vous constaterez que Maxwell ne pourra même pas passer au statut de révision du code, car la seule façon de le faire est de passer par cette transition de soumission pour révision que nous avons limitée Maintenant, si je devais me connecter en tant qu'Ethan, qui est l'un des développeurs du groupe de développeurs, laissez-moi ouvrir cette fenêtre ici Je suis connecté en tant qu'Ethan ici. Maintenant connecté en tant qu'Ethan. Si nous devions examiner l'un de ces éléments de travail, voir son statut. C'est en cours. Si je le retire, nous pouvons utiliser cette transition de soumission pour révision pour la faire passer au statut de révision du code. Et nous y voilà. Ethan peut désormais modifier l'élément de travail pour qu'il passe au statut de révision du code. Grâce à cette transition, la transition de soumission pour révision permet uniquement aux membres ce groupe de développeurs de passer par cette transition, ce qui est le seul moyen d'accéder à statut de révision de code Même statut, même élément de travail, autorisations utilisateur différentes. Il s'agit d'un moyen puissant d' appliquer l'accès basé sur les rôles dans notre flux de travail sans avoir à nous contenter de nous souvenir des règles. Le système peut l' appliquer pour nous. Certains autres cas courants d'utilisation de la transition restreinte peuvent inclure des éléments tels que n'autoriser cette transition approuvée qu' aux chefs de projet ou aux gestionnaires. Ou peut-être que, puisque nous avons mis en place une équipe d'assurance qualité, seule l' équipe d'assurance qualité peut réellement terminer l'assurance qualité et l' envoyer à Dunn une fois tests d'assurance qualité terminés, ou peut-être même ne peut-elle que démarrer l'assurance qualité Peut-être que nous voulons que l'équipe d'assurance qualité ne puisse démarrer l'assurance qualité qu'une fois qu'elle sera prête pour l'assurance qualité, seule l'équipe equa peut réellement démarrer les tests d'assurance qualité, qui passent par cette transition d'assurance qualité C'est exactement le même processus. Nous intervenons ici pour la transition, pour restreindre la transition, pour ajouter une règle, pour restreindre les personnes autorisées à la déplacer. Cette fois, au lieu du groupe des développeurs, limitons-nous au responsable de l' assurance qualité. Ajoutez ça. Allez-y et mettez à jour ce flux de travail. Nous pouvons maintenant confier ce travail à l'équipe en cours de révision du code et le mettre en état de préparation pour l'assurance qualité, mais seul notre service d'assurance qualité sera en mesure de le prendre en compte dans le cadre des tests. Voyons donc à quoi cela ressemble, encore une fois, lorsque nous sommes connectés en tant que développeur ici, Ethan, alors disons, d'accord, code est en cours de révision, qu'il a été approuvé Cela signifie donc qu'il est prêt pour l'assurance qualité. Ethan peut le remplacer par «   prêt pour l'assurance qualité », mais il ne peut pas ensuite être approuvé et retiré de celui-ci « prêt pour l' assurance qualité », n'est-ce Sauf que nous l'avons réglé, je crois que c'est à cause de cette transition ici. Ouaip. Donc, même si nous avons cette transition ici, nous avons cette configuration pour n'importe quel statut. Donc, si vous vouliez supprimer cela, nous pourrions simplement entrer, appuyer sur Supprimer, mettre à jour ce flux de travail. Maintenant, le seul moyen d'y parvenir est de passer par l'assurance qualité. Ainsi, si nous revenons à nous connecter en tant que développeur ici, nous ne pourrons plus passer au statut De. La seule façon de le faire est de passer par l'équipe d'assurance qualité, ce qui signifie que nous sommes connectés, que nous allons redevenir connectés en tant que Maxwell ici, en tant que Maxwell, c'est prêt pour l'assurance qualité, et il peut passer aux tests d'assurance qualité Oui, d'accord, c'est prêt pour les tests d'assurance qualité. Une fois qu'il aura terminé, il pourra effectuer les tests d'UA, et cet élément de travail sera entièrement terminé tout au long de ce flux de travail. Pour récapituler ce que nous avons appris dans cette leçon, nous avons appris comment restreindre une transition certains utilisateurs en fonction du groupe dont ils font partie Et il existe de nombreuses autres façons d' ajouter de la complexité à cela si nous le voulions. Nous pouvons même ajouter une règle enfant à cela si nous voulions, par exemple, restreindre une transition entre une personne faisant partie du groupe des développeurs et une personne faisant partie d'un groupe d' assurance qualité, des choses comme ça. présent, je vous encourage à créer un flux de travail de test et à commencer à jouer avec les règles de transition restrictives dans les flux de travail de votre côté pour voir comment vous pouvez les utiliser à votre avantage. Et lorsque vous serez prêt, je vous verrai dans la prochaine leçon, où nous découvrirons un autre type de règle pour nos transitions, à savoir demandes de saisie. On se voit là-bas. 5. Ajouter des règles d'entrée de requête: Dans la dernière leçon, nous avons examiné la règle de transition restrictive. Dans cette leçon, nous allons examiner le deuxième type de saisie de demandes de règles de flux de travail. saisie des demandes fait apparaître un écran pendant une transition qui demande à l'utilisateur de remplir des champs spécifiques avant que la transition ne se Au lieu de simplement déplacer l'élément de travail d' une taille à l'autre, Jira fait une pause et dit : « Hé, avant d'aller plus loin, j'ai besoin que tu remplisses quelques informations. Et cela est utile lorsque nous voulons collecter des données au moment précis où une transition entre les statuts se produit Voici donc notre scénario pour cette leçon. Lorsque quelqu'un fait passer un élément de travail du d'assurance qualité effectué du statut de test d'assurance qualité à terminé, cela utilise la transition complète de l' assurance qualité. Nous voulons nous assurer que le champ des versions corrigées est rempli afin de savoir quelle version de notre code contient ce correctif. Nous pouvons simplement espérer que les utilisateurs n'oublient pas de le définir, mais un meilleur flux de travail consiste à utiliser la saisie de la demande pour les inviter immédiatement à remplir ce champ lorsqu'ils ont terminé ce travail. Revenons donc dans l' éditeur de flux de travail et configurons cette configuration. Après les tests d'assurance qualité, pour y parvenir, comme vous pouvez vous y attendre, vous devez suivre cette transition complète en matière d'assurance qualité. Passons donc ici à la transition complète de l'assurance qualité , puis passons à la saisie des demandes, ajoutons une règle de saisie des demandes. Nous devons maintenant indiquer à Jira quel écran afficher. Il n'y a donc qu'une seule chose ici. Nous pouvons afficher un écran, sélectionnez-le. Quel écran voulons-nous afficher ? Maintenant, nous pouvons tirer parti de n'importe quel autre écran. Vous pouvez voir qu'il y a de nombreux écrans différents que j'ai installés mon côté dans mon installation Jira Mais si aucun écran n'a déjà été créé, nous souhaiterons peut-être entrer et créer un nouvel écran. Je vais donc le faire, et cela ouvrira un nouvel onglet. Nous y voilà. Passons maintenant à l'ajout d'un écran. Et donne un nom. Nommer est toujours une bonne chose. Ce sera donc pour notre transition complète en matière d'assurance qualité. Demandez des entrées pour les versions fixes. Nous y voilà. Donnez-lui une description si nous le voulons. Mais je vais cliquer sur Ajouter. Nous avons maintenant créé notre écran. Nous pouvons fermer cet onglet qui nous ramènera à notre éditeur de flux de travail. Et trouvons ça. C'était donc quelque chose avec des versions fixes. Nous y voilà. Trouvez cet écran, ajoutez-le à notre règle. Et maintenant, chaque fois que quelque chose est prêt à être fait après un test d'assurance qualité, cet écran s'affichera, bien entendu, dès que nous mettrons à jour notre flux de travail. Alors faisons-le. Maintenant que notre flux de travail est mis à jour, allons-y et voyons à quoi cela ressemble de l'autre côté. Nous devons donc nous connecter en tant que Maxwell. Qui est notre responsable de l'assurance qualité, n'est-ce pas ? Parce que n'oubliez pas que nous avons mis en place cette restriction là où Maxwell est le seul à pouvoir le faire Ainsi, dès que les tests d'assurance qualité sont terminés, ils sont prêts à être terminés. Maintenant, lorsque nous l'avons défini sur Dunn, cette transition va apparaître Mais attendez, où est notre terrain ? En fait, j'ai oublié une étape. Revenons et annulons tout ça. Cela ne va donc pas déplacer cette transition. C'est quelque chose qu'il est important de garder à l'esprit. Si vous annulez cette période, cette transition ne sera pas terminée. Et revenons à notre écran ici. C'est un excellent moyen de montrer comment nous pouvons ajuster cela après coup. Trouvons donc notre écran. Ce sera l'écran de la version fixe ici. Nous avons oublié d'ajouter le champ que nous voulons ajouter sur cet écran. Donc, pour le moment, rien n'est configuré pour cet écran. C'est pourquoi il n'a rien montré. Alors entrons et ajoutons des versions fixes. Nous y voilà. Il n'y a aucune sauvegarde ou quoi que ce soit de ce genre. C'est déjà enregistré. Et comme nous l' avons déjà configuré dans notre flux de travail, revenons dans notre éditeur de flux revenons dans notre éditeur de flux de travail ici pour montrer qu' il est déjà configuré. C'était notre flux de travail de développement logiciel, celui-ci ici. Il devrait donc déjà être configuré qu'une fois l'assurance qualité terminée, oui. OK, cet écran apparaît, et cet écran contient maintenant ce champ. Donc, si nous revenons à nous connecter en tant que Maxwell, prenons cet élément de travail et que nous le terminons, c'est fait Et maintenant, nous avons ce champ de version fixe. Bien sûr, il semble que je n'ai aucune version dans cet espace. Passons donc à nos publications. Ce sont les différentes versions. Oui, nous n'avons aucune version ici pour le moment. Et il semble que Maxwell n'ait pas les autorisations nécessaires pour en créer un. Ce n'est pas grave. Revenons en tant qu' administrateur et créons une nouvelle version ici. Je vais donc retourner dans l'espace de développement logiciel, aborder les versions, et maintenant nous pouvons créer une version. Alors disons, OK, il s'agit de la version 1.0 de notre logiciel. Sauvegardez ça. Cela a été créé. Et maintenant, avec Maxwell, si nous actualisons la page, il verra cette version apparaître. Nous y voilà. Et puis revenons à l'élément de travail, une fois que cela aura été fait dans le cadre des tests d'assurance qualité, nous pourrons le terminer. Il apparaîtra sur notre écran, et il verra cette version fixe à laquelle il pourra l'associer, ajouter tout type de commentaire qu'il souhaite, la mettre à jour. Et maintenant, cet élément de travail va passer au statut De. Une sorte de récapitulation. Dans cette leçon, nous avons appris que la règle de saisie des demandes s'affiche sur un écran lors d'une transition Nous apprenons où aller pour ajouter des champs à notre écran. Nous avons même cherché où installer une nouvelle version dans notre espace, afin qu'elle apparaisse dans le champ des versions fixes. Bien entendu, cet écran peut inclure les champs que nous voulons. Et nous pouvons même passer au niveau supérieur en contrôlant les champs obligatoires sur nos écrans l'aide d'un schéma de configuration des champs. En fait, en parlant d' exigences, passons à notre vidéo suivante où nous verrons comment nous pouvons configurer exactement ce scénario avec la règle de validation des détails. Et nous apprendrons tout cela dans notre prochaine leçon. 6. Valider les transitions: Dans la dernière leçon, nous avons utilisé saisie de requêtes pour inviter les utilisateurs à saisir des données lors d'une transition. Dans cette leçon, nous allons apprendre à utiliser la règle de validation des détails. La règle des détails de validation était autrefois appelée validateurs dans les anciennes versions de Jira, et elle vérifie que données requises existent avant autoriser cette transition Mais contrairement à la saisie des demandes, qui invite l'utilisateur à renseigner les données manquantes, les validateurs adoptent une position plus stricte Si la validation échoue, la transition est complètement bloquée et l'utilisateur reçoit un message d'erreur. Pensez-y de cette façon. saisie de la demande arrête l'utilisateur et lui dit : « Hé, remplissez-le avant de continuer ». détails de validation indiquent : « Non, vous ne pouvez pas continuer tant que vous n'avez pas terminé ces étapes ». Voici donc notre scénario pour cette leçon. Nous allons nous appuyer sur ce que nous avons fait dans la dernière leçon où nous avons ajouté un écran permettant à un utilisateur de remplir le champ des versions fixes, n'est-ce pas ? Mais au lieu de simplement le pendant la transition, comme nous l'avons fait pour la saisie de la demande puis de nous attendre à ce qu'elle soit remplie, nous allons bloquer cette transition si elle n'est pas réellement remplie Ajoutons donc un validateur à la fin de la transition qui vérifie que le champ est rempli avant de l' autoriser à continuer Donc, en passant à la modification du flux de travail ici, sous la saisie de la demande, nous avons les détails de validation Et dans ce cas, nous voulons nous assurer que le champ des versions fixes est rempli. Donc, lorsque nous entrons pour valider la règle des détails, ajoutez-la. Il y en a un tas que nous pouvons faire ici. Dans ce cas, nous voulons valider un champ car comme nous l'avons vu dans la dernière vidéo, les versions fixes sont un champ. Nous voulons donc valider ce champ, sélectionnez-le maintenant, nous devons indiquer à Jira comment nous voulons valider le champ Voulons-nous nous assurer qu'il possède une seule valeur au lieu de plusieurs valeurs ? Ou voulons-nous nous assurer qu' elle correspond à une expression ? Peut-être que le résumé de l'élément de travail commence par les mêmes mots et quelle que soit cette expression. Dans ce cas, cependant, nous voulons nous assurer que le champ n'est pas vide du tout. Il contient des données. Maintenant, nous devons dire à Jira : « D'accord, quand tu veux valider qu' un champ n'est pas vide, quel champ Eh bien, dans ce cas, nous voulons que ce soit le champ des versions fixes, celui que nous avons ajouté auparavant, n'est-ce pas ? Donc celui-ci ici. Et nous pouvons soit laisser le message d'erreur vide, ce qui va ajouter un message par défaut, soit ajouter notre message d'erreur personnalisé en cas d'échec. Disons que vous devez d'abord ajouter une version fixe. Nous y voilà. Allez-y, ajoutez ceci. Maintenant, voici un point important parce que l'ordre de ces règles est important, n'est-ce pas ? Ils courent donc en fait de haut en bas. Ainsi, comme nous avons saisi la demande avant les détails de validation, l'écran qui permettra à l'utilisateur d' ajouter le champ des versions fixes en utilisant l'écran que nous avons configuré dans la dernière vidéo s'affichera. S'ils le font, cette validation validera s' il y a ou non des données dans ce champ. Ils ont donc la possibilité d'ajouter des données à ce champ avant que celui-ci n' essaie de terminer cette transition. S'ils ne le font pas, le message d'erreur apparaîtra et indiquera qu'il doit être rempli. Ce champ ne peut pas être vide. Mettons donc à jour notre flux de travail et voyons cela en action. Je vais mettre à jour le flux de travail, il est donc désormais disponible. Et puis passons à la connexion en tant que Maxwell. N'oubliez pas qu'il est notre responsable de l'assurance qualité et que nous avons limité les transitions. Nous voulons donc nous assurer que cela est transmis au QA, mais en fait, nous devons d' abord nous connecter en tant qu'Ethan , car cela doit passer par une révision du code N'oubliez pas que c'est le processus que nous avons suivi depuis le début, il doit passer à la révision du code. Et puis, à partir de la révision du code, une fois qu'il est approuvé par le biais de la révision du code, il est prêt pour A. D'accord ? Maintenant que c'est en QA, nous pouvons nous connecter en tant que Maxwell dans notre équipe d'assurance qualité. Il est prêt pour l'assurance qualité. OK. Et c'est en cours de test d'assurance qualité. Maintenant que c'est fait par le biais de tests d'assurance qualité, OK, c'est terminé, c'est fait. Nous pouvons venir ici et ajouter à notre version fixe. Ou si nous venons ici et essayons simplement de le mettre à jour, cela va dire non, il faut l'ajouter. Nous devons d'abord ajouter une version corrigée. C'est le message d'erreur que nous lui avons demandé de nous envoyer dans ce validateur C'est notre validateur qui fonctionne ici. Mais dès que nous arriverons ici et que nous ajouterons des données à ce champ, observez ce qui se passe. Je pourrai le mettre à jour car ces données ont été validées sur le back-end. Encore une fois, dans le flux de travail, c'est cette règle de validation des détails qui arrive ici et indique qu'elle coche ce champ. S'il n'est pas vide, en gros, il contient des données, il lui permet de passer, et quand il ne l'a pas fait, il nous a donné ce message d'erreur ici même. Donc, pour récapituler, la règle des détails de validation vérifie que validation que nous avons configurée est remplie pour que la transition soit terminée Lorsque la validation échoue, la transition est bloquée et l'utilisateur voit un message d'erreur. Bien entendu, nous pouvons utiliser n'importe quel champ au-delà du champ des versions fixes. Et comme nous l'avons vu lors de la mise en place de la règle, nous pouvons faire bien plus que valider les champs eux-mêmes Mais j'espère que les choses commencent à changer quant à la manière dont vous pouvez l'utiliser dans vos propres flux de travail. Je vous encourage donc à prendre un peu de temps entre les leçons, à les essayer de votre côté et à commencer à jouer avec certaines des différentes règles pour voir comment elles peuvent aider votre organisation. Nous avons un autre type de règle à examiner. Dans notre prochaine leçon, nous allons donc apprendre comment nous pouvons poursuivre sur cette base en effectuant des actions lors de nos transitions de flux de travail. On se voit là-bas. 7. Réaliser des actions: Dans cette leçon, nous allons découvrir le quatrième type de règle de flux de travail exécutant des actions. Maintenant, celle-ci est un peu différente de toutes les autres règles que nous avons examinées jusqu'à présent car elles apparaissent à la toute fin, une fois toutes les autres règles ont été remplies avec succès, et elles ne valident rien vraiment Si vous avez utilisé d'anciennes versions de Jira, les appelait auparavant des fonctions de publication Ils sont donc différents parce qu'ils ne décident pas vraiment si la transition peut avoir lieu ou non. C'est l'équipe de nettoyage qui intervient une fois que tout a déjà été validé Ils font des choses comme mettre à jour les champs et attribuer des utilisateurs, des choses comme ça Voici donc notre scénario pour cette leçon. Une fois que notre élément de travail passé avec succès au statut «   prêt pour l'assurance qualité », attribuons-le automatiquement à notre responsable de l'assurance qualité, Maxwell De cette façon, il sera informé du travail qui lui est assigné, et il sait qu'il est prêt à être testé. Passons donc à Jira et configurons-le. Ce que nous voulons faire, c'est qu' une fois passé de la révision du code à la préparation pour l'assurance qualité, nous devons l'appliquer à cette transition approuvée ici même. Donc, sous Transition approuvée, sélectionnez-la, faites défiler l'écran vers le bas, effectuez l'action. Nous allons exécuter la règle d'action. Et nous pouvons le faire de différentes manières. Nous pourrions entrer et mettre à jour un champ d'élément de travail, car le cessionnaire est un champ que nous pouvons Mais c'est une chose tellement courante qu' Alasian l' a fait apparaître Nous pouvons donc attribuer un élément de travail sans avoir à parcourir les différents champs. Sélectionnons-le donc. Maintenant, nous devons dire à Jira à qui nous voulons l'attribuer, ou bien nous pouvons supprimer toute personne assignée actuellement Si nous voulions le faire, nous pourrions le supprimer ici même. S'il a déjà été attribué à quelqu'un, nous pouvons simplement le supprimer à ce stade de la transition Pour notre scénario d'aujourd'hui, entrons ici et choisissons notre responsable de l'assurance qualité. C'est Maxwell. Ajoutez ça. OK, donc une fois cette transition exécutée, l'action à la fin consiste à attribuer l'élément de travail à Maxwell Carter Mettons donc à jour notre flux de travail pour voir cela en action. C'est bon. Alors, connectons-nous en tant que développeur, Ethan, n'est-ce pas ? Prenons donc l'un de ces éléments de travail ici. Disons juste celui-ci ici. Disons, d'accord, de «   à faire » à « en cours ». Ensuite, une fois en cours, il est prêt pour la révision du code. Une fois le code révisé, il est approuvé et envoyé au service d'assurance qualité. Regardez ce qui arrive au cessionnaire lorsqu'il est approuvé et envoyé au service d'assurance qualité. Allons-y. Il a été attribué à Maxwell Carter. Et maintenant Maxwell Carter peut faire le reste du chemin, car, encore une fois, connecté sous le nom d'Ethan, il ne peut pas passer le contrôle qualité Il va aussi loin qu'il le peut. Maintenant, c'est à Maxwell Carter de décider, et c'est à lui qu'on l'assigne. Venir ici et commencer les tests d'assurance qualité et exécuter dans le reste du flux de travail que nous avons déjà configuré. Maintenant, une chose à savoir, tout comme le reste de nos règles, les actions se déroulent de haut en bas. Donc, si nous avons une autre action ici, si nous devions intervenir et dire que nous voulons également mettre à jour l'un des champs, nous pourrions sélectionner l'un de ces champs. Disons que je vais ajouter quelque chose comme ça dans la description. Si nous voulons mettre à jour ce champ, la commande est importante, n'est-ce pas ? Donc, si je devais le prendre et le faire glisser vers le haut, cela va maintenant avoir lieu avant que cela ne soit attribué. Maintenant, dans ce cas, et dans ce petit scénario que j'ai mis en place, la description est mise à jour avant qu' elle ne soit attribuée, cela ne changera rien vraiment. Mais il est important de le garder à l'esprit car si vous commencez à mettre à jour des champs et que vous exécutez cette séquence et que vous exécutez cette séquence de différentes actions, cet ordre est important. Vous pouvez donc cliquer et faire glisser pour réattribuer ou mettre à jour cet ordre dans la pile, en gros, n'est-ce pas ? Tout se déroule donc séquentiellement de haut en bas. Et à tout moment, vous pouvez venir ici et supprimer ces règles si vous le souhaitez afin supprimer toutes les actions que vous ne souhaitez pas y inclure. Pour récapituler, dans cette leçon, nous avons appris comment ajouter des actions à la fin de la transition de notre flux Parmi les cas d'utilisation classiques et les plus courants citons l' attribution automatique que nous avons examinée ici, mais également des actions telles que la définition des valeurs des champs, l' effacement complet des champs, la copie complète des valeurs des champs ou le déclenchement d'un agent IA ou d'un webhook En parlant d'agents d'intelligence artificielle, passons à notre prochaine leçon où nous allons prendre quelques instants pour voir comment nous pouvons les utiliser nos transitions. On s'y voit ? 8. Déclencher des agents d'IA: Dans la dernière leçon, nous avons examiné la règle qui exécute des actions une fois la transition terminée. Dans cette leçon, nous allons poursuivre sur cette lancée en étudiant comment déclencher des agents d'intelligence artificielle. À présent, le déclenchement d'un agent d'intelligence artificielle n'est pas une règle, au même titre que les autres règles que nous avons examinées jusqu'à présent à la racine de ces règles. Au lieu de cela, il est niché sous les actions d'exécution. C'est là que nous sommes allés pour attribuer automatiquement un élément de travail après sa transition, sauf qu' au lieu d' attribuer automatiquement un élément de travail, nous allons cette fois demander à un agent d' IA d'examiner attribuer automatiquement un élément de travail après sa transition, sauf qu'au lieu d' attribuer automatiquement un élément de travail, nous allons cette fois demander à un agent d' IA d'examiner l'élément de travail et de faire quelque chose en fonction de l' invite que nous lui donnons Je suis sûr qu'il n'est pas surprenant que lorsque nous déclenchons l'IA, celle-ci comporte certaines réserves en fonction de la version de Jira que vous Rovo doit être activé dans votre instance Jira pour que cela fonctionne Rovo est la plateforme d'IA d'Atlassian qui alimente l' infrastructure des agents, les agents, les crédits, la connexion aux flux de travail Jira, etc. La bonne nouvelle, c'est que Rovo est automatiquement inclus dans les forfaits payants Jira Cloud, standard premium et Enterprise Il n'y a donc pas de licence séparée à acheter. Maintenant, dans mon cas, j'utilise une licence standard de Jira Cloud sans rien de plus Voici donc notre norme pour laquelle nous utiliserons l'IA dans cette leçon. Lorsqu'une personne soumet un travail pour révision de code, nous voulons que l'agent d'intelligence artificielle automatiquement effectue automatiquement une analyse initiale de l'élément de travail pour nous, suggère les modifications qui pourraient devoir être apportées à cet élément de travail afin que chaque fois que quelqu'un commence à réviser le code, il ait une longueur d'avance. Passons donc à Jira et commençons par passer à la transition où nous voulons que cette action se produise réellement C'est cette transition ici, soumettez-la pour révision, car lorsque travail passe de la phase en cours à la révision du code, il doit passer par cette transition de soumission pour révision. Donc, dans le cadre de la transition ici sur le côté droit, comme nous l'avons fait auparavant, ajoutons une règle d'exécution d'actions. Et cette fois, nous allons ajouter une action d'agent déclencheur. Nous devons maintenant indiquer à Jira quel agent nous voulons utiliser. Maintenant, ce sont les agents préinstallés fournis avec Rovo Nous avons un agent de codage, un agent de livraison ou un agent de triage, mais certains agents ne sont disponibles que pour les versions Premium ou Enterprise C'est là que le niveau de votre plan peut vraiment faire la différence. Vous pouvez également installer des agents supplémentaires ou même créer votre propre agent personnalisé si vous le souhaitez. Mais pour notre cas d'utilisation actuel, nous voulons utiliser l'agent de triage Son travail consiste à lire l' élément de travail, puis à le trier, déterminer quelle est la plus haute priorité et ce qui nécessite une attention particulière en premier Maintenant, il possède un ensemble de commandes par défaut. Nous pouvons simplement l'ajouter si nous le voulons, mais nous pouvons le personnaliser en ajoutant notre propre invite. Voici donc un message qui m'invite à analyser l'élément de travail pour m'assurer qu'il est prêt à réviser le code, puisqu'il s'agit de passer à la révision du code, à suggérer une priorité en fonction de la description, signaler tout élément de travail connexe ou dupliqué, détecter et à noter si la description est suffisamment détaillée pour qu'un réviseur puisse commencer son travail Ensuite, cela nous donnera un commentaire sur l'élément de travail avec ses conclusions afin d'aider notre équipe à prendre une longueur d'avance. Allons-y et ajoutons ceci. Allons-y. Nous devons maintenant mettre à jour notre flux de travail, puis accéder à Jira, nous connecter en tant que développeur, tant qu'Ethan Choisissons donc l'un de ces éléments de travail. En fait, je vais prendre cette colonne de statut, déplacer ici pour qu' elle soit un peu plus facile à voir. Quel est le travail réel à côté du statut. Nous n'allons donc pas retirer l'une de ces solutions avec lesquelles nous avons déjà travaillé dans ce tribunal qui l'a déjà fait. Disons, d'accord, disons que cela génère des entrées d'API. Disons que nous voulons commencer à travailler là-dessus. C'est en cours. Ethan y travaille Et maintenant, d'accord, c'est prêt à être révisé. Avant de le faire, je voudrais l'ouvrir afin que nous puissions voir que sur cet élément de travail, il n'y a rien dans l'élément de travail lui-même. C'est à peu près juste un résumé. Vous pouvez voir qu'il n'y a aucune description. Il n'y a aucun commentaire, quoi que ce soit de ce genre. Mais si je devais le prendre et le soumettre pour examen, regardez ce qui se passera. Immédiatement, il va commencer à déclencher cet agent, non ? Les agents vont commencer à suivre le processus. Il va passer par cette invite que nous avons ajoutée. Ensuite, nous lui donnons juste un moment pour suivre le processus. Et bien sûr, nous le regardons réellement faire cela. Normalement, lorsque vous effectuez une transition, cela se produit simplement sur le back-end, nous ne sommes pas vraiment en train de le regarder se produire, et c'est parti. Voici ce qu'il a proposé et recommandé. Il est écrit : Voulons-nous lier cet autre élément de travail ? Il a trouvé un objet de travail similaire. Celui-ci parce qu'il parle des points de terminaison de l'API ? Hum. Cela peut en fait être lié à cet élément de travail, nous pouvons donc vouloir le lier ici dans Jira Nous voudrions peut-être changer cela plutôt qu'une idée pour le moment. C'est une idée, un type de travail ici. Et les agents disent : Vous voudrez peut-être changer cela en tâche parce qu'il semble que nous travaillons réellement sur cette tâche, n'est-ce pas ? Le contenu décrit une tâche plutôt qu' une idée de haut niveau. Et en ce moment, il est écrit : « Oh, en fait, Ethan, nous sommes connectés en tant qu'Ethan ». C'est lui qui fait ça. Nous voudrions peut-être remplacer le cessionnaire par Dan par Ethan, puisque c'est lui qui fait le travail là-dessus Et maintenant, nous pouvons entrer et dire : voulons-nous vraiment l'accepter ? Voulons-nous affiner, ce qui ouvrira une fenêtre de discussion sur Rovo où nous pourrons parler à Rovo et peut-être affiner certaines de ces suggestions Nous pouvons également l'associer à d'autres rôles que nous avons examinés en l' attribuant automatiquement à un membre de notre équipe avant qu'il ne soit attribué à cet agent de triage, puis en plaçant l'agent IA en dessous pendant notre transition et en ajoutant quelque chose dans notre invite pour vérifier ou non à puis en plaçant l'agent IA en dessous pendant notre transition et en ajoutant quelque chose dans notre invite pour vérifier si le travail suggéré correspond l'autre qu'ils leur ont déjà attribué dans l'espace. Vous pouvez commencer à voir à quel point cela peut être puissant. Mais gardez toujours à l'esprit que cet agent fait de telles recommandations. Il ne va pas apporter de modifications automatiques. Un humain doit encore entrer et vérifier s'il accepte ou non tous ces changements. Non, il convient de mentionner que dans notre espace de démonstration, nous n'avons qu'une poignée d'éléments de travail. n'y avait pas vraiment de description ou quoi que ce soit d' autre que l' agent de triage examinerait pour ajouter un commentaire ou quoi que ce soit d'autre à notre élément de travail, car cet élément de travail ne contient pas vraiment grand-chose Normalement, lorsque vous travaillez sur quelque chose, vous devriez avoir une description beaucoup plus de ce qu'est réellement ce travail. Mais nous pouvons accepter ces modifications, puis l'agent se chargera de les mettre à jour. Et nous pouvons voir qu'il a été attribué, qu'il a été lié. Il semble qu'il n'ait pas pu mettre à jour une chose à cause d'un problème. Vous pouvez soit suivre ce processus. Il semble que la seule chose qu'il n'ait pas pu faire était de changer le type de travail, ce qui n'est pas grave. Nous pouvons venir ici et le mettre à jour très rapidement ici. Ensuite, nous pourrions soit répondre et discuter pour ouvrir cette fenêtre de discussion avec IA afin d'essayer de résoudre ce problème soit simplement la fermer pour la fermer. Vous pouvez donc voir comment cela nous aide très rapidement à mieux nous organiser et à mieux trier notre travail La dernière chose que je souhaite souligner avant de terminer cette leçon est que même si nous utilisons l'un des agents préinstallés, l'agent de triage fourni avec Rovo, agent de triage fourni avec Rovo, l'écosystème Jira va bien au-delà Si nous revenons, nous pourrions même en ajouter un autre si nous le voulions. Vous pouvez donc voir, encore une fois, que l'ordre d'empilement compte, celui-ci passerait en dessous de celui que nous avons déjà ajouté Et si nous voulions ajouter un agent différent, ou si nous venons ici et examinons tous les différents agents que nous avons, vous pouvez voir qu'il y a une tonne d'agents différents. Certains d'entre eux sont basés sur la licence. Il n'est pas disponible pour ma licence actuelle. Mais vous pouvez commencer à voir une tonne d'agents différents provenant de nombreux fournisseurs différents, n'est-ce pas ? Beaucoup d'entre eux sont donc conçus par Atlassian pour des tâches spécifiques Mais il y en a peut-être qui proviennent de GitHub ou d'un agent cloud pour Jira Nous pouvons l'intégrer directement dans Jira très, très rapidement. Et bien sûr, si aucune des options prédéfinies ne répond à nos besoins, nous pouvons intervenir Nous pouvons créer notre propre agent au sein du studio Rovo pour vraiment faire ce que nous voulons Pour récapituler, la règle d'action de l' agent déclencheur nous permet exécuter automatiquement un agent d'intelligence artificielle lorsqu'un élément de travail passe d'un statut à un autre Dans cette leçon, nous avons appris comment configurer cela à l'aide l'agent de triage préinstallé pour analyser les éléments de travail , puis suggérer des modifications Mais encore une fois, comme nous l'avons vu, il n'apporte pas réellement ces modifications tant que nous ne les avons pas approuvées, puis il les appliquera et les mettra en œuvre. Une dernière chose à garder à l'esprit, selon l' agent d'IA que nous utilisons, ils peuvent consommer des crédits Rovo à chaque fois qu'ils s'exécutent Désormais, chaque planteur Jira Cloud est assorti d' une allocation de crédit mensuelle par C'est donc toujours une bonne idée de vérifier l' allocation de crédit de votre plan lorsque vous testez des agents d'intelligence artificielle, et de réfléchir aux transitions auxquelles nous les associons afin de ne pas brûler les crédits de façon inattendue. Dans notre prochaine leçon, nous allons prendre du recul par rapport à l'éditeur de flux de travail et examiner la situation dans son ensemble, en créant un deuxième flux de travail et en liant le tout créant un deuxième flux de travail et en liant le tout dans un schéma de flux de travail. On se voit là-bas. 9. et: Dans cette leçon, nous allons apprendre comment utiliser schémas de flux de travail pour relier plusieurs flux de travail. Cela signifie également que nous aurons besoin d'un autre flux de travail. Nous allons donc également apprendre à créer un nouveau flux de travail. Mais commençons par bien comprendre ce qu'est un schéma de flux de travail. En gros, un schéma de flux de travail est une carte qui indique Jira quel flux de travail est utilisé par quel type de travail dans un espace Par exemple, un schéma de flux de travail peut indiquer à Jira d'utiliser le flux de travail de développement logiciel que nous avons utilisé tout au long ce cours pour les idées et les tâches de notre espace Mais peut-être souhaitons-nous que Jira utilise un flux de travail complètement différent pour les bogues de notre espace de développement logiciel Pour que cela fonctionne, nous aurons besoin d' un autre flux de travail que celui que nous avons utilisé jusqu'à présent. Commençons donc par créer un flux de travail simple pour nos livres. Je vais terminer l'éditeur de flux de travail que nous avons utilisé. Et dans notre flux de travail dans le domaine administratif, entrons dans le vif du sujet. Cela se trouve en fait dans les paramètres d'espace. Je vais donc aborder nos paramètres administratifs globaux de Jira, puis les flux de Ensuite, ajoutons un flux de travail. Nous allons créer un nouveau flux de travail. Donne-lui un nom. Ce sera donc notre flux de travail sur les bogues. Pour le type de bogue, créez-le. C'est bon. Cela a donc été créé. Il s'agit simplement d'un flux de travail très simple. Allons-y, et nous allons le faire rapidement car nous avons déjà vu comment ajouter des statuts Mais je vais ajouter les mêmes statuts par défaut que nous avions auparavant Donc, au lieu d'en créer de nouveaux, nous allons simplement en ajouter de très simples à réaliser en cours, en réutilisant des statuts que nous avons déjà utilisés et que nous avons déjà utilisés Allons-y. Et puis, au lieu d'être ouvert lorsque de nouvelles œuvres sont créées, partons du principe, et nous pouvons supprimer le statut ouvert. OK. Donc, en gros, nous avons créé très rapidement un nouveau flux de travail qui est exactement le même que celui que nous avons créé lorsque nous avons commencé ce cours dans le domaine du développement logiciel. N'oubliez pas qu'il avait juste ces trois statuts différents. Et bien entendu, nous pourrions ajouter d'autres statuts, transitions et règles, comme nous l'avons fait avec le flux de travail de développement logiciel dans nos leçons précédentes Mais pour le moment, cela nous donne ce dont nous avons besoin pour démontrer comment un schéma de flux de travail peut gérer plusieurs flux de travail. Mettons donc à jour notre flux de travail ici. Nous devons maintenant lier cela à notre espace de développement logiciel avec un schéma de flux de travail, car vous pouvez voir à l'heure actuelle s'agit d'un flux de travail inactif, ce qui signifie qu'il n'est utilisé nulle part. Revenons donc à nos paramètres ici et à nos schémas de flux de travail. Désormais, par défaut, tout comme Jira a créé un flux de travail pour notre espace lorsque nous l'avons créé, avons également obtenu un schéma de flux de travail Les espaces ont toujours besoin d'un schéma indiquant les flux de travail utilisés. C'est juste que par défaut, il n'y a qu'un seul flux de travail dans chaque schéma. Laissez-moi vous montrer ce que je veux dire. Nous travaillons sur le projet de développement du logiciel. C'est donc le schéma qui est utilisé dans ce projet. Si nous venons ici et modifions cela, c'est ainsi que la plupart des schémas sont configurés par défaut dans un Jira En gros, si vous vous contentez de mentionner chaque type de travail, souvenez-vous du type de travail qui était auparavant appelé type de problème, sorte que vous verrez peut-être encore cette terminologie quelque part dans la zone administrative. Chaque type de travail de ce projet utilise donc le flux de travail que nous avons créé tout au long de ce cours, développement logiciel flux de travail de développement logiciel avec lequel nous avons travaillé. Si nous voulions changer cela et dire : « Vous savez quoi ? Pour les bogues, nous voulons utiliser un flux de travail différent, nous pouvons venir ici, ajouter un flux de travail existant, et c'est pourquoi nous avons d'abord voulu créer le nouveau flux de travail, car il recherche un flux de travail existant. Ajoutons ce flux de travail BG. Ensuite, pour le type de problème BG ou le type de travail, comme on les appelle maintenant. Maintenant, chaque fois qu'un bogue est créé dans l'espace utilisant ce schéma de flux de travail, il utilisera le flux de travail BG, n'est-ce pas ? Allons-y, publions ceci et voyons-le en action. Maintenant, il se peut que nous rencontrions un petit problème qui consiste à associer n'importe quoi, un petit problème qui consiste à associer n'importe quoi, à passer en revue, à vérifier et à s'assurer que tous les statuts sont bons Je rencontre un problème nous avons peut-être supprimé un statut dans le flux de travail, mais certains éléments de travail étaient dans ce statut. Supposons que nous supprimions des éléments en cours pour une raison ou une autre et que des éléments de travail étaient en cours, que des éléments de travail étaient en cours, message « Hé, que voulez-vous en faire » ? Voulez-vous les associer à un nouveau statut ? Voulez-vous les supprimer ou ne pas apporter cette modification ? C'est juste pour nous le faire savoir. Dans ce cas, comme nous venons de le configurer, nous n'avons aucun élément de travail existant dans ces statuts que nous sommes en train de supprimer, n'est-ce Nous y ajoutons un flux de travail. Nous ne supprimons aucun flux de travail de notre schéma. Mais si nous revenons à notre projet, examinons le projet ici, juste un moyen rapide d'y revenir. Il se peut que nous rencontrions un problème que nous devrons résoudre car je ne sais pas si nous devions venir ici et créer un nouvel élément de travail. Je ne sais pas si nous avons encore des bugs ici. Non, nous n'avons pas de bugs dans notre espace. Passons donc à nos éléments de travail, à nos types. Et ajoutons un type de travail. Nous voulons donc nous assurer que nous ajoutons réellement des bogues, afin de pouvoir utiliser des bogues dans cet espace. Allons-y. Appuyez sur Enregistrer. Nous pouvons désormais utiliser des bogues dans notre espace de développement logiciel, et chaque fois que nous utilisons des bogues, le flux de travail des bogues sera utilisé au lieu du flux de travail utilisé par tous les autres éléments de travail. Vous pouvez voir la différence ici, non ? Ils utilisent donc tous le flux de travail que nous avons créé, et nous avons travaillé tout au long de ce cours. Mais ce type de travail utilise un flux de travail différent. Voyons donc cela en action. Si nous devions retourner dans notre espace ici, entrons et examinons tous les différents éléments de travail dont nous disposons. Nous allons fermer le menu pour avoir un peu plus de place dans les colonnes. Voici donc les éléments de travail sur lesquels nous avons travaillé tout au long de ce cours. Regardons celui-ci ici, d'accord ? Regardez le statut, non ? C'est ce que nous avons examiné tout au long de ce cours, bloc en cours. Une fois que ce sera en cours, nous pourrons venir ici et commencer à le prendre. Nous l'avons effectivement parce que nous ne sommes pas connectés en tant que développeur. Si nous nous connectons en tant que développeur, tant qu'Ethan, il peut réellement prendre cela et exécuter dans les différents flux de travail, n'est-ce pas ? Voici donc le flux de travail que nous avons mis en place. Mais si cet élément de travail devait changer, nous avons vu comment remplacer l'élément de travail d' une vidéo précédente par un autre type. Si nous devions passer d'une idée à un bogue, regardez ce qui se passerait. Donc ça dit : OK, attends une minute. Cela a été modifié. Comment voulons-nous associer cela au nouveau flux de travail, n'est-ce pas ? OK, donc pour le moment, c'est une idée. Nous voulons changer cela pour en faire un bogue. Ensuite, il va passer en revue et dire : OK, quel en est le statut ? Est-ce que tout cela est bon ? Et comme nous sommes en train de progresser, tout semble aller bien. Il n'y a aucun problème. Il s'agit d'un simple résumé de ce qui va se passer. Cela va passer du statut d'idée à celui de bug. Il ne sera plus en cours dans ce flux de travail mais en cours dans ce flux de travail. Maintenant qu'il fait partie du flux de travail relatif aux bogues, il ne sera plus soumis au même processus d'assurance qualité que celui que nous avons mis en place dans le flux de travail de développement logiciel. Il va passer par un processus complètement différent, ce qui signifie qu'il peut simplement entrer. Cela peut être à faire. Cela peut être fait. Il ne va pas passer par le processus d'assurance qualité que nous avons mis en place dans le flux de travail de développement logiciel. Et le back-end se trouve dans l'éditeur de flux de travail où nous pouvons voir laissez-moi les ouvrir côte à côte afin que nous puissions voir ces deux flux de travail différents sous les flux de travail. Nous avons le flux de travail relatif aux bogues. Je vais donc l'ouvrir dans un nouvel onglet. Je vais ouvrir une fenêtre hors écran qui apparaîtra bientôt ici. Nous avons le flux de travail de développement logiciel avec lequel nous avons travaillé tout au long de ce cours. Allons-y. C'est donc le flux de travail qui était à l'origine de l'idée lors de sa création. Ensuite, lorsque nous l'avons modifié, il est devenu ce flux de travail, le flux de travail sur les bogues. Que nous venons de créer, ce qui signifie qu'il ne passe par aucun des autres statuts que nous avons ici, n'est-ce pas ? Dans le même espace, il est toujours utilisé dans le même espace, mais il n'est utilisé que pour le type de travail BG. Mais ici, ce flux de travail est utilisé pour tous les autres types de travail à l'intérieur de l'espace. OK, donc pour récapituler. Dans cette leçon, nous avons appris ce qu'est un schéma de flux de travail. C'est un moyen de mapper les types de travail aux flux de travail d'un espace. Nous avons également appris à créer un nouveau flux de travail et utiliser le schéma pour lui indiquer le type de travail à utiliser avec celui-ci. Et comme vous pouvez l'imaginer, toutes ces transitions, règles et informations que nous avons apprises jusqu'à présent sont incluses dans chaque flux de Nous pouvons donc personnaliser encore davantage ce flux de travail lié aux bogues si nous le voulions. Dans notre prochaine leçon, nous allons tout relier aux processus agiles de notre équipe en observant comment flux de travail affectent nos tableaux agiles dans Jira 10. Utiliser les flux de travail avec les tableaux agiles: Dans cette leçon, nous verrons comment les flux de travail et les tableaux agiles fonctionnent ensemble, car c'est là que notre équipe interagit le plus souvent avec les flux de travail au quotidien via notre tableau agile. En résumé, les tableaux Agile et Jira font simplement correspondre les statuts de notre flux de travail à un tableau visuel avec des colonnes . N'oubliez pas que chaque statut appartient à l'une des trois catégories suivantes : effectuer en cours ou terminé. Le tableau regroupe également les statuts en fonction de ces catégories , comme en témoignent les barres grises, bleues et vertes situées tout en haut Le gris indique « à faire », le bleu « en cours », puis le vert indique les statuts figurant dans la catégorie « terminé ». Maintenant, voyons cela en action. Je vais accéder au tableau agile de notre espace. Alors entrons, et nous allons entrer dans l'espace lui-même. Ensuite, nous pouvons entrer dans l'espace en utilisant le fil d'Ariane, un moyen très rapide d'y arriver Et cela devrait nous amener à l'espace global lui-même. se peut que nous devions accéder à la vue du tableau si elle ne nous y amène pas par défaut, mais il semble que le tableau soit en train de charger. Très bien, voici donc le tableau Cbon que nous avons installé dans notre espace Maintenant, si vous utilisez un tableau Scrum, c'est essentiellement le même processus, à l'exception, bien sûr, de la différence entre Scrum et Cbon qui utilisent des sprints sur des tableaux Scrum et pas les tableaux Mais sur le back-end, la façon dont il est lié aux flux de travail est la même. Ces colonnes sont liées aux différents statuts des éléments de travail Donc, si nous entrons dans les paramètres du tableau, nous pouvons le voir sur le backend, dans les colonnes. Et nous pouvons voir que les tâches en cours et les tâches terminées sont mappées sur ces différentes colonnes Mais nous pouvons constater qu'un grand nombre des différents statuts que nous avons créés dans notre flux de travail ne sont actuellement mappés à rien Nous pouvons donc vraiment personnaliser cela comme nous le souhaitons sur le forum, ce qui permettra à nos utilisateurs de passer très rapidement d'un statut à l'autre Configurons donc cela très rapidement. Disons, d'accord, pour la révision du code, disons que nous voulons ajouter un nouveau statut ici, une nouvelle colonne, devrais-je dire. Ajoutez ça. Oups. Révision du code. Ensuite, nous pouvons associer ce statut à cette colonne ici. Et je veux vraiment le déplacer. Il va donc être en cours de révision du code, puis le blocage peut également être en cours. Ça ne suffira pas, c'est un statut terminé. Pour quar, construisons en fait une seule colonne à partir de laquelle A pourra s'appuyer. Nous allons prendre ça. Ce sera après la révision du code. Encore une fois, avec Agile, vous allez de gauche à droite. Ray for A, les tests d'assurance qualité peuvent figurer dans la même colonne. Nous y voilà. Nous avons donc tout configuré sur le back-end mappant les statuts aux différentes colonnes Voyons comment cela fonctionnera dans la pratique. Revenons donc à notre connexion en tant que développeur, Ethan Donc, si nous abordons le conseil d'administration notre projet de développement logiciel, nous verrons comment tous ces éléments sont liés, n'est-ce pas ? Nous avons donc ces différents éléments de travail qui sont les différents statuts liés à cette colonne Nous pouvons donc voir celui-ci ici Si nous l'ouvrons, le statut est la révision du code. Mais si je devais changer cela, si nous devions changer cela, disons passer à en cours, ce qui se passerait sur le tableau pour être maintenant en cours. C' est donc le processus de base, n'est-ce pas ? Lorsque vous prenez quelque chose et que vous le changez d'une colonne à l'autre, en arrière-plan, Jira fait exactement la même chose que nous avons fait jusqu' à présent Il passe par le processus de transition entre les différents statuts de ces de travail Maintenant que nous avons modifié la colonne, le statut de cet élément de travail change également, n' est-ce pas ? C'est donc maintenant en cours de révision du code. C'est en fait passé par l'agent. Vous pouvez donc voir qu'il a été exécuté par le même agent de triage que celui que nous avons configuré car cela fait partie de la transition entre ces différents statuts Cela arrive toujours sur le plateau aussi. Il attend juste notre avis. Voulons-nous vraiment en changer le niveau de priorité, n'est-ce pas ? C'est donc ce que je suggère cette fois. Oui, allons-y et changeons le niveau de priorité de cela. Cela va être mis à jour. On peut même voir sur le tableau le hot Back here. Je ne sais pas si vous remarquez, mais ici, ça dit qu'il y a un agent de triage ici Ainsi, lorsque nous y glissons des éléments de travail, cela déclenche cet agent, ce qui signifie que vous voudrez probablement y aller pour vérifier et voir ce qu'il va faire. Encore une fois, l'agent de triage ne fera rien sans qu'un humain ne l'examine d' abord et ne s'assure qu'il souhaite accepter ces recommandations Dans les coulisses, le flux de travail continue donc de tout contrôler. Tout ce que nous avons configuré est toujours contrôlé sur ce forum. Même les schémas de flux de travail. Alors regardez ce qui se passe avec ce bogue. C'est en cours. Mais nous ne pouvons pas passer cela à la révision du code. Nous ne pouvons pas porter ça au QA. Nous ne pouvons que poursuivre dans cette voie, car si vous vous souvenez, lorsque nous avons créé le flux de travail BG, celui-ci ne comportait que trois statuts en cours, ce qui est déjà fait ou est déjà fait Nous ne pouvons pas l'intégrer à ces autres statuts, car ce type de travail n'est pas associé au flux de travail contenant ces statuts C'est là que vous pouvez réellement contrôler non seulement les flux de travail eux-mêmes, mais aussi les types de travail utilisant différents flux de travail, et vous pouvez vraiment voir comment vous pouvez commencer à personnaliser cela pour votre équipe. C'est donc là que les flux de travail peuvent vraiment commencer à devenir complexes, selon la façon dont vous les avez configurés. Si vous vous en souvenez, nous avons établi certaines règles concernant nos transitions. Donc, pour passer de la revue de code à A, même si sur le back-end, nous avons plusieurs statuts mappés dans cette colonne Lorsque nous sommes connectés en tant que développeur, en tant qu'Ethan, il ne peut passer qu'au statut « prêt pour l'assurance qualité », ce qui signifie que s'il devait prendre le relais ici, il ne pourrait que passer au statut « prêt pour l'assurance qualité Même si ici est en cours, il peut choisir le statut qu' il souhaite attribuer à l'assurance qualité Il ne peut voir celui-ci qu'en raison des restrictions que nous avons imposées, car il fait partie du groupe de développeurs, et seuls les utilisateurs du groupe de développeurs peuvent se préparer à l'assurance qualité. Une fois qu'il est prêt pour l'assurance qualité, regardez, il va être mis à jour et automatiquement attribué à MAX. Encore une fois, une autre chose que nous avons configurée dans ce cours était l'attribution automatique à MAX. Maintenant, si nous nous connectons pour être connecté en tant que MAX, nous pouvons voir cet élément ici, il apparaîtra ici. Vous pouvez le voir mis à jour en temps réel pour être en phase d'assurance qualité. Maintenant que nous sommes connectés en tant que Max au sein de l'équipe d'assurance qualité, il peut réellement s'en occuper et le mettre à jour. Maintenant, il ne peut pas en parler à Dunn, car cela doit en fait passer à l' étape suivante de notre flux de Si vous vous souvenez que la prochaine étape du flux de travail consiste à passer à l'étape suivante d'assurance qualité, n'est-ce pas ? Vous devez donc en démarrer un avant de pouvoir faire en raison de la façon dont notre flux de travail est configuré. C'est donc là que nous devrions entrer ici et nous demander : « D'accord, voulons-nous vraiment une seule colonne pour assurance qualité ou voulons-nous une deuxième colonne qui nous permettra de démarrer l'assurance qualité et de la faire glisser là-dedans pour que Max n'ait pas à entrer et à ouvrir cet élément de travail comme nous venons de le faire. Il pourrait simplement le faire glisser maintenant une fois qu'il sera en cours de test d'assurance qualité. Il est en cours de test. Il n'est pas prêt pour l'Aqua. Maintenant, nous pouvons l'intégrer Dunn parce qu'il a suivi ce processus. Encore une fois, tout cela se trouve dans le back-end notre flux de travail, qui est lié aux colonnes du tableau. Donc, si nous voulions étendre cela, nous pourrions le faire. Nous pourrions ajouter une deuxième colonne si vous le souhaitez pour l'assurance qualité. Cela dépend vraiment de ce qui fonctionne le mieux pour votre équipe et de la manière dont vous souhaitez que tout cela se passe. Bien sûr, le hic , c'est que maintenant, Ethan va voir cette autre chronique apparaître également sur son tableau, mais il ne va pas être capable d'y glisser quoi que ce soit Il va juste voir quels éléments de travail sont actuellement en cours de test. Il ne peut pas vraiment le déplacer là-bas cause des restrictions que nous avons mises en place. Vous pouvez voir qu'il n'est pas en mesure de le faire glisser là-bas en raison des restrictions de notre flux de travail. Pour récapituler ce que nous avons appris dans cette leçon, statut est mappé aux colonnes du tableau Agile Et il est même possible que plusieurs statuts partagent la même colonne Lorsque nous déplaçons le travail d' une colonne à l'autre de notre tableau, nous le faisons réellement passer d' un statut à un autre dans notre flux Cela signifie que toutes ces règles de notre flux de travail s'appliquent également. Donc, si vous rencontrez des difficultés pour déplacer travail d'une colonne à l'autre, c'est probablement à cause des règles telles que les restrictions ou les validateurs que nous avons apprises dans ce cours Nous. C'est beaucoup, n'est-ce pas ? Cela dit, nous avons presque terminé notre cours, mais j'aimerais vous inviter à vous joindre à moi pour une dernière vidéo dans laquelle nous prendrons quelques instants pour réfléchir à tout ce que nous avons appris dans ce cours. 11. Résumé du cours: Tu as atteint la dernière leçon. Dans ce cours, nous avons expliqué comment créer un flux de travail personnalisé, en commençant par les statuts et les transitions de base, passant par les règles du flux de travail, les agents d'intelligence artificielle, puis nous l'avons réintégré à nos tableaux agiles Permettez-moi de vous présenter les principaux points que j'espère vraiment que vous en retiendrez. Commencez simplement. Nous n'avons pas construit un Behem à 30 statuts Nous avions quelques statuts qui répondaient à nos besoins. Si vous n'avez jamais créé de flux de travail auparavant, commencez par ce que fait réellement votre équipe au quotidien. Ajoutez de la complexité uniquement lorsque le flux de travail prouve qu'il est nécessaire. Ensuite, associez les flux de travail aux types de travail. Certains types de travail partagent des cycles de vie, comme les idées et les tâches dans notre cas, mais d'autres n'ont pas leur propre flux de travail, et il n'est pas nécessaire de forcer un flux de travail à répondre à tous si les cycles de vie ces types de travail sont généralement différents. Utilisez également des règles pour résoudre les problèmes, et non pour en créer de nouveaux. Vous pouvez limiter la transition pour contrôler qui peut déplacer le travail, valider les détails pour garantir existence des données, effectuer des actions, automatiser les mises à jour, demander des entrées, collecter des données aux moments clés. Chaque type de règle a une fonction, mais ne les empilez pas simplement parce que vous le pouvez. Donnez un but à chacun de ceux que vous utilisez. Et faites attention aux crédits Rovo. Nous utilisons l'agent de triage avec une invite personnalisée lors des transitions, et Rovo est inclus dans les forfaits Jira Cloud payants, standard premium et entreprise à compter de n'y a donc pas de licence distincte à craindre, mais chaque niveau de plan est assorti d'une allocation de crédit mensuelle par utilisateur, et les agents consomment des crédits à chaque fois qu'ils fonctionnent. Déployez-les donc là où leur analyse apporte une véritable valeur ajoutée, non à chaque transition. Et continuez à recevoir des commentaires et à mettre à jour vos flux de travail. Vous allez le modifier au fur et à mesure de l'évolution des processus de votre équipe, ajouter des statuts lorsque de nouveaux transferts apparaissent, les supprimer lorsqu'ils Testez les modifications avant mettre à jour votre flux de travail pour l'ensemble de votre équipe. La partie la plus difficile de la création de flux de travail est surmonter la croyance selon laquelle ils doivent être parfaits dès le premier essai. Ce n'est pas le cas. Construisez quelque chose qui fonctionne pour aujourd'hui. Effectuez des itérations lorsque l' équipe en a besoin de plus, et vous obtenez ainsi un flux de travail qui correspond à la façon dont votre équipe travaille réellement Merci beaucoup de m'avoir rejoint dans ce voyage. Que vous soyez administrateur Jira, administrateur d'espace ou chef d'équipe, j'espère que vous disposez désormais des outils et de la confiance nécessaires pour créer des flux de travail adaptés à la manière dont votre équipe travaille réellement Merci encore d'avoir regardé.