Tag: jira

Se você curte o Jira, não deixe de conferir meu artigo sobre gestão de backlog usando Jira!

No último artigo eu ensinei como criar diversos tipos de automações em Jira. Venho trabalhando com esta ferramenta desde 2018 e ela é bem poderosa, mais até do que a que usei por mais de 10 anos, o famoso TFS da Microsoft.

Entre as inúmeras funcionalidades, o Jira permite criar diversos campos customizados de vários tipos, mas, além disso, campos que carregam o seu conteúdo dinamicamente a partir de scripts Groovy, graças ao plugin Adaptavist ScriptRunner. Vou mostrar aqui como criar um campo dinâmico.

Este tutorial foi feito usando o Jira na versão server/on-premise (v7.10), mas possivelmente deve funcionar em versões posteriores e talvez até na cloud, desde que tenha o plugin/add-on do Script Runner. Você precisa de permissões de administrador do Jira para conseguir fazer o que vou mostrar.

Este artigo não tem a pretensão de ensinar a administrar Jira, mas apenas a dar um upgrade nas suas skills se já for um administrador de Jira Server. Para quem quer aprender a administrar Jira, recomendo os serviços de consultoria da e-core, parceiros Atlassian no Brasil e com quem eu aprendi.

Custom Fields

Por padrão o Jira permite que você crie Custom Fields ou Campos Personalizados. Nada mais são do que inputs comuns, usando os tipos pré-existentes do Jira, mas como rótulos/labels personalizados e que adicionam mais informações às screens já existentes ou a novas screens.

Caso isso seja novidade para você, o passo-a-passo abaixo mostra como criar um custom field simples. Me perdoe as imagens em português, foi uma imagem que tirou os prints e ela usa o Jira em pt-br (eu prefiro usar em inglês pois facilita a procura por informações na Internet).

1. Acesse o painel de administração;
2. Seção Issues;
3. Sub-seção Fields;
4. Opção Custom Fields/Add Custom Field

Na tela que se abrirá, preencha de acordo com o campo que precisa (campo de texto, de seleção, etc). Cada tipo de campo possui as suas particuliaridades, como a Select List, que exige que tu preencha manualmente todas as opções do drop-down.

A seguir, depois de clicar em Create, você vai ser solicitado que selecione em quais telas este campo vai aparecer.

E pronto. Caso ele ainda não apareça nas telas que você selecionou, dê uma olhada na Screen para ver se não tem de torná-lo visível pois às vezes ele está na tela, mas oculto/hidden.

Mas e para criar custom fields baseados em scripts, como faz?

Script Fields

Você pode criar campos dinâmicos que carregam o seu conteúdo a partir de scripts, o que chamamos de Script Field. Esse recurso é muito poderoso para, por exemplo:

• exibir informações de linked issues dentro das issues principais (e vice-versa);
• exibir informações resultantes de cálculos ou transformações de outros dados da issue;

Uma vez com o campo criado, é possível adicioná-lo em qualquer screen ou até mesmo usá-lo em queries e reports.

Para criar um Script Field você deve:

1. Entre em Administration;
2. Escolha a opção Issues;
3. Clique em Custom Fields, abaixo da seção Fields;
4. Clique em Add Custom Field;
5. Em Select Field Type, encontre Scripted Field dentro de Advanced (o ícone é o mesmo do Script Runner);
6. Next;
7. Dê um nome e uma descrição ao campo (este último é opcional) e salve;
8. Selecione todas as telas em que este campo deve aparecer e clique em Update;
9. Retorna a Administration, Add-ons, Script Runner e Fields;
10. Encontre o seu Scripted Field criado e depois clique em Edit;

Preencha o formulário como segue:

• Field Name: não editável;
• Field Description: não editável;
• Note: uma nota opcional;
• Template: como esse campo será renderizado na screen;
• Script: o código Groovy que vai retornar o conteúdo desse campo. É aqui que a magia acontece e esse código sempre recebe um objeto issue como argumento, com as propriedades da issue atualmente visível na screen onde esse script field está.
• Preview Issue Key: coloque o id de uma issue aqui e clique no botão preview para ver como seu Script Field vais e parecer na screen.

