Nouveaux cours – 12 décembre 2012
décembre 12, 2012 Poster un commentaire
Voici les nouveaux cours parus dans la bibliothèque Pluralsight cette semaine
Instrumentation du code : les bonnes pratiques
septembre 3, 2012 Poster un commentaire
La plupart des développeurs néglige les aspects d’exploitation du logiciel qu’ils développent. Un programme est toujours écrit pour fonctionner en production – heureusement – et écrire du code permettant une bonne exploitation requiert quelques bonnes pratiques étayées par l’expérience.
Sans entrer dans des sujets avancés comme la programmation orienté "aspects", nous pensons qu’il existe des dimensions de base de l’instrumentation du code que tout développeur logiciel devrait connaître.
Traces et débogage
Le premier élément critique de l’instrumentation est la gestion des traces. Ajouter des traces à votre code est toujours une bonne idée. Cela peut parfois avoir un impact sur les performances mais cela se gère facilement en ajoutant différents niveaux de traçabilité, configurables au moment de l’exécution.
Trop de développeurs continuent à favoriser le débogage à la traçabilité faisant disparaître leur investissement dès l’instant où ils referment leur déboguer. Nous recommandons la lecture d’un de nos précédents articles en anglais "Our case against debugging" que nous déclinerons bientôt en français. Bien utilisées, les traces sont un investissement plus durable et vous permettent de tirer parti de l’information pour comprendre et résoudre les problèmes en production. Souvent, les problèmes arrivent avec des combinaisons non-anticipées de chemins de code ou de données, de sorte que le développeur ne peut pas faire trop de raccourcis ou hypothèses en développant. Le débogage ne sera alors pas bien utile.
En outre au fil du temps, des développeurs différents peuvent contribuer à l’application, et les traces ajoutées au code sont conservées et préservent l’investissement de chaque contributeur.
La gestion des exceptions
Le traitement des exceptions est le deuxième point important de l’instrumentation du code. Quand une exception survient, il se peut que vous soyez dans un scénario imprévu, ou au minimum, dans des conditions spécifiques qui nécessitent de l’attention.
Traiter correctement les exceptions en prenant des actions pertinentes pour maintenir l’intégrité, pour fournir des informations sur les valeurs de données ou sur la manière de les obtenir peut être critique pour pouvoir effectuer le support de l’application en production.
Avec .NET, nous voyons beaucoup de mauvaises pratiques autour de la gestion des exception, comme celles-ci :
Le seul résultat de ce code est de perdre la trace de l’information. Ne rien faire serait effectivement mieux qu’intercepter l’exception et réduire l’information disponible. Si vous décidez de gérer une exception, assurez-vous de pouvoir ajouter de l’information et de la valeur au cas spécifique que vous interceptez.
Enfin, si vous souhaitez que la pile complète d’information soit disponible en production (avec la source et le numéro de ligne du fichier), c’est également une bonne idée de déployer les fichiers symboles (.PDB) notamment pour le déploiement d’application orientée serveur (web) ce qui n’est pas toujours fait.
Mesure de la performance
Dans Windows, il existe un moyen très simple de fournir de l’information utile sur la performance au moment de la production.
Les compteurs de performance sont directement intégrés dans le système d’exploitation (c’est en fait le cas depuis la toute première version de Windows NT) et vous pouvez créer vos propres compteurs pour surveiller les informations pertinentes avec tous les outils associés à Windows (Observateur d’événements). Du point de vue du développeur, les compteurs sont également faciles à définir ainsi que les classes associées.
De notre expérience, ces compteurs sont rarement utilisés par les développeurs d’application, dans la mesure où beaucoup ont tendance à ne considérer que les compteurs du système d’exploitation ‘prêt à l’emploi’ ou des composants de bas niveau, perdant ainsi l’opportunité de mesurer la performance dans des scénarios réels.
Investir dans ces compteurs est un moyen simple et pragmatique d’identifier les facteurs clés pour améliorer la performance au cours des différentes versions de votre application.
Il existe également des outils qui peuvent aider dans le "profiling" du code a posteriori mais c’est un processus en général plus lourd et dont les résultats sont plus aléatoires ou spécifiques.
La récupération des données et la journalisation
Enfin, pour aider les gens qui font le support de votre application en production à comprendre les problèmes ou optimiser les opérations, il est souvent pertinent de leur fournir des données relatives aux applications concernées.
Le développeur de l’application connait en général quand il code les données critiques qui doivent être disponibles pour l’analyse d’un problème en production.
Par conséquent, n’hésitez pas à placer ces données à un endroit pertinent pour votre application, que ce soit des fichiers journaux d’application ou une base de données spécifique, en fonction de votre architecture et des contraintes techniques.
En résumé, s’assurer que ces 4 dimensions sont couvertes n’est pas réellement compliqué. Cela relève plus de la discipline que d’expertise.
- Commenting, Testing, and Instrumenting Code from Dr Dobbs
- Instrumentation by Thomas Kyte
- An Introduction To Performance Counters by Michael Groeger
- Effective Code Instrumentation? discussion on Stack Overflow
Nouveau cours : Chroniques de débogage 2
août 29, 2012 Poster un commentaire
| Nouveau cours dans la bibliothèque Pluralsight Par Mario Hewardt Dans ce cours, nous allons jeter un oeil à des outils tels que PerfView, les compteurs de performance, MDBG, etc.., qui sont tous d’une grande aide pour éliminer les bugs. En outre, nous allons présenter Team Foundation Services (TFS) dans le nuage, qui peut vous aider dans vos processus de développement. |
 |
