Propriété du code avec plusieurs équipes Scrum

Si deux équipes Scrum utilisent le même composant logiciel, qui est chargé de fournir une vision architecturale claire de ce composant et de maintenir / développer cette vision à mesure que la base de code évolue? Dans Scrum, vous êtes censé posséder un code de propriété collectif, alors comment vous assurer que le développement effectué par l'équipe A n'interfère pas avec le développement effectué par l'équipe B?

Je ne suis pas un expert Scrum, mais la "propriété collective de code" AFAIK est destinée à être par équipe et par produit (et je pense que votre question n'est pas spécifique à Scrum, elle pourrait s'appliquer à tout processus de développement "code partagé").

Si vous avez deux équipes A, B, deux produits A, B et un composant partagé C, il existe différents scénarios possibles. Peut-être que le composant partagé appartient principalement au produit A (et est juste réutilisé, mais pas évolué, par l'équipe pour le produit B). Dans cette situation, l'équipe A est clairement responsable de la vision architecturale. Ou vice versa: il appartient clairement au produit B - donc la responsabilité est là. Si l'équipe A est responsable, l'équipe B peut utiliser une fourchette du composant pour permettre des corrections de bogues urgentes (il devrait également y avoir un moyen de les réintégrer dans la ligne principale de C), mais B devrait éviter de faire une plus grande évolution du composant.

Cependant, si les produits A et B ont beaucoup d'exigences de pilotage pour C, vous devez gérer C comme un produit complètement distinct, avec sa propre version, la gestion des versions, la gestion des modifications, les tests unitaires, etc., et une équipe distincte qui a le responsabilité de cette composante. Cette équipe pourrait être juste une "équipe virtuelle", composée de développeurs distincts de l'équipe A, B ou des deux. Cette équipe a la «propriété du code partagé» pour C, et la responsabilité de la «vision architecturale». Imaginez que C soit un composant fourni par un fournisseur tiers.

Il n'y a pas de concept de "vision architecturale claire" dans Scrum ou agile!

Je suis depuis longtemps architecte, et il est clair pour moi que pour avoir une vision architecturale, il faut avoir une vision claire des besoins futurs. Étant donné que dans la plupart des cas, les exigences ne sont pas claires du tout, il n'est pas logique d'avoir une vision fixe.

Ce qui est nécessaire, c'est d'avoir une architecture suffisamment adaptable à l'évolution des besoins. En d'autres termes, les choses changent et l'architecture change - je ne préconise pas une architecture "douce" qui puisse être reconfigurée. Je parle d'accepter que l'architecture que l'on a aujourd'hui sera bientôt obsolète et devra être modifiée, donc personne ne devrait "s'y marier".

La propriété collective du code signifie que tout le monde devrait - en théorie - pouvoir changer quoi que ce soit. Cela doit être compris comme "l'opposé des silos". En d'autres termes, il peut y avoir une barrière de compétences en place, ce qui est normal et attendu - tout le monde n'est pas un DBA expérimenté qui peut affiner les requêtes SQL, pour donner un exemple - mais il ne s'ensuit pas que seul un DBA peut optimisation manuelle des requêtes. Il y aura un "expert du domaine des fonctionnalités" qui pourra aider les autres à devenir compétents, mais les tâches devraient toujours incomber à tout le monde.

Par exemple: si je suis l'expert du domaine sur la fonctionnalité "A", alors je m'attends à ce que quelqu'un d'autre travaille sur la fonctionnalité "A", mais je suis susceptible d'être consulté lorsque des changements majeurs doivent se produire ou que les gens ont besoin d'aide. La fonctionnalité "A" ne serait certainement pas ma fonctionnalité. Ce sera une fonctionnalité que je connais bien. Ce sera mon intérêt de connaître beaucoup plus de fonctionnalités, et l'intérêt des autres de connaître cette fonctionnalité.

En synthèse: l'architecture est conçue et repensée plusieurs fois par les développeurs au fur et à mesure que les exigences émergent et changent. Tout le monde est censé apporter les changements nécessaires en fonction de ses compétences et savoir quand demander de l'aide. Il n'y a pas de vision à long terme sur l'architecture car nous faisons confiance aux gens et nous ne faisons pas confiance aux exigences .

Par exemple, spotify utilise un rôle nommé "Propriétaire du système" pour résoudre le problème, directement à partir du document:

Techniquement, tout le monde est autorisé à modifier n'importe quel système. Étant donné que les escouades sont effectivement des équipes de fonctionnalités, elles doivent normalement mettre à jour plusieurs systèmes pour mettre une nouvelle fonctionnalité en production. Le risque avec ce modèle est que l'architecture d'un système est gâchée si personne ne se concentre sur l'intégrité du système dans son ensemble.

Pour atténuer ce risque, nous avons un rôle appelé «propriétaire du système». Tous les systèmes ont un propriétaire de système ou une paire de propriétaires de système (nous encourageons le jumelage). Pour les systèmes critiques sur le plan opérationnel, le propriétaire du système est une paire Dev-Ops, c'est-à-dire une personne avec une perspective développeur et une personne avec une perspective opérations.

Le propriétaire du système est la ou les personnes à contacter pour tout problème technique ou architectural lié à ce système. Il est coordinateur et guide les personnes qui codent dans ce système pour s'assurer qu'elles ne tombent pas les unes sur les autres. Il se concentre sur des choses comme la qualité, la documentation, la dette technique, la stabilité, l'évolutivité et le processus de publication.

Le propriétaire du système n'est pas un architecte de goulot d'étranglement ou de tour d'ivoire. Il n'a pas personnellement à prendre toutes les décisions, ni à écrire tout le code, ni à faire toutes les versions. Il est généralement un membre de l'équipe ou un chef de section qui a d'autres responsabilités quotidiennes en plus de la propriété du système. Cependant, de temps en temps, il prendra une «journée du propriétaire du système» et effectuera des travaux d'entretien sur ce système. Normalement, nous essayons de limiter la propriété de ce système à moins d'un dixième du temps d'une personne, mais cela varie beaucoup d'un système à l'autre.

J'aime vraiment cette idée, avoir les avantages ou la propriété collective du code au niveau de l'entreprise (non seulement au niveau de l'équipe) mais avec ces propriétaires de systèmes essayant d'assurer une certaine intégrité architecturale.

Un lien vers le document complet: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , c'est un document court mais très, très intéressant basé sur une expérience réelle sur la mise à l'échelle agile.

C'est un problème difficile à résoudre, et ce n'est certainement pas résolu par Scrum, qui est une méthodologie de gestion de projet, pas une méthodologie de développement.

La solution la plus efficace que j'ai trouvée est une bonne gestion des packages (nuget / gem / etc) et un contrôle de version. N'imposez jamais un changement à une autre équipe tant qu'elle n'est pas prête à le consommer. Laissez-les continuer à utiliser l'ancienne version pendant que vous passez à la nouvelle.

Assurez-vous que vous disposez d'une stratégie de gestion des versions qui indique clairement quelles modifications sont en rupture et quelles sont les extensions.

De plus, lorsque vous apportez une modification, envoyez une révision de code à quelqu'un SUR CHAQUE ÉQUIPE. Laissez-les voir comment cela est susceptible de les affecter, bien avant qu'ils ne soient obligés de le consommer afin de pouvoir mettre en œuvre leurs propres modifications.

Et, quand les choses deviennent vraiment désordonnées; lorsqu'une équipe a besoin d'apporter un changement et ne peut pas consommer un autre changement facilement (cela DEVRAIT être un cas vraiment rare), branchez le code, faites-en un package entièrement différent, mais faites-en une priorité pour revenir au code commun dès que le temps permet.

La réponse qui n'est pas toujours aussi évidente que cela pourrait être de laisser les équipes décider comment elles vont partager un composant donné.

Par exemple, mon équipe a récemment commencé à développer une nouvelle gamme de produits qui partage beaucoup de code en commun avec deux autres équipes qui développent des produits similaires depuis longtemps. Notre produit est différent à plusieurs égards, nous devons donc parfois trouver des moyens d'ajouter des points de personnalisation au code commun.

Nous avons eu quelques heurts à propos de ce code et avons essayé quelques façons différentes de gérer la propriété commune. Puis, avec une nouvelle fonctionnalité importante à venir, nous avons décidé que nous devions réunir toutes les équipes pour obtenir la même page, ce qui a abouti à un groupe plus petit composé de quelques membres de chaque équipe qui travaillent sur les détails.

La solution proposée par nos équipes pourrait ne pas fonctionner dans une autre situation. Vous pourriez avoir besoin de quelque chose de plus simple ou de quelque chose de beaucoup plus formel. Le fait est que vous prenez la propriété collective et déterminez ce qui fonctionne pour vous.

Je me permettrai de supposer:

• les tests d'acceptation sont automatisés.
• composant utilise de bons principes de POO: faible couplage et haute cohésion.

Si les hypothèses ci-dessus sont correctes, il ne devrait y avoir qu'occasionnellement des moments où deux équipes interfèrent l'une avec l'autre. Ils peuvent le résoudre en utilisant les méthodes suivantes:

• Dès que le test d'acceptation de l'autre équipe a échoué, parlez-leur pour savoir si leur utilisation du composant partagé est correcte ou la vôtre. Si les deux utilisations sont correctes, voyez si une partie commune de cette utilisation est poussée (refactorisée) vers un composant de base commun et la variance d'utilisation est gérée à l'aide de classes enfants ou peut être via la composition.
• Rendez une personne responsable du composant pendant son développement actif. Il devrait agir comme une ressource partagée entre les équipes.