Estimation agile des fonctionnalités

Idéalement, une fonctionnalité devrait respecter les critères suivants

1. Il devrait fournir valeur commerciale.
2. CA devrait etre estimable – Elle doit être suffisamment définie pour permettre à l'équipe de développement d'estimer le travail nécessaire à sa mise en œuvre.
3. CA devrait etre assez petit pour tenir dans une itération – par conséquent, si elle est trop grande, elle doit être divisée davantage.
4. CA devrait etre testable – Vous devez comprendre quels tests automatisés ou manuels une fonctionnalité doit réussir pour être acceptable par le client.

Les différentes méthodologies utilisent une terminologie différente pour désigner les fonctionnalités. Il appartient à l'équipe de choisir la méthodologie et la terminologie à employer. L'eXtreme Programming (XP) utilise les termes « user stories » ou « stories » pour représenter les fonctionnalités ; Scrum utilise le « backlog produit » pour décrire une liste de fonctionnalités ; le développement piloté par les fonctionnalités utilise le terme « fonctionnalité » ; et DSDM utilise le terme « exigence ». De même, il existe différentes versions allégées du processus unifié, ou Agile UP, qui utilisent les termes « exigence » et/ou « cas d'utilisation » pour définir des fonctionnalités livrables de manière incrémentale. Au final, l'objectif reste le même : fournir régulièrement de la valeur ajoutée à l'entreprise par petites étapes, et ce, le plus rapidement possible.

Différences méthodologiques

Scrum appelle une fonctionnalité élément de l'arriéré, qui a tendance à être plus détaillé et peut également inclure des éléments non liés aux fonctionnalités, tels que « configurer le matériel de production » ou « rechercher les options xyz ».

XP appelle une fonctionnalité DE BOUBA, ce qui se prête à une approche particulièrement utile pour définir les fonctionnalités.

DSDM appelle une fonctionnalité exigence, ce qui peut également inclure plus que de simples fonctionnalités système.

Agile UP Les praticiens utilisent exigences et cas d'utilisation définir les fonctionnalités.

Structure de décomposition des fonctionnalités (FBS)

Lors de la planification détaillée, développement agile Elle privilégie une approche par structure de décomposition des fonctionnalités (FBS) plutôt que par structure de décomposition du travail (WBS) comme dans les approches de développement en cascade. Les structures de décomposition des fonctionnalités présentent plusieurs avantages :

1. Elles permettent une communication entre le client et l'équipe de développement dans des termes que les deux parties peuvent comprendre.
2. Elles permettent au client de prioriser le travail de l'équipe en fonction de sa valeur commerciale.
3. Ils permettent de suivre le travail effectué par rapport à la valeur commerciale réelle produite.

Il est tout à fait acceptable de commencer par des fonctionnalités importantes, puis de les décomposer progressivement en fonctionnalités plus petites. Cela permet au client d'éviter de se perdre dans les détails tant que ceux-ci ne sont pas nécessaires à la conception et à la mise en œuvre concrètes.

Élaboration d'une liste de fonctionnalités initiale

Avant la planification des versions et planification itérativeL'équipe doit rapidement dresser une liste aussi exhaustive que possible des fonctionnalités potentielles du système. Généralement, une seule personne est chargée de recueillir ces fonctionnalités (par exemple, un chef de produit, un client, un chef de projet, un analyste métier ou un autre représentant du client), mais les demandes de fonctionnalités peuvent provenir de sources diverses : utilisateurs, clients, équipes commerciales et marketing, appels d'offres, membres de l'équipe de développement, direction, concurrents et réglementations gouvernementales. La liste centrale des fonctionnalités de l'équipe doit comporter des mécanismes de contrôle afin d'éviter les doublons, les fonctionnalités irréalisables et les demandes trop vagues. L'équipe doit toutefois être encouragée à ajouter de nouvelles fonctionnalités au fur et à mesure qu'elle les identifie, afin qu'elles puissent être intégrées au processus de priorisation et de planification.

Une liste initiale de fonctionnalités peut servir d'ébauche, d'ensemble, pour planifier la version et la première itération. Elle représente le potentiel actuel du système, potentiellement sur plusieurs versions. Il n'est pas nécessaire d'attendre que toutes les fonctionnalités soient définies pour commencer. livraison de logicielsEt vous n'êtes pas obligé de vous en tenir aveuglément à la liste, aux descriptions ou aux priorités initiales. Un des principes fondamentaux du développement agile est que cette liste (comme tout le reste) évolue, itération après itération.

