Jira contra o caos no desenvolvimento: como não perder tarefas

Em um artigo anterior , eu disse a você que complementos para o Jira criamos para que o fluxo de trabalho se torne o mais conveniente possível e o ticket seja exaustivamente informativo. No artigo de hoje, resolveremos outro problema.

Dado:

• Você desenvolve e suporta um produto de software complexo que é executado em vários clientes.
  
• você tem várias equipes de engenharia (back-end, operações de TI, iOS, Android, web etc.) que trabalham independentemente entre si com pendências em separado;
  
• você tem várias linhas de produtos, ou seja, um gerente de produto lidera vários projetos em sua própria direção, outro gerente - à sua maneira;
  
• suas equipes de engenharia são funcionais, ou seja, não são alocadas para áreas de produto separadas, mas resolvem as tarefas de todas as unidades de uma só vez, atendendo a uma certa parte da pilha tecnológica;
  
• e é claro que você usa Jira!
  

Os problemas:

• os participantes do processo não entendem em quais peças de engenharia o recurso consiste e o que mais precisa ser feito no projeto no momento;
  
• as equipes de engenharia trabalham no mesmo projeto de forma assíncrona: uma equipe pode terminar sua parte há um mês e a segunda não pode nem começar a sua própria porque se esqueceu da peça no fluxo de tarefas mais importantes.
  

Há um problema óbvio com a transparência do processo de desenvolvimento. Quando existem muitos projetos e orientações, a necessidade de algum tipo de instrumento mágico que elimine o caos e dê uma imagem clara é especialmente aguda. Infelizmente, nossa experiência mostra que os recursos padrão do Jira não lidam totalmente com isso.

Isso é familiar? Vamos pensar no que podemos fazer sobre isso.

Estrutura do projeto

Analisarei o problema usando o exemplo de desenvolvimento no Badoo. Então, como é o trabalho do projeto? Quais estágios o projeto passa? Em que peças um novo recurso típico consiste em exigir a participação de várias equipes?

Ideia e design

O gerente de produto (PM), tendo apresentado o que pode ser aprimorado no produto, cria um ticket PROD com o tipo Project em Jira. A descrição desse ticket consiste em um único link para uma página no Confluence (um análogo do Wiki do Atlassian que se integra ao Jira). A esta página chamamos PRD (Documento de Requisitos do Produto). É um elemento chave do desenvolvimento. De fato, esta é uma descrição detalhada do que resta a ser feito na estrutura do projeto.


Ao criar este documento, o PM trabalha em estreita colaboração com o designer. Para isso, outro ticket PROD com o tipo Design é criado. Nele, o designer coloca layouts, conjuntos de ícones etc. Esses elementos são inseridos no PRD para maior clareza e também são usados ​​pelas equipes de engenharia em desenvolvimento.

Após redigir o documento, o MP o submete à discussão pública. Normalmente, outros PMs e líderes de equipes de engenharia participam da conversa. A discussão está diretamente nos comentários sobre o PRD. Isso é conveniente, porque o histórico de correspondência permanece e todos os participantes interessados ​​recebem notificações quando novos comentários aparecem. Com base na discussão, as alterações acordadas são feitas no PRD original.

Quando todas as nuances são esclarecidas, o ticket PROD inicial é convertido no backlog do desenvolvimento pendente. Depois disso, uma vez por semana, a equipe de produtos classifica esse backlog de acordo com a prioridade, de acordo com os objetivos da empresa, a exaustão estimada e a complexidade da implementação. Os projetos reconhecidos como os mais promissores passam para a próxima etapa - decomposição. Para isso, um ticket MAPI especial (Mobile API) é criado para a equipe de arquitetos de sistemas.

É importante observar aqui que, para criar tickets mais rapidamente relacionados ao projeto e eliminar o fator humano (eles esqueceram algo, vincularam ou marcaram incorretamente), automatizamos esse processo. Assim, por exemplo, o ticket raiz do projeto no cabeçalho possui dois botões adicionais.



