用户故事的时间估算
您如何估计实施用户故事所需的时间？ 如果您在知道需要多长时间之前就已经完成了某件事。 但如果它对你来说是全新的呢？ 你预留多少时间来给“惊喜”？
How do you estimate the time needed to implement a user story? If it's something you had done before you know how long it'll take. But what about if it's completely new to you? How much time do you reserve for "surprises"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一个很好的技巧是将故事分解为更小的任务，然后对它们进行相互比较（而不是绝对）。 所以你可以说：
我们更擅长估计相对复杂度而不是绝对复杂度复杂。 然后，您实际执行其中一项任务，并计算出执行 1 个单元需要多少“实时”时间 - 现在您可以计算所有任务。 您根据进展情况不断更新您的估计。
这项技术来自 Mike Cohn 的敏捷估算和规划，这是一本很棒的书就此主题而言。
A great technique for this is to break the story down to somewhat smaller tasks, and estimate them compared to each other (instead of absolutely). So you can say:
We're better at estimating relative complexity than absolute complexity. Then you actually perform one of the tasks, and figure out how much "real time" it takes you to implement 1 unit - now you can calculate all the tasks. You keep updating your estimates according to how you progress.
This technique is from Agile Estimating and Planning by Mike Cohn, which is a great book on the subject.
在敏捷开发的 XP 学派中，他们提倡不要以实际时间而是以任意单位进行估计。 （他们使用“小熊软糖”，但你可以使用任何东西）。 您可以对实现该用户故事所需的单元数量进行最佳猜测。
确实，您可能是错的，但是您将在开发过程中进入一个阶段，进行几次迭代，此时您的猜测大部分是正确的，并且企业/客户可以轻松获得他们可以包含多少个故事的准确预算在一次迭代中。
当早期难以估计时，一个好的经验法则是选择最简单的任务之一，并将其分配为 1。评估与该任务相关的每个其他用户故事，并给出您的最佳猜测。 如果某件事太复杂，或者定义不够明确，你将被迫给它一个非常大的数字。
另一个关键概念是，您必须在每次迭代中重新评估每个用户故事的时间。 随着您的故事得到更好的定义，并且随着您对速度的估计提高，您将获得更准确的故事时间。
至于惊喜，它并不真正影响用户故事的估计......因为你没有用户故事来代表惊喜。
In the XP school of agile development, they advocate that you don't estimate in actual time but in arbitrary units. (They use "Gummy Bears" but you can use whatever). You assign your best guess as to the number of units it will take to implement that user story.
True, you might be wrong, but you will hit a phase in your development, a few iterations in, when your guesses are mostly right, and it is easy for the business/customer to get an accurate budget of how many stories they can include in an iteration.
A good rule of thumb early on when it is hard to estimate, is to take one of your easiest tasks, and allocate that at a value of 1. Evaluate each other user story in relation to that one, and give your best guess. If something is too complicated, or not clearly defined enough, you will be forced to give it a really big number.
Another key concept is that you must re-evaluate the times for each user story every iteration. As your stories get better defined, and as your estimation of your velocity improves, you will get more accurate times on your stories.
As for surprises, it doesn't really bear on the estimation of user stories... since you don't have user stories to represent surprises.
Steve McConnel 在“软件估算 - 揭秘黑术”中说得比我好：
第 7 章 - 计数、计算、判断 (PDF) （
谢谢你提醒我这一点：）
Steve McConnel in "Software estimation - demystifiying the black art" said it better than I would:
Chapter 7 - Count, Compute, Judge (PDF).
(thanks for reminding me of this :)
在我工作的地方实施的一项技术。
对于每个用户故事，将其写在一张带有标题的卡片上。让每个人拿一张卡片，并在上面写下他们认为完成该任务所需的小时数。 让他们根据任务放置卡片，但不要互相展示。 获得所有结果后，查看数字并查看顶部和底部值。您通常会得到彼此非常接近的数字。
对于那些远高于或远低于平均值的值，请询问开发人员或提供信息的人员，为什么他们认为与平均值相比需要这么长或这么短。 团队而不是个人达成共识意味着每个人都对任务有自己的看法。
这是我读过的一本关于敏捷技术的书中的一个想法，但忘记了作者是否将其归功于他们。
A technique implemented where i work.
For each user story write it on a piece of card with a heading.Get each person to take a card and write on it the number of hours they think it will take to complete. Get them to place the cards against the task without showing them to each other. Once you have all the results in look at the figures and see the top and bottom values.You will normally get figures quite close to each other.
For those values way above or way below ask the developer or person with the input why they think it would take so long or so short compared to the average. Coming up with a concensus from the team as opposed to an individual means everyone gets their take on the task.
This is an idea from a book I read on agile techniques and have forgotten the author to credit them with it.