Quelle pourrait être une bonne activité de consolidation d'équipe pour améliorer les compétences d'estimation? [fermé]

9

Je prépare une présentation à livrer à certains de mes coéquipiers (tous les développeurs), et j'aimerais inclure une courte activité de consolidation d'équipe qui se concentre sur l'amélioration des compétences d'estimation. Quelqu'un a-t-il des suggestions ou connaît-il des activités de consolidation d'équipe que je pourrais utiliser?

estimation team-building Rob
la source
2
L'amélioration de l'estimation n'est pas quelque chose qui peut être fait avec une courte activité. Cela doit être un effort à long terme pour suivre vos estimations, les temps réels et une sorte de post-mortem pour déterminer pourquoi l'estimation et le temps réel étaient différents. C'est aussi une compétence qui se développe au fil du temps - vous vous améliorez en estimant et en apprenant de vos erreurs grâce à l'analyse.
Thomas Owens
Avez-vous un problème? Quelle est la précision de vos estimations et devriez-vous prendre le temps de les améliorer?
JeffO
@Thomas Owens, je suis conscient que ce n'est pas quelque chose qui peut être fait avec une courte activité. J'essaie simplement de faire prendre conscience de l'importance de développer de bonnes compétences d'estimation. J'aurais dû être plus précis dans ma question.
Rob
2
@Jeff O, pas de problème - ce sont de nouvelles recrues, certaines avec moins d'expérience, et je veux les aider à travailler sur l'estimation en général.
Rob

Réponses:

8

Consultez la planification basée sur des preuves de Joel On Software , c'est un moyen assez simple pour les gens de comprendre comment estimer plus précisément.

La meilleure façon d'apprendre à estimer est d'avoir de bonnes exigences, de la pratique, de la pratique et de la pratique. Leur enseigner des choses comme la planification basée sur des preuves aidera la pratique à être plus efficace, mais rien ne peut remplacer la pratique réelle.

Malfist
la source
Je m'aime un peu d'EBS (je suis un fervent utilisateur de FogBugz). Je n'ai pas pensé à l'utiliser comme exemple, cependant - bonne suggestion. Je vais m'en inspirer.
Rob
6

Présentez un exemple de problème avec Minecraft.

Le client a besoin d'une pyramide à degrés marron de 20x20 blocs. La pyramide a également besoin d'un fossé d'au moins 10 blocs de large.

Donnez-leur 3 minutes pour esquisser un WBS simple et une estimation.

Après 2 minutes, dites que le client a changé d'avis et qu'il a besoin d'une pyramide 30x30 maintenant. Dites-leur de réviser leurs estimations dans la minute restante.

À la fin du temps, dites-leur de poser leurs crayons et dites maintenant que les développeurs commencent à travailler sur le projet, mais le client est confus car il n'y avait pas de pont traversant les douves.

Dites-leur que le pont mettrait X heures à se développer et demandez à tous ceux qui ont sous-estimé de se lever.

Cela ramènera le point à la maison.

maple_shaft
la source
2
J'aime ça, mais si vous n'êtes pas familier avec Minecraft, je ne sais pas comment vous pourriez arriver à une estimation qui a du sens. Comment quantifieriez-vous le temps qu'il faut pour construire une pyramide à degrés marron?
Rob
1
@Thomas Owens, je pense que le point maple_shaft est d'impressionner les développeurs sur l'importance de découvrir ces types d'exigences. En tant que consultant, j'ai personnellement vu de nombreux exemples de choses ridiculement évidentes qu'un utilisateur aurait dû demander, mais ne l'a pas fait, car il ne réalisait pas que c'était ce dont il avait besoin. Moi-même et mes développeurs sont tous des consultants, et dans notre situation actuelle, nous n'avons pas le luxe d'ingénieurs de bonnes exigences, c'est pourquoi j'essaie de les inciter à poser ces types de questions de découverte à leurs clients pour aider à améliorer leurs estimations. .
Rob
2
@ unfgiven3 Cela n'a cependant rien à voir avec l'estimation. Le travail d'ingénierie des exigences peut incomber à un développeur, mais vous ne pouvez baser vos estimations que sur des exigences connues. L'amélioration de votre capacité à analyser, vérifier, valider et découvrir les exigences est dissociée de l'amélioration de votre capacité à estimer le temps qu'il faudra pour effectuer une tâche. Les exigences changent, les estimations changent donc, mais il est impossible d'estimer ce que vous ne savez pas et vous ne devriez pas essayer.
Thomas Owens
1
@Thomas Owens, je suis d'accord qu'il est impossible d'estimer ce que vous ne savez pas - ce qui est précisément mon point - vous devez découvrir les exigences pour une fonctionnalité et valider les hypothèses à ce sujet comme condition préalable à la création d'une estimation décente. Je suis d'accord, cependant, après un certain examen, qu'il est disjoint d'améliorer sa capacité d'estimer - peut-être que concentrer l'activité sur la découverte des besoins serait plus immédiatement utile qu'une activité d'estimation. Bons points - ils me font définitivement penser que je me concentre peut-être sur la mauvaise compétence à améliorer.
Rob
1
@ unfgiven3 Un bon ingénieur devrait toujours travailler à améliorer les deux. J'ai été dans une position où je n'étais pas chargé de l'ingénierie des exigences, mais on m'a remis une spécification qui avait ce que je voyais être des problèmes. Avoir la capacité de les voir et de poser les bonnes questions est essentiel pour quiconque développe un logiciel, et il faut y travailler. Cependant, lorsque je fais des estimations, j'ai toujours basé mes estimations sur les spécifications, même s'il y a des questions. Je laisse juste une plus grande fenêtre d'erreur (donnant 75% de chances au lieu de 85%, ou donnant une fenêtre légèrement plus grande).
Thomas Owens
1

Je suggère un générateur / solveur de labyrinthe pour les points suivants:

  • C'est amusant à faire
  • Vous ne pouvez pas penser à tous les cas pour la première fois
  • La génération et la résolution des problèmes sont assez complémentaires
  • Cela couvre du back-end avec sauvegarde des données au front-end avec chargement des données
  • De nombreux points peuvent être attribués aux personnes: spécification de fichier, affichage, génération, résolution, optimisation, test etc ...
Whiskas
la source
1

Vous pouvez jouer le "Combien de temps vous faudrait-il pour écrire ceci?" Jeu. Semblable à un groupe de personnes se vantant de la façon dont elles peuvent se rendre à Las Vegas en X heures (où le nombre X diminue généralement avec chaque fanfaron jusqu'à ce que quelqu'un affirme pouvoir le faire en moins d'une heure). Donc, pour les codeurs: jetez un objectif simple et voyez ce que chaque individu dit et s'il y a un consensus du groupe ou des opinions marquantes. Combien de temps vous faudrait-il pour écrire Hello World? Que signifie "écrire", cela signifie-t-il aussi "exécuter" et "tester"? Faut-il d'abord un environnement de simulation? Sur quelle plateforme et quel compilateur croisé et les outils sont-ils déjà installés et prêts? etc etc .. "Hello world" peut prendre 4 jours pour "écrire" sur une plateforme embarquée (installer les outils, préparer la plateforme,

Une fois que l'équipe a fini de décider de la durée de l'objectif, mesurez le temps nécessaire (peut-être pas pour l'objectif suggéré mais pour un objectif similaire dans le monde réel) ou rappelez-vous un projet précédent avec un objectif très similaire. Comparez l'estimation à la réalité. Exagérez énormément l'erreur entre l'estimation et la réalité et publiez une conclusion pour tous.

Jonathan Cline IEEE
la source