O primeiro cria um ticket para designers, o segundo para arquitetos de sistemas. Nesse caso, novos tickets são preenchidos automaticamente com os atributos necessários: os rótulos corretos, um link para o PRD, um modelo de descrição e o mais importante - são vinculados entre si.

Essa otimização de fluxo é implementada com base no plug- in Jira ScriptRunner , sobre o qual escrevi em um artigo anterior .

Decomposição

Após receber um novo ticket MAPI com um PRD anexado, os arquitetos do sistema decidem:

• qual parte da lógica deve ser implementada no lado do servidor e qual parte no lado do cliente;
  
• quais comandos o cliente deve enviar e quais respostas ele deve receber do servidor;
  
• quais tokens devem ser "conectados" ao cliente e quais devem vir do lado do servidor.
  

Muitas vezes, nesta fase, ocorre uma alteração no PRD. Os arquitetos se aprofundam nos detalhes da implementação do que quando discutiram o PRD. Portanto, pode-se concluir que, para atingir os objetivos de negócios do projeto, é possível, abandonando parte dos requisitos iniciais, simplificar significativamente o desenvolvimento. Nós realmente apreciamos esta iniciativa.

Você pode aprender mais sobre como nossa equipe de arquitetos trabalha e ver nossa descrição da API no relatório .

Os resultados do trabalho dos arquitetos de sistemas são:

1. A aparência da documentação técnica completa do projeto (uma descrição do protocolo de interação cliente-servidor com referência aos casos de lógica de negócios descritos no PRD).
   
   
   Captura de tela de parte da documentação de um de nossos recursos atualmente inativos

   
   
   
   
2. Protocolo modificado (arquivo no formato Google Protocol Buffers) nos repositórios. Se novos recursos ou alterações nos antigos forem necessários para implementar os recursos, eles estarão disponíveis para os desenvolvedores de todas as equipes.
   
3. Ingressos para equipes de desenvolvimento e localização. Para isso, temos uma interface especial que permite criar os tickets necessários para todas as equipes envolvidas ao mesmo tempo. Ele é aberto por um link de um ticket MAPI.
   
   
   
   Ao clicar nele, a seguinte interface criada por nós é aberta:
   
   
   
   Ao clicar no botão na parte inferior do formulário (não é visível na captura de tela), os tickets necessários aparecerão, que serão automaticamente vinculados ao ticket MAPI original. Vale ressaltar que todas as equipes de desenvolvimento trabalham em nosso próprio espaço (projeto) Jira: a equipe de back-end está em SRV, a equipe de Android está em AND, a equipe de web está na Web etc.
   
   A interface é baseada na API REST do Jira.
   

Assim, a estrutura do projeto pode ser descrita como o seguinte diagrama:

Desenvolvimento e lançamento

No caso geral, todas as equipes podem trabalhar em um projeto em paralelo, tocando apenas no estágio final de integração, ou seja, as equipes clientes não precisam esperar que um servidor finalizado faça sua parte. Como o protocolo de interação é descrito em detalhes, durante o desenvolvimento, é possível emular com segurança a resposta esperada do servidor e a lógica do cliente de depuração. Além disso, o servidor não precisa de um cliente durante o desenvolvimento - o programador do servidor simplesmente implementa o protocolo e o cobre com testes, emulando solicitações de clientes.

Normalmente, um recurso é iniciado no seguinte cenário:

1. O servidor é o primeiro a dispor sua parte da funcionalidade, coberta pelo sinalizador de recurso, na produção. Portanto, essa lógica permanece ociosa até que um dos clientes comece a enviar esse sinalizador de recurso.
   
2. As equipes do cliente antes do lançamento na produção testam sua parte da funcionalidade já no servidor de "batalha".
   
3. Assim que pronto, diferentes clientes são liberados, comece a enviar o sinalizador de recurso desejado e a receber uma nova resposta do servidor.
   

