Les grandes phases du développement « feature-driven »

Qu’est-ce que le développement feature-driven ?

Le développement feature-driven (FDD) est une méthodologie de développement de logiciels qui organise le travail autour des caractéristiques ou des fonctionnalités d’une application. Lorsque les développeurs adoptent une telle approche, ils identifient une poignée de fonctionnalités spécifiques à mettre en œuvre ou à améliorer et terminent ce travail avant de passer à un nouvel ensemble de features. Tant qu’il y a suffisamment de développeurs travaillant sur la même application ou le même projet, ils peuvent être divisés en groupes plus petits – généralement appelés « feature teams » –, chaque équipe se concentrant sur un ensemble spécifique de fonctionnalités ou de mises à jour de ces dernières.

De cette manière, le développement basé sur les fonctionnalités permet de traduire en étapes concrètes les philosophies Agile de haut niveau, qui encouragent les développeurs à diviser les projets complexes en tâches réduites et plus faciles à gérer. En utilisant les fonctionnalités pour définir les unités de travail, le FDD offre un moyen pragmatique d’améliorer la qualité de vie des utilisateurs.

Sur quelles fonctionnalités le développement feature-driven se concentre-t-il ?

Notons que le terme « fonctionnalité » est utilisé de manière assez vague dans le contexte du développement feature-driven. Il peut se référer à des fonctionnalités d’application, au sens traditionnel, telles que le processus permettant à un client d’un site d’e-commerce d’ajouter un item dans un panier virtuel ou de payer l’article dans ce même panier. Cependant, le terme « feature » peut avoir un sens plus large.

L’amélioration de la vitesse de chargement des pages d’un site Web pourrait également être considérée comme une fonctionnalité, tout comme la modification de la taille et de la couleur du texte au sein d’une application afin d’en améliorer la convivialité. Ces mises à jour n’ajoutent pas de nouvelles fonctionnalités (elles améliorent les capacités existantes de l’application), mais sont considérées comme telles dans le cadre du développement basé sur les fonctionnalités.

Si par certains aspects le FDD se rapproche du Scrum (les fonctionnalités pourraient être vues comme des histoires), la grande différence tient dans la place donnée à la documentation. Selon Planview, la méthode FDD s’appuie moins sur la conduite de réunions régulières que sur la transmission des informations à travers une documentation bien structurée.

Les avantages du développement feature-driven

Lorsqu’il est mis en œuvre avec succès, le développement basé sur les fonctionnalités offre plusieurs avantages significatifs :

• Clarté de la feuille de route et du planning. En alignant les unités de travail sur des fonctionnalités spécifiques ou des améliorations de fonctionnalités, le FDD permet aux développeurs d’estimer plus finement le temps et les efforts consacrés à chaque tâche.
• Progression itérative. La division des projets en petites unités de travail aide les équipes à travailler efficacement et de manière itérative. Plutôt que d’essayer d’apporter des changements majeurs à une application en une seule fois – une tâche difficile à coordonner – le FDD permet aux développeurs de procéder par petites étapes, en améliorant continuellement l’application.
• Approche centrée sur l’utilisateur. Parce que le FDD se concentre sur les fonctionnalités, il permet d’aligner le travail des développeurs sur les fonctionnalités appréciées par les utilisateurs.
• Communication efficace et consensus entre les développeurs. Lorsque le travail de développement s’aligne sur les fonctionnalités, il devient relativement facile de définir les tâches. De cette manière, le FDD minimise le besoin de réunions ou de discussions entre les développeurs pour décider de ce sur quoi ils vont travailler. Avec la méthode FDD, les équipes peuvent rapidement se mettre d’accord sur un ensemble de tâches et commencer à les mettre en œuvre.

Les défis du développement axé sur les fonctionnalités

Idéal sur le papier, le développement axé sur les fonctionnalités peut présenter certains défis.

L’un des plus grands d’entre eux consiste à apporter des changements qui affectent plusieurs fonctionnalités ou l’application dans son ensemble. Par exemple, pour remanier une application monolithique en une autre orientée microservices, l’approche axée sur les fonctionnalités ne fonctionne pas, car les développeurs doivent apporter des changements importants allant au-delà de la mise en œuvre ou de la mise à jour d’une fonctionnalité spécifique.

