Le FDD (Feature-driven development) est une méthode agile créée par Jeff De Luca en 1997 ; cette méthode agile basée sur des concepts incrémental et itératif avait été créée pour une grande banque singapourienne.
Curieusement pour ceux qui découvrent cette méthode agile FDD beaucoup moins populaire qu’un Scrum, il faut savoir que sa première publication était au sein du livre Java Modeling in Color avec UML et non pas dans une oeuvre à part entière.
Le FDD (Feature-driven development) en quelques mots
Pour ceux qui sont dans les grands groupes, vous allez être étonné de découvrir cette méthodologie FDD car on y trouve beaucoup de choses qui se mettent en place dans ces grands groupes… Et ce sont mêmes des choses dites « non agile ».
En fait le FDD est ancien et il est vrai que l’agilité a en réalité évolué avec le temps. Cependant, on la considère comme l’une des méthodes agiles existantes malgré ses contradictions avec des méthodes agiles telles que XP ou Scrum.
Le FDD (Feature-driven development) propose :
- des itérations courtes et grandes
- d’avoir une meilleure communication durant l’ensemble du développement
- de faire des livraisons fréquentes avec de vrais travaux terminés
- des informations de progression et d’état précises et significatives pour un minimum de coût et de perturbation pour les développeurs.
- d’avoir des processus appréciés par les clients, développeurs et managers
Les itérations du FDD en 5 étapes
Une itération en FDD (Feature-driven development) se compose en 5 étapes différentes :
- Créer le modèle du système avec un diagramme de classes UML
- Faire la liste des fonctionnalités à réaliser
- Assigner les fonctionnalités aux développeurs
- Créer le modèle de chacune des fonctionnalités
- Développer chacune des fonctionnalités
Contrairement au Scrum et à l’Extrême programming, le FDD recommande fortement d’assigner les fonctionnalités à un ou des développeurs précis.
Les 6 rôles clés en FDD (Feature-driven development)
La méthodologie FDD définit 6 rôles clés dont certains peu appréciés par la communauté agile d’aujourd’hui.
The Project Manager (PM)
En FDD, il existe bien ce rôle tant rejeté par les communautés agiles d’aujourd’hui. Il aura comme rôle de faire les bons reportings d’avancement, de se battre pour le bien être de l’équipe, de s’occuper des budgets, du recrutement et de la logistique.
Si on regarde de près cette description, c’est souvent le rôle attribué aux Scrum Master dans les grands groupes qui ont du mal à devenir 100% Scrum Master.
The Chief Architect (CA)
Le CA est responsable de la modélisation complète de l’architecture pour le produit en cours de développement.
The Development Manager (DM)
Le DM est responsable de l’activité des développements. En effet, nous sommes dans une méthode agile totalement en opposition avec Scrum bien qu’au final, on retrouve plus ou moins ces types de rôles au sein des grands groupes.
Certains seront ravi de découvrir cette méthode agile pour dire qu’au final c’est agile de fonctionner avec des rôles aussi précis fortement déconseillés dans d’autres méthodes agiles… C’est pas totalement faux, disons que l’agilité à évolué et que les coachs préconisent dans une grande majorité la partage des responsabilités.
The Chief Programmers
En FDD, les développeurs expérimentés travailleront sur la partie analyse et les spécifications techniques. On les rend responsables d’un groupe de 3 à 6 développeurs chacun.
The Class Owner
Ce sont des développeurs qui travaillent en petits groupes justement sous le le Chief Programmer avec comme rôles de développer, de tester et de documenter les fonctionnalités réalisées.
The Domain Experts
Ce rôle est en fait représenté par les Utilisateurs clés, Sponsors et Business Analyst. Ils sont présent pour identifier les besoins et permettent aux développeurs de travailler. Leur présence est indispensable pour avoir un produit de qualité.
Des rôles transverses en FDD
Il existe quelques rôles transverses proposés par la méthode comme le Release Manager, le Language Guru (formateur de développeurs), le Build Engineer (responsable des build applicatif), le Toolsmith (développeur de petits outils ou librairies pour les développeurs) et le System Administrator.
Le FDD (Feature-driven development) propose également de rajouter des testeurs, des Deployers et des Technical Writers (ceux qui écrivent les documents techniques).
Les pratiques du FDD (Feature-driven development)
En FDD (Feature-driven development), il y a des pratiques qui sont très privilégiées. Nous devons par exemple avoir l’utilisation de l’UML Color (couleurs pour les classes) pour réaliser les modèles de classes.
Travaillons par feature
Le FDD privilégie fortement le développement par feature. Une « feature » doit comme une user-story être possible à développer en deux semaines. Si ce n’est pas le cas il faut découper la « feature » en deux features distinctes.
D’ailleurs, il existe un format classique pour écrire des features en FDD :
<action> the <result><by|for|of|to|><a(n)><object>
Par exemple, on pourrait avoir :
Calculer [action] le total [result] d'une vente [object].
En parlant de feature, les équipes en FDD sont définies en Feature Team qui seront responsables des parties sur lesquelles elles interviennent ; cela implique que la feature team sera choisi également à l’avenir pour des développements concernant leurs périmètres.
Ces feature teams seront d’ailleurs au maximum autonomes pour travailler sur leur périmètre.
Les développeurs sont responsables
Une pratique totalement en opposition avec les méthodes agiles aujourd’hui en place au sein des entreprises est le fait de faire des « Class Ownership ». En gros une classe dans le code est de la propriété d’un développeur (ou de deux développeurs) tant qu’il est au sein de l’entreprise. Si un développement doit se faire à nouveau sur cette classe à l’avenir, on privilégiera que son propriétaire travaille dessus.
On privilégie cependant quand cela est possible d’avoir deux Class Owner pour diminuer les craintes d’être seul responsable (ressenti du développeur) en cas de problème.
Des builds réguliers
Le FDD impose le fait d’avoir des build réguliers (ou mise en recette) afin de pouvoir tester régulièrement l’avancement du produit. La récupération de feedback est un point essentiel dans les produits agiles.
Outil de reporting d’avancement
Le FDD impose comme le fait d’ailleurs d’autres frameworks, le fait de faire du reporting d’avancement. Il est très important dans les projets d’avoir de la transparence sur l’avancement du projet afin de pouvoir gérer au plus vite les éventuels obstacles.
Le FDD est-il vraiment une méthode agile ?
En effet, le FDD répond à l’ensemble des valeurs et des principes du Manifeste Agile. En fait, il y a souvent une erreur de faites dans le monde de l’agilité : le fait d’avoir des rôles techniques très précis, le fait d’assigner le travail aux développeurs sont des pratiques que le Scrum refuse totalement… mais ce n’est pas interdit dans le monde de l’agilité.
Maintenant, la façon de travailler en FDD (Feature-driven development) fait plus penser à des pratiques anciennes que récentes.
Conclusion FDD (Feature-driven development)
Est-ce que les entreprises (souvent les grands groupes) qui font un Scrum avec des chefs de projet et architectes ne sont pas agiles ? En fait ce sont des équipes qui détournent le Scrum mais cela ne les rend pas anti-agile pour autant.
Pour ma part, je recommande quand même d’avoir des équipes techniques multi-disciplinaires car la formule fonctionne plutôt bien : équipe motivée, turn-over sans risque…. Peut-être parce que c’est plus dans l’ère du temps.
J’espère que cet article vous permettra de connaitre une nouvelle méthode agile ; Certaines de ses pratiques pourraient vous aider un jour.
Super article qui montre bien que l’agilité est agile et évolue elle aussi ^^(et ne se résume pas à scrum, kanban et au lean).
Une des idées intéressantes à retenir du FDD est notamment le format d’écriture qui s’applique bien à ce qu’on appelle souvent maladroitement « technical stories » par opposition aux « user stories ».
Eviter d’écrire des
ETQ base de donnée
JS supprimer la table X
AD diminuer la dette technique
mais plutôt des
Supprimer la table X pour mettre à jour le modèle de donnée