La productivité des développements… n’est pas qu’une affaire de technologie !

12 leçons à retenir

Retour d’expérience sur le projet NéoRetraite de GENERALI, vu par Benamar développeur et Olivier coach. Ce projet stratégique consistait à mettre en production une nouvelle version d’un contrat de retraite. Il s’est déroulé sur 1 an et a nécessité l’effort coordonné de 3 équipes, chacune en charge d’une application participant au projet. Au plus fort de l’activité 50 développeurs travaillaient en même temps sur le projet.

> Benamar L’équipe que j’ai rejoint était largement constituée de jeunes développeurs qui ne se connaissaient pas avant. Le changement de contexte et de milieu de travail a fait qu’au début je me sentais dépaysé. En outre nous devions collaborer étroitement avec 2 autres équipes constituées aussi de nouveaux arrivants pour mener ce projet.

> Olivier Quand un nouveau arrive, il doit intégrer un grand nombre de règles implicites. Par exemple « Puis-je partager mes doutes sur la pertinence d’une analyse ? Qu’est ce qui est le plus important entre le respect des normes d’architecture et la date de livraison ? Ai-je l’autorité de remettre en question une estimation optimiste ? ». Un jeune développeur a une interprétation moins généreuse qu’un développeur expérimenté sur ces questions. Par exemple, un développeur m’a confié qu’il ne savait pas s’il avait la liberté de reformuler une spécification en pseudo code : « Je dois faire une string avec OK ou KO, ou bien je peux utiliser un boolean ? ». Ce qui a bien fonctionné a été de binômer avec les nouveaux et d’expliciter certaines règles, comme la priorité donnée à la qualité sur les délais.

Leçon #1 : bînomer pour intégrer les nouveaux Leçon #2 : définir clairement les priorités et les objectifs

> Benamar Au début nous avons dû surmonter ensemble un premier obstacle technique : l’intégration douloureuse entre l’IDE RAD6 (1) et MAVEN (2). Pour cela une implication totale de la cellule support JAVA a été nécessaire.

> Olivier Cette période a été importante car elle a permis de lever 2 facteurs limitants. Le premier est le complexe que faisait l’équipe vis-à-vis de ses compétences techniques. Appeler le support JAVA démontrait qu’elle n’avait pas la compétence suffisante pour s’en sortir toute seule. « Attends, je cherche encore un peu tout seul pourquoi ce DTO (3) ne passe pas avec XFIRE (4) ». Aujourd’hui, l’ensemble des technologies à appréhender pour monter une application web standard ne permet pas à une personne de concentrer, seule, toute l’expertise technique. Le second facteur limitant était le mode d’intervention de cette cellule support. Au début nous pensions tous qu’elle pouvait opérer en minimisant les interventions sur le terrain. Par mail : « Essaye avec un entier – déjà fait – t’as vérifié le mapping – quel mapping ? … ». Ce mode n’était pas efficace et les experts se sont mis à venir aider directement les développeurs en vis-à-vis à chaque sollicitation.

Leçon #3 : demander de l’aide n’est pas un aveu d’échec. Leçon #4 : un support efficace passe par aller sur le terrain.

> Benamar Un deuxième levier d’amélioration a été de tirer les bénéfices de l’intégration continue, pour détecter au plus tôt les problèmes d’incohérence et automatiser la construction des releases de notre application. Nous avions l’outillage avec MAVEN et BAMBOO (5) mais les concepts n’étaient pas assimilés. Nous mélangions test d’intégration et test unitaire. Ceci provoquait des échecs de build parasites, pour cause d’indisponibilité ou de non-conformité des services web distant.

> Olivier Le principe de l’intégration continue va de pair avec celui des tests unitaires. Qu’est ce qu’un test unitaire ? Un test automatisé qui vérifie un petit élément de code (méthode ou classe) dans un environnement d’exécution isolé (mocks, stubs… (6)). Son objectif est d’alarmer si ce code ne fonctionne plus (régression). Pourquoi isolé ? Parce que tout ce qui s’exécute dans ce test mais qui n’est pas du code à tester est une source potentielle d’erreur parasite. C’était le cas ici : les développeurs utilisaient l’infrastructure de test unitaire pour enregistrer des test de communication avec des serveurs externes. L’effort à fournir pour séparer le grain de l’ivraie dans les rapports BAMBOO était tellement important qu’il n’était plus fourni. « Pas la peine de chercher pourquoi ça plante, le serveur du back office a du être réinstallé ». Par convention de nommage, nous avons fait en sorte que ces tests d’intégration puissent être exécutés manuellement tout en n’étant pas référencés comme tests de non régression par BAMBOO.