De même, si les développeurs souhaitent améliorer la sécurité d’une application, cela peut s’avérer difficile, car cela pourrait avoir un impact sur un certain nombre de fonctionnalités différentes, telles que la manière dont les utilisateurs se connectent, la façon dont l’application traite les données et la façon dont elle interagit avec le réseau. Cette tâche ne peut pas être réduite à une fonction discrète.

Le FDD peut également s’avérer difficile lorsque les développeurs n’ont pas une vision claire des fonctionnalités appréciées par les utilisateurs ou lorsqu’ils doivent prendre en charge plusieurs groupes d’utilisateurs ayant des intérêts divergents. Dans ces cas-là, il peut être plus long de décider sur quelles fonctionnalités travailler, car il n’est pas évident de savoir ce qui crée le plus de valeur pour l’utilisateur moyen. Dès lors, une planification minutieuse est nécessaire et potentiellement plus coûteuse que si l’équipe avait commencé à développer des incréments sujets à des limites temporelles.

Un troisième inconvénient majeur du FDD est qu’il ne fonctionne pas bien pour les projets qui n’ont que quelques développeurs – ou, éventuellement, un seul développeur. S’il n’y a pas assez de développeurs pour assigner différentes tâches à plusieurs équipes simultanément, le FDD apporte moins de valeur, car il ne permet pas aux programmeurs de travailler en parallèle.

Les phases du développement feature-driven

Pour mettre en pratique le développement piloté par les fonctionnalités, la plupart des équipes travaillent en cinq étapes formelles, ou phases.

Phase 1. Créer un modèle global

Tout d’abord, l’équipe doit établir une vision de haut niveau du fonctionnement de l’application et des catégories de fonctionnalités qu’elle inclura. Ce processus implique de formuler des hypothèses sur les types de fonctionnalités que les utilisateurs apprécient, ainsi que de prendre des décisions techniques sur la meilleure façon de mettre en œuvre les exigences clés.

Par exemple, si les développeurs conçoivent une application d’e-commerce, ils peuvent décider au cours de cette phase à quoi ressemble le parcours de base du client dans l’application et quels types de fonctionnalités clés, telles que la possibilité de créer des comptes, de rechercher des produits et d’effectuer des achats, l’application doit prendre en charge.

Phase 2. Établir une liste de fonctionnalités

Ensuite, les développeurs établissent une liste de fonctionnalités qui détaille les capacités qu’ils doivent mettre en œuvre pour créer le type d’application qu’ils ont imaginé lors de la phase précédente.

Si la possibilité de créer des comptes fait partie du modèle d’application, les fonctionnalités spécifiques associées à cette capacité peuvent inclure l’enregistrement d’un nouveau compte, l’authentification des utilisateurs et la possibilité pour les utilisateurs existants de mettre à jour les détails de leur compte.

Phase 3. Planifier par fonctionnalité

Une fois que les équipes sont parvenues à un consensus sur une liste de fonctionnalités, elles peuvent commencer à planifier leur mise en œuvre.

À ce stade du cycle du FDD, les équipes évaluent généralement le temps et les efforts nécessaires à chaque fonctionnalité. Elles décident ensuite comment déléguer le travail entre les équipes chargées des fonctionnalités.

La planification par fonctionnalité doit également tenir compte des types de compétences que chaque développeur ou équipe de développement apporte à la table. Dans l’idéal, les développeurs se voient attribuer des fonctionnalités qu’ils sont capables de traiter, au vu de leurs compétences.

Phase 4. Concevoir par fonctionnalité

La conception par fonctionnalité consiste à élaborer des plans spécifiques pour la mise en œuvre de chaque fonctionnalité. Cette tâche est généralement supervisée par un développeur en chef qui travaille avec chaque équipe de développement pour prendre des décisions, telles que le choix du langage ou du cadre à utiliser et, le cas échéant, la manière dont l’utilisateur s’interface avec la fonctionnalité.

Phase 5. Compiler (Build) par fonctionnalité

Enfin, les développeurs mettent en œuvre les fonctionnalités sur la base des conceptions établies lors de la phase 4. Si une fonctionnalité prend beaucoup plus de temps que prévu, l’équipe peut décider de la redéfinir ou de la diviser en un plus petit ensemble de tâches.

Ce processus se poursuit jusqu’à ce que les équipes aient construit et testé toutes les fonctionnalités prévues. À ce stade, les développeurs sont prêts à planifier et à mettre en œuvre un nouvel ensemble de fonctionnalités en travaillant sur une nouvelle itération des phases du développement basé sur les fonctionnalités.