développement basé sur les fonctionnalités

Pourquoi utiliser le feature driven development – FDD

Temps de lecture : environ 8 min

Lorsque vous pensez aux méthodologies agiles, vous pensez probablement à Scrum. C’est logique, car Scrum est reconnue comme la méthodologie la plus populaire parmi les chefs de produit et les équipes de développement depuis les 13 dernières années.

Si Scrum est la méthodologie la plus populaire, une lecture rapide des rapports annuels sur la méthode agile révèle que d’autres méthodologies, telles que Kanban ou un hybride de Scrum, ont gagné en popularité. L’une de ces autres méthodologies est le développement basé sur les fonctionnalités (feature driven development – FDD).

Le développement basé sur les fonctionnalités n’est peut-être pas aussi répandu ou utilisé que d’autres méthodologies agiles, mais il vaut la peine de s’y intéresser, surtout si vous devez adapter votre développement agile à un projet à long terme réunissant de nombreux intervenants.

aperçu du développement basé sur les fonctionnalités
Aperçu du développement basé sur les fonctionnalités (Cliquez sur l’image pour le modifier en ligne)

Qu’est-ce que le développement basé sur les fonctionnalités ou feature driven development(FFD)?

En 1997, Jeff De Luca travaillait au sein d’une équipe de 50 personnes sur un projet de développement logiciel de 15 mois à Singapour. Afin d’aider son équipe à s’adapter et à répondre aux besoins des clients, il a conçu un modèle en cinq étapes consistant à développer des fonctionnalités par cycles courts : le feature driven development ou FDD.

Scrum, XP et autres méthodologies agiles utilisent toutes une approche itérative pour créer des logiciels. En revanche, les cinq étapes du FDD obligent l’équipe à suivre un ensemble de bonnes pratiques d’ingénierie lors du développement de petits ensembles de fonctionnalités par cycles d’une à deux semaines.Ces cinq étapes garantissent la cohérence du développement, de sorte que le projet puisse monter en puissance et les nouveaux membres de l’équipe se mettre au diapason beaucoup plus rapidement.

Bonnes pratiques du feature driven development

Nous aborderons les cinq étapes du cycle de vie d’un projet FDD plus tard dans cet article, mais en premier lieu, il est important de comprendre les principes fondamentaux de cette méthodologie.

  • Modélisation objet de domaine : les équipes créent des diagrammes de classes pour décrire les objets d’un domaine et leurs associations. Ce processus vous fait gagner du temps en vous aidant à identifier la fonction à ajouter pour chaque élément.
  • Développement par fonctionnalité : si une fonctionnalité ne peut être mise en œuvre en deux semaines, elle doit être décomposée en éléments plus petits et gérables.
  • Propriété individuelle d’une classe (d’un code) : chaque classe ou groupe de codes est attribué à un seul propriétaire.
  • Équipes de fonctionnalité : bien qu’une personne soit responsable des performances et de la qualité de chaque classe, une fonctionnalité peut impliquer plus d’une classe, de sorte que tous les membres de l’équipe de fonctionnalité contribuent aux décisions concernant la conception et la mise en œuvre.
  • Inspections : les équipes FDD effectuent des inspections pour détecter les défauts et garantir la meilleure qualité.
  • Gestion de la configuration : cette pratique consiste à identifier le code source de toutes les fonctionnalités et à en consigner les modifications.
  • Calendrier de réalisation périodique : cette bonne pratique permettra à l’équipe de disposer en permanence d’un système à jour qu’elle pourra présenter au client.
  • Rapports d’avancement : les chefs de projet doivent fournir fréquemment des rapports attestant du travail terminé.
FFD

Membres de l’équipe FDD