Clique em Update para finalizar.

Caso seu script field não aparece na screen que deveria, reveja as configurações de screen do custom field e/ou verifique na screen se o campo está aparecendo no editor visual dela.

Um exemplo de código Groovy para script field é mostrado abaixo. Nele, nós ascendemos na hierarquia da issue atual até encontrar qual o Projeto (um issue type custom) ela pertence, imprimindo essa informação então no custom script field:

No exemplo abaixo, de outro script field, dado um issue do tipo Mudança, a gente busca o item originador desta mudança (outra issue) e se tiver mais de um, pega apenas o primeiro para exibir no custom script field:

E nesse último abaixo, mais simples de todos, temos um custom script field que apenas exibe o nome do épico associado a esta issue:

Espero ter ajudado!

Infelizmente eu não possuo um curso de Jira, mas caso se interesse por métodos ágeis em geral, dê uma conferida no meu curso online de Scrum e Métodos Ágeis clicando no banner abaixo.

Se você curte o Jira, não deixe de conferir meu artigo sobre gestão de backlog usando Jira!

O Jira permite criar diversos tipos de automações, principalmente através de plugins como o famoso Adaptavist ScriptRunner ou o Automation for Jira. Vou mostrar aqui como criar alguns tipos diferentes de automação, todas usando o Jira Server v7.10 (a versão que mais tive contato, mas é possível que funcione nas posteriores) e necessitando de permissão de administrador para serem criadas.

Como uma dica geral, todas automações que exigem script Groovy você pode usar log.warn(“mensagem”) para registrar logs e ajudar no seu debug enquanto estiver programando e quando estiver em produção e ter de fazer troubleshooting.

Este artigo não tem a pretensão de ensinar a administrar Jira, mas apenas a dar um upgrade nas suas skills se já for um administrador de Jira Server. Para quem quer aprender a administrar Jira, recomendo os serviços de consultoria da e-core, parceiros Atlassian no Brasil e com quem eu aprendi.

Tipo 1: Automações de Workflow

Você pode criar automações que serão disparadas quando uma issue for realizar uma transição dentro do seu workflow, ou seja, mudar de um estado para outro. Esse recurso é muito poderoso para:

• criar validações na troca de estado, como garantir que campos estejam preenchidos, por exemplo;
• Realizar atividades automáticas após uma troca de estado (atualizar um campo, disparar um script Groovy, etc);
• Disparar eventos que podem ser tratados depois, pelo Jira (listeners, mais adiante);

Para criar uma validação de campo obrigatório (ou que tenha de ter um valor específico preenchido), você deve:

1. Clicar em Project Settings (ícone da engrenagem);
2. Clicar em Workflows;
3. Clicar no botão de Edit do workflow em questão (ícone do lápis);
4. Seleciona a visualização em forma de Diagram;
5. Clica na linha da transição que deseja adicionar a validação;
6. Seleciona a opção Validators (ou Post Function se for querer disparar eventos depois da transição);
7. Clique no link “Add validator”;
8. Seleciona a opção “Script validator [Script Runner]”;
9. Seleciona a opção “Simple scripted validator”;

A seguir, preencha os campos da seguinte forma:

• Note: nome da validação;
• Condition: o seu código Groovy que deve retornar true ou false, dizendo se aquela transição vai poder acontecer ou não;
• Error Message: mensagem de erro que vai aparecer se a validação bloquear a transição (retorno false);
• Field: se você deixar esse campo em branco, a mensagem de erro vai aparecer no topo do formulário. Preencha se quiser que ela apareça ao lado do campo;

No exemplo abaixo, o campo Área de Negócio deve ser preenchido para que uma issue possa ser criada:

Caso você quer que algo aconteça DEPOIS da transição ocorrer, você usa post-function ao invés de validator e além de vários templates prontos, você também pode codificar o comportamento usando Script Runner.

Tipo 2: Automações para Jira Service Desk

Você pode criar automações baseadas no Service Desk e seus serviços. Para fazê-lo, precisa de permissão de administrador no Jira Service Desk ao invés do Jira Software. Esse recurso é muito poderoso para:

