Jusqu’à l’année dernière, l’une des façons dont j’ai défini les jalons était fortement basée sur la perspective de la façon dont moi ou mon équipe et moi devions travailler sur le projet.
Il y a cependant un problème avec cette approche: pour ceux d’entre nous qui essaient d’inclure les commentaires des clients tout au long du processus de développement, il n’est pas aussi facile pour eux de prendre le jargon que nous utilisons et de leur donner un sens.
À cette fin, j’ai commencé à définir les jalons du projet WordPress un peu différemment afin qu’ils soient un peu plus conviviaux tout en donnant un sens à la façon dont une équipe de développeurs peut accomplir ce qui est nécessaire pour s’assurer que les choses sont fonctionnelles.
Jalons du projet WordPress
Pensez un instant à la dernière fois où vous avez été responsable de la création d’un plugin personnalisé ou de l’intégration de fonctionnalités personnalisées dans un projet WordPress. Peut-être qu’il comprenait quelque chose comme:
- Importer des données dans la base de données WordPress,
- Rendre les informations visibles et modifiables depuis l’espace d’administration de WordPress,
- Affichez les informations sur le front-end et de manière à pouvoir les trier, par exemple, par valeurs de colonne,
- Les données peuvent être mises à jour via un autre import ou gérées depuis l’espace d’administration,
- Et peut-être quelques autres fonctionnalités connexes.
Si vous devez décomposer cela en langage développeur, vous allez beaucoup parler de certaines choses concernant l’importation, l’analyse des données, l’intégrité des données, etc. Et tout cela est 100% correct, et tout cela devrait être du point de vue d’un développeur.
Mais si vous utilisez un logiciel de gestion de projet (que nous avons récemment installé sur Asana ), ces types de jalons ne vous aideront pas lorsque vous intégrerez des utilisateurs dans le projet.
- Comment sont-ils censés connaître les détails d’un processus d’importation ?
- Comment sont-ils censés comprendre les détails techniques pour rendre quelque chose triable ?
- Existe-t-il un moyen de leur décrire facilement un algorithme qui compte ?
Je dirais non. Alors, comment pouvons-nous rendre les jalons du projet WordPress plus accessibles? Je ne sais pas si ma réponse est une réponse solide, mais c’est quelque chose que nous avons essayé et quelque chose qui semble fonctionner relativement bien, mais c’est simple :
- Les clients pensent souvent à leurs projets concernant des pages (ou quelque chose en rapport),
- Étant donné que nous, en tant que développeurs, pouvons travailler dans ce contexte, nous pouvons définir un projet destiné au public pour décomposer les tâches page par page.
Ainsi, les jalons du projet WordPress concernent davantage les tâches par page et les tâches restantes dans un jalon plus "général".
Un mot sur les aspects techniques
Tout ce qui est mentionné ci-dessus fonctionne bien lorsque le client est impliqué dans certaines parties du projet, mais cela laisse toujours la question « Que faisons-nous des aspects plus techniques ? »
Et par là, cela peut aller de la façon dont vous allez organiser vos interfaces, classes, méthodes, etc. à la façon dont vous allez implémenter un certain algorithme. Quoi qu’il en soit, le fait est qu’il y a une discussion technique plus approfondie qui doit avoir lieu. Alors, que faisons-nous de ceux-ci lorsque nous discutons des jalons du projet WordPress ?
Il existe plusieurs options :
- Configurez une étape distincte, un groupe de tâches, des projets, une discussion, tout ce que votre système permet, et gardez cela entre vous et votre équipe.
- Tirer parti des problèmes GitHub, des projets GitHub, d’un wiki, de Trello ou d’un autre système,
- Conservez les informations dans une autre application accessible à tous les développeurs, mais isolée du client.
Bien sûr, cela crée un peu plus de frais généraux, mais j’ai constaté que plus vous avez diffusé d’informations sur les différentes parties de votre projet, plus un projet peut être réussi.
Lorsque des informations sont laissées de côté, dispersées, non partagées ou non détaillées, il devient plus difficile de les gérer au fur et à mesure que le projet avance, en particulier lors des itérations futures.
En fin de compte, je pense qu’il est important de diviser les jalons du projet WordPress en parties où le client comprend facilement le travail en cours et que vous et votre équipe avez un moyen de gérer ce qui est fait.
La façon dont vous faites cela dépend évidemment de vous, mais c’est quelque chose que j’ai trouvé qui valait bien le temps de configuration.