Trello vs. Jira: Comparado da perspectiva de um desenvolvedor

A produção de software hoje não é a mesma de 20 anos atrás. O software tornou-se cada vez mais complexo, com equipes distribuídas literalmente em todo o mundo e dependentes de pessoas especializadas apenas em uma parte específica do processo. Além disso, UI/UX tornou-se uma questão muito importante à medida que aumenta a competição pela captura de novos usuários e retenção dos atuais.

Ao longo do ano passado, trabalhei em uma dúzia de projetos e quase todos eles usaram uma ferramenta de gerenciamento de projetos (PMT). Não vou dar a você um discurso de vendas para uma ferramenta específica hoje, mas sim uma visão interna da perspectiva de um desenvolvedor de como essas ferramentas são usadas na vida real, bem como uma visão geral de dois representantes Ferramentas. Esperamos que este artigo ajude os tomadores de decisão e desenvolvedores a descobrir o que é mais conveniente para eles, sua equipe e o projeto em que estão trabalhando.

Por que usar uma ferramenta de gerenciamento de projetos?

Quando eu estava começando, a maioria dos meus projetos não dependia de uma ferramenta de gerenciamento de projetos, então você pode estar se perguntando se realmente precisa de uma. Os desenvolvedores não podem simplesmente criar software sem eles? A resposta é que depende de vários fatores, então vamos analisar alguns deles.

A ascensão das equipes globais

Na maioria dos projetos, trabalho para pessoas ao redor do mundo e, embora isso seja realmente incrível, também apresenta uma série de desafios que uma equipe de escritório não enfrentará. Os fusos horários tornam-se um problema real quando você está tentando fazer com que um colega conserte ou modifique alguma parte do sistema na qual você não é suficientemente proficiente.

Há também cenários em que você pode não conseguir falar com o outro desenvolvedor mais de uma ou duas vezes por semana. As ferramentas de gerenciamento de projetos ajudam a tornar esses processos colaborativos mais fáceis porque se tornam um canal oficial (e, por motivos práticos, às vezes o único) para os membros da equipe comunicarem suas necessidades.

É claro que não se trata apenas de comunicação entre membros individuais de uma equipe distribuída. Os PMTs também fornecem mais informações e visibilidade a todos os membros da equipe, permitindo que eles acompanhem o progresso de outros membros da equipe e planejem suas atividades de acordo.

Colaboração

Você pode estar pensando que pode obter os mesmos resultados simplesmente colaborando por e-mail ou outros canais de comunicação. Um cliente meu fez isso em um projeto em que trabalhei alguns meses atrás, e foi um pesadelo. As pessoas usavam vários e-mails para se comunicar, então era difícil acompanhar os diferentes tópicos. Além disso, a comunicação sobre um único problema se torna um quebra-cabeça dividido em diferentes peças que vivem em diferentes conversas de e-mail. A maioria das conversas por e-mail tocava em vários problemas, o que tornava cada vez mais difícil acompanhar o que restava a ser feito.

As ferramentas de gerenciamento de projetos resolvem isso com um fluxo de conversa dedicado a cada problema, facilitando sua vida, pois permitem encontrar tudo o que você precisa (designs, APIs e feedback) em um único clique. Do ponto de vista colaborativo, isso pode fazer uma enorme diferença, pois as ferramentas de gerenciamento de projetos permitem que todos acessem e visualizem todos os segmentos e etapas do projeto, reduzindo a necessidade de comunicação e atualizações constantes.

Gerenciar requisitos do projeto

Um dos maiores problemas enfrentados pelas equipes que não utilizam uma ferramenta de gerenciamento de projetos é causado pela natureza intrínseca do software. Talvez você esteja trabalhando em uma startup e tenha feito pivot mais de algumas vezes. Talvez seus objetivos e requisitos continuem evoluindo à medida que você trabalha no projeto.

