Il était une fois la révolution

La qualité logicielle ne se réinvente pas si souvent et une fois encore cette révolution nous vient de l’open source.

Qualité rime trop souvent avec douleur. Cette douleur n’est pas liée à la contrainte très compréhensible mais par les métriques sensés les mesurer qui sont abstraites et parfois totalement détachées du travail de celui qui contribue pourtant à cette métrique (voir qui a encore changé le système métrique dans ce blog)

Pourtant, je ne connais ni un ingénieur ni un manager ni aucun autre professionnel qui aime faire un travail de mauvaise qualité.

Alors pourquoi ces pans entiers de copier-coller dans le code de la part de ceux qui en plus ont parfois le mauvais goût d’échapper au revue de code que tout développeur fait ( à moins que ce ne soit une programmation en binôme).

J’adore agile et scrum, mais l’idée que les décisions de bout en bout soient prises rapidement par un groupe d’experts omniscients (qui connaissent 100% du code), ne me semble pas fonctionner sur un projet de plusieurs milliers de personnes. (Mais je suis preneur de témoignage qui me prouveront le contraire)

Donc, comment un directeur d’un projet de plusieurs milliers de personnes peut prendre une bonne décision, sentant sur sa nuque le souffle chaud des CFO et CEO de son organisation, ou dans le meilleurs des cas la pression du client certes compréhensif mais pressé. A t il connaissance de l’ensemble des forces et faiblesses en présence (SWOT) ? Même en admettant qu’il soit le champion de son projet, comment sa décision engagera les futures évolutions du produits ?

Au pire  après quelques projets de moins en moins réussis, l’organisation peut étre amenée à  abandonner des produits entiers car incapable de fournir les évolutions demandées dans des coûts et donc des délais comparables à la concurrence.

Et surtout quel est le rapport entre le travail d’un de ces milliers de développeurs et les métriques désastreuses que lui indiquent le service assurance qualité, ou ce rapport accablant des test systèmes, arrivé 6 mois après la bataille ( Au moins en phase de transition de Waterfall vs Agile). Cela revient à la question, comment donner le pouvoir de décider à une équipe scrum sans mettre en péril le besoin de bout en bout d’un énorme projet?

C’est ce que permet SQALE sous licence creative commons   (Software Quality Assessment based on Lifecycle Expectations). 

L’idée est aussi simple que de quantifier  (en €) la dette technique comme on le fait pour la création de valeur ou pour le cout des développements.

Rappelons ce qu’est la dette technique: le code est un capital, une partie de ce code rapporte des intérêts (Le product Owner de scrum est là pour augmenter cette fameuse valeur), mais l’intégralité de ce code a un coût d’entretien lié à sa maintenabilité qui représente la dette.

L’avantage de la dette technique est de parler au développeur qui en grande majorité n’aime pas intervenir sur un code qui ‘sent mauvais’, à condition une fois de plus d’en comprendre les règles ( qui sont au moins transparentes dans SonarQube )

SQALE peut être instrumenté par l’outil Open source SonarQube.

Pour expliciter rapidement comment cela marche, je me réfère au site de Sonarqube: http://www.sonarqube.org/hudson-sonar-plugin-10-to-industrialize-the-ultimate-build-system/

Et pour en montrer sa simplicité conceptuelle, le mieux reste de se balader à l’intérieur de l’usine logicielle Nemo,.

Nemo est une instance publique de Sonar couplée à  Maven, Hudson, Nexus et Subversion.

Un click sur nemo permet de voir les statistiques de haut niveau :

nemodashboard

Depuis ces statistiques un simple click permet d’aller au détail.

Ainsi en descendant selon le découpage du projet on va pouvoir aller jusqu’à …. la ligne de code concernée.

Et ce n’est pas tout, SonarQube permet de représenter la dette technique grâce donc à la méthodologie SQALE .

Sans entrer dans le détail, SQALE se base sur des règles personnalisables. Exemple :

rules nemo

L’outil est modulaire et devra être adapté en fonction de la technologie (depuis SOC jusqu’au Interface Homme Machine en passant par les applications ), du langage ( les projets en JAVA, sont une fois de plus, les plus chanceux), et surtout de l’adhérence de l’entreprise au fait que la qualité est plus facile à obtenir en s’appuyant sur des cycles de plus en plus courts. (Point Commun à Lean engineering, agile développement Extreme programming, et Artisanat logiciel et surement d’autres cultures d’entreprise tout aussi efficaces).

Définir les régles de dette techniques peut êtte difficile, s’il n’existe pas de standard à grande échelle. Il est une fois de plus fondamental de ne pas chercher le consensus, mais de travailler les objections (à la méthode sociocratique).

Bien que fondamentale, la mise en place de l’outillage n’est pas la plus grosse difficulté, mais d’instaurer un éco-système favorable à gérer ce type changement (voir rupture douce) .

Une fois mise en place, une telle usine logicielle laisse les équipes se focaliser sur la valeur et la qualité du code tandis que le management se focalise sur la vision et le maintien d’un environnement motivant, celui qui encourage la différenciation par l’innovation.

Ce management d’excellence pourra également tenir le niveau d’obstacles en dessous du seuil admissible (une autre sorte de dette technique) ( voir Les employés d’abord, les clients ensuite… de Vineet Nayar)

référence :

http://www.sonarqube.org/hudson-sonar-plugin-10-to-industrialize-the-ultimate-build-system/

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s