Lembro-me de configurar meu primeiro blog WordPress. Passei horas seguindo os guias on-line para baixar o WordPress, tentando carregá-lo novamente e depois descobrindo como configurar um banco de dados.


Enviei todas as alterações por FTP até o servidor ativo e esperei que o blog não ficasse escuro se eu digitasse um ponto de interrogação.

Entretanto, o WordPress cresceu. As grandes empresas de mídia usam o WordPress como principal meio de comunicação com o mundo. Vá para o Tech Crunch ou o New Yorker e veja o html de origem. Você descobrirá que o site foi criado usando o WordPress. Beyonce? Sim. Ela gosta de WordPress.

Ao mesmo tempo, o WordPress tem uma reputação terrível entre os desenvolvedores. O estereótipo é de crianças de script que enviam arquivos via FTP, não usam controle de versão e geralmente abandonam todos os princípios sãos de desenvolvimento de software conhecidos pela humanidade.

Obviamente, não é uma acusação justa. WordPress cresceu. Está ficando totalmente desenvolvido API REST este ano. Agora você pode instalar o WordPress e as dependências na linha de comando usando WP-CLI.

Desenvolvedores de WordPress e designers de temas estão crescendo. O Roots.io é um exemplo de tratamento de projetos WordPress como qualquer projeto sério de desenvolvimento de software. Eles não mexem com o upload de arrastar e soltar por FTP. Em vez disso, eles usam git para controle de versão e capistrano para implantações.

Joel, da Fog Creek Software, escreveu sobre 12 etapas para melhorar o software, e um deles era um problema ou rastreador de erros. Ele está certo. É difícil lembrar de todos os diferentes pedidos e bugs de recursos em sua cabeça. É ainda mais difícil lembrar de todas as etapas para reproduzir bugs, o que o usuário esperava e o que realmente conseguiu.

Também existem tantas notas post-it em sua mesa. O próprio WordPress usa Trac como rastreador de problemas. Trabalhei com o Redmine, outra ferramenta de gerenciamento de projetos e rastreador de problemas de código aberto, porque estou no Planio, que oferece hospedagem hospedada no Redmine e git.

O caso de uso típico de um rastreador de problemas

Então, imagine que você está criando um novo plug-in para o WordPress. Você tem uma equipe pequena no trabalho – um desenvolvedor ou dois, um designer e um cara de negócios.

Você não é mais uma equipe de apenas uma pessoa. Nem todos trabalham 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 plug-in “não funciona”. Se você tiver realmente sorte, receberá uma captura de tela mostrando uma mensagem de erro “não funciona”.

Você encaminha o e-mail. Alguém envia um e-mail com uma pergunta de qual navegador eles estavam usando e, de repente, você tem um thread do Gmail com 12 e-mails. Existem alguns problemas aqui e os rastreadores de problemas ajudam a resolver esses problemas.

As três partes críticas de cada bug corrigível

A primeira é que você realmente precisa de três coisas para cada relatório de erro:

  1. Quais etapas o usuário executou que resultou no bug?
  2. O que o usuário esperava ver?
  3. O que o usuário realmente viu?

Você precisa reproduzir o bug, porque é realmente difícil corrigir um bug que você não vê em ação. Segundo, você precisa garantir que o bug seja, de fato, um bug ou se o usuário esperava algo que seu software não fornece.

Aqui está outra maneira de colocar:

E você não pode enganar a pessoa que está denunciando o erro com a linha clássica: “Não é um bug. É uma característica!“Se você não sabe o que a pessoa esperava.

Usando um rastreador de problemas como 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: vagamente sugerido que a equipe faça algo a respeito. A menos que seja atribuído a um “proprietário”, ele não será concluído.

Os rastreadores de problemas obrigam você a atribuir um problema a, bem, uma pessoa a qualquer momento, para que você saiba sempre quem é o dono de um bug ou tarefa. Ao mesmo tempo, os problemas passam por um fluxo de trabalho de diferentes status, como “Em andamento”, “Controle de qualidade / 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 resta a ser feito. Você pode até criar gráficos de burndown, popularizados em metodologias ágeis.

Integre firmemente o Git ao seu fluxo de trabalho de gerenciamento de projetos

Como mencionamos acima, o uso do git no processo de desenvolvimento do WordPress tornará sua vida muito mais fácil quando as coisas derem errado. O Git fornece uma botão de rebobinar no seu código e você pode criar várias versões paralelas do seu site.

Toda vez que você “confirma” um novo código no seu repositório git, cria um ponto natural para discutir a alteração na base de código. Além disso, acho mais fácil discutir problemas com base no código confirmado real do que apenas em idéias vagas.

É aí que os rastreadores de problemas brilham, porque o Redmine, por exemplo, está totalmente integrado ao git ou svn. Você pode ver rapidamente quem cometeu o quê contra os problemas e depois discuti-los..

Crie um sistema para o seu desenvolvimento WordPress

Um rastreador de problemas ajudará você a se expandir além de você mesmo. Você terá certeza de que os problemas não estão escapando pelas fendas.

Na Planio, a maioria de nossos clientes usa o Redmine hospedado com o objetivo de rastrear projetos de desenvolvimento de software, incluindo projetos WordPress. Eles rastreiam bugs, novos recursos e sprints em conexão com o controle de versão.

O Redmine, como o WordPress, é de código aberto, então você obtém a vantagem de não estar preso a um software proprietário. E, como o WordPress, você pode terceirizar a hospedagem para alguém como nós no Planio, ou pode instalá-lo por conta própria, se preferir Redmine.org.

Over To You

Então, como você gerencia seus fluxos de trabalho? Você já experimentou o Redmine? Gostaríamos muito de ouvir seus pensamentos e comentários abaixo!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me