A possibilidade de trabalho síncrono no projeto é uma enorme vantagem, que pode aumentar significativamente a eficiência do desenvolvimento. Mas aqui está o risco: algumas equipes podem "escrever para a mesa", ou seja, fazer sua parte do trabalho, que nunca será demandada por outros participantes do projeto. Pode haver vários motivos:

• prioridades diferentes para equipes de desenvolvimento; problemas geralmente não surgem quando se trabalha em projetos que são super importantes para a empresa (todos são bem conhecidos e difíceis de esquecer), mas os menos importantes podem ser colocados no backlog local de uma equipe separada nos últimos lugares;
  
• erro de gerenciamento de projeto: o gerente pode simplesmente esquecer de priorizar corretamente as tarefas da equipe de desenvolvimento, ou seja, seus participantes nem saberão que o ticket deve ser levado para o desenvolvimento o mais rápido possível.
  

Como nivelar esses problemas? Como garantir que as partes do projeto não sejam perdidas e as equipes prestem a devida atenção aos projetos prioritários?

Recursos padrão do Jira

O que a funcionalidade Jira padrão oferece ao gerente de projetos para resolver esses problemas? Nem tanto:

• Filtros
  
• placas kanban.
  

Filtros

O filtro permite que você veja uma lista linear de tickets recebidos para uma consulta JQL arbitrária. Essa ferramenta é muito conveniente para atender o backlog de uma equipe, mas não sei como usá-la para o gerenciamento de projetos de alta qualidade, distribuído por diferentes equipes. O máximo que um gerente pode fazer é exibir uma lista priorizada de tickets PROD raiz, e então você precisa entrar em cada um deles, observando os tickets vinculados. Mas isso é extremamente inconveniente e longo, especialmente considerando que a hierarquia de links pode ser de várias histórias. Além disso, a equipe de desenvolvimento pode criar vários tickets adicionais para resolver a tarefa inicial, e seu status também deve ser monitorado.

Kanban boards

Para quem não sabe como isso funciona em Jira, vou explicar. Em geral, esta é uma lista de tarefas com base em um filtro específico, agrupadas em três colunas: "Backlog", "Tarefas em desenvolvimento", "Tarefas concluídas". A interface permite aumentar a prioridade das tarefas, simplesmente arrastando um ticket na lista com o mouse. Ao mesmo tempo, a propriedade Classificação é alterada, pela qual você pode classificar os tickets nos seus filtros.

Aqui já temos muito mais espaço para usar a ferramenta no contexto da tarefa em questão. O PM pode criar um filtro que seleciona todas as tarefas de todos os departamentos na direção desejada. Isso pode ser feito, por exemplo, colocando bilhetes automaticamente com as etiquetas correspondentes. Lembro que todos os principais tickets do projeto são criados usando as ferramentas apropriadas. Portanto, copiar automaticamente os rótulos necessários do ticket PROD raiz para todos os tickets derivados é uma tarefa técnica trivial.

Usamos placas kanban para formar e controlar pedidos em atraso de equipes de engenharia. Usando a ferramenta Swimlanes, uma placa pode ser agrupada em projetos que correspondem às equipes de engenharia. Assim, usando essa ferramenta, o PM pode monitorar o andamento de seus projetos no contexto de diferentes equipes, bem como priorizar tickets de equipe.


Esquema de um quadro Kanban de produtos no qual os tickets de projetos de MP são agrupados por equipes

O problema é que a ferramenta não oferece uma maneira fácil de agrupar tickets por tickets PROD de origem, ou seja, por recursos: desejo monitorar o progresso de cada projeto individualmente em todas as equipes de engenharia.

Excel

A solução mais óbvia é usar planilhas. Afinal, você pode fazer tudo o que quiser: conveniente, bonito, informativo. Algo assim:



