您如何预先评估敏捷项目？
在从事固定价格的软件开发项目时，我经常发现自己必须估计价格确定后、工作开始前（或开发初期）项目所需的总时间。不幸的是，这些类型的项目最好使用迭代/敏捷方法来开发，这意味着我们不会（也确实不能）进行完整的前期设计。
在典型情况下，我们会拥有一份具有 X 个功能和 Y 美元的合约。签订合同后，工程部门需要估计完成 X 功能所需的小时数。有几个可能的原因需要预先提供此信息，包括：
• Y 美元转换为可用的 Z 小时，因此我们必须确保时间(X)<=Z，也许可以通过缩小 X 的范围来实现
。交付日期已经确定，因此我们必须分配适当的资源来满足该日期。
Kelly Waters 对敏捷评估有一个有趣的看法：http:// /www.agile-software-development.com/2009/04/agile-estimating.html 不幸的是，这些是使用积分系统对难度的估计，并且不能转换为小时数。
在我看来，我们需要能够做以下两件事之一：
• 获得具有巨大灵活性的合同，以适应敏捷开发流程。
• 弄清楚如何为尚未设计的功能提供相当准确的预先估计。
在大多数情况下，第一个选项当然不是一个选项。 有人对如何在敏捷开发场景中生成预先估算有任何建议/指导吗？
或者，是否有人看到通过其他流程更改来解决我们的问题的另一种选择？
When working on fixed price software development projects, I frequently find myself having to estimate the total number of hours a project will take after the price is set, but before the work is started (or VERY early on in the development). Unfortunately, these types of projects are best developed using an iterative/agile method, which means that we don’t (and really can’t) do a complete up-front design.
In a typical scenario, we would have a contract that has X features and Y dollars. After contracting, the engineering department would then need to estimate the number of hours required to complete the X features. There are several possible reasons to need this information up front, including:
• The Y dollars translates to Z hours available, so we have to make sure that time(X)<=Z, perhaps by reducing the scope of X.
• The delivery date is set, and so we have to assign the appropriate resources to meet that date.
Kelly Waters has an interesting take on estimating agile here: http://www.agile-software-development.com/2009/04/agile-estimating.html Unfortunately, these are estimations of difficulty, using a points system, and do not translate to hours.
It seems to me that we need to be able to do one of two things:
• Obtain contracts that have a huge amount of flexibility in them to accommodate an agile development process.
• Figure out how to provide reasonably accurate up-front estimates for features that have not yet been designed.
The first option is of course not an option in most cases.
Does anyone have any advice/guidance on how to generate up-front estimates in an agile development scenario?
Alternatively, does anyone see another option for solving our problem through some other process change?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为每个客户都希望至少估算出实施给定数量的功能将花费他多少费用。我不同意有人说如果你使用敏捷就不能做到这一点。敏捷可以适应现实世界，客户想知道他们将在一个项目上花多少钱，或者至少有一个粗略的想法。
因此，至少有两种有记录的方法可以做到这一点，并且都在 " 中进行了描述迈克·科恩 (Mike Cohn) 的《敏捷估算和规划》一书，我强烈建议大家阅读。
在您的项目开始之前，请先将您的故事分解为任务，并以小时为单位估算每个家庭的情况。根据这些估计值进行预算计算。请记住，这些估计仅用于达到估计时间/预算。当项目开始时，团队应该像平常一样负责估算和创建任务。
在项目开始
使用历史数据。如果同一团队之前曾参与过具有类似技术的项目，那么您可以使用过去的团队速度来估算项目成本。
同样，有关如何执行此操作的更多详细信息，请阅读参考书。
I think every client wants to have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
So, there are at least two documented ways you can do this and both are described in the "Agile Estimating and Planning" book by Mike Cohn that i strongly advise everyone to read.
Before your project even starts do the exercise of breaking down your stories in tasks and estimate each home in hours. Do the budget math with those estimates. Keep in mind that these estimates will only be used to reach the estimate time/budget. When the project starts the team should be responsible for estimating and creating the tasks like normal.
Use historical data. If the same team has worked before on a project with similar technology then you can use the past team velocity to estimate the project cost.
Again, for more details on how to do this read the referenced book.
大的前期估算只是大的前期设计，附加了$$$。
你不这样做，那将完全违背整个敏捷范式。
敏捷可以是关于固定成本的，
你可以做的是设定一个日期，然后在迭代/冲刺中朝着它努力，让产品负责人决定在该日期之前完成什么是重要的。这样，1 或 2 周的 Sprint 就是固定成本，就像在大型预先设计中一样，它只是一个较小的固定成本。
敏捷方法论背后的整个前提是消除任意的截止日期和死亡行军，因为变化没有在合同和截止日期中得到考虑。 SCRUM 是有效的，是构建方法论的一个很好的起点，阅读它并按照它所说的去做，至少作为一个起点。
带有客户反馈和批准的短冲刺
为您提供一个起点来完善您的未来估计，并帮助您很快获得产品所有者和客户的信任，因为他们看到他们最重要的问题在很短的时间内得到解决。
Big Upfront Estimation is just Big Upfront Design with $$$ attached
You don't, that would go completely against the entire paradigm of agile.
Agile can be about Fixed Costs
What you can do is set a date and then work torwards it in iterations/sprints and let the product owner(s) decided what is important to get done by that date. In this way a Sprint of 1 or 2 weeks is a Fixed Cost the same way it would be in an Big Up Front Design would be, it is just a smaller fixed cost.
The entire premise behind agile methodologies is to do away with arbitrary deadlines and the death march that they become because change is not accounted for in the contracts and deadlines. SCRUM works, is a great starting point to build a methodology on, read about it and do what it says at least as a starting point.
Short Sprints with customer feedback and approvals
Give you a starting point to refine your future estimations upon, and helps you gain trust from the product owner and customer very quickly, because they see their most important concerns delivered in a very short amount of time.
敏捷中的固定价格为您提供了针对给定团队规模可以运行的迭代次数。敏捷的重点是最大化您在这些迭代过程中可以获得的价值。敏捷涉及范围管理。
因此，您实际上不应该进行预先估计。这意味着固定范围，如果您愿意的话，这与敏捷或反敏捷正好相反。
正如另一个答案中指出的那样，敏捷不是这样工作的，你需要一种新的合同。例如，请参阅 10 个敏捷合同 和/或 Google。
Fixed price in Agile gives you a number of iterations you can run for a given team size. The point of Agile is then to maximize the value you can get during these iterations. Agile is about scope management.
So, you actually shouldn't do upfront estimations. This would mean fixed scope which is the just the opposite of Agile or anti-Agile if you prefer.
Agile doesn't work like this, you need a new kind of contract, as pointed out in another answer. See for example 10 Agile Contracts and/or google.
您不应瞄准“整个”项目的合同，而应创建仅运行一两个月的合同。
设定一些非常低的目标，也许只有两三个功能。
向客户解释这是项目的发现阶段。如果没有这个阶段，您无法向他们提供整个范围的估计。给他们一个不准确的估计并不符合任何人的利益。
客户可以通过以下方式受益：
Instead of aiming for a contract for the "entire" project, you should create a contract that just runs for a month or two.
Set some very low goals, perhaps only two or three features.
Explain to the client this is a discovery phase of the project. Without this phase you cannot give them an estimate for the entire scope. It would be in no ones interest to give them an inaccurate estimate.
The client benefits in the following ways:
“你不这样做，那将完全违背敏捷的整个范式”：我认为这是非常不正确的。敏捷是基于常识的，如果不知道项目的大致成本是多少，没有人会投资项目：他们知道他们可能必须缩小范围才能满足最后期限或增加预算和/或延长最后期限以交付整个范围。在我公司的项目中，我们通过比较项目的规模来估计项目，并且还使用扑克规划来估计史诗。使用不确定性锥体，并且在不牺牲质量的情况下，我们在开始第一个冲刺之前的估计与现实相比最多大约有 50% 的偏差。随着我们建立敏捷专业知识（在准确性和获得首次估计的时间方面），我们将不断改进。
您不能指望营销部门赞助项目 3 个冲刺（最多 3 个月）才能了解其成本。
"you don't, that would go completely against the entire paradigm of agile": I think this is quite incorrect. Agile is common sense based and nobody would invest in project if they had no idea how much it would roughly cost: they understand they may have to cut scope to meet deadlines or increase budget and/or extend deadlines to deliver the whole scope. On my company projects, we estimate projects by comparing their size and are also estimating epics using poker planning. Using the cone of uncertainty, and without trading off quality, we are about maximum 50% off on our estimates prior to starting the first sprint compared to the reality. And we will improve as we build up our Agile expertise (on accuracy and time to get first estimates).
You can't expect marketing to sponsor projects for 3 sprints (so up to 3 months) to have an idea of how much it would cost.
如果您估计故事点中的积压项目（在您链接到的 Kelly Waters 文章中对此进行了讨论），那么问题就变成您希望您的团队在冲刺中交付多少个故事点。如果您的团队以前曾一起工作过，那么您应该能够对此进行猜测（也许用上限和下限来指示置信范围）。
如果团队以前没有一起工作过，那么您可以采取一些易于理解的故事并将其分解为详细的任务。这将为您提供一个工时数，您可以将其与您的故事点估计进行比较，以尝试预测您的速度。同样，上限和下限值的置信范围可能是合适的。
假设您的用户故事加起来有 150 个点，您预测您的团队每月可以交付 15-20 个故事点，那么工作将需要 7.5 - 10 个月（通过简单划分）。
这种方法的优点是您可以测量团队的实际速度，并将其与计划进行比较。重新估计时间表也应该非常容易，例如，如果您在几次冲刺后发现团队的速度实际上每月只有 10 个故事点，那么您可以轻松预测修改后的时间表。
请记住，团队速度确实会因多种原因而波动。在项目开始时，当团队仍在组建时，它通常较低。此外，团队此时很可能专注于基础设施问题，而不是提供功能。
If you estimate the backlog items in story points (which is discussed in the Kelly Waters article you link to) then the question becomes how many story points do you expect your team to deliver in a sprint. If your team has been working together before, then you should be able to take a guess at this (perhaps with upper and lower bounds to indicate a confidence range).
If the team haven't worked together before, then you can take a few well-understood stories and break them down into detailed tasks. This will give you a man-hours number and you can compare this against your story point estimates to try and predict your velocity. Again, a confidence range of upper and lower values is probably appropriate.
Let's suppose your user stories add up to 150 points, and you predict that your team can deliver 15-20 story points per month, then the work will take 7.5 - 10 months (through simple division).
The advantage of this approach is that you can measure the team's actual velocity, and compare it to the plan. Re-estimating you timelines should also be pretty easy, e.g. if you discover after a couple of sprints that the team's velocity is actually only 10 story points per month, then you can easily predict what your revised timelines will be.
Do bear in mind that team velocity does fluctuate for a number of reasons. It is typically lower at the start of a project when the team is still forming. Also the team is most likely concentrating on infrastructure concerns at this point rather than delivering functionality.