Périodiquement, d’autres me demanderont comment j’arrive à organiser les différentes tâches, actifs, ressources et éléments connexes tout au long d’un projet. Tout d’abord, j’ai décidé de garder Pressware petit (et c’est pour certaines raisons), donc cela me permet de l’exécuter différemment que s’il était, bien sûr, plus grand.
Deuxièmement, j’utilise généralement une version très réduite d’un tableau kanban. Pour ceux qui ne connaissent pas, le kanban est défini comme ceci :
un système de fabrication japonais dans lequel l’approvisionnement en composants est régulé par l’utilisation d’une carte d’instruction envoyée le long de la chaîne de production.
À cette fin, j’ai pensé partager un bref aperçu de la façon dont je configure généralement chaque colonne et chaque carte ainsi que les outils que j’utilise pour gérer chaque tâche.
Kanban dans le développement WordPress
D’une manière générale, chaque tableau que je mets en place – et je parlerai des outils que j’utilise pour ceux-ci dans un instant – comprend quatre colonnes dont chacune est définie comme suit :
- À FAIRE. Il s’agit essentiellement de l’arriéré de tâches qui doivent être effectuées pour terminer le projet. Il s’agit d’une liste de toutes les exigences qui sont généralement décrites dans l’ énoncé des travaux, mais décomposées en tâches qui peuvent se déplacer dans chaque colonne pour voir les progrès réalisés.
- Faire. Lorsqu’une carte est dans cette colonne, cela signifie que l’équipe, quelqu’un d’autre, ou moi, y travaillons. Parfois, une carte contient plusieurs sous-tâches (qui sont généralement identifiées par des cases à cocher), et nous les tenons à jour avec l’état de la tâche. J’essaie de garder chaque carte liée à un commit dans le code source afin que si nous devons annuler quelque chose, nous replaçons une carte dans une colonne. Alternativement, une fois que nous avons validé un changement, nous pouvons déplacer la carte vers la colonne suivante.
- Révision / mise en scène. Cette colonne signifie que le travail a été fait et qu’il est prêt à être revu par l’utilisateur sur l’environnement de staging du site. En règle générale, je donne aux clients l’accès au tableau, afin qu’ils puissent le faire. Autrement dit, ils peuvent voir quand quelque chose est prêt à être examiné, avoir accès au site de staging et vérifier que les exigences répertoriées dans l’énoncé des travaux et sur la carte sont prêtes à être utilisées.
- Fait. Une fois que le client a vérifié que le travail terminé est fait à sa satisfaction, la carte se déplace dans la colonne terminé, le code est fusionné dans la branche principale, puis le cycle se répète. Si, toutefois, la tâche n’est pas terminée, la carte revient à Doing et revient dans le pipeline jusqu’à ce qu’elle soit prête à être publiée.
Maintenant, lorsqu’il s’agit de travailler sur des projets, il y a un autre aspect qui doit être pris en compte: les actifs.
Une seule source de vérité
Plus précisément, je parle de tout ce qui va de:
- polices,
- conceptions,
- informations d’identification pour les API tierces,
- outils tiers,
- ou généralement tout autre actif qui peut être nécessaire dès le début du projet ou à partir du moment où les développeurs du projet.
Il y a plusieurs façons de gérer cela et j’essaie de laisser la nature des actifs dicter où je place les choses. Par exemple, les ressources de conception sont souvent conservées dans un dossier Dropbox partagé ou peut-être sur une carte, si elles sont petites (mais elles ne le sont généralement pas). Même dans ce cas, je peux toujours créer une colonne Ressources et répertorier les cartes avec des liens vers le dossier Dropbox, par exemple.
Un exemple très simple d’utilisation de Trello.
S’il s’agit d’informations d’identification pour une API, je peux le placer dans une carte sous la colonne Ressources, mais s’il s’agit de quelque chose de sensible, je peux utiliser une note Droplr privée, puis la lier depuis l’outil de gestion de projet de mon choix.
Vous avez compris l’idée, cependant : la nature de l’actif détermine où il est stocké, mais le tableau kanban y fait toujours référence d’une manière ou d’une autre. C’est ce qui l’aide à rester une source unique de vérité pour vous et toutes les parties concernées.
Et pour les outils ?
Je pense que beaucoup d’entre nous aiment essayer la nouvelle chose brillante. Pour certains, c’est presque une habitude :
Un nouvel outil de gestion de projet est sorti? Essayons. Pour d’autres, s’il existe une méthode éprouvée qui fonctionne, alors pourquoi ne pas s’y tenir ?
Peu importe où vous vous situez, je pense qu’il est important de trouver ce qui fonctionne le mieux pour vous et votre équipe, puis de les utiliser de manière cohérente et normative qui peut être appliquée à tous les projets.
Pour ma part, j’ai tendance à utiliser les outils suivants :
- Projets Trello ou GitHub. Cela dépend en grande partie du client.
- Dropbox pour partager des actifs.
- Droplr pour sécuriser les informations d’identification.
- Google Docs pour les énoncés de travail et les conditions générales
- Google Docs pour les notes de frais
- Facture pour les factures.
- Eversign pour les signatures électroniques sur les documents ci-dessus.
Je sais que pour quelques-uns des logiciels ci-dessus, certains peuvent être préoccupés par la sécurité, en particulier en ce qui concerne les informations financières ou sécurisées.
Photo de John Salvino sur Unsplash
Je ne prends pas ça à la légère. La règle générale que j’essaie de suivre est que si c’est quelque chose qui, selon moi, doit être complètement sécurisé, j’utiliserai un système approprié pour l’utiliser ; sinon, si c’est quelque chose qui ne me dérange vraiment pas si quelqu’un devait y accéder, alors ça me va.
Et je pense que c’est une considération importante que nous devons prendre en compte pour fournir un service aux autres. En fait, il s’agit probablement du contenu d’un autre article, voire d’un tout autre blog. Mais ce n’est pas ce post, ni ce blog – du moins pas en ce moment.
Mon point?
Enfin, assurez-vous d’avoir les éléments suivants :
- un moyen pour vous et votre client de suivre l’avancement d’un projet tout au long du cycle de développement,
- un moyen pour eux de voir comment les choses se passent qui ne sont pas ouvertement techniques comme le contrôle des sources,
- un moyen de partager et d’accéder au besoin,
- la capacité de communiquer et de poser des questions au besoin.
Je suis sûr qu’il y a d’autres choses à noter, mais celles-ci sont essentielles au contenu de cet article. L’utilisation de kanban dans le développement WordPress n’est donc pas difficile, mais elle est également étayée par quelques éléments supplémentaires qui peuvent faciliter le processus.
Conservez une source de vérité unique prise en charge par des services tiers qui facilitent la collaboration.