Você pode ver o escopo geral do trabalho para cada projeto em um só lugar. Você pode fazer várias anotações, riscar bilhetes concluídos etc. Tudo aqui é bom, exceto por um ousado, mas: manter a relevância de tais tabelas é extremamente difícil. Os status dos tickets estão mudando constantemente, novos estão sendo criados. Fazer manualmente todas as alterações? Você pode gastar o dia todo. Mas nós somos pela eficiência, certo?

"E vamos atravessar!"

Por que não usamos a conveniência e a clareza das planilhas adicionando sincronização automática com o Jira? Temos todas as possibilidades para isso! Por isso, decidimos criar uma ferramenta adicional baseada na API REST do Jira, que mantém automaticamente o estado atual das informações e possui uma interface conveniente para nós.

Os requisitos da ferramenta foram os seguintes:

• a capacidade de criar listas de projetos e seus derivados a partir de tickets de acordo com consultas JQL arbitrárias (isso é necessário para que qualquer PM possa criar seu próprio espaço (unidade) no qual apenas verá seus projetos e os gerencie);
  
• novos projetos em Jira devem aparecer automaticamente na interface;
  
• novos tickets no projeto devem aparecer automaticamente na interface (ou seja, se a equipe de desenvolvimento decidir que mais tickets são necessários para implementar o recurso, o PM o verá imediatamente na interface);
  
• dependendo do status dos tickets, as cores das células da tabela devem mudar (para uma rápida compreensão dos participantes do status do projeto);
  
• a capacidade de classificar projetos (priorizá-los adequadamente);
  
• ocultação automática de projetos concluídos duas semanas após a conclusão.
  

O PM começa a trabalhar com a ferramenta, criando seu próprio espaço (unidade), indicando seu nome e consulta JQL:



Em seguida, é feito um pedido ao Jira para obter uma lista de projetos para a consulta JQL especificada. Também usando links no Jira estão todos os tickets derivados das equipes de engenharia. O resultado é algo como esta tabela:



Acima estão os links para alternar entre as unidades.

As linhas da tabela são os tickets PROD raiz da unidade. Nas células, vemos as tarefas do projeto para departamentos de engenharia específicos. O preenchimento ocorre automaticamente, sujeito às regras para vincular os tickets do projeto. As etapas concluídas são marcadas em verde, não iniciadas em vermelho e atual em amarelo.

Os links levam a ingressos para Jira. Você também pode obter informações breves sobre o ticket, passando o mouse sobre o link:



Com uma frequência de uma vez a cada poucos minutos, uma solicitação é feita à API do Jira para obter uma lista atualizada de projetos para todas as unidades, para sincronizar a lista de tickets derivados, bem como seus status atuais.

A classificação é feita simplesmente arrastando e soltando o projeto desejado no local desejado na lista:



É importante observar que, com essa ferramenta no Badoo, não apenas os gerentes de produto trabalham, mas também os líderes das equipes de engenharia. Afinal, é importante que todos entendam o que está acontecendo nas áreas de produtos, quais equipes avançaram na implementação de projetos importantes para a empresa mais do que outros e quais estão atrasadas.

Conclusões

Jira "pronto para uso" fornece funcionalidade poderosa para gerenciar a estrutura do projeto e o relacionamento entre os tickets. Também existem plugins que expandem significativamente os recursos do JQL (por exemplo, eles permitem o uso de links entre tickets e seus tipos para filtrar tickets). No nosso caso, nos faltava apenas a capacidade de visualizar tudo o que precisávamos.

Felizmente, o Jira permite criar ferramentas convenientes adicionais baseadas em sua API, adaptadas aos processos de negócios da empresa. Assim, por exemplo, fomos capazes de resolver o problema que surgiu com a transparência da condução de projetos em uma dúzia de áreas de produtos, com um pouco de esforço e usando os recursos adicionais desse rastreador de tarefas. Seria interessante ler nos comentários se você tentasse fazer esses complementos em seu local ou encontrasse outras soluções para suas tarefas.

Obrigado a todos pela atenção!