Como nossa equipe de desenvolvimento mudou do Jira para o MOGU

Escolha da solução

Nossa fascinante história começou quando o Jira deixou a Rússia. Isso contribuiu para uma rápida decisão de procurar um novo serviço. Precisávamos transferir os processos para o produto da forma mais simples possível. Analisamos muitas opções, mas não conseguimos encontrar nada adequado para nós. Descobrimos que a solução para o nosso problema estava na superfície.

A mudança para o MOGU não foi apenas um desafio, mas também uma etapa empolgante no desenvolvimento da nossa equipe de desenvolvimento. A ideia de usar nosso próprio produto parecia lógica, e tomamos essa decisão com certa coragem e confiança no sucesso.

Dificuldades de transição

Foi assim que nossa história de transição começou. Não quero dizer que tudo foi tranquilo, algumas funcionalidades estavam faltando para um trabalho confortável. Mas, considerando nosso roteiro, sabíamos que muito mais funcionalidades seriam adicionadas em um futuro próximo.

Encontramos problemas para importar dados do Jira para o MOGU, o que causou alguns atrasos e a necessidade de fazer esforços extras para transferir informações.

Apesar das dificuldades, o resultado foi impressionante. Nós nos adaptamos rapidamente e acabamos descobrindo muitos benefícios. Um dos principais foi a maior flexibilidade na personalização do MOGU de acordo com nossas necessidades. Pudemos adicionar facilmente novos campos, personalizar fluxos de trabalho e adaptar o sistema aos nossos requisitos exclusivos.

No Jira, uma maneira de ampliar a essência de uma tarefa era adicionar campos personalizados de vários tipos (texto, link, número etc.). Usávamos ativamente esse recurso e queríamos fazer algo semelhante no MOGU. Na época da migração para o MOGU, os campos personalizados precisavam ser aprimorados, por exemplo, não havia a possibilidade de alterar a ordem dos campos personalizados. Essa limitação nos impedia de organizar os campos na ordem correta, o que era importante para o nosso fluxo de trabalho.

Além disso, tivemos um problema com os nomes das ramificações no GitLab. Para tornar o processo mais gerenciável, decidimos incorporar chaves de tarefas em nossas ramificações. Também ouvimos ativamente nossos usuários, e houve ocasiões em que as ideias deles estavam totalmente alinhadas com as nossas.

A interface simples e intuitiva do MOGU também foi um argumento importante a favor da mudança.

Como nossa equipe se apaixonou pelo Kanban

Primeiramente, criamos um quadro DEV e adicionamos desenvolvedores, designers, testadores e pessoal de produto a ele.

Então, o voo da fantasia começou. A primeira coluna é Roadmap. Todo mundo sabe o que é, portanto, não vamos nos alongar sobre ele. Em seguida, temos a coluna Ready For Dev – aqui colocamos as tarefas para as quais os requisitos já foram definidos. O desenvolvedor responsável só precisa mover essa tarefa para sua coluna.

Backend, Frontend – tudo está interconectado aqui, um desenvolvedor de backend transfere uma tarefa do Ready For Dev para ele mesmo, executa-a e a passa para os desenvolvedores de Frontend. Em seguida, passamos para o estágio Ready for Test (Pronto para teste). Quando o desenvolvimento estiver concluído, faremos o teste. Primeiro, testamos o design: o componente visual do recurso deve corresponder ao layout (botões, espaçamento, cores). Em seguida, o testador entra em ação e verifica a funcionalidade.

Se tudo estiver correto e todos os estágios forem aprovados, a tarefa é movida para a coluna final – Done. Mas há ocasiões em que a tarefa precisa ser melhorada e, então, ela é movida de volta para o estágio em que o bug foi detectado.

Trabalho com bugs ou quadro de bugs

Outra placa obrigatória para nós é a de bugs. O cenário é muito semelhante ao da placa de desenvolvimento, exceto por algumas nuances. O quadro tem um sistema de bugs que depende do nível de criticidade, do mais baixo ao mais alto (que precisa ser resolvido com muita urgência). Há uma planilha diferente para cada nível.

No final do sprint, cada desenvolvedor pega de 2 a 3 bugs para trabalhar. É claro que os bugs críticos são resolvidos instantaneamente. Essa estrutura permite não acumular dívida técnica e melhorar a qualidade do produto em um tempo mínimo.

Conclusão

Agora, seis meses após a transição, podemos dizer com confiança que a decisão de usar o MOGU para gerenciar o processo de desenvolvimento foi a correta – obtivemos um sistema simples e flexível que atende exatamente aos nossos requisitos.

Nosso estudo de caso confirma mais uma vez que um rastreador de tarefas é uma ótima ferramenta para uma equipe de desenvolvimento. Inscreva-se, convide sua equipe e divirta-se com seu trabalho!