Je me souviens d’avoir créé mon premier blog WordPress. J’ai passé des heures à suivre des guides en ligne pour télécharger WordPress, à essayer de le télécharger à nouveau, puis à déterminer comment configurer une base de données.

J’ai juste envoyé chaque changement par FTP jusqu’au serveur en direct, et j’espérais que le blog ne s’éteindrait pas si j’avais mal tapé un point d’interrogation.

WordPress a grandi entre-temps. Les entreprises de médias de masse utilisent WordPress comme principal moyen de communiquer avec le monde. Accédez à Tech Crunch ou au New Yorker et affichez le code source html. Vous constaterez que le site Web est construit à l’aide de WordPress. Beyonce? Ouaip. Elle fouille WordPress.

En même temps, WordPress a cette terrible réputation parmi les développeurs. Le stéréotype est celui des script kiddies téléchargeant des fichiers via FTP, n’utilisant pas de contrôle de version et abandonnant généralement tous les principes sains de développement de logiciels connus de l’humanité.

De toute évidence, ce n’est pas une accusation juste. WordPress a grandi. Ça devient un véritable API REST cette année. Vous pouvez maintenant installer WordPress et les dépendances à partir de la ligne de commande en utilisant WP-CLI.

Les développeurs WordPress et les concepteurs de thèmes grandissent. Roots.io est un exemple de traitement des projets WordPress comme tout projet de développement logiciel sérieux. Ils ne plaisantent pas avec le téléchargement FTP par glisser-déposer. Au lieu de cela, ils utilisent git pour le contrôle de version et capistrano pour les déploiements.

Joel of Fog Creek Software a écrit sur 12 étapes pour un meilleur logiciel, et l’un d’entre eux était un problème ou un suivi de bogue. Il a raison. Il est difficile de se souvenir de toutes les différentes demandes de fonctionnalités et bogues dans votre tête. Il est encore plus difficile de se souvenir de toutes les étapes pour reproduire les bogues, de ce que l’utilisateur attendait et de ce qu’il a réellement obtenu.

Il y a aussi un nombre limité de post-it que vous pouvez sur votre bureau. WordPress lui-même utilise Trac comme son suivi des problèmes. J’ai travaillé avec Redmine, un autre outil de suivi des problèmes et de gestion de projet open source, car je suis chez Planio, qui propose un hébergement Redmine et git hébergé.

Le cas d’utilisation typique d’un suivi des problèmes

Alors, imaginez que vous construisez un nouveau plugin pour WordPress. Vous avez une petite équipe au travail – un développeur ou deux, un designer et un homme d’affaires.

Vous n’êtes plus une équipe d’une seule personne. Vous ne travaillez pas tous au même endroit, car, eh bien, le travail à distance est génial, et l’hémisphère nord n’est pas très amusant en hiver.

Un utilisateur envoie un e-mail disant que le plugin «ne fonctionne pas». Si vous êtes vraiment chanceux, vous obtiendrez une capture d’écran montrant un message d’erreur «ne fonctionne pas».

Vous transférez l’e-mail. Quelqu’un envoie un e-mail en lui demandant quel navigateur il utilisait, et tout à coup, vous avez un fil Gmail de 12 e-mails. Quelques problèmes sont résumés ici, et les outils de suivi des problèmes vous aident à résoudre ces problèmes.

Les trois éléments critiques de chaque bogue réparable

La première est que vous avez en fait besoin de trois choses pour chaque rapport de bogue:

  1. Quelles mesures l’utilisateur a-t-il prises qui ont entraîné le bogue?
  2. Qu’est-ce que l’utilisateur s’attendait à voir?
  3. Qu’est-ce que l’utilisateur a réellement vu?

Vous devez être capable de reproduire le bogue, car il est vraiment difficile de corriger un bogue que vous ne pouvez pas voir en action. Deuxièmement, vous devez vous assurer que le bogue est en fait un bogue ou si l’utilisateur attend quelque chose que votre logiciel ne fournit pas.

Voici une autre façon de le dire:

Et vous ne pouvez pas repousser la personne qui signale le bogue avec la ligne classique: “Ce n’est pas un bug. C’est une fonctionnalité!»Si vous ne savez pas ce que la personne attendait à la place.

Utilisation d’un outil de suivi des problèmes tel que Redmine signifie que vous disposez d’une manière standardisée de recevoir ces informations.

Il y a une façon de s’assurer qu’une tâche n’est jamais accomplie: suggérer vaguement que l’équipe devrait faire quelque chose à ce sujet. À moins qu’il ne soit attribué à un «propriétaire», cela ne se fera tout simplement pas.

Les outils de suivi des problèmes vous obligent à attribuer un problème à une personne à un moment donné, afin que vous sachiez toujours à qui appartient actuellement un bogue ou une tâche. Dans le même temps, les problèmes passent par un flux de travail de différents statuts tels que «En cours», «QA / Test» ou «Prêt pour le déploiement».

La plupart des trackers vous fourniront des rapports basés sur l’état actuel d’un problème, afin que vous puissiez voir le volume actuel de travail en cours et combien il reste à faire. Vous pouvez même créer des graphiques de burndown, qui sont popularisés dans des méthodologies agiles.

Intégrez étroitement Git dans votre flux de travail de gestion de projet

Comme nous l’avons mentionné ci-dessus, l’utilisation de git dans votre processus de développement WordPress vous rendra la vie beaucoup plus facile lorsque les choses tournent mal. Git vous donne un bouton de rembobinage sur votre code, et vous pouvez créer plusieurs versions parallèles de votre site.

Chaque fois que vous «validez» un nouveau code dans votre référentiel git, vous créez un point naturel pour discuter de la modification de la base de code. De plus, je trouve qu’il est plus facile de discuter des problèmes en se basant sur du code réel engagé plutôt que sur de vagues idées.

C’est là que les trackers de problèmes brillent, car Redmine, par exemple, est étroitement intégré à git ou svn. Vous pouvez voir rapidement qui a commis quoi par rapport aux problèmes, puis discuter de ces problèmes.

Créez un système pour votre développement WordPress

Un outil de suivi des problèmes vous aidera à évoluer au-delà de vous-même. Vous serez sûr que les problèmes ne passent pas entre les mailles du filet.

Chez Planio, la majorité de nos clients utilisent notre Redmine hébergée dans le but de suivre les projets de développement logiciel, y compris les projets WordPress. Ils suivent les bogues, les nouvelles fonctionnalités et les sprints en relation avec le contrôle de version.

Redmine, comme WordPress, est open source, vous avez donc l’avantage de ne pas être enfermé dans un logiciel propriétaire. Et comme WordPress, vous pouvez sous-traiter l’hébergement à quelqu’un comme nous chez Planio, ou vous pouvez l’installer vous-même si vous préférez Redmine.org.

À vous

Alors – comment gérer vos flux de travail? Avez-vous essayé Redmine? Nous aimerions connaître vos opinions et commentaires ci-dessous!

Share: