Interview de Mr Martínez, responsable du bureau de productivité d’Orange OSP (13/11/2019).
Qu’est-ce qui a motivé Orange à adopter les méthodes Agiles pour développer des logiciels ?
Je pense que la motivation a été la même que celle du reste des entreprises qui se sont lancées dans le monde agile : la nécessité de s’adapter à un marché de plus en plus numérisé, complexe et vertigineux. En raison des conditions changeantes de ces écosystèmes, il est plus avantageux de commencer par l’analyse ou le développement partiel de la solution et de procéder étape par étape, plutôt que de l’analyser ou de la développer d’un seul tenant.
C’est pour cette raison que les entreprises immergées dans des marchés très dynamiques et changeants choisissent d’adopter des méthodes agiles qui, contrairement aux méthodes traditionnelles, permettent des livraisons successives de valeur qui s’adaptent aux évolutions du marché et maximisent le rapport valeur commerciale/effort.
Le marché des télécommunications ne fait pas exception, c’est pourquoi Orange a choisi d’adopter ces méthodes. Pour Orange, les pratiques agiles représentent une évolution dans la manière dont nous développons nos projets, nous permettant de placer le client au centre, de mieux prioriser et de fournir les fonctionnalités les plus pertinentes dans des délais plus courts ; et, tout cela, en travaillant de manière organisée, collaborative, efficace et transparente avec une orientation claire vers la numérisation.
En ce sens, il convient de noter que les méthodes agiles ne s’appliquent pas seulement au domaine des systèmes d’information mais s’étendent également à l’ensemble de l’organisation. À mon avis, c’est une des raisons de leur succès.
Utiliser des méthodes agiles durant la phase de conception du projet permet d’affiner les exigences jusqu’à atteindre une définition de projet atomique et synthétique. Il contient alors les fonctionnalités qui apportent une réelle valeur ajoutée à l’entreprise.
Quels changements l’adoption de ce type de méthode a-t-elle apportés à Orange par rapport à d’autres plus classiques (en cascade) ?
Tout d’abord, nous avons changé notre état d’esprit. Nous avons dû vaincre cette résistance au changement qui survient lorsqu’on veut modifier une dynamique ancrée de longue date. Pour ce faire, Orange a invité les collaborateurs, via des formations spécifiques, à franchir cette barrière, à ouvrir leur esprit et à sortir de notre zone de confort.
Par la suite, des formations ont été dispensées sur ces méthodes avec différents niveaux d’intensité, allant de formations légères où les concepts de base ont été introduits de manière simple à des formations plus complètes, pleines de dynamique qui se sont même terminées par un accompagnement à la mise en œuvre de ces méthodes le jour même.
Enfin, je dois mentionner le groupe Orange Agile Coach, qui a apporté un soutien continu à la mise en œuvre de ces méthodes dans les différentes équipes, en les accompagnant lors des réunions et en résolvant les doutes qui se posaient.
Dans tous les cas, il est important de souligner que même si les méthodes sont claires, tous les outils ne sont pas utilisés de la même manière dans toutes les équipes ou activités. Pour résoudre ce problème et éviter la confusion que cela pourrait causer, nous nous sommes mis d’accord en interne sur des modèles de reporting nous permettant de connaître l’état des projets développés en agile et, surtout, qui facilitent la coordination des projets avec implémentation agile et Cascade. Tous ces accords et pratiques ont été intégrés dans un livre blanc qui sert de référence aux équipes actuelles et à venir.
Comment cela a-t-il affecté les relations avec vos éditeurs de logiciels ?
L’irruption des méthodes a nécessité d’ajuster les accords-cadres signés avec les prestataires pour qu’ils assurent la couverture nécessaire. Au fur et à mesure que la mise en œuvre agile progressait, nous avons revu et mis à jour les accords pour les adapter à la nouvelle dynamique.
Les nouveaux modèles de travail modifient le périmètre des responsabilités client-fournisseur et cela doit être pris en compte dans les accords-cadres entre les deux parties.
Peut-être que l’inclusion de ces méthodes dans les contrats-cadres nous oblige à quitter le cadre traditionnel de l’offre de services avec son coût et son SLA associés et à en adopter un complètement différent où nous avons tous les deux des objectifs et des responsabilités partagés. C’est quelque chose qui doit mûrir petit à petit.
En quoi consiste le projet de contrôle et d’amélioration de la productivité du développement logiciel ?
Nous avons adopté, et adapté, dans un premier temps, la méthode des Points de Fonction aux besoins d’Orange, en développant des guides de mesure adaptés à nos particularités.
Ensuite, nous définissons le modèle de productivité qui a été déployé dans les contrats avec nos fournisseurs il y a environ 10 ans. Grâce à ce modèle, nous pouvons dire que nous avons réussi à «payer par point de fonction» (le point de fonction est l’unité dans laquelle les développements sont mesurés avec la méthode IFPUG).
Ce modèle de productivité a été appliqué depuis lors et il a subi quelques évolutions. Nous appliquons également ce modèle d’estimation aux développements que nous faisons toujours en cascade.
Pourquoi devrions-nous continuer à mesurer la productivité dans les développements agiles ?
La question serait plutôt pourquoi pas. La productivité est un indicateur objectif qui nous permet de connaître le degré de performance avec lequel le développement logiciel est réalisé. Les méthodes agiles fournissent d’autres métriques quelque peu similaires à celle-ci, telles que la vitesse, mais ne sont pas comparables en dehors du domaine de l’équipe. C’est l’une des raisons pour lesquelles la mesure de la productivité est toujours très utile.
Lorsque nous nous sommes demandé comment mesurer la productivité des développements agiles, nous savions que nous devions profiter de notre expérience relative à l’estimation des projets développés en cascade pour mesurer l’activité développée en agile. Cela nous a permis de vérifier si les méthodes agiles, en plus d’apporter les avantages que nous avons précédemment mentionnés, étaient plus ou moins productives que les traditionnelles, un aspect non négligeable du point de vue de la durabilité économique.
À mon avis, l’utilisation du Story Point (unité dans laquelle les développements des méthodes agiles sont estimés) comme unité pour estimer les user stories dans la dynamique de chaque groupe est très positive, car elle offre la prévisibilité nécessaire pour s’adapter aux efforts de chaque sprinter. Mais la mesure de la productivité n’en est pas moins importante, car elle nous renseigne sur la performance réelle du groupe et nous permet de la comparer avec d’autres équipes, même si elles utilisent d’autres méthodes de développement. En conclusion, notre proposition est basée sur l’utilisation du Story Point en tant qu’unité d’estimation et du Point de Fonction en tant qu’ unité de mesure.
De toute évidence, mesurer les user stories n’a pas été facile car, dans le monde agile, il existe une réticence concernant l’utilisation de méthodes perçues comme moins adaptées. Tenant compte de cette problématique, nous avons défini une procédure avec pour directive claire qu’elle soit la moins intrusive possible dans les pratiques agiles, mais qu’elle nous permette de calculer notre indicateur avec un bon degré de qualité.