Imaginons qu'une liste préliminaire des fonctionnalités soit finalisée, qu'un plan de lancement et un plan d'itération soient élaborés, et que la première itération soit terminée, avant même que quelques fonctionnalités critiques ne soient identifiées. Ces fonctionnalités sont alors simplement intégrées au plan de lancement évolutif et à une itération ultérieure, et livrées dès que possible. En attendant, le temps n'est pas perdu. L'équipe commence à apporter de la valeur au plus vite et met en place l'infrastructure nécessaire pour permettre au projet de s'adapter au fil du temps aux nouvelles priorités, informations et dynamiques commerciales.

Liste des fonctionnalités

Lors de l'élaboration d'une liste de fonctionnalités, celles-ci sont initialement décrites dans un court paragraphe, généralement de deux à quatre phrases. Cette description constitue un résumé général de la fonctionnalité, un point de départ pour une compréhension préliminaire et une base pour les communications ultérieures. Elle s'apparente au titre d'un article à rédiger ultérieurement. L'objectif est de consacrer juste assez de temps à la description de la fonctionnalité pour bien comprendre son importance relative, sa complexité et sa priorité par rapport aux autres fonctionnalités. D'autres détails apparaîtront ultérieurement. planification itérativeMais la compréhension précise et concrète de la fonctionnalité peut émerger au cours de l'itération, lorsque les clients et les développeurs en discutent suffisamment pour la mettre en œuvre, ou (dans certaines méthodologies) pour créer des tests d'acceptation automatisés qui la spécifient de manière déterministe.

Références utiles

Histoires d'utilisateurs

Témoignages d'utilisateurs appliqués : pour le développement logiciel agile par Mike Cohn

Webinaire

Comment exécuter la planification PI avec Digital.ai Agility

Fonctions d'organisation

Gérer une longue liste de fonctionnalités peut s'avérer complexe. Il est donc très utile de les organiser en précisant les catégories, les regroupements fonctionnels de haut niveau, la valeur ajoutée ou la priorité, ainsi que les risques. Le filtrage et le tri selon ces différents attributs permettent de découper une liste de fonctionnalités très volumineuse en éléments plus faciles à gérer.

L'ensemble des fonctionnalités doit être classé par ordre de priorité afin que l'équipe projet puisse facilement identifier les plus importantes. Si un projet débute avec 100 fonctionnalités, il est fréquent que 50 d'entre elles soient considérées comme « hautement prioritaires ». Un classement séquentiel des fonctionnalités permet de repérer celles qui sont absolument essentielles et qui, par conséquent, doivent être réalisées en premier afin d'optimiser la valeur ajoutée.

Comptabilisation des risques

Une attention particulière peut être portée aux risques associés à certaines fonctionnalités. Certaines fonctionnalités impliquent des conceptions, des architectures, des frameworks ou des algorithmes nouveaux pour l'équipe, ou présentant d'autres risques. Même si ces fonctionnalités n'apportent pas la plus grande valeur ajoutée à l'entreprise, il est souvent judicieux d'en augmenter la priorité afin de les traiter dès les premières itérations. Si une fonctionnalité à haut risque est abordée en début de projet et s'avère, pour une raison ou une autre, irréalisable, l'équipe a encore le temps de réagir et de trouver une solution de contournement. Cela minimise le risque global pour le projet. Il incombe à l'équipe de développement de collaborer étroitement avec le client pour identifier ces types de problèmes, de risques et de dépendances. La priorisation des fonctionnalités revient en dernier ressort au client, mais ce processus crucial ne doit pas être mené isolément. Les meilleures équipes travaillent ensemble pour apporter de la valeur et réduire les risques tout au long du cycle de vie d'un projet.

Caractéristiques d'estimation

Après avoir identifié les fonctionnalités, le client collabore souvent avec les principaux acteurs du développement pour définir des estimations de fonctionnalités. Ces estimations sont des estimations préliminaires de haut niveau qui servent de base à la définition des objectifs. planification des versions et la planification des itérations. Les parties prenantes impliquées dans l'estimation peuvent inclure des architectes, des responsables techniques, des développeurs, des testeurs, des rédacteurs et des gestionnaires. De nombreuses organisations ont mis en place des processus permettant à des groupes de collaborer pour fournir rapidement des estimations initiales. Cette étape peut s'avérer utile pour déterminer dans un premier temps si la fonctionnalité doit être décomposée plus en détail.

