Propriété du code avec plusieurs équipes Scrum


10

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?

Réponses:


10

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.


"soit le composant partagé appartient au produit A" soit ...?
Joe Z.

6

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 .


Mais cela ne répond pas directement à ma question. Que faire des composants utilisés par plusieurs équipes? Qui s'assure que l'architecture actuelle est appropriée? Même si la "vision" architecturale est pour le prochain Sprint ou deux, il doit encore y avoir une vision. Vous ne voulez pas que les développeurs de différentes équipes Scrum changent le composant sans comprendre l'impact du changement sur toutes les équipes et sur l'architecture globale.
Eugene

1
Cela répond à votre question ... quand je dis "tout le monde", je veux dire "entre équipes". Je ne suis pas d'accord que le fait de permettre à tout le monde de modifier un composant partagé le brisera - les développeurs doivent être informés du risque et faire confiance pour le faire correctement.
Sklivvz

Je suppose donc que la personne qui souhaite modifier un composant partagé organisera une réunion avec les développeurs qui connaissent le mieux ce composant et, ensemble, ils adapteront la conception du composant aux nouvelles exigences. Est-ce ainsi que vous travaillez dans votre organisation?
Eugene

@Eugene, ce n'est pas ce que j'ai dit: tout le monde peut changer des choses sans l'autorisation d'un comité. Nous faisons confiance aux gens pour demander de l'aide s'ils en ont besoin et réparer les trucs s'ils les gâchent.
Sklivvz

Je comprends. Je ne dis pas qu'il s'agit d'un processus officiel et obligatoire. Je suis à peu près sûr que dans de nombreux cas, la personne qui souhaite effectuer un changement voudra planifier une réunion afin de comprendre l'impact possible de ses changements.
Eugene

4

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.


Organisation assez cool et idée intéressante sur les propriétaires de système
Eugene

Au lieu de mettre en gras et en italique ce bloc de texte pour signaler qu'il s'agit d'une citation, l'éditeur propose une fonctionnalité / un style de "texte cité". Vous sélectionnez simplement un bloc de texte et utilisez l'icône de guillemets doubles en haut de l'éditeur. Cette utilisation permet de conserver le texte cité dans un style cohérent et reconnaissable sur le site.
Marjan Venema

2

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.


1

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.


Quand vous dites "nous avons décidé", voulez-vous dire par une décision consensuelle? Ou la décision finale dans ces cas appartient à un architecte / responsable technique?
Eugene

Une décision consensuelle, conduite quelque peu mais non dictée par les Scrum Masters.
Karl Bielefeldt

1

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.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.