Quelle est l'agilité des points de fonction?

De nombreuses organisations ont appris qu'elles pouvaient mieux maîtriser leurs projets logiciels en les estimant avec des points de fonction. À la fois, nous constatons que de plus en plus d'organisations ont une méthode de travail Agile, généralement en appliquant Scrum. La grande question est de savoir si les points de fonction restent debout. Scrum les jette-t-il par-dessus bord? Ou les points de fonction ont-ils encore de la valeur dans un monde Agile? Dans ce blog, Jolijn Onvlee et Rini van Solingen montrent quelles frictions et similitudes il y a.

Agile / Scrum

Agile (avec Scrum comme approche la plus utilisée) est adopté par un nombre croissant d'organisations comme la solution à l'échec de grands projets informatiques. En commençant à livrer directement des logiciels, toutes les deux semaines, un client reçoit un aperçu direct des progrès et de la valeur ajoutée. Les utilisateurs n'ont plus à attendre la fonctionnalité avec la valeur commerciale la plus élevée. en outre, le flux continu de rétroaction conduit à des systèmes précieux qui fonctionnent, Plus vite. En réalité, avec l'utilisation de Scrum, un grand projet informatique est découpé en plusieurs petits projets. Cela facilite la réponse aux nouvelles informations et réduit considérablement la complexité de l'ensemble du projet.

Scrum gère les spécifications du système d'une manière radicalement différente. Le produit est décrit uniquement en termes généraux (appelé le Backlog produit).ensuite, au début, seules les parties qui ont la plus grande valeur commerciale sont élaborées en détail et les thèses sont livrées rapidement. Après cette livraison, la valeur commerciale la plus élevée est à nouveau déterminée, développé et livré, etc. Un réglage constant est possible de cette manière. Cela remplace l'idée originale d'un projet qui fournit un résultat prédéfini. L'estimation de l'ensemble de la livraison n'a plus de sens, simplement parce que toute la portée n'est plus élaborée en détail. La tache à l'horizon peut changer à tout moment.

Friction

Scrum gère l'estimation et la budgétisation différemment d'une approche plus traditionnelle et systématique. L'approche traditionnelle utilise souvent l'analyse des points de fonction (FPA) pour la quantification. FPA est utilisé pour estimer le coût de fabrication du logiciel et combien de temps il faudra pour le livrer.. Un point de fonction est utilisé comme métrique pour déterminer la taille du système. Ce dimensionnement se fait sur la base des spécifications fonctionnelles. Un certain degré de détail de ce que vous allez faire est nécessaire pour FPA.

Il semble donc que les points de fonction et Scrum ne correspondent pas. Après tout, le premier veut une spécification complète à l'avance et l'autre veut remettre en question et mettre à jour la spécification à tout moment et ne va pas trop loin dans les détails. Les sprints dans l'approche Scrum sont trop courts et trop variés pour être estimés en fonction des points de fonction. À la fois, également au sein des organisations Agile, il est nécessaire de contrôler les coûts. "Nous verrons à la fin combien cela a coûté" est inacceptable pour la plupart des organisations. Cela signifierait qu'Agile crée une anarchie dans les dépenses informatiques, ce qui est insensé. Même avec Scrum, un client a besoin de contrôle. Le Product Owner souhaite conserver une vue d'ensemble des résultats de tous ces efforts (objectif) et combien de temps et d'argent cela a coûté à la fin (budget). Et c'est précisément là que le FPA traditionnel propose une solution.

Similitudes

Si vous regardez en détail la combinaison de FPA et Scrum, vous voyez qu'ils se renforcent plutôt qu'ils ne s'affaiblissent. Après tout, FPA aide à établir la portée globale (la tache à l'horizon) et le budget approprié. Scrum aide à réaliser d'abord les fonctions avec la valeur commerciale la plus élevée dans ce budget. Dès que possible, des commentaires sont intégrés au processus de livraison. Commentaires sur deux fronts: première, si la portée globale est correcte et, Deuxièmement, si tout le problème peut être résolu dans les limites du budget.

En pratique, cela signifie que l'arriéré du projet est déterminé au niveau mondial. Dans Scrum, il est courant que la partie du produit ayant la valeur commerciale la plus élevée ait déjà une quantité importante de détails. Ce niveau de détail (de préférence pour un certain nombre de sprints) est généralement suffisant pour faire une analyse des points de fonction. Vous pouvez ensuite utiliser cette analyse pour déterminer le nombre total de points de fonction pour l'ensemble du backlog en extrapolant. Dans la méthode FPA, cela sera autorisé.

Scrum et FPA sont amis