Lors de l'estimation initiale des fonctionnalités, l'objectif est de parvenir rapidement à une estimation globale raisonnable. Plutôt que de se concentrer sur le temps nécessaire (17.5 heures de conception, ou 17.5 oursons en gélatine, ou 1 noix, ou toute autre unité de mesure ; voir ci-dessous), l'objectif est d'obtenir une estimation suffisamment précise en un temps record. S'il faut deux minutes pour s'accorder sur un temps idéal de deux à trois jours pour implémenter la fonctionnalité, contre 30 minutes pour établir une estimation précise de 17,5 heures de conception, la première approche est préférable. Pour obtenir une estimation unique en cas de divergences d'opinions au sein du groupe, les équipes peuvent soit faire une moyenne, soit élaborer une approximation raisonnable, soit toujours retenir le scénario le plus favorable, soit encore effectuer un calcul intégrant le meilleur des cas, le pire des cas et l'estimation attendue si une plus grande complexité est justifiée. Dans tous les cas, les discussions autour des différentes estimations sont souvent riches d'enseignements.

Ce processus de définition et d'estimation des fonctionnalités peut paraître complexe au premier abord. Lors de sa mise en œuvre, les équipes peuvent avoir besoin de plusieurs réunions pour trouver une méthode qui leur convienne. Avec le temps, il devient plus facile de décomposer les fonctionnalités en unités de travail réalisables en une seule itération. Les équipes excellent dans ce qu'elles pratiquent, et le développement agile leur permet de s'exercer à l'estimation à chaque version et à chaque itération.

Unités d'estimation

Par définition, les estimations sont imprécises, et les développeurs ont toujours eu du mal à estimer correctement le temps nécessaire à la réalisation d'une tâche de développement. Les estimations du temps de programmation effectif sont souvent inexactes (surtout si elles ne sont pas rigoureusement comparées aux données réelles). Mais le temps consacré aux tâches non liées à la programmation est encore plus difficile à évaluer. Que répondez-vous si quelqu'un vous demande combien de temps il faut pour traverser la ville en voiture ? Vous utilisez une mesure relative : « Une heure en dehors des heures de pointe, par beau temps, s'il n'y a pas de travaux, sinon peut-être deux heures », etc. Ces facteurs externes sont impossibles à contrôler et difficiles à prévoir. Outre le développement du code, les programmeurs consacrent du temps aux tests, à la rédaction de la documentation, à la conception, aux réunions et aux revues de code, à la gestion des e-mails, etc. Comparé au travail de programmation, le travail non lié à la programmation est difficile à prévoir et à contrôler. Il peut varier en fonction du secteur d'activité, de l'entreprise, de la période de l'année et de toute autre pression externe sur l'organisation.

Certaines équipes demandent aux programmeurs d'inclure chaque activité non liée à la programmation dans leurs estimations. Or, comme nous l'avons dit, cela n'est pas chose aisée. Pour un projet agile donné, bien avant de mesurer précisément le temps consacré aux tâches non liées à la programmation, l'équipe peut connaître le travail relatif nécessaire à la réalisation des différentes fonctionnalités et planifier en conséquence. C'est pourquoi les équipes agiles ont généralement tendance à axer leurs estimations sur ce qui est le plus simple à estimer et à mesurer : la programmation proprement dite. Elles se concentrent sur la charge de travail de chaque fonctionnalité et de chaque tâche technique, par rapport aux autres fonctionnalités et tâches techniques. Elles laissent le temps consommé par ces tâches non liées à la programmation se préciser à mesure que la vélocité réelle se dégage après quelques itérations. Deux principales unités d'estimation permettent aux équipes agiles de se concentrer ainsi sur la programmation :

• Unités de travail
• Moment idéal

Unités de travail

Une unité de travail est une mesure relative qu'il est essentiel de ne pas confondre avec le temps absolu. Voici quelques exemples :

• Points
• Ours gummi
• Pieds-livres
• NUT (Unités de Temps Nébuleuses)

Ces unités représentent la charge de travail relative nécessaire à la mise en œuvre d'une fonctionnalité (ou d'une tâche), par rapport aux autres fonctionnalités (ou tâches). Ce n'est qu'une fois que l'équipe a atteint une vélocité stable, généralement après quelques itérations, qu'elle peut commencer à convertir ces unités de travail en unités de temps réel. C'est précisément l'objectif de la vélocité : décrire la quantité de travail que l'équipe peut accomplir par unité de temps réel.

Une fois que l'équipe ou l'organisation s'est accordée sur une unité d'estimation, elle doit s'engager à l'appliquer de manière cohérente et à respecter sa définition initiale. Surtout lors des premières itérations du projet, il est important de résister à la tentation de faire correspondre ces unités à des unités de temps avec une précision absolue.

Moment idéal

À l'instar des unités de travail, le temps idéal exclut le temps hors programmation. Lorsqu'une équipe utilise le temps idéal pour ses estimations, elle se réfère explicitement au temps de programmation nécessaire à la réalisation d'une fonctionnalité ou d'une tâche, par rapport aux autres fonctionnalités ou tâches. De même, lors des premières itérations, l'historique des estimations s'accumule, une vélocité réelle se dessine et le temps idéal peut être converti en temps réellement écoulé.

