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.
