Fluxos de trabalho no Jira: crie fluxos de trabalho personalizados que combinam com a forma como sua equipe trabalha

1. Introdução ao curso: Bem-vindo a este curso sobre fluxos de trabalho do Jira. Meu nome é Dan Lefeb e, neste curso, aprenderemos como criar fluxos de trabalho personalizados que correspondam à forma como sua equipe Ao final deste curso, você poderá personalizar fluxos de trabalho para diferentes tipos de trabalho, como ideias, tarefas e bugs Cada um deles pode ter seu próprio fluxo de trabalho em seus espaços do Jira Também aprenderemos como adicionar restrições para que somente pessoas específicas possam realizar determinadas transições. Aprenderemos como validar dados antes que a transição prossiga entre dois status diferentes Também aprenderemos como automatizar tarefas com ações e agentes de IA, implantar fluxos de trabalho em seu espaço usando esquemas de fluxo de trabalho, conectar seu fluxo de trabalho a quadros ágeis e muito Este curso se concentra nos espaços gerenciados pela empresa, o que oferece controle total sobre fluxos de trabalho e esquemas Isso também significa que teremos permissões administrativas globais para poder configurar fluxos de trabalho em toda a nossa instância do Jira Agora, se você estiver usando espaços gerenciados por equipe, ainda obterá valor da maioria das lições deste curso, porque o editor de fluxo de trabalho nos espaços gerenciados pela equipe funciona da mesma forma que nos espaços gerenciados pela empresa que estamos usando ao longo deste curso. Ao final deste curso, você terá um fluxo de trabalho de status totalmente funcional com restrições, validações, ações automáticas agentes de IA implantados em Agora, antes de entrarmos no Jira, vamos conversar sobre os principais conceitos dos fluxos de trabalho do Jira, e abordaremos isso em nossa 2. Core concepts of Jira Workflows: Nesta lição, abordaremos os principais conceitos por trás fluxos de trabalho do Jira antes de entrarmos na própria interface do Jira Cada fluxo de trabalho no Jira consiste em duas partes principais: status e Os status representam onde um item de trabalho se encontra em seu ciclo de vida Os status básicos são “ Do in progress” e “pronto”. Mas podemos estendê-los criando qualquer status personalizado que quisermos, como revisão de código, pronto para controle de qualidade, teste de controle de qualidade ou bloqueado, coisas assim Com isso dito, não importa o status que criamos, cada status pertence a uma das três categorias. Essas categorias estão em andamento e concluídas. Embora não possamos criar categorias personalizadas no Jira, elas são principalmente para a própria organização de back-end do Jira , para ajudá-la a determinar o que é qualquer tipo de status personalizado que criamos Basicamente, qualquer status personalizado que criarmos ficará dentro de uma dessas três categorias, e isso determina como o Jira sabe quando fazer certas coisas Por exemplo, se algo estiver na categoria concluído , o Jira sabe que o trabalho foi concluído Não importa se você chama o status concluído ou concluído ou o que quer que chamemos de status personalizado, porque está na categoria concluído, o Jira sabe que o trabalho está concluído As transições representam a ação que move um item de trabalho de um status para outro Tecnicamente, uma transição única é um movimento unidirecional. Se quisermos alternar entre dois status, precisamos de duas transições separadas Agora, dito isso, há algumas maneiras de permitir que Jira faça a transição de status em qualquer direção, e veremos isso neste curso Mas saiba que, no back-end, se mudarmos o trabalho de “fazer” para em andamento” e depois voltar para “fazer”, tecnicamente são duas transições diferentes Um de para fazer para em andamento e, em seguida, outro diferente de em andamento, de volta para fazer. Isso é importante porque podemos dizer ao Jira que tipo de coisas queríamos fazer com cada uma dessas transições Se quisermos que o item de trabalho faça algo diferente ao passar de “ A fazer” para “em andamento”, então quando ele passa de “ em andamento” para “pronto”. Como você pode imaginar, as coisas podem começar a ficar complexas rapidamente. Portanto, é importante criar uma convenção de nomenclatura sólida para nossos status e Então, saberemos o que cada um significa e o que faz. E aqui estão algumas dicas para começar. Número um, use nomes claros e consistentes. A revisão de código é melhor do que fase de revisão ou mesmo em desenvolvimento. Isso leva ao número dois. Evite a sobreposição de significados. Se tivermos tanto em desenvolvimento quanto em andamento, isso pode ser confuso Mas, em andamento e com a revisão do código em status separados, nossa equipe saberá qual deles representa desenvolvimento ativo versus transferência E, como administradores do jure, podemos voltar a um fluxo de trabalho daqui a meses ou anos e não lembrar para que eles são usados se esses status parecerem Como uma pequena dica extra, se você ainda não o fez, comece a fazer documentação sobre nossas convenções de nomenclatura Dessa forma, se, por algum motivo, optarmos por criar status de som semelhantes, podemos consultar aqueles no futuro para saber por que escolhemos algo específico E se sua organização estiver usando ferramenta de documentação da Atlassian chamada Confluence, esse é um ótimo lugar para armazenar toda a documentação da convenção de Em terceiro lugar, mantenha as coisas simples. Não adicione vários status apenas para tentar organizar demais as coisas Adicione o mínimo necessário para começar e, nas próximas semanas e meses, receba feedback de nossa equipe sobre se acharíamos útil adicionar mais ao fluxo de trabalho, talvez adicionar mais uma ou duas coisas e ver se isso ajuda Caso contrário, remoção. Se sim, mantenha-o por perto. Quanto mais temos em nosso fluxo de trabalho, mais complexo ele fica, e não queremos que as coisas se tornem insustentáveis Agora, se você já usa o Jira há algum tempo, talvez esteja acostumado com uma terminologia antiga que mudou um pouco com as atualizações recentes Portanto, neste curso, encontraremos quatro tipos de regras de fluxo de trabalho, e os termos dessas regras foram alterados. Primeiro, temos as regras restritas de transição. Antigamente, essas eram chamadas de condições. Aqueles controlam quem pode ver e usar uma transição. Se um usuário não atender à restrição, não poderá fazer a transição entre os status seguir, temos as regras de entrada de solicitações que exibem uma tela durante uma transição que solicita que o usuário preencha campos específicos antes que a transição continue, e abordaremos isso posteriormente neste curso É como um primo mais amigável dos validadores que solicita dados em vez de bloqueá-los E então temos as regras de validação de detalhes. Esses são anteriormente chamados de validadores. Eles verificam se os dados necessários existem antes de permitir essa transição. Portanto, é mais rigoroso do que apenas solicitar informações. Por exemplo, exigir que o campo de versão fixa seja definido antes de fechar um item de trabalho. E, novamente, veremos isso mais tarde neste curso. Então, temos as regras de execução de ações. Antigamente, essas eram chamadas de funções de postagem. Eles são executados automaticamente após a conclusão da transição. Eles atualizam campos, atribuem usuários ou podem acionar agentes de IA, e veremos isso mais adiante neste curso. Agora, também há algo a se ter em mente sobre as permissões. Um usuário precisa de mais do que apenas permissões de fluxo de trabalho para mover um item de trabalho. Eles também precisam ser capazes de editar o item de trabalho em si. Portanto, ao testar restrições, use um usuário que tenha pelo menos permissões básicas de edição para esse tipo de trabalho. Então, para recapitular, os fluxos de trabalho consistem em status Cada status pertence a uma categoria que determina a aparência do quadro. As transições são ações unidirecionais entre os status, e há quatro tipos de regras que podemos ter nas Eles podem restringir quem pode fazer essa transição, podem solicitar informações durante uma transição. Você pode validar os dados antes da transição e realizar ações após a Agora, em nossa próxima lição, entraremos no Jira para que possamos converter um fluxo de trabalho padrão em um personalizado e, em seguida, começaremos a criar a partir daí 3. Configurando estados personalizados e transições: Nesta lição, entraremos no Jira e começaremos a criar nossos próprios status e transições personalizados para criar nosso fluxo de trabalho de desenvolvimento de software Primeiro, vamos ao editor de fluxo de trabalho. Agora, há duas maneiras de chegarmos lá. Podemos examinar nossas configurações de espaço. Então, podemos entrar nesses três pequenos pontos, entrar nas configurações espaciais. E isso é útil. Se já estivermos trabalhando dentro de nosso espaço específico, podemos acessar o fluxo de trabalho que o espaço está usando. Mas como essa é a primeira vez que entramos no Jira neste curso e estamos trabalhando como administradores globais do Jira, vamos examinar as configurações globais do Jira, onde podemos ver e gerenciar todos os fluxos de trabalho em toda a Assim, podemos acessar as configurações, descer aos itens de trabalho. E aqui no lado esquerdo, se chegarmos aos nossos fluxos de trabalho, isso nos mostrará todos os fluxos de trabalho que temos em nossa instância do Jira Agora estamos trabalhando com um espaço chamado desenvolvimento de software, este aqui. Portanto, esse é o fluxo de trabalho usado nesse espaço. Vamos entrar em três pontos. Desça para editar, e isso nos levará ao editor de fluxo de trabalho. Vou fechar isso apenas para nos dar um pouco mais de espaço para que possamos ver o editor aqui. Agora, aqui podemos ver os status e transições padrão do modelo Scrum Esse é o modelo que eu usei quando criei esse espaço. Temos que fazer em andamento e pronto. E então, aqui em cima, temos que começar, certo? Então, vou realmente manter pressionada a tecla Control, usar a roda do mouse para ampliar que possamos ver isso com um pouco mais de facilidade. Então, aqui temos o começo. E isso não é realmente um status, mas é o começo de quando um novo item de trabalho é iniciado, certo? Então, quando começa, ele passa por essas transições de criação, e isso diz ao Jira, quando você cria um novo item de trabalho, para onde ele vai Nesse caso, e por padrão, ele vai para isso para fazer o status. Agora, se quiséssemos mudar isso, tudo o que precisaríamos fazer é selecionar essa transição aqui e depois movê-la para um status diferente. Digamos que queremos que ele esteja em andamento. Agora, se criássemos um novo item de trabalho dentro desse espaço, ele estaria em andamento assim que atualizássemos esse fluxo de trabalho. Por que, é claro, realisticamente, isso não faz muito sentido Vamos deixar isso para fazer com esse status. E isso traz um bom ponto porque antes de passarmos pelo processo de fazer muitas alterações no editor de fluxo de trabalho, eu recomendo que você reserve um alterações no editor de fluxo de trabalho, tempo para esboçar exatamente o que precisa em seu fluxo de trabalho primeiro Então, quando você chega aqui, você já sabe o que vai fazer ou tem uma ideia de como tudo vai se conectar. Agora, se você estiver usando o confluence junto com o Jira, você pode usar seus É um ótimo lugar para fazer isso desenhando cada status e transição de uma forma muito flexível antes de entrar aqui e realmente torná-los funcionais no editor de fluxo de trabalho. Claro, você sempre pode mudar as coisas mais tarde, mas esse planejamento prévio lhe dará um bom ponto de partida. Dito isso, às vezes é útil ver como as outras equipes trabalham primeiro. Então, eu já passei pelo processo de descobrir como quero que seja esse fluxo de trabalho que estamos usando hoje Então, vamos começar adicionando nossos novos status para trabalhar, e passaremos pelo processo de criar todos eles de uma vez, e depois organizaremos tudo e conectaremos tudo junto Então, vou até aqui para ver o status do anúncio na parte superior e queremos criar alguns status Então, vamos entrar aqui e selecionar um status que já criamos em nossa instância do Jira, ou eu vou entrar aqui e começar a digitar Não, ainda não temos esse status, então vamos criá-lo. A categoria estará em andamento. E então poderíamos permitir transições do status Edi aqui, mas vou clicar em Adicionar, focar em adicionar esses status para começar e depois organizaremos tudo Então, vamos nos preparar para que o QA seja nosso próximo status. Crie isso. Novamente, a categoria estará em andamento. No status, entraremos e isso será um teste de controle de qualidade. Novamente, a categoria será alguma forma de isso estar em andamento. Vamos adicionar nosso status de bloqueio. E então vamos adicionar mais um status aqui, e vamos fazer um status de não vou fazer. E isso vai ser outra forma de fazer. Assim, teremos alguns status diferentes na categoria De E em vez de fazermos com que todos eles funcionem, esse trabalho está realmente concluído, se entrarmos aqui e adicionarmos um que não funcionará, se adicionarmos trabalho ao status de não fazer, poderemos voltar mais tarde aos relatórios e filtros e ver aqueles que conscientemente tomamos a decisão de que sim, isso foi realmente concluído, isso está feito ou tomamos a decisão funcionem, esse trabalho está realmente concluído, se entrarmos aqui e adicionarmos um que não funcionará, se adicionarmos trabalho ao status de não fazer, poderemos voltar mais tarde aos relatórios e filtros e ver aqueles que conscientemente tomamos a decisão de que sim, isso foi realmente concluído, isso está feito ou tomamos a decisão de realmente não faça esse trabalho por qualquer motivo. E então, no próprio item de trabalho, você adicionaria qualquer motivo pelo qual você não decidiu fazer esse trabalho. Tudo bem, agora temos nossos status criados. Vamos entrar aqui e começar a criar algumas transições. Então, nesses status que já temos, essa é qualquer transição Isso significa que os itens de trabalho no status concluído podem passar para esse status a partir de qualquer outro status. Então, se estiver em andamento, se for para fazer, se estiver em algum desses aqui, ele pode realmente fazer a transição para o status concluído a partir desse outro status. Mas talvez nem sempre queiramos isso. Então, vamos começar organizando isso criando algumas novas transições entre esses status, porque, no momento, eles estão destacados, o que significa que não há como fazer a transição para o status de revisão de código Não podemos trabalhar no status de revisão de código se não houver transição para ele. Então, vou pegar uma, digamos que, de em andamento, queremos que, em andamento, entre na revisão de código. E vamos dar um nome a esse status. É sempre uma boa ideia dar um nome a tudo. E é aqui que o pré-planejamento pode ser realmente útil, como você vai nomear as coisas Então, isso será enviado para revisão. Então, ele vai de em andamento para a revisão do código para a transição e é enviado para revisão. Para as próximas transições, diremos: Ok, quando o trabalho estiver na revisão de código, ele sairá da revisão de código e, em seguida, o prepararemos para o controle E esse status ou essas transições, devo dizer, serão chamados de aprovados, certo? Então, foi aprovado e, em seguida, passa pela revisão do código. A revisão do código é aprovada e fica pronta para o controle Agora, outro fluxo de trabalho possível para isso é que, se não for aprovado, se houver algo que precise mudar, podemos entrar e dizer: Ok, revisão de código, vamos voltar ao andamento. E essa será a transição, solicitará mudanças. Lá vamos nós. Então, esse é outro fluxo de trabalho em potencial que nossos itens de trabalho poderiam ter. E podemos reorganizar isso se quisermos que isso faça um pouco mais de sentido na forma como temos tudo isso organizado Em seguida, quando o trabalho está pronto para o status de controle de qualidade, o que acontece aqui? Ok, então pronto para o controle de qualidade neste fluxo de trabalho será basicamente o status de tarefas de nossa equipe de controle de qualidade, certo? Depois de passar pela revisão do código pelos desenvolvedores, eles revisão do código pelos desenvolvedores, estarão prontos para o controle de qualidade. E então, qualquer coisa no status de Pronto para QA, nosso líder de QA, esse usuário poderá saber: Ok, isso está pronto para começar. E então, enquanto eles estão realmente trabalhando nisso, eles podem trabalhar arrastá-lo para o teste de controle de qualidade para mostrar que o teste foi realmente iniciado. E para isso, digamos, vamos simplesmente chamar isso de início de QA. E então isso pode vir de um teste de controle de qualidade, e na verdade queremos que isso seja feito para dizer: Sim, ok, isso foi concluído Lá vamos nós. Ou, assim como fizemos com a revisão do código, se houver uma mudança que precise acontecer, podemos transformar isso do teste de controle de qualidade em andamento e dizer que isso precisa ser enviado de volta para uma correção. Lá vamos nós. E então, para esses outros dois status, certamente haverá momentos em que desejaremos fazer uma transição global de qualquer status para outro status e, a qualquer momento, queremos poder dizer que tomamos a decisão de não fazer esse trabalho Então, para isso, vamos adicionar uma transição, e isso vai ser de qualquer status para não Vá em frente e crie isso. E o mesmo com bloqueado, diremos que, a qualquer momento, qualquer trabalho pode ser bloqueado nesse fluxo de trabalho. Lá vamos nós. Portanto, criamos nosso fluxo de trabalho aqui dentro do editor de fluxo de trabalho. E agora temos nosso fluxo de trabalho pronto para começar. Em nossa próxima lição, começaremos a analisar algumas das regras que podemos adicionar ao nosso fluxo de trabalho, começando por restringir as transições 4. Como restringir transições: Nesta lição, aprenderemos sobre o primeiro tipo de regra de fluxo de trabalho que restringe quem pode executar uma transição A regra de transição restrita era anteriormente chamada de condições em versões mais antigas do Jira e controla se uma transição está disponível, com base em qualquer regra que decidirmos Provavelmente, o caso de uso mais comum para isso é restringir uma transição com base em quem é o usuário. Então, aqui está um cenário comum que aprenderemos a configurar nesta lição. Só queremos que os desenvolvedores possam enviar trabalhos para revisão de código. Então, em nossa configuração, Ethan é um desenvolvedor e está no grupo de usuários do desenvolvedor Maxwell é nosso líder de controle e não está no grupo de desenvolvedores, e queremos que Ethan possa se submeter à revisão para fazer a transição de um status para outro para o status de revisão de código, mas Maxwell não deve ser capaz de fazer a transição do status em andamento para esse status de revisão de código Então, vamos configurar isso. O que queremos fazer é usar esse envio para revisão da transição que criamos na lição anterior. Nessa transição, como esse será qualquer trabalho que venha do andamento até a revisão do código, ele precisa passar por essa transição. Vamos ver nossas regras, restringir a transição, adicionar uma regra de transição restrita. E então queremos restringir com base em quem é o usuário. Portanto, restrinja quem pode mover um item de trabalho. E podemos escolher usuários específicos, ou descobri que um fluxo de trabalho melhor é usar grupos. Dessa forma, podemos adicionar usuários ao grupo, e todas essas regras serão aplicadas automaticamente , em vez de serem apenas usuários individuais. Então, vou entrar e escolher grupos, e vamos selecionar o grupo de desenvolvedores. Isso significa que somente os desenvolvedores poderão usar essa transição para passar da versão em andamento para a revisão do código. Clique em AD, aí está. Temos isso adicionado às nossas regras aqui no lado direito. Agora, para que isso entre em vigor, precisamos atualizar o fluxo de trabalho. Então, agora, estamos basicamente em um modo de rascunho. Na verdade, não atualizamos isso. Então, para que isso se torne ativo, precisamos atualizar o fluxo de trabalho. Agora que nosso fluxo de trabalho está atualizado, vamos ver o que isso significa para nossa equipe. Então, primeiro, vou entrar como Maxwell. Isso está logado como Maxwell Carter. Ele é nosso líder de controle de qualidade, que não faz parte do grupo de desenvolvedores ao qual acabamos de adicionar essa restrição de transição Então, se entrássemos em um desses itens de trabalho que está em andamento, você pode ver que Maxwell nem consegue levar isso ao status de revisão de código porque a única maneira de fazer isso é passar por essa transição de envio para revisão que restringimos Agora, se eu fosse fazer login como Ethan, que é um dos desenvolvedores do grupo de desenvolvedores, deixe-me abrir essa janela aqui Estou logado como Ethan aqui. Agora logado como Ethan. Se examinássemos um desses itens de trabalho, veja o status. Está em andamento. Se eu retirar isso, podemos usar essa transição de envio para revisão para fazer a transição para o status de revisão de código. E lá vamos nós. Agora, Ethan pode alterar o item de trabalho para estar no status de revisão de código devido a essa transição A transição de envio para revisão só permite que as pessoas desse grupo de desenvolvedores passem por essa transição, que é a única maneira de entrar nesse status de revisão de código Mesmo status, mesmo item de trabalho, permissões de usuário diferentes. É uma maneira poderosa de impor o acesso baseado em funções em nosso fluxo de trabalho sem depender apenas de nós para lembrar quais são as regras O sistema pode aplicá-lo para nós. Alguns outros casos de uso comuns de transição restrita podem incluir coisas como talvez apenas permitir que essa transição aprovada seja liderada por líderes ou gerentes de projetos. Ou talvez, como temos uma equipe de controle de qualidade configurada, talvez somente a equipe de controle de qualidade possa realmente concluir o controle de qualidade e enviá-lo para Dunn após conclusão do teste de controle de qualidade ou talvez só possa iniciar o controle Talvez só queiramos que a equipe de controle de qualidade possa iniciar o controle de qualidade quando estiver pronta para o controle de qualidade, somente a equipe equa possa realmente iniciar o teste de controle de qualidade, que passa por essa transição inicial de controle É exatamente o mesmo processo. Chegamos aqui para a transição, viemos para restringir a transição, adicionar uma regra, restringir quem pode movê-la. Desta vez, em vez do grupo de desenvolvedores, vamos nos restringir ao líder de controle de qualidade. Adicione isso. Vá em frente e atualize esse fluxo de trabalho. E agora podemos fazer com que eles trabalhem na revisão de código prepará-lo para o controle de qualidade, mas somente nosso controle de qualidade poderá testá-lo. Então, vamos ver o que isso parece, novamente, quando estamos logados como nosso desenvolvedor aqui, Ethan, então digamos que, ok, está em revisão de código, foi aprovado Isso significa que ele está pronto para o controle de qualidade. Ethan pode substituí-lo para pronto para o controle de qualidade, mas ele não pode ser aprovado e retirado desse lugar, pronto para o controle de qualidade, certo? Exceto que estamos configurados para, acredito que seja por causa dessa transição aqui. Sim. Portanto, embora tenhamos essa transição aqui, temos essa configuração para qualquer status. Então, se você quiser remover isso, poderíamos simplesmente entrar, clicar em Excluir e atualizar esse fluxo de trabalho. Agora, a única maneira de fazer isso é por meio do controle de qualidade. Portanto, se voltarmos login como nosso desenvolvedor aqui , faça isso e não poderemos mais levá-lo ao status De A única maneira de fazer isso é por meio da equipe de controle de qualidade, que significa que estamos logados, vamos mudar novamente para estar logado como Maxwell aqui, estar logado como Maxwell, isso está pronto para o controle de qualidade, e ele pode ir em frente e levar isso para o teste de controle frente e levar isso Sim, tudo bem, está pronto para o teste de controle de qualidade. E então, quando terminar, ele poderá concluir o teste de UA, e esse item de trabalho será totalmente concluído e passará por todo o fluxo de trabalho. Então, para recapitular o que aprendemos nesta lição, aprendemos como restringir a transição de determinados usuários com base no grupo do qual o usuário faz parte E há muitas outras maneiras de adicionar complexidade a isso, se quisermos. Podemos até adicionar uma regra secundária a isso se quisermos, digamos, restringir a transição de alguém que está no grupo de desenvolvedores e também de alguém que estava em um grupo de controle de qualidade, coisas assim. Agora, eu encorajo você a criar um fluxo de trabalho de teste e começar a brincar com as regras restritas de transição nos fluxos de trabalho do seu lado para ver como você pode usá-las em seu próprio benefício E quando você estiver pronto, nos vemos na próxima lição, onde aprenderemos sobre outro tipo de regra para nossas transições, solicitação de informações. Nos vemos lá. 5. Adicionando regras de entrada de solicitação: Na última lição, examinamos a regra de transição restrita. Nesta lição, veremos o segundo tipo de entrada de solicitação de regra de fluxo de trabalho. entrada de solicitação exibe uma tela durante uma transição que solicita que o usuário preencha campos específicos antes que a transição continue. Em vez de simplesmente mover o item de trabalho de um tamanho para outro, Jira faz uma pausa e diz: Ei, antes de prosseguirmos, preciso que você preencha algumas coisas E isso é útil quando queremos coletar dados no momento exato em que ocorre uma transição entre os status Então, aqui está nosso cenário para esta lição. Quando alguém move um item de trabalho do controle de qualidade concluído do status de teste de controle de qualidade para concluído, isso usa a transição completa do controle de qualidade. Queremos garantir que o campo de versões fixas seja preenchido para sabermos qual versão do nosso código contém essa correção. Esperamos que as pessoas se lembrem de configurá-lo, mas um fluxo de trabalho melhor é usar a entrada da solicitação para preencham esse campo imediatamente quando estiverem que preencham esse campo imediatamente quando estiverem concluindo o trabalho . Então, vamos voltar ao editor de fluxo de trabalho e configurar essa configuração. Depois do teste de controle de qualidade, para ser feito, como era de se esperar, ele precisa viver dessa transição completa de controle de qualidade. Então, vamos entrar aqui para a transição completa do controle e, em seguida, entrar para solicitar uma entrada adicionar uma regra de entrada de solicitação. Agora precisamos dizer ao Jira qual tela mostrar. Então, só há uma coisa aqui. Podemos mostrar uma tela, selecioná-la. Qual tela queremos mostrar? Agora, podemos extrair de qualquer uma das outras telas. Você pode ver que há muitas telas diferentes que eu configurei do telas diferentes que eu configurei meu lado na minha instalação do Jira Mas se ainda não tivermos uma tela criada, talvez queiramos entrar e criar uma nova tela. Então, eu vou fazer isso, e isso abrirá uma nova guia. Lá vamos nós. Agora vamos adicionar a tela. E dê um nome. Nomear é sempre bom. Então, isso será para nossa transição completa de controle de qualidade. Solicite entrada para versões fixas. Lá vamos nós. Dê uma descrição, se quisermos. Mas vou clicar em adicionar. Agora, criamos nossa tela. Podemos fechar essa guia que nos levará de volta ao nosso editor de fluxo de trabalho. E vamos descobrir isso. Então, era algo com versões fixas. Lá vamos nós. Encontre essa tela e adicione-a à nossa regra. E agora, sempre que algo vier de um teste de controle de qualidade e estiver pronto para ser feito, ele mostrará essa tela, é claro, assim que atualizarmos nosso fluxo de trabalho. Então, vamos fazer isso. Agora que nosso fluxo de trabalho está atualizado, vamos entrar e ver como isso se parece do outro lado. Então, precisamos fazer login como Maxwell. Quem é nosso líder de controle de qualidade, certo? Porque lembre-se de que configuramos essa restrição onde Maxwell é o único que pode fazer isso Então, assim que o teste de controle de qualidade for concluído, ele estará pronto para ser concluído. Agora, quando configurarmos para Dunn, aparecerá essa transição Mas espere, onde está nosso campo? Na verdade, esqueci uma etapa. Vamos voltar e cancelar isso. Então, isso não vai mudar essa transição. Isso é algo que é importante ter em mente. Se você cancelar isso, não concluirá a transição. E vamos voltar para nossa tela aqui. Essa é uma ótima maneira de mostrar como podemos ajustar isso após o fato. Então, vamos encontrar nossa tela. Será a tela da versão fixa aqui. Esquecemos de adicionar o campo real que queremos adicionar nessa tela Então, no momento, não há nada configurado para essa tela. É por isso que não mostrou nada. Então, vamos entrar e adicionar versões fixas. Lá vamos nós. Não há salvamento nem nada parecido. Já está salvo. E como já o configuramos em nosso fluxo de trabalho, vamos voltar ao nosso editor de fluxo de trabalho aqui apenas para mostrar que ele já está configurado. Era nosso fluxo de trabalho de desenvolvimento de software, esse aqui. Portanto, já deve estar configurado para que , uma vez concluído o controle de qualidade, sim. Ok, essa tela está aparecendo, e essa tela agora tem esse campo. Então, se voltarmos a estar logados como Maxwell, pegarmos esse item de trabalho e o concluirmos, está pronto E agora, temos esse campo de versão fixa. Claro, parece que eu não tenho nenhuma versão aqui neste espaço. Então, vamos ver nossos lançamentos. Essas são as diferentes versões. Sim, na verdade, não temos nenhum lançamento aqui no momento. E parece que Maxwell não tem as permissões para realmente criar um. Não é grande coisa. Vamos voltar como nosso administrador e criar uma nova versão aqui. Então, vou voltar ao espaço de desenvolvimento de software, entrar nos lançamentos e agora podemos criar um lançamento. Então, digamos, OK, esta é a versão 1.0 do nosso software. Guarde isso. Isso foi criado. E agora com Maxwell, se atualizarmos a página, ele verá essa versão aparecer. Lá vamos nós. E, voltando ao item de trabalho, uma vez concluído o teste de controle de qualidade, podemos concluí-lo, abrirá nossa tela e ele verá a versão corrigida qual pode associá-la, adicionar qualquer tipo de comentário que quiser e atualizá-la. E agora esse item de trabalho passará para o status De. Uma espécie de recapitulação Nesta lição, aprendemos que a regra de entrada da solicitação exibe uma tela durante uma transição Aprendemos aonde ir para adicionar campos à nossa tela. Até analisamos onde ir para configurar uma nova versão em nosso espaço, então ela aparece no campo de versões fixas. Obviamente, essa tela pode incluir os campos que quisermos. E podemos até mesmo levar isso para o próximo nível controlando quais campos são necessários em nossas telas usando um esquema de configuração de campo. Na verdade, falando em exigir coisas, vamos passar para o próximo vídeo onde podemos aprender como basicamente configurar esse cenário exato com a regra de validação de detalhes E aprenderemos tudo sobre isso em nossa próxima lição. 6. Como validar transições: Na última lição, usamos entrada de solicitação para solicitar dados aos usuários durante uma transição. Nesta lição, aprenderemos como usar a regra de validação de detalhes A regra de validação de detalhes costumava ser chamada de validadores em versões mais antigas do Jira e verifica se os dados necessários existem antes permitir que a transição continue Mas, diferentemente da entrada de solicitações, que solicita que o usuário preencha os dados ausentes, os validadores adotam uma postura mais rígida Se a validação falhar, a transição será totalmente bloqueada e o usuário verá uma mensagem de erro. Pense nisso dessa forma. solicitação de entrada interrompe o usuário e diz: Ei, preencha isso antes de continuarmos. detalhe de validação diz: Não, você não pode continuar até concluir essas etapas Então, aqui está nosso cenário para esta lição. Vamos nos basear no que fizemos na última lição, quando adicionamos uma tela que permitia ao usuário preencher o campo de versões fixas, certo? Mas, em vez de apenas solicitá-la durante a transição, como fizemos com a entrada da solicitação e esperar que ela seja preenchida, o que vamos fazer é bloquear essa transição se ela não estiver realmente preenchida Então, vamos adicionar um validador na transição completa do QA que verifica isso para garantir que o campo seja preenchido antes de permitir que continue Então, entrando na edição do fluxo de trabalho aqui, abaixo da entrada da solicitação, temos os detalhes da validação. E, nesse caso, queremos garantir que o campo de versões fixas seja preenchido. Então, quando entrarmos para validar a regra de detalhes, adicione-a. Há um monte deles que podemos fazer aqui. Nesse caso, queremos validar um campo porque, como vimos no último vídeo, as versões fixas são um campo Então, queremos validar esse campo, selecione isso agora, precisamos dizer ao Jira como queremos validar o Queremos ter certeza de que ele tem um único valor em vez de vários valores? Ou queremos ter certeza de que corresponde a uma expressão? Talvez o resumo do item de trabalho comece com as mesmas palavras e qualquer que seja essa expressão. Nesse caso, porém, queremos ter certeza de que o campo não esteja vazio. Tem dados nele. Agora precisamos dizer ao Jira: Ok, quando você quer validar que um campo não está vazio, qual Bem, nesse caso, queremos que seja o campo de versões fixas, aquele que adicionamos antes, certo? Então, esse aqui. E podemos deixar a mensagem de erro em branco, que adicionará uma mensagem padrão, ou podemos adicionar nossa mensagem de erro personalizada se isso falhar. Digamos que você precise primeiro adicionar uma versão fixa. Lá vamos nós. Vá em frente e adicione isso. Agora, aqui está um ponto importante porque a ordem dessas regras é importante, certo? Então, na verdade, eles correm de cima para baixo. Então, como temos a entrada da solicitação antes dos detalhes de validação, isso abrirá a tela que permitirá ao usuário adicionar o campo de versões fixas usando a tela que configuramos no último vídeo Se eles fizerem isso, essa validação validará se há ou não dados nesse campo Assim, eles têm a oportunidade de adicionar dados a esse campo antes que ele tente concluir a transição. Se eles não fizerem isso, aparecerá a mensagem de erro e dirá que precisa ser preenchida. Esse campo não pode estar vazio. Então, vamos atualizar nosso fluxo de trabalho e ver isso em ação. Vou atualizar o fluxo de trabalho, então agora ele está ativo. E então vamos começar a fazer login como Maxwell. Lembre-se de que ele é nosso líder de controle de e restringimos as transições. Então, queremos ter certeza de que isso seja levado para o QA, embora, na verdade, precisemos fazer login como Ethan primeiro, porque ele precisa passar por uma revisão de código Lembre-se, este é o processo que temos em andamento, ele tem que ir para a revisão do código. E então, a partir da revisão de código, uma vez aprovado por meio revisão de código , está pronto para A. Ok? Agora que está no controle de qualidade, podemos fazer login como Maxwell em nossa equipe qua. Está pronto para o controle de qualidade. OK. E está em testes de controle de qualidade. Agora que foi feito por meio de testes de controle de qualidade, ok, está concluído, está feito. Podemos entrar aqui e adicioná-lo à nossa versão fixa. Ou se entrarmos aqui e tentarmos atualizar, isso dirá que não, precisa ser adicionado. Primeiro, precisamos adicionar uma versão fixa. Essa é a mensagem de erro que pedimos que ele nos desse validador Esse é o nosso validador trabalhando aqui. Mas assim que chegarmos aqui e adicionarmos dados a esse campo, observe o que acontece. Eu poderei atualizar isso porque esses dados foram validados no back-end Mais uma vez, no fluxo de trabalho, essa é a regra de validação de detalhes chegando aqui e dizendo que está verificando esse campo Se não estiver vazio, basicamente, ele tem dados lá dentro, permite que eles passem e, quando não nos deu essa mensagem de erro aqui mesmo. Então, recapitulando, a regra de validação de detalhes verifica se qualquer validação que configuramos foi cumprida para que a transição Quando a validação falha, a transição é bloqueada e o usuário vê um erro. Obviamente, podemos usar qualquer campo além do campo de versões fixas. E, como vimos quando configuramos a regra, podemos fazer ainda mais do que validar os campos em si Mas espero que as coisas estejam começando a mudar para saber como você pode usar isso em seus próprios Por isso, recomendo que você reserve um tempo entre as aulas, experimente do seu lado e comece a jogar com algumas das diferentes regras para ver como elas podem ajudar sua organização. Temos mais um tipo de regra a ser analisada. Então, em nossa próxima lição, aprenderemos como podemos desenvolver isso ainda mais realizando ações em nossas transições de fluxo de trabalho. Nos vemos lá. 7. Executando ações: Nesta lição, aprenderemos sobre o quarto tipo de regra de fluxo de trabalho que executa ações. Agora, essa é um pouco diferente de qualquer outra regra que analisamos até agora porque elas acontecem no final, depois todas as outras regras foram concluídas com sucesso, e elas não estão realmente validando nada Se você já usou versões mais antigas do Jira, elas costumavam ser chamadas de funções de postagem Então, eles são diferentes porque não estão realmente decidindo se a transição pode ou não acontecer Eles são a equipe de limpeza que acontece depois que tudo já foi validado Eles fazem coisas como atualizar campos e atribuir usuários, coisas assim Então, aqui está nosso cenário para esta lição. Depois que nosso item de trabalho passar com sucesso para o status Pronto para QA, vamos atribuí-lo automaticamente ao nosso líder de QA, Maxwell Dessa forma, ele receberá uma notificação de que o trabalho está sendo atribuído a ele e sabe que está pronto para começar o teste. Então, vamos entrar no Jira e configurá-lo. O que queremos fazer é uma vez que ele passe da revisão do código para o controle de qualidade, significa que precisamos aplicá-lo a essa transição aprovada aqui mesmo. Então, em Transição aprovada, selecione isso, role para baixo e execute a ação. Vamos executar a regra de ação. E há algumas maneiras diferentes de fazer isso. Poderíamos entrar e atualizar um campo de item de trabalho porque destinatário é um campo que podemos Mas isso é uma coisa tão comum que Alasian realmente apareceu para aparecer Assim, podemos atribuir um item de trabalho sem precisar vasculhar todos os campos diferentes. Então, vamos selecionar isso. E agora precisamos dizer ao Jira a quem queremos atribuir isso ou, alternativamente, podemos remover qualquer destinatário que esteja atualmente designado Se quiséssemos fazer isso, poderíamos tirar isso aqui mesmo. Se já estivesse atribuído a alguém, poderíamos simplesmente remover esse destinatário neste momento da Para nosso cenário de hoje, vamos entrar aqui e escolher nosso líder de controle de qualidade. Isso é Maxwell. Adicione isso. Ok, então depois que essa transição for executada, a ação no final é atribuir o item de trabalho a Maxwell Carter Então, vamos atualizar nosso fluxo de trabalho para ver isso em ação. Tudo bem. Então, vamos começar login como nosso desenvolvedor, Ethan, certo Então, vamos pegar um desses itens de trabalho aqui. Digamos que só essa aqui. Digamos: Ok, de “ a fazer” a “em andamento”. E então, a partir do andamento, está pronto para a revisão do código. Após a revisão do código, ele é aprovado e enviado para o controle de qualidade. Veja o que acontece com o responsável quando ele é aprovado e enviado para o controle de qualidade. Lá vamos nós. Foi atribuído a Maxwell Carter. E agora Maxwell Carter pode continuar com o resto do caminho, porque, novamente, logado como Ethan, ele não pode continuar e, na verdade, passar pelo controle Ele está levando isso o mais longe que pode. Agora cabe a Maxwell Carter, e é atribuído a ele. Entrar aqui e realmente iniciar o teste de controle de qualidade e executá-lo no resto do fluxo de trabalho que já configuramos. Agora, uma coisa a ter em mente, assim como o resto de nossas regras, as ações são executadas de cima para baixo. Então, se tivermos outra ação aqui, se entrássemos e disséssemos que também queremos atualizar um dos campos, poderíamos selecionar um desses campos. Digamos que eu acrescente na descrição algo parecido. Se quisermos atualizar esse campo, a ordem é importante, certo? Então, se eu pegar isso e arrastá-lo para cima, agora isso vai acontecer antes que isso seja atribuído. Agora, neste caso, e nesse pequeno cenário que eu configurei, a descrição sendo atualizada acontecendo antes de ser atribuída, isso realmente não vai mudar nada. Mas é importante ter em mente , se você está começando a atualizar campos e está executando essa sequência de ações diferentes que estão sendo executadas, essa ordem importa. Então, você pode clicar e arrastar para reatribuir ou atualizar essa ordem na pilha, basicamente, certo Então, tudo funciona sequencialmente de cima para baixo. E a qualquer momento você pode entrar aqui e excluir essas regras, se quiser , a fim eliminar quaisquer ações que você não queira. Então, para recapitular, nesta lição, aprendemos como adicionar ações no final da transição do nosso fluxo de Alguns casos de uso clássicos e mais comuns para isso incluem a atribuição automática que vimos aqui, mas também fazer coisas como definir valores de campo, limpar totalmente os campos ou talvez copiar totalmente os valores dos campos ou acionar um agente de IA Por falar em agentes de IA, vamos passar para a próxima lição qual analisaremos alguns minutos como podemos usá-los nossas transições. Te vejo lá? 8. Disparando agentes de IA: Na última lição, analisamos a regra que executa ações após a conclusão de uma transição. Nesta lição, vamos nos basear nisso analisando como acionar agentes de IA. Agora, acionar um agente de IA não é uma regra da mesma forma as outras regras que analisamos até agora no nível raiz dessas Em vez disso, está situado sob as ações de execução. É o mesmo lugar em que atribuímos automaticamente um item de trabalho após a transição, exceto que, em vez de atribuir automaticamente um item de trabalho, desta vez, vamos acionar um agente de IA para examinar o item de trabalho e, em seguida, fazer algo com base em qualquer solicitação fornecida Tenho certeza de que não surpreende que, quando ativamos a IA, isso tenha algumas ressalvas, dependendo da versão do Jira que você está usando isso tenha algumas ressalvas, dependendo da versão do Jira que Você precisa ter o Rovo ativado em sua instância do Jira para que isso funcione Rovo é a plataforma de IA da Atlassian que potencializa a infraestrutura do agente, os agentes, os créditos, a conexão com os fluxos de trabalho do Jira A boa notícia é que o Rovo é incluído automaticamente nos planos pagos do Jira Cloud, standard premium e enterprise Portanto, não há uma licença separada para compra. Agora, no meu caso, estou usando uma licença padrão do Jira Cloud sem nada extra Então, aqui está nosso padrão para o que usaremos a IA nesta lição. Quando alguém envia um trabalho para revisão de código, queremos que o agente de IA execute automaticamente uma análise inicial do item de trabalho sugira quaisquer alterações que precisem ser feitas nesse item de trabalho para que, sempre que alguém realmente começar a revisar o código, tenha uma vantagem Então, vamos entrar no Jira e começar indo para a transição em que queremos que essa ação realmente aconteça Essa é essa transição aqui, envie para revisão, porque quando trabalho passa de em andamento para revisão de código, ele precisa passar por essas transições de envio para revisão Então, na transição aqui no lado direito, assim como fizemos antes, vamos adicionar uma regra de execução de ações. E desta vez, vamos adicionar uma ação de agente acionador. Agora precisamos dizer ao Jira qual agente queremos usar. Agora, esses são os agentes pré-instalados que vêm com o Rovo Temos um agente de codificação, um agente de entrega ou um agente de triagem, mas alguns agentes só estão disponíveis nas versões premium ou empresarial É aqui que o nível do seu plano pode fazer a diferença. Você também pode instalar agentes adicionais ou até mesmo criar seu próprio agente personalizado, se quiser. Mas para nosso caso de uso atual, queremos usar o agente de triagem Seu trabalho é ler o item de trabalho e depois fazer a triagem, descobrir qual é a maior prioridade e o que precisa de atenção primeiro Agora, ele tem um conjunto padrão de comandos. Poderíamos simplesmente adicionar isso se quisermos, mas podemos personalizar isso adicionando nosso próprio prompt. Então, aqui está uma mensagem de que preciso analisar o item de trabalho para verificar se está pronto para a revisão de código, já que isso é passar para a revisão de código, sugerir uma prioridade com base na descrição, sinalizar quaisquer itens de trabalho relacionados ou duplicados, que ele possa encontrar e observar se a descrição tem detalhes suficientes para que um revisor comece E então isso nos dará um comentário sobre o item de trabalho com suas descobertas para ajudar nossa equipe a começar. Vamos adicionar isso. Lá vamos nós. Agora precisamos atualizar nosso fluxo de trabalho e, em seguida, entrar no Jira, fazer login como um de nossos desenvolvedores e fazer login como Ethan Então, vamos escolher um desses itens de trabalho. Na verdade, vou pegar essa coluna de status movê-la aqui para que fique um pouco mais fácil de ver. Qual é o trabalho real ao lado do status. Então, não estamos retirando um desses com os quais já trabalhamos neste tribunal que já tenha sido feito Digamos que, ok, digamos que essas entradas da API de construção. Digamos que queremos começar a trabalhar nisso. Está em andamento. Ethan está trabalhando nisso. E agora, tudo bem, está pronto para análise. Antes de realmente fazermos isso, quero abrir isso para que possamos ver neste item de trabalho não há nada no item de trabalho em si. É basicamente apenas o resumo. Você pode ver que não há descrição. Não há comentários, nada parecido. Mas se eu pegar isso e enviar para análise, veja o que acontece. Imediatamente, ele vai começar a acionar esse agente, certo Os agentes começarão a passar pelo processo. Ele passará pela solicitação que adicionamos. Depois, reservamos um momento para percorrer o processo. E, claro, estamos vendo ele realmente fazer isso. Normalmente, quando você faz a transição de algo, isso acontece no back-end, não estamos realmente vendo isso acontecer, e aí está. Aqui estão as coisas que ele trouxe e recomendou. Diz: Queremos vincular esse outro item de trabalho? Ele encontrou um item de trabalho semelhante. Esse porque está falando sobre os endpoints da API? Hm. Na verdade, isso pode estar relacionado a esse item de trabalho, então talvez queiramos vinculá-lo aqui dentro do Jira Na verdade, talvez queiramos mudar isso em vez de uma ideia agora. Isso é uma ideia, tipo de trabalho aqui. E os agentes dizem: Talvez você queira transformar isso em uma tarefa porque parece que estamos realmente trabalhando nessa tarefa, certo? O conteúdo descreve uma tarefa em vez de uma ideia de alto nível. E agora, está dizendo: Oh, na verdade, Ethan, estamos logados como Ethan. É ele quem está fazendo isso. Talvez queiramos mudar o destinatário de ser designado para Dan para realmente ser designado para Ethan, já que é ele quem está trabalhando nisso E agora podemos entrar e dizer: queremos realmente aceitar isso? Queremos refinar? Isso abrirá uma janela de bate-papo do Rovo, onde podemos conversar com o Rovo e talvez refinar algumas Ou podemos combinar isso com algumas das outras funções que analisamos, atribuindo-a automaticamente a alguém da nossa equipe antes de chegar a esse agente de triagem e, em seguida, talvez posicionar o agente de IA abaixo dele em nossa transição e adicionar algo em nosso prompt para verificar se o trabalho sugerido está ou não adequado antes de chegar a esse agente de triagem e, em seguida, talvez posicionar o agente de IA abaixo dele em nossa transição e adicionar algo em nosso prompt para verificar se o trabalho sugerido está ou não adequado ao outro trabalho. que eles já atribuíram a eles no espaço. Você pode começar a ver o quão poderoso isso pode ser. Mas lembre-se sempre de que esse agente faz recomendações como essa. Não fará alterações automáticas. Um humano ainda precisa entrar e analisar se aceita ou não todas essas mudanças. Não, vale a pena mencionar que em nosso espaço de demonstração, temos apenas alguns itens de trabalho Na verdade, não havia nenhuma descrição ou qualquer outra coisa que o agente de triagem analisasse para adicionar um comentário ou algo parecido ao nosso item de trabalho, porque verdade não temos muita coisa nesse item de trabalho Normalmente, quando você está trabalhando em algo, você teria uma descrição muito mais detalhada do que esse trabalho realmente é. Mas podemos aceitar essas alterações e, em seguida, o agente passará pelo processo de realmente atualizá-las. E podemos ver que foi atribuído, foi vinculado. Parece que não foi possível atualizar nada por causa de um problema. Você pode passar por esse processo. Parece que a única coisa que não conseguiu fazer foi mudar o tipo de trabalho, o que não é grande coisa. Podemos entrar aqui e atualizar isso muito rapidamente aqui. E então poderíamos responder e conversar para abrir a janela de bate-papo com IA para tentar corrigir isso ou simplesmente descartar isso para encerrar Assim, você pode ver como isso rapidamente nos ajuda a ficar mais organizados e a fazer uma triagem ainda melhor do nosso trabalho Agora, a última coisa que quero ressaltar antes de concluirmos esta lição é que, embora usemos um dos agentes pré-instalados, aquele agente de triagem que vem com o Rovo, o ecossistema de agentes no Jira vai muito além desses padrões Se voltarmos, poderíamos até adicionar outro, se quiséssemos. Então você pode ver, novamente, com a ordem de empilhamento que importa, então esta ficaria abaixo da que já adicionamos E se quisermos adicionar um agente diferente, ou se entrarmos aqui e analisarmos todos os diferentes agentes que temos, você pode ver que há muitos agentes diferentes. Alguns deles são baseados na licença. Não está disponível para minha licença atual. Mas você pode começar a ver muitos agentes diferentes que temos de vários fornecedores diferentes, certo? Então, muitos deles são da Atlassian para fazer coisas específicas Mas existem alguns talvez do GitHub ou de um Cloud Agent for Jira Podemos integrar isso diretamente ao Jira muito, muito rapidamente E, claro, se nenhuma das opções pré-construídas atender às nossas necessidades, podemos entrar Podemos criar nosso próprio agente dentro do estúdio Rovo para realmente fazer o que quisermos Então, recapitulando, a regra de ação do agente acionador nos permite executar um agente de IA automaticamente quando um item de trabalho faz a transição entre os status E nesta lição, aprendemos como podemos configurar isso usando o agente de triagem pré-instalado para analisar itens de trabalho e sugerir algumas mudanças Mas, novamente, como vimos, ele não faz essas alterações até que as aprovemos e, em seguida, ele examinará e implementará todas essas mudanças Uma última coisa a ter em mente dependendo do agente de IA que estamos usando, eles podem consumir créditos Rovo toda vez que correm Agora, cada plantador do Jira Cloud vem com uma franquia de crédito mensal por usuário. Portanto, é sempre uma boa ideia verificar a franquia de crédito de seus planos ao testar agentes de IA e considerar as transições às quais os vinculamos, e considerar as transições às quais os vinculamos para não gastarmos gastarmos Agora, em nossa próxima lição, vamos nos afastar do editor de fluxo de trabalho e analisar o panorama geral, criando um segundo fluxo de trabalho e unindo tudo a um esquema de fluxo de trabalho. Nos vemos lá. 9. Como conectar fluxos de trabalho com esquemas de fluxo de trabalho: Nesta lição, aprenderemos como podemos usar esquemas de fluxo de trabalho para unir vários fluxos de trabalho Isso também significa que precisaremos de outro fluxo de trabalho. Então, também aprenderemos como criar um novo fluxo de trabalho. Mas vamos começar entendendo bem o que é um esquema de fluxo de trabalho. Basicamente, um esquema de fluxo de trabalho é um mapa que informa Jira qual fluxo de trabalho é usado por qual tipo de trabalho em um espaço Por exemplo, um esquema de fluxo de trabalho pode fazer com que o Jira use o fluxo de trabalho de desenvolvimento de software que usamos ao longo deste curso para as ideias e tarefas em nosso espaço Mas talvez queiramos que o Jira use um fluxo de trabalho completamente diferente para os bugs em nosso espaço de desenvolvimento de software Para ver isso em ação, precisaremos outro fluxo de trabalho além do que temos usado até agora. Então, vamos começar criando um fluxo de trabalho simples para nossos livros. Vou encerrar o editor de fluxo de trabalho que estamos usando. E em nosso fluxo de trabalho na área administrativa, vamos entrar. Na verdade, isso está dentro das configurações de espaço. Então, vou entrar em nossas configurações administrativas globais gerais do Jira e depois entrar nos fluxos de trabalho E então vamos entrar e adicionar um fluxo de trabalho. Vamos criar um novo fluxo de trabalho. Dê um nome a isso. Portanto, esse será nosso fluxo de trabalho de bugs. Para o tipo de trabalho de bug, crie isso. Tudo bem. Então isso foi criado. Esse é apenas um fluxo de trabalho muito simples. Vamos entrar e vamos fazer isso rapidamente porque já vimos como adicionar status Mas vou adicionar os mesmos status padrão que tínhamos antes Então, em vez de criar novos, vamos apenas adicionar alguns muito simples para fazer em andamento, reutilizando status que usamos antes e fizemos Lá vamos nós. E então, em vez de estar aberto quando um novo trabalho é criado, vamos fazer isso e podemos remover o status aberto. OK. Então, basicamente, o que criamos muito rapidamente é um novo fluxo de trabalho que é exatamente igual ao fluxo de trabalho de quando começamos este curso na área de desenvolvimento de software. Lembre-se, ele só tinha esses três status diferentes. E, claro, poderíamos adicionar mais status, transições e regras, assim como fizemos com o fluxo de trabalho de desenvolvimento de software em nossas aulas anteriores Mas, por enquanto, isso nos dá o que precisamos para demonstrar como um esquema de fluxo de trabalho pode lidar com vários fluxos de trabalho Então, vamos atualizar nosso fluxo de trabalho aqui. Agora, precisamos vincular isso ao nosso espaço de desenvolvimento de software com um esquema de fluxo de trabalho, porque você pode ver agora esse é um fluxo de trabalho inativo, que significa que não está sendo usado em nenhum lugar Então, vamos voltar às nossas configurações aqui e aos nossos esquemas de fluxo de trabalho. Agora, por padrão, assim como o Jira criou um fluxo de trabalho para nosso espaço quando o criamos, também temos um esquema de fluxo de trabalho Os espaços sempre precisam de um esquema para informar quais fluxos de trabalho são usados Só que, por padrão, há apenas um fluxo de trabalho em cada esquema. Deixe-me mostrar o que quero dizer. Estamos trabalhando com o projeto de desenvolvimento de software. Então esse é o esquema que está sendo usado nesse projeto. Se entrarmos aqui e editarmos isso, é assim que a maioria dos esquemas é configurada por padrão dentro de um Jira Basicamente, ao dizer apenas cada tipo de trabalho, lembre-se do tipo de trabalho que costumava ser chamado de tipo de problema, você ainda possa ver essa terminologia em algum lugar na área administrativa Portanto, cada tipo de trabalho dentro deste projeto está usando o fluxo de trabalho que criamos ao longo deste curso, aquele fluxo de trabalho de desenvolvimento de software com o qual trabalhamos. Se quiséssemos mudar isso e dizer: Sabe o que? Para bugs, queremos usar um fluxo de trabalho diferente, podemos entrar aqui adicionar um fluxo de trabalho existente, e é por isso que queríamos criar o novo fluxo de trabalho primeiro, porque ele está procurando um fluxo de trabalho existente. Vamos adicionar esse fluxo de trabalho do BG. Em seguida, para o tipo de problema BG ou tipo de trabalho, como são chamados agora. Agora, sempre que um bug no espaço que está usando esse esquema de fluxo de trabalho for criado, ele usará o fluxo de trabalho BG, certo? Então, vamos publicar isso e ver isso em ação. Agora, podemos nos deparar um pequeno problema ao associar qualquer coisa É necessário verificar se todos os status estão corretos. Eu me deparei com um problema em que talvez tenhamos removido um status no fluxo de trabalho, mas havia itens de trabalho que estavam nesse status. Digamos, se removermos em andamento por qualquer motivo e houver itens de trabalho em andamento, ele dirá: Ei, o que você quer fazer com eles? Você quer mapeá-los para um novo status? Deseja removê-los ou não fazer essa alteração? Só está nos avisando. Nesse caso, como acabamos de configurar isso, não temos nenhum item de trabalho existente nos status que estamos removendo, certo? Estamos adicionando um fluxo de trabalho a ele. Não estamos removendo nenhum fluxo de trabalho do nosso esquema. Mas se voltarmos ao nosso projeto, vamos dar uma olhada no projeto aqui, apenas uma maneira rápida de voltar ao projeto. Talvez nos deparemos com um problema que precisaremos corrigir porque não tenho certeza se viremos aqui e criaremos um novo item de trabalho. Não tenho certeza se ainda temos insetos aqui. Não, não temos insetos em nosso espaço. Então, vamos abordar nossos itens de trabalho, tipos. E vamos adicionar um tipo de trabalho. Então, queremos ter certeza de que realmente adicionamos bugs, para que possamos usar bugs neste espaço. Lá vamos nós. Clique em Salvar. Agora podemos usar bugs em nosso espaço de desenvolvimento de software e, sempre que usarmos bugs, ele usará esse fluxo de trabalho de bugs em vez do fluxo de trabalho com todos os outros itens de trabalho que estamos usando Você pode ver a diferença aqui, certo? Então, tudo isso está usando o fluxo de trabalho que criamos e trabalhamos durante todo o curso. Mas esse tipo de trabalho está usando um fluxo de trabalho diferente. Então, vamos ver isso em ação. Se voltarmos ao nosso espaço aqui, vamos entrar e dar uma olhada em todos os diferentes itens de trabalho que temos. Vamos fechar o menu apenas para termos um pouco mais de espaço aqui para ver nas colunas. Então, esses são os itens de trabalho com os quais trabalhamos ao longo deste curso. Vamos dar uma olhada nesse aqui, ok? Veja o status, certo? Isso é o que vimos ao longo deste curso, bloco em andamento. Uma vez que esteja em andamento, podemos entrar aqui e começar a tomá-la. Na verdade, nós o temos porque não estamos logados como nossos desenvolvedores Se fizermos login como nosso desenvolvedor, como Ethan, ele pode realmente pegar isso e executá-lo em diferentes fluxos de trabalho, certo? Então, esse é o fluxo de trabalho que configuramos. Mas se esse item de trabalho fosse alterado, vimos como podemos alterar o item de trabalho em um vídeo anterior para um tipo diferente. Se mudarmos isso de uma ideia para um bug, veja o que acontece. Então está dizendo: Ok, espere um minuto. Isso foi alterado. Como queremos mapear isso para o novo fluxo de trabalho, certo? Ok, então agora, é uma ideia. Queremos transformar isso em um bug. E então ele vai passar e dizer: Ok, qual é o status disso? Tudo isso é bom? E como estamos realmente no status em andamento, tudo parece estar bem. Não há problemas. Este é um resumo simples do que vai acontecer. Isso vai deixar de ser uma ideia para se tornar um bug. Isso mudará de estar em andamento nesse fluxo de trabalho para estar em andamento com esse fluxo de trabalho. E agora que está no fluxo de trabalho do Bug , não passará mais mesmo processo de controle de qualidade que configuramos no fluxo de trabalho de desenvolvimento de software. Vai passar por um processo completamente diferente, o que significa que pode simplesmente entrar. Pode ser para fazer. Isso pode ser feito. Não passará pelo processo de controle de qualidade que configuramos no fluxo de trabalho de desenvolvimento de software. E o back-end disso está no editor de fluxo de trabalho, onde podemos ver deixe-me abri-los lado a lado aqui para que possamos ver esses dois fluxos de trabalho diferentes abaixo dos fluxos Temos o fluxo de trabalho de bugs. Então, vou abrir isso em uma nova guia. Vou abrir a tela que aparecerá aqui em breve. Temos o fluxo de trabalho de desenvolvimento de software com o qual trabalhamos ao longo deste curso. Aqui vamos nós. Portanto, esse é o fluxo de trabalho que a ideia era quando foi criada pela primeira vez. E então, quando o alteramos, ele mudou para esse fluxo de trabalho, o fluxo de trabalho de bugs. Que acabamos de criar, o que significa que não está passando por nenhum desses outros status que temos aqui, certo? No mesmo espaço, ele ainda é usado no mesmo espaço, mas é usado apenas para o tipo de trabalho BG. Mas aqui, esse fluxo de trabalho está sendo usado para todos os outros tipos de trabalho dentro do espaço. Ok, então, para recapitular. Nesta lição, aprendemos o que é um esquema de fluxo de trabalho. É uma forma de mapear tipos de trabalho para fluxos de trabalho em um espaço. Também aprendemos como criar um novo fluxo de trabalho e usar o esquema para dizer qual tipo de trabalho usar com ele. E, como você pode imaginar, todas essas transições, regras e coisas que aprendemos até agora estão incluídas em cada fluxo de trabalho, para que possamos personalizar ainda mais esse fluxo de trabalho de bug , se quisermos Agora, em nossa próxima lição, vincularemos tudo aos processos ágeis da nossa equipe, vendo como fluxos de trabalho afetam nossos quadros ágeis 10. Usando fluxos de trabalho com quadros ágeis.: Nesta lição, veremos como os fluxos de trabalho e os quadros ágeis funcionam juntos, já que é aí que nossa equipe interage com os fluxos de trabalho com mais frequência todos os dias por meio do nosso Resumindo, os quadros Agile e o Jira estão simplesmente mapeando status do nosso fluxo de trabalho para uma exibição visual Lembre-se de que cada status pertence a uma das três categorias a serem feitas em andamento ou concluídas. O quadro também agrupa os status por essas categorias, o que você pode ver pelas barras cinza, azul e verde na parte superior Cinza significa fazer, azul está em andamento e verde é o status que está na categoria concluído Agora, vamos ver isso em ação. Vou usar o quadro ágil do nosso espaço. Então, vamos entrar e vamos entrar no próprio espaço. E então podemos entrar no espaço usando a migalha de pão apenas uma maneira muito rápida de chegar E isso deve nos levar ao espaço geral em si. Talvez precisemos acessar a visualização do quadro se ela não nos levar até lá por padrão, mas parece que está carregando o quadro. Tudo bem, então esta é a placa Cbon que instalamos em nosso espaço Agora, se você estiver usando um quadro scrum, é basicamente o mesmo processo, exceto, é claro, pela diferença entre scrum e Cbon usando sprints em quadros scrum e quadros Mas, no back-end, a forma como ele se conecta aos fluxos de trabalho é a mesma Essas colunas estão vinculadas aos diferentes status dos itens de trabalho Então, se entrarmos nas configurações do quadro, podemos ver isso no back-end, nas colunas. E podemos ver que as tarefas em andamento e concluídas são mapeadas para essas colunas diferentes Mas podemos ver que muitos dos diferentes status que criamos em nosso fluxo de trabalho não estão atualmente mapeados para Portanto, podemos realmente personalizar isso quisermos no quadro, e isso permitirá que nossos usuários façam a transição rápida de status de um para outro Então, vamos configurar isso bem rápido. Digamos que, ok, para revisão de código, digamos que queremos adicionar um novo status aqui, uma nova coluna, devo dizer. Adicione isso. Opa. Revisão do código. E então podemos mapear esse status para essa coluna aqui. E eu quero realmente mover isso. Portanto, a revisão do código estará em andamento e, em seguida, o bloqueio também poderá estar em andamento. Não vou fazer é um status concluído. Para o quar, vamos realmente criar uma única coluna para A trabalhar. Nós vamos levar isso. Será depois da revisão do código. Então, novamente, com o Agile, você vai da esquerda para a direita. Ray for A, os testes de QA podem estar na mesma coluna. Lá vamos nós. Portanto, temos tudo configurado no back-end mapeando os status para as diferentes colunas Vamos ver como isso funcionará na prática. Então, vamos voltar login como desenvolvedor, Ethan Então, se formos à diretoria do nosso projeto de desenvolvimento de software, veremos como tudo isso se relaciona, certo? Portanto, temos esses diferentes itens de trabalho que são os diferentes status vinculados a essa coluna Então, podemos ver isso aqui, se abrirmos isso, o status é revisão de código. Mas se eu mudasse isso, se mudássemos isso, digamos transição para em andamento, o que acontece é que isso vai passar para o quadro e agora está em andamento. Então, esse é o processo básico, certo, quando você pega algo e muda de uma coluna para outra, no back-end, tudo o que o Jira está fazendo é exatamente a mesma coisa que fizemos até agora Ele está passando pelo processo de transição entre esses diferentes status nesses nesses Então, agora que alteramos a coluna, o status desse item de trabalho também está mudando, certo? Então, isso agora está na revisão do código. Na verdade, é executado pelo agente. Então, você pode ver que ele foi executado pelo mesmo agente de triagem que configuramos porque isso faz parte da transição entre esses diferentes status Eu também acontece no tabuleiro. Está apenas esperando nossa opinião. Nós realmente queremos mudar o nível de prioridade disso, certo? Então essa é a sugestão desta vez. Sim, vamos mudar o nível de prioridade disso. Isso vai atualizar isso. Podemos até ver no quadro o quente Back here. Não sei se você percebeu, mas aqui está dizendo que há um agente de triagem aqui Então, quando arrastamos itens de trabalho para lá, isso aciona esse agente, o que significa que você provavelmente quer ir até lá e verificar o que ele vai fazer. Novamente, o agente de triagem não fará nada sem que um humano o revise primeiro e se certifique que deseja aceitar essas recomendações Então, nos bastidores, o fluxo de trabalho ainda está controlando tudo. Tudo o que configuramos ainda está sendo controlado nesta placa. Até mesmo os esquemas de fluxo de trabalho. Então veja o que acontece com esse bug. Está em andamento. Mas não podemos levar isso à revisão de código. Não podemos levar isso para o controle de qualidade. Só podemos fazer isso porque, se você se lembra, quando criamos o fluxo de trabalho do BG, ele só tinha três status para fazer em andamento, quais já estão em andamento ou concluídos Não podemos incluir esses outros status porque esse tipo de trabalho não está associado ao fluxo de trabalho que contém esses status Então é aí que você pode realmente obter uma boa camada de controle não apenas sobre os fluxos de trabalho em si, quais tipos de trabalho estão usando fluxos de trabalho diferentes, e você pode realmente ver como começar a personalizar isso para sua Então é aqui que os fluxos de trabalho podem realmente começar a ser complexos, dependendo de como você os configurou Se você se lembra, estabelecemos algumas regras em nossas transições. Então, para ir da revisão de código para A, mesmo que no back-end, tenhamos vários status mapeados nesta Quando estamos logados como nosso desenvolvedor, como Ethan, ele só pode fazer a transição para o status Pronto para QA, o que significa que, se ele assumir isso aqui, ele só poderá fazer a transição para Pronto para Embora aqui esteja em andamento, ele pode escolher qual status deseja que seja para o controle de qualidade, ele só pode ver esse por causa das restrições que temos porque ele faz parte do grupo de desenvolvedores, e somente usuários do grupo e somente usuários desenvolvedores podem se preparar para o controle de qualidade. Quando estiver pronto para o controle de qualidade, observe que, que será atualizado, será automaticamente atribuído ao MAX. Novamente, outra coisa que configuramos neste curso foi atribuir automaticamente ao MAX. Agora, se fizermos login para sermos designados como MAX, podemos ver esse item aqui, ele aparecerá aqui Você pode ver isso atualizado em tempo real para estar no controle de qualidade. Agora que estamos logados como Max como parte da equipe de controle de qualidade, ele pode realmente pegar isso e atualizar isso Agora, ele não pode levar isso para Dunn porque isso realmente precisa ser abordado e estar na próxima etapa do nosso fluxo Se você se lembra, a próxima etapa do fluxo de trabalho é fazer a transição para iniciar o controle de qualidade, certo? Então, você realmente precisa começar um antes que isso possa ser feito devido à forma como nosso fluxo de trabalho está configurado. Então é aí que talvez queiramos entrar aqui e dizer: Ok, na verdade queremos apenas uma coluna para controle de qualidade ou queremos uma segunda coluna que nos permita iniciar o controle de qualidade e arrastá-la para lá para que Max não precise entrar e abrir esse item de trabalho como acabamos de fazer. Ele poderia simplesmente arrastá-lo agora, uma vez que esteja no status de teste de controle de qualidade. Está sendo testado. Não está pronto para o qua. Agora podemos arrastá-lo para Dunn porque ele passou por esse processo E, novamente, tudo isso está no back-end nosso fluxo de trabalho, vinculado às colunas no quadro. Então, se quiséssemos espalhar isso, poderíamos fazer isso. Poderíamos adicionar uma segunda coluna se você quisesse para o controle de qualidade. Na verdade, depende do que funciona melhor para sua equipe e de como você quer que tudo isso aconteça. Claro, o problema , claro, é que agora, como Ethan, ele verá a outra coluna aparecer também em seu quadro, mas ele não conseguirá arrastar nada até ela Ele só vai ver quais itens de trabalho estão sendo testados atualmente. Na verdade, ele não pode arrastar isso até lá por causa das restrições que estabelecemos. Você pode ver que ele não consegue arrastar isso até lá por causa das restrições em nosso fluxo de trabalho. Para recapitular o que aprendemos nesta lição, status é mapeado para as colunas do quadro Agile E você pode até mesmo ter vários status compartilhando a mesma coluna Quando movemos o trabalho de uma coluna para outra em nosso quadro, o que realmente estamos fazendo é fazer a transição de um status para outro em nosso E isso significa que todas essas regras em nosso fluxo de trabalho também se aplicam. Portanto, se você tiver problemas para mover trabalho de uma coluna para outra, isso provavelmente se deve às regras, como restrições ou validadores, que aprendemos neste curso Nós. Isso é muito, não é? E com isso, estamos quase terminando nosso curso, mas eu gostaria de convidar você a se juntar a mim um último vídeo, onde vamos dedicar alguns momentos para refletir sobre tudo o que aprendemos neste curso. 11. Resumo do curso: Você chegou à aula final. Neste curso, analisamos a criação de um fluxo de trabalho personalizado, desde os status e transições básicos até um fluxo de trabalho personalizado, desde os as regras do fluxo de trabalho e os agentes de IA, e depois vinculamos tudo de volta aos nossos quadros ágeis Deixe-me deixar vocês com as principais coisas que eu realmente espero que você tire disso. Comece de forma simples. Não construímos um Behem de 30 status Tínhamos alguns status que atendiam às nossas necessidades. Se você ainda não criou um fluxo de trabalho, comece com o que sua equipe realmente faz todos os dias. Só aumente a complexidade quando o fluxo de trabalho provar que é necessário. Em seguida, combine os fluxos de trabalho com os tipos de trabalho. Alguns tipos de trabalho compartilham ciclos de vida, como as ideias e tarefas em nosso caso, mas outros não têm seu próprio fluxo de trabalho, e você não precisa forçar um fluxo de trabalho a atender a tudo se os ciclos de vida desses tipos de trabalho geralmente forem diferentes. Além disso, use regras para resolver problemas, não para criar novos. Você pode restringir a transição para controlar quem pode mover o trabalho, validar detalhes para garantir que os dados existam, realizar ações, automatizar atualizações, solicitar informações coletar dados nos momentos-chave Cada tipo de regra tem um trabalho, mas não os coloque lá só porque você pode Tenha um propósito para cada um que você usa. E fique atento aos créditos da Rovo. Usamos o agente de triagem com uma solicitação personalizada em uma transição, e o Rovo está incluído nos planos pagos do Jira Cloud, standard premium e enterprise a partir Portanto, não há uma licença separada com que se preocupar, mas cada nível de plano tem uma franquia de crédito mensal por usuário, e os agentes consomem créditos toda vez que correm Portanto, implante-os onde suas análises realmente agreguem valor, não em todas as transições E continue recebendo feedback e atualizando seus fluxos de trabalho. Você ajustará isso à medida que os processos de sua equipe evoluírem, adicionará status quando surgirem novas transferências e as removerá quando deixarem Teste as alterações antes de atualizar seu fluxo de trabalho para toda a equipe. A parte mais difícil de criar fluxos de trabalho é superar a crença de que eles precisam ser perfeitos na primeira tentativa Isso não acontece. Crie algo que funcione para hoje. Repita quando a equipe precisar de mais, e é assim que você acaba com um fluxo de trabalho que corresponde à forma como sua equipe realmente trabalha Muito obrigado por se juntar a mim nessa jornada. Se você é administrador do Jira, administrador de espaço ou líder de equipe, espero que agora tenha as ferramentas e a confiança para criar fluxos de trabalho que correspondam à forma como sua equipe realmente Obrigado novamente por assistir.