De nombreuses équipes utilisant le temps idéal ont constaté que leur effort final dépasse de 1 à 2 fois les estimations initiales des programmeurs, et que cet écart se stabilise, dans une fourchette acceptable, après quelques itérations. Le ratio varie d'une tâche à l'autre, mais sur une itération complète, les ratios développés par les équipes se sont avérés relativement constants. Pour une équipe donnée, un historique connu du ratio temps idéal/temps réel peut s'avérer particulièrement précieux pour la planification des versions. Une équipe peut rapidement analyser les fonctionnalités requises et fournir une estimation globale de 200 jours idéaux. Si son ratio historique temps idéal/temps réel est d'environ 2.5, l'équipe peut soumettre une estimation de 500 jours de projet en toute confiance. Dans le cadre d'un contrat à prix fixe, ce type d'estimation peut être fiable.

Estimation relative

De nombreuses équipes agiles utilisent la méthode d'estimation relative pour les fonctionnalités. Au lieu d'estimer les fonctionnalités sur un large éventail de longueurs unitaires, elles sélectionnent quelques catégories d'estimation relative (trois à cinq), ou compartiments, et estiment toutes les fonctionnalités en fonction de ces catégories.

Planification des fonctionnalités par rapport à la planification des tâches

Bien que l'accent soit mis, lors de cette phase initiale de planification, sur la rapidité et la charge de travail relative par fonctionnalité, il est nécessaire, à un moment donné, de décomposer les fonctionnalités en leurs tâches respectives et d'estimer plus précisément leur charge. Cela se produit lors de la planification des versions et de la planification des itérations. En général, les estimations de fonctionnalités et les estimations de tâches ont des objectifs différents :

• Les estimations de fonctionnalités permettent d'orienter la planification des versions et des itérations.
• L'estimation des tâches permet de mieux gérer la charge des ressources au sein d'une itération.

Du fait de leurs fonctions différentes, l'estimation d'une caractéristique ne correspond pas nécessairement à la somme des estimations de ses tâches. Toutefois, pour un ensemble de caractéristiques, il devrait exister au moins une corrélation approximative entre les estimations des caractéristiques et la somme des estimations des tâches associées.

Questions fréquentes

Quelle est la taille d'une fonctionnalité ?

Cela peut varier considérablement en fonction du travail de développement de votre équipe. En règle générale, une fonctionnalité doit être suffisamment petite pour être réalisée en une itération et suffisamment importante pour justifier une planification. Par exemple, il serait absurde de planifier uniquement des fonctionnalités d'une heure pour une équipe de dix personnes travaillant sur un sprint d'un mois. Cela représente beaucoup trop d'éléments à planifier et à suivre. Si certaines modifications de fonctionnalités sont très petites, il est souvent préférable de les regrouper en un seul élément plus important à des fins de planification. Considérez chaque heure de travail comme une tâche au sein de cette fonctionnalité.

Les correctifs de bugs sont-ils des fonctionnalités ?

C'est possible. Scrum, par exemple, préconise de consigner dans le backlog tout le travail à accomplir par l'équipe. Les méthodes courantes de gestion des bogues incluent : 1) la création d'une fonctionnalité distincte pour chaque bogue ; 2) la création d'une fonctionnalité intitulée « Correction des bogues » à chaque itération, détaillant la liste ou les types de bogues à corriger ; ou 3) la gestion séparée des bogues, sans suivi du temps passé. Le nombre et l'ampleur des bogues que votre équipe prévoit de rencontrer doivent être des facteurs déterminants dans le choix de la méthode.

Pourquoi estimer les caractéristiques ?

L'estimation des fonctionnalités permet d'orienter le classement et la planification des versions et des itérations. Pour déterminer la charge de travail à planifier sur une période donnée, il est indispensable d'estimer la taille de chaque tâche. Voir aussi : vitesse agileSi deux fonctionnalités ont une valeur commerciale égale, mais que l'une est deux fois plus petite que l'autre, l'équipe sera plus efficace si elle travaille sur la première fonctionnalité, qui devrait donc être classée avant la seconde.

Devrions-nous mettre à jour les estimations des fonctionnalités si les estimations des tâches ne correspondent pas ?

Non, ce sont les estimations des fonctionnalités qui déterminent la planification. Les estimations des tâches, quant à elles, déterminent l'allocation des ressources. Bien qu'il doive y avoir une corrélation entre les valeurs, elles n'ont pas besoin de correspondre exactement.