L’équipe de modélisation FDD comprend les rôles principaux suivants :

  • Le chef de projet supervise l’ensemble du projet.
  • L’architecte en chef est chargé de la conception globale et de la modélisation du système. L’architecte en chef collabore avec d’autres développeurs qualifiés au cours de la phase de planification du cycle de développement.
  • Le responsable du développement dirige et encadre l’équipe de développement et supervise les activités de programmation quotidiennes.
  • Le programmeur principal participe à l’analyse et à la conception, et peut également être chargé de diriger de petites équipes de développement.
  • Le propriétaire de la classe est membre des petites équipes de développement dirigées par le programmeur principal. Ses responsabilités comprennent la conception, le codage, les tests et la documentation des fonctionnalités.
  • L’expert en domaine est membre d’une équipe qui comprend le problème que le client doit résoudre. Les développeurs s’appuient sur les connaissances de l’expert en domaine pour s’assurer qu’ils œuvrent et fournissent les éléments qui comptent le plus pour le client.

Pourquoi utiliser le feature driven development ?

Vous pouvez envisager d’utiliser la méthodologie FDD si votre projet devient trop volumineux et complexe pour que les petites équipes Scrum puissent gérer efficacement la quantité de travail à abattre. Cette méthodologie agile axée sur les fonctionnalités convient parfaitement aux projets à long terme qui changent continuellement et ajoutent des fonctionnalités via des itérations régulières et prévisibles. 

Le FDD permet de passer facilement de petites équipes à de grandes équipes transversales, car il est conçu pour toujours se concentrer sur les besoins et les souhaits du client.

Avantages du FDD

  • Donne à l’équipe une très bonne compréhension de la portée et du contexte du projet.
  • Nécessite moins de réunions. L’une des plaintes fréquentes concernant la méthode agile concerne le nombre trop important de réunions. Scrum fait reposer la communication sur des réunions quotidiennes. Avec FDD, c’est la documentation qui est utilisée à cet effet.
  • Utilise une approche centrée sur l’utilisateur. Avec Scrum, le chef de produit est généralement considéré comme l’utilisateur final. Avec le FDD, le client est l’utilisateur final.
  • Fonctionne bien avec des projets à grande échelle, à long terme ou en cours. Cette méthodologie est très évolutive et peut s’adapter à la croissance de votre entreprise et du projet. Cinq étapes bien définies permettent aux nouveaux membres de l’équipe ou aux nouvelles recrues de se familiariser très rapidement avec le projet.
  • Décompose les ensembles de fonctionnalités en petits morceaux et en versions itératives périodiques, ce qui facilite le suivi et la correction des erreurs de codage, réduit les risques et vous permet de répondre rapidement aux besoins de votre client.

Inconvénients du modèle de feature driven development

  • Le FDD n’est pas idéal pour les petits projets et ne fonctionne pas pour les projets où il n’y a qu’un seul développeur, car il est difficile pour une personne ou un petit groupe de personnes d’assumer les différents rôles sans aide.
  • Dépend fortement d’un programmeur principal qui doit être capable d’agir en tant que coordinateur, concepteur principal et mentor pour les nouveaux membres de l’équipe.
  • Ne fournit aucune documentation écrite au client, bien qu’il y ait beaucoup de communication documentée entre les membres de l’équipe pendant les cycles de développement du projet. Par conséquent, le client n’est pas en mesure d’obtenir de justificatifs pour son propre logiciel.
  • Met l’accent sur la propriété individuelle du code au lieu d’une propriété partagée par l’équipe.
  • Peut ne pas fonctionner correctement avec les anciens systèmes, car il existe déjà un système en place et aucun modèle global pour le définir. Il se peut que vous deviez repartir de zéro.

Les 5 étapes du cycle de vie d’un projet FDD

Maintenant que vous connaissez les avantages du développement basé sur les fonctionnalités, examinons ses différentes étapes pour que vous puissiez commencer à les mettre en œuvre avec votre équipe.

Étape 1 : Développer le modèle global

