Automação do Processo de troca de status das Histórias

[Fabrício Diego Ferreira]

Olá, comunidade.

Atualmente, estou trabalhando em uma empresa onde seu fluxo de status das histórias é muito grande. São 19 status, o que na minha visão, torna tudo muito confuso e diminui muito a visibilidade do time em relação ao andamento daquela história.

Pensando nisso, há alguma forma de automatizar esse processo, no sentido de que sempre que houver uma troca de status, o responsável seja notificado?

Porque, por exemplo, há alguns status que são de responsabilidade do desenvolvedor naquele momento, assim como há momentos que é de responsabilidade do QA.

Hoje o JIRA notifica via e-mail, de maneira genérica (e para todos do projeto) que houve uma mudança do status daquela história, mas não aponta para a pessoa exata que deve ter ação naquele momento.

Pensando nisso, há alguma forma de melhorar o processo de visibilidade em relação a história x responsável no JIRA? Apontando para o responsável exato sempre que houver uma mudança de status?

Muito obrigado!

[Trudy Claspill · Accepted solution]

Olá @Fabrício Diego Ferreira ,

Eu encorajaria você a conversar com sua equipe e gerentes de projeto sobre como redesenhar o fluxo de trabalho para reduzir os status.

Se isso não for uma opção, podem ser criadas regras de automação acionadas por alterações de status, e os acionadores podem ser configurados para limitar a regra com base no status inicial e/ou no status final. A regra também pode enviar um email.

Você deve ser capaz de identificar para quem esse e-mail deve ser enviado. Como saber qual pessoa específica é responsável por um determinado problema com base em seu status? Você tem campos de usuário adicionais no problema onde especifica o desenvolvedor e o controle de qualidade para cada problema?

No entanto, noto que você marcou sua postagem para indicar que está na assinatura gratuita. Na assinatura Gratuita há limites de quantos e-mails podem ser enviados em um período de 24 horas, e isso inclui notificações e e-mails que você enviaria por meio de regras de automação. Além disso, há um limite de quantas execuções de regras são permitidas a cada mês.

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

Você precisará considerar esses limites para determinar se pode usar regras de automação de maneira eficaz para essa finalidade.

---

Hello,

I would encourage you to talk with your team and project managers about redesigning the workflow to reduce the statuses. 

If that is not an option, Automation rules can be created that are trigged by status changes, and the triggers can be set to limit the rule based on the starting status and or the ending status. The rule can also send an email.

You must be able to identify to whom that email should be sent. How do you know which specific person is responsible for a given issue based on its status? Do you have additional User fields in the issue where you specify the developer, and the QA, for each issue?

However, I do notice that you tagged your post to indicate you are on the Free subscription. In the Free subscription there are limits on how many emails can be sent in a 24 hour period, and that includes both notifications and emails you would send through Automation rules. Additionally there is a limit on how many rule executions you are permitted each month.

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

You will need to consider those limits to determine if you can effectively use Automation Rules for this purpose.

Automation of the Stories status change process

Hello, community.

I'm currently working at a company where their Stories status stream is very large. There are 19 statuses, which in my opinion makes everything very confusing and greatly reduces the team's visibility in relation to the progress of that story.

With that in mind, is there any way to automate this process, so that whenever there is a status change, the person responsible is notified?

Because, for example, there are some statuses that are the responsibility of the developer at that moment, just as there are moments that are the responsibility of QA.

Today, JIRA notifies via email, in a generic way (and to everyone in the project) that there has been a change in the status of that story, but it does not point to the exact person who should take action at that moment.

With that in mind, is there any way to improve the visibility process in relation to story x owner in JIRA? Pointing to the exact person responsible whenever there is a status change?

Thank you very much!

[Fabrício Diego Ferreira]

Olá, Trudy. Como vai? Espero que se encontre bem.

Primeiramente, eu gostaria de agradecê-lo pela disponibilidade em ajudar.
-

O redesenho do fluxo de histórias já está sendo discutido. Mas acredito que ainda levará um tempo para que mudanças grandes e efetivas sejam feitas.

Eu tenho todas as respostas para "Você deve ser capaz de identificar para quem esse e-mail deve ser enviado. Como saber qual pessoa específica é responsável por um determinado problema com base em seu status? Você tem campos de usuário adicionais no problema onde especifica o desenvolvedor e o controle de qualidade para cada problema?"

E, eu publico aqui dúvidas utilizando minha conta pessoal, mas o cenário que descrevi se aplica à uma conta corporativa. As soluções deste fórum seriam aplicadas no projeto prático da empresa.

[Trudy Claspill]

Olá Fabrício,

Estou bem. Espero que você esteja bem também.

Com uma assinatura paga ainda existem limitações no número de execuções de regras. O limite específico depende do tipo de assinatura paga. As informações estão no link do documento que forneci.

Forneci informações suficientes para você trabalhar no desenvolvimento de regras de automação? Vejo que não forneci um link para a documentação para isso. Aqui está esse link:

https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

Se você tiver mais perguntas, não hesite em perguntar.

---

Hello Fabricio,

I am well. I hope you are well also.

With a paid subscription there are still limitations on the number of rule executions. The specific limit depends on the type of paid subscription. The information is in the document link I provided.

Did I provide enough information to you for you to work on the development of Automation Rules? I see I did not provide a link to the documentation for that. Here is that link:

https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

If you have more questions don't hesitate to ask.

Hello, Trudy. How are you? I hope you are well.

Firstly, I would like to thank you for your willingness to help.
-

The redesign of the story flow is already being discussed. But I believe it will still take some time for big, effective changes to be made.

I have all the answers to "You must be able to identify who this email should be sent to. How do you know which specific person is responsible for a particular issue based on their status? Do you have additional user fields in the issue where you specify the developer and QA for each issue?"

And, I post questions here using my personal account, but the scenario I described applies to a corporate account. The solutions from this forum would be applied to the company's practical project.

[Sholeh oleole]

Saya akan merespon