Une façon agile et conviviale d'intégrer deux applications/équipes distinctes

Question

Nous avons deux équipes agiles distinctes, chacune travaillant sur des applications distinctes, mais liées.
Jusqu'à présent, chaque équipe était capable de travailler de manière indépendante (bases de code distinctes, magasins de persistance, sprints, backlogs, etc.). Récemment, la gestion des produits a décidé que ces applications seraient encore plus étroitement intégrées. D'un autre côté, la taille de chaque équipe (composée de QA, Devs, BAs) augmentera au cours des 6-12 prochains mois.

La direction a décidé de garder le processus agile en grande partie intact, car il a bien fonctionné (deux équipes travaillant de manière indépendante autant que possible), mais a suggéré l'intégration des applications.

Dans chaque sprint, tout sujet nécessitant une intégration avec l'autre application sera identifié. À ce stade, une histoire d'intégration supplémentaire sera ajoutée au carnet de commandes des autres équipes. Cette équipe sera ensuite chargée de l'exécution du contrat. En attendant, l'autre équipe peut continuer son travail d'histoire original, en substituant un service faux/faux jusqu'à ce que l'autre équipe produise un service de travail.

Depuis Agile prêche une philosophie KISS, plusieurs personnes dans les équipes ont contesté la «complexité» de cette approche. Ils préconisent de continuer à utiliser le partage de procédures stockées comme une méthodologie d'intégration plus simple et plus simple qui «a bien fonctionné dans le passé». Je préfère la programmation par contrat pour toutes sortes de raisons, mais la raison principale est sa capacité à fournir une visibilité dans le temps de compilation du comportement que votre application est censée fournir. Vous avez également des limites claires autour de qui possède quel code, et dont vous risquez de casser le code si vous rompez votre contrat. Les procédures stockées ne font rien de tout cela. Comme nous avons déjà récolté de nombreux avantages de l'agilité, je voudrais penser qu'il existe déjà un moyen "agile-friendly" pour faire face à ce genre d'intégration/synchronisation d'applications. La création d'une couche SOA basée sur un contrat répond-elle au test d'odeur agile? Y a-t-il une troisième option que je n'ai pas envisagée?

Answer 1

Bonne question. Marcher sur la corde raide de conception est toujours une question délicate. Je pense que garder les applications aussi lâchement couplées que possible est certainement la voie à suivre.

La chose la plus simple qui pourrait fonctionner est une excellente approche, mais après une fin dogmatique sans tenir compte des principes SOLID et de la bonne conception générale va vous donner deux applications qui sont étroitement couplées et probablement pleine de dettes techniques cela amènera l'équipe à s'arrêter à un moment donné dans le futur.

Le découplage et l'ajout de l'abstraction semblent maintenant être la chose la plus sensée à faire, tant que vous n'ajoutez pas beaucoup de «framework» supplémentaire qui n'est pas encore nécessaire. L'astuce consiste à s'assurer que vous avez une conception suffisamment bonne pour permettre à ce framework de se développer si nécessaire, sans pour autant créer beaucoup de choses inutiles à ce stade - vous devez faire juste assez pour découpler les applications.

Answer 2

Je ne pense pas que garder le processus actuel intact est une bonne idée. La coopération et la communication entre les équipes doivent augmenter sinon cela aura un impact négatif sur les deux équipes. Vous devriez suivre une pratique similaire à Scrum of Scrum.

Modifier Scrum de Scrum: Je n'ai pas l'expérience avec le projet géré par plus d'une équipe Scrum mais à cause de très bonne expérience avec Daily Scrum une croient que Scurm de Scrum fonctionne et d'augmenter la productivité dans toutes les équipes.