• Criar alertas diversos, como SLA expirando, por exemplo;
• Atualizar issues relacionadas toda vez que a principal for alterada;
• Reabrir issues que tenham sido comentadas;
• Muitos tipos de regras personalizadas;

1. Clique em Project Settings;
2. Clique em Automation;
3. Clique em Add Rule;
4. Selecione o tipo de regra que deseja adicionar, neste exemplo usarei Custom Rule (Regra Personalizada);

Preencha os campos como segue:

• Rule name: o nome da automação;
• Description: a descrição do que faz esta automação;

Construa a automação como segue:

• When: a situação ou evento que irá disparar esta automação. Adicione tantas triggers (gatilhos) quanto forem necessárias. Por exemplo, toda vez que o status de uma issue seja atualizado.
• If: a condição (uma ou mais) que será validada para esta automação executar ou não. As condições disponíveis no if dependem do when. Quando for uma issue, por exemplo, as condições vão ser relacionadas a issues.
• Then: uma ou mais ações que serão executadas quando esta automação ocorrer. Por exemplo, você pode mudar o estado de uma issue ou enviar um e-mail.

Neste tipo de automação não qualquer criação de script, é tudo visual.

Tipo 3: Automações com Escalation Services

Você pode criar automações que serão disparadas automaticamente, de tempos em tempos. Esse também é um recurso do ScriptRunner e permite fazer coisas como fechar chamados automaticamente depois de X tempo;

Para criar um escalation service, você deve:

1. Ir na administração geral do Jira Software estando autenticado como administrador;
2. Acesse a aba Add-ons;
3. No menu esquerdo, vá em Escalation Services, dentro da subseção Script Runner;
4. Clique em Create Escalation Service;

Existem vários tipos, vamos usar aqui o Escalation Service de Issue.

Preencha os campos do formulário como segue:

• Description: o nome do escalation service;
• JQL Query: a consulta que irã ser executada de tempos em tempos para executar a ação automática sobre as issues retornadas;
• As User: o usuário que irá executar a automação;
• Interval/CRON Expression: uma expressão CRON que determine a periodicidade da automação;
• Action: opcional, permite escolher uma transição de workflow pré-existente, útil se você apenas quer mudar o status das issues retornadas pelo JQL;
• Additional issue actions: script Groovy que faz a operação que você deseja, nas issues retornadas pelo JQL.
• Transition Options: alguns cheats para tornar a transição mais fácil como ignorar validators, permissões ou conditions.

Clique em Add e o tempo começará a correr, executando a automação no próximo CRON. Caso queira executar imediatamente, clique em “Run now”.

Tipo 4: Automações com Listeners

Você pode criar automações que serão disparadas automaticamente, quando algum evento acontecer no Jira. Esse também é um recurso do ScriptRunner e permite fazer coisas parecidas com as post-functions de workflow. Na verdade, a base dos Listeners são “escutar” (listen) eventos gerados por transições de estado, mas diferente das automações de workflow, você não cria em um workflow, mas de maneira global e genérica, o que é muito útil quando tem vários times com diferentes workflows mas uma automação e aplica a todos eles.

Para criar um listener, você deve:

1. Acesse Administration;
2. Add-ons;
3. Clique na opção Listeners, dentro da subseção ScriptRunner;
4. Clique em Create Listener;
5. Escolha um dos templates prontos ou a opção Custom Listener para adicionar um código Groovy personalizado, opção que vou usar aqui;

Preencha o formulário como segue:

• Note: o nome do listener;
• Project(s): um ou mais projetos que este listener vai ficar escutando eventos;
• Events: os eventos que vão disparar este listener. Você pode escolher eventos pré-definidos do Jira (que ele dispara sozinho) ou algum evento que você tenha criado manualmente e que dispare através de workflow post-functions ou de outras formas existentes;
• Inline script: seu código Groovy. Ele recebe um objeto event por padrão, com as propriedades do evento;
• Script file: opcional, permite dizer o caminho de um arquivo com o código Groovy dentro.

Clique em Add.

Um exemplo de código Groovy para listener pode ser visto abaixo. Neste exemplo, quando uma issue é resolvida (evento Issue Resolved) e ela está associada a um épico, ela propaga a sua informação de épico às issues de Service Desk (SDN) relacionadas à ela:

