La performance
d’une équipe de développement
Comment la mesurer ? Sur quels axes ?

Version
abrégée
Daniel Cohen-Zardi
Jan...
La performance d’une équipe de développement

Sommaire
I. Introduction ......................................................
I

Introduction

3
La performance d’une équipe de développement

I. Introduction
La mesure de la performance d’une équipe de développement es...
La performance d’une équipe de développement

La clé d’une meilleure performance réside dans la façon dont l’équipe de
dév...
II

Alignement

6
La performance d’une équipe de développement

II. Alignement
L’alignement est probablement le facteur le plus important po...
La performance d’une équipe de développement

De plus, comme le coût de maintenance est intimement lié à la quantité de co...
III
Qualité

9
La performance d’une équipe de développement

III. Qualité
La qualité est un aspect critique des logiciels et mesurer la p...
La performance d’une équipe de développement

Dans ce livre blanc, nous nous concentrons sur la façon de mesurer la perfor...
La performance d’une équipe de développement

Performance
Nous sommes tous des utilisateurs de logiciels. Qui n’a jamais p...
La performance d’une équipe de développement

Scalabilité
On a tendance parfois à confondre performance et montée en charg...
La performance d’une équipe de développement

Exploitabilité
L’exploitabilité est la capacité d’une application à fonction...
La performance d’une équipe de développement

Ergonomie et facilité d’utilisation
L’ergonomie et la facilité d’utilisation...
IV

Productivité

16
La performance d’une équipe de développement

IV. Productivité
L’enjeu de la mesure
La productivité est évidemment un indi...
La performance d’une équipe de développement

Les méthodologies agiles
C’est sans aucun doute la tendance majeure du momen...
La performance d’une équipe de développement

Il convient de décrire de manière détaillée les différentes fonctionnalités ...
La performance d’une équipe de développement

Notre approche pour les logiciels d’entreprise
De notre point de vue, obteni...
V

Evolutivité

21
La performance d’une équipe de développement

V. Evolutivité
Le concept de la dette applicative
Derrière le terme d’évolut...
La performance d’une équipe de développement

L’effet de levier de la dette
Dans la mesure où votre application évolue, l’...
La performance d’une équipe de développement

C’est toute la puissance de l’effet de levier de la dette qui s’exprime à re...
VI

Prédictibilité

25
La performance d’une équipe de développement

VI.	 Prédictibilité
Lors des chapitres précédents, nous avons développé les ...
La performance d’une équipe de développement

Il est également fréquent, notamment lors de ruptures technologiques, de tro...
La performance d’une équipe de développement

Les calendriers prenant du retard, les responsables fonctionnels « chargent ...
VII

Créativité

29
La performance d’une équipe de développement

VII.	 Créativité
Ce sixième axe de mesure de la performance nous semble plus...
La performance d’une équipe de développement

Chez SoftFluent, nous pensons que dissocier totalement la conception d’un lo...
VIII
Conclusion

32
La performance d’une équipe de développement

VIII.	Conclusion
Chez SoftFluent, nous sommes des passionnés du développemen...
A propos de SoftFluent
SoftFluent est une société logicielle innovante créée en 2005 par d’anciens collaborateurs de Micro...
www.softfluent.fr

35

3 rue de la Renaissance
92160 Antony
01 75 60 04 45
Prochain SlideShare
Chargement dans…5
×

La performance d’une équipe de développement. Comment la mesurer ? Sur quels axes ?

7 612 vues

Publié le

Comment mesurer la performance d’une équipe de développement ?
Cette question est délicate. S’il est facile de mesurer la performance d’une entreprise ou de comparer les performances des ventes ou des services financiers, l’exercice qui consiste à mesurer la performance d’une équipe de développement reste un exercice complexe.
Il est assez facile de mesurer les coûts, mais comment mesurer la valeur réelle de ce qui est produit ? La valeur réelle correspond, la plupart du temps, à la transformation en termes de ventes et cela ne dépend pas seulement de l’équipe de recherche et développement.
De notre point de vue, il y a 5 piliers pour mesurer la performance d’une équipe de développement logiciel :
Alignement,
Productivité,
Qualité,
Capacité à minimiser la dette,
Prédictibilité.
Que vous découvrirez dans le livre blanc.

Publié dans : Technologie
  • Soyez le premier à commenter

