Parmi les différentes méthodologies agiles, il en existe une peu connue : le feature driven development (FDD) ou le développement basé sur les fonctionnalités en français.
Cette méthode est idéale pour les projets vastes et complexes dont la quantité de travail ne peut pas être gérée efficacement avec une méthode Scrum. Elle convient aux projets à long terme qui changent régulièrement et auxquels s’ajoutent de nouvelles fonctionnalités à travers des itérations régulières et prévisibles.
Définition
Le feature driven development (FDD) est une méthodologie agile dont la particularité est d’organiser le développement d’un logiciel autour de la réalisation et de la progression des fonctionnalités. En suivant la philosophie agile, l’idée est de travailler en itération courtes (une à deux semaines) et de produire un livrable fonctionnel à la fin de chaque itération. Si une fonctionnalité ne peut pas être réalisée en deux semaines, elle doit être divisée en fonctionnalités plus petites et plus facilement gérables.
Des petites équipes aux grandes équipes multidisciplinaires, la méthode FDD est très évolutive car elle est conçue pour toujours se concentrer sur les besoins et les exigences du client.
Le feature driven development se déroule en cinq étapes, ce qui garantit la cohérence dans le développement du projet et permet aux nouveaux membres de l’équipe de se mettre à niveau beaucoup plus rapidement.
Origine de la méthode FDD
La méthode feature driven development a été mise au point par Jeff De Luca afin de répondre aux besoins spécifiques d’un important projet de développement de logiciel (15 mois et une équipe de 50 personnes) pour une banque singapourienne en 1997.
L’objectif était d’aider son équipe à être plus réactive et capable de s’adapter aux besoins du client. Pour cela, il a créé un modèle de développement en cinq étapes qui se concentre sur le développement de fonctionnalités en courtes itérations.
Comment ça marche ?
La méthode FDD suit un processus de développement en cinq phases.
1. Développer un modèle global
Lors de cette première étape, vous devez définir les grandes lignes de votre modèle de domaine, c’est-à-dire la problématique que votre projet de développement logiciel va permettre de résoudre. L’équipe collabore étroitement avec l’architecte en chef pour définir l’étendue et le contexte du système.
Plusieurs modèles de domaine sont créés (pour chaque domaine de modélisation) par différents petits groupes, puis ceux sélectionnés sont fusionnés pour former un modèle global.
2. Etablir une liste de fonctionnalités
La liste de fonctionnalités correspond au product backlog de la méthode Scrum. Ici, vous devez identifier les fonctions du logiciel qui sont importantes pour le client. Ces fonctionnalités peuvent être formulées comme des actions, des résultats ou des objets. Par exemple, « calculer le montant total du panier d’un client » ou « valider le mot de passe d’un utilisateur » sont des fonctionnalités.
Chaque fonctionnalité ne doit pas prendre plus de deux semaines pour être développée, sinon elle doit être décomposée en plus petites fonctionnalités.
3. Planifier à partir des fonctionnalités
Cette étape permet de planifier l’ordre dans lequel chaque fonctionnalité sera développée et mise en œuvre. Comme pour n’importe quel projet, vous devez prendre en compte les risques potentiels, les dépendances entre les différentes tâches, la charge de travail de vos collaborateurs ainsi que tous les autres obstacles qui peuvent nuire au bon déroulement du projet.
Ensuite, assignez les fonctionnalités aux personnes (programmeurs) les plus compétentes pour qu’elles les réalisent dans les délais.
4. Concevoir par fonctionnalités
C’est le programmeur en chef qui détermine quelles fonctionnalités seront conçues lors d’itérations de deux semaines. C’est également lui qui définit les priorités et désigne les membres de l’équipe qui seront impliqués. Avant de passer à l’itération suivante, l’ensemble de l’équipe passe en revue la conception de la fonctionnalité.
5. Construire à partir des fonctionnalités
Dans cette étape, tous les éléments qui accompagnent la conception de la fonctionnalité sont réalisés. L’interface utilisateur est créée, et un prototype de la fonctionnalité est construit et testé. Si le test est réussi et que la fonctionnalité est validée, sa version finale est alors ajoutée au logiciel et elle devient accessible aux clients.
Avantages et inconvénients
La méthode FDD comporte différents atouts.
- En tant que méthode agile, il s’agit d’une approche centrée sur l’utilisateur final.
- Son processus simple en cinq étapes permet un développement plus rapide du produit.
- Le fait de diviser les fonctionnalités en petites itérations régulières facilite le suivi et la correction des erreurs, diminue les risques et permet de répondre rapidement aux besoins du client.
- La méthode permet aux grandes équipes d’avancer dans le projet en enchaînant les réussites.
- Les équipes ont une bonne compréhension du contexte et de l’étendue du projet, et elles progressent plus rapidement grâce à des standards de développement prédéfinis.
Cependant, comme toutes les méthodes, FDD possède également ses faiblesses.
- Elle n’est pas adaptée pour les petits projets.
- Cette méthode repose beaucoup sur une seule personne : le programmeur en chef. Celui-ci doit jouer plusieurs rôles (coordinateur, designer principal et mentor auprès des nouveaux membres de l’équipe), ce qui, dans un projet vaste et complexe, peut augmenter le risque de commettre des erreurs.
- Très peu de documentation écrite est fournie au client.
- Le FDD ne fonctionne pas très bien avec des systèmes déjà en place. Il est préférable de repartir de zéro.
Conclusion
Si vous hésitez entre plusieurs méthodes agiles, sachez que le feature driven development vous conviendra si vous faites partie d’une grande entreprise et que vous travaillez sur des projets de développement logiciel vastes et complexes, qui s’étendent sur le long terme. En vous focalisant sur les fonctionnalités, vous pourrez répondre aux besoins du client plus rapidement, et vous serez plus efficace pour identifier et corriger les problèmes qui pourraient survenir.
Cependant, notez qu’il est important que cette méthode corresponde à la culture de votre entreprise pour être plus facilement adoptée par vos collaborateurs.
Source : https://www.lucidchart.com/blog/why-use-feature-driven-development
