Gestion de projet : fonctionnalités (jalons, tâches et boucles de rétroaction)
La gestion de projet comporte de multiples facettes, et la façon dont nous décomposons tous les différents aspects de nos projets dépend probablement de la façon dont notre lieu de travail le fait, de la façon dont le client veut le faire ou de la façon dont nous choisissons de le faire nous-mêmes.
Pour ce poste, lorsqu’il s’agit de travailler spécifiquement sur un projet donné, je parle spécifiquement de la façon dont nous prenons les exigences d’un projet et les décomposons en éléments et livrables plus gérables pour les personnes pour lesquelles nous travaillons. Et ce faisant, je pense qu’il est important qu’ils soient tenus au courant et puissent voir les progrès aux points de contrôle appropriés pour recueillir des commentaires.
Malgré l’évolution de divers aspects de mon entreprise au fur et à mesure que j’en apprenais davantage sur ce qui fonctionne et ce qui ne fonctionne pas, une chose est restée cohérente dans la façon dont je gère les aspects liés au développement des fonctionnalités d’un projet.
Fonctionnalités : jalons, tâches et boucles de rétroaction
Chaque fois que nous parlons de ce genre de choses, il est facile de tomber dans le jargon de notre industrie. Et bien que je ne pense pas qu’il y ait nécessairement quoi que ce soit de trop technique dans les « étapes importantes » et les « tâches », une « boucle de rétroaction » est quelque chose d’un peu différent. Mais je vais couvrir cela momentanément.
Étant donné un ensemble d’exigences, quelle que soit leur taille, je commence immédiatement à parcourir le document – quelle que soit la façon dont nous le recevons – et à réfléchir à toutes les pièces qui seront nécessaires pour réaliser une fonctionnalité donnée. Quels que soient les langages, les outils, les frameworks ou les applications avec lesquels vous choisissez de travailler, je pense que c’est là qu’il est important d’avoir une connaissance approfondie de ce avec quoi vous travaillez.
Décomposer les fonctionnalités en jalons et les jalons en tâches.
À partir de là, je vais ensuite prendre une fonctionnalité donnée et la décomposer en différentes tâches, et je répéterai cela pour chacune des fonctionnalités. Habituellement, j’essaierai de faire de chaque fonctionnalité une étape importante, mais certaines fonctionnalités sont plus importantes que d’autres et doivent être divisées en plusieurs parties. À cette fin, un projet est généralement divisé de telle sorte que :
- Une fonctionnalité devient un jalon (ou des jalons),
- Un jalon est un groupe de tâches,
- Et une tâche correspond à une unité fonctionnelle (pas nécessairement une fonction dans la base de code globale, cependant).
Ensuite, vous pouvez revenir en arrière à partir de cela pour voir comment cela correspond à une version :
- Une tâche correspond généralement à un commit,
- Un ensemble de commits correspond à une balise,
- Une balise correspond à la fusion d’une fonctionnalité,
- Une fonctionnalité correspond à un jalon.
À ce stade, une étape doit être prête à être déployée dans l’environnement intermédiaire afin que le client puisse l’évaluer par rapport à ce qu’il a en tête (et dans les exigences) pour s’assurer qu’il est respecté.
C’est là qu’une boucle de rétroaction entre en jeu. Mais d’abord, je définis une boucle de rétroaction simplement comme suit :
Une conversation autour d’une fonctionnalité donnée qui détermine si elle est terminée ou mérite plus de travail.
Bien que d’autres entrent dans beaucoup plus de détails. Je m’égare cependant.
Ainsi, en attendant que le client reprenne contact au sujet de la dernière étape, je (ou nous) passerons généralement à l’étape suivante. C’est pourquoi il est important d’avoir une manière cohérente de travailler avec les jalons, les tâches et les commentaires (ainsi que les branches dans les environnements de contrôle de source et de mise en scène).
Commencez à travailler sur une nouvelle fonctionnalité après avoir validé la dernière dans le contrôle de code source et la mise en scène.
Si les commentaires reviennent du client, nous prenons généralement les commentaires, déterminons ce qui peut être fait, ce qui ne peut pas être fait, puis nous les regroupons dans une nouvelle étape. Parfois, le jalon est ajouté à la fin ; d’autres fois, il est ajouté comme prochain élément de priorité. Tout dépend de la nature du travail, du retour d’expérience, et de la manière dont il s’inscrit dans le périmètre du projet.
Plus que des fonctionnalités
D’une manière générale, ce n’est qu’une vue d’ensemble de la façon dont j’essaie de gérer les aspects de développement des fonctionnalités. Mais l’examen des jalons, des tâches et des boucles de rétroaction est quelque chose d’important car une fois que ce système est en place, il crée une manière prévisible que vous et une équipe pouvez mettre en œuvre des solutions.
De plus, cela crée de la prévisibilité avec les livrables et la communication avec votre client, et cela fonctionne particulièrement bien avec les clients réguliers, car ils savent à quoi s’attendre.
Comme pour beaucoup de choses sur lesquelles j’écris, je n’essaie pas de présenter cela comme un évangile, mais je crois qu’il est important d’avoir un système en place. Je ne pense pas qu’on devrait jamais piloter un projet à moins que ce ne soit qu’un projet personnel et parallèle.
Donc, quelle que soit l’approche que vous choisissez, ayez au moins une approche.