Je te rejoins complètement, et ce n'est pas le seul truc qui me chiffonne dans cet article.
D’expérience, je pense qu’il faut remplacer la revue de code par la revue de conception.
C’est-à-dire demander d’abord aux développeurs de définir comment ils vont résoudre un problème en écrivant le plan de leur solution technique. Et ensuite de relire et de commenter cette conception.
Ça c'est n'importe quoi aussi. J'ai vu un paquet de fois des belles planifs sur tableau blanc tomber à l'eau dès la première ligne de code. Croire qu'on peut résoudre toutes les questions d'implémentation sans coder, et que si ça ne marche pas c'est qu'il fallait réfléchir mieux, c'est se fourvoyer. C'est même la raison pour laquelle on ne fait plus de cycle en V.
Pour moi la question de la conception doit se faire « en gros », et le moment du chiffrage est un bon moment pour échanger là dessus : on communique sur les approches et on élimine les plus gros problèmes.
Les daily/le stand-up sert à remonter les soucis qu'on rencontre sur le terrain : on communique sur les problèmes, on les élimine ou on les contourne.
La revue sert à partager l'information et affiner des détails : on communique sur comment les choses sont faites en pratique. C'est autant au bénéfice du relecteur que du codeur.
Dans toutes les boîtes où je suis passé ces trois étapes étaient la raison pour laquelle les projets étaient fluides. Trois points de synchro pour communiquer et le reste du temps on est bien tranquille. Les seuls soucis que j'ai eu étaient des galères d'humains de mauvaise volonté qui se pointaient au stand-up en râlant à propos du commercial (c'est pas le sujet) ou du patron (toujours pas le sujet), ou encore des gens qui ne voulaient pas retoucher à leur code crado en revue parce que « boaf, ça marche comme ça », voire des héros fiers bloqués en refusant d'échanger à propos de leurs galères. Au final ça me semble simple : si tu joues en équipe, ça marche bien, sinon c'est la merde.
[^] # Re: L'objectif de la revue de code
Posté par Julien Jorge (site web personnel) . En réponse au lien Mais la revue de code, ça sert à rien ?. Évalué à 8.
Je te rejoins complètement, et ce n'est pas le seul truc qui me chiffonne dans cet article.
Ça c'est n'importe quoi aussi. J'ai vu un paquet de fois des belles planifs sur tableau blanc tomber à l'eau dès la première ligne de code. Croire qu'on peut résoudre toutes les questions d'implémentation sans coder, et que si ça ne marche pas c'est qu'il fallait réfléchir mieux, c'est se fourvoyer. C'est même la raison pour laquelle on ne fait plus de cycle en V.
Pour moi la question de la conception doit se faire « en gros », et le moment du chiffrage est un bon moment pour échanger là dessus : on communique sur les approches et on élimine les plus gros problèmes.
Les daily/le stand-up sert à remonter les soucis qu'on rencontre sur le terrain : on communique sur les problèmes, on les élimine ou on les contourne.
La revue sert à partager l'information et affiner des détails : on communique sur comment les choses sont faites en pratique. C'est autant au bénéfice du relecteur que du codeur.
Dans toutes les boîtes où je suis passé ces trois étapes étaient la raison pour laquelle les projets étaient fluides. Trois points de synchro pour communiquer et le reste du temps on est bien tranquille. Les seuls soucis que j'ai eu étaient des galères d'humains de mauvaise volonté qui se pointaient au stand-up en râlant à propos du commercial (c'est pas le sujet) ou du patron (toujours pas le sujet), ou encore des gens qui ne voulaient pas retoucher à leur code crado en revue parce que « boaf, ça marche comme ça », voire des héros fiers bloqués en refusant d'échanger à propos de leurs galères. Au final ça me semble simple : si tu joues en équipe, ça marche bien, sinon c'est la merde.