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 por todo o mundo e dependente de pessoas especializadas apenas em uma parte específica do processo. Além disso, a UI / UX se tornou uma questão muito importante à medida que aumenta a competição para capturar novos usuários e reter os atuais.
No ano passado, trabalhei em uma dúzia de projetos e quase todos eles usaram um ferramenta de gerenciamento de projeto (PMT). Não vou apresentar um argumento de venda 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. Esperançosamente, este artigo ajudará os tomadores de decisão e desenvolvedores a descobrir o que é mais conveniente para eles, sua equipe e o projeto no qual estão trabalhando.
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.
Na maioria dos projetos, encontro-me trabalhando 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 se tornam 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.
Existem 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 razões práticas, às vezes o único) para os membros da equipe comunicarem suas necessidades de um lado para outro.
Claro, não se trata apenas de comunicação entre os 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.
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, por isso era difícil acompanhar os diferentes tópicos. Além disso, a comunicação sobre um único problema torna-se um quebra-cabeça dividido em diferentes peças em diferentes conversas por e-mail. A maioria das conversas por e-mail abordou vários problemas, o que tornou cada vez mais difícil manter o controle do que ainda precisava ser feito.
As ferramentas de gerenciamento de projetos resolvem isso tendo um fluxo de conversa dedicado a cada problema, tornando sua vida mais fácil, pois permitem que você encontre tudo o que precisa (designs, APIs e feedback) em um único clique. Do ponto de vista colaborativo, isso pode fazer uma grande 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.
Um dos maiores problemas enfrentados pelas equipes que não usam uma ferramenta de gerenciamento de projetos é causado pela natureza intrínseca do software. Talvez você esteja trabalhando em uma startup e tenha mudado o pivô mais do que algumas vezes. Talvez seus objetivos e requisitos continuem evoluindo enquanto 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 ele precisar ser alterado. 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 resto da equipe, isso não acontecerá.
Se não foi escrito, pode até ser esquecido pelo gerente e CEO também. Não ter um lugar onde você tenha as últimas novidades 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 o projeto. Não se trata apenas de não adicionar recursos que você pode adicionar mais tarde - desenvolvi recursos inteiros apenas para descobrir que não fui informado de que não oferecemos mais suporte para esse recurso.
A tinta mais clara é mais confiável do que a memória mais poderosa. - Provérbio
Só podemos lidar com tanto em nossa cabeça de cada vez. Quando você faz uma ligação com seus gerentes e eles trazem à tona uma dezena de questões diferentes durante a conversa, em algum momento, algo se perderá. Você pode tentar anotar os pontos mais importantes sozinho, 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 tem algo mais urgente para trabalhar no produto e voltar algumas semanas ou meses depois apenas para perceber que esqueceu o que exatamente era necessário.
É por isso que ter os requisitos anotados pode economizar seu tempo, seja por não ter que se lembrar ou por evitar ter que discutir o mesmo recurso novamente. A eficiência do tempo é muito importante, pois o software é mais complexo, então você pode aproveitar a vantagem de 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.
Isso está relacionado à questão anterior de manter o controle da comunicação relacionada ao problema que está sendo abordado e apenas manter o controle dos recursos de requisitos futuros sem que você precise falar sobre essas coisas.
Isso ajuda o desenvolvedor a manter o foco na criação das 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 às informações. O nível adicional de visibilidade permite que cada membro da equipe tenha uma visão geral e planeje com antecedência.
Portanto, o que estamos procurando 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 a comunicação entre pessoas em fusos horários diferentes e equipes diferentes, ao mesmo tempo que serve como um repositório da visão oficial do software, ajudando você a manter o foco e economizando tempo ao reduzir 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 é um PMT muito poderoso que foi projetado especificamente para o desenvolvimento de software. No entanto, nem todo mundo conhece todos os recursos do Jira e pode ser opressor se você for proprietário de uma empresa tentando gerenciar seu primeiro projeto. Se você está lendo isso como uma pessoa que decide entre diferentes opções, mas nunca usou o Jira antes, recomendo assistir alguns tutoriais primeiro para que possa realmente tirar proveito de seu poder.
Existem três palavras com as quais posso definir a maior parte da minha experiência com Jira, e uma delas é arrancada . Um sprint é um período de tempo em que a equipe trabalha para cumprir certos objetivos que podem estar intimamente relacionados ou não. É totalmente flexível. Os sprints de Jira geralmente duram uma semana, o que, em minha opinião, é a duração ideal.
Do ponto de vista do desenvolvedor, isso dá a você 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 outra fácil de relaxar, ou talvez trabalhar em 2 -3 que estão intimamente relacionados ao mesmo tempo. Isso permite que os desenvolvedores tomem algumas decisões enquanto mantêm o foco ao mesmo tempo em entregar no prazo.
Enquanto corre as tarefas de grupo no reino temporal, épicos pode 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 no front-end e no back-end. Ao dividir tarefas por assunto, você pode atribuir um desenvolvedor a um assunto.
Por exemplo, você pode ter uma epopéia para migrar dados de um banco de dados existente, então você pode chamar essa epopéia de Migração de banco de dados, e como todas as tarefas nessa epopéia estão relacionadas, um único desenvolvedor pode ser o responsável por isso durante todo o corrida. Isso evita que dois desenvolvedores percam tempo aprendendo o antigo banco de dados, tornando o desenvolvimento mais eficiente.
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 esses são história , tarefa e erro . Uma história tem a peculiaridade de ter subtarefas, que podem ser usadas para quebrar um problema em pedaços menores que formam uma imagem completa quando tomadas em conjunto - isso evita a criação de um grande número de tarefas, em vez de focar em um único item a ser concluído.
Tarefas no Jira são questões muito específicas e não têm subtarefas. Quando algo que precisa ser feito é muito simples e não vale a pena tentar decompô-lo, é uma tarefa. Bugs são coisas a serem corrigidas - manter os bugs como uma categoria especial o ajudará a entender o quanto você está corrigindo em oposição ao quanto você está progredindo no projeto.
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 em que muitos desenvolvedores vivem. Uma das coisas que é difícil de comunicar de gerentes para 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 outros 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 escolher ir para as mais fáceis primeiro, deixando a crítica para o final. Se algo inesperado acontecer e a lista não for concluída, é a tarefa mais importante que é cortada ou concluída com pressa (provavelmente sacrificando a qualidade do processo). Isso é facilmente resolvido em Jira por ter prioridades , que permite que os desenvolvedores entendam o que é mais importante ou crítico a ser concluí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 tudo isso seja verdade sobre o Trello também, a IU realmente o incentiva a colocar mais conteúdo, o que ajuda a ter mais dados em cada tarefa.
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 tanto assustador para um desenvolvedor novato. A experiência pode ser avassaladora - sprints, épicos e problemas podem se misturar. Isso é especialmente verdadeiro se o gerente for um cliente com pouca experiência em desenvolvimento de software, tentando gerenciar uma equipe de desenvolvedores. Eu recomendo fortemente o Jira para grandes equipes e grandes projetos que levarão um tempo para se desenvolver (mais de alguns meses), bem como para gerentes (clientes) e desenvolvedores experientes.
O Trello pode ser resumido em uma frase simples: “tabuleiros com cartas”, a.k.a. Kanban . À primeira vista, pode até ser simples demais para um olho destreinado; entretanto, 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 Jira sente vontade de ter tudo que você pode pensar, Trello sente vontade de ter apenas o suficiente para você passar. Sem épicos, sem histórias, sem sprints - você simplesmente trabalha em um cartão e o move através dos diferentes estágios (colunas).
Tendo em mente que tudo isso existe em Jira também, explicarei alguns dos recursos que mais brilham no Trello.
Trello faz a definição estágios muito fácil - basta criar uma coluna e começar a usá-la. Os mais comuns são Tarefas, Tarefas, Revisão e Concluído. 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 criar 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 simples site, um widget ou uma extensão, onde não há muitos membros ou tarefas para gerenciar simultaneamente.
Você pode atribuir um cartão aos membros e é assim que você atribui um cartão a um desenvolvedor - muito simples aqui. Você também pode marcar outros membros nos comentários, o que ajuda todos os envolvidos em um problema a se comunicarem 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 Calendário.
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, as cartas podem ter imagens visíveis no tabuleiro.
Isso é algo que Jira não tem (ou pelo menos eu não vi sendo usado em um projeto real). Uma vez que uma imagem pode dizer mais do que palavras, você pode ver facilmente o que está acontecendo sem abrir cada bilhete.
Além disso, as tags coloridas do Trello podem ser usadas para adicionar ainda mais informações sem a necessidade de expandir um cartão. Com um pouco de boa organização, esses equivalentes Kanban dos rótulos Post-It podem ser muito úteis e poupar muitos cliques desnecessários.
Devido à sua simplicidade inerente, o Trello estimula você a manter as coisas simples e objetivas, evitando a sensação de ser sobrecarregado por montanhas de informações. Muitas vezes, você estará trabalhando em um projeto no qual é constantemente bombardeado por notificações de itens com os quais nem está envolvido.
Este 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.
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 o desanima se for complementada com recompensas,” como apontado neste artigo no Trello Blog .
Há um aumento de adrenalina (ou dopamina) sempre que um ingresso é 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 resolver mais problemas naquele dia do que no dia anterior (espero que não esteja sozinho aqui com esse sentimento) ou você apenas sente vontade de lutar para fazer a coluna de tarefas esvazie o mais rápido possível. Muitos produtos de software usam a gamificação hoje para criar um envolvimento 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.
Ainda estou surpreso em como usar o Trello é agradável e, certamente, sua simplicidade é crucial para esta experiência. As tarefas tendem a ser menores - embora você execute o mesmo trabalho, é melhor mover três tarefas para a coluna “Para revisão” do que mudar o status de uma única história de Jira para Concluída. (Acho que a taxa de conversão de uma história de Jira é cerca de três cartas no Trello.)
Isso é ideal para novos desenvolvedores ou proprietários de negócios que tentam gerenciar um projeto porque a barreira de entrada é muito baixa. O Trello é facilmente dominado por qualquer pessoa, engenheiro de software ou outro. O problema é que o Trello pode ser muito leve para certos projetos e equipes enormes. Embora você possa facilmente criar 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 de Jira.
Sim, acho que na situação típica de hoje, em que o gerente ou proprietário da empresa não está disponível para responder a perguntas 24 horas por dia, 7 dias por semana, você deve realmente pensar em usar uma ferramenta apenas como uma forma de ter um repositório onde tudo o que é necessário está escrito de forma clara. Isso o ajudará 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.
A resposta é a que melhor se adapta às suas necessidades. Se sua equipe consistir em mais de quatro pessoas e o projeto durar mais de um ano, eu escolheria Jira. Se for esse o seu caso, recomendo fortemente que você leia mais sobre como usar o Jira e como usar metodologias de desenvolvimento de software .
Se sua equipe tem menos de quatro pessoas e o projeto é um site simples, ou talvez adicionando algumas funcionalidades a um projeto existente, recomendo o Trello pela sua simplicidade. Como sempre, com ferramentas, ambos podem fazer o trabalho, mas isso não significa que o melhor seja o mesmo para todos.
Um tíquete Jira é como um átomo é uma das menores unidades na equipe de gerenciamento. Um ticket pode ser coisas diferentes, no caso de Jira pode ser uma tarefa, história ou bug. Basicamente, é uma tarefa que você precisa completar, listada no Jira como um único item.
Jira atua facilitando a organização de grandes equipes de desenvolvedores, permitindo acompanhar as atividades e o estado atual de cada atividade. Para esse propósito, ele contém muitos recursos como prioridades e sprints e é amigável ao Agile.
Uma Epopéia é um grupo de histórias, tarefas relacionadas pelo propósito que tentam alcançar. Imagine que você está criando uma plataforma de mídia social: um épico pode ser um site que contém todas as tarefas relacionadas ao site, outro pode ser o aplicativo que contém problemas relacionados ao aplicativo etc.