Suspensão da Descrença

Tickets no Jira tendem a acumular campos redundantes e opcionais, ficando complexos e confusos. Gosto do Jira, mas compreendo a frustração que isso causa. Por isso, inspirado pelas , sugiro aplicar a abordagem de criar tíquetes menores.

Apenas três estados

Uma maneira de limitar o tamanho dos tickets é simplificar o workflow restringindo o número de estados. Por exemplo, podemos definir que cada tipo de tíquete teria, no máximo, três estados:

• A fazer
• Em progresso
• Concluído

Para representar outros estágios, podemos criar de novos tipos de tíquetes, como subtarefas.

Um tipo de tíquete medianamente complexo

Vejamos um exemplo. Considere o tíquete abaixo:

Ele seguiria por este workflow:

Como poderíamos reduzir o número de fases?

Podemos começar removendo estágio “Em análise. No seu lugar, criamos um novo tipo de tíquete, chamado “Análise Técnica”. Assim, a tarefa original ficará em execução (“Fazendo”) enquanto a análise técnica estiver em andamento.

Menos campos em um tíquete

Uma vantagem disto seria transferência de campos para subtarefas. Campos que se misturariam no tíquete original apareceriam apenas nas tarefas em que são relevantes.

Considere o campo “Data de lançamento”, que só faz sentido na fase “A Lançar”. Se desenvolvedores, testadores etc. não são responsáveis pelo lançamento, este campo é confuso e polui a tarefa original. Com um novo tipo de tarefa chamado “Release“, esse campo estaria no lugar mais apropriado, mantendo o tíquete original sucinto.

Repetindo estágios sem regredir

Outra vantagem é que o ticket original pode passar pelo mesmo “estágio” várias vezes. É comum um tíquete ter uma fase de desenvolvimento, seguida por testes de qualidade, por exemplo. Só que, se surgir um problema na avaliação, não é recomendável retroceder à fase de desenvolvimento. Como lidar com isso?

Ao trabalhar com subtarefas, podemos marcar a validação como concluída e criar um novo tíquete de implementação. No nosso tíquete, por exemplo, podemos remover a fase “Em teste” e criar uma subtarefa do tipo “Testagem”, assim como uma outra chamada “Desenvolvimento”. Cada vez que o teste falhar, fechamos a testagem e abrimos uma nova tarefa de desenvovimento.

Resultado

Seguindo esta estratégia, nosso tíquete ficaria assim:

E o workflow ficaria bem mais simples:

Naturalmente, esta estratégia é flexível. No nosso caso, por exemplo, não removemos a fase “A fazer” ainda. Restringir a cinco (incluindo backlog e validação) é outra possibilidade, mas não muito mais que isso.

Conclusões

Em programação, é comum encontrar os chamados “God objects“, objetos enormes que são responsáveis por várias funções diferentes. Quebrá-los é uma maneira segura de obter qualidade de código. Por isso, suspeito que o mesmo princípio pode se aplicar a tíquetes no Jira.

Não sou o gerente de projeto, mas como programador, acredito que limitar o tamanho e os passos dos tickets pode ser uma ideia eficaz. Fico curioso para saber se alguém já experimentou isso e como foi.