L'alignement de l'architecture technique et l'organisation projet

Ou comment adapter l'organisation de l'équipe en fonction des choix d'architecture technique d'un projet.

Publié le 28 août 2012, catégorie boulot
Tags: architecture, gestion, management, projet

L’environnement

Lorsque l’on lance un projet SI, on fait un certain nombre de choix techniques, en particulier des choix architecturaux. Hors ces choix impliquent certaines contraintes sur l’organisation de l’équipe de développement et de son entourage.

Prenons un exemple : nous souhaitons développer une brique applicative d’un SI quelconque. On pose classiquement une architecture n-tiers, avec trois couches de base :

Le projet est ainsi découpé en trois briques, relativement isolées les unes des autres. Cette organisation architecturale se retrouve souvent dans l’organisation des sources et des projets : on va classiquement créer trois projets distincts. Ces trois projets distincts devraient fort logiquement se retrouver avec trois équipes distinctes, pourtant c’est rarement le cas.

Les problèmes

Parce que les ressources sont insuffisantes, parce que les délais sont trop serrés, parce que l’AMOA qui définit les cas métiers fait une fiche par fonctionnalité, et qu’on n’a pas le temps de concevoir chacune des fiches en fonction de l’architecture établie, un ingénieur de développement va prendre une fiche d’évolution, et seul va prendre en charge la gestion d’une évolution. Il va ainsi à lui tout seul modifier les trois couches.

Ainsi, l’équipe n’est plus segmentée horizontalement, mais verticalement. C-à-d qu’au lieu de segmenter l’équipe en équipe projets, on va segmenter l’équipe en domaines fonctionnels : untel pour les fonctionnalités A, tel autre pour les fonctionnalités B.

Cela pose plusieurs problèmes. Pour commencer, tout le monde touche à toutes les briques. Chacun travaillant dans son coin, chacun arbitre en son âme et conscience les solutions d’implémentation, amenant redondances, et incohérence. Par exemple, l’un a choisit d’implémenter le contrôle d’une règle de gestion dans l’interface, l’autre dans la couche services.

Le fait que tout le monde touche à toutes les couches applicatives amène également un grand nombre de conflits lors de la soumission des modifications.

D’autre part, la base de données relationnelle nécessite des compétences distinctes de la génération d’un code source, et l’expérience montre que des experts dans les deux domaines à la fois sont plutôt rares (je n’ai pas dû en croiser plus de 5 depuis 15 ans).

Enfin, le développeur va avoir tendance, lorsqu’il code ses tests, à ne pas faire des tests unitaires à chaque couche mais plutôt faire un test d’intégration qui va tester en une seule fois toutes les couches. Pour sa défense, c’est moins long de faire ainsi. Cela est en soit un problème parce que cela bloque de facto la réutilisation du code. Si une brique d’une couche basse est utilisée par une autre brique qu’on ne connait pas, que ses interfaces ne sont pas spécifiées, ai-je la possibilité d’y apporter des modifications ? Sans test unitaire, on ne peut pas répondre à la question.

Et comme chaque fonctionnalité n’est gérée que par une personne, cette personne a tendance à devenir le référent pour cette fonctionnalité (c’est lui qui va gérer les évolutions), et prendre les fonctionnalités similaires. En cas de turn-over, la perte d’information devient sensible…

Pour pallier ces problèmes, j’ai déjà vu une équipe implémenter tout un système de gestion de plugins pour livrer des briques transverses au sein de toutes les couches. Chaque plugin étant une fonctionnalité comprenant des éléments des trois couches. Le logiciel se composait ainsi de plusieurs centaines de projets distincts. Ou comment verticaliser un projet par nature horizontal amène une usine à gaz…

On en arrive à une base de données où on trouve deux/trois tables identiques, contenant des données similaires mais organisées différement, parce que crées par plusieurs personnes dans leur coin, sans concertation avec les autres. Il faut dire à leur décharge qu’une concertation quand l’équipe fait plus de dix personnes devient difficile.

Les solutions

La solution, pourtant évidente, consiste à aligner l’organisation technique de l’organisation de l’équipe.

Cela amène une grosse contrainte : il faut traiter les fiches fonctionnelles reçues, et concevoir à cette étape comment on va développer la fonctionnalité demandée, arbitrer les choix architecturaux dès ce moment (par exemple où implémenter les règles de gestion) et se mettre d’accord sur des interfaces. Cette phase prend effectivement un peu de temps, mais elle permet de gagner en cohérence et en maintenabilité du source. Cette tache est généralement prise en charge par l’architecte projet, qui peut organiser des réunions avec les chefs d’équipe pour effectuer ce travail.

Ce découpage peut coicider avec le chiffrage du temps de développement requis. D’ailleurs, découper ainsi les fiches amène une meilleure précision du chiffrage, et lorsque les deux opération sont faites conjointement, on gagne pas mal de temps.

Comme chaque brique est maintenant spécifiée et que les interfaces sont définies précisément, la réalisation des tests unitaires devient évidente : le test unitaire n’est que le codage de la description contenue dans la fiche technique, pour chacune des trois couches. Les tests étant codés, on a maintenant la garantie qu’une modification dans une brique n’impactera pas le reste du monde si les tests ne sont pas violés. La maintenabilité du code augmente donc.

Chaque équipe ayant un rôle plus restreint, elle peut ainsi se concentrer sur plus de détails. Par exemple des détails d’optimisation.

Chaque équipe étant plus spécialisées, la communication sur des problèmes similaires se fait avec un nombre plus restreint de personnes. Par exemple, au lieu d’avoir douze développeurs qui font tout, et qui doivent se synchroniser entre eux, on n’a plus que quatre personnes qui s’occupent spécifiquement de la base de données et qui doivent impérativement se parler entre eux. La communication est définitivement plus facile à quatre qu’à douze.

La communication entre les équipes doit également se faire, et elle se formalise par les réunions de spécifications des interfaces lorsque l’on conçoit le développement unitaire.

On le voit, on a donc des gains de - cohérence dans le développement de l’application ; - maintenabilité du code ; - facilité d’optimisation ; - facilitation de la communication intra et inter équipes.

Lorsque l’organisation technique d’un projet, et l’organisation physique des équipes coincident, les choses coulent d’elles-mêmes, et tout devient plus simple.

Envoyer un commentaire

Les commentaires sont relus pour modération avant publication.
Le formattage HTML basic est accepté.

Nom : (requis)
E-mail : (requis, non publié)
Site Web : (optionnel)