Nesse contexto, devemos pensar no software como um ser vivo. Independentemente de quão bem o plano inicial foi elaborado, sempre há uma boa chance de que ele precise mudar. No entanto, às vezes essas mudanças não estão sendo comunicadas a todos os membros da equipe. Os executivos podem conversar sobre um novo recurso que lhe dará uma vantagem sobre seus concorrentes, mas se o gerente não expressar isso para o restante da equipe, isso não acontecerá.

Se não fosse escrito, poderia até ser esquecido pelo gerente e pelo CEO também. Não ter um lugar onde você tenha o que há de mais recente e os requisitos oficiais fará com que você perca muito tempo e dinheiro. Os PMTs oferecem um único ponto de verdade, um único local onde todos os requisitos e informações são armazenados durante a duração do projeto. Não se trata apenas de recursos que não foram adicionados e que você pode adicionar mais tarde - desenvolvi recursos inteiros apenas para descobrir que não me disseram que não daríamos mais suporte a esse recurso.

Memória e eficiência de tempo

A tinta mais pálida é mais confiável do que a memória mais poderosa. – Provérbio

Nós só podemos lidar com tanta coisa em nossa cabeça de cada vez. Quando você tem uma ligação com seus gerentes e eles trazem à tona uma dúzia de questões diferentes durante a conversa, em algum momento, algo vai se perder. Você pode tentar anotar os pontos mais importantes, mas ainda assim, algo pode falhar.

Ter os requisitos anotados em vez de falar sobre eles em uma chamada é uma boa maneira de detectar possíveis elementos ausentes no fluxo ou detectar coisas que podem impedir você de implementar esse problema no momento. O desenvolvimento de software não é linear, então você pode começar a trabalhar em um recurso hoje, mas ter algo mais urgente para trabalhar no produto e voltar algumas semanas ou meses depois apenas para perceber que esqueceu exatamente o que era necessário.

É por isso que ter requisitos escritos pode economizar seu tempo, seja por não ter que lembrar ou por evitar ter que discutir o mesmo recurso novamente. A eficiência do tempo é muito importante porque o software é mais complexo, então você pode aproveitar apenas ter as coisas escritas, para reduzir o tempo da reunião pela metade ou mais, concentrando-se apenas nas questões que você precisa esclarecer.

Foco

Isso está relacionado ao problema anterior de acompanhar a comunicação relacionada ao problema que está sendo abordado e apenas acompanhar os recursos de requisitos futuros sem que você precise falar sobre essas coisas.

Isso ajuda o desenvolvedor a manter o foco na criação de coisas que são necessárias no momento e aprender o que está por vir. Não se trata apenas de conveniência e fácil acesso à informação. O nível adicional de visibilidade permite que cada membro da equipe veja o quadro geral e planeje com antecedência de acordo.

Principais recursos do PMT

Então, o que procuramos em um PMT é uma ferramenta que ajude a gerenciar a conversa, mantendo a discussão de diferentes questões separadas e bem organizadas. Isso ajuda na comunicação entre pessoas em diferentes fusos horários e diferentes equipes e, ao mesmo tempo, serve como um repositório da visão oficial do software, ajudando você a manter o foco e economizando tempo, reduzindo o atrito no processo de desenvolvimento para o desenvolvedor, gerente de projeto , e todos os envolvidos no cenário atual de desenvolvimento de software.

Jira

O Jira é um PMT muito poderoso que foi projetado especificamente para desenvolvimento de software. No entanto, nem todo mundo conhece todos os recursos do Jira e pode ser esmagador se você for proprietário de uma empresa tentando gerenciar seu primeiro projeto. Se você está lendo isso como uma pessoa decidindo entre diferentes opções, mas não usou o Jira antes, recomendo assistir a alguns tutoriais primeiro para que você possa realmente aproveitar seu poder.

Corrida

Há três palavras com as quais posso definir a maior parte da minha experiência com o Jira, e uma delas é sprint . Um sprint é um período de tempo em que a equipe trabalha para completar certos objetivos que podem estar intimamente relacionados ou não. É completamente flexível. Os sprints do Jira geralmente duram uma semana, o que, na minha opinião, é a duração ideal.

