agile façon amicale d'intégrer deux applications / équipes distinctes [fermé]

Question

Nous avons deux équipes agiles distinctes, chaque travail sur distinctes, mais connexes, applications.
Chaque équipe a, jusqu'à présent, été en mesure de travailler de façon indépendante (bases de code distinct, les magasins de la persistance, les sprints, les arriérés, etc.). Récemment, la gestion des produits a décidé que ces applications deviendront encore plus étroitement intégrés. Sur une note de côté, la taille de chaque équipe (composée de QAs, Devs, baccalauréats) augmentera au cours des 6-12 prochains mois.

La direction a décidé de maintenir le processus agile en grande partie intact, car il a bien fonctionné (deux équipes travaillant indépendamment, autant que possible), mais ont lancé l'idée d'une couche de service contractuelle comme moyen d'intégration des applications.

Dans chaque sprint, une histoire qui nécessite l'intégration avec l'autre application sera identifiée. À ce moment-là, une histoire « d'intégration » supplémentaire sera ajoutée au carnet d'autres équipes. Cette équipe sera alors chargée de l'exécution du contrat. Entre-temps, l'autre équipe peut poursuivre leur travail d'histoire originale, en remplaçant un service fictif / faux jusqu'à ce que l'autre équipe produit un service de travail.

Depuis Agile prône un philosphy KISS, plusieurs personnes sur les équipes ont contesté la « complexité » de cette approche. Ils plaident en faveur du partage utilisé continué de procédure stockée en tant que méthode de plus maigres / intégration plus simple que « a bien fonctionné dans le passé ».

Je préfère la programmation à base contractuelle pour toutes sortes de raisons, mais la principale raison est la capacité de fournir à la visibilité de la compilation dans le comportement de votre demande devrait fournir. Vous pouvez également obtenir des limites claires autour de qui est propriétaire de ce code, et dont le code que vous êtes susceptible de casser si vous cassez votre contrat. Les procédures stockées ne font rien de cela.

Comme nous l'avons déjà beaucoup profité de agile, je me plais à penser qu'il existe déjà un moyen « agile-friendly » pour faire face à ce type d'intégration d'applications / synchronisation. Est-ce que la création d'une couche SOA à base de contrat de rencontre le test de l'odorat agile? Y at-il une troisième option, je ne l'ai pas considéré?

Answer 1

Grande question. Marcher sur la corde raide de la conception est toujours délicate. Je pense que maintenant les applications comme couplage lâche possible est certainement le chemin à parcourir.

La chose la plus simple qui pourrait fonctionner possible est une bonne approche, mais après cela à une fin dogmatique, sans égard pour les principes solides et une bonne conception générale va vous donner deux applications qui sont étroitement couplées et probablement plein de la dette technique apportera l'équipe de broyage à l'arrêt à un moment donné à l'avenir.

Découplage et en ajoutant l'abstraction semble maintenant comme la chose la plus sensée à faire, aussi longtemps que vous n'êtes pas ajoutant beaucoup de « cadre » supplémentaire qui n'est pas encore nécessaire. L'astuce est de vous assurer d'avoir une assez bonne conception qui permettrait à ce cadre de croître en cas de besoin, sans avoir à construire un tas de choses inutiles à ce moment -. Vous devez faire juste assez pour découpler les applications

Answer 2

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

Modifier Scrum de Scrum. Je n'ai pas d'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 accroître la productivité dans toutes les équipes