Planning Poker and wordy developers [fermé]

Mon équipe est composée de 4 développeurs; tous chevronnés et qualifiés. L'un d'eux est un gars verbeux et bien intentionné qui insiste pour définir la solution technique à nos histoires avant de déposer nos estimations avec Planning Poker. Il refuse d'estimer s'il n'a pas une idée approximative de la solution technique convenue (ce qui semble raisonnable, non?).

Le problème est que nos séances d'estimation prennent une éternité pour se terminer !! D'après votre expérience, comment gérez-vous ce genre de personnalité lorsque vous jouez au poker de planification?

Il semble aimer que les choses soient définies de manière formelle, donc un chronomètre serait une bonne idée, car la planification du poker est définie comme ayant défini des délais pour que les gens puissent parler.

Il a également une mauvaise idée de l'estimation, tout le monde estime par rapport à l'histoire et non à la mise en œuvre , c'est pourquoi vous obtenez une telle variance. Par exemple, certaines personnes peuvent ignorer un cadre ou une solution standard et commencer à écrire des choses à partir de zéro.

Votre membre de l'équipe a une personnalité d'analyste. Les analystes ont besoin de beaucoup d'informations pour prendre une décision. L'idée de la minuterie est la meilleure, mais sachez qu'il va éviter l'enfer de tout ce qu'il donne. Travaillez avec lui pour lui expliquer qu'il ne s'agit que d'une estimation précoce basée sur le problème PAS sur la solution. S'il veut poser des questions, demandez-lui de s'en tenir au problème et non à la solution. Vous devrez peut-être le couper ou l'ennuyer pendant un certain temps lorsqu'il continuera à dériver vers des solutions.

Assurez-vous de tenir les autres membres de l'équipe à ces mêmes règles afin qu'il ne se sente pas isolé. Les analystes sont une personnalité courante dans la programmation, vous pouvez donc très bien en rencontrer d'autres comme lui.

Il semble que votre collègue ne comprenne pas la différence entre l'estimation et l'engagement ou qu'il ne lui ait pas été communiqué pendant la formation. Et, puisque vous avez essayé d'attacher le problème à sa personnalité, il est possible que toute votre équipe ne le comprenne pas encore. (Mais ne vous inquiétez pas! La plupart de notre industrie ne le comprend pas. Agile est difficile!)

Lorsque nous disons que la taille d'une histoire est de X points, nous entendons en fait une distribution de probabilité. Si nos estimations sont correctes, l'histoire devrait prendre plus de 50% du temps (et les 50% restants, cela prendra moins de temps). Si votre collègue estime que, lorsque X unités de temps se seront écoulées, il lui sera demandé de faire une démonstration de l'histoire ou bien, cela changera son approche de l'estimation.

La planification du poker introduit une autre erreur: au lieu d'essayer d'épingler X, nous l'associons à une échelle discrète, l'échelle de Fibonacci (1, 2, 3, 5, 8, etc.) étant la plus populaire. C'est dire que la taille n'est pas autant que ce qu'elle est. Quand nous disons que la taille de l'histoire est de 3 points, nous disons vraiment "c'est X plus-moins une certaine variance et X est plus proche de 3 que de 2 ou 5."

Votre équipe pourrait tirer profit de la compréhension de l'imprécision de cet exercice et de la différence entre l'estimation et l'engagement. Si vous voulez / devez étudier ces concepts en profondeur, ce livre a cela.

Je peux voir d'où vient votre membre de l'équipe, mais il n'a clairement pas complètement compris le concept d'Agile et Planning Poker. Vous devez commencer par vous assurer que tout le monde comprend les concepts et le raisonnement qui les sous-tendent, puis ils doivent faire les choses par eux-mêmes.

Pour les équipes avec lesquelles je travaille, au début de chaque session de planification, je mets une minuterie de sable de 3 minutes sur la table. Je fais savoir à toute l'équipe que si à un moment donné ils sentent que la conversation devient une plongée profonde, ou non pertinente, ou de toute autre manière va au-delà de ce qu'ils estiment nécessaire pour estimer l'histoire en points d'histoire, alors n'importe qui dans l'équipe peut retourner la minuterie. Une fois le sable épuisé, l'équipe estime immédiatement.

Cette méthode permet à chaque membre de l'équipe de limiter la conversation, lorsqu'ils estiment que la conversation n'est plus utile pour estimer l'histoire en cours de discussion. En même temps, cela n'interrompt pas immédiatement la conversation, mais donne à tout le monde une indication visuelle que leur conversation doit se terminer dans les prochaines minutes, car nous allons ensuite voter.

Un autre outil que j'utilise pour aider à garder les sessions de planification concentrées est de s'assurer que tout le monde dans l'équipe a examiné les histoires en haut de l'arriéré au moins quelques jours avant la planification. L'idée est que si vous avez une liste de questions immédiatement après avoir lu les histoires, vous pouvez informer le propriétaire du produit des questions potentielles plusieurs jours avant, afin qu'il puisse clarifier l'histoire ou la critique d'acceptation pour, espérons-le, limiter la discussion ultérieure. Cela permet également aux gens de commencer à réfléchir à la conception potentielle de l'histoire, avant d'être en planification (et d'essayer de concevoir pendant la planification).