Début 2013, InfoQ a publié l'article Comparaison de l'agilité et de Scrum avec d'autres méthodologies logicielles, écrit par Capers Jones, dans lequel il compare l'efficacité de l'agilité et de Scrum avec d'autres méthodes de développement logiciel, à l'aide de quelques métriques standards.
InfoQ poursuit sur sa lancée avec une interview de Capers, abordant la mesure de la performance agile et l'utilisation de métriques en général, et en particulier pour le suivi de l'adoption agile.
InfoQ : Merci à vous, Capers, de bien vouloir accorder cette interview à InfoQ. Pour les lecteurs qui ne vous connaissent pas, pouvez-vous vous présenter en quelques mots?
Capers : Je suis le vice-président et CTO de Namcooks Analytics LLC. Je collecte des données qualité et productivité depuis plus de 40 ans, et j'ai publié une douzaine de livres, ainsi qu'une centaine d'articles, parmi lesquels un article sur la mesure logicielle, dans "Scientific American Magazine".
InfoQ : Nous avons étudié le jeu de données que vous nous avez fourni - il est vaste ! Pouvez-vous nous présenter quelques exemples sur l'usage qu'en font les entreprises ?
Capers : Les entreprises utilisent à la fois les données et notre outil de prévision, Software Risk Manager (SRM). Nous effectuons des études préalablement au démarrage des projets, qui proposent des éléments de risque, planning, staffing, effort, coût et qualité. Ces études sont fondées sur des données historiques pour des projets similaires. L'idée est de minimiser les risques de retard, de dépassement de coûts et d'échec projet, pouvant potentiellement conduire à des procès.
Par exemple, nous pouvons montrer à nos clients des exemples comparés de Waterfall, d'agilité, de XP et de quelques autres méthodologies de développement. D'autres sociétés procèdent similairement, accompagnant les projets agiles avec des outils payants d'estimation, comme KnowledgePlan, SEER, SLIM et SRM.
InfoQ : Quelles sont les principales barrières à l'adoption de métriques ? Et comment peut-on les lever, et aider les organisations lorsqu'elles souhaitent utiliser des métriques avec l'agilité ?
Capers : L'agilité est un mouvement ayant reçu pas mal de succès, permettant d'accélérer le développement en reconnaissant que le changement est légitime, et doit donc être traité naturellement par les méthodes de développement. Cela signifie que la taille finale d'une application peut être ambiguë. Cependant, l'agilité a été utilisée depuis suffisamment longtemps pour que nous disposions de données historiques nous permettant de calculer des indicateurs tels que le nombre de sprints, le taux de croissance dans le temps, l'effort cumulé pour des phases de développement et même de maintenance. Des données relatives à la qualité sont également disponibles sur certains projets.
Le top management (directions exécutive, informatique et technique) s'intéresse de près aux évolutions possibles de leurs projets, avant d'y investir de fortes sommes. Les métriques de résultats historiques peuvent améliorer les prédictions futures. Ainsi, si la communauté agile souhaite convaincre ces directions de la pertinence de l'agilité, alors il leur faut mesurer à la fois la qualité et la productivité.
L'un des problèmes classiques est que le comptage manuel des points de fonction est relativement lent, ce qui constitue une barrière pour les projets agiles, d'autant que cette approche suppose une taille fixée à l'avance. Les méthodes modernes, très rapides, qui prédisent la taille en quelques minutes en l'accompagnant de taux de variation, se prêtent probablement mieux aux contextes agiles. Plusieurs sociétés travaillent ainsi sur le calcul automatisé et rapide de points de fonction, comme CAST Software, Relativity Technologies, et ma propre société.
InfoQ : Lorsque les organisations sont en cours de migration depuis du Waterfall vers des approches agiles, les métriques qu'elles utilisent pour suivre leur développement logiciel doivent-elle également évoluer ?
Capers : Cette question postule que l'agilité est la seule continuation valide depuis le Waterfall. Or, il existe de multiples méthodes qui sont tout aussi efficaces que l'agilité, voire encore meilleures. Le RUP de IBM ("Rational Unified Process", Processus Unifié) et le TSP de Watts Humphrey ("Teams Software Process") fournissent souvent une qualité plus élevée que l'agilité.
Plusieurs variantes agiles, telles que l'eXtreme Programming ou le Crystal Development, ont également l'air intéressantes. D'autres méthodes, comme IntegraNova, permettent une production logicielle encore plus rapide qu'avec l'agilité. IntegraNova est une nouvelle méthode qui nous vient d'Espagne, utilisée par l'armée allemande, et qui a été montrée au Département de la Défense américain. Elle utilise une combinaison de modélisation de besoins et de génération de code, afin de construire des applications complètes en quelques jours. La conception personnalisée et le codage manuel, même dans un contexte agile, sont intrinsèquement plus lents que la génération d'applications, ou l'utilisation de composants certifiés.
En limitant la question au Waterfall et à l'agilité, nous perdons donc un peu de perspective. C'est comme de dire "quels sont les impacts pour la santé d'un changement de régime alimentaire pour un plat principal, lorsqu'on passe de barres chocolatées à des chips ?". On a besoin de plus d'un choix ! Il faut également inclure les approches hybrides, souvent très solides.
InfoQ : Compris. Je reformule alors ma question : existe-t-il des métriques de base, que l'on peut utiliser lorsque l'on passe d'une méthodologie à une autre, qui nous permettraient de suivre la performance d'une façon cohérente ?
Capers : Les deux mesures de productivité les plus utilisées sont "les points de fonction par mois/homme", et sa réciproque "les heures de travail par point de fonction". Lorsque l'on veut juger du niveau de productivité, on estime que des taux de points de fonction par mois/homme supérieurs à 10 sont bons, et des taux situés en dessous de 7 pas très bons. Certains projets agiles ont parfois atteint 15 points de fonction par mois/homme, ce qui n'arrive quasiment jamais dans du Waterfall.
Les mesures de qualité les plus pertinentes sont "les bugs en attente (defect potentials), normalisés par points de fonction", et "l'efficacité de suppression des bugs". Les bugs en attente, ou potentiel de bugs, sont la somme des anomalies qui seront trouvées dans les besoins, la conception, le code, la documentation et les corrections défectueuses. Ainsi, un potentiel de 5 bugs ou plus par point de fonction est mauvais, et un potentiel inférieur à 3 est bon.
L'objectif est de supprimer plus de 99% des bugs, mais la moyenne américaine se stabilise seulement à 85% environ. Atteindre un taux de suppression supérieur à 95% est bon ; se situer en dessous de 85% est mauvais. La plupart des projets agiles ne mesure ni les potentiels de bugs, ni l'efficacité de leur suppression, et n'ont donc pas vraiment d'idée claire sur leur niveau de qualité.
InfoQ : Au sujet de la méthodologie TSP, certains lecteurs ont déploré dans votre article comparant les méthodologies logicielles une inclination trop marquée vers TSP, à la limite du commercial.
Capers : TSP a été développé par feu Watts Humphrey. C'est une méthodologie approuvée par le Software Engineering Institute (SEI). Je n'ai pas participé au développement de TSP, et n'ai pas de relations commerciales avec le SEI.
A ma connaissance, les seuls revenus qui peuvent être dérivés de l'utilisation de TSP proviennent uniquement des ventes du livre de Watts Humphrey sur TSP, et des versements liés à ses anciens investissements. De mon côté, je ne reçois aucun revenu en rapport avec TSP ou toute autre méthodologie. Je ne vends pas des méthodes, je mesure seulement leurs résultats.
J'ai bien reçu des revenus de missions de mesure de projets TSP, mais pas plus que d'autres missions de mesure liées aux 34 autres méthodologies que je connais. Mon article a rapporté les résultats de 10 méthodologies. Je n'ai jamais reçu aucun versement de la part d'un des propriétaires de ces méthodes.
InfoQ : Les équipes agiles peuvent utiliser des "story points" pour suivre leur performance. Peut-on les utiliser comme des points de fonction, vu qu'ils se cantonnent toujours aux mêmes produit / projet / équipe ?
Capers : Les story points sont populaires dans les projets agiles, et portent une forme de valeur intellectuelle, parce qu'ils incitent à réfléchir à ce que les utilisateurs vont faire avec le logiciel. Dans cette perspective, ils sont importants.
En revanche, les story points ne sont pas normés par des standards internationaux, et ne sont pas soumis à des examens de certification, comme le sont les points de fonction. Ainsi, ce qu'on appelle un story point peut varier de 1 à 3 entre les projets et les entreprises.
Dans quelques projets ayant utilisé à la fois des story points et des points de fonction IFPUG, on semble converger vers un ratio de 2 pour 1, i.e. il existe environ deux fois plus de points de fonction que de story points pour une application donnée.
La comparaison entre les projets peut être hasardeuse. Il existe des groupes de benchmarks avec des données de points de fonction, pour plus de 50.000 projets, dont environ 5.000 librement publiés par le ISBSG.org ("International Software Benchmark Standards Group", Groupe pour les standards internationaux de mesure logicielle). A ma connaissance, il n'existe pas de bonnes bases de données relatives aux story points.
InfoQ : Existe-t-il des pratiques agiles particulières ayant démontré un bénéfice pour les équipes ? Si oui, lesquelles, et comment créent-elles de la valeur pour l'organisation ?
Capers : En général, les standup-meetings de Scrum semblent à la fois appréciés et utiles. Bien sûr, les pratiques Scrum peuvent être utilisées dans le cadre de méthodes non agiles, même si elles proviennent de l'agilité. Beaucoup de gens limitent Scrum à un contexte agile, à tort. Une fois que des pratiques telles que les standup-meetings ont montré leur intérêt, elles sont reprises dans d'autres méthodes.
L'une des pratiques agiles ayant reçu le plus de succès est celle des "utilisateurs embarqués", qui deviennent membres intégrés de l'équipe, non seulement fournissant des besoins en temps réel, mais validant également ces mêmes besoins. La limitation de cette pratique a trait à la taille des projets : elle n'est efficace que pour les petits projets, avec un faible nombre d'utilisateurs. Par exemple, Microsoft Office est utilisé par plus de 50 millions de personnes dans le monde, et nul ne peut comprendre la totalité des fonctionnalités disponibles dans une suite logicielle aussi riche et complexe.
Une limitation similaire s'applique aux tailles des applications. Jusqu'à environ 1.000 points de fonction, un utilisateur unique peut appréhender et maîtriser l'ensemble des besoins. Au-delà, pour des applications variant entre 10.000 et 100.000 points de fonction, un utilisateur ne peut espérer connaître plus de 5% de l'ensemble des besoins. Pour ces systèmes géants, des groupes de travail et des études de marché doivent être ajoutés aux utilisateurs embarqués.
InfoQ : Que faut-il à une organisation déjà agile pour mettre en place des métriques efficaces ?
Capers : Ce n'est pas seulement une problématique propre à l'agilité. Nous avons pu déterminer, grâce à des entretiens avec des centaines d'équipes de développement, que la moyenne US de collecte de données projets historiques atteint à peine 37%. Les oublis les plus courants sont les heures supplémentaires non payées, la conduite de projet, et les interventions ponctuelles de spécialistes tels que des rédacteurs techniques, du personnel d'assurance qualité, d'intégration et de contrôle de version. Les dirigeants ont une plus mauvaise opinion des groupes de développement logiciel que des autres groupes techniques, notamment à cause des estimations régulièrement optimistes, des retards de planning, des dépassements de coûts, de la qualité médiocre à la livraison, ou simplement des échecs cuisants de projets. Le développement logiciel récolte les plus mauvaises notes sur tous ces critères. L'agilité visait à améliorer cette situation, et a partiellement réussi, sauf pour les systèmes massifs de plus de 10.000 points de fonction, qui restent problématiques même avec l'agilité.
Une meilleure mesure des projets, y compris des projets agiles, devrait améliorer le statut professionnel de la communauté, et peut-être même revaloriser l'opinion des dirigeants sur les groupes de développement logiciel. La plupart des dirigeants considèrent les groupes de développement comme un mal nécessaire. L'un des anciens dirigeants de ITT, Lyman Hamilton, a déclaré dans un discours public que les ingénieurs logiciels avaient besoin de 3 ans de développement projet en guise de formation, avant d'atteindre le niveau d'autres types d'ingénieurs, comme les électriciens ou les mécaniciens.
InfoQ : Qu'en est-il des prestataires d'outsourcing, mesurent-ils leur performance ?
Capers : Ils le font, donc tant que l'agilité ne produit pas de données quantitatives, les équipes agiles restent susceptibles d'être remplacées par de l'offshore. Par exemple, 60% des sociétés indiennes utilisent des métriques de points de fonction, et s'appuient sur des données pour démontrer leur réussite. Le gouvernement brésilien exige désormais des points de fonction pour tous les contrats publics, et les gouvernements italien et sud-coréen pourraient bien suivre son exemple. Les projets logiciels doivent rester sous contrôle, et les points de fonction en sont un facteur-clé de succès. Tout groupe agile US souhaitant faire du business à l'étranger devra nécessairement fournir de meilleures métriques. Sans cela, il sera impossible de même simplement déposer une candidature dans des pays tels que le Brésil ou la Corée du Sud.
Les sociétés américaines ont beaucoup à apprendre de la façon dont les contrats sont gérés au Brésil. La taille est définie en termes de points de fonction, et l'effort, le planning, les coûts etc. sont déterminés en avance avec une assez bonne précision.
InfoQ : Si une organisation ne devait construire qu'une seule métrique, laquelle serait-ce ? Pourquoi ?
Capers : Les organisations qui ne veulent faire qu'une seule chose échoueront toujours, quelle que soit la nature de cette chose. Il en faut plus d'une seule.
Les métriques les plus susceptibles de convaincre les dirigeants du sérieux de l'agilité seraient : 1. Plannings comparés avec ceux d'autres méthodes, comme RUP, TSP et le Waterfall 2. Effort et coûts comparés à ceux d'autres méthodes 3. Une productivité mesurée à l'aide de points de fonction par mois/homme, ou sa réciproque du nombre d'heures de travail par point de fonction
On a toujours besoin de mesures multiples, quel que soit l'objet de la mesure. C'est comme essayer de ne choisir qu'un seul produit en guise de repas : steak ou chou de Bruxelles, si vous ne mangez que ça, vous finirez malade et vous mourrez de malnutrition.
InfoQ : C'est vrai, mais les organisations ne peuvent pas tout faire au même moment. Une dernière opinion sur comment se lancer dans les mesures, ou comment améliorer sa capacité à effectuer des mesures ?
Capers : Les fondamentaux de la mesure sont en réalité assez simples. Vous devez d'abord connaître la taille de votre application, en l'exprimant dans une métrique standard, telle que des points de fonction. Vous devez également connaître l'effort de développement, ainsi que le nombre de bugs et de défaillances rencontrés avant la mise en production, et pour un intervalle fixe après la mise en production.
Ces données sont de toute façon requises dans plusieurs contrats, et sont de plus en plus exigées par les CEO et CIO des grandes sociétés. Le développement logiciel doit progresser, d'un artisanat de bas niveau vers une profession solide, et la mise en place de métriques est l'une des étapes y conduisant. Toute personne ayant déjà payé une facture d'un avocat ou d'un médecin sait bien que les métriques font partie intégrante d'un métier. Si les médecins et les avocats savent mesurer, alors pourquoi la communauté logicielle ne le saurait-elle pas ?
Lorsqu'une société indienne vient proposer un outsourcing logiciel à une entreprise américaine, il y a de fortes probabilités que la proposition commerciale soumise au CEO inclue une productivité prévisionnelle en points de fonction et des métriques de qualité. Comment des équipes US peuvent-elles rivaliser avec des groupes d'outsourcing si elles ne connaissent ni leur niveau de productivité ni leur niveau de qualité ?
InfoQ : Êtes-vous intéressé par des expériences de nos lecteurs InfoQ en matière de métriques ?
Capers : Si des lecteurs de cet article utilisent des métriques, alors je serais heureux d'en discuter la pertinence et l'usage.
Disponible en téléchargement (en anglais): Gestion du risque logiciel corporate dans un entreprise du Fortune 500
Cet article par Capers Jones décrit comment un fabricant du Fortune 500 a décidé de lancer un programme de réduction des risques liés aux logiciels de la société. Les activités de réduction des risques se sont déroulées sur 4 ans, et peuvent servir d'exemple pour les autres grandes entreprises subissant des annulations de projets logiciels, des retards de planning, des dépassements de coûts, des procès avec des clients mécontents, et d'autres problèmes logiciels endémiques.
A propos de Capers Jones
Capers Jones est aujourd'hui vice-président http://www.infoq.com/fr/articles/evaluating-agile-software-methodologieshttp://www.infoq.com/fr/articles/evaluating-agile-software-methodologieset CTO (Chief Technical Officer) de Namcooks Analytics LLC. Cette entreprise construit des outils de pointe d'estimation et de mesure des risques, coûts et qualité. Il fut président de Capers Jones & Associates LLC jusqu'en 2012, chercheur informatique et manager chez IBM pendant 12 ans, et directeur adjoint de la programmation chez ITT Corporation, chez qui il lança le programme de mesure logicielle. Capers est un auteur réputé et un orateur international. Parmi ses livres, on trouve "L'Economie de la qualité logicielle (The Economics of Software Quality)" (avec Olivier Bonsignour), "Bonnes pratiques de l'ingénierie logicielle (Software Engineering Best Practices)", "Mesure logicielle mise en oeuvre et estimation des coûts logiciels (Applied Software Measurement and Estimating Software Costs)". Il travaille actuellement à la rédaction de son 15ème livre, "l'histoire technique et sociale de l'ingénierie logicielle (The Technical and Social History of Software Engineering)", qui sera publié courant automne 2013.
Capers et ses collaborateurs ont collecté des données historiques aujourd'hui utilisées pour juger de l'efficacité des méthodes d'amélioration des processus logiciels, ainsi que pour calibrer la précision des estimations logicielles, parfois utilisées dans des procès liés à des logiciels, comportant des sujets liés à qualité, à la productivité et au planning. Il a également travaillé comme témoin expert dans 15 procès concernant des ruptures contractuelles et des problématiques de taxation logicielle.