Flujos de trabajo de Jira: crea flujos de trabajo personalizados que se adapten a la forma en que trabaja tu equipo

1. Introducción al curso: Bienvenido a este curso todo sobre flujos de trabajo de Jira. Mi nombre es Dan Lefeb y en este curso, aprenderemos a construir flujos de trabajo personalizados que coincidan con cómo funciona realmente tu equipo Al final de este curso, podrás personalizar flujos de trabajo para diferentes tipos de trabajo, como ideas, tareas, errores. Cada uno puede tener su propio flujo de trabajo en tus espacios Jira También aprenderemos a agregar restricciones para que solo personas específicas puedan realizar ciertas transiciones. Aprenderemos a validar los datos antes de que transcurra una transición entre dos estados diferentes También aprenderemos a automatizar tareas con acciones y agentes de IA, implementar flujos de trabajo en su espacio usando esquemas de flujo de trabajo, conectar su flujo de trabajo a tableros ágiles y mucho más. Este curso se enfoca en espacios gestionados por la empresa, lo que le brinda un control total sobre flujos de trabajo y esquemas. Eso también significa que tendremos permisos administrativos globales para poder configurar flujos de trabajo en toda nuestra instancia de Jira Ahora bien, si estás usando espacios gestionados por equipos, aún obtendrás valor de la mayoría de las lecciones de este curso, porque el editor de flujo de trabajo en espacios administrados por equipos funciona la misma manera que en espacios administrados por la empresa que estamos usando a lo largo de este curso. Al final de este curso, tendrás un flujo de trabajo de estado completamente funcional con restricciones, validaciones, acciones automatizadas, agentes de IA desplegados en Ahora, antes de entrar en Jira, tomemos unos momentos para ponernos en la misma página sobre los conceptos centrales de los flujos de trabajo de Jira, y lo cubriremos en nuestra próxima lección 2. Conceptos básicos de los flujos de trabajo de Jira.: En esta lección, cubriremos los conceptos centrales detrás flujos de trabajo de Jira antes saltar a la propia interfaz de Jira Cada flujo de trabajo en Jira consta de dos partes principales, estados y transiciones Los estados representan dónde se asienta un elemento de trabajo en su ciclo de vida Los estados básicos son hacer en progreso y hecho. Pero podemos extenderlos creando cualquier estado personalizado que queramos, como revisión de código, listo para QA, QA testing o bloqueado, cosas así Dicho esto, no importa qué estatus sea el que creamos, cada estatus pertenece a una de tres categorías. Esas categorías son para hacer en progreso y hecho. Si bien no podemos crear categorías personalizadas en Jira, son principalmente para la propia organización de back end de Jira para ayudarle a determinar cuál es cualquier tipo de estado personalizado que creamos Básicamente, cualquier estado personalizado que creamos va a vivir dentro de una de esas tres categorías, y luego eso determina cómo Jira sabe cuándo hacer ciertas cosas Por ejemplo, si algo está en la categoría de hecho, entonces Jira sabe que la obra está terminada No importa si llamas al estado hecho o completo o terminado o como podamos llamarlo para el estado personalizado, porque está en la categoría hecho, Jira sabe que el trabajo está hecho Las transiciones representan la acción que mueve un elemento de trabajo de un estado a otro. Técnicamente, una sola transición es un movimiento unidireccional. Si queremos movernos de un lado a otro entre dos estados, necesitamos dos transiciones separadas Ahora con eso dicho, hay algunas formas en las que podemos permitir Jira haga la transición de estados en cualquier dirección, y lo veremos en este curso Pero solo debes saber que en la parte de atrás, si pasamos el trabajo de a hacer a en progreso y luego de vuelta a hacer, eso son técnicamente dos transiciones diferentes. Uno de hacer a en progreso, y luego otro diferente de en progreso volver a hacer. Eso es importante porque podemos decirle a Jira qué tipo de cosas queríamos hacer con cada una de esas transiciones Si queremos que el elemento de trabajo haga algo diferente cuando va de hacer a en progreso, entonces cuando pasa de en progreso de nuevo a hacer. Como puedes imaginar, las cosas pueden comenzar a volverse complejas bastante rápido. Por lo tanto, es importante llegar a una convención de nomenclatura sólida para nuestros estados y transiciones Entonces sabremos qué significa cada uno y qué hace. Y aquí hay algunos consejos para comenzar. Número uno, usa nombres claros y consistentes. La revisión de código es mejor que la etapa de revisión o incluso en desarrollo. Eso lleva al número dos. Evite la superposición de significados. Si tenemos tanto en desarrollo como en progreso, eso puede resultar confuso. Pero en progreso y la revisión del código como estados separados, nuestro equipo sabrá cuál representa el desarrollo activo versus el traspaso Y como administrador jure, podríamos volver a un flujo de trabajo dentro de meses o años y no recordar para qué se utilizan si esos estados suenan similares Como un pequeño consejo extra, si aún no lo estás, empieza a hacer documentación sobre nuestras convenciones de nomenclatura De esa manera, si lo hacemos, por alguna razón, optamos por hacer estados de sondeo similares, podemos referirnos de nuevo a los del futuro para saber por qué elegimos ir con algo específico Y si tu organización está utilizando herramienta de documentación de Atlassian llamada Confluence, ese es un gran lugar para almacenar toda esa documentación de la convención de nomenclatura Tercero, mantenlo simple. No agregues un montón de estados solo para tratar de organizar en exceso las cosas Agregue el mínimo para comenzar y luego obtenga comentarios de nuestro equipo en las próximas semanas y meses sobre si encontraríamos útil o no agregar más al flujo de trabajo, tal vez agregar una o dos cosas más y luego ver si eso ayuda. De no ser así, remoción. Si es así, manténgalo alrededor. Cuanto más tenemos en nuestro flujo de trabajo, más complejo se vuelve, y no queremos que las cosas se vuelvan inminables Ahora bien, si has estado usando Jira por un tiempo, es posible que estés acostumbrado a alguna terminología más antigua que ha cambiado un poco con las actualizaciones recientes Entonces, en este curso, hay cuatro tipos de reglas de flujo de trabajo que encontraremos, y los términos para esas reglas han cambiado. Primero, tenemos las reglas de transición de restricción. Esos antes se llamaban condiciones. Aquellos controlan quién puede ver y usar una transición. Si un usuario no cumple con la restricción, entonces no puede hacer la transición entre estados A continuación, tenemos las reglas de entrada de solicitud que aparecen en una pantalla durante una transición que le pide al usuario que complete una transición que le pide al usuario que complete campos específicos antes de que prosiga la transición, y lo cubriremos más adelante en este curso. Es como un primo más amable de validadores que solicita datos en lugar de Y luego tenemos las reglas de validar detalles. Esos antes se llaman validadores. Aquellos verifican si los datos requeridos existen antes de permitir esa transición. Entonces es más estricto que solo solicitar insumos. Por ejemplo, requerir que se establezca el campo de versión fija antes de cerrar un elemento de trabajo. Y nuevamente, veremos eso más adelante en este curso. Entonces tenemos las reglas de realizar acciones. Esas se llamaban antiguamente funciones de poste. Esos se ejecutan automáticamente después de que se completa una transición. Actualizan campos, asignan usuarios o pueden activar agentes de IA, y los veremos más adelante en este curso. Ahora, también hay algo a tener en cuenta sobre los permisos. Un usuario necesita algo más que permisos de flujo de trabajo para mover un elemento de trabajo. También necesitan poder editar el elemento de trabajo en sí. Entonces, cuando estés probando restricciones, asegúrate de usar un usuario que tenga al menos permisos de edición básicos para ese tipo de trabajo. Entonces, para recapitular, los flujos de trabajo consisten en estados y transiciones Cada estado pertenece a una categoría que determina su apariencia de tablero. Las transiciones son acciones unidirectivas entre estados, y hay cuatro tipos de reglas que podemos tener sobre las transiciones Pueden restringir quién puede hacer esa transición, pueden solicitar entrada durante una transición. Puede validar los datos antes de realizar la transición y realizar acciones después de la transición Ahora en nuestra siguiente lección, saltaremos a Jira para que podamos convertir un flujo de trabajo predeterminado en uno personalizado, y luego comenzaremos a construir desde allí 3. Configuración de estados y transiciones personalizados: En esta lección, saltaremos a Jira y comenzaremos a construir nuestros propios estados y transiciones personalizados para construir nuestro flujo de trabajo de desarrollo de software Primero, vayamos al editor de flujo de trabajo. Ahora bien, hay dos formas en las que podemos llegar ahí. Podemos pasar por nuestra configuración espacial. Entonces podemos entrar en estos tres pequeños puntos, entrar en ajustes de espacio. Y eso es práctico. Si ya estamos trabajando dentro de nuestro espacio específico, podemos llegar al flujo de trabajo que el espacio está utilizando. Pero como esta es la primera vez que saltamos a Jira en este curso, y estamos trabajando como administradores globales de Jira, pasemos por la configuración global de Jira donde podemos ver y administrar todos los flujos de trabajo en toda nuestra instancia Para que podamos llegar a los ajustes, bajar a los elementos de trabajo. Y luego por aquí del lado izquierdo, si llegamos a nuestros flujos de trabajo, esto nos va a mostrar todos los flujos de trabajo que tenemos en nuestra instancia de Jira Ahora estamos trabajando con un espacio llamado desarrollo de software, este de aquí mismo. Entonces este es el flujo de trabajo que se utiliza en este espacio. Vamos a entrar en tres puntos. Ven a editar, y eso nos llevará al editor de flujo de trabajo. Voy a cerrar esto solo para darnos un poco más de espacio para que podamos ver aquí al editor. Ahora, aquí podemos ver los estados y transiciones predeterminados de la plantilla Scrum Esa es la plantilla que usé cuando creé este espacio. Tenemos que hacer en progreso y hecho. Y entonces aquí arriba, tenemos que empezar, ¿no? Así que en realidad voy a mantener pulsado Control, usar mi rueda del ratón para acercar solo para que podamos ver esto un poco más fácil. Entonces aquí tenemos inicio. Y esto no es realmente un estado, pero es el comienzo de cuando se inicia un nuevo elemento de trabajo, ¿verdad? Entonces cuando empieza, luego pasa por esta creación de transiciones, y eso le dice a Jira, cuando creas un nuevo elemento de trabajo, ¿a dónde va? En este caso, y por defecto, va a esto para hacer status. Ahora bien, si quisiéramos cambiar eso, todo lo que tendríamos que hacer es seleccionar aquí esta transición y luego moverla a un estatus diferente. Digamos que queremos que esté en progreso. Ahora bien, si tuviéramos que crear un nuevo elemento de trabajo dentro de este espacio, estaría en progreso tan pronto como actualicemos este flujo de trabajo. Por qué, claro, de manera realista, eso no tiene mucho sentido Dejemos esto en para hacer por este estado. Y eso trae a colación un buen punto porque antes de pasar por el proceso de hacer muchos cambios en el editor de flujo de trabajo, recomiendo encarecidamente que te tomes el tiempo para esbozar exactamente lo que necesitas en tu flujo de trabajo primero. Entonces para cuando entres aquí, ya sabes lo que vas a estar haciendo o tienes una idea de cómo todo va a conectar entre sí. Ahora, si estás usando confluencia junto a Jira, puedes usar sus pizarras digitales Es un gran lugar para hacerlo dibujando cada estado y transición de una manera muy suelta antes de venir aquí y hacerlo realmente funcional en el editor de flujo de trabajo. Por supuesto, siempre puedes cambiar las cosas más adelante, pero ese poco de planeación previa te dará un buen punto de partida. Dicho esto, a veces es útil ver primero cómo trabajan otros equipos. Así que ya he pasado por ese proceso de averiguar cómo quiero que vaya este flujo de trabajo que estamos usando hoy Entonces comencemos agregando nuestros nuevos estados para trabajar, y pasaremos por el proceso de crearlos todos a la vez, y luego organizaremos todo y lo conectaremos todos juntos Entonces voy a subir aquí al estado del anuncio arriba en la parte superior, y queremos crear algunos estados Así que vamos a entrar aquí y o bien seleccionamos un estado que ya hemos creado en nuestra instancia de Jira, o voy a entrar aquí y empezar a escribir No, aún no tenemos ese estatus, así que vamos a crearlo. El rubro va a estar en curso. Y luego podríamos permitir transiciones desde el estado Edi aquí mismo, pero solo voy a seguir adelante y hacer clic en Agregar, enfocarnos en agregar estos estados para empezar, y luego organizaremos todo más adelante Así que vamos a estar listos para QA es nuestro próximo estado. Crea eso. Nuevamente, la categoría va a ser alguna forma de progreso. En el estado, vamos a entrar, y esto va a ser una prueba de QA. Nuevamente, la categoría va a ser alguna forma de esto está en curso. Vamos a sumar en nuestro estado de bloqueo. Y luego vamos a agregar un estatus más aquí, y vamos a hacer un estado de no hacer. Y esa va a ser otra forma de hacer. Para que tengamos un par de estados diferentes en la categoría De Y en lugar de tener a todos ellos siendo este trabajo realmente está hecho, siendo este trabajo realmente está hecho, si entramos aquí y agregamos uno que no va a hacer, si agregamos trabajo al estado de no va a hacer, entonces podemos volver más tarde a los informes y filtros y ver los que conscientemente tomamos la decisión de que sí, esto en realidad se completó, esto está hecho, o tomamos la decisión realmente no hacer ese trabajo por la razón que sea. Y luego en el elemento de trabajo en sí, agregarías cualquiera que sea la razón por la que no decidiste hacer ese trabajo. Bien, así que ahora tenemos nuestros estados creados. Entremos aquí y comencemos a crear algunas transiciones. Entonces sobre estos estados que ya tenemos, esta es la cualquier transición Eso significa que los elementos de trabajo en el estado hecho pueden pasar a este estado desde cualquier otro estado. Entonces, si está en progreso, si es para hacer, si es alguno de estos aquí, realidad puede pasar al estado hecho de ese otro estatus. Pero quizá no siempre queramos eso. Entonces comencemos por organizar esto creando algunas transiciones nuevas entre estos estados, porque ahora mismo, estos están resaltados, lo que significa que no hay forma de que nada pueda pasar al estado de revisión de código No podemos tener trabajo en el estado de revisión de código si no hay transición a él. Entonces voy a venir y tomar uno, digamos, de en progreso, queremos en progreso para entrar en revisión de código. Y vamos a darle un nombre a este estado. Siempre es una buena idea ponerle un nombre a todo. Y aquí es donde la planeación previa puede venir realmente útil, lo que vas a estar nombrando las cosas Por lo que esto va a ser presentado para revisión. Por lo que va de en curso a revisión de código a transición se somete para revisión. Para las próximas transiciones, vamos a decir, Bien, cuando el trabajo está en revisión de código, va a salir de la revisión de código, y luego vamos a tener que estar listo para QA. Y este estatus o estas transiciones, debería decir, se va a llamar aprobado, ¿verdad? Por lo que ha sido aprobado, y luego pasa de revisión de código. La revisión del código lo aprueba, y va a estar lista para QA. Ahora bien, otro posible flujo de trabajo para esto es si no se aprueba, si hay algo que necesita cambiar, podemos entrar y decir: Bien, revisión de código, volvamos a llevar esto en progreso. Y esta va a ser la transición va a ser solicitar cambios. Ahí vamos. Entonces ese es otro flujo de trabajo potencial que nuestros elementos de trabajo podrían tener. Y podemos reorganizar esto si solo queremos que esto tenga un poco más de sentido en cómo tenemos todo esto organizado A continuación, cuando el trabajo está listo para el estado de QA, ¿qué sucede aquí? Bien, entonces listo para el control de calidad en este flujo de trabajo básicamente va a ser el estado a hacer para nuestro equipo de QA, ¿verdad? Van a hacerlo una vez que haya pasado por revisión de código por parte de los desarrolladores, va a estar listo para QA. Y luego cualquier cosa en el estado listo para QA, nuestro líder de QA, ese usuario va a poder saber, Bien, esto está listo para funcionar. Y luego, como en realidad están trabajando en ello, pueden tomar el trabajo, arrastrarlo a las pruebas de QA para demostrar que las pruebas realmente se inician en esto. Y para esto, digamos, simplemente vamos a llamar a este inicio QA. Y luego puede provenir de las pruebas de QA, y en realidad queremos que esto se haga para decir, Sí, bien, esto se ha completado Ahí vamos. O al igual que hicimos con la revisión del código, si hay un cambio que tiene que suceder, podemos llevar esto de las pruebas de control a en curso y decir, esto necesita ser enviado de vuelta para una solución. Ahí vamos. Y entonces para estos otros dos estados, ciertamente habrá momentos en los que queremos hacer una transición global de cualquier status a otro status, y en cualquier momento, queremos poder decir, tomamos la decisión de no hacer este trabajo Entonces para esto, vamos a agregar transiciones, y esto va a ser de cualquier estado a no va a hacer. Adelante y crea eso. Y luego lo mismo con bloqueado, vamos a decir en cualquier momento, cualquier trabajo puede ser bloqueado en este flujo de trabajo. Ahí vamos. Así que tenemos nuestro flujo de trabajo creado aquí dentro del editor de flujo de trabajo. Y ahora tenemos nuestro flujo de trabajo listo para funcionar. En nuestra siguiente lección, comenzaremos a ver algunas de las reglas que podemos agregar a nuestro flujo de trabajo, comenzando por restringir las transiciones 4. Restricción de Transiciones: En esta lección, aprenderemos sobre el primer tipo de regla de flujo de trabajo que restringe quién puede ejecutar una transición La regla de transición de restricción se llamaba anteriormente condiciones en versiones anteriores de Jira, y controla si una transición está disponible en absoluto, en base a cualquier regla que decidamos Probablemente el caso de uso más común para esto es restringir una transición en función de quién es el usuario. Entonces aquí hay un escenario común que vamos a aprender a configurar en esta lección. Solo queremos que los desarrolladores puedan enviar trabajos para revisión de código. Entonces, en nuestra configuración, Ethan es desarrollador, y está en el grupo de usuarios del desarrollador Maxwell es nuestro líder de control de calidad, y no está en el grupo de desarrolladores, y queremos que Ethan pueda enviar para revisión para pasar de un estado a otro al estado de revisión de código, pero Maxwell no debería poder pasar de estado en curso a ese estado de revisión de código Así que vamos a configurar eso. Lo que queremos hacer es utilizar este envío para transición de revisión que creamos en la lección anterior. Bajo esta transición, porque ese va a ser cualquier trabajo del que venga en curso a la revisión del código, tiene que pasar por esta transición. Pasemos a nuestras reglas, restrinjamos la transición, agreguemos una regla de restricción de transición. Y luego queremos restringir en función de quién es el usuario. Así que restringe quién puede mover un elemento de trabajo. Y podemos elegir ya sea usuarios específicos, o me pareció que un mejor flujo de trabajo es usar grupos. De esa manera podemos agregar usuarios al grupo, y todas estas reglas se aplicarán automáticamente en lugar de que solo sean usuarios individuales. Entonces voy a entrar y elegir grupos, y vamos a seleccionar el grupo de desarrolladores. Entonces eso significa que solo los desarrolladores podrán usar esta transición para pasar de en curso a revisión de código. Golpea AD ahí vamos. Tenemos esto sumado a nuestras reglas por aquí en el lado derecho. Ahora, para que esto entre en vigor, realidad tenemos que actualizar el flujo de trabajo. Entonces ahora mismo, básicamente estamos en modo borrador. En realidad no hemos actualizado esto. Entonces, para que esto se convierta en vivo, necesitamos actualizar el flujo de trabajo. Ahora que nuestro flujo de trabajo está actualizado, veamos cómo es esto para nuestro equipo. Entonces primero, voy a iniciar sesión como Maxwell. Esto se ha iniciado sesión como Maxwell Carter. Él es nuestro líder de QA, que no forma parte del grupo de desarrolladores al que acabamos de agregar esa restricción de transición. Entonces, si tuviéramos que entrar en uno de estos elementos de trabajo que está en curso, puedes ver que Maxwell ni siquiera puede llevar esto al estado de revisión de código porque la única forma de hacerlo es pasar por esta transición de envío para revisión que hemos restringido Ahora bien, si tuviera que iniciar sesión como Ethan, quien es uno de los desarrolladores del grupo de desarrolladores, déjame abrir esa ventana aquí Estoy conectado como Ethan aquí. Ahora inició sesión como Ethan. Si tuviéramos que mirar uno de estos elementos de trabajo, ver el estado. Está en progreso. Si tiro esto hacia abajo, podemos usar ese envío para la transición de revisión para pasarlo al estado de revisión de código. Y ahí vamos. Ahora, Ethan puede cambiar el elemento de trabajo para que esté en el estado de revisión de código debido a esta transición, la transición de enviar para revisión solo permite que las personas ese grupo de desarrolladores pasen por esa transición, que es la única forma de ingresar a ese estado de revisión de código Mismo estado, mismo elemento de trabajo, diferentes permisos de usuario. Es una forma poderosa de hacer cumplir el acceso basado en roles en nuestro flujo de trabajo sin depender de nosotros para recordar cuáles son las reglas. El sistema lo puede hacer cumplir por nosotros. Algunos otros casos de uso de transición restringida comunes pueden incluir cosas como tal vez solo permitir que esta transición aprobada sea líderes de proyectos o gerentes. O tal vez ya que tenemos un equipo de control de calidad configurado, tal vez solo el equipo de QA pueda completar el QA y enviarlo a Dunn después que haya terminado con las pruebas de QA o tal vez incluso solo pueda comenzar el QA Tal vez solo queremos que el equipo de QA pueda iniciar QA una vez que esté listo para QA, solo el equipo equa puede comenzar esa prueba de QA, que pasa por esta transición de QA de inicio Es exactamente el mismo proceso. Entramos aquí a la transición, venimos a restringir la transición, agregar una regla, restringir quién puede moverla. Esta vez, en lugar del grupo de desarrolladores, vamos a restringirnos al líder de QA. Agrega eso. Siga adelante y actualice este flujo de trabajo. Y ahora podemos llevarles ese trabajo que está en revisión de código, prepararlo para QA, pero solo nuestro QA podrá llevarlo a pruebas. Entonces veamos cómo se ve esto, de nuevo, cuando estamos conectados como nuestro desarrollador aquí, Ethan, así que digamos, bien, está en revisión de código, ha sido aprobado Entonces eso significa que está listo para QA. Ethan puede llevarlo a estar listo para QA, pero entonces no se puede aprobar y sacar de eso listo para QA, ¿verdad Excepto, sí lo tenemos establecido, creo que eso es por esta transición aquí mismo. Sí. Entonces, aunque tenemos esta transición aquí, tenemos esta configuración para cualquier estado. Entonces, si quisieras eliminar eso, simplemente podríamos entrar, presionar Eliminar, actualizar ese flujo de trabajo. Entonces ahora la única manera de llegar a hacer es a través de QA, así que si volvemos a estar conectados como nuestro desarrollador aquí, tire de esto, ya no podemos llevarlo al estado De. La única manera de hacerlo es a través del equipo de QA, lo que significa que estamos loguados, vamos a cambiar nuevamente a estar logueado como Maxwell aquí, estar conectado como Maxwell, esto está listo para QA, y él puede seguir adelante y llevarlo a las pruebas de QA Sí, bien, está listo para las pruebas de QA. Y luego una vez que haya terminado, puede completar las pruebas de UA, y ese elemento de trabajo estará completamente terminado pasando por todo ese flujo de trabajo. Entonces, para recapitular lo que aprendimos en esta lección, aprendimos a restringir una transición de ciertos usuarios en función del grupo del que el usuario forma parte Y hay tantas más formas en las que podemos agregar complejidad a esto si quisiéramos. Incluso podemos agregar una regla secundaria a esto si quisiéramos, digamos, tal vez restringir una transición de alguien que está en el grupo de desarrolladores, y también alguien que estaba en un grupo de QA, cosas así. Ahora, te animo a crear un flujo de trabajo de prueba y empezar a jugar con las reglas de transición de restricción en los flujos tu lado para ver cómo puedes usarlas para tu propio beneficio. Y cuando estés listo, te veré en la siguiente lección donde aprenderemos sobre otro tipo de regla para nuestras transiciones, solicitar entrada. Nos vemos ahí. 5. Cómo agregar reglas de entrada de solicitud: En la última lección, nos fijamos en la regla de transición de restricción. En esta lección, veremos el segundo tipo de entrada de solicitud de regla de flujo de trabajo. Solicitar entrada aparece una pantalla durante una transición que le pide al usuario que complete campos específicos antes de que continúe la transición. En lugar de simplemente mover el elemento de trabajo de una talla a otra, Jira hace una pausa y dice: Oye, antes de ir más lejos, necesito que llenes algunas cosas Y esto es útil cuando queremos recopilar datos en el momento exacto en que ocurre una transición entre estados Entonces aquí está nuestro escenario para esta lección. Cuando alguien mueve un elemento de trabajo de QA done del estado de prueba de QA a hecho, eso usa la transición de QA completa. Queremos asegurarnos de que el campo de versiones fijas se complete para que sepamos qué versión de nuestro código contiene esa corrección. Podríamos esperar que la gente recuerde configurarlo, pero un mejor flujo de trabajo es usar la entrada de solicitud para avisarles de inmediato cuando estén completando ese trabajo para completar ese campo. Así que volvamos al editor de flujo de trabajo y obtengamos esa configuración. Después de las pruebas de QA, para poder hacerse, como cabría esperar, eso necesita vivir en esta transición completa de QA. Entonces, entremos aquí a la transición de QA completa y luego entremos a solicitar entrada, agreguemos una regla de entrada de solicitud. Ahora tenemos que decirle a Jira qué pantalla mostrar. Entonces sólo hay una cosa aquí. Podemos mostrar una pantalla, seleccionarla. ¿Qué pantalla queremos mostrar? Ahora, podemos sacar de cualquiera de las otras pantallas. Se puede ver que hay un montón de pantallas diferentes que he configurado mi lado en mi instalación de Jira Pero si no tenemos una pantalla ya creada, es posible que queramos entrar y crear una nueva pantalla. Entonces voy a hacer eso, y eso abrirá una nueva pestaña. Ahí vamos. Ahora vamos a subir a agregar pantalla. Y dar un nombre. Nombrar siempre es bueno. Entonces esto va a ser para nuestra completa transición de QA. Solicitar entrada para versiones fijas. Ahí vamos. Darle una descripción si queremos. Pero voy a pegarle en add. Ahora tenemos nuestra pantalla creada. Podemos cerrar esta pestaña que nos llevará de vuelta a nuestro editor de flujo de trabajo. Y encontremos eso. Entonces era algo con versiones fijas. Ahí vamos. Encuentra esa pantalla, agrega eso a nuestra regla. Y ahora, siempre que algo venga de las pruebas de QA y esté listo para hacerse, mostrará esa pantalla, por supuesto, tan pronto como actualicemos nuestro flujo de trabajo. Entonces hagámoslo. Ahora que nuestro flujo de trabajo está actualizado, entremos y veamos cómo es esto del otro lado. Así que tenemos que iniciar sesión como Maxwell. ¿Quién es nuestro líder de QA, verdad? Porque recuerden, configuramos esa restricción donde Maxwell es el único que puede hacer eso Así que tan pronto como se hace con las pruebas de QA, está listo para ser completado. Ahora cuando lo pongamos a Dunn, va a aparecer esta transición Pero espera, ¿dónde está nuestro campo? De hecho olvidé un paso. Volvamos y cancelemos fuera de esto. Entonces no va a mover esa transición. Eso es algo que es importante tener en cuenta. Si cancelas fuera de eso, no va a completar esa transición. Y volvamos a subir a nuestra pantalla aquí. Esta es una gran manera de mostrar cómo podemos ajustar esto después del hecho. Así que encontremos nuestra pantalla. Va a ser la pantalla de la versión fija aquí. Olvidamos agregar en el campo real que queremos que se agregue en esta pantalla. Entonces ahora mismo, no hay nada configurado para esta pantalla. Por eso no mostró nada. Así que entremos y agreguemos versiones fijas. Ahí vamos. No hay salvamento ni nada por el estilo. Ya se salvó. Y como ya lo tenemos configurado en nuestro flujo de trabajo, volvamos a nuestro editor de flujo aquí solo para demostrar que ya está configurado. Era nuestro flujo de trabajo de desarrollo de software, este de aquí. Entonces ya se debería configurar eso una vez que esté en QA completo, Sí Bien, esa pantalla está apareciendo, y esa pantalla ahora tiene ese campo. Entonces, si volvemos a estar conectados como Maxwell, toma este artículo de trabajo y lo completamos, ya está hecho Y ahora, tenemos ese campo de versión fija. Por supuesto, parece que no tengo ninguna versión realmente aquí en este espacio. Así que entremos a nuestros lanzamientos. Esas son las diferentes versiones. Sí, en estos momentos no tenemos ningún comunicado aquí. Y parece que Maxwell no tiene los permisos para crear realmente uno. No es gran cosa. Volvamos a entrar como nuestro administrador y crear una nueva versión aquí. Así que voy a volver al espacio de desarrollo de software, entrar en las versiones, y ahora podemos crear una versión. Entonces digamos, Bien, esta es la Versión 1.0 de nuestro software. Guarde eso. Eso ha sido creado. Y luego ahora con Maxwell, si actualizamos la página, verá aparecer esa versión. Ahí vamos. Y luego de vuelta al elemento de trabajo, una vez hecho en las pruebas de QA, podemos completarlo, aparecerá nuestra pantalla, y verá esa versión fija con la que puede asociar eso, agregar cualquier tipo de comentario que quiera, actualizarlo. Y ahora ese ítem de trabajo pasará al estatus De. Una especie de recapitulación En esta lección, aprendimos que la regla de entrada de solicitud aparece una pantalla durante una transición. Aprendemos a dónde ir para agregar campos a nuestra pantalla. Incluso miramos a dónde ir para configurar una nueva versión en nuestro espacio, así que aparece en el campo de versiones fijas. Por supuesto, esa pantalla puede incluir los campos que queramos. E incluso podemos llevar eso al siguiente nivel controlando qué campos se requieren en nuestras pantallas usando un esquema de configuración de campo. En realidad, hablando de requerir cosas, pasemos a nuestro siguiente video donde podemos aprender cómo básicamente podemos configurar ese escenario exacto con la regla de validar detalles. Y aprenderemos todo sobre eso en nuestra próxima lección. 6. Validación de Transiciones: En la última lección, utilizamos entrada de solicitud para solicitar a los usuarios datos durante una transición. En esta lección aprenderemos a usar la regla de validar detalles. La regla de validar detalles solía llamarse validadores en versiones anteriores de Jira, y verifica que los datos requeridos existan antes permitir que continúe esa transición Pero a diferencia de la entrada de solicitudes, que incita al usuario a completar los datos faltantes, los validadores adoptan una postura más estricta Si la validación falla, la transición se bloquea por completo y el usuario ve un mensaje de error. Piénsalo de esta manera. Solicitar entrada detiene al usuario y dice: Oye, rellena esto antes de continuar. Validar detalle dice, No, no se puede continuar hasta que complete estos pasos. Entonces aquí está nuestro escenario para esta lección. Vamos a construir sobre lo que hicimos en la última lección donde agregamos en una pantalla que permitió a un usuario rellenar el campo de versiones fijas, ¿verdad? Pero en lugar de solo solicitarlo durante la transición, como hicimos con la entrada de la solicitud y luego esperar que se llene, lo que vamos a hacer es bloquear esa transición si en realidad no se llena Entonces, agreguemos un validador en la transición qa completa que verifica para asegurarnos de que ese campo esté lleno antes de que permita que continúe Así que saltando a la edición del flujo de trabajo aquí, bajo la entrada de la solicitud, tenemos los detalles de validación Y en este caso, queremos asegurarnos de que el campo de versiones fijas esté lleno. Entonces cuando entramos a validar los detalles regla, agrega eso en. Hay un montón de ellos que podemos hacer aquí. En este caso, queremos validar un campo porque como vimos en el último video, las versiones fijas es un campo. Entonces queremos validar ese campo, seleccione esto ahora necesitamos decirle a Jira cómo queremos validar el campo ¿Queremos asegurarnos de que tiene un solo valor en lugar de múltiples valores? ¿O queremos asegurarnos de que coincida con una expresión? A lo mejor el resumen del ítem de trabajo comienza con las mismas palabras y cualquiera que sea esa expresión. En este caso, sin embargo, queremos asegurarnos de que el campo no esté vacío en absoluto. Tiene datos en él. Ahora tenemos que decirle a Jira, Bien, cuando se quiere validar que un campo no está vacío, ¿qué campo? Bueno, en este caso, queremos que sea el campo de versiones fijas, el que agregamos antes, ¿ verdad? Entonces este de aquí. Y podemos dejar en blanco el mensaje de error, que va a agregar uno predeterminado, o podríamos agregar en nuestro mensaje de error personalizado si esto falla. Digamos, primero es necesario agregar una versión fija. Ahí vamos. Adelante y agrega esto. Ahora bien, aquí hay un punto importante porque el orden de estas reglas importa, ¿verdad? Así que en realidad corren de arriba a abajo. Entonces, debido a que tenemos la entrada de solicitud antes de los detalles de validación, esto aparecerá en la pantalla que permitirá al usuario agregar el campo de versiones fijas usando la pantalla que configuramos en el último video. Si hacen eso, esta validación validará si hay o no datos en ese campo. Por lo que tienen la oportunidad de agregar datos a ese campo antes de que intente completar esa transición. Si no hacen eso, aparecerá ese mensaje de error y dirá, eso necesita ser llenado. Ese campo no puede estar vacío. Así que actualicemos nuestro flujo de trabajo y veamos esto en acción. Voy a actualizar el flujo de trabajo, así que ya está en vivo. Y luego entremos a estar logueado como Maxwell. Recuerda, él es nuestro líder de QA, y restringimos las transiciones. Entonces queremos asegurarnos de que esto se lleve al QA, aunque en realidad, primero necesitamos iniciar sesión como Ethan porque tiene que pasar por revisión de código Recuerda, este es el proceso que tenemos desde en curso, tiene que ir a revisión de código. Y luego a partir de la revisión de código, una vez que se aprueba a través revisión de código, entonces está listo para A. ¿Bien? Entonces ahora que está en QA, podemos iniciar sesión como Maxwell en nuestro equipo qua. Está listo para el control de calidad. Bien. Y es en pruebas de QA. Ahora que se hace a través de pruebas de QA, bien, está terminado, está hecho. Podemos entrar aquí y podemos agregarlo a nuestra versión fija. O si solo entramos aquí y tratamos de actualizar esto va a decir, no, hay que sumar. Necesitamos agregar primero una versión fija. Ese es el mensaje de error que le dijimos que nos diera en ese validador Ese es nuestro validador trabajando aquí mismo. Pero en cuanto entremos aquí y agreguemos datos a este campo, vigile lo que sucede. Voy a poder actualizar esto porque esos datos han sido validados en el back end. Una vez más, en el flujo de trabajo, esa es esta regla de validar detalles entrando aquí y diciendo que está revisando este campo. Si no está vacío, básicamente, tiene datos ahí, le permite pasar, y cuando no nos dio este mensaje de error aquí mismo. Entonces, para recapitular, la regla de validar detalles verifica que se cumpla cualquier validación que configuremos para que se complete la transición Cuando falla la validación, la transición se bloquea y el usuario ve un error. Por supuesto, podemos usar cualquier campo más allá del campo de versiones fijas. Y como vimos cuando configuramos la regla, podemos hacer incluso más que validar los propios campos Pero ojalá, los engranajes estén empezando a girar para saber cómo puedes usar esto en tus propios flujos de trabajo. Entonces te animo a tomarte un tiempo entre clases, para probarlo de tu lado y empezar a jugar con algunas de las diferentes reglas para ver cómo pueden ayudar en tu organización. Tenemos un tipo más de regla que mirar. Entonces, en nuestra siguiente lección, pasaremos a aprender cómo podemos construir sobre esto aún más realizando acciones en nuestras transiciones de flujo de trabajo. Nos vemos ahí. 7. Realizar acciones: En esta lección, aprenderemos sobre el cuarto tipo de regla de flujo de trabajo que realiza acciones. Ahora bien, esta es un poco diferente cualquiera de las otras reglas que hemos visto hasta ahora porque suceden al final después todas las otras reglas hayan completado con éxito, y en realidad no están validando nada Si has usado versiones anteriores de Jira, estas solían llamarse funciones de publicación Entonces son diferentes porque en realidad no están decidiendo si la transición puede ocurrir o no. Ellos son el equipo de limpieza que sucede después de que todo ya ha sido validado Hacen cosas como actualizar campo y asignar usuarios, cosas así Entonces aquí está nuestro escenario para esta lección. Después de que nuestro elemento de trabajo pase con éxito al estado listo para el control de calidad, asignémoslo automáticamente a nuestro líder de QA, Maxwell De esa manera, recibirá una notificación del trabajo que se le está asignando, y sabe que está listo para comenzar a probar. Entonces, vamos a meternos en Jira y preparémoslo. Lo que queremos hacer es una vez que pase de la revisión del código a listo para el control de calidad, eso significa que tenemos que aplicarlo a esta transición aprobada aquí mismo. Entonces, bajo transición aprobada, selecciónala, desplázate hacia abajo, realiza acción. Vamos a realizar regla de acción. Y hay un par de maneras diferentes en las que podemos hacer esto. Podríamos entrar y actualizar un campo de elemento de trabajo porque el cesionario es un campo que podríamos Pero eso es algo tan común que Alasian realmente ha salido a la superficie que para aparecer Así podemos asignar un elemento de trabajo sin tener que excavar en todos los diferentes campos. Así que vamos a seleccionar eso. Y ahora tenemos que decirle a Jira a quién queremos asignarle esto, o alternativamente, podríamos despojar a cualquier cesionario que esté Si quisiéramos hacer eso, podríamos despojarnos de eso aquí mismo. Si ya estaba asignado a alguien, podríamos simplemente retirar a ese cesionario en este punto de la transición Para nuestro escenario de hoy, entremos aquí y escojamos nuestro líder de control de calidad. Ese es Maxwell. Agrega eso. Bien, entonces después de que se ejecute esta transición, la acción al final es asignar el elemento de trabajo a Maxwell Carter Así que actualicemos nuestro flujo de trabajo para ver esto en acción. Todo bien. Así que vamos a entrar como nuestro desarrollador, Ethan, ¿verdad? Entonces tomemos aquí uno de estos elementos de trabajo. Digamos que solo esta de aquí. Digamos, Bien, de hacer a en progreso. Y luego a partir de que esté en progreso, está listo para la revisión del código. Después de la revisión del código, se aprueba y se envía a QA. Observe lo que le sucede al cesionario cuando es aprobado y enviado a QA. Ahí vamos. Se le asignó a Maxwell Carter. Y ahora Maxwell Carter puede llevarlo por el resto del camino, porque, de nuevo, inició sesión como Ethan, no puede pasar y realmente moverlo más allá Lo está llevando tan lejos como puede llevarlo. Ahora le toca a Maxwell Carter, y se le asigna. Para entrar aquí y comenzar las pruebas de control de calidad y ejecutarlo a través del resto del flujo de trabajo que ya hemos configurado. Ahora, una cosa a tener en cuenta, igual que el resto de nuestras reglas, las acciones van de arriba a abajo. Entonces, si tenemos otra acción aquí, si tuviéramos que entrar y decir, también queremos actualizar uno de los campos, podríamos seleccionar uno de estos campos. Digamos, voy a añadir en la descripción, algo así. Si queremos actualizar ese campo, el orden importa, ¿verdad? Entonces, si tuviera que tomar esto y arrastrarlo arriba, ahora esto va a tener lugar antes de que esto se asigne. Ahora bien, en este caso, y este pequeño escenario que configuré, la descripción que se está actualizando pasando antes de que se le asigne, eso no va a cambiar nada realmente. Pero es importante tener en cuenta porque si estás empezando a actualizar campos y estás ejecutando esta secuencia de diferentes acciones que se están realizando, este orden sí importa. Entonces puedes hacer clic y arrastrar para reasignar o actualizar ese orden en la pila, esencialmente, ¿verdad Entonces todo corre secuencialmente de arriba a abajo. Y en cualquier momento puedes entrar aquí y eliminar esas reglas si quieres con el fin aclarar cualquier acción que no quieras en eso. Entonces, para recapitular, en esta lección, aprendimos a agregar acciones al final de nuestra transición de flujo Algunos casos de uso clásicos y más comunes para esto incluyen la asignación automática que miramos aquí, pero también hacer cosas como establecer valores de campo, borrar campos por completo o tal vez copiar valores de campo por completo o desencadenar un agente de IA o webhook Hablando de agentes de IA, pasemos a nuestra siguiente lección donde tomaremos unos momentos para ver cómo podemos usarlos con nuestras transiciones. ¿Te ves ahí? 8. Cómo activar los agentes de IA: En la última lección, miramos la regla que realiza acciones después de que se completa una transición. En esta lección, nos basaremos en eso analizando cómo activar los agentes de IA. Ahora, activar un agente de IA no es una regla de la misma manera que las otras reglas que hemos visto hasta ahora en el nivel raíz de esas reglas En cambio, está enclavado bajo las acciones de realizar. Ese es el mismo lugar al que fuimos a asignar automáticamente un elemento de trabajo después de que haga la transición, excepto que en lugar de asignar automáticamente un elemento de trabajo, esta vez, vamos a activar un agente de IA para que mire el elemento de trabajo y luego haga algo basado en cualquier mensaje que le proporcionemos Estoy seguro de que no sorprende que cuando estamos activando la IA, eso tiene algunas de sus propias advertencias dependiendo de qué versión de Jira estés usando Tienes que tener habilitado a Rovo en tu instancia de Jira para que esto funcione Rovo es la plataforma de IA de Atlassian que impulsa la infraestructura de agentes, los agentes, los créditos, la conexión con los flujos de trabajo de Jira y todo La buena noticia es que Rovo se incluye automáticamente con los planes pagados de Jira Cloud, premium estándar y enterprise Entonces no hay licencia por separado para comprar. Ahora, en mi caso, estoy usando una licencia estándar de Jira Cloud sin nada extra Así que aquí está nuestro estándar para lo que usaremos la IA en esta lección. Cuando alguien envía un trabajo para revisión de código, queremos que el agente de IA ejecute automáticamente un análisis de primera pasada sobre el elemento de trabajo para nosotros, sugiera cualquier cambio que pueda necesitar hacerse en ese elemento de trabajo para que cada vez que alguien venga a comenzar a revisar el código, tenga una ventaja inicial Entonces, vayamos a Jira y comencemos por ir a la transición donde queremos que realmente suceda esta acción Esa es esta transición aquí mismo, envíelo para revisión porque cuando trabajo pasa de estar en progreso a revisión de código, tiene que pasar por este envío para transiciones de revisión. Entonces, bajo la transición por aquí en el lado derecho, tal como lo hemos hecho antes, agreguemos una regla de realizar acciones. Y esta vez, vamos a agregar una acción de agente desencadenante. Ahora tenemos que decirle a Jira qué agente queremos usar. Ahora bien, estos son los agentes preinstalados que vienen con Rovo Tenemos un agente de codificación, agente de entrega o un agente de triaje, pero algunos agentes solo están disponibles en premium o enterprise Aquí es realmente donde su nivel de plan puede marcar la diferencia. También puedes instalar agentes adicionales o incluso crear tu propio agente personalizado si quieres. Pero para nuestro caso de uso hoy, queremos usar el agente de triaje Su trabajo es leer el ítem de trabajo y luego trializarlo, averiguar cuál es la prioridad más alta y qué necesita atención primero Ahora, tiene un conjunto predeterminado de comandos. Podríamos simplemente agregar esto si queremos, pero podemos personalizarlo agregando en nuestro propio prompt. Entonces aquí hay una indicación de que tengo que analizar el elemento de trabajo para la preparación de revisión de código, ya que eso es pasar a la revisión de código, sugerir una prioridad basada en la descripción, marcar cualquier elemento de trabajo relacionado o duplicado, podría encontrar y anotar si la descripción tiene suficiente detalle para que un revisor comience su Y entonces esto nos va a dar un comentario sobre el ítem de trabajo con sus hallazgos para ayudar a nuestro equipo a obtener una ventaja. Sigamos adelante y agreguemos esto. Ahí vamos. Ahora necesitamos actualizar nuestro flujo de trabajo, y luego entrar en Jira, iniciar sesión como uno de nuestros desarrolladores, iniciar sesión como Ethan aquí Entonces, escojamos uno de estos elementos de trabajo. De hecho voy a tomar esta columna de estado, moverla por aquí solo para que sea un poco más fácil de ver. Cuál es el trabajo real al lado del estatus. Entonces no estamos tirando de uno de estos con los que ya hemos trabajado en este tribunal que ya está hecho. Digamos, bien, digamos que esta compilación de entradas API. Digamos que queremos empezar a trabajar en esto. Está en progreso. Ethan está trabajando en ello. Y ahora, bien, está listo para su revisión. Antes de que realmente hagamos esto, quiero abrir esto para que podamos ver en este ítem de trabajo, no hay nada en el elemento de trabajo en sí. Es más o menos solo el resumen. Se puede ver que no hay descripción. No hay comentarios, nada de eso. Pero si tuviera que tomar esto y someterlo a revisión, mira lo que pasa. inmediato, va a empezar a activar a este agente, ¿no? Los agentes van a empezar a pasar por el proceso. Va a pasar por ese prompt que agregamos. Entonces solo le damos un momento para que pase por el proceso. Y por supuesto, lo estamos viendo en realidad hacer esto. Normalmente, cuando haces la transición de algo, simplemente sucede en la parte de atrás, en realidad no estamos viendo que pasó, y ahí vamos. Aquí están las cosas con las que volvió y recomendó. Dice: ¿Queremos vincular este otro ítem de trabajo? Encontró un elemento de trabajo similar. ¿Éste porque está hablando de los endpoints API? Hm. Esto en realidad podría estar relacionado con este ítem de trabajo, así que podríamos querer vincularlo aquí dentro de Jira De hecho, podríamos querer cambiar esto en lugar de una idea en este momento. Esto es una idea, tipo de trabajo aquí mismo. Y los agentes diciendo: De hecho, tal vez quieras cambiar esto a una tarea porque parece que en realidad estamos trabajando en esta tarea, ¿verdad? El contenido está describiendo una tarea más que una idea de alto nivel. Y ahora mismo, está diciendo, Oh, en realidad, Ethan, estamos conectados como Ethan. Él es el que está haciendo esto. Podríamos querer cambiar al cesionario de ser asignado a Dan a ser asignado realmente a Ethan, ya que es él quien está haciendo el trabajo Y ahora podemos entrar y decir, ¿queremos realmente aceptar esto? ¿Queremos refinar, lo que abrirá una ventana de chat de Rovo donde podamos platicar con Rovo y tal vez refinar algunas de estas sugerencias O podemos emparejar esto con algunos de los otros roles que hemos visto asignándolo automáticamente a alguien en nuestro equipo antes de que llegue a este agente de triaje, y luego tal vez posicionar al agente de IA debajo de él en nuestra transición y agregar algo en nuestro aviso para ver si el trabajo que han sugerido ha sido encajado o no sugerido ha sido encajado con el otro trabajo que ya les han asignado en el espacio. Se puede empezar a ver lo poderoso que puede ser esto. Pero siempre ten en cuenta que este agente hace recomendaciones como esta. No va a hacer cambios automáticos. Un humano todavía tiene que entrar y revisar si acepta o no todos estos cambios o no. No, vale la pena mencionar que en nuestro espacio de demostración, solo tenemos un puñado de artículos de trabajo. Realmente no había ninguna descripción ni nada más que el agente de triaje vaya a mirar para agregar un comentario o algo así a nuestro elemento de trabajo porque realmente no tenemos mucho en este elemento de trabajo Normalmente, cuando estás trabajando en algo, tendrías mucha más descripción de lo que realmente es este trabajo. Pero podemos aceptar estos cambios, y entonces el agente va a pasar por el proceso de actualizarlos realmente. Y podemos ver que ha sido asignado, ha sido vinculado. Parece que no fue capaz actualizar una cosa por un problema. O puedes pasar por ese proceso. Parece que lo único que no pudo hacer fue cambiar el tipo de trabajo, lo cual no es gran cosa. Podemos entrar aquí y actualizarlo muy rápidamente aquí mismo. Y luego podríamos responder y charlar para abrir esa ventana de chat con IA para intentar arreglarlo o simplemente podríamos descartarlo para cerrar Para que veas como eso muy rápidamente nos ayuda a organizarnos más y a triazar aún mejor nuestro trabajo Ahora lo último que quiero señalar antes de concluir esta lección es que aunque usamos uno de los agentes preinstalados, ese agente de triaje que viene con Rovo, el ecosistema de agentes agente de triaje que viene con Rovo, en Jira se extiende mucho más allá Si volvemos a entrar, incluso podríamos agregar otro si quisiéramos. Entonces se puede ver, de nuevo, con el orden de apilamiento que importa, así éste iría por debajo del que ya agregamos. Y si quisiéramos agregar un agente diferente, o si entramos aquí y miramos todos los diferentes agentes que tenemos, puedes ver que hay un montón de agentes diferentes. Algunos de ellos se basan en la licencia. No está disponible para mi licencia actual. Pero puedes empezar a ver un montón de diferentes agentes que tenemos de muchos proveedores diferentes, ¿verdad? Entonces muchos de estos son de Atlassian para hacer cosas específicas Pero hay algunos de tal vez GitHub o un Cloud Agent para Jira Podemos integrar eso directamente en Jira muy, muy rápidamente Y por supuesto, si ninguna de las opciones preconstruidas se ajusta a nuestras necesidades, podemos entrar Podemos crear nuestro propio agente dentro del estudio Rovo para hacer realmente lo que queramos Entonces, para recapitular, la regla de acción del agente desencadenante nos permite ejecutar un agente de IA automáticamente cuando un elemento de trabajo realiza una transición entre estados Y en esta lección, aprendimos cómo podemos configurarlo usando el agente de triaje preinstalado para analizar elementos de trabajo y luego sugerir algunos cambios Pero nuevamente, como vimos, en realidad no hace esos cambios hasta que los aprobemos, y luego pasará e implementará todos esos cambios. Una última cosa a tener en cuenta, dependiendo del agente de IA que estemos usando, pueden consumir créditos de Rovo cada vez que ejecuten Ahora, cada plantier de Jira Cloud viene con asignación de crédito mensual Por lo tanto, siempre es una buena idea verificar asignación de crédito de sus planes cuando esté probando agentes de IA, y tenga en cuenta a qué transiciones los adjuntamos para que no quememos los créditos inesperadamente. Ahora, en nuestra siguiente lección, daremos un paso atrás del editor de flujo de trabajo y veremos el panorama general, creando un segundo flujo de trabajo y vinculando todo con un esquema de flujo de trabajo. Nos vemos ahí. 9. Conecta flujos de trabajo con esquemas de flujo de trabajo.: En esta lección, aprenderemos cómo podemos usar esquemas de flujo de trabajo para unir múltiples flujos de trabajo. Eso también significa que necesitaremos otro flujo de trabajo. Entonces aprenderemos a crear un nuevo flujo de trabajo, también. Pero comencemos por obtener una comprensión sólida de lo que es un esquema de flujo de trabajo. Básicamente, un esquema de flujo de trabajo es un mapa que le dice Jira qué flujo de trabajo es utilizado por qué tipo de trabajo dentro de un espacio Por ejemplo, un esquema de flujo de trabajo podría decirle a Jira que use el flujo de trabajo de desarrollo de software que hemos estado usando a lo largo este curso para las ideas y tareas en nuestro espacio Pero tal vez queremos que Jira use un flujo de trabajo completamente diferente para los errores en nuestro espacio de desarrollo de software Para ver eso en acción, necesitaremos otro flujo de trabajo más allá de lo que hemos estado usando hasta ahora. Así que comencemos por crear un flujo de trabajo sencillo para nuestros libros. Voy a cerrar el editor de flujo de trabajo que hemos estado usando. Y en nuestro flujo de trabajo en el área administrativa, entremos. Esto está en realidad dentro de la configuración del espacio. Así que voy a entrar en nuestra configuración administrativa global general de Jira y luego entrar en los flujos Y luego entremos y agreguemos un flujo de trabajo. Vamos a crear un nuevo flujo de trabajo. Dale un nombre a esto. Entonces este será nuestro flujo de trabajo de errores. Para el tipo de trabajo de error, crea eso. Todo bien. Entonces esto ha sido creado. Esto es solo un flujo de trabajo muy simple. Vamos a entrar, y vamos a hacer esto rápidamente porque ya hemos mirado cómo agregar estados Pero voy a agregar en los mismos estados predeterminados que teníamos antes Entonces, en lugar de crear otros nuevos, solo vamos a agregar algunos muy simples hacer en progreso, reutilizando estados que hemos usado antes y Ahí vamos. Y luego en lugar de estar abierto cuando se crea un nuevo trabajo, tomemos eso para hacer, y podemos eliminar el estado abierto. Bien. Entonces, básicamente, lo que hemos creado muy rápidamente es un nuevo flujo de trabajo que es exactamente el mismo que el flujo de trabajo cuando iniciamos este curso por primera vez en el espacio de desarrollo de software. Recuerden, solo tenía esos tres estados diferentes. Y por supuesto, podríamos agregar más estados, transiciones y reglas, como lo hemos hecho con el flujo de trabajo de desarrollo de software en nuestras lecciones anteriores Pero por ahora, esto nos da lo que necesitamos para demostrar cómo un esquema de flujo de trabajo puede manejar múltiples flujos de trabajo. Así que actualicemos nuestro flujo de trabajo aquí. Ahora necesitamos vincularlo a nuestro espacio de desarrollo de software con un esquema de flujo de trabajo, porque puedes ver ahora mismo este es un flujo de trabajo inactivo, lo que significa que no se está usando en ningún lado. Así que volvamos a nuestra configuración aquí y a nuestros esquemas de flujo de trabajo. Ahora, por defecto, al igual que Jira creó un flujo de trabajo para nuestro espacio cuando lo creamos, también obtuvimos un esquema de flujo Los espacios siempre necesitan un esquema para decirle qué flujos de trabajo se utilizan. Es solo que por defecto, solo hay un flujo de trabajo en cada esquema. Déjame mostrarte a lo que me refiero. Estamos trabajando con el proyecto de desarrollo de software. Entonces este es el esquema que se está utilizando en ese proyecto. Si entramos aquí y editamos esto, así es como la mayoría de los esquemas se configuran por defecto dentro de una Jira Básicamente, si solo digo cada tipo de trabajo, recuerde el tipo de trabajo que solía llamarse tipo de problema, por lo que es posible que aún vea esa terminología en algún lugar del área administrativa. Así que cada tipo de trabajo dentro de este proyecto está utilizando el flujo de trabajo que hemos estado creando a lo largo de este curso, ese flujo de trabajo de desarrollo de software con el que hemos estado trabajando. Si quisiéramos cambiar esto y decir, ¿sabes qué? Para los errores, queremos usar un flujo de trabajo diferente, podemos entrar aquí, agregar un flujo de trabajo existente, y es por eso que queríamos crear primero el nuevo flujo de trabajo porque está buscando un flujo de trabajo existente. Agreguemos este flujo de trabajo BG. A continuación, para el tipo de emisión BG o tipo de trabajo, como se les llama ahora. Ahora, cada vez que se cree un error en el espacio que está usando este esquema de flujo de trabajo, utilizará el flujo de trabajo BG, ¿verdad? Entonces, sigamos adelante y publiquemos esto y veamos esto en acción. Ahora bien, podríamos encontrarnos un pequeño problema que va a asociar cualquier cosa, va a pasar y verificar y asegurarse de que todos los estados sean buenos Me encuentro con un problema que tal vez hemos eliminado un estado en el flujo de trabajo, pero había elementos de trabajo que estaban en ese estado. Digamos, si retiramos en progreso por cualquier motivo, y había elementos de trabajo en curso, va a decir, Oye, ¿qué quieres hacer con estos? ¿Quieres mapearlos a un nuevo estado? ¿Quieres quitarlos o no hacer ese cambio? Es solo hacérnoslo saber. En este caso, porque acabamos de configurar esto, no tenemos ningún elemento de trabajo existente en esos estados que estamos quitando, ¿verdad Le estamos agregando un flujo de trabajo. No estamos eliminando ningún flujo de trabajo de nuestro esquema. Pero si volvemos a nuestro proyecto, veamos el proyecto aquí, solo una forma rápida de volver al proyecto. Podríamos encontrarnos con un problema que necesitaremos solucionar porque no estoy seguro de si íbamos a venir aquí y crear un nuevo elemento de trabajo. No estoy seguro de si todavía tenemos bichos aquí. No, no tenemos bichos en nuestro espacio. Entonces vamos a entrar en nuestros artículos de trabajo, tipos. Y agreguemos en un tipo de trabajo. Así que queremos asegurarnos de que realmente agregamos errores, para que podamos usar errores en este espacio. Ahí vamos. Golpea Guardar. Ahora podemos usar errores en nuestro espacio de desarrollo de software, y cada vez que usemos errores, va a usar ese flujo de trabajo de errores en lugar del flujo de trabajo con todos los demás elementos de trabajo que están usando. Puedes ver la diferencia aquí, ¿verdad? Así que todos estos están usando el flujo de trabajo que hemos creado, y hemos estado trabajando a lo largo de este curso. Pero este tipo de trabajo está utilizando un flujo de trabajo diferente. Entonces veamos esto en acción. Si volviéramos a nuestro espacio aquí, entremos y veamos todos los diferentes elementos de trabajo que tenemos. Vamos a cerrar el menú solo para que tengamos un poco más de espacio aquí para ver en las columnas. Entonces estos son los elementos de trabajo con los que hemos estado trabajando a lo largo de este curso. Veamos este de aquí, ¿de acuerdo? Mira el estado, ¿verdad? Esto es lo que hemos mirado a lo largo de este curso, bloque en progreso. Una vez que esté en progreso, entonces podemos entrar aquí y podemos empezar a tomarlo. En realidad lo tenemos porque no estamos registrados como nuestro desarrollador. Si iniciamos sesión como nuestro desarrollador, como Ethan, en realidad puede tomar esto y ejecutarlo a través de los diferentes flujos de trabajo, ¿verdad? Entonces este es el flujo de trabajo que hemos configurado. Pero si este elemento de trabajo cambiara, vimos cómo podemos cambiar el elemento de trabajo en un video anterior a otro tipo. Si tuviéramos que cambiar esto de una idea a un error, mira lo que pasa. Entonces está diciendo: Bien, espera un minuto. Esto ha sido cambiado. ¿Cómo queremos mapear esto al nuevo flujo de trabajo, verdad? Bien, entonces ahora mismo, es una idea. Queremos cambiar esto para que sea un error. Y entonces va a pasar y decir: Bien, ¿cuál es el estado de eso? ¿Todo esto es bueno? Y porque en realidad estamos en el estado en progreso, todo parece estar bien. No hay problemas. Este es un simple resumen de lo que va a pasar. Va a cambiar de ser una idea a un error. Va a cambiar de estar en progreso en este flujo de trabajo a estar en progreso con este flujo de trabajo. Y ahora que está en el flujo de trabajo de Bug, ya no va a pasar por ese mismo proceso de QA que configuramos en el flujo de trabajo de desarrollo de software. Va a pasar por un proceso completamente diferente, lo que significa que simplemente puede entrar. Puede ser para hacer. Se puede hacer. No va a pasar por ese proceso de control de calidad que configuramos en el flujo de trabajo de desarrollo de software. Y el back-end de eso está en el editor de flujo de trabajo donde podemos ver déjame abrirlos uno al lado del otro aquí para que podamos ver estos dos flujos de trabajo diferentes bajo los flujos de trabajo. Tenemos el flujo de trabajo de errores. Entonces voy a abrir eso en una nueva pestaña. Voy a abrir fuera de la pantalla que se detendrá aquí pronto. Tenemos el flujo de trabajo de desarrollo de software con el que hemos estado trabajando a lo largo de este curso. Aquí vamos. Entonces este es el flujo de trabajo que fue la idea cuando se creó por primera vez. Y luego cuando lo cambiamos, cambió a este flujo de trabajo, el flujo de trabajo de errores. Eso acabamos de crear, lo que significa que no está pasando por ninguno de esos otros estados que tenemos aquí, ¿verdad En el mismo espacio, todavía se usa en el mismo espacio, pero solo se usa para el tipo de trabajo BG. Pero aquí, este flujo de trabajo se está utilizando para todos los demás tipos de trabajo dentro del espacio. Bien, entonces para recapitular. En esta lección aprendimos qué es un esquema de flujo de trabajo. Es una forma de mapear tipos de trabajo a flujos de trabajo en un espacio. También aprendimos a crear un nuevo flujo de trabajo y usar el esquema para decirle qué tipo de trabajo usar con él. Y como te imaginas, todas esas transiciones y reglas y cosas que hemos aprendido hasta ahora se incluyen con cada uno de los flujos de trabajo, por lo que podemos personalizar ese flujo de trabajo de errores aún más si quisiéramos. Ahora, en nuestra siguiente lección, vincularemos todo a procesos ágiles de nuestro equipo al ver cómo los flujos de trabajo afectan a nuestros tableros ágiles en Jira 10. Cómo usar los flujos de trabajo con los tableros Agile: En esta lección, veremos cómo los flujos de trabajo y los tableros Agile trabajan juntos, ya que ahí es donde nuestro equipo interactuará con mayor frecuencia con los flujos de trabajo todos los días a través de nuestro tablero Agile. En pocas palabras, los tableros Agile y Jira simplemente están mapeando los estados de nuestro flujo de trabajo a una pantalla de tablero visual Recuerde, cada estatus pertenece a una de tres categorías para hacer en progreso o hecho. El tablero agrupa estados por estas categorías, también, lo que se puede decir por las barras grises, azules y verdes en la parte superior Gris siendo para hacer, azul en progreso, y luego verde siendo los estados que están en la categoría hecho Ahora, veamos esto en acción. Voy a subirme al tablero ágil para nuestro espacio. Entonces entremos, y vamos a entrar en el espacio mismo. Y luego podemos subirnos al espacio usando la miga de pan solo una manera realmente rápida de llegar allí Y eso debería llevarnos al espacio general en sí. Es posible que tengamos que entrar en la vista de tablero si no nos lleva ahí por defecto, pero parece que está cargando el tablero. Bien, entonces esta es la placa Cbon que hemos instalado en nuestro espacio Ahora bien, si estás usando una tabla scrum, básicamente es el mismo proceso, excepto por, por supuesto, la diferencia entre scrum y Cbon usando sprints en tablas scrum y tableros Pero en el back-end, la forma que se conecta a los flujos de trabajo es la misma. Estas columnas están atadas a los diferentes estados para los elementos de trabajo Entonces, si entramos en la configuración del tablero, podemos ver esto en el back-end, entrar en las columnas. Y podemos ver To Do en progreso y hecho se mapean a estas diferentes columnas. Pero podemos ver que muchos de los diferentes estados que hemos creado en nuestro flujo de trabajo actualmente no están mapeados a nada Así que realmente podemos personalizar esto como queramos en la pizarra, y eso va a permitir a nuestros usuarios hacer una transición muy rápida de estados de uno a otro Así que vamos a configurar esto muy rápido. Digamos, bien, para la revisión de código, digamos que queremos agregar aquí un nuevo estado , una nueva columna, debería decir. Agrega eso en. Uy. Revisión de código. Y entonces podemos mapear ese estado a esta columna aquí. Y en realidad quiero mover esto. Entonces va a estar en progreso para revisar el código, y luego bloqueado también puede estar bajo en progreso. No va a hacer es un estado hecho. Para quar, construyamos realmente una sola columna para que A funcione. Vamos a tomar esto. Va a ser después de la revisión del código. Así que de nuevo, con Agile, vas de izquierda a derecha. Ray for A, las pruebas de QA pueden estar en la misma columna. Ahí vamos. Entonces tenemos todo configurado en el back-end mapeando los estados a las diferentes columnas Veamos cómo va a funcionar esto en la práctica. Así que volvamos a estar logueado como desarrollador, Ethan Entonces, si vamos a la junta directiva en nuestro proyecto de desarrollo de software, veremos cómo se vinculan todos estos, ¿verdad? Entonces tenemos estos diferentes elementos de trabajo que son los diferentes estados vinculados a esa columna Entonces podemos ver este de aquí, si abrimos esto, el estado es revisión de código. Pero si tuviera que cambiar esto, si tuviéramos que cambiar esto, digamos transición esto a en progreso, lo que pasa es que se va a mover en la pizarra para ahora estar en progreso. Entonces ese es el proceso básico, correcto, es cuando tomas algo y lo cambias de estar en una columna a otra, en el back-end, todo lo que Jira está haciendo es exactamente lo mismo que hemos hecho hasta ahora Está pasando por el proceso de transición entre esos diferentes estados en esos elementos de trabajo Entonces ahora que hemos cambiado la columna, el estado de este ítem de trabajo también está cambiando, ¿verdad? Entonces eso está ahora en revisión de código. En realidad es atropellado por el agente. Entonces puedes ver que pasó por el mismo agente de triaje que configuramos porque eso es parte de la transición entre esos diferentes estados Sigo pasando en la pizarra también. Solo está esperando nuestro aporte. En realidad queremos cambiar el nivel de prioridad de esto, ¿verdad? Entonces esa es la sugerencia esta vez. Sí, sigamos adelante y cambiemos el nivel de prioridad de eso. Eso va a actualizar. Incluso podemos ver en la pizarra el caliente De vuelta aquí. No sé si te das cuenta, pero aquí mismo, está diciendo que aquí hay un agente de triaje Entonces, cuando arrastramos elementos de trabajo a eso, va a activar ese agente, que significa que probablemente quieras entrar ahí y verificar y ver qué va a hacer. Nuevamente, el agente de triaje en realidad no va a hacer nada sin que un humano lo revise primero y se asegure que quiere aceptar esas recomendaciones Entonces detrás de escena, el flujo de trabajo sigue controlando todo. Todo lo que montamos sigue siendo controlado en este tablero. Incluso los esquemas de flujo de trabajo. Así que mira lo que pasa con este error. Está en progreso. Pero no podemos llevar esto a revisión de código. No podemos llevar esto a QA. Solo podemos tomar esto para hacer porque si recuerdas, cuando creamos el flujo de trabajo BG, solo tiene tres estados que hacer en progreso, que ya está en o hecho No podemos tomarlo en estos otros estados porque ese tipo de trabajo no está asociado con el flujo de trabajo que tiene esos estados ahí Entonces ahí es donde realmente puedes obtener una fina capa de control sobre no solo los flujos de trabajo en sí, qué tipos de trabajo están usando diferentes flujos de trabajo, y realmente puedes ver cómo puedes comenzar a personalizar esto para tu equipo. Entonces aquí es donde los flujos realmente pueden comenzar a ser complejos, dependiendo de cómo lo tengas configurado. Si recuerdas, establecemos algunas reglas sobre nuestras transiciones. Así que para pasar de la revisión de código a A, aunque en el back-end, tenemos múltiples estados mapeados en esta columna Cuando estamos conectados como nuestro desarrollador, como Ethan, solo puede hacer la transición al estado listo para QA, lo que significa que si tuviera que tomar esto aquí, solo puede hacer la transición a listo para QA A pesar de que aquí está en progreso, puede elegir qué estatus quiere que sea para QA, solo puede ver ese por las restricciones que tenemos porque es parte del grupo de desarrolladores, y solo los usuarios del grupo de desarrolladores pueden entrar listos para QA. Una vez que esté listo para el control de calidad, mira, eso se va a actualizar, se asignará automáticamente a MAX. Nuevamente, eso es otra cosa que configuramos en este curso fue asignar automáticamente a MAX. Ahora, si iniciamos sesión para ser asignados logueado como MAX, podemos ver este ítem aquí mismo, aparecerá por aquí. Se puede ver eso actualizado en tiempo real al estar en QA. Entonces, ahora que estamos conectados como Max como parte del equipo de QA, en realidad puede tomar esto y puede actualizarlo. Ahora, no puede llevarle esto a Dunn porque esto realmente necesita caminar y debe estar en el siguiente paso en nuestro flujo Si recuerdas que el siguiente paso en el flujo de trabajo es hacer la transición de esto a ser para iniciar QA, ¿verdad? Así que en realidad tienes que iniciar una antes de que se pueda hacer debido a cómo se configura nuestro flujo de trabajo. Entonces ahí es donde podríamos querer entrar aquí y estar como, Bien, ¿en realidad queremos solo una columna para QA o queremos una segunda columna que nos permita iniciar QA y arrastrar eso ahí para que Max no tenga que entrar y abrir este elemento de trabajo como acabamos de hacer nos permita iniciar QA y arrastrar eso ahí para que Max no tenga que entrar y abrir . Simplemente podría arrastrarlo ahora una vez que esté en el estado de pruebas de QA. Está siendo probado. No está listo para th qua. Ahora podemos arrastrarlo a Dunn porque ha recorrido ese proceso Y nuevamente, eso es todo en el back-end aquí en nuestro flujo de trabajo que está atado a las columnas en el tablero. Entonces, si quisiéramos difundir eso, podríamos hacerlo. Podríamos agregar una segunda columna si quisieras para QA. Realmente depende de lo que funcione mejor para tu equipo y cómo quieres que vaya todo esto. Por supuesto, la trampa a eso, por supuesto, es ahora como Ethan, va a ver que otra columna aparece también en su tablero, pero no va a poder arrastrar nada a ella Simplemente va a ver qué elementos de trabajo se encuentran actualmente en pruebas. En realidad no puede arrastrar eso por ahí debido a las restricciones que hemos establecido. Puedes ver que no es capaz de arrastrar eso por ahí debido a las restricciones en nuestro flujo de trabajo. Para recapitular lo que aprendimos en esta lección, estado se asigna a las columnas de tablero ágil E incluso puedes tener múltiples estados que compartan la misma columna Cuando movemos el trabajo de una columna a otra en nuestro tablero, lo que realmente estamos haciendo es hacer la transición de un estado a otro en nuestro flujo Y eso significa que todas esas reglas en nuestro flujo de trabajo también se aplican. Entonces, si tienes problemas para mover trabajo de una columna a otra, eso probablemente sea por las reglas como restricciones o validadores que aprendimos en este curso Nosotros. Eso es mucho, ¿no? Y con eso, ya casi terminamos con nuestro curso, pero me gustaría invitarte a unirte a mí para un último video donde tomaremos unos momentos para reflexionar sobre todo lo que hemos aprendido en este curso. 11. Resumen del curso: Llegaste a la lección final. En este curso, recorrimos la construcción un flujo de trabajo personalizado desde los estados básicos y las transiciones, pasando por las reglas de flujo de trabajo, los agentes de IA, y luego lo atamos todo de nuevo a nuestros tableros ágiles Déjame dejarte con las cosas principales que realmente espero que te lleves de esto. Empieza simple. No construimos un Behem de estado 30 Teníamos algunos estados que cubrían nuestras necesidades. Si no has creado un flujo de trabajo antes, comienza con lo que tu equipo realmente hace todos los días. Solo agregue complejidad cuando el flujo de trabajo demuestre que es necesario. A continuación, haga coincidir los flujos de trabajo con los tipos de trabajo. Algunos tipos de trabajo comparten ciclos de vida, como las ideas y tareas en nuestro caso, pero otros no tienen su propio flujo de trabajo, y no es necesario forzar un flujo de trabajo para que sirva a todo si los ciclos de vida para esos tipos de trabajo generalmente son diferentes. También, usa reglas para resolver problemas, no crear otros nuevos. Puede restringir la transición para controlar quién puede mover el trabajo, validar detalles para asegurarse de que los datos existen, realizar acciones , automatizar actualizaciones, solicitar entrada, recopilar datos en los momentos clave. Cada tipo de regla tiene un trabajo, pero no los apile ahí solo porque puedas. Tener un propósito para cada uno que uses. Y estar atentos a los créditos de Rovo. Usamos el agente de triaje con un aviso personalizado en una transición, y Rovo está incluido con los planes pagados de Jira Cloud, premium estándar y enterprise a partir de Por lo tanto, no hay una licencia separada de la que preocuparse, pero cada nivel del plan viene una asignación de crédito mensual por usuario, y los agentes consumen créditos cada vez que ejecutan. Así que despliégalos donde su análisis realmente agregue valor, no en cada transición. Y sigue recibiendo comentarios y actualizando tus flujos de trabajo. Modificarás esto a medida que evolucionen los procesos de tu equipo, agregarás estados cuando surjan nuevos traspasos, los eliminarás cuando dejen Pruebe los cambios antes de actualizar su flujo de trabajo para todo su equipo. La parte más difícil de construir flujos de trabajo es superar la creencia de que tiene que ser perfecto en el primer intento. No lo hace. Construye algo que funcione para hoy. Iterar cuando el equipo necesita más, y así es como terminas con un flujo de trabajo que coincide con el funcionamiento real de tu equipo Muchas gracias por acompañarme en este viaje. Ya sea un administrador de Jira, un administrador de espacios o un líder de equipo, espero que ahora tenga las herramientas y la confianza para construir flujos de trabajo que coincidan con el funcionamiento real de su equipo Gracias de nuevo por ver.