Do ponto de vista de um desenvolvedor, isso lhe dá a flexibilidade de ter várias coisas atribuídas a você e trabalhar na ordem que for mais confortável para você, que pode ser trabalhar em uma tarefa difícil e depois em uma fácil para relaxar, ou talvez trabalhar em 2 -3 que estão intimamente relacionados ao mesmo tempo. Isso permite que os desenvolvedores tomem algumas decisões, mantendo o foco ao mesmo tempo na entrega no prazo.

Épicos e problemas do Jira

Enquanto os sprints agrupam tarefas no reino temporal, os épicos podem agrupar tarefas por assunto. Por exemplo, você pode dividir suas tarefas em sprints por semana, mas também pode agrupar as tarefas ao mesmo tempo em front-end e back-end. Ao dividir tarefas por assunto, você pode atribuir um desenvolvedor a um assunto.

Por exemplo, você pode ter um épico para migrar dados de um banco de dados existente, então você pode chamar esse épico de migração de banco de dados e, como todas as tarefas nesse épico estão relacionadas, um único desenvolvedor pode ser o responsável por isso durante todo o corrida. Isso evita que dois desenvolvedores gastem tempo aprendendo o banco de dados antigo, tornando o desenvolvimento mais eficiente.

Os problemas , por outro lado, são as coisas que precisam ser feitas, que podem pertencer a um épico e a um sprint. Existem vários tipos de problemas e são história , tarefa e bug . Uma história tem a peculiaridade de ter subtarefas, que podem ser usadas para dividir um problema em partes menores que formam uma imagem completa quando tomadas em conjunto – isso evita criar um grande número de tarefas, em vez de focar em um único item a ser concluído.

As tarefas no Jira são problemas muito específicos e não têm subtarefas. Quando algo que precisa ser feito é muito simples e não faz sentido tentar decompô-lo, é uma tarefa. Bugs são coisas a serem corrigidas - manter os bugs como uma categoria especial ajudará você a entender o quanto você está corrigindo em oposição ao quanto você está progredindo no projeto.

Prioridades

A comunicação é uma grande parte da equação ao trabalhar em uma equipe global que trabalha em vários fusos horários. Trabalhar “ao redor do mundo” não é uma metáfora, mas uma realidade na qual muitos desenvolvedores vivem. Uma das coisas que é difícil de comunicar dos gerentes aos desenvolvedores é o nível de prioridade de uma tarefa. Imagine o seguinte cenário usando uma lista de tarefas:

O desenvolvedor vê que durante esta semana, eles têm sete tarefas para concluir. Alguns deles são difíceis e alguns são fáceis. Uma tarefa crítica para o gerente, no entanto, é muito complexa, mas para o desenvolvedor em uma lista de tarefas, todas as tarefas são iguais – eles podem optar pelas mais fáceis primeiro, deixando as críticas para o final. Se algo inesperado acontecer e a lista não for finalizada, é a tarefa mais importante que é cortada, ou é finalizada às pressas (provavelmente sacrificando a qualidade no processo). Isso é resolvido muito facilmente no Jira por ter prioridades , o que permite que os desenvolvedores entendam o que é mais importante ou crítico a ser concluído.

Conteúdo, Conteúdo, Conteúdo

Uma das coisas que você realmente apreciará no Jira é a quantidade de conteúdo que você pode colocar em cada edição; você pode adicionar imagens ou links, bem como marcar outros membros da equipe - embora isso também seja verdade no Trello, a interface do usuário realmente o incentiva a colocar mais conteúdo, o que ajuda a ter mais dados em cada tarefa.

Os prós e contras de Jira

O Jira é uma ferramenta muito bem estabelecida com muitos recursos que foram incorporados especificamente para o desenvolvimento de software. Ele oferece várias integrações com outros sistemas e ajuda você a se manter bem organizado. É especialmente bom para equipes (muito) grandes.

