Les « équipes transverses » vues par un développeur agile.

Publié le 20/05/2011, par Thomas Bonset dans Agile | 4 Commentaires

Ma mission actuelle

Actuellement j’effectue une prestation pour une banque. Décrire ce métier n’est pas aussi simple que ça en a l’air et en plus ça n’est pas vraiment le sujet de cet article. C’est néanmoins avec appréhension que j’ai accepté cette mission, ne connaissant que d’un point de vue extérieur le domaine métier de la banque.

Le contexte de la mission m’a très rapidement rassuré : Je devais intervenir au sein de l’équipe « usine logicielle » (on va dire UL) afin de la faire évoluer, de la maintenir et aussi d’intégrer une fonction support.

Avant de continuer, il me faut décrire le contexte technique des développements au sein de cette banque, du moins ceux pris en compte par l’UL :

• les applications sont des clients légers, reposant coté serveur sur du Java.
• l’IDE utilisé est Eclipse.
• une grande partie des applications concerne la banque en ligne, à destination des clients.
• une autre grande partie concerne les applications internes à la banque. Il a été décidé, pour garder une homogénéité assez large, d’avoir pour ces applications la même charte graphique, les mêmes contrôleurs… bref, une même « tronche ».

Pour ce faire, Il a été mis en place un plugin Eclipse « maison », un framework « maison », des règles de qualité « maison » :

• le framework est une couche développée au dessus des habituelles bibliothèques (Spring, Hibernate…)

• le plugin Eclipse développé pour accompagner les développeurs pour la création, le développement, la compilation et le déploiement des applications.

• les règles de qualité, exploitant principalement ceux des plugins de référence PMD et Checkstyle.

Ce que Fait l’équipe

L’équipe à laquelle j’appartiens fait partie d’un pôle d’équipes régissant ces différents aspects : parmi elles, les administrateurs des serveurs – bien évidemment -, l’équipe qui met en place, développe et maintient le framework, et l’équipe UL, en charge des aspects de l’usine logicielle (intégration continue, qualité, dépôt de version…)

Et voici donc le rôle de notre équipe :

• Mettre en place le serveur d’intégration continue Hudson, architecturé à grande échelle, avec maitre-esclaves et tout, qui sert de pivot à à peu près tout (j’y reviendrai plus loin) ;  le configurer, gérer les files d’attente, et les déploiements en recette.
• Développer et mettre en place tous les mécanismes de livraison internes à l’IDE.
• Administrer un bon paquet d’applis centrales (subversion, un wiki, d’autres intranets…)
• Développer, mettre en place et fixer les règles de qualité qui font qu’une application est bonne à livrer en production ou pas.
• Offrir un socle de développement permettant d’exploiter ces outils (Eclipse, jre6, tomcat pré configurés…)
• Et évidemment avoir un rôle de support : quand on offre de telles solutions, faut prévoir les cas ou les utilisateurs ont un problème avec ces solutions…

A noter, cette équipe se dit fonctionner en mode Scrum, à la limite du KanBan quand même : les post-its sont là, ils bougent d’une colonne à l’autre pendant les sprints de 3 semaines, ces sprints donnent lieu à des rétros, des planifs et il y a même un burndown chart.

Sauf que…

Eh bien l’indisponibilité liée aux assistances, estimée à 50%, peut énormément varier , ce qui rend très difficile une application littérale de Scrum ; il y a rarement de développements à proprement parler ni de livrables  (donc pas de démos franches) ; il n’y pas vraiment de product-owner non plus. L’équipe UL fonctionne souvent à flux tendu…

Pourquoi le fait-elle

A la base, le besoin d’industrialiser les développements est évidemment le même qu’ailleurs : s’assurer que ce qui part en production fonctionnera bien.

Sans vouloir remettre en cause ni la cascade ni le cycle en V, il faut reconnaître que le cycle itératif, induit par le build continu, présente des avantages tout à fait considérables (!), parmi eux  le fait pour les MOA/MOE d’être au fait de la bonne santé des applications, et ce à tous les niveaux.

Un deuxième intérêt est de valider ou non une application selon des critères de qualité objectifs, définis via  les plugins PMD-checkstyle par l’équipe.

Le véritable intérêt se trouve surtout dans les tests « fonctionnels » : comme les contrôleurs des applis sont très souvent les mêmes (grâce au framework), il a été très rapidement aisé d’utiliser et de mutualiser l’outil Selenium. L’équipe UL a ainsi mis en place deux seuils validant ou non une livraison : Un seuil de 5% de couverture de code par les tests unitaires, et un seuil de 40% par les tests Selenium, ce qui peut paraître peu ; cependant il faut savoir que ces deux seuils se sont greffés sur des projets existants sans tests, et sont voués à augmenter.

Forcer ces seuils présente un double avantage : habituer les développeurs à tester leurs développements, voire à les convertir au cycle TDD, et bien sûr s’assurer de la non régression des applications.

Les limites

Tout ça, ça donne l’impression d’un environnement de travail très sain, et en vérité ça l’est : les développements avancent à bon rythme, tout est cadré, voire sous contrôle.

On voit quand même au bout de quelques mois quelques limites apparaître :

