FogBugz 估计和结对编程
我使用 FogBugz 作为工具来让我们“展望未来”。 该程序会记录我们的工作时间、发布的任务、分配的开发人员对该任务的估计以及开发人员低估/高估的倾向，并尝试提出针对未来一系列日期进行发布的概率。
现在，由于 FogBugz 考虑了工作时间，因此它假设开发人员会将时间投入到分配给他们的任务中，这在 XP 中并非如此，因为两人之前的决定是处理开发人员的其中一个任务一起。
这是否意味着我在进行结对编程时不能使用 FogBugz 进行估计？
I am using FogBugz as a tool to give us "a look into the future". The program takes our work hours, the tasks for a release, assigned developer's estimate against that task, and the developers tendency to under/over estimate, and tries to come up with a probability of making the release against a range of dates in the future.
Now since FogBugz takes into account the work hours, it assumes that the developers will put in the hours into the tasks they are assigned, which is not true in XP because the earlier decision of the pair was to work on one of the developers' tasks together.
Does this mean that I cant use FogBugz for estimates when doing pair programming?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在这种情况下，我要做的就是让每个开发人员估计他的每个发布案例，以结对编程时完成发布所需的工作时间表示（即与实际处理该案例的合作伙伴花费的时间）。 然后计算出您在自己的任务上与在其他人的任务上花费多少时间进行结对编程，并将您的工作计划中的“在 FogBugz 任务上花费的时间百分比”设置为您在自己的任务上花费的时间的大致百分比。
然后，当您正在处理任务时，将自己标记为“正在处理 ->” 案例 ID，当您正在处理其他人的任务时，设置正在处理 -> 没有什么。
实际上有很多不同的方法可以让它发挥作用（根据具体情况，这里的其他答案可能会更好），但这就是我要做的。
What I would do in this case would be to have each developer estimate each of his cases for the release expressed in working hours it will take to complete it while pair programming (that is, time spent with a partner actually working on that case). Then figure out about how much time you spend pair programming on your own tasks vs. on someone else's tasks, and set your "% time spent on FogBugz tasks" on your Working Schedule to the approximate percentage of time you spend on your own tasks.
Then, when you're working on your tasks, mark yourself as Working On -> case ID, and when you're working on someone else's tasks, set Working On -> Nothing.
There are actually a lot of different ways to get get this to work (and the other answers here might be better depending on the circumstances), but that's how I would do it.
如果两个程序员一起工作，那么出于所有实际目的，他们就像一个有两个头脑的程序员，不是吗？ 为什么不在 FogBugz 中创建另一个代表他们的用户帐户呢？ 然后他们还应该一起做出估计。 这实际上可能会提高精度。
If the two programmers are working together, then for all practical purposes they are like one programmer with two heads, no? Why not create another user account in FogBugz that represents them both? They should then also produce their estimates together. That might actually increase precision.
我没有任何 FogBogz 经验，但我会说“尝试一下”。 FogBogz 中时间估算的要点在于，该软件会从经验中学习，并据此自动修正估算。 这是一个非常强大的机制，因为在实践中，大多数人的估计都值得下注。 看看 FogBugs 是否也能处理配对估计会很有趣。 我预计误差范围会高一些，但也许估计值仍然可用。
I don't have any FogBogz experience but I'd say “give it a try”. The whole point of the time estimates in FogBogz is that the software learns from experience and automatically corrects estimates based on this. This is an incredibly strong mechanism because in practice, most people's estimates are worth squat. It'd be interesting to see if FogBugs can also cope with pair estimates. I expect the error margin to be quite a bit higher but perhaps the estimtates are still usable.
我没有这方面的经验，但直觉会告诉我“这取决于”
详细说明 - 假设你有 2 个程序员，John 和 Bob，都拥有 FB 帐户：
John 总是与 Bob 配对编程吗？
- 约翰的估计应该与他的实际完成时间一致。 即使他根据自己的想法进行估计，“速度”计算也应该弥补这一点。
约翰是否有时与鲍勃结对编程，有时自己进行结对编程？
- 如果约翰提前知道哪些项目将配对，哪些不会配对，他将相应地调整他的估计。 他们可能仍然是错的，但是速度计算应该还是可以的？ 或许？
John 是否与各种各样的合作伙伴进行结对编程？ （可选地包括单独编程）
- 你完蛋了。 对于 John 来说，动态中的变量太多，无法做出任何有用的估计，更不用说 FB 或任何其他东西（或任何人）来补偿它们了。
I don't have experience with it, but intuition would tell me "it depends"
To elaborate - Say you have 2 programmers, John and Bob, both with FB accounts:
Does John always Pair-Program with Bob?
- John's estimates should be consistent with respect to his actual completion times. Even if he does his estimates based on what he alone thinks, the 'velocity' calculations should make up for this
Does John sometimes Pair-Program with Bob, and sometimes by himself?
- Provided John knows ahead of time which projects will be paired, and which won't, he will adjust his estimates accordingly. They might still be wrong, but the velocity calculations should probably still be ok? maybe?
Does John pair-program with a wide variety of partners? (optionally including programming alone)
- You're screwed. There are too many variables in motion for John to be able to produce any kind of useful estimates, let alone for FB or anything (or anyone) else to compensate for them.