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.