The estimates have to be made with the knowledge of who is going to do the tasks.
Otherwise they make no sense.
Developer: "I can drive from Toronto to Los Angeles in 17 hours" (that's two random cities in the world and a 110% made up number, don't sue me if it isn't even possible to drive between those two cities)
Manager: "Ok, then I'm going to give you this old rusty kids bike. See you in Los Angeles in 17 hours"
Obviously that's not going to work.
So the estimates have to be made after it has been decided who's going to work on the tasks.
If not, you're going to have to build one big homogenous team, consisting of clones or something, that will all take the same amount of time as every other team member on a particular task.
Note, this is kinda the same problem of one person estimating a task, and another going is going to implement it. Unless the two are extremely familiar with each other (or at least the person estimating knows the other person 100%), you're going to get incorrect estimates.
All developers in the team should be involved when estimating a story. The estimate shouldn't depend on who's going to do the work. That's not even known at estimation time. We use Planning Poker wich is both fun and gives good results.
So then her and the developer she pairs with must choose to implement either his or her task. Based on that choice the work they perform is then counted toward the estimate that she made for the task. Is that estimate still valid, because it seems to be dependent on who she is working with?
Did I read this correctly? It appears to imply that:
John estimates it will take 2 days to build a Widget
Lisa estimates it will take 7 weeks to fix a bug
John and Lisa get together, and decide to work on the bug fixing.
7 weeks occur, and even though the widget isn't started, it gets 7 weeks booked against it.
I haven't read the XP book, but surely that can't be right?
If I get to work with Bob this will take 3 days, anyone else 5 days.
I'm not sure I understand the last part of the question, but when a pair get together its on the basis of one developer asking the other to pair. The developer who asks is asking that they work on his task, and they should only work on one task at a time. If they finish quickly, the pair breaks apart and goes their separate ways. If they take a long time, they may break up before the task is finished, and the original developer has to find someone else to pair with before being able to finish the task.
I didn't see a answer I could agree with, so here is a wiki describing how I now look at this issue.
Practically, the developer responsible for the task will come up with the estimate. Assuming that we can correct that estimate (based on history for that specific developer for example), we can deduce that the longest the task will take is her corrected estimate, since working in a pair will probably allow the developer to finish either on time using her own expertise or faster with the help of the person she is paired with. So in the worst case the estimate is too long, allowing for some slack.
发布评论
评论（6）
我配对时的基本规则之一：
永远不要将裂缝与初学者配对。 伙伴们的技能必须相当。 否则，你会表现不佳、沮丧和麻烦。
因此，无论是谁做的，估计结果或多或少都应该是现实的。
我个人的意见。
One of my basic rules when pairing:
Never ever pair a crack with a beginner. The buddies must be comparable in skill. Otherwise, you will get low performance, frustration and trouble.
So the estimate should come out more or less realistic - no matter who did it.
My personal opinion.
必须在了解谁将执行任务的情况下进行估计。
否则它们就没有意义。
开发者：“我可以在 17 小时内从多伦多开车到洛杉矶”（这是世界上两个随机城市，并且是 110% 的虚构数字，如果甚至无法在这两个城市之间开车，请不要起诉我）
经理：“好吧，那我就送你这辆生锈的儿童自行车。17 小时后洛杉矶见”
显然这是行不通的。
因此，必须在决定由谁来执行这些任务后才能进行估算。
如果没有，你将不得不建立一个由克隆人或其他东西组成的大型同质团队，这将与其他团队成员在特定任务上花费相同的时间。
请注意，这与一个人估计一项任务，而另一个人去实施它的问题有点相同。 除非这两个人彼此非常熟悉（或者至少估计的人 100% 认识对方），否则您将得到错误的估计。
“我估计鲍勃会花 2 个小时来完成这个”
就像那永远会飞一样。
The estimates have to be made with the knowledge of who is going to do the tasks.
Otherwise they make no sense.
Developer: "I can drive from Toronto to Los Angeles in 17 hours" (that's two random cities in the world and a 110% made up number, don't sue me if it isn't even possible to drive between those two cities)
Manager: "Ok, then I'm going to give you this old rusty kids bike. See you in Los Angeles in 17 hours"
Obviously that's not going to work.
So the estimates have to be made after it has been decided who's going to work on the tasks.
If not, you're going to have to build one big homogenous team, consisting of clones or something, that will all take the same amount of time as every other team member on a particular task.
Note, this is kinda the same problem of one person estimating a task, and another going is going to implement it. Unless the two are extremely familiar with each other (or at least the person estimating knows the other person 100%), you're going to get incorrect estimates.
"I estimate Bob will use 2 hours on this"
Like that's ever going to fly.
评估故事时，团队中的所有开发人员都应该参与其中。 估算不应取决于谁来完成这项工作。 在估计时甚至还不知道这一点。 我们使用计划扑克，它既有趣又效果良好。
All developers in the team should be involved when estimating a story. The estimate shouldn't depend on who's going to do the work. That's not even known at estimation time. We use Planning Poker wich is both fun and gives good results.
我读对了吗？ 这似乎意味着：
我没有读过 XP 书，但这肯定不对吧？
Did I read this correctly? It appears to imply that:
I haven't read the XP book, but surely that can't be right?
您可以创建相关估计：
如果我与 Bob 一起工作，这将需要 3 天，其他任何人都需要 5 天。
我不确定我是否理解问题的最后一部分，但是当一对开发人员聚集在一起时，它是基于一个开发人员要求另一个开发人员进行配对的基础上的。 提出要求的开发人员要求他们执行他的任务，并且他们一次只能执行一项任务。 如果他们很快结束，两人就会分手并分道扬镳。 如果时间较长，可能任务还没完成就分手了，原来的开发者就得找其他人结对才能完成任务。
You can create dependent estimates:
If I get to work with Bob this will take 3 days, anyone else 5 days.
I'm not sure I understand the last part of the question, but when a pair get together its on the basis of one developer asking the other to pair. The developer who asks is asking that they work on his task, and they should only work on one task at a time. If they finish quickly, the pair breaks apart and goes their separate ways. If they take a long time, they may break up before the task is finished, and the original developer has to find someone else to pair with before being able to finish the task.
我没有看到我可以同意的答案，所以这里有一个 wiki 描述我现在如何看待这个问题。
实际上，负责该任务的开发人员会提出估算。 假设我们可以纠正该估计（例如，根据该特定开发人员的历史记录），我们可以推断出该任务将花费的最长时间是她的纠正估计，因为两人一起工作可能会让开发人员按时完成使用她自己的专业知识或在与她配对的人的帮助下更快。 因此，在最坏的情况下，估计值太长，需要留有一定的余量。
I didn't see a answer I could agree with, so here is a wiki describing how I now look at this issue.
Practically, the developer responsible for the task will come up with the estimate. Assuming that we can correct that estimate (based on history for that specific developer for example), we can deduce that the longest the task will take is her corrected estimate, since working in a pair will probably allow the developer to finish either on time using her own expertise or faster with the help of the person she is paired with. So in the worst case the estimate is too long, allowing for some slack.