En bref, Scrum et FPA peuvent s'entraider et se renforcer parfaitement. Les points de fonction vous aident à garder une emprise sur les dépenses totales. En utilisant Scrum, vous restez flexible en fonction des informations. En fin de compte, c'est à vous de résoudre le problème global. Aussi vite, aussi bon et aussi bon marché que possible. Dans ce domaine, les points de fonction et Scrum ont un objectif commun.
Donc Scrum et FPA sont amis. La perte de contrôle et le dépassement du budget (commun) ennemi!

Victoires rapides

Gains rapides dans la combinaison Scrum et Function Points

1. Concrétisation plus rapide du Backlog Produit
   Le Product Backlog est la description de toutes les exigences non mises en œuvre qui doivent être faites. En haut du carnet de produits se trouvent les éléments les plus importants pour l'entreprise et seuls ces éléments sont élaborés en détail. La taille du Product Backlog peut être concrétisée en utilisant FPA. Spectacles FPA quoi la fonctionnalité est requise. FPA fournit ainsi un résumé du Backlog Produit en termes fonctionnels.
2. Objectif mesurable
   Un backlog produit détaillé pour les six premiers sprints suffit pour faire un FPA estimé (ISO / CEI 24570 Méthode de mesure de la taille fonctionnelle Nesma). Le nombre de points de fonction peut alors être extrapolé au total. Donc, le but ultime (la tache à l'horizon) peut être quantifié, et le résultat final est rendu tangible, sans avoir besoin de spécifications détaillées pour l'ensemble du produit.
3. Mesure plus facile de la «valeur ajoutée’
   La vitesse à laquelle une équipe fournit un logiciel est mesurée en points d'histoire. Ce sont des estimations relatives de la taille de l'œuvre. Ces points d'histoire ne doivent pas être confondus avec des points de fonction. Ils ne se ressemblent même pas (sauf de nom, bien sûr). Les points de fonction sont tournés vers l'extérieur et prennent en compte l'ensemble du projet. Les Story Points sont tournés vers l'intérieur et aident à empêcher une équipe Scrum de mordre plus qu'elle ne peut mâcher. Dans Scrum cependant, il est difficile d'exprimer la valeur livrée. pourtant, cela peut parfaitement être fait en termes de: Points de fonction!
4. Aide à la hiérarchisation des fonctionnalités
   Un aspect important de Scrum est de déterminer la fonctionnalité souhaitée avec la valeur commerciale la plus élevée, qui sera ensuite repris lors du prochain sprint. Avec le FPA estimé, la liste de souhaits totale – et à l'intérieur de ça, les prochains sprints – peut être mesuré de manière simple, également en ce qui concerne le regroupement des fonctionnalités. L'image globale est conservée et les changements sont traçables.
5. Aide à la réalisation d'estimations
   L'estimation est la tâche de l'équipe. Faire une estimation est toujours (et reste) une affaire délicate. Après tout, une équipe n'a pas de boule de cristal et avant de savoir, les estimations sont utilisées comme s'il s'agissait de garanties. Estimations Scrum avec points d'histoire, mais ce sont relativement: comparable à l'équipe mais pas au-delà. Points de fonction, pourtant, sont absolument et comparables. Les points de fonction sont comparables entre les projets et ne peuvent pas seulement être mesurés à l'avance, mais aussi pendant et après un projet. Donc, l'équipe reçoit une aide supplémentaire pour faire des estimations.
6. Détecter les améliorations
   Parce que FPA fournit une mesure objective, il peut être utilisé dans la rétrospective du processus Scrum pour montrer une amélioration. Vous pouvez ainsi aider les équipes à apprendre les unes des autres et à détecter les principaux facteurs inhibiteurs.
7. Confirmation de l'analyse de rentabilisation pour Scrum
   Alors que de nombreuses organisations sont enthousiasmées par Scrum, les roumeurs peuvent être entendues à travers la vigne que les processus Scrum incluent plus de retouches (en faisant progresser la perspicacité) ce qui les rendra plus chers. Le nombre de points de fonction de la fonctionnalité nouvelle et améliorée peut être déterminé et ainsi la productivité de l'adaptation et de l'ensemble du processus peut être établie. Ensuite, l'analyse de rentabilisation peut être déterminée objectivement.

Ce blog a été publié à l'origine comme un article d'opinion dans Guide d'automatisation (en néerlandais).

 

À propos des auteurs

Jolijn Onvlee (jolijn@onvlee.com) est un spécialiste et consultant indépendant FPA, auditeur et conférencier dans le domaine de la qualité, gestion du budget et de la productivité. Jolijn a également travaillé pendant de nombreuses années en tant que président et membre du conseil d'administration de Nesma.

Rini van Solingen est CTO chez Prowareness (rini@scrum.nl) et professeur à l'Université technique de Delft. Rini est l'auteur du livre “Le pouvoir de Scrum”; maintenant aussi publié en anglais, Allemand et anglais.