Nouveau cours : SQL Server – Collecter et analyser les données de traçage
août 23, 2012 Poster un commentaire
| Nouveau cours dans la bibliothèque Pluralsight Par Jonathan Kehayias Ce cours vous initiera à l’utilisation de SQL Trace et SQL Profiler pour l’activité de traçage SQL Server, y compris les pièges et les problèmes communs à éviter. Vous apprendrez également à analyser les informations recueillies pour vous aider avec le dépannage des performances, l’analyse comparative charge de travail, de l’audit des activités, et bien plus encore. |
 |
Mesurer la performance d’une équipe de développement – Partie 4 : Minimisation de la dette
août 14, 2012 Un commentaire
Dans nos précédents articles concernant la performance d’une équipe de développement, nous avons abordé l’alignement et la productivité, et la qualité.
Aujourd’hui, parlons de la réduction de la dette.
Capacité à réduire la dette
La dette IT est une notion qui devient de plus en plus populaire auprès des analystes. L’institut Gartner estime la dette informatique à 1,000 milliards de $ à horizon 2015.
Pendant longtemps, les départements informatiques ont présenté à leur management le coût des applications développées sans réellement mesurer les coûts induits pour le futur.
Et pourtant, dès que vous développez et déployez une application, vous générez des coûts de maintenance qui dureront aussi longtemps que l’application elle-même. Ces coûts ne disparaîtront qu’au remplacement de l’application.
L’expérience montre que les applications durent toujours plus longtemps que prévu. Même quand vous pensez qu’il s’agit d’une solution temporaire, un changement d’orientation ou des restrictions budgétaires peuvent impacter le timing de la nouvelle version. Des problèmes apparaissent aussi souvent dans tout projet logiciel et les retards de livraison sont la règle dans ce domaine, sans parler d’échec de certains projets en particulier dans le cas de rupture technologique.
Par conséquent, livrer une application qui fonctionnera avec un effort de maintenance minimal est en fait l’un des éléments les plus importants pour mesurer la performance d’une équipe de développement logiciel.
Lors d’une réunion d’éditeurs à l’AFDEL, Microsoft avait partagé cette diapositive il y a 5 ans. Il s’agissait de l’évolution de la répartition des développeurs pour le groupe Windows. En bleu, ceux dédiés à la maintenance, en orange, ceux dédiés à la compatibilité et en jaune, ceux dédiés à l’innovation. Cela illustre parfaitement l’évolution du défi du coût (notamment pour un éditeur) lorsqu’un logiciel est utilisé avec succès. L’existant devient un poids important pour préserver le bon fonctionnement.
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 démesurée des coûts de maintenance, le problème grandissant au fil du temps. La diapositive ne dit pas réellement si la part jaune produit autant de valeur que par le passé, mais on peut en avoir une idée en pensant que l’effort était surtout un travail pré-Vista.
Les problèmes sont délicats à éviter, généralement, les gens en prennent la pleine mesure quand il est trop tard. C’est un peu comme ‘la tour de Pise’ pour laquelle une correction a posteriori n’est pas réellement possible, et le seul fait de la faire tenir debout est coûteux. La vraie solution consiste parfois à reconstruire alors que les organisations pensent qu’ils ne peuvent pas se le permettre.
Elles vont donc dépenser encore plus d’argent à maintenir car en informatique, c’est généralement moins visible que la tour de Pise, et cela sera noyé dans les coûts opérationnels. Les informaticiens associeront ces coûts aux ‘évolutions déraisonnables’ demandées par les ‘utilisateurs sur-exigeants’. 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 :
De notre point de vue, il y a 2 types de systèmes :
- Ceux qui sont très stables fonctionnellement. Dans ces scénarios, même si une évolution individuelle s’avère coûteuse, c’est probablement une bonne chose de les maintenir sur le long terme, bien que la technologie soit très ancienne. On lance souvent des projets au prétexte que la technologie n’est plus supportée par l’éditeur, mais ce n’est pas un argument si important lorsque votre système a fonctionné pendant des décennies. Le risque est minime avec un tel historique.
- Ceux qui évoluent beaucoup parce que l’entreprise exige des ajustements de l’application relativement souvent. Dans ces situations, si vous avez basculé dans un scénario de dette lourde, il est toujours temps de parier sur une nouvelle conception pour résoudre le problème. Le plus délicat est que vous devrez probablement le faire par ‘morceaux’ pour sécuriser le succès du projet car les projets ‘big bang’ mènent souvent à des échecs majeurs. Rajeunir le code, réduire la taille de la base et l’aligner avec une technologie plus récente vous fera économiser de l’argent relativement rapidement. Encore faut-il le faire correctement, avec l’approche appropriée, les bonnes personnes et un outillage efficace.
L’effet de levier de la dette applicative
Dans la mesure où votre application évolue, l’héritage que vous avez développé grossit en maintenance et une sur-complexité impacterait l’évolution des coûts.
Prenons un scénario typique d’une application qui a un cycle de vie de 10 ans. Le tableau suivant décrit un ‘scénario nominal’ avec un développement initial de 100 et des évolutions au cours des années suivantes. La maintenance est calculée sur la base de 15% du temps passé cumulé.
Scénario nominal
|
Ligne de coût |
Année 1 |
Année 2 |
Année 3 |
Année 4 |
Année 5 |
Année 6 |
Année 7 |
Année 8 |
Année 9 |
Année 10 |
Total |
|
Développement initial |
100 |
100 |
|||||||||
|
Evolutions |
30 |
15 |
50 |
25 |
10 |
40 |
25 |
16 |
5 |
216 |
|
|
Maintenance |
15 |
20 |
22 |
29 |
33 |
35 |
41 |
44 |
47 |
284 |
|
|
Coût annuel |
100 |
45 |
35 |
72 |
54 |
43 |
75 |
66 |
60 |
52 |
600 |
Cela donne un coût global équivalent à 6 fois le coût initial ce qui est cohérent avec beaucoup de projets ‘classiques’ avec un certain niveau d’évolution au fil du temps pour être aligné avec l’entreprise.
Maintenant, imaginons une équipe qui n’est pas complètement optimale mais qui ajoute un peu de sur-complexité avec un facteur de 20% par an, ce qui n’est pas outrageux. Là encore, nous estimons que la complexité se démultiplie au fil des années et accroît le coût des évolutions par une approche cumulative. Nous calculons là encore la maintenance avec 15 % du temps passé.
Déviation annuelle de sur-complexité de 20%
|
Ligne de coût |
Année 1 |
Année 2 |
Année 3 |
Année 4 |
Année 5 |
Année 6 |
Année 7 |
Année 8 |
Année 9 |
Année 10 |
Total |
|
Facteur de sur-complexité |
1,2 |
1,2 |
1,2 |
1,2 |
1,2 |
1,2 |
1,2 |
1,2 |
1,2 |
1,2 |
|
|
Développement initial |
120 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
120 |
|
Evolutions |
0 |
43 |
26 |
104 |
62 |
30 |
143 |
107 |
83 |
31 |
629 |
|
Maintenance |
0 |
18 |
24 |
28 |
44 |
53 |
58 |
79 |
95 |
108 |
508 |
|
Coût annuel |
120 |
61 |
50 |
132 |
106 |
83 |
201 |
187 |
178 |
139 |
1257 |
Le coût cumulé du projet a doublé à la fin et, fait notable, le coût de l’évolution de l’année 10 est 6 fois supérieur à ce qu’il serait sans le fardeau de cet héritage trop complexe !
Une autre observation qui peut être intéressante est de comprendre ce qui se passe quand le projet démarre mal. Avec un facteur de dérive de complexité de 30% au début, même si vous réagissez et que vous baissez progressivement le facteur de 1,3 à 1 au fil des années, vous n’allez jamais réduire votre coût de maintenance suffisamment pour être aligné avec les équipes ci-dessus.
Déviation annuelle de sur-complexité initialement à 30% réduite à 0 au fil du temps
|
Ligne de coût |
Année 1 |
Année 2 |
Année 3 |
Année 4 |
Année 5 |
Année 6 |
Année 7 |
Année 8 |
Année 9 |
Année 10 |
Total |
|
Facteur de sur-complexité |
1,3 |
1,3 |
1,3 |
1,2 |
1,2 |
1,2 |
1,1 |
1,1 |
1 |
1 |
|
|
Développement initial |
130 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
130 |
|
Evolutions |
0 |
51 |
33 |
132 |
79 |
38 |
167 |
115 |
73 |
23 |
711 |
|
Maintenance |
0 |
20 |
27 |
32 |
52 |
64 |
69 |
94 |
112 |
123 |
592 |
|
Coût annuel |
130 |
70 |
60 |
164 |
131 |
102 |
236 |
209 |
185 |
146 |
1433 |
Les projets qui démarrent mal ne finissent jamais bien, c’est également une observation terrain que l’on peut faire. Lorsque cela est vraiment dramatique, il vaut mieux démarrer un nouveau projet. Ci-après un graphique des coûts cumulés des applications des 3 équipes.
Bien qu’un peu simpliste, ce modèle est cohérent avec certaines de nos observations sur le terrain lorsque la complexité se traduit par une explosion des coûts à long terme.
C’est pourquoi, comme nous l’avons expliqué dans l’article sur la productivité, il est également très important d’être capable d’estimer la taille réelle et la complexité de votre projet. C’est une façon de s’assurer de ne développer que le minimum nécessaire dans la mesure où chaque ligne de code superflue sera très coûteuse tout au long du cycle de vie de l’application.
De nos observations sur le terrain, nous sommes toujours très surpris quand les gens ne connaissent pas les métriques simples comme :
- Nombre d’entités du métier ou tables,
- Nombre d’écrans ou de pages,
- Nombre de rapports,
- Nombre de lignes de code.
Une chose est sûre, il faut être en mesure d’évaluer le coût sur la base de ces é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…) à la fois pour la production du logiciel mais aussi pour évaluer la maintenance et la mise en œuvre des évolutions.
Si le seul critère que vous avez pour connaître l’impact d’une demande de fonctionnalité est le temps estimé par vos développeurs, il se peut que vous soyez en difficulté dans la mesure où vous n’avez aucun moyen de contester. Et l’expérience montre un degré très élevé de variabilité entre les compétences des développeurs.
Comme toujours, n’hésitez pas à commenter et à partager vos propres expériences.
Daniel COHEN-ZARDI
Président de SoftFluent
Mesurer la performance d’une équipe de développement – Partie 3 : Qualité
août 2, 2012 2 Commentaires
Dans nos précédents articles à propos de la performance d’une équipe de développement, nous avons abordé l’alignement et la productivité.
Aujourdhui, nous traitons de la qualité.
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.
Selon nous cela passe par 5 dimensions comme indiqué dans le schéma suivant :
La qualité est évidemment un sujet “en soi” avec ses propres défis d’organisation et de meilleures pratiques. Précédemment, nous avions développé dans un article les "Software testing best practices". Ce billet est d’ailleurs devenu le plus visité de notre blog, ce qui confirme l’importance du sujet.
L’idée ici n’est pas de traiter de l’ensemble du vaste sujet de gestion de la qualité mais plutôt de se concentrer sur la façon de mesurer la performance de votre équipe de développement sur cet aspect particulier du développement logiciel.
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 l’évolution au fil du temps. Evidemment moins il y a de bogues mieux c’est. Mais attention, le "zéro bogue" est souvent 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 en général cela signifie dans ce cas qu’il y a peu d’évolutions.
Ce qu’il est important de surveiller au fil du temps lorsque vous livrez un logiciel c’est
- La tendance du nombre de bogues : elle peut être élevée au moment où de nouvelles fonctionnalités sont livrées et doivent se réduire régulièrement ensuite,
- La répartition de l’importance des bogues : critique, majeur or mineur,
- La cohérence du ratio bogue/ligne de code quand vous dé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 de l’impact sur la fiabilité.
La conséquence d’un manque de fiabilité peut être désastreuse, surtout pour les éditeurs de logiciels. Le coût du support d’une application peut en être impacté dramatiquement, il y a quelques précédents d’éditeurs qui ont disparu ou ont été sévèrement impactés par manque de fiabilité sur une version spécifique de leur logiciel.
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 qualité du logiciel, les utilisateurs n’utiliseront pas 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. Cela ne signifie pas de ne prendre en compte que ce critère ou de tout écrire en langage assembleur, mais 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).
Si certains traitements de données sont longs il est judicieux de réfléchir à des mécanismes asynchrones, au fractionnement des données ou à d’autres options de conception pour éviter une expérience pénible pour vos utilisateurs.
La conséquence d’un manque de performance sera la non-acceptation de l’application par l’utilisateur, quelle que soit la bonne mise en œuvre des fonctionnalités. Dans le cas d’une application interne, cela causera un conflit dans l’entreprise. Dans le cas d’un produit destiné à être vendu… vous ne le vendrez simplement pas !
Scalabilité
On a tendance parfois à confondre performance et montée en charge (scalabilité). Ce sont 2 sujets différents qui parfois requièrent 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 à gérer. Par exemple Access est une SGBD très performante mais pas scalable notamment en nombre d’utilisateurs.
A gauche, est représenté un système non scalable, à droite, un système scalable.
Avec l’émergence d’internet, et donc des applications Saas et Cloud, la scalabilité revêt souvent 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.
Avec la diminution du coût du matériel, multiplier le nombre de machines est nettement moins coûteux que la sur-optimisation de la performance avec du temps de développeurs. Mais l’ajout de machines ‘en soi’ ne fonctionne pas, il vous faut concevoir votre application de sorte que vous puissiez partager le travail entre ces machines tout en maintenant la cohérence.
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 que l’application n’a pas été conçue pour, il n’y a en général pas de solution à court terme.
Exploitabilité
L’exploitabilité est la capacité d’une application à être rapidement corrigée en production.
La bonne gestion des erreurs et exceptions est un élément clé comme mentionné dans notre article "Code instrumentation best practices".
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 scénario non prévu initialement,
- Proposer une correction compatible avec le code existant.
La rapidité avec laquelle vous pouvez reproduire le problème est également un indicateur clé pour le support de votre application.
Penser à l’après-sinistre et à la manière de restaurer une application dans le cas d’événements majeurs fait partie de cette dimension également.
La conséquence d’une application peu exploitable se traduit par un risque d’indisponibilité. Au-delà des coûts induits et des problèmes d’image une interruption de service peut être très impactant dans certaines entreprises où le chiffre d’affaires est directement corrélé au bon fonctionnement du système.
Ergonomie et facilité d’utilisation
L’ergonomie et la facilité d’utilisation constituent également un pilier majeur de la qualité.
Les mesurer et effectuer des comparaisons n’est pourtant pas si simple. Les gens ont 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.
Certaines applications comportent de plus des complexités intrinsèques à leur problématique susceptibles de requérir une connaissance très spécifique, et pour lesquels il n’est pas toujours aisé de définir une ergonomie simple et intuitive.
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 ?
L’idéal est de privilégier de nouveaux utilisateurs plutôt que des utilisateurs qui auraient pu être habitués à d’autres systèmes. 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é de vos utilisateurs et une facilité d’acceptation de l’application.
Exactement comme pour la performance, le risque en cas d’échec sur cette dimension est la non-acceptation de l’application par les utilisateurs et des coûts cachés.
En conclusion, lorsque vous mesurez la qualité de votre développement logiciel, n’oubliez pas d’évaluer ces 5 dimensions. Elles contribuent toutes à faire de votre logiciel un succès.
N’hésitez pas à commenter et à partager vos expériences.
Daniel COHEN-ZARDI
Président de SoftFluent
Mesurer la performance d’une équipe de développement – Partie 1 : Alignement
juillet 9, 2012 4 Commentaires
Cette question est toujours délicate. 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 un exercice complexe.
Et notamment lorsque ces équipes doivent créer des produits commerciaux et innover, par exemple dans le cas des éditeurs de logiciels. Une mesure universelle est 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, dans 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, il peut y avoir également une opportunité de valeur additionnelle dans la manière dont cela aide l’entreprise à prendre des décisions stratégiques en mettant en avant l’information pertinente de la bonne façon. Donc mesurer la performance intrinsèque d’une équipe technique n’est pas simple.
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.
Comment l’équipe de développement contribue à améliorer la façon dont une entreprise gère ses affaires est la clé d’une meilleure performance. Et cela nécessite une réelle collaboration entre l’équipe de développement et les autres départements.
De notre point de vue, il y a 5 piliers pour la performance d’une équipe de développement logiciel :
-
Alignement,
-
Productivité,
-
Qualité,
-
Capacité à minimiser la dette,
-
Prédictibilité.
Ces 5 dimensions sont toutes importantes pour avoir une équipe de développement performante sur le long terme.
Alignement
Commençons par l’alignement. C’est probablement le facteur le plus important pour la performance du fait de son effet de levier considérable qui peut créer une différenciation significative entre les équipes.
Beaucoup de gens mesurent la productivité (ou pire, juste 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 (flèche la plus courte) en quantité. 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 (projection sur l’axe valeur).
Et 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 pertinente 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.
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.
Ce syndrome est lié au fait que les techniciens aime la technologie. Donc ils essaient de résoudre des problèmes qu’ils n’ont pas encore ou appliquent des choses qu’ils lisent sur Internet sans réellement comprendre si cela s’applique à leur problématique ou pas.
Une autre question délicate à propos de l’alignement est le positionnement de l’équipe technique dans certaines organisations. Parfois, l’équipe technique est positionnée comme une simple ressource qui n’a pas de valeur ajoutée, au-delà de la production, sur les décisions des départements ventes ou marketing, sans possibilité de dire un mot sur les options potentielles de conception.
Dans cette situation, vous obtenez une équipe technique faible, ce qui justifie a posteriori de donner les pleins pouvoirs aux équipes commerciales. Les organisations sont alors piégées dans un cercle vicieux et se ferment l’opportunité d’obtenir un apport réel d’ingénieurs intelligents qui pourraient proposer des options de conception susceptibles d’optimiser le coefficient valeur de sortie/coût d’investissement.
Bien sûr, il existe aussi des applications de faible valeur avec peu d’espace pour la créativité et simplement un travail détaillé par un expert métier. Mais ces applications ont toutes les chances d’être disponibles sur le marché des progiciels donc pourquoi vouloir les développer dans ce cas ?
Les équipes qui sont allées dans cette voie en délocalisant leur développement à bas coûts ont la plupart du temps perdu la capacité d’une évolution majeure de leur offre. A un certain stade, ils sont rattrapés par une perturbation fonctionnelle majeure sur leur marché, sans parler de la nécessité de suivre l’innovation technologique, un défi auquel toutes les équipes logicielles finissent par devoir faire face.
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… pour la même valeur !
De notre point de vue, 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 y a 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.
Une autre façon avancée de maintenir cet alignement sur le long terme est de mettre les données directement dans votre application. Cela est particulièrement intéressant pour les applications Saas ; l’éditeur de logiciel peut ainsi facilement suivre les fonctionnalités réellement utilisées par les clients. Suivre l’utilisation fournit des informations essentielles pour connaitre la valeur de chaque fonctionnalité et permet de faire des investissements basés sur des faits, et non seulement sur des perceptions, que celles-ci proviennent de vos clients ou des équipes internes.
Daniel COHEN-ZARDI
Président de SoftFluent
Notions essentielles du protocole HTTP
mars 16, 2012 Poster un commentaire
|
Nouveau cours dans la bibliothèque Pluralsight HTTP est le protocole du web, et ce cours se penchera sur l’HTTP selon la perspective d’un développeur. Nous verrons durant le cours les ressources, messages, cookies, et protocoles d’identification. Puis nous nous pencherons sur comment les clients http peuvent utiliser les connexions persistantes et parallèles pour améliorer les performances, et comment le web s’ajuste à la demande en utilisant la mise en cache, en-têtes, et servers proxy. |
 |
Programmation asynchrone avec TPL
janvier 9, 2012 Poster un commentaire
|
Nouveau cours dans la bibliothèque Pluralsight Par Ian Griffiths Ce cours décrit comment utiliser le support de programmation asynchrone dans la bibliothèque parallèle de taches (TPL), qui fut ajoutée dans .NET 4.0. Il montre également comment les nouvelles caractéristiques de langage dans C# et Visual Basic s’adaptent avec la TPL. Apprenez comment la TPL vous aide à écrire un code performant, réactif et montant en charge en utilisant des techniques de programmation asynchrone. Visualisez ce nouveau cours maintenant ! (US) |
 |
