TÉMOIGNAGE : « Le développement Agile dans les banques ? Pas vraiment… »

eFC logo
TÉMOIGNAGE : « Le développement Agile dans les banques ? Pas vraiment… »

Le développement en cascades a encore de beaux jours devant lui....

Aujourd’hui, avec l'assaut des fintechs dans la banque de détail et des marges toujours plus réduites, les grandes banques misent toutes sur la "transformation numérique" pour gagner en productivité et devenir plus rentables. Marcus de Goldman Sachs en est un parfait exemple. Les banques veulent profiter de la puissance des données, redéfinir leurs modèles opérationnels et devenir des organisations où le digital est roi. Management mis à part, elles tentent toutes de faire en sorte que leurs département IT utilisent des pratiques Agiles de développement software afin de soutenir le rythme auquel les fintechs peuvent commercialiser de nouveaux produits.

Le développement logiciel Agile provient du Manifesto Agile publié en 2001. Cet ensemble de principes est combiné à une pratique de développement itératif appelée Scrum. L'idée était de réaliser un logiciel utilisateurs toutes les deux semaines environ, avec les retours des utilisateurs pour le prochain cycle de développement. Il y avait des réunions de stand-up quotidiennes pour gérer de près le suivi des progrès d'un ensemble de tâches convenu pour le cycle. Il existe de nombreux outils et techniques regroupés sous le terme Agile. Il est devenu synonyme de développement itératif en général.

De nombreuses affirmations circulent autour de la manière dont certains outils, technologies et autres pratiques améliorent le développement de logiciels. En effet, toute une industrie artisanale de consultants et de coachs certifiés autour des pratiques d’ingénierie Agile est maintenant bien établie. Je les ai vus éparpillés autour des banques pour lesquelles je travaillais, essayant en vain d’effectuer un changement culturel.

Cela peut paraître surprenant, mais dans la finance, nous en savons très peu, de manière empirique, sur l’efficacité des pratiques en matière d’ingénierie logicielle. L’une des raisons est qu’il est extrêmement difficile de collecter des données en raison de la nature exclusive de la plupart des grands projets de programmation. Parmi les études effectuées, nous savons, par exemple, que les révisions de code réduisent les bugs de production et que la programmation par pairs améliore la qualité du code tout en réduisant la productivité.

Le fameux "programmeur 10x" qui est censé être 10 fois plus productif que le développeur moyen ? Cela nous aiderait si nous pouvions trouver un moyen objectif de mesurer la productivité des développeurs. Mais nous ne pouvons pas. Franchement, selon moi, nous sommes au milieu d’une série de méthodologies d’ingénierie logicielle, toutes anecdotiques et de bon sens, qui n’accordent que peu d’attention à l’étude des résultats ou à la collecte de preuves et que les banques, comme tout le monde, ont été séduites.

Le fait est que de nombreuses équipes IT dans les banques continuent de faire du développement en cascades, et ce malgré le fait qu’Agile peut être utlisée dans les applications les plus récentes. – Ces équipes ont peut-être incorporé certains des outils et principes agiles dans leur travail quotidien, mais leur produit ne sera utilisé qu’une fois terminé. Traders, vendeurs et banquiers n’ont ni l’intérêt ni les ressources humaines nécessaires pour se consacrer à des projets technologiques de gestion de produits. C’est d’ailleurs la raison pour laquelle les technologies sont sous-traitées à leurs équipes de gestion.

C'est le gros problème avec les travaux de développement software dans les banques. Le développement logiciel itératif en scrum agile requiert un feedback constant et des experts du domaine facilement disponibles. Ce qui est rarement le cas dans la finance. Ce qui se passe en réalité, c’est qu’une équipe livre un produit fini pas tout à fait correct : à ce moment-là, il faut un bon engagement des départements IT pour éliminer les bugs et les transformer en quelque chose d’utilisable. Je ne dis pas qu’il n’existe pas d’équipes très impliquées pratiquant scrum agile, mais simplement que ce n’est pas la norme dans les grandes banques.

Dès lors, sur quoi les banques devraient-elles se concentrer pour automatiser leurs systèmes de manière plus agressive ? D’après ma petite expérience, les étoiles doivent s’aligner sur plusieurs fronts :

Des équipes de développeurs co-localisées avec un mix équilibré de juniors et seniors et un fort potentiel technologique. Vous avez juste besoin des bonnes personnes qui aiment travailler ensemble et sont consciencieuses (pas facile).

Plutôt que de spécifier la manière de travailler (agile ou non), autorisez les équipes à s'organiser de façon autonome, analysez les politiques de l'organisation au sens large et convenez d'un modèle opérationnel avec les activités supports.

Un outil de première classe facilitant l’intégration, le test et la publication de logiciels récemment développés.

Une infrastructure cloud avec un minimum de bureaucratie afin que les équipes puissent gérer et faire évoluer leur parc logiciel.

Des partenaires hautement engagés et des experts de domaines du secteur qui sont incités à donner de leur temps aux projets technologiques (vraiment difficile.)

Vous avez un scoop, une anecdote, un conseil ou un commentaire que vous aimeriez partager ? Contact : tiochem@efinancialcareers.com

A lire aussi…

Close
Loading...