Je travaille sur un énorme projet. Pendant que nous programmons, nous finissons par rencontrer des sessions de dimensionnement d'arriéré sans fin où tous les développeurs s'assoient avec les histoires d'utilisateurs de l'équipe et de la taille.
Scrum Doutes disent que ce processus prend trop de temps et que le temps de développement est gaspillé.
Ma question est de savoir combien de temps faut-il à la taille d'une histoire d'utilisateur en moyenne? Et quelqu'un a-t-il des conseils pour que ces sessions de dimensionnement vont plus vite?
6 Réponses :
Scrum est une méthodologie très cliente. Pour qui le livrerez-vous? Quelle est leur plus haute priorité? De plus, vous n'avez pas besoin de faire des histoires d'utilisateurs pour les articles qui sont peu susceptibles d'être effectués à tout moment. Bien sûr, ils doivent être effectués un peu de temps, mais vous n'avez tout simplement pas le temps maintenant.
Combien de temps dure votre sprint. Deux semaines? Passez deux heures sur les tâches du sprint avec vos développeurs. Assurez-vous que tout le monde a ses 60 à 70 heures de travail (ne jamais donner 80, ou vous ne ferez que bombarder ...), puis le maître Scrum peut vous concentrer sur des histoires d'utilisateurs. Si vous avez un arriéré, vous avez probablement besoin d'un responsable de produit dont le travail consiste à interfacer avec les clients et à gérer l'arriéré.
bref
Edit: Je pensais que vous écriviez des histoires d'utilisateurs, pas de dimensionnement. Ma faute! Cependant, les points 1 et 2 s'appliquent toujours.
Nous formatons une histoire d'utilisateur en environ 30 secondes à une minute.
Nous discutons des bases de ce que veut l'utilisateur. Très peu de temps est passé sur la façon dont il sera accompli. Si vous êtes trop loin dans la façon dont il est accompli, alors vous prenez une tâche de l'histoire, qui est une activité différente.
Le plus qui devrait être discuté sur le "Comment" pour l'histoire est des risques (comme l'histoire utilisant une technologie que personne de l'équipe n'a d'expérience acquise).
C'est la clé pour dimensionner ne pas prendre pour toujours. Vous n'êtes pas là pour concevoir toute l'histoire. Juste pour la dimensionner. Obtenez une idée de base de ce qui devra être fait et laisser cela à cela. Defiantly Ne finit pas par faire valoir la façon dont l'histoire sera faite à moins d'une différence de temps significative dans les différentes approches.
Après une brève discussion, tout le monde choisit un numéro (en utilisant des cartes Point d'histoire ou juste dans leur tête). Vous montrez ensuite le numéro et discutez de toutes les différences.
Après une courte période de discussion, un consensus doit être atteint.
Une autre chose clé est de ne pas avoir des histoires de taille qui ne sont pas dans l'épopée actuelle ou à venir. Scrum change trop vite à la taille de la taille de la taille d'une histoire pouvant être éliminée ou cassée.
Je ferais attention à ne pas dimensionner plus loin dans l'arriéré. Cela peut être très utile pour le PO d'avoir une idée de la coûteuse d'une histoire lorsqu'il donne la priorité au travail. De plus, si vous n'avez pas l'état d'arriéré estimé, le PO ne peut pas planifier / prédire les dates de libération approximatives pour les fonctionnalités futures basées sur la vitesse.
Comprendre l'histoire - Taille de l'histoire - Discutez de la différence - Reformalisation pour obtenir un consensus ------------- Comment ce processus pourrait-il être fait en 30 secondes? Nous passons habituellement 2-10 minutes pour chaque histoire en fonction de la complexité de l'histoire
Eh bien, puisque nous avons tous été sur le projet pendant un moment, nous savons généralement ce que l'histoire implique fondamentalement (alors comprendre l'histoire n'est pas difficile. Il suffit de le lire, qui prend environ 15-30 secondes.) Nous choisissons tous un numéro et montrez-le. Fréquemment, les chiffres sont les mêmes. S'ils sont alors nous avons terminé. S'ils ne sont pas, eh bien, j'ai dit 30 secondes à 1 minute. C'est là que le temps supplémentaire entre en place. La personne la plus différente du reste dit brièvement pourquoi ils ont voté comme ils l'avaient fait. Nous atteignons généralement rapidement un consensus.
Si cela vous prend trop de temps pour le faire, je dirais que vos histoires sont trop grandes ou que vous concevez quand vous devriez avoir un dimensionnement (bien que 2-4 minutes ne soit pas trop longue.)
1 minute; Plus que cela et vos histoires sont trop grandes. S'il y a beaucoup de discussions sur chaque histoire, votre SM a besoin d'aider votre PO à écrire des histoires plus petites / meilleures / concises.
EPICS que le PO veut avoir travaillé devrait être divisé en petits morceaux avant la réunion de planification du sprint. Je suppose que vous n'avez pas de bonnes histoires de bonne qualité à la taille et que votre PO pourrait avoir besoin d'aide pour obtenir cette pièce juste pour vous.
Je ne suis pas sûr de ce que vous entendez par "sessions de dimensionnement sans fin". Votre séance de planification de sprint pour un sprint de 2 semaines devrait être temporaire à quelque chose de temps sur quelque chose <= 4 heures. Pourquoi est-ce sans fin?
Si vous cassez la grande histoire en plus petits, vous avez plus d'histoires, ce qui signifie que le temps total consacré à l'estimation de l'histoire ne change pas.
Je ne trouve pas que pour être vrai. Tout comme une taille 8 ou 13 histoire est plus complexe à construire avec plus d'inconnues; Les estimer ont plus d'inconnues et conduit donc à plus de discussions. Les petites histoires comme une 3 ou une 5 sont assez coupées et à sec entraînent moins besoin de discussion en équipe et il y a moins de désaccord de taille.
Je suis d'accord avec les danseswithbamboo. Les plus petites histoires sont également beaucoup plus précises qu'une grande grande histoire. Il est également plus avantageux d'avoir des histoires plus petites pour une comparaison relative d'estimation.
C'est ce que je fais:
Limitez vos sessions de poker de planification à 5 développeurs. Essayez de choisir des représentants (expérimentés, pas expérimentés, grosse bouche, timide, etc.). Tournez-les souvent (ne choisissez pas la même chose à chaque fois).
S'il faut trop de temps pour décrire votre article d'utilisateur, cela signifie probablement que l'histoire de l'utilisateur a été mal écrite. Améliorez vos utilisateurs. Avoir des histoires d'utilisateurs bien écrits est très importante. Une histoire d'utilisateur typique doit être dimensionnée en moins de 3 minutes et deux cartes passent. Parfois, c'est beaucoup plus vite, parfois, il est beaucoup plus lent.
Si vous avez des histoires d'utilisateurs trop grandes (dans la quantité de travail), divisez-les. Si vous obtenez une estimation ci-dessus 13 "jours ouvrables", votre histoire d'utilisateur est le problème.
Si vous avez vraiment trop d'histoires d'utilisateurs, faites une priorisation avant les sessions d'estimation en fonction de la valeur de l'entreprise. Vous allez ajuster la priorisation plus tard. Je partage habituellement le projet est des composants à cause de cela. S'il y a encore trop d'histoires d'utilisateurs, vous aurez peut-être besoin d'être sous-effectif et vous devez créer une deuxième équipe.
Votre équipe estimera plus rapidement avec le temps
Timebox Vos sessions de poker de planification! Si cela dure trop longtemps, les développeurs impliqués s'ennuient et cela rend la réunion encore plus longue ... la littérature vous indique au Timebox à 4h. IMHO et avec ce que j'ai observé dans mes équipes de Scrum, c'est beaucoup trop, du moins dans les équipes européennes. Essayez 2x 1h avec une pause.
Si tout cela ne fonctionne pas, engagez un maître de Scrum expérimenté (plus de 3 ans à temps plein et maîtrise de Scrum actif dans une taille de projet similaire à votre guise). Si cela ne fonctionne pas après cela, arrêtez d'utiliser Scrum. Scrum peut être très destructeur dans certaines entreprises, en particulier dans le secteur public.
L'idée de faire tourner les développeurs grâce à la planification des sessions de poker me fait peur. Comment établissez-vous une vitesse crédible si ce n'est pas une équipe raisonnablement statique?
Comment établissez-vous une estimation crédible si ce sont toujours les mêmes développeurs qui estiment?
Votre session de planification pour un sprint de deux semaines ne doit pas prendre plus que 1 heure mais il n'est pas inhabituel qu'il faut 1 jour lorsque vous commencez avec Scrum. Juste pratiquer et ne pas laisser l'analyse La réunion de planification est, après tout, principalement une opportunité d'apprentissage , donc si vous vous concentrez sur la compréhension de ce que le travail doit être effectué (et combien de temps cela va prendre en tant que sous-produit) ne perdent pas vraiment la durée.
J'aime l'idée de dimensionnement t-shirt ... intelligente!
Scrum ne permet pas de prendre pour toujours. Scrum a des boîtes de temps pour chaque réunion qu'il doit mener.
À mon avis, cela n'utilise pas un but à prendre pour toujours. Scrum préfère respecter les délais. Si aucune décision n'a été faite à partir de ce qui est l'article de rétro-éclairé le plus crucial pour commencer, l'équipe choisit ensuite la plupart des articles (autant que l'équipe pensent qu'il peut livrer dans un sprint) et aller avec elle.
Il ne sert à rien de prendre pour toujours, sous le risque de se répéter, car cela ne conduira que de plus en plus de confusion parmi les membres de l'équipe de Scrum. N'oubliez pas que la direction n'a aucun rôle dans Scrum, ils sont donc «poulet», ils n'ont aucun droit de parler, même du PDG! Si le PDG a quelque chose à dire, il doit indiquer au propriétaire du produit, et c'est la responsabilité du propriétaire du produit de voir comment il peut avoir le meilleur retour de la valeur de ce qui est fait. Et il est le seul autorisé à interrompre un sprint, ce qui n'est généralement pas nécessaire en raison des sprints de courte durée.
Pourquoi avez-vous fait un wiki communautaire?
Je vote pour fermer cette question de déchargement car c'est une question de gestion de projet non spécifiquement liée au développement de logiciels.
Je vote pour fermer cette question comme hors-sujet car il ne s'agit pas de la programmation.