Leçon #5 : test unitaire = isolé. Leçon #6 : les outils ET les principes.

> Benamar Ce qui freinait ensuite notre performance était la façon de communiquer par web services. Consommer des services avec 5 paramètres d'appels au maximum était maîtrisé, mais les services se sont multipliés et leurs signatures se sont grandement complexifiées. Pourquoi ? Parce que les 2 équipes qui nous fournissaient des services minimisaient leurs efforts en exposant leur logique interne dans la signature, ce qui complexifiait grandement leur invocation. Nous avons alors décidé qu’une phase de définition conjointe du contrat de service devait précéder l’implémentation. Ce contrat incluait notamment des exemples d’invocation et une implémentation factice pour les tests. Cela a eu un effet très positif. Nous avons renforcé cet effort en séparant, dans le référentiel de code, la partie interface de l’implémentation, pour pouvoir livrer le premier avant le second. Cela a sensibilisé tout le monde sur l’importance de stabiliser les interfaces.

Leçon #7 : stabilité des interfaces. Leçon #8 : spécifiée par le client et non le fournisseur. Leçon #9 : spécifier par l’exemple.

> Benamar Ensuite, nous avons investi dans l’automatisation de nos scénarios de tests avec SELENIUM (7), et mis en place un environnement tampon par équipe avant la mise en intégration bi-hebdomadaire. Cela a permis de prévenir les problèmes d’intégration dont la correction minait grandement notre productivité.

Leçon #10 : Automatiser les tests de non-régression fonctionnelle

> Olivier Quand j’ai rejoint cette équipe, elle avait surmonté les plus gros obstacles technologiques. Mais la technologie ne sert que la partie répétitive du travail de développement. Le reste, le cœur de la valeur ajoutée, est essentiellement une activité de créativité collective. En outre le matériau qui est crée, le code lui-même, est difficilement appréhendable par quelqu’un qui ne code pas lui-même depuis plusieurs mois. Ces 2 caractéristiques font que l’entraide entre développeurs est un facteur crucial d’efficacité. Diagnostiquer un incident, identifier sa cause profonde, trouver un design performant, respecter les normes de codage, remanier du code existant. La qualité d’exécution de ces tâches varie de plusieurs ordres de grandeurs selon le degré d’entraide qu’elle bénéficie. Pour décupler les demandes d’aide dans cette équipe, j’en ai formulé beaucoup moi-même, tout en explicitant le modèle du protocole « Ask For Help » issu de l’étude de Jim et Michèle McCarthy (8) « Je te demande de l’aide librement, je ne prendrais pas ton refus comme un affront bien au contraire, je m’attends à ce que tu refuses sans me dire pourquoi si tu n’est pas disposé à y répondre. Si je ne fais pas cette hypothèse, je risque d’avoir peur que tu acceptes malgré toi. Si tu refuses, je demanderais de l’aide à quelqu’un d’autre. ». Nous avons aussi mis en place le « stand up meeting », un pratique agile qui consiste à se réunir quotidiennement pendant 10 minutes le matin, debout, pour que chacun dise ce qu’il va faire et ait l’opportunité de demander de l’aide. Au bout de quelques semaines il y avait toujours sur le plateau plusieurs personnes en train de s’aider.

Leçon #11 : Demander de l’aide ne coûte rien et apporte beaucoup.

> Benamar Le succès de la première mise en production a été l’occasion de remerciements et satisfaction des hauts dirigeant de chez GENERALI. Ce qui ne pouvait que nous donner une grande satisfaction, et ensuite plus de responsabilités et de détermination pour ne plus baisser le rythme.

Leçon #12 : célébrez !

> Olivier Cette histoire illustre l’aventure humaine d’un projet informatique. La valeur produite par ces mois de travail collectif dépasse la valeur de l’application livrée à la fin. La capitalisation des leçons que l’on peut tirer de chacune de ces expériences est le facteur de productivité durable de l’organisation tout entière.

Auteurs • Olivier PIZZATO, coach chez OCTO Technology • Benamar BER RABAH, développeur chez GENERALI

Références (1) Rational© Application Development est l’environnement de développement d’IBM©. (2) MAVEN est un outil de build opensource. (3) Data Transfert Object désigne un objet qui structure une donnée d’échange. (4) XFIRE est un framework SOAP opensource. (5) BAMBOO est un automate de build continu. (6) “mock” ou “stub” désignent une implémentation factice d’une interface. (7) SELENIUM est un outil de test automatisé d’IHM qui se branche sur le navigateur. (8) “http://www.mccarthyshow.com ” Jim et Michèle McCarthy