La performance d’une équipe de développement. Comment la mesurer ? Sur quels axes ?

  1. 1. La performance d’une équipe de développement Comment la mesurer ? Sur quels axes ? Version abrégée Daniel Cohen-Zardi Janvier 2014 1
  2. 2. La performance d’une équipe de développement Sommaire I. Introduction ....................................................................................................................................... 4 II. Alignement ........................................................................................................................................ 7 III. Qualité ............................................................................................................................................. 10 Fiabilité........................................................................................................................................ 11 Performance ............................................................................................................................... 12 Scalabilité ................................................................................................................................... 13 Exploitabilité ............................................................................................................................... 14 Ergonomie et facilité d’utilisation ................................................................................................ 15 IV. Productivité .................................................................................................................................... 17 L’enjeu de la mesure .................................................................................................................. 17 Les méthodologies agiles ........................................................................................................... 18 La méthode des points de fonction ............................................................................................ 18 Notre approche pour les logiciels d’entreprise ........................................................................... 20 V. Evolutivité ........................................................................................................................................ 22 Le concept de la dette applicative .............................................................................................. 22 L’effet de levier de la dette .......................................................................................................... 23 VI. Prédictibilité .................................................................................................................................... 26 VII. Créativité ....................................................................................................................................... 29 VIII. Conclusion ................................................................................................................................... 32 Si vous êtes intéressé par le sujet, il est possible d’acquérir une version intégrale et imprimée du livre blanc. Les chapitres y sont plus détaillés, le modèle de dette est expliqué avec les exemples des règles de calcul. Suivez le lien http://www.softfluent.com/store/livre-blanc-performance. 2
  3. 3. I Introduction 3
  4. 4. La performance d’une équipe de développement I. Introduction La mesure de la performance d’une équipe de développement est un exercice délicat. Sur quels axes peut-on comparer le travail de différentes équipes ? Comment mesurer le résultat associé sur ces axes ? S’il est facile de mesurer la performance d’une entreprise ou de comparer les performances des ventes ou des services financiers en utilisant des ratios du métier, l’exercice qui consiste à mesurer la performance d’une équipe de développement reste complexe. C’est d’autant plus vrai lorsque ces équipes doivent créer des produits commerciaux et innover, par exemple dans le cas des éditeurs de logiciels. Une mesure universelle est souvent impossible à déterminer. En particulier, il est assez facile de mesurer les coûts, mais comment mesurer la valeur réelle de ce qui est produit ? La valeur réelle est, la plupart du temps, ce qui va être transformé en termes de ventes et cela ne dépend pas seulement de l’équipe de recherche et développement. En outre, en mettant en avant l’information pertinente de la bonne façon, les applications logicielles peuvent apporter une valeur additionnelle dans l’aide aux décisions stratégiques, valeur qu’il est bien difficile de quantifier. Mesurer la performance intrinsèque d’une équipe technique n’est donc pas simple car celle-ci peut contribuer de manière plus ou moins forte par ses idées. Pour les applications d’entreprise, cela peut sembler plus facile dans la mesure où la valeur réside principalement dans le soutien des processus du métier. Mais si l’on creuse un peu, il apparait rapidement que la compréhension, la gestion et l’évolution de ces processus est une responsabilité qui s’étend à des départements bien au-delà de l’équipe technique. 4
  5. 5. La performance d’une équipe de développement La clé d’une meilleure performance réside dans la façon dont l’équipe de développement contribue à améliorer l’efficacité de l’entreprise. Et cela nécessite une réelle collaboration entre l’équipe de développement et les autres départements. De notre point de vue, nous identifions 6 axes d’évaluation de la performance d’une équipe de développement logiciel : alignement, qualité, productivité, évolutivité, prédictibilité et créativité. Alignement Créativité Qualité Productivité Prédictibilité Évolutivité Hormis la créativité, dimension quelque peu particulière qui peut s’avérer contreproductive si les 5 autres axes ne sont pas maitrisés, ces dimensions revêtent toutes une importance significative dans l’évaluation de la performance d’une équipe de développement à long terme. 5
  6. 6. II Alignement 6
  7. 7. La performance d’une équipe de développement II. Alignement L’alignement est probablement le facteur le plus important pour la performance du fait de son effet de levier considérable, effet qui peut créer une différenciation significative entre les équipes. Beaucoup mesurent la productivité - ou pire simplement les coûts - mais cela n’a pas de sens si personne ne vérifie réellement comment l’effort de développement est aligné à la valeur apportée pour le gain d’affaires. Sur le schéma ci-après l’équipe N°3 produit moins que les autres en quantité, car la flèche est plus courte. Pourtant cette équipe sera à même de fournir plus de valeur à son entreprise dans la mesure où son effort est plus aligné avec les besoins du métier. La projection sur l’axe de valeur est, au final, la plus élevée des 3 équipes. Fonctions superflues ou inutilisées Équipe Logicielle 1 Équipe Logicielle 2 Équipe Logicielle 3 Création de valeur pour le métier de la société 7
  8. 8. La performance d’une équipe de développement De plus, comme le coût de maintenance est intimement lié à la quantité de code produit, le bénéfice d’une bonne focalisation sur la valeur augmentera encore au fil du temps, alors que les équipes 1 et 2 auront à maintenir du code sans valeur ajoutée et à supporter une dette applicative plus lourde. Nous y reviendrons plus loin. Bien sûr, cet alignement est particulièrement difficile à mesurer. Comment peut-on vraiment déceler un effort non productif sur un projet ? Notre expérience d’audit des applications et des logiciels démontre que les équipes de développement surinvestissent souvent sur des frameworks et des approches techniques qui sont trop coûteux comparés à la valeur qu’ils apportent à l’entreprise. Nous détectons souvent du code inutilisé, des fonctions qui existent déjà dans les classes standards et de la sur-ingénierie qui n’apporte pas de réelle valeur dans le contexte de l’application. Selon nous, c’est uniquement avec la contribution des ingénieurs logiciels que vous pouvez faire une réelle différence à long terme sur le marché, dans la mesure où ils sont capables de faire les choix critiques qui impacteront les coûts de développement à grande échelle. Seul un processus de collaboration durable et convivial entre les personnes qui maîtrisent la technologie et celles qui maîtrisent les besoins peut aboutir à des solutions innovantes qui ont du succès. C’est la principale raison qui fait que les méthodes agiles sont devenues si populaires. Au-delà d’assurer l’alignement comme partie intégrante de votre méthodologie, il existe aussi des façons d’évaluer votre niveau d’alignement actuel à l’aide d’un audit externe par exemple. Cela peut vous aider à découvrir des zones de code qui peuvent être simplifiées ou recentrées sur votre métier. 8
  9. 9. III Qualité 9
  10. 10. La performance d’une équipe de développement III. Qualité La qualité est un aspect critique des logiciels et mesurer la performance de votre équipe de développement au travers de ce critère est fondamental. La qualité comporte pour nous 5 dimensions comme indiqué dans le schéma suivant : Fiabilité Ergonomie et facilité d’utilisation Performance Exploitabilité Montée en charge La qualité est évidemment un sujet en soi avec ses propres défis d’organisation et de meilleures pratiques. On pourrait écrire un livre blanc sur ce seul sujet et nous avons d’ailleurs écrit un article long et très consulté sur notre blog « Les meilleures pratiques du test logiciel1 ». URL1 : http://blog.softfluent.com/2009/03/02/software-testing-best-practices/ 10
  11. 11. La performance d’une équipe de développement Dans ce livre blanc, nous nous concentrons sur la façon de mesurer la performance de votre équipe de développement sur cet aspect particulier du développement logiciel qu’est la qualité. Fiabilité Mesurer la fiabilité d’une application peut s’avérer relativement simple même si les comparaisons ne sont pas toujours faciles ; cette information étant la plupart du temps confidentielle au sein des entreprises. Fondamentalement, le meilleur indicateur est le nombre de bogues ouverts et son évolution au fil du temps. Evidemment moins il y a de bogues, mieux c’est. Mais attention, le « zéro bogue » peut être aussi le signe d’une insuffisance des tests ou d’une non utilisation de l’application, à moins que vous n’atteignez ce résultat sur le long terme. Et cela peut signifier également dans ce cas qu’il y a peu d’évolutions. Tout d’abord, il est important de ne pas mélanger bogues et décalages fonctionnels. Notre expérience du terrain montre que beaucoup de remontées des utilisateurs lors de phases de recette sont des problèmes d’alignement avec l’attente. Il faut donc bien séparer ces points avant d’évoquer l’aspect de fiabilité. Pour la fiabilité elle-même, ce qu’il faut surveiller au fil du temps lorsque vous livrez un logiciel : • La tendance du nombre de bogues : elle peut être élevée au moment où de nouvelles fonctionnalités sont livrées et doit se réduire régulièrement ensuite, • La répartition de l’importance des bogues : critique, majeure or mineure, • La cohérence du ratio bogue/ligne de code quand vous livrez un nouveau logiciel. Un indicateur important que nous allons aborder à propos du support est le temps nécessaire pour corriger un bogue. Si ce temps est élevé par rapport au nombre de bogues, c’est le signe d’une mauvaise conception et cela aura probablement un impact sur la fiabilité. 11
  12. 12. La performance d’une équipe de développement Performance Nous sommes tous des utilisateurs de logiciels. Qui n’a jamais pesté contre une application lente ou un site web qui ne répond pas ? C’est évident lorsque nous sommes du côté utilisateur, mais certains développeurs ont tendance à minimiser l’importance d’une interface utilisateur réactive. Au final, et quelle que soit la raison technique sous-jacente ou la complétude du logiciel en fonctionnalités, les utilisateurs n’utiliseront jamais une application trop lente. Par conséquent, lorsque vous codez, vous devez opter pour les options techniques qui procurent une bonne performance pour les utilisateurs. Ne nous méprenons pas, notre propos n’est pas de dire de se focaliser uniquement sur ce point et de tout écrire en langage assembleur. Cependant, il est vital d’optimiser les composants qui ont un fort impact sur la performance : les connexions à distance, l’accès aux données, la réduction appropriée des jeux de données manipulés, la parcimonie dans l’utilisation des boucles, notamment imbriquées. 12
  13. 13. La performance d’une équipe de développement Scalabilité On a tendance parfois à confondre performance et montée en charge (ou scalabilité). Ce sont deux sujets différents qui requièrent parfois des options de conception contradictoires. La scalabilité est la capacité de votre application à croître sans limite, à la fois en nombre d’utilisateurs pris en charge qu’en volume de données. Par exemple Microsoft Access est un SGBD très performant mais peu scalable en nombre d’utilisateurs, c’est un choix de conception. Avec l’émergence d’internet, et donc des applications SaaS et Cloud, la scalabilité revêt désormais une importance supérieure à la pure performance. C’est la plupart du temps un défi technique que d’avoir à gérer un nombre énorme d’utilisateurs partageant les mêmes données. Mesurer la scalabilité de votre application est un processus relativement coûteux. Cela requiert la mise en place de plateformes complètes dédiées au processus d’évaluation de votre application en fonction de la charge d’utilisateurs et de données. Cela requiert également les outils et compétences appropriés pour interpréter correctement les mesures et être capable d’évaluer les éléments dont vous avez besoin en fonction de la croissance de votre base d’utilisateurs. Ce processus est connu sous le nom de planification de la capacité (capacity planning en anglais). Le manque de scalabilité peut être la cause de problèmes commerciaux majeurs. Si l’application ne peut pas accueillir de nouveaux utilisateurs et qu’elle n’a pas été conçue pour, il n’y a en général pas de solution à court terme. 13
  14. 14. La performance d’une équipe de développement Exploitabilité L’exploitabilité est la capacité d’une application à fonctionner en production et à être rapidement corrigée en cas de défaillance. La bonne gestion des erreurs et exceptions est un élément clé. Nous avons illustré cela sur notre blog dans l’article « Les bonnes pratiques d’instrumentation de code1 ». Une application conçue pour l’exploitation doit être capable de faire face à certains événements impromptus comme les pannes de réseaux, la bande passante ou les problèmes matériels. Pour mesurer les résultats sur cette dimension, nous recommandons de mesurer le temps moyen de correction d’un bogue : • Trouver ce qui s’est produit, • Trouver la ligne de code concernée, • Être capable d’isoler les données utilisées dans le scénario qui cause l’erreur, • Identifier le scenario non prévu initialement, • Proposer une correction compatible avec le code existant. URL1 : http://blog.softfluent.fr/2012/09/03/instrumentation-du-code-les-bonnes-pratiques/ 14
  15. 15. La performance d’une équipe de développement Ergonomie et facilité d’utilisation L’ergonomie et la facilité d’utilisation constituent également un pilier majeur de la qualité. Mesurer et effectuer des comparaisons n’est pourtant pas si simple. On a tendance soit à sous-estimer l’importance de l’ergonomie soit, au contraire, à attendre de toutes les applications la même facilité d’utilisation que les sites web grand public majeurs, alors que ceux-ci sont développés avec des dizaines de millions de dollars dont on ne dispose pas forcément. Le meilleur indicateur est la capacité des utilisateurs à apprendre et à utiliser l’application rapidement. Si possible, nous recommandons de mesurer cet aspect avec de nouveaux utilisateurs. Combien de temps leur faut-il pour se familiariser avec l’application ? S’il faut du temps, quelle est la part de la complexité intrinsèque et quelle est la part liée à l’ergonomie et à la conception ? Du point de vue ergonomique, il est souvent préférable de privilégier les nouveaux utilisateurs plutôt que des utilisateurs qui auraient pu être habitués à d’autres systèmes, car leur jugement est souvent biaisé par l’historique et les réticences au changement. Bien traiter cet aspect permet potentiellement des coûts de formation réduits, une amélioration de la productivité des utilisateurs et une facilité d’acceptation de l’application. Exactement comme pour la performance, le risque en cas d’échec sur cette dimension est le refus de l’application par les utilisateurs et des coûts cachés. Nous ne l’avons pas mentionné en tant que dimension de la qualité, mais la bonne documentation de l’application est un élément qui peut être clé dans son adoption et que nous considérons comme un élément de la facilité d’utilisation. En conclusion, lorsque vous mesurez la qualité de votre développement logiciel, n’oubliez pas d’évaluer ces 5 dimensions qui contribuent toutes à faire de votre logiciel un succès. 15
  16. 16. IV Productivité 16
  17. 17. La performance d’une équipe de développement IV. Productivité L’enjeu de la mesure La productivité est évidemment un indicateur de performance critique dans tous les métiers. Mais dans la mesure où les développeurs de logiciels sont des ressources rares et coûteuses, la mesurer précisément s’avère d’autant plus important dans ce domaine. Pourtant, et bien que le développement logiciel ne soit pas une nouvelle discipline, il n’existe pas de méthodologie universellement reconnue pour mesurer la productivité d’une équipe de développement. Pourquoi en est-il ainsi ? Premièrement, et par définition, chaque développement logiciel est unique. Contrairement à un bien physique qu’il faut fabriquer en autant d’exemplaires que d’utilisateurs, un logiciel se reproduit à l’infini par copie immatérielle. Un logiciel n’est donc réalisé qu’une seule fois et la comparaison formelle et rigoureuse de production de deux logiciels distincts est impossible car ils ne sont jamais identiques. Deuxièmement, le rythme de l’évolution technologique est particulièrement rapide. Par conséquent, chaque fois qu’une méthodologie relative à une certaine vague technologique est suffisamment éprouvée, elle s’avère en même temps partiellement obsolète. Troisièmement, la part de créativité dans la recherche de solutions à un problème donné est souvent importante. Il est donc difficile d’avoir un repère unique. Certaines approches simples, comme la mesure du résultat en termes de « lignes de code » par exemple, permettent de mesurer la taille de la solution, mais finalement pas la taille du problème. 17
  18. 18. La performance d’une équipe de développement Les méthodologies agiles C’est sans aucun doute la tendance majeure du moment dans les méthodes de développement logiciel. La mise en avant des méthodologies agiles est souvent liée à la sécurisation d’un processus collaboratif entre la gestion du produit et les développeurs. En ce sens, cette approche relève assez bien le défi d’alignement dont nous avons parlé précédemment. Mais comment traitent-elles de la productivité ? Sur ce sujet, la pratique courante est d’évaluer la tâche de développement en utilisant des niveaux de complexité et des « points ». En fonction du niveau de complexité, une formule non-linéaire donnant le temps de développement. La méthode des points de fonction L’analyse des points de fonction est une méthode d’évaluation qui relève le défi en définissant de manière « absolue » ce qui doit être produit en termes de complexité. Interfaces externes Requêtes externes Navigation Internet Comparateurs de prix Site marchand Fichiers internes Stocks produit Entrées externes 18 Sorties externes Catalogues fournisseurs Commandes prises
  19. 19. La performance d’une équipe de développement Il convient de décrire de manière détaillée les différentes fonctionnalités du logiciel dans chaque domaine. Pour en savoir plus, nous recommandons les documents1 de Software Metrics, une société spécialisée dans ce domaine. Sur le terrain, cette approche se révèle finalement peu utilisée. URL1 : http://fr.wikipedia.org/wiki/Suite_de_Fibonacci 19
  20. 20. La performance d’une équipe de développement Notre approche pour les logiciels d’entreprise De notre point de vue, obtenir une mesure « absolue » du logiciel produit par votre équipe pour un budget donné demeure un sujet important. En mesurant les défis mentionnés ci-dessus, nous avons ajusté notre méthodologie à la taille d’un projet de développement logiciel, en particulier dans le domaine des « applications métier », à l’aide de critères simplifiés. Si vous combinez plusieurs facteurs de complexité, vous pouvez également trouver des ratios qui vous aident à faire face à cette complexité et vous devriez dans tous les cas être en mesure d’évaluer un projet sur la base des éléments suivants : • Nombre d’entités métier (concept proche de celui de Classe en objet ou encore de Table en base de données), • Nombre de règles métier simples (au sein d’une entité), • Nombre de règles métier avancées (combinant plusieurs entités par exemple), • Nombre d’éléments pour l’interface utilisateur (écrans, pages web), • Nombre de rapports (ou états), • Nombre d’interfaces externes (vers un autre système), • Nombre de calculs ou processus de traitements par lots, • Nombre de variations technologiques de chaque composant (différentes technologies de client-riche, de page web, de version mobile, de système de gestion de base de données, utilisation d’un stockage de type Cloud). Dans les projets qui utilisent notre fabrique logicielle CodeFluent Entities2, nous avons souvent constaté qu’un projet, en intégrant les dimensions non techniques et le pilotage du projet, devrait coûter : • de 2 000 à 4 000 Euros par entité si c’est une application entreprise, • de 4 000 à 6 000 Euros par entité si c’est un produit packagé qui doit être déployé à des clients variés, comme un produit d’éditeur, dans la mesure où réaliser un produit configurable est généralement plus complexe qu’une application à déploiement unique. Ces chiffres sont simplifiés car il faut les affiner en fonction des critères mentionnés précédemment, mais cela donne cependant un moyen très simple de détecter d’éventuels problèmes de productivité lors d’audit de projets en condition réelle avec un peu d’historique et d’héritage. URL2 : http://www.softfluent.com/products/codefluent-entities 20
  21. 21. V Evolutivité 21
  22. 22. La performance d’une équipe de développement V. Evolutivité Le concept de la dette applicative Derrière le terme d’évolutivité, nous trouvons en particulier la capacité à minimiser la dette embarquée dans vos applications. Effectivement, plus vous minimiserez celle-ci, plus vous pourrez évoluer rapidement et avec des contraintes minimales. La dette applicative est une notion qui devient de plus en plus populaire auprès des analystes. L’institut Gartner estime la dette informatique1 à 1,000 milliards de $ à horizon 2015. L’expérience montre que les applications durent toujours plus longtemps que prévu à leur conception. Même lorsque vous pensez qu’il s’agit d’une solution temporaire, un changement d’orientation ou des restrictions budgétaires peuvent impacter le calendrier de la nouvelle version. Dans tout projet logiciel, des problèmes apparaissent au fil du temps et les retards de livraison sont la règle dans ce domaine, sans parler des échecs complets de certains projets, en particulier dans le cas d’une rupture technologique. Par conséquent, livrer une application qui fonctionnera avec un effort de maintenance minimal tout en pouvant suivre l’évolution technologique est en fait l’un des éléments les plus importants pour mesurer la performance d’une équipe de développement logiciel. La dette applicative est généralement difficile à mesurer dans la mesure où la majorité des coûts cachés ne sont pas dans la maintenance corrective pure. Bien sûr, quand une application est vraiment boguée les gens prennent conscience du problème et réagissent. Mais dans la plupart des cas une partie non négligeable de la dette réelle se cache dans une mauvaise conception, qui se traduit par une évolution accrue des coûts de maintenance, le problème grandissant au fil du temps jusqu’à devenir démesuré. Si votre évolution des coûts ressemble à la courbe ‘non industrielle’ ci-après, il est temps de penser à une réelle modernisation de votre application. URL1 : http://www.gartner.com/id=1419325 22
  23. 23. La performance d’une équipe de développement L’effet de levier de la dette Dans la mesure où votre application évolue, l’héritage que vous avez développé grossit en maintenance et une sur-complexité impacte l’évolution des coûts. Nous simulons les coûts pour 4 équipes fictives dont les scénarios relativement réalistes seraient les suivants : • • • • Equipe 1 : 10% de facteur de sur-complexité, Equipe 2 : 20% de facteur de sur-complexité, Equipe 3 : 30% de facteur de sur-complexité, Equipe 4 : 30% de facteur de sur-complexité ramené progressivement à 0% dans le temps. En année 10, un nouveau projet de poids 70 s’avère nécessaire et l’organisation dispose d’un budget de 170… 23
  24. 24. La performance d’une équipe de développement C’est toute la puissance de l’effet de levier de la dette qui s’exprime à retardement. Le modèle de dette expliqué avec les exemples des règles de calcul est disponible dans la version intégrale du livre blanc disponible ici http://www.softfluent.com/store/livre-blanc-performance Par ailleurs, nous observons sur le terrain une méconnaissance de métriques simples comme le nombre d’entités du métier ou tables, le nombre d’écrans ou pages, le nombre de rapports et une incapacité à croiser ces éléments avec le nombre de lignes de code produites. Une chose est sûre, il faut être en mesure d’évaluer le coût sur la base de d’éléments factuels ou, encore mieux, avec des détails comme les règles métier, les propriétés des données, les champs de l’interface utilisateur. C’est nécessaire à la fois pour la production du logiciel mais aussi pour évaluer les coûts de maintenance et de mise en œuvre des évolutions à venir. Si le seul critère que vous avez pour évaluer l’impact d’une demande de fonctionnalité est le temps estimé par vos développeurs, vous serez en difficulté dans la mesure où vous n’aurez aucun moyen de vérifier l’information. Et l’expérience du terrain montre un degré très élevé de variabilité entre les compétences des développeurs. Cela induit un risque important si votre seul critère est de faire confiance aux développeurs sans un minimum de moyens de contrôle. 24
  25. 25. VI Prédictibilité 25
  26. 26. La performance d’une équipe de développement VI. Prédictibilité Lors des chapitres précédents, nous avons développé les quatre premiers axes de performance des équipes de développement. Le cinquième élément important à prendre en compte pour évaluer la performance d’une équipe de développement est le caractère prévisible des résultats obtenus. Selon diverses études évoquées notamment par l’AFDEL dans le livre blanc sur la conduite de l’innovation, 58% des logiciels achetés ne sont jamais mis en production, seulement 13% des projets informatiques sont livrés dans les délais et 30% des projets sont purement et simplement arrêtés. C’est dire l’enjeu qui demeure encore sur cet axe pour piloter et prévoir les projets logiciels. Néanmoins, la finalité de toute équipe de développement est d’ obtenir des résultats, que ceux-ci soient des prototypes de recherche, des logiciels devant être commercialisés ou des applications à usage interne. Dans l’univers des applications de gestion, et dans l’état de l’art actuel, il nous semble faisable d’obtenir des résultats réguliers, dans des délais et pour des coûts que l’on peut évaluer à l’aide de critères macroscopiques relativement simples et limités. Enfin, notons que pour les éditeurs, il est souvent nécessaire de faire émerger de nouveaux produits, pour se différencier de la concurrence et conserver une place sur le marché. Nous y reviendrons en parlant de la dimension supplémentaire de la créativité, spécifiquement pour les équipes des éditeurs avec un département de Recherche et Développement. De notre expérience, beaucoup d’échecs sont dus à un décalage entre le résultat attendu et ce qui est produit. Ce décalage est souvent issu d’une rupture voulue entre conception et développement. L’off-shore est un des facteurs qui a contribué à renforcer cet état de fait. Nous avons d’ailleurs publié sur notre blog cet article au titre un peu provocateur Le mythe du mois-homme indien, afin de rappeler que la mesure d’un projet en jour-homme est une aberration dénoncée depuis 1975. On semble avoir oublié ce point dans un mouvement prononcé vers l’off-shore lors de la décennie passée, mouvement axé principalement sur le coût du jour-homme. URL1 : http://blog.softfluent.fr/2013/01/07/le-mythe-du-mois-homme-indien/ 26
  27. 27. La performance d’une équipe de développement Il est également fréquent, notamment lors de ruptures technologiques, de trouver des équipes qui perdent la maîtrise du calendrier. Des projets de R&D peuvent prendre plusieurs mois voire des années de retard, avec des budgets qui gonflent dans les mêmes proportions et des déficits colossaux. Dans l’univers des applications de gestion, et dans l’état de l’art actuel, il nous semble faisable d’obtenir des résultats réguliers, dans des délais et pour des coûts que l’on peut évaluer à l’aide de critères macroscopiques relativement simples et limités. Pour des éditeurs de logiciels, il faut aussi pouvoir formaliser une feuille de route (roadmap) et sortir des versions régulièrement. Même s’il est notoire que ces feuilles de route sont rarement respectées, des décalages trop importants peuvent mener à la catastrophe, car les prévisions financières y sont souvent liées. Voici un exemple de feuille de route de Microsoft Visual Studio sur les années passées : 2006 & Avant 2007 2008 2009 2010 & Au-delà Visual Studio .NET Visual Studio .NET 2003 Visual Studio .NET 2005 Visual Studio 2008 Team Foundation Server 2005 Team Foundation Server 2008 Visual Studio 2008 SP1 Team Foundation Server 2008 SP1 Visual Studio Rosario Update Visual Studio 10 Team Foundation Server Rosario Team Foundation Server 10 Par ailleurs, à un niveau plus fin, les méthodes agiles constituent aussi un rempart intéressant en matière de prédictibilité car elles évitent cet effet tunnel en maintenant un alignement entre les détenteurs de la vision du produit et les équipes de réalisation, mais elles ne dispensent pas d’établir par ailleurs une vision macroscopique. Pour conclure, notons que l’enjeu de la prédictibilité est plus fort qu’il n’y parait, car, au-delà des conséquences financières directes d’un retard, lorsque la perte de confiance s’installe, la dynamique devient rapidement un cercle vicieux. 27
  28. 28. La performance d’une équipe de développement Les calendriers prenant du retard, les responsables fonctionnels « chargent la barque » car ils savent qu’ils attendront longtemps des fonctionnalités reportées à une version ultérieure. Ce faisant, ils accentuent les difficultés et exposent le projet à des risques d’échec majeurs. 28
  29. 29. VII Créativité 29
  30. 30. La performance d’une équipe de développement VII. Créativité Ce sixième axe de mesure de la performance nous semble plus particulier, et concerne plutôt les éditeurs de logiciels. En effet, il est potentiellement à double tranchant. Si les axes précédents ne sont pas maîtrisés, et que le niveau de prédictibilité n’est pas suffisant par rapport aux besoins des utilisateurs ou du marché, il vaut mieux éviter d’avoir une équipe trop créative, qui pourrait constituer un facteur de dispersion. En revanche, lorsqu’une équipe technique de bon niveau a été constituée, particulièrement avec des offres de produit pour un marché donné, la créativité peut être un levier extrêmement puissant. En effet, au-delà des études de marché théoriques et des analyses faites par les profils marketing et commerciaux, ou de ce que peuvent réellement anticiper les clients, certains produits innovants émergent avant tout d’équipes techniques expertes d’un marché. Marché cible Développeur Technologies Par leur connaissance intime des enjeux d’un marché cible et la combinaison de ce savoir avec une compréhension des grandes innovations technologiques, ce sont souvent ces équipes qui sont à même de concevoir une approche nouvelle et un produit de rupture. 30
  31. 31. La performance d’une équipe de développement Chez SoftFluent, nous pensons que dissocier totalement la conception d’un logiciel de sa réalisation est souvent une ineptie. Bien sûr, il faut du recul pour en concevoir les grands lignes et ce n’est pas toujours le travail du développeur d’identifier les scénarios clients macroscopiques ou de détailler les besoins du marché considéré. Néanmoins, le développeur et les équipes techniques disposent quasiment toujours d’une grande capacité à définir des options de conception qui vont avoir un coefficient valeur/coût optimal pour une fonctionnalité donnée. Si on ajoute la dimension psychologique, l’impact est encore démultiplié. Le développeur à qui on retire la conception perd l’intérêt de son travail. Or, il s’agit d’un travail intellectuel et les résultats peuvent donc différer d’un ordre de grandeur (au moins de 1 à 10) pour le même temps investi. En niant ce point et en positionnant le développeur comme un « pisseur de code », on ne pourra garder que des développeurs de faible niveau et le cercle vicieux sera enclenché. Pour un éditeur de logiciels, réussir à développer ce sixième axe, lorsque les cinq précédents sont bien maîtrisés, est un moyen de voir émerger des idées de produits totalement innovants, qui peuvent parfois à eux seuls définir un nouveau marché. Il nous semble important de terminer sur ce point, tant celui-ci ne peut être abordé que par une compréhension de l’intérêt de disposer d’équipes techniques de grande valeur et d’expérience éprouvée. 31
  32. 32. VIII Conclusion 32
  33. 33. La performance d’une équipe de développement VIII. Conclusion Chez SoftFluent, nous sommes des passionnés du développement et pensons que le logiciel est un formidable levier du succès des sociétés sur leurs différents marchés. Cependant, nous pensons que ce métier est encore jeune, car le logiciel n’existe que depuis quelques décennies, et il s’avère souvent insuffisamment cadré dans sa mise en œuvre sur le terrain. L’objectif de ce livre blanc est avant tout de vous faire partager l’état actuel de notre réflexion sur le sujet, tout en sachant qu’elle n’est que partielle et imparfaite, et que ce métier nécessite sans cesse des améliorations et une remise en cause permanente. Pour autant, nous espérons qu’il contient déjà un certain nombre d’éléments fondamentaux qui peuvent permettre à tout responsable pilotant des équipes de développement de positionner son organisation sur différents axes et de définir ses priorités d’amélioration. Au travers de la plateforme de blogs de notre société (blogs.softfluent.com), nous continuons de partager nos réflexions et restons preneurs d’échanges sur vos propres expériences. Si vous êtes intéressé par le sujet, il est possible d’acquérir une version intégrale et imprimée du livre blanc. Les chapitres y sont plus détaillés, le modèle de dette est expliqué avec les exemples des règles de calcul. Suivez le lien http://www.softfluent.com/store/livre-blanc-performance. 33
  34. 34. A propos de SoftFluent SoftFluent est une société logicielle innovante créée en 2005 par d’anciens collaborateurs de Microsoft Consulting Services, cumulant des interventions sur plus de 600 projets .NET dans des environnements très divers. SoftFluent partage son expérience du développement au travers de publications : livres blancs et blog des meilleures pratiques (http://blog.softfluent.fr). Les 2 cofondateurs sont aussi membres fondateurs du mouvement associatif « Fier d’être développeur ». SoftFluent est la seule société du marché français à proposer une triple offre d’accompagnement : Accompagnement • • • • • Développement spécifique (Web, Métier, SharePoint, Office, Azure...) Audit (Organisation/Code/Performances) Conseil et expertise (architecture, prototypage technologique) Modernisation d’applications (migration, refonte, évolution) Aide à l’industrialisation Training Formation • En ligne 24h/24 • Présentielle (inter et intra) • Combinaison optimale possible entre les deux • Plans de formation personnalisés • Bilans pédagogiques 34 Software Outils CodeFluent Entities pour : • Bâtir votre application sur des fondations solides • Vous concentrer sur le fonctionnel • Contrôler la production de code • Maîtriser les technologies Microsoft • Evoluer de manière prédictible
  35. 35. www.softfluent.fr 35 3 rue de la Renaissance 92160 Antony 01 75 60 04 45

×