L'année dernière, j'ai travaillé sur un projet dans une entreprise de services numériques avec un budget assez conséquent, de plusieurs centaines de milliers d'euros. On avait une équipe d'une dizaine de développeurs, deux ou trois architectes, cinq analystes d'affaires pour faire le lien entre les besoins du client et les aspects techniques, et deux chefs de projet. L'objectif était de lancer une première version en un an. Cependant, à la fin, on n'a pas réussi à livrer toutes les fonctionnalités que le client attendait. De plus, il y avait des problèmes sérieux de sécurité, comme l'absence de contrôles sur les données envoyées à l'API, pas de limite de fréquence, ni de restriction sur la taille des fichiers ou des textes. Un utilisateur malintentionné aurait pu exploiter ces failles pour affecter gravement notre base de données ou rendre le service inopérant.
On a également perdu beaucoup de temps en réunions agiles et en discussions, où les analystes d'affaires faisaient le point avec le client puis avec nous, les développeurs. Cela entraînait souvent une perte d'informations et des questions importantes restaient sans réponse. Concernant les accès AWS et les modifications de configuration, cela a été compliqué. Par exemple, si on avait besoin d'un service AWS supplémentaire, il fallait suivre toute une procédure et attendre qu'un architecte puisse le configurer, mais ils n'étaient présents qu'un jour par semaine, donc parfois il fallait attendre une semaine entière pour une simple action.
Ce qui est regrettable, c'est qu'on a mis l'accent sur le respect des délais au détriment de la qualité et de la sécurité. Les clients n'étaient même pas au courant de ces problèmes. Le projet consistait simplement en une application mobile et une API gérant des opérations CRUD, rien de très complexe.
Je pense qu'avec une équipe réduite de trois ingénieurs full-stack compétents, on aurait pu réaliser le projet en mieux et en moins de temps, peut-être en seulement six mois. Cela aurait été plus économique pour le client et le produit final aurait été de meilleure qualité.
C’est contre-intuitif, mais a un moment tu doubles ton équipe tech et tu te dis que tu as l’impression qu’on ship beaucoup moins de nouvelles fonctionnalités que quand on était moitié moins. Tu te rends compte qu’une équipe ne fonctionne pas pareil a 10 et 40. Il y a de la spécialisation, des processus, et tu as un rendement marginal décroissant. Tu peux en sortir bien sûr, mais si tu laisses le bateau tech naviguer par lui même sans une gestion de projet optimisé et un reporting bien défini, alors c’est inévitable. - Laura Pallier (Regate)
Quake a été intégralement réalisé par une équipe de moins de 10 personnes ( source )
Et vous, quelles sont vos retours d'expérience concernant l'application de ce principe ?