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

Guide de Survie à l’Adoption ou Transformation Agile

Un livre simple et court à lire absolument pour toute transformation vers plus d’agilité

Plus d’information sur agile-lean-et-compagnie:

http://agile-lean-et-compagnie.com/2013/02/guide-de-survie-a-ladoption-ou-transformation-agile/

 

Le livre est disponible en version PDF gratuite à l’url suivante: http://www.lulu.com/shop/michael-sahota/un-guide-de-survie-%C3%A0-ladoption-ou-transformation-agile-travailler-avec-la-culture-dune-organisation/ebook/product-20702531.html

 

 

 

Jeu du Product Box (Tradution des innovations games)

Objectif: Identifier les  Caractéristiques les plus excitantes de votre produit

Les clients travaillent individuellement ou en petites équipes pour créer et vendre leur produit idéal. Laissez-les vous dire comment ils souhaitent résoudre leurs problèmes.

product-box

Les allées des supermarchés du monde entier sont remplis de Boites passionnantes, colorées, contenant de merveilleux produits venant de partout dans le monde. Elles nous vantent des produits nouveaux, améliorés… Elles nous expliquent en quoi ces produits vont nous rendre plus mince, plus intelligent, plus malin, plus heureux… Et oui, les meilleures boîtes sont là pour nous inciter à ramener ces produits des étagères du supermarché jusqu’à chez nous.

Product Box permet de réutiliser ces techniques issues de la consommation de détail de masse auprès de vos clients.  Pour cela vous allez leur demander de concevoir LA boîte du produit qu’il achète.  Attention, pas n’importe quel boîte, il s’agira de LA boîte qui représente le produit  qu’ils veulent acheter. Ainsi, vous apprendrez ce que vos clients pensent comme étant le plus important, les caractéristiques intéressantes du produit ou du service concerné. Assurez-vous de mettre quelqu’un de votre équipe de marketing dans le coup car il est possible que le résultat soit surprenant.

Le Jeu :

Demandez à vos clients d’imaginer qu’ils vendent votre produit à un salon professionnel, une vente au détail, ou sur un marché. Donnez-leur quelques boîtes en carton et demandez leur de concevoir littéralement la boite du produit qu’ils vous achètent. La boîte devra avoir les slogans de marketing clés qu’ils trouvent intéressants. Lorsque vous avez terminé, jouez le sceptique et demandez à votre client d’utiliser la boîte pour vous vendre le produit de nouveau

Pourquoi cela marche ?

Au delà de ce que nous leur vantons, les clients veulent croire que le produit ou service qu’ils achètent va résoudre leurs problèmes. Pas seulement les problèmes explicités lors du processus de vente, mais les vrais problèmes qui les ont conduit à la décision d’achat. Dans certains cas, ceux-ci peuvent correspondre. Dans d’autres, les clients, même lors de la vente, peuvent ne pas être en mesure de comprendre, et encore moins de mettre en situation les problèmes qui sont à l’origine de leur achat. Product Box offre aux clients un moyen de détecter les vrais besoins profond non explicités et de les exprimer en tentant de nous revendre ce même produit.

En cherchant un moyen de vous vendre ce produit votre client le vendra également aux autres clients dans la salle. Regarder bien l’interaction entre les clients: c’est souvent un moyen d’identifier les informations les plus importantes et utiles. Qui acquiesce? Qui secoue la tête? Quand? Qui pose des questions? A propos de quoi? Quels messages résonnent avec d’autres clients?

Un des défis les plus courants rencontrés par les équipes de produits est de se concentrer sur les apports du produit et non pas seulement ses fonctionnalités. L’avantage de la Product Box, c’est que même si votre client a écrit une fonctionnalité (le quoi) il y a de grande chance qu’il la vende en montrant les avantages qu’ils en tirent (le pourquoi)

Notez que le jeu de la Product Box est un exercice ouvert. Vos clients sont sous votre contrôle, mais restent libres de créer la boîte qu’ils trouvent irrésistible. Vous pouvez comparer ce jeu avec un jeu d’ achat de fonctionnalité , dans laquelle vous sélectionnez et contraindre les fonctionnalités que les clients achètent.

Traduit de http://www.innovationgames.com/resources/the-games/

 

Racine du PDCA, du PSCA, Kaizen….

Merci a Fabrice Aimetti pour la traduction de cetté étude par Ronald Moen, Clifford Norman:

Je me permet d’en copier la synthèse et les conclusions ici.

Fondement du PDCA

Le PDCA, le PDSA et le Modèle de l’Amélioration ont leurs racines dans la méthode scientifique et la philosophie des sciences qui a évolué pendant plus de 400 ans. Nous croyons que le Modèle de l’Amélioration est une évolution importante du cycle PDCA. L’expérience du modèle depuis son élaboration en 1994, montre que :

• Il est applicable à tous les types d’organisations et à tous les groupes et niveaux de l’organisation

• Il fournit un cadre pour l’application des méthodes d’amélioration et des outils guidés par la théorie de la connaissance :

• Il encourage la planification fondée sur la théorie

• La théorie mène à des questions appropriées qui servent de base à l’apprentissage

• Les questions mènent à des prédictions qui guident l’utilisateur à identifier les données nécessaires, les méthodes et les outils pour répondre aux questions concernant la théorie utilisée

• Il souligne et encourage le processus d’apprentissage itératif de l’apprentissage déductif et inductif.

• Il permet d’adapter les plans de projet lorsque l’apprentissage se fait

• Il fournit un moyen simple aux personnes pour prendre elles-mêmes des mesures qui mène à des résultats utiles dans le respect la tradition pragmatique de l’apprentissage.

Traduit par Fabrice Aimetti le 18 novembre 2012• Il facilite l’utilisation du travail d’équipe pour apporter des améliorations.