Je me souviens 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 à trouver comment configurer une base de données.
J’ai juste envoyé chaque modification par FTP jusqu’au serveur en direct, et j’espérais que le blog ne s’assombrirait pas si je tapais mal un point d’interrogation.
WordPress a grandi entre-temps. Les entreprises de médias de masse utilisent WordPress comme principal moyen de communication avec le monde. Accédez à Tech Crunch ou au New Yorker et affichez le code html source. Vous constaterez que le site Web est construit à l’aide de WordPress. Beyoncé ? Ouais. Elle creuse WordPress.
Dans le même temps, WordPress a cette terrible réputation parmi les développeurs. Le stéréotype est que les script kiddies téléchargent des fichiers via FTP, n’utilisent pas de contrôle de version et abandonnent 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. C’est en train de devenir un API REST cette année. Vous pouvez maintenant installer WordPress et ses 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 n’importe quel projet de développement logiciel sérieux. Ils ne dérangent 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 de Fog Creek Software a écrit à propos de 12 étapes pour un meilleur logiciel, et l’un d’entre eux était un bug tracker. 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 de reproduction des bogues, de ce que l’utilisateur attendait et de ce qu’il a réellement obtenu.
Il y a aussi peu de post-it que vous pouvez sur votre bureau. WordPress lui-même utilise Trac comme son outil de 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 outil de suivi des problèmes
Alors, imaginez que vous construisez un nouveau plugin pour WordPress. Vous avez une petite équipe sur le tas – 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 tellement 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 affichant un message d’erreur « ne fonctionne pas ».
Vous transférez l’e-mail autour. Quelqu’un répond par e-mail avec une question sur le navigateur qu’il utilisait, et tout à coup, vous avez un fil Gmail de 12 e-mails. Il y a quelques problèmes 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 éléments pour chaque rapport de bogue :
- Quelles mesures l’utilisateur a-t-il prises qui ont entraîné le bogue ?
- Qu’est-ce que l’utilisateur s’attendait à voir ?
- 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 bien un bogue ou si l’utilisateur s’attendait à quelque chose que votre logiciel ne fournit pas.
Voici une autre façon de le dire :
Les règles d’un parent pour le rapport de bogue :
– Que vouliez-vous que le programme vous apporte ?
– Qu’avez-vous fait du programme ?
– Qu’est-ce que c’était pour toi ?– Steve Purcell (@sanityinc) 29 octobre 2015
Et vous ne pouvez pas tromper 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.
Utiliser un outil de suivi des problèmes tel que Redmine signifie que vous disposez d’un moyen normalisé de recevoir ces informations.
Il existe un moyen de s’assurer qu’une tâche ne sera jamais accomplie : suggérer vaguement que l’équipe devrait faire quelque chose à ce sujet. À moins qu’il ne soit attribué à un seul « propriétaire », il ne sera tout simplement pas fait.
Les traqueurs de problèmes vous obligent à attribuer un problème à, eh bien, 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 workflow de différents statuts tels que « En cours », « QA/Testing » ou « Ready for Deployment ».
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 burndown charts, qui sont vulgarisés dans les méthodologies agiles.
Intégrez étroitement Git dans votre workflow de gestion de projet
Comme nous l’avons mentionné ci-dessus, l’utilisation de git dans votre processus de développement WordPress vous facilitera grandement la vie en cas de problème. 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 « commettez » 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éellement validé plutôt que sur de vagues idées.
C’est là que brillent les traqueurs de problèmes, car Redmine, par exemple, est étroitement intégré à git ou svn. Vous pouvez rapidement voir qui a commis quoi contre les 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é dans le but de suivre les projets de développement de logiciels, y compris les projets WordPress. Ils suivent les bogues, les nouvelles fonctionnalités et les sprints en lien 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 depuis Redmine.org.
À vous de jouer
Alors, comment gérez-vous vos flux de travail ? Avez-vous essayé Redmine ? Nous aimerions entendre vos pensées et commentaires ci-dessous!