Tipo 5: Automações com e-mail

Você pode criar automações de e-mails que serão disparadas automaticamente, de tempos em tempos, baseada em consultas construídas por você (JQL). Esse é um recurso natural do Jira Software, embora com o Jira Service Desk também possa ser feito, como mencionado anteriormente.

1. Faça uma consulta qualquer (JQL) na caixa de pesquisa do Jira;
2. Salve a sua consulta, dando um nome à ela;
3. Clique em Details e selecione a opção New Subscription;

Configure a Subscription dessa forma:

• Recipients: quem vai receber essa assinatura de e-mails? Você pode enviar para grupos de pessoas;
• Schedule: qual a recorrência? Em Advanced você pode definir uma expressão CRON para a recorrência;
• “E-mail this filter…”: por padrão o resultado da consulta só é enviado por e-mail quando ele traz resultados. Marque se quiser receber um e-mail mesmo sem resultados na consulta.

Ao clicar em Subscribe, a automação de emails passará a funcionar.

Espero ter ajudado!

Infelizmente eu não possuo um curso de Jira, mas caso se interesse por métodos ágeis em geral, dê uma conferida no meu curso online de Scrum e Métodos Ágeis clicando no banner abaixo.

Atualizado em 01/07/19!

Quando começamos a estudar o Scrum Guide logo nos deparamos com o artefato Product Backlog. O framework prescreve que o Product Owner deve manter este artefato com todos os itens necessários ao produto/projeto a ser desenvolvido, de maneira priorizada, atualizada e visível.

No vídeo abaixo falo rapidamente sobre isso:

No entanto, algo que o framework não prescreve é como fazer isso e a ideia do post de hoje é justamente essa, mostrar uma ideia de como organizar o seu Product Backlog usando a ferramenta Jira Software, em sua versão SaaS. Não vou falar aqui de priorização de backlog, coisa que já falei em outros posts, mas de como usar esta ferramenta web para fazê-lo e explicando alguns conceitos importantes que podem ser aplicados independente da ferramenta que você venha a utilizar.

Caso prefira acompanhar este artigo em vídeo, segue abaixo um trecho pequeno do meu curso de Scrum e Métodos Ágeis no meu canal no Youtube:

Jira Software

O Jira é a ferramenta líder de vendas para gestão de projetos de software no mundo todo, sendo um concorrente direto do Azure DevOps da Microsoft (o antigo TFS). A sua fabricante, Atlassian, possui uma suíte de soluções que vão desde o Trello, para gestão básica de quadros de trabalho, até ferramentas de chat e colaboração entre times, versionamento de código e construção de pipelines automatizados de deploy.

Mesmo que você não venha a usar a suíte completa (até porque sairia bem caro), usar o Jira pode ser uma excelente opção para tocar os seus projetos de maneira mais organizada. A ferramenta SaaS tem muitas funcionalidades interessantes e um grande fit com as metodologias ágeis como Scrum e Kanban, fornecendo todos os artefatos prontos ou configuráveis para os usuários.

O Jira oferece um trial de uma semana na época em que escrevo este artigo, mas se você procurar bem você encontra a versão free para 5 usuários (assim como o TFS tem). O trial é suficiente para que consiga aprender a usar a ferramenta e seguir este tutorial, mas de repente o plano free também te atenda. Então, crie uma conta no site da Atlassian antes de prosseguir.

Vale salientar que este tutorial cobre apenas a versão SaaS (cloud, online) do Jira, sendo que ele possui uma versão server cuja interface é ligeiramente diferente, embora o funcionamento seja exatamente mesmo.

Criando um novo projeto

Na tela inicial da ferramenta você tem um botão Create Project no canto direito. Use ele e defina um nome para o projeto. Se você tem apenas um time que toca diversos projetos, pode ser interessante colocar o nome do time aqui, ao invés do nome do projeto atual deles, para fins de histórico. Ao longo deste tutorial usarei o template Scrum, que foi selecionado como na imagem abaixo (esquerda).

Outras opções na criação do projeto incluem o método Kanban e isso influencia bastante a organização dos itens, os quadros e diversos outros fatores, embora seja possível mudar de um para outro.

Organizando o Product Backlog

Uma vez com o projeto criado, você vai ser direcionado para a tela de Backlog do seu projeto, sendo que aqui ele representa o Product Backlog, cuja gestão é de responsabilidade do Product Owner.

No Jira existem três níveis de backlog que auxiliam o Product Owner (principalmente) a se organizar, ambos acessíveis na parte esquerda, entre o menu lateral e o backlog, à saber:

• Epics: épicos são features muito grandes e pouco detalhadas (alto nível de incerteza técnica), geralmente levando várias sprints para serem concluídas (pense na grandeza de semanas a meses de trabalho). Épicos são constituídos de múltiplas User Stories.
• User Stories: o Jira assume o padrão de Histórias do Usuário para os famosos itens de backlog do produto que são citados no Scrum Guide como sendo a unidade de trabalho do Product Backlog. Uma User Story gera valor ao usuário por si só e entregar uma ou mais delas prontas (DONE). User Stories geralmente levam dias para serem entregues, possuem linguajar de negócio e grau de incerteza técnica médio, podendo ser quebradas em pedaços menores, chamados de Sub-Tasks, para se ter maior assertividade do trabalho a ser realizado.
• Sub-Task: uma sub-task é uma tarefa que deve levar horas para ser feita, é extremamente técnica, com baixo grau de incerteza técnica e não entrega muito valor por si só, fazendo parte de um grupo que juntas, entregam o valor proposto pela User Story.

O formato recomendado de escrita é partir do Issue Type menos granular (Epic) até o mais granular (Sub-Task), usando o menu Epics que fica à esquerda do backlog, mas antes do menu lateral. Sendo assim, acesse o nível Epic do seu Backlog.

Nesta tela da imagem acima, note que tem um link “Create Epic” ao lado da seção EPICS, clique nele para começar a criar os seus épicos com apenas o título e um resumo. Mais tarde você pode adicionar mais detalhes a cada um deles (mas não muito, eles são apenas visões) clicando no título dos mesmos

Após adicionar os seus épicos, você vai ver eles na coluna esquerda do painel. Note na imagem abaixo como o épico “Cartão no App” aparece depois do meu cadastro e com ele a opção “Create issue in epic”, que é justamente para criar elementos dentro dele. Caso já existam issues, elas aparecerão no painel da direita.

Clique no “Create issue in epic” para adicionar uma User Story (o Issue Type padrão), com um título, descrição (a história em si) e o que mais você precisar.

Para este exercício, pegue um projeto real do seu time ou então um problema fictício como um cadastro de cliente. O épico seria fazer a versão completa do cadastro, sendo que as User Stories poderiam ser “Adicionar novo cliente”, “Excluir cliente”, etc.

Se você atendeu à sugestão do Jira de usar User Stories, pense em todos as histórias de usuário que puder lembrar para cada um dos épicos. Alguns épicos simples talvez tenham apenas uma ou duas histórias, enquanto outros mais complicados podem ter várias. Não esqueça de, além de escrever o título e descrição da história (usando o formato padrão da User Story), escreva também os critérios de aceite.

É importante ter em mente que o Product Owner tem total liberdade neste momento. Crie, edite e exclua seus Epics e User Stories livremente. É comum escrevermos algumas histórias que mais tarde descobrimos serem épicos. É comum épicos serem quebrados em mais épicos para que o sistema não vire um mero waterfall-iterativo. Embora o time tenha acesso ao Product Backlog como um todo, não é a partir dele que eles se orientarão no dia-a-dia, como falarei mais adiante.

Organizando as sprints

A visão de backlog que usamos até o momento são de foco do Product Owner. O Time de Desenvolvimento trabalha usando a visão da sprint atual (current sprint) dentro do Jira. Assim que tiver algumas User Stories criadas, como abaixo, vai aparecer um botão de “Create Sprint” no canto superior direito.

Ao iniciar uma planning (ou agora, para fins de exercício), clique no botão “Create Sprint” e você será direcionado para o planejador de sprints. Na parte inferior da tela ele lista as User Stories existentes e, na parte superior, o escopo da sprint atual, que vai se tornar o Sprint Backlog. Explico: durante a Sprint Planning o Product Owner explica quais são as prioridades do Product Backlog.

