Dans ce talk, Thomas Wickham, Cloud Solution Architect chez Scalingo nous fait part de son retour d'experience. Immersion :

Mise en situation. Je viens d’être nommé chef de projet dans ma big company sur un projet XXL structurant et stratégique. Mais tout ne se passe pas comme prévu, on a de plus en plus de fonctionnalités en stock comme le montre le tableau que j'utilise pour gérer mon projet et les retards s’accumulent.

“Fait comme tout le monde, ajoute plus de développeur·.euse·s”,  me dit un collègue,

On agrandit le graphe et hop c’est bon ! Régression, bugs, tout est mis dans “Nouvelles demandes”. Je vais reprendre le contrôle du projet et ça va mieux se passer

Sauf que… ça n’a pas fonctionné. Mon stock de fonctionnalités à réaliser est toujours aussi important.

C’est à ce moment que j’appelle à l’aide un·e consultant·e.

Son verdict est implacable « vous avez un problème de congestion ».

Il utilise l’analogie du rond point, les voitures peuvent y entrer et en sortir mais il suffit qu’un bus bloque l’accès pour qu’une file interminable de véhicules en bloque complètement l’accès. Il se peut aussi que le flux entre mais ne sorte jamais.

Je lui rétorque que le développement ne marche pas tout à fait comme un rond point.

Il·elle revient à la charge avec un premier schéma qui modélise le flux de développement.

Très bien mais je ne suis toujours pas convaincu. Si la mise en production est bloquée, quelque soit la raison, on va attendre, c’est l’équivalent de notre bus sur le rond point.

Et si mon rond point est limité, l'environnement de pré-production ne l'est pas !

Mais c’est bien plus compliqué, ajoute la·e consultant·e, car le flux n’est pas linéaire, il peut y avoir des retours en arrière :

Ajouter des développeurs au projet n’augmentera pas forcément la vélocité de l’équipe

Résultat, ajouter des développeur·eu·s a même congestionné à nouveau mon projet, à nombre de fonctionnalités équivalente, plus de devs amène plus de retours :

• le code ne passe pas directement en pré-prod, il y a des allers- retours au stade de la revue de code si jamais ce n’est pas conforme aux standards de l’équipe
• l’activité de code review augmente également car il y a moins de cohérences : les dev ne sont pas forcément d’accord
• il faut toujours vérifier que tout fonctionne en environnement d'intégration (recette) : comme on a plus de fonctionnalités par itération, cela complexifie notre application, si plusieurs changements ont été apportés, cela peut avoir entraîné des régressions
• le taux d’anomalies fonctionnelles, lui, n’a pas changé. Des spécifications peuvent être mal comprises ou ne pas correspondre tout à fait à la demande

Le système est de nouveau congestionné et cela se voit à ces symptômes :

• des Feature branch qui sont vieilles (plus de 5 jours ouvrés) et qui sont en attente
• le temps de développement augmente à spécification équivalente
• des PR de PR* dépendantes les unes des autres

A fonctionnalité équivalente, on a donc plus d’efforts de développement !

La·e consultant·e me propose de faire progressivement entrer des devs pour pallier à ces problèmes. Et de prendre du recul.

Le goulot d’étranglement peut se situer à un autre niveau

Au niveau métier, c’est “facile” d’ajouter de nouvelles de spécifications et d’alimenter le flux entrant. On a mesuré la capacité de production de l’équipe de développement, mais qu’en est-il de mon équipe chargée de l’exploitation ? Ne serait-elle pas le facteur limitant de l’équipe ?

Mon objectif est de livrer en production le plus rapidement possible.

J’ai besoin de savoir quelle est la capacité de l’équipe d’exploitation, comment ils fonctionnent et quels sont leurs problèmes.

Mon·a consultant·e me propose de faire appel à un·e un architecte pour faire un état des lieux de nos équipes. Quelqu’un qui connaît l’entreprise, fait de la veille technique et m’aide à travailler avec les équipes techniques, notamment en cartographiant les rôles et responsabilités de chacun·e :

Il est possible de réduire le temps pour passer en production en faisant passer une partie des tâches de la production vers les développeur·euse·e.

Sauf que, ça fait baisser leur capacité de production même si on a amélioré la phase d’exploitation.

Et au lieu de passer du temps à développer des fonctionnalités, les devs peuvent très vite se retrouver empêtrés dans les problématiques d’exploitation...

Retour à la case départ.

Et si on simplifiait ?

Les devs poussent le code source en local, puis le passent à l'exploitation avec les fonctions à déployer. L’exploitation s’occupe des mise à jours, des images dockers, etc.

Take away

Que peut-on retenir de la présentation imagée proposée par Thomas Wickham ? Si une équipe moins agile est sur un chemin critique, cela deviendra à un moment ou à un autre un facteur limitant et votre organisation deviendra alors aussi agile que le moins agile de ses composants. Mais par agile, il faut plutôt ici comprendre véloce.

En cas d'engorgement, voici les trois points à garder à l'esprit :

• On ne peut pas juste ajouter des développeur·euse·s en espérant une augmentation linéaire du nombre de fonctionnalités ajoutées
• La contrainte n’est peut-être pas dans le développement, elle peut être soit en amont au niveau fonctionnel, soit en aval sur l’exploitation
• Un·e architecte peut apporter son aide : sur des questions d’interfaces, de rôles et de responsabilités

Retrouvez la présentation complète sur Slideshare.

https://www.youtube.com/watch?v=3YztF__CL0g