• Une banque peut concentrer beaucoup d’applications à développer, des applications de plus en plus nombreuses et sophistiquées. Toutes les faire passer dans l’usine logicielle revient à redoubler de vigilance : donc nécessité d’une gestion très fine d’Hudson.
• Les outils mis à disposition des utilisateurs  sont développés en interne. Les utilisateurs doivent être formés spécifiquement aux outils maison.
• De plus, un peu d’empathie envers les utilisateurs peut rapidement montrer qu’il est difficile de capitaliser, voire de motiver sur l’utilisation d’outils maison.
• L’évolution des technos (html5, développements sur mobile, sur tablette…) oblige à veiller quotidiennement à la mise à la page des outils mutualisés
• Cela court-circuite un peu la démarche agile (pourquoi ne pas faire confiance aux équipes hein ?)
• Imposer des couvertures de test minimales aux développeurs peu habitués à développer des tests automatisés sur leurs applications (eh bien oui, cela existe encore en 2011), conduit d’une part à de la « sur-qualité », ou le fait de tester du code non pertinent juste pour atteindre le seuil fatidique –exemple concret : tester les accesseurs des beans java -, ou encore avoir à gérer une liste de dérogations pour valider la livraison d’une appli non testée mais critique.
• Il faut aussi définir et se mettre d’accord sur les règles PMD/Checkstyle qui valident ou non une livraison.

A partir de ces constatations, je vous propose quelques réflexions :

Pourquoi imposer des outils, des frameworks aux équipes de développements ?

Tout simplement parce qu’il y a des contraintes :

• Contractuelles : l’intégration aux solutions IBM (Websphere, DB2…)
• Techniques : L’existant sur lesquelles la nouvelle application doit se reposer détermine souvent ce point.
• Financières : Utiliser des outils sous licence libre revient moins cher, et permet de ne pas dépendre d’une société tierce
• Idéologiques : Certaines sociétés n’imposent que des outils libres et ouvertes afin de se faire une image au près de communautés

Pourquoi ne pas faire confiance aux équipes de développements?

A cette question, mon chef/scrummaster me souffle à l’oreille que dans leurs équipes de développement, on retrouve surtout des profils juniors, des stagiaires, des ingénieurs cherchant à évoluer dans le métier bancaire, d’anciens du métier bancaire… bref, très peu de geeks cherchant à capitaliser de nouvelles connaissances.

Chaque pole contient toutefois un référent technique (parfois issu de nos équipes transverses) qui adhère aux frameworks communs et qui – souvent – demeure l’unique interlocuteur de notre équipe transverse.

Que se passerait-il si les différentes équipes avaient toute la latitude sur les choix des technos et des outils ?

Les équipes bougent, changent, un turn-over constant existe dans une banque comme dans toute société. On imagine difficilement qu’un leader technique nouvellement arrivé effectue un audit rapide de ce qui a été fait précédemment obtienne quelques mois de budget pour une refonte technique totale. Ni même que pour avoir 36 applications à faire, il avoir 36 serveurs configurés séparément. Au final, à moins d’une communication optimisée au maximum entre les équipes (Scrum de scrums ?), on arriverait à une cacophonie ingérable, il  faut l’avouer.

Où se trouve l’endroit idéal ou mettre ce curseur ? Homogénéisation ou  Autonomisation ?

Ça n’est bien sûr pas aux équipes de développement de définir l’ensemble du périmètre technique, ni au client de dicter ligne par ligne le code aux développeurs.

Placer un curseur entre ces deux extrêmes est complexe : il s’agit de définir les périmètres d’où découle tout le fonctionnement d’un SI.

Pour répondre à cette question, je me propose de dresser une liste de rôles que pourrait avoir une équipe transverse.

Une telle équipe pourrait avoir pour rôle :

• d’être le garant de qualité des développements
• de mettre en place les critères d’intégration et de qualité minimum au sein d’un SI (quel que soit le contexte technique)
• de s’assurer que les outils de reporting soient utiles et utilisés.
• de pouvoir fournir à chaque  instant l’état des développements actuels
• de proposer, de conseiller  sur les outils à utiliser ou à mettre en place sur les équipes de développeurs (attention, pas forcément à les administrer)
• de proposer et de conseiller sur les méthodes de gestion de projets facilitant le dialogue entre développeurs et utilisateurs…

Comment une telle organisation risque d’évoluer ?

De nombreux paramètres sont à prendre en compte pour donner réponse à une telle question, alors autant faire une réponse courte :

Si l’équipe transverse arrive à communiquer, maintient un dialogue constant entre les différentes équipes (direction – MOE – MOA – développeurs – administrateurs), reste garante de la qualité, maintient et fait évoluer les outils mutualisés, essaie d’induire de bonnes pratiques tels que le cycle TDD, la TDR… alors oui, la présence d’une telle équipe se justifie.

Pour conclure

Ce sujet est vaste et complexe, et mesurer tous les enjeux sur le choix ou non d’une telle organisation demande une réelle expérience, une réelle qualification sur les bonnes pratiques, les méthodes agiles,et surtout un gros effort sur la communication des rôles des équipes transverses.  Je me permettrai enfin de rappeler le premier des 4 piliers du manifeste agile : l’interaction avec les personnes plutôt que les processus et les outils.