Sobre cada história priorizada, o time clica nela e deve discutir quais as tarefas serão necessárias para que seja possível estimar o esforço (campo Estimate) de entrega daquela história.

Uma técnica muito comum utilizada para estas estimativas é a de Planning Poker, já citada aqui no blog. Caso o Time de Desenvolvimento julgue útil, eles podem “quebrar” as User Stories em Sub-Tasks dentro da própria visão da User Story que contém um link “Create Sub-Task”, abrindo a tela abaixo.

Aqui você define um nome para a sub-task e sua descrição, sendo que você pode adicionar estimativas para as sub-tasks depois, se quiser. As estimativas, em especial a da histórias, compõem o esforço da sprint e são usadas mais tarde para geração de gráficos e extração de métricas ágeis importantes para o time. Se você optar por quebrar e/ou estimar as tarefas é uma decisão do time, mas essa atividade é auxiliar para descobrir o esforço da história. Entende-se que somente a entrega completa da história agrega valor ao cliente e consequentemente nos permite dar uma sprint como bem sucedida.

Após descobrir o esforço de cada uma das User Stories prioritárias do P.O. (a unidade de medida padrão é Story Points, mas também pode ser configurado), o time decide qual o volume de histórias que cabem na sprint arrastando as mesmas para a parte superior do planejador de sprint, sendo que no rodapé da mesma aparece o esforço total.

Se esse time já rodou sprints anteriores usando a mecânica de pontos eles já devem ter algum histórico de velocidade. Caso contrário terão de chutar mesmo, posteriormente analisando na Sprint Retrospective o quão próximo estavam da realidade.

Uma vez definido o escopo da próxima sprint, você clica no botão azul “Start Sprint” que aparece na imagem anterior, lhe permitindo configurar os últimos detalhes desta sprint, como o Sprint Goal e as datas de início e fim.

O Time de Desenvolvimento irá trabalhar somente olhando o backlog da sprint que pode ser acessado usando o menu Active Sprint na esquerda, e via de regra, o escopo não deve ser mudado durante o desenvolvimento da mesma. Nessa tela de Active Sprint o time tem um Kanban virtual que apesar de não ser tão bom de usar quanto o Trello, é bem útil e completamente personalizável, o que pode ser assunto para outro post.

Boas Práticas

Algumas boas práticas para quem está começando a usar o Jira Software agora e até mesmo está começando com Scrum:

• Como Product Owner, refine o seu backlog quase que diariamente, detalhando as histórias mais importantes, consultando o time sobre o impacto de cada uma delas, consultando os stakeholders, analisando o mercado, etc. O seu backlog sempre deve estar atualizado, priorizado e visível antes de uma Sprint Planning for começar.
• Cada história pode estar associada a um membro do time (campo Assigned To). Converse com seu time para que ninguém associe mais de uma história a si mesmo para evitar problemas.
• Como Product Owner, use e encoraje os três níveis de backlog, isso ajuda a deixar tudo mais organizado e ao time entender para onde o projeto está caminhando.
• Priorize visualmente o seu backlog, deixando o que é mais prioritário no topo. Apesar de existir campos que auxiliam nisso, as demais configurações são facilmente negligenciadas por não serem muito visuais.
• Use o padrão de User Stories em suas Issues para focar na entrega de valor para o usuário final e facilitar o entendimento dos requisitos por parte do Time de Desenvolvimento.
• Estime em Story Points as suas histórias e não em horas. Isso tem uma série de benefícios mas principalmente descola alguns conceitos de chão de fábrica como produtividade em horas.
• use Tags (tem um campo pra isso) nas suas User Stories para facilitar consultas, relatórios e dashboards mais tarde (aba Reports). Use a imaginação, tags podem ser qualquer coisa.
• não se preocupe em usar tudo que a ferramenta oferece, aprenda o básico que faz sentido pra você e depois vá usando o restante conforme for necessitando.

Espero que tenham gostado do post e até a próxima!

Neste artigo ensino como manter um bom nível de qualidade e detalhamento do backlog. E se você quer se aprofundar no uso de Jira, neste artigo ensino como criar automações.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!