… à l'Ecole de la V.I.E …

Agile et le Feature Driven Development (FDD)

Feature Driven Development est une méthode agile développée par Jeff de Luca et Peter Coad en 1997 pour mieux gérer les risques existants dans les projets de développement.

L’idée de base de la méthode est de procéder par itérations très courtes, de deux semaines, avec production à la fin de chaque itération d’un livrable fonctionnel.

Les spécifications sont découpées le plus possibles en caractéristiques simples : les « features » que l’on peut regrouper en « feature sets ».

Intérêt

– pour le client

Les clients ont une vue claire sur le planning et les différentes étapes du projet. Ils ont aussi des résultats concrets qui leur prouvent l’avancée du projet.

– pour les managers

Du point de vue des managers, cette façon de procéder permet de connaître facilement l’état d’avancement du projet et d’avoir du concret à montrer au client à chaque fin d’itération. Le fait de délivrer fréquemment des composants fonctionnels permet aussi une bonne gestion du risque.

– pour les développeurs

Pour les développeurs, procéder par itérations est très motivant puisqu’ils doivent être capables de livrer toutes les deux semaines des composants qui sont utiles au client, qui fonctionnent et sont porteurs de valeur pour lui.

Bénéfice

Cette pratique encourage la créativité, l’innovation et l’exploration et conduit à la découverte de nouvelles fonctionnalités qui apporteront un avantage concurrentiel.

Notions de   » Feature  » et  » feature set « 

– Feature

Feature désigne une fonctionnalité porteuse de valeur pour le client, susceptible d’être implémentée en deux semaines ou moins.

Le formalisme utilisé pour les décrire est le plus simple possible : <action> the <result> <by, for, of, to> a(n) <object> (ex : calculate the total of a sale).

Ce découpage en fonctionnalités simplissimes permet au client d’exprimer ce qu’il attend de manière très simple.

– Feature set

Ces features sont regroupées en groupes qui participent à une même fonction plus globale.

Le formalisme utilisé pour décrire les feature sets est alors : <action><-ing> a(n) <object> (ex : making a product sale to a customer).

En pratique, les 5 phases d’un projet FDD

Phase 1 : Développer un modèle global

Phase 2 : Établir une liste détaillée de features classées par priorité

Phase 3 : Planifier à partir des features

Phase 4 : Concevoir à partir des features

Phase 5 : Construire à partir des features

Forces et faiblesses de FDD

FDD présente les avantages des méthodes agiles, à savoir gestion des risques, flexibilité par rapport au changement, rapidité, livraisons fréquentes, etc. FDD a déjà été utilisé avec des équipes de taille conséquente pouvant aller jusqu’à une vingtaine de développeurs. Le facteur limitant cependant la taille d’une équipe est le nombre de développeurs seniors à disposition. La propriété du code revenant aux propriétaires de classes a l’avantage de ne permettre des modifications que par une personne qui a une vision globale d’une classe. On peut opposer à cela le principe de propriété collective du code en vigueur dans eXtreme Programming qui nécessite une plus grande discipline mais peut s’avérer plus rapide si un développeur a besoin de modifier du code écrit par un autre membre de l’équipe. L’inspection du code permet d’apporter un regard neuf sur chaque portion du code et permet ainsi de produire un code de meilleur qualité. Cependant, la personne qui inspecte le code ne le connaît pas a priori et il lui faut donc un minimum de temps pour se familiariser avec ce code. Encore une fois, il peut s’avérer plus judicieux de passer à la programmation en binôme pour éviter cette perte de temps et faire la révision du code en même temps que son écriture. FDD n’est d’ailleurs par fermée à ce genre de pratiques qui poussent l’agilité encore plus loin.

Filed under:
Agile, Agile et le Feature Driven Development (FDD), FDD, Feature Driven Development, Méthodes Agile by admin