Jira, sendo um PMT capaz e repleto de recursos, pode ser um pouco assustador para um desenvolvedor iniciante. A experiência pode ser esmagadora - sprints, épicos e problemas podem se misturar. Isso é especialmente verdade se o gerente for um cliente com pouca experiência em desenvolvimento de software, tentando gerenciar uma equipe de desenvolvedores. Eu recomendo o Jira para grandes equipes e grandes projetos que levarão um tempo para serem desenvolvidos (mais de alguns meses), bem como para gerentes (clientes) e desenvolvedores experientes.

Prós

• Projetado especificamente para desenvolvimento de software
• Permite que cada edição possa ter muito conteúdo, como links, imagens, anexos
• Tem um aplicativo móvel com notificações, que ajuda você a acompanhar seus problemas o tempo todo
• Integra sprints com o núcleo do produto
• Fornece filtragem de tarefas muito intuitiva para que você possa se concentrar nas tarefas que são relevantes para você

Contras

• Tem muitos recursos, para que você possa facilmente subutilizar o software
• Requer algum treinamento para aproveitar todos os seus recursos
• Requer (ou pelo menos é ajudado imensamente por) uma compreensão do desenvolvimento ágil
• Pode ser um exagero para um projeto pequeno com uma equipe pequena

Trello

O Trello pode ser resumido em uma frase simples: “quadros com cartões”, também conhecido como Kanban . À primeira vista, pode até ser simples demais para um olho destreinado; no entanto, coisas simples podem ser extremamente úteis.

A simplicidade é um conceito poderoso. Essa é parte da razão pela qual o iPhone e o Mac se tornaram tão populares, já que seu sistema operacional era simples e agradável de usar. Enquanto o Jira parece ter tudo o que você pode pensar, o Trello parece ter apenas o suficiente para você passar. Sem épicos, sem histórias, sem sprints - você simplesmente trabalha em um cartão e o move pelos diferentes estágios (colunas).

Lembrando que tudo isso também existe no Jira, vou explicar alguns dos recursos que mais brilham no Trello.

Estágios

O Trello facilita muito a definição de estágios - basta criar uma coluna e começar a usá-la. Os mais comuns são To Do, Doing, Review e Done. Devido à sua simplicidade, você pode adicionar outras colunas como On Hold (Jira pode fazer isso também, mas parece que elas estão perdidas, a menos que você procure explicitamente por esses problemas) ou crie colunas para diferentes partes do sistema, como Todo Front-end ou Todo Back-end. Isso é excelente quando a equipe e o projeto são pequenos, como um site simples, um widget ou uma extensão, onde não há muitos membros ou tarefas para gerenciar simultaneamente.

Membros

Você pode atribuir um cartão a membros e é assim que você atribui um cartão a um desenvolvedor - muito simples. Você também pode marcar outros membros nos comentários, o que ajuda todos os envolvidos em um problema a continuar se comunicando sobre ele.

Com um único clique, os usuários podem filtrar facilmente seus cartões ou cartões pertencentes a outros membros da equipe, o que é especialmente útil na visualização do Calendário.

Muito Visual

Devido à sua simplicidade, o Trello tem o Kanban visível sempre que você abre o conteúdo de um cartão. É uma abordagem muito visual, pois você não pode escapar dessa visão. Além disso, os cartões podem ter imagens visíveis no quadro.

Isso é algo que o Jira não tem (ou pelo menos eu não vi isso sendo usado em um projeto real). Como uma imagem pode dizer mais do que palavras, você pode ver facilmente o que está acontecendo sem abrir cada ticket.

Além disso, as tags coloridas do Trello podem ser usadas para adicionar ainda mais informações sem precisar expandir um cartão. Com um pouco de boa organização, esses equivalentes Kanban de etiquetas Post-It podem ser muito úteis e poupar muitos cliques desnecessários.

Sobrecarga de informação

Devido à sua simplicidade inerente, o Trello leva você a manter as coisas simples e diretas, evitando a sensação de estar sobrecarregado por montanhas de informações. Muitas vezes, você estará trabalhando em um projeto no qual está sendo constantemente bombardeado por notificações de itens com os quais nem está envolvido.

