Lembro-me de configurar meu primeiro blog WordPress. Passei horas seguindo guias on-line para baixar o WordPress, tentando carregá-lo novamente e descobrindo como configurar um banco de dados.
Acabei de enviar por FTP todas as alterações até o servidor ativo e esperava que o blog não ficasse escuro se eu digitasse errado um ponto de interrogação.
O WordPress cresceu nesse meio tempo. As empresas de mídia de massa usam o WordPress como sua principal forma de comunicação com o mundo. Vá ao Tech Crunch ou ao New Yorker e veja o html de origem. Você verá que o site é construído usando o WordPress. Beyoncé? Sim. Ela cava o WordPress.
Ao mesmo tempo, o WordPress tem essa reputação terrível entre os desenvolvedores. O estereótipo é de script kiddies fazendo upload de arquivos via FTP, sem usar controle de versão e geralmente abandonando todos os princípios sensatos de desenvolvimento de software conhecidos pela humanidade.
Obviamente, não é uma acusação justa. O WordPress cresceu. Está recebendo uma API REST completa este ano. Agora você pode instalar o WordPress e dependências a partir da linha de comando usando WP-CLI .
Desenvolvedores e designers de temas do WordPress estão crescendo. Roots.io é um exemplo de tratamento de projetos WordPress como qualquer projeto sério de desenvolvimento de software. Eles não brincam com o upload de FTP de arrastar e soltar. Em vez disso, eles usam git para controle de versão e capistrano para implantações.
Joel, da Fog Creek Software, escreveu cerca de 12 passos para melhorar o software , e um deles era um problema ou rastreador de bugs. Ele está certo. É difícil lembrar de todas as várias solicitações de recursos e bugs na sua cabeça. É ainda mais difícil lembrar de todas as etapas para reproduzir bugs, o que o usuário esperava e o que eles realmente conseguiram.
Há apenas tantos post-its que você pode em sua mesa também. O próprio WordPress usa o Trac como seu rastreador de problemas. Trabalhei com o Redmine, outro rastreador de problemas e ferramenta de gerenciamento de projetos de código aberto, porque estou no Planio, que oferece hospedagem Redmine e git.
O caso de uso típico de um rastreador de problemas
Então, imagine que você está construindo um novo plugin para WordPress. Você tem uma pequena equipe no trabalho – um desenvolvedor ou dois, um designer e um empresário.
Você não é mais uma equipe de apenas uma pessoa. Vocês não trabalham todos em um único local, porque, bem, o trabalho remoto é incrível, e o hemisfério norte não é tão divertido no inverno.
Um usuário envia um e-mail dizendo que o plugin “não funciona”. Se você tiver muita sorte, receberá uma captura de tela mostrando uma mensagem de erro “não funciona”.
Você encaminha o e-mail ao redor. Alguém responde um e-mail com uma pergunta sobre qual navegador estava usando e, de repente, você tem um tópico do Gmail com 12 e-mails. Há alguns problemas aqui, e os rastreadores de problemas ajudam você a resolver esses problemas.
As três peças críticas de cada bug corrigível
A primeira é que você realmente precisa de três coisas para cada relatório de bug:
- Quais etapas o usuário executou que resultaram no bug?
- O que o usuário esperava ver?
- O que o usuário realmente viu?
Você precisa ser capaz de reproduzir o bug, porque é muito difícil consertar um bug que você não pode ver em ação. Segundo, você precisa ter certeza de que o bug é, de fato, um bug ou se o usuário esperava algo que seu software não oferece.
Aqui está outra maneira de colocá-lo:
E você não pode enganar a pessoa que relata o bug com a linha clássica: “ Não é um bug. É uma característica! ” se você não souber o que a pessoa esperava.
Usar um rastreador de problemas como o Redmine significa que você tem uma maneira padronizada de receber essas informações.
Há uma maneira de garantir que uma tarefa nunca seja concluída: sugerir vagamente que a equipe deve fazer algo a respeito. A menos que seja atribuído a um “proprietário”, simplesmente não será feito.
Os rastreadores de problemas forçam você a atribuir um problema a, bem, uma pessoa a qualquer momento, para que você sempre saiba quem atualmente possui um bug ou tarefa. Ao mesmo tempo, os problemas passam por um fluxo de trabalho com diferentes status, como “Em andamento”, “QA/Teste” ou “Pronto para implantação”.
A maioria dos rastreadores fornecerá relatórios com base no status atual de um problema, para que você possa ver o volume atual de trabalho em andamento e quanto ainda precisa ser feito. Você pode até criar gráficos de burndown, que são popularizados em metodologias ágeis.
Integre firmemente o Git ao seu fluxo de trabalho de gerenciamento de projetos
Como mencionamos acima, usar o git em seu processo de desenvolvimento do WordPress tornará sua vida muito mais fácil quando as coisas derem errado. O Git oferece um botão de retrocesso em seu código e você pode criar várias versões paralelas do seu site.
Toda vez que você “comita” um novo código para seu repositório git, você está criando um ponto natural para discutir a mudança na base de código. Além disso, acho mais fácil discutir problemas com base no código real comprometido em vez de apenas ideias vagas.
É aí que os rastreadores de problemas brilham, porque o Redmine, por exemplo, é totalmente integrado ao git ou svn. Você pode ver rapidamente quem cometeu o quê contra os problemas e depois discutir esses problemas.
Crie um sistema para o seu desenvolvimento WordPress
Um rastreador de problemas ajudará você a escalar além de você mesmo. Você terá certeza de que os problemas não estão escapando das rachaduras.
Na Planio , a maioria de nossos clientes usa nosso Redmine hospedado com a finalidade de rastrear projetos de desenvolvimento de software, incluindo projetos WordPress. Eles rastreiam bugs, novos recursos e sprints relacionados ao controle de versão.
O Redmine, como o WordPress, é de código aberto, então você tem a vantagem de não estar preso a software proprietário. E como o WordPress, você pode terceirizar a hospedagem para alguém como nós da Planio , ou você mesmo pode instalá-lo, se preferir, no Redmine.org .
Para você
Então – como você gerencia seus fluxos de trabalho? Já experimentou o Redmine? Adoraríamos ouvir seus pensamentos e comentários abaixo!
