Conclusion de l'intervenant : l'architecte doit intervenir en amont pour éviter ce genre d'erreur.
Evidemment, je n'ai pas les détails du contexte, mais cette conclusion heurte mes conviction. Revoyons donc la scène au ralenti au travers de la loupe des 4 valeur eXtreme Programming :
Communication
De toute évidence, il n'existe pas de manière visible un diagramme des applications du S.I. Elles sont pourtant toutes fortement liées, donc cette information serait primordiale. Sans vouloir faire de scrum-urbanisme, un schéma logique des composants majeurs me semble indispensable. De manière plus générale, la communication ne doit pas s'arrêter au portes de l'équipe.
Simplicité
Est-ce que s'interfacer dès le début avec ce système externe aurait été bénéfique ? Le risque est de développer directement avec ses API, et de coupler les applications. En définissant une API neutre avec ses propres métaphores et son niveau d'abstraction, on découple les composants. Le code initial peut également servir de simulateur ou d'outil de test, ce qui n'est pas une perte de temps. Le concept de Simplicité est délicat à assimiler : il ne s'agit pas de faire du code naïf, ni même de faire le moins de lignes de code, mais de faire quelque chose de clair, concis, avec des rôles bien séparés et un bon niveau d'abstraction. Les métriques de cette architecture émergente sont difficiles à quantifier.
Par ailleurs, la maturité obtenue sur ce premier jet est en soi une avancée. On a toujours tendance à évaluer le coût en considérant nos connaissances actuelles, et non celles qu'on avait à l'instant t.
Feedback
Quelqu'un s'est rendu compte que le système existait déjà dans le SI, mais trop tard. De toute évidence il n'intervenait pas dans la boucle de feedback. D'où l'importance de lier aux démos un maximum de personnes d'horizons variés, de faire tourner en continue les tests d'inter-opérabilité, de publier ses API auprès des autres équipes, etc.
Courage
Il faut avoir le courage de faire un refactoring en profondeur pour abstraire l'application de ses dépendances externes. Dans cette optique, les bonnes pratiques de masquage par des interfaces nous aide fortement. A ma connaissance, la seule difficulté majeur est de déterminer si un service est synchrone ou non, ce qui induit fortement nos interfaces. En dehors de ça, local, disant, XML, JMS, ou base de données, peu importe. Il faut aussi avoir le courage de développer son propre modèle de données et une couche de traduction, plutôt que de bondir sur le code généré depuis un WSDL. Le courage de défendre ce choix, qui coûte un peu initialement, mais qui permet une souplesse sans comparaison par la suite.
Alors ?
Si l'équipe agile a pondu une solution locale, même si elle n'est pas adaptée à la cible du S.I, elle a finalement apporté de la valeur métier rapidement. Elle a développé un mécanisme proche de ses propres besoins, respectant le critère de simplicité. Dire que le refactoring associé à une étape d'intégration dans le SI est un surcout est (AMHA) une erreur; au contraire, le système développé permet d'avoir un feedback rapide, et le refactoring nécessaire peut ne pas être si coûteux (en fonction de la maturité technique de l'équipe et de la propreté de son design). Le risque de faire intervenir une phase amont d'architecture, c'est de figer le périmètre, et de décharger l'équipe de ses engagements : "Ca ne tiens pas 1000 utilisateurs simultanés ? C'est pas nous, c'est l'architecte !"
Ma conclusion est que les architectes sont paradoxalement ceux qui défendent l'agilité pour avoir bouffé trop de projets mal ficelés, mais qui ne se l'appliquent pas à eux même. Un peu comme de vouloir une liaison TGV, mais dans le bled d'à côté. Ma conclusion secondaire, appuyé sur de nombreux autres exemples, c'est que beaucoup (trop) de gens s'arrêtent à Scrum pour mettre en place l'agilité, et ne poussent pas assez les pratiques de développement et de responsabilisation de l'équipe, ce qui est le coeur de l'eXtreme Programming.
4 commentaires:
Analyse intéressante. Je suis en train de lire le livre "Coder proprement", et il contient un chapitre sur les ce qui se passe aux limites avec d'autres systèmes. Ce que l'auteur écrit sur le sujet rejoint ton point de vue. Il raconte comment une équipe a du développer un module d'un projet avec une dépendance vers un module non encore spécifié. Placé devant ce problème, ils ont développé une interface spécifiant ce que eux attendaient du service externe, ce qui leur a permis de développer proprement. Puis quand ils ont reçu l'interface réellement exposée par le module externe, ils ont créé un adaptateur entre les deux. Ça permet de découpler fortement. Évidemment, placé devant un module non spécifié, on n'a pas le choix. Il faudrait avoir le courage (et le temps) de le faire systématiquement sur les interfaces...
Disons qu'il faut avoir le courage de défendre qu'une architecture faiblement couplée, avec un cout de dev un peu supérieur, apporte un énorme gain par la suite.
Autre remarque : dans l'idéal on devrait définir les interface externes toujours en asynchrone. Cela permet de migrer plus simplement si c'est effectivement le cas, mais aussi potentiellement de paralelliser les tâches et améliorer les perfs sur un appel externe.
Je propose une métaphore entre les triplettes architecte/logiciel/développeur et mécano/voiture/conducteur.
Il est difficile de prétendre qu'une voiture n'aura jamais besoin dans sa vie d'un mécano, mais si le conducteur l'entretient correctement, il n'y a pas de raison d'intervenir trop souvent. De la même manière, si un code est propre, refactorisé dès qu'il devient trop complexe, et qu'on parvient à faire émerger au fur et à mesure une architecture naturelle, il n'y a aucune raison de faire intervenir un architecte logiciel...
Et je ne dis pas ça de gaieté de coeur : je suis architecte logiciel !
Une autre remarque sur la nécessité d'une architecture en amont : lors d'un retour d'expérience d'un chef de projet MOA devenu Product Owner Agile, l'oratrice a parlé d'un besoin de refactorisation lourde, et a émis l'idée de la nécessité d'un architecte en amont.
Personnellement, ça m'a fait penser au mauvais réflexe dont parlait Régis Médina le matin même à l'Agile Tour Nantes (500 pages de specs ont produit un projet raté, bétonnons les encore plus !). L'impression que ça m'a donné est qu'une surarchitecture en amont avait nécessité une grosse refacto et que le pire à faire était de rajouter de l'archi.
Maintenant, après discussion avec l'oratrice, il s'est avéré que le problème venait plutôt d'une envie des managers de fusionner deux modèles de code développés en parallèles et qui semblaient communs. Et on retombe sur le problème dont on parle dans l'article...
D'expérience, j'aurais tendance à avancer dans un modèle simple, tout en soignant ses interfaces de façon à pouvoir le remplacer par celui existant si nécessaire. En pratique, on se rend souvent compte après un temps que finalement, ça ne fait pas vraiment ce qu'on attendait, que notre modèle dérive vers un besoin un peu différent, et qu'à la fin, on a bien fait de partir sur notre propre choix. Et je te rejoins tout à fait sur le fait que, si les interfaces sont correctes, le branchement sur le modèle pré-existant avec une couche d'adaptation ne devrait pas être si compliqué. Et si c'est le cas, c'est peut-être bien le signe que les deux modèles ne sont pas aussi similaires qu'on le voudrait.
Etant moi aussi architecte mais évoluant dans des équipes Scrum, je me suis interessé à la problématique de la place de l'architecture dans les processus agile.
Je pense effectivement qu'une phase d'architecture est bénéfique en phase d'avant projet, mais la plus light possible l'objectif étant de construire une vision technique du produit, sans rentrer dans le détail de l'implémentation. L'architecte aura ensuite le rôle de guider son équipe pendant l'ensemble de la phase de développement, agissant plus comme un coach que comme un donneur d'ordre.
J'ai détaillé l'ensemble de cette reflexion sur mon blog dans la catégorie architecture logicielle
Enregistrer un commentaire