Quand la taille d'une équipe dépasse 10, pouvez-vous quand même faire la planification des versions ensemble?

Lorsque vous décidez sur quoi travailler pour la prochaine version et que vous estimez les délais pour chaque user story (et les sous-tâches pour une story donnée), faites-vous cela en groupe ou simplement des managers?

Pour une équipe de 10 personnes, est-ce pratique?

Combien de temps cela prend-il?

La hiérarchisation doit être effectuée par un seul propriétaire de produit avec la contribution des différentes parties prenantes, y compris un développeur senior qui est une partie prenante du code et aussi responsable des exigences non fonctionnelles qu'un acteur commercial l'est pour les exigences fonctionnelles.

L'estimation doit absolument être faite par les personnes qui feront le travail, jamais par un gestionnaire qui est sous pression pour livrer, mais votre instinct est correct que plus d'une demi-douzaine de personnes passeront des heures à discuter de cela. Dans un monde idéal, vous devriez vraiment diviser l'équipe de manière à ce qu'il n'y ait pas moins de 4 et pas plus de 7 dans une seule équipe - 5 est idéal, à mon humble avis.

Si cela n'est absolument pas possible, pour une raison quelconque - et vous devez appliquer 5 pourquoi à cette raison avant d'accepter que c'est impossible - alors une équipe de 4-5 personnes devrait être sélectionnée par l'équipe pour faire des estimations en leur nom.

À mon avis, vous ne devriez PAS faire de planification des versions en équipe de 10 personnes. Très probablement, vous vous retrouverez avec une réunion géante où, dans une discussion donnée, 6-8 personnes se sentiront complètement déconnectées et ennuyées. Ajoutez à cela l'épuisement de 3-4 heures étant enfermé dans une pièce ensemble. Et considérez que si 10 personnes parlent, vous avez beaucoup trop de conversations. S'ils ne parlent pas, vous n'obtiendrez peut-être pas de précieuses informations.

Nous avons fait quelque chose de très similaire à l'entreprise de Joseph. La version précédente, nous avions 8 ingénieurs et la planification de la version a pris 2 semaines solides. Et c'était absolument brutal. Quelques heures après le début de la journée, je pense que nous commençons tous à essayer de parler le moins possible afin que la réunion se termine plus tôt.

Cette version de notre équipe a plus que doublé. Nous nous sommes donc divisés en équipes plus petites qui s'approprieraient en permanence une zone d'un produit. Chacune des petites équipes avait une avance. Ensuite, nous avons fait une planification de version de haut niveau avec uniquement les leads, ce qui est allé beaucoup plus vite et plus efficacement car maintenant nous n'avions que 4 développeurs dans une salle. Pendant ce temps, nous avons identifié quelle équipe ferait quelles histoires et comment le produit sera divisé. Cela a également donné aux prospects une image plus large de l'ensemble du produit.

Ensuite, chaque lead est retourné à sa propre équipe et a passé en revue la partie de la version dont seule cette équipe était responsable. Pendant ce temps, nous avons rempli certains détails et attribué des valeurs de points d'histoire.

Enfin, tout a été mis en place et nous avons fait une dernière visite (plus une présentation qu'une discussion) afin que tout le monde dans l'équipe sache ce qui se passe avec toute l'équipe.

Bien que nous n'ayons pas eu une version complète avec succès avec cette méthode, je pense que la planification globale des versions s'est déroulée de manière plus fluide qu'auparavant et nous en avons tiré beaucoup plus. La clé était que nous n'avions jamais eu plus de 3-4 développeurs dans une réunion donnée et que la voix de tout le monde était toujours entendue.

Si possible, je vous recommande de diviser vos 10 développeurs en 3 groupes. Si vous ne pouvez pas diviser votre version globale en 3 zones qui ne se chevauchent pas, alors même 2 groupes seraient mieux qu'une grande équipe.

Je fais en fait partie de plusieurs projets (et de plusieurs équipes) en tant que chef de file, et il y en a quelques-uns qui sont 10+. Sur presque tous les projets sur lesquels je travaille, la planification des versions est effectuée par les leads et les analystes métier. Cependant, dans notre situation, les BA ne sont pas les gestionnaires, donc les gestionnaires ne participent pas vraiment à la planification des versions.

L'estimation est faite par l'équipe de mise en œuvre, cependant, et bien que les deux parties soient séparées, elles sont très liées.

L'estimation correspond au temps nécessaire à l'exécution d'une tâche, tandis que la planification de la version correspond au moment où ces tâches doivent être planifiées.

La planification doit être effectuée en fonction des préoccupations commerciales, tandis que l'estimation doit être effectuée en fonction des préoccupations techniques. D'où l'éclatement de l'estimation et de la planification.

Cette tâche est effectuée plus efficacement par un gestionnaire. Dans les petites équipes, les rôles ont tendance à se confondre. Tout le monde est impliqué dans tout. Mais à mesure que votre équipe se développe, cela devient ingérable et les rôles doivent être clairement définis.

Autant j'ai le désir de m'impliquer dans tout, mais ce n'est pas productif.