La propriété des fonctionnalités est-elle une bonne pratique?

Récemment, dans mon entreprise, il a été suggéré qu'un développeur se concentre (et un seul) sur une fonction. Cela signifierait quelque chose comme mettre le développeur de côté de la routine normale de l'équipe, la libérer de certaines autres responsabilités (réunions et autres) et cette personne serait le "seul" responsable de la fonctionnalité, sur le plan technologique.

Pour mémoire, nous utilisons SCRUM dans SAFe, et nous avons pour les développeurs à temps plein par équipe, le partage de l'AQ et les propriétaires de produits entre nos deux équipes (Android et iOS).

Bien que je convienne que cela augmenterait la productivité à court terme, j'ai le sentiment (et je pense l'avoir appris à l'université) que c'est une mauvaise pratique pour plusieurs raisons:

La révision du code perd de sa valeur.
Partage minimal des connaissances.
Incrément de risque.
Perte de flexibilité d'équipe.

Ai-je raison ou ce n'est pas du tout une mauvaise pratique?

agile team code-ownership

— mdelolmo
source

Ma réaction immédiate est que cela pourrait fonctionner si cela est fait avec modération, mais vous avez raison sur les problèmes si cela va trop loin. D'un autre côté, mon expérience est que chaque fonctionnalité a déjà un propriétaire de fait: la dernière personne qui a passé beaucoup de temps à travailler dessus.

— Ixrec

" un développeur doit se concentrer (et un seul) " - Si vous voulez un SPOF, c'est une bonne idée de le faire de cette façon. J'ai récemment formulé une théorie empirique selon laquelle la personne dont vous avez le plus besoin dans une certaine situation (" wtf?!? Pourquoi l'a-t-il écrit ainsi? ") Est généralement exactement celle qui est en fait absolument inaccessible.

— JensG

@JensG: meh, j'ai une théorie empirique selon laquelle la personne dont j'ai le plus souvent besoin ("wtf? Pourquoi l'a-t-il écrit de cette façon?") Est moi, et en tant que tel le facteur de bus pour "se souvenir des choses qui auraient dû être écrites à l'époque "est 0. C'est juste plus remarquable quand je suis bloqué par quelqu'un d'autre, parce que je m'inquiète à ce sujet au lieu de réexaminer le code existant à partir de zéro sur ses propres mérites ;-)

— Steve Jessop

@SteveJessop: Bien sûr, essayer de réorganiser la façon de penser des autres en examinant un tas de KLOC de leur code pendant que le client vous crie qu'il a besoin d'une solution maintenant ( ou bien! ) Peut être une bonne idée pour certaines personnes, mais je Je ne suis pas assez ringard pour voir quelque chose de drôle en perdant mon temps que je pourrais dépenser de manière plus productive à la place.

— JensG

@JensG: heureusement, mes clients sont mieux socialisés que les vôtres. Par conséquent, je ne suis pas tellement sous pression que de m'engager dans le genre de pensée magique qui aboutit à la conclusion qu'être important pour moi rend vraiment les gens moins joignables par moi. En tant que tel, je pensais qu'il y avait un élément de plaisanterie dans ce que vous avez dit, alors oui, je suis assez ringard pour trouver une situation amusante dans laquelle vous compensez le code incompréhensible en essayant de garder plusieurs personnes autour de vous qui se souviennent comment cela fonctionne. D'autant plus que ces wtfs sont souvent ma faute stupide et non celle de mes collègues.

— Steve Jessop

Réponses:

Au cours de mes 20 années d'expérience, il est préférable que les responsabilités de propriété du code tournent entre les concepteurs ou au moins aient une paire de propriétaires. La propriété d'une fonctionnalité unique présente les problèmes suivants, dont plusieurs que vous avez mentionnés:

il a tendance à pigeonner les concepteurs de trous et à limiter leurs opportunités de croissance
il met tous les œufs dans le même panier, donc si quelqu'un est heurté par un bus ou s'arrête, il peut y avoir un trou dans la connaissance
une seule personne peut ne pas voir un problème dans le code et sans examen par les pairs du code du propriétaire sont beaucoup moins efficaces
il est difficile de maintenir la cohérence et la lisibilité du code si tout le monde travaille sur du code en utilisant son propre style - alors que cela peut être contourné avec des directives de style, les subtilités peuvent se glisser en particulier lors de l'utilisation de la convention sur la configuration où les gens s'appuient sur le comportement par défaut
les développeurs peuvent avoir tendance à devenir protecteurs et défensifs de leur code s'ils le possèdent, ce qui peut inhiber l'évolution du code - si plusieurs personnes le possèdent, cette tendance est réduite

— Jason K.
source

Absolument. Il est important de mentionner le facteur bus comme le problème le plus évident avec une propriété d'une seule personne.

— JensG

Le facteur bus doit être échangé contre le coût et YAGNI, cependant, et si le bus va vraiment paralyser votre organisation ou simplement causer beaucoup de tracas. Si c'était un choix entre perdre, disons, 3 heures par semaine pour toujours s'assurer que deux personnes sont éduquées sur un morceau de code particulier au lieu d'un seul, ou perdre, disons, 60 heures comme une seule fois pour que quelqu'un se lève pour accélérer dans le cas où l'un de vos développeurs est touché, dans de nombreux cas, vous avez choisi le coût unique. Mais pour les raisons indiquées, les silos de connaissances présentent d'autres inconvénients plus importants (quoique moins évidents).

— Steve Jessop

La propriété des fonctionnalités est inévitable, et bien fait peut être une bonne chose. Il contribue à renforcer la maîtrise et permet l'autonomie - deux des piliers d'engagement généralement reconnus . Il indique clairement qui a la responsabilité de ce code, et aide à la délégation, à la communication et autrement à la merde.

Mais vous ne parlez pas de cela. Vous parlez de former une nouvelle équipe - de couper cette personne du reste du code. Ce n'est pas génial. Cela limite leur carrière. Cela augmente les risques pour le projet / l'entreprise. Cela nuit à la camarade.

Une certaine modération pourrait donc être nécessaire pour détourner cela d'une mauvaise idée.

— Telastyn
source

Je ne suis pas d'accord que la propriété du code par une seule personne est inévitable, mais elle appartiendra à un petit nombre de personnes. J'ai vu des organisations qui ont fait du mauvais travail en partageant du code mais qui l'ont fait tout de même. Les configurations les plus efficaces que j'ai vues étaient lorsque 2 à 3 personnes connaissaient des morceaux de code et collaboraient. Cela a réduit le stress et l'isolement parmi les codeurs, car ils n'étaient pas autonomes quand les choses ont échoué et les fonctionnalités en retard pourraient recevoir plus d'attention pour respecter les délais sans les rampes de formation rapides d'autres personnes de l'organisation.

— Jason K.

@jason - bien sûr, il devrait y avoir quelques personnes dans l'équipe à l'aise et capables de travailler sur un morceau de code. Mais une personne finira par l'expert en la matière simplement parce qu'elle y travaillera le plus.

— Telastyn

conviennent que cela se produit souvent, est le scénario le plus probable et que l'expertise en la matière est une bonne chose - seul le désaccord est inévitable simplement parce que j'ai vu un meilleur succès avec plusieurs personnes étant les PME dans un domaine en ayant un chevauchement considérable

— Jason K .