C’est à cette étape que vous rédigez votre plan pour définir votre modèle de domaine, le problème commercial que votre projet de développement logiciel doit résoudre. L’équipe travaille en étroite collaboration avec l’architecte en chef pour définir la portée et le contexte du système. Plusieurs modèles de domaine doivent être fusionnés en un modèle global qui servira d’ébauche à votre système.

Étape 2 : Établir une liste de fonctionnalités

La liste des fonctionnalités est similaire au backlog produit Scrum. Identifiez les fonctionnalités qui sont importantes pour le client et exprimez-les en tant qu’action, résultat et objet (par exemple, « valider le numéro de compte de l’utilisateur »). 

Le développement d’une fonctionnalité donnée ne devrait pas prendre plus de deux semaines. Dans le cas contraire, elle devra être divisée en fonctionnalités plus petites.

3 : Planifier par fonctionnalité

Déterminez l’ordre dans lequel les fonctionnalités de votre liste de fonctionnalités seront développées et mises en œuvre. Tenez compte des risques, des dépendances, de la charge de travail de l’équipe et des individus, et de tout autre obstacle qui pourrait entraver le développement des fonctionnalités.

Attribuez ensuite les ensembles de fonctionnalités aux programmeurs les plus compétents et disposant du temps nécessaire pour les développer dans les délais impartis. 

4 : Concevoir par fonctionnalité

Le programmeur principal détermine quelles fonctionnalités seront conçues et intégrées dans une itération de deux semaines. Cette personne définit également les priorités relatives aux fonctionnalités et détermine qui fera partie de l’équipe chargée des fonctionnalités. Une revue de la conception doit être effectuée par toute l’équipe avant de poursuivre.

5 : Créer par fonctionnalité

Lors de cette étape, tous les éléments nécessaires au développement de la fonctionnalité sont mis en œuvre. L’interface utilisateur est conçue, et un prototype de fonctionnalité est conçu et testé. Si la fonctionnalité réussit le test et est approuvée, la version finale peut être ajoutée à la version principale et mise à la disposition des clients. 

feature driven development

Dans le cadre des bonnes pratiques du FDD, vous devez fournir des rapports relatifs à l’avancement des travaux au fur et à mesure de leur réalisation. Lancez-vous à l’aide de notre modèle gratuit.

Ouvrez-le maintenant

Si vous travaillez dans une grande entreprise et que vous vous attaquez à de grands processus complexes, une approche agile basée sur les fonctionnalités peut vous convenir. Le FDD est conçu pour s’adapter à l’évolution de votre entreprise et de votre projet, et fonctionne bien si votre produit nécessite un développement continu à long terme. L’accent mis sur les fonctionnalités vous permet de répondre plus rapidement aux besoins des clients et vous aide à identifier et à résoudre les problèmes qui pourraient survenir.

Essayez Lucidchart dès maintenant !

Commencez à créer des diagrammes avec Lucidchart dès aujourd'hui – essayez notre solution gratuitement !

Inscription gratuite

À la une

The 4 Phases of the Project Management Life CycleLes 4 phases du cycle de vie de la gestion de projet

À propos de Lucidchart

Lucidchart est un éditeur de diagrammes intelligents qui permet aux équipes de simplifier la compréhension, de partager une vision commune et de construire l'avenir plus rapidement. Grâce à cette solution intuitive et basée sur le cloud, chacun peut travailler visuellement et collaborer en temps réel à la création de logigrammes, de maquettes, de diagrammes UML et bien plus encore.

Alternative à Visio la plus populaire, Lucidchart est une plateforme en ligne utilisée dans plus de 180 pays par plusieurs millions d'utilisateurs, des directeurs commerciaux chargés de cartographier leurs entreprises clientes aux responsables informatiques souhaitant visualiser leur infrastructure réseau.

Démarrer

  • Tarifs
  • Individual
  • Équipe
  • Entreprise
  • Contact commercial
ConfidentialitéMentions légalesCookies

© 2022 Lucid Software Inc.