Im le contexte de la programmation par paire ... comment jugez-vous? Une histoire de 5 points ... divisée en 3 tâches ... chaque tâche étant essaimée par 2 membres. Cela veut-il dire que cela signifie qu'il est finissable dans la moitié du temps?Estimation agile/XP
Vous estimez l'utilisation de points. Le nombre de points pouvant être obtenus par une paire est appelé vitesse. Cochez ceci: http://en.wikipedia.org/Planning_poker
La plupart des méthodologies Agile suggèrent que vous devriez estimer en points. Cependant, il y a beaucoup d'équipes qui réussissent - y compris plusieurs équipes Kanban avancées et très productives - qui évaluent en quelques heures. Les points viennent avec leurs propres jeux, incitations perverses et problèmes. YMMV. Quoi qu'il en soit ...
J'ai entendu des chiffres de 25% plus dev-heures pour une paire effectuant une tâche. Ainsi, la tâche serait terminée dans 62,5% du temps, en utilisant deux développeurs au lieu d'un. Cependant, la qualité et le partage des connaissances augmentent souvent aussi. Puisque les bogues = retravailler et retravailler prennent plus de temps que de le faire de la bonne façon la première fois, la programmation par paire est généralement payante. Cela diffère pour différentes tâches et différents niveaux de compétences, par exemple: corrections de bugs simples, programmeurs débutants, etc.
D'après mon expérience, 2/3 du temps est un très bon chiffre approximatif. C'est plus long que 1/2 mais moins que ce serait avec seulement 1 personne.
Sallyann Freudenberg est un bon nom à rechercher en ce qui concerne la recherche de programmation par paire. Vous pouvez également consulter les refs sur la page Wikipedia: http://en.wikipedia.org/wiki/Pair_programming
Le chiffre est surtout confirmée par les données dans ce rapport Alistair Cockburn et Laurie Williams: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
estime Paire combien de temps il va prends les. Toute estimation est basée sur l'expérience - plus l'équipe d'expérience a de l'expérience avec le projet, avec la technologie et en travaillant ensemble en binôme, plus les estimations seront bonnes. Tous les pourcentages arbitraires comme ajouter 25% pour les paires, etc. ne sont utiles qu'au tout début - avec un nouveau projet et une nouvelle équipe sur une nouvelle technologie - où vous n'avez encore rien d'autre à baser sur l'estimation. Dès que l'expérience commencera à se développer, les estimations s'amélioreront.
Rappelez-vous cependant, qu'ils ne sont que cela - estimations, qui est notre meilleure estimation du futur dérivé avec l'aide de l'expérience et de la connaissance de notre compréhension du présent. C'est comme les prévisions météorologiques - plus nous avons de données, plus les prévisionnistes ont de l'expérience, mieux c'est, mais ce n'est qu'une prédiction, pas une réalité.
C'est pourquoi les points sont si grands, car ils vous aident à estimer un paramètre que vous pouvez - combien "gros" les tâches sont à portée de main.
Je souligne toujours dimensionnement de l'histoire sur l'estimation. Si vous pouvez minimiser la variation de taille entre les histoires, les estimations deviennent beaucoup moins intéressantes. Autrement dit, les activités d'estimation perdent de leur valeur lorsque la différence de taille entre deux histoires est faible, ce qui permet aux équipes rapides de récupérer le coût de l'estimation et de l'orienter vers quelque chose de productif (comme le produit de construction). Dans cette optique, je suggérerais d'élaguer de manière proactive l'arriéré et de diviser les histoires à cinq points en plus petites (tranches verticales encore minces) chaque fois que possible. Jusqu'à ce que votre équipe soit expérimentée, je vous suggère de continuer à faire des estimations, mais d'obtenir une estimation par défaut de 1 point pour chaque carte, avec une vérification rapide du consensus ou une discussion pour savoir pourquoi justifier un 2 ou 3.Pour tout ce qui est clairement plus grand qu'un 3, je suggérerais que l'un des deux problèmes soit présent: la valeur de base de "1" est trop petite ou l'histoire devrait être divisée (soit plus spécifique ou suivie comme une épopée). À mesure que l'équipe établit une vélocité décente, l'activité peut, espérons-le, passer de l'estimation à la simple vérification de l'histoire. Autrement dit, la question lors de la planification de "quelle est la taille de cette histoire?" devient "cette histoire est-elle anormale?" La dernière question prend beaucoup moins de temps pour répondre.
Ceci est juste une extension du commentaire d'Amber (* En général - expérience *) mais montre comment y arriver. +1 – APC
1) Une manière simple et concrète de penser à l'estimation des unités est le nombre nombre de check-ins nécessaire pour compléter l'histoire . Si vous faites du TDD, de l'intégration continue et du refactoring, vous travaillerez en petits morceaux, en gardant le build vert et en vous enregistrant régulièrement, donc dans ces conditions, les check-ins simples peuvent être une unité significative d'estimation .
2) Vous pouvez également penser aux blocs de temps d'appariement ininterrompu en un jour, par ex. après la pause-café, après la pause-café, après le déjeuner jusqu'au milieu de l'après-midi, le milieu de l'après-midi jusqu'à l'heure du foyer - disons 4 périodes par jour ... disons 4 unités par jour. Cela vous donne une limite sur ce que vous pourriez vous attendre à faire dans une interaction ...
Personnellement, je vais pour le nombre de check-ins, parce que je peux esquisser à peu près les tâches impliquées et avoir une idée de check-in Nombres. La grande chose à propos du nombre de check-ins est que ce n'est pas grave si vous êtes en train de coupler ou non - vous suivez simplement ce que vous pouvez faire.
En général ... expérience. – Amber