Esse ruído extra parece ser um pouco reduzido no Trello, pelo menos na minha experiência. Como o Trello não é tão fácil de usar para adicionar informações, descobri que os problemas tendem a ser menores, o que significa que as tarefas são divididas em partes menores do que no Jira. Com algum planejamento, essas pequenas tarefas não devem gerar muito ruído.

Gamificação

O conceito de gamificação é, em parte, pegar uma tarefa simples e transformá-la em um jogo por meio do uso de recompensas. “A dificuldade não te desencoraja se for complementada com recompensas”, como apontado neste artigo no Trello Blog.

Há um aumento de adrenalina (ou dopamina) sempre que um bilhete está sendo movido de um estágio para outro. Como você não pode mover um cartão para um estágio diferente sem arrastá-lo no Trello (enquanto no Jira, é mais fácil apenas alterar o status de um problema), você obtém uma conexão física com o progresso que está fazendo. Em algum momento sem você perceber, você sente vontade de competir contra si mesmo para derrubar mais questões naquele dia do que no dia anterior (espero não estar sozinho aqui com esse sentimento) ou você apenas sente vontade de lutar para fazer a coluna de tarefas esvaziar o mais rápido possível. Muitos produtos de software usam a gamificação hoje para criar um engajamento maior, como as visualizações e curtidas na maioria das plataformas sociais – esse mecanismo de ação-recompensa é o que mantém as pessoas engajadas nas plataformas.

O bom e o mau

Ainda estou impressionado com a alegria de usar o Trello e, certamente, sua simplicidade é crucial para essa experiência. As tarefas tendem a ser menores - embora você faça o mesmo trabalho, é melhor mover três tarefas para a coluna "Para revisão" do que alterar o status de uma única história do Jira para Concluído. (Sinto que a taxa de conversão de uma história do Jira é de cerca de três cartões no Trello.)

Isso é ideal para novos desenvolvedores ou empresários que tentam gerenciar um projeto porque a barreira de entrada é muito baixa. O Trello é facilmente dominado por qualquer pessoa, engenheiro de software ou não. O problema é que o Trello pode ser muito leve para certos projetos e grandes equipes. Embora você possa criar facilmente placas adicionais, ter muitos desenvolvedores trabalhando em uma única placa pode significar problemas. Não é o mesmo, qualitativamente, que o espaço de trabalho compartilhado do Jira.

Prós

• Baixa barreira de entrada - você não precisa de nenhuma experiência
• IU simples
• Extremamente visual - você obtém a ideia imediatamente
• Ideal para pequenos projetos e pequenas equipes

Contras

• Não é uma UI/UX amigável para adicionar muitos detalhes a um problema
• Não traduz tão bem no celular, pois você precisa fisicamente de mais espaço para exibir um quadro kanban
• Não tem uma maneira (pelo menos, intuitivamente) de priorizar tarefas

Devo usar uma ferramenta de gerenciamento de projetos?

Sim, acho que na situação típica de hoje, em que o gerente ou empresário não está disponível para responder as perguntas 24 horas por dia, 7 dias por semana, você deve realmente pensar em usar uma ferramenta apenas como forma de ter um repositório onde tudo o que é necessário está anotado de forma clara. Isso ajudará você a evitar confusão ou itens perdidos porque foram esquecidos em uma conversa do Skype ou enterrados sob centenas de e-mails. Se o seu projeto for menor, como um site de hobby, um PMT pode ser um exagero.

Qual deles devo usar?

A resposta para isso é aquela que melhor se adapta às suas necessidades. Se sua equipe for composta por mais de quatro pessoas e o projeto durar mais de um ano, eu escolheria o Jira. Se esse for o seu caso, recomendo que você leia mais sobre como usar o Jira e como usar as metodologias de desenvolvimento de software.

Se sua equipe tiver menos de quatro pessoas e o projeto for um site simples, ou talvez adicionar alguns recursos a um projeto existente, recomendo o Trello devido à sua simplicidade. Como sempre, com ferramentas, ambos podem fazer o trabalho, mas isso não significa que o melhor seja o mesmo para todos.