To me, the short answer about Agile and fixed price is that you can't do it, at least not with a fixed scope.
I know some people will say "that's not true, we are doing it" but, with all due respect, I don't think they are really doing Agile and I'll explain why. Actually the explanation is quite simple: fixed price implies fixed scope and is based on predictability where Agile is all about variable scope, scope management and adaptivity. So fixed price with fixed scope is basically the opposite of Agile.
With an Agile approach, fixed price gives you a number of iterations for a given team size. During these iterations, the customer will be able to have the team build the most valuable features first and thus to maximize the generated business value. The whole idea is then to stop iterating when the cost of an iteration is greater than the generated value. This is how Agile works.
So when people says they do fixed price with fixed scope in an agile way, they actually introduce some constraints that are not really compatible with the Agile theory - like doing an up-front estimation of a given set of features and freezing these features and estimations - and they loose important advantages of Agile (unless they have a perfect knowledge of the technologies and of the business domain and master them enough to predict everything but I know few projects that are like this).
Here is anyway a good compilation of various Agile contracts: 10 Contracts for your next Agile Software Project that might be helpful. But I think they all require some education of customers, especially the one that are used to fixed price with fixed scope (and late deliveries).
Scrum does not replace having proper requirements, or even having occasional major releases or milestones. Rather, it gives you a means to keep your team productive and focused, and avoids the time-wasting side-effects of a waterfall process.
In fact, one of the biggest advantages of an agile process like Scrum is that it causes you to "fail quickly and loudly" on problematic areas of your project. If, after a couple of sprints, your team still can't effectively estimate the time and resources needed to implement a particular feature, it may be worth pushing back on the requirements in that area -- they may need to be clarified, simplified, or scrapped altogether. In a traditional waterfall process, however, those "problem features" can often be pushed back to the last possible minute, resulting in the usual deathmarch and under-delivery into which most projects devolve.
However, the role of the Product Owner is even more critical in teams using Scrum who have a large set of requirements. Left to their own devices, most development teams will focus on the most interesting/fun/geeky features (service APIs, caching, search) first, and leave the "messy" stuff like payment process, UX design, and i18n until the last minute. A strong user voice is essential to making sure those features critical to the end user receive their fair share of attention.
Okay, this will not be the ideal answer you are looking for, but may help non-the-less.
For your first point:
With agile, and Scrum in particular, the style is suited toward changing specifications and unfixed deadlines using iteration patterns. To be able to manage this in a fixed scope project will be a nightmare. What one would normally do is set a budget for the specified scope, and any addendum to this would produce billable hours above and beyond the scoped budget. To do this in Scrum would be pointless, as the product backlog will be continually filled by the stakeholders. If there is no "punishment" for scope changes in a fixed budget, there will be nothing holding people back from just loading on to you.
The alternative here is to have fixed scope sprint successions, so for instance:
5x Sprints = x Cost with minimal scope change.
For your second point:
The use of Analysis and Design is an invaluable tool. By using use cases, event tables, sequence diagrams, state machines and the like; you will be saving yourselves oceans of tears in the long run. Basically, once the planning has been done, any addendum to this that requires additional (please note additional, not things that have been overlooked) use cases and large code changes will be out of scope. In fact, anything that was not overlooked in the planning and is not in your specification, is out of scope.
In closing, you will need to have very well planned documentation as well as very solid agreements with your clients to be able to pull this off 100%.
1 Catalogue
1a View all Items
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row
1aii View 10 items per page with paging
1aiii View a user slected number of items per page, with paging
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row
1b View by Category
...
1c Search
...
1d Attribute Filter
...
I worked in a environment where we had fixed cost and fixed time projects. We has switched to a Scrum-esque methology from a Waterfall/VModel methology. Scrum can work very well in fixed cost/time projects as the concept is that the customer is put in control, however for this to work you have to be able to somewhat accuratly determine what work is required and what it will cost (time, money, resource). And this is a situtation where Scrum in an ideal candidate.
You break down the wishy-washy wish list/requirements/screenshots into tagiable deliverables. E.g. a customer may say "I want ecommerce, with Paypal", you need to break this down into actual deliverables e.g. "1. Customer Registration and Login, 2. Product Catalogue, 3. Shopping Bag, 4. Payment, 5. Order Acknowlegment". At this stage, it's still impossible to determine how long it will take, and ofc we need to deliver all of the above in order to complete the project (i.e. you can't have Ecommerce without Payment). So break them down again, and again, until you have granular deliverables, genreally delverable within hours, maybe days, but certainly not weeks e.g.
1 Catalogue
1a View all Items
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row
1aii View 10 items per page with paging
1aiii View a user slected number of items per page, with paging
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row
1b View by Category
...
1c Search
...
1d Attribute Filter
...
And so on, it can be done very quickly, and you can now probably guesstimate how long it would take todo x (ofc, I might break the above down even further, add more descriptive text to describe the work required, such as what persistant data stuctures Ill might need, the data in those structures, how data will be added, going further you might even desribe the required the begin and exit states).
Once you've go this, you'll notice that some features and depenant on others, e..g you can't have paging feature on a catalogue unless you have a catalogue to start witj, and the catagloge will require the CMS screesn to add and edit items etc etc. Highlight these 'can't live without feature' in whatever tool you using and this forms the core project, and within a day or two you have a bunch of features that can be developed somewhat standalone, with costs, which when added up make the cost of the project. And now the customer is in charge, they decide thay want to added a feature and increase the cost, cool, its up to them afterall.
All the above is obviously only a small portion of what scrum or any agile process is.
当客户进行范围蠕变时，您与他们一起将“蠕变”作为用户故事添加到待办事项中。每次添加新故事时，请指出，对于添加到待办事项中的每 X 个点，他们将不得不增加 Y 的成本并增加 Z 的进度，或者，他们将不得不放弃同等价值的故事点。由于他们每次迭代都会选择您的工作内容，因此他们放弃的点（如果这是选择的话）将是最不有价值的功能。当您的日程安排结束时，您将积压一些最不重要的功能，他们可以选择放弃这些功能或给您一份新合同来完成。
当然，诀窍是善于估算每个故事/任务的成本和时间表;-)
I don't think a fixed price contract with scope creep and a Scrum process are incompatible. You just need to agree up front with your customer how it will work. If you create your initial backlog with your customer, estimating as you go, you can use that as your basis for the fixed price cost and schedule. You can even agree to a rate of "X" story points equals "Y" cost and "Z" schedule at the beginning.
You then do the normal scrum thing, having the customer allocate stories to the current iteration, etc.
As the customer engages in scope creep, you work with them to add the "creep" as user stories to the backlog. Each time you add a new story, point out that for each X points added to the backlog, they will have to increase cost by Y and schedule by Z, or, they will have to give up story points of equal value. Since they are picking what you work each iteration, the points they give up (if that's the choice) will be the least valuable features. When your schedule runs out, you will be left with a backlog of the least important features that they can choose to drop or give you a new contract to finish.
The trick, of course, is to be good at estimating cost and schedule for each story/task ;-)
The project could be broken down into smaller parts and fixed rates could be attached to those. The other phases of the project could then be adjusted.
You have to be able to sell the agile process against your competitors. If a client has a history of fixed bid projects that were delivered on time, spec and cost, why would they waste their time taking bids from other developers?
Fixed Cost does not mean single sprint. Scope gets transfered to the Product Backlog, and as Sprints progress, scope is adjusted, negotiated and delivered. Scrum allows for rapid value delivery, and provides quick validation, and the opportunity to identify potential gold plating.
Scope change may result in the addition of backlog items, and the deletion of others. Its a balance of ROI vs the fixed budget provided.
If the scope does increase (and add value), and the cost is fixed, then the triple constraint (cost, time and scope) must be managed accordingly.
Remember that fixed cost does not mean fixed length.
发布评论
评论（7）
对我来说，关于敏捷和固定价格的简短回答是你做不到，至少在固定范围内做不到。
我知道有些人会说“这不是真的，我们正在这样做”，但是，恕我直言，我不认为他们真正在做敏捷，我会解释原因。实际上，解释很简单：固定价格意味着固定范围，并且基于可预测性，而敏捷则涉及可变范围、范围管理和适应性。因此，固定价格和固定范围基本上与敏捷相反。
通过敏捷方法，固定价格可以为给定团队规模提供多次迭代。在这些迭代过程中，客户将能够让团队首先构建最有价值的功能，从而最大化所产生的业务价值。整个想法是当迭代成本大于生成值时停止迭代。这就是敏捷的运作方式。
因此，当人们说他们以敏捷的方式在固定范围内进行固定价格时，他们实际上引入了一些与敏捷理论并不真正兼容的约束 - 例如对一组给定的功能进行预先估计并冻结这些功能和估计- 他们失去了敏捷的重要优势（除非他们对技术和业务领域有完美的了解，并掌握足够的知识来预测一切，但我知道很少有这样的项目）。
无论如何，这里是各种敏捷合同的良好汇编：您的下一个敏捷软件项目的 10 份合同 这可能会有所帮助。但我认为它们都需要对客户进行一些教育，尤其是那些习惯于固定范围固定价格（以及延迟交付）的客户。
To me, the short answer about Agile and fixed price is that you can't do it, at least not with a fixed scope.
I know some people will say "that's not true, we are doing it" but, with all due respect, I don't think they are really doing Agile and I'll explain why. Actually the explanation is quite simple: fixed price implies fixed scope and is based on predictability where Agile is all about variable scope, scope management and adaptivity. So fixed price with fixed scope is basically the opposite of Agile.
With an Agile approach, fixed price gives you a number of iterations for a given team size. During these iterations, the customer will be able to have the team build the most valuable features first and thus to maximize the generated business value. The whole idea is then to stop iterating when the cost of an iteration is greater than the generated value. This is how Agile works.
So when people says they do fixed price with fixed scope in an agile way, they actually introduce some constraints that are not really compatible with the Agile theory - like doing an up-front estimation of a given set of features and freezing these features and estimations - and they loose important advantages of Agile (unless they have a perfect knowledge of the technologies and of the business domain and master them enough to predict everything but I know few projects that are like this).
Here is anyway a good compilation of various Agile contracts: 10 Contracts for your next Agile Software Project that might be helpful. But I think they all require some education of customers, especially the one that are used to fixed price with fixed scope (and late deliveries).
Scrum 并不能取代适当的需求，甚至不能取代偶尔的主要版本或里程碑。相反，它为您提供了一种保持团队高效和专注的方法，并避免了瀑布流程浪费时间的副作用。
事实上，像 Scrum 这样的敏捷流程的最大优势之一是，它会导致您在项目的有问题的领域“快速而大声地失败”。如果经过几次冲刺，您的团队仍然无法有效地估计实现特定功能所需的时间和资源，那么可能值得推迟该领域的需求——它们可能需要澄清、简化、或完全报废。然而，在传统的瀑布流程中，这些“问题功能”通常会被推迟到最后一分钟，从而导致大多数项目都会陷入死亡行军和交付不足的情况。
然而，在使用 Scrum 并有大量需求的团队中，产品负责人的角色更为重要。大多数开发团队都会根据自己的设备，首先关注最有趣/好玩/极客的功能（服务 API、缓存、搜索），并将支付流程、UX 设计和国际化等“混乱”的东西留到最后一刻。强大的用户声音对于确保那些对最终用户至关重要的功能得到公平的关注至关重要。
Scrum does not replace having proper requirements, or even having occasional major releases or milestones. Rather, it gives you a means to keep your team productive and focused, and avoids the time-wasting side-effects of a waterfall process.
In fact, one of the biggest advantages of an agile process like Scrum is that it causes you to "fail quickly and loudly" on problematic areas of your project. If, after a couple of sprints, your team still can't effectively estimate the time and resources needed to implement a particular feature, it may be worth pushing back on the requirements in that area -- they may need to be clarified, simplified, or scrapped altogether. In a traditional waterfall process, however, those "problem features" can often be pushed back to the last possible minute, resulting in the usual deathmarch and under-delivery into which most projects devolve.
However, the role of the Product Owner is even more critical in teams using Scrum who have a large set of requirements. Left to their own devices, most development teams will focus on the most interesting/fun/geeky features (service APIs, caching, search) first, and leave the "messy" stuff like payment process, UX design, and i18n until the last minute. A strong user voice is essential to making sure those features critical to the end user receive their fair share of attention.
好吧，这不是您正在寻找的理想答案，但仍然可能有帮助。
对于第一点：
对于敏捷，尤其是 Scrum，该风格适合使用迭代模式来改变规范和不固定的截止日期。能够在固定范围的项目中管理这个将是一场噩梦。人们通常会做的是为指定范围设定预算，对此进行任何补充都会产生超出范围预算的计费时间。在 Scrum 中这样做是没有意义的，因为产品待办事项将不断地由利益相关者填充。如果固定预算中的范围变化没有“惩罚”，那么就没有什么可以阻止人们直接向你加载。
这里的替代方案是固定范围的冲刺连续，例如：
5x Sprints = x 范围变化最小的成本。对于第二点：
分析和设计的使用是一个非常宝贵的工具。通过使用用例、事件表、序列图、状态机等；从长远来看，你会为自己节省大量的眼泪。基本上，一旦规划完成，任何需要额外（请注意额外，而不是被忽视的事情）用例和大型代码更改的附录都将超出范围。事实上，任何在规划中没有被忽视并且不在您的规范中的内容都超出了范围。
最后，您需要有精心策划的文档以及与客户签订的非常可靠的协议，才能 100% 实现这一目标。
我希望这有帮助。
Okay, this will not be the ideal answer you are looking for, but may help non-the-less.
For your first point:
With agile, and Scrum in particular, the style is suited toward changing specifications and unfixed deadlines using iteration patterns. To be able to manage this in a fixed scope project will be a nightmare. What one would normally do is set a budget for the specified scope, and any addendum to this would produce billable hours above and beyond the scoped budget. To do this in Scrum would be pointless, as the product backlog will be continually filled by the stakeholders. If there is no "punishment" for scope changes in a fixed budget, there will be nothing holding people back from just loading on to you.
The alternative here is to have fixed scope sprint successions, so for instance:
5x Sprints = x Cost with minimal scope change.For your second point:
The use of Analysis and Design is an invaluable tool. By using use cases, event tables, sequence diagrams, state machines and the like; you will be saving yourselves oceans of tears in the long run. Basically, once the planning has been done, any addendum to this that requires additional (please note additional, not things that have been overlooked) use cases and large code changes will be out of scope. In fact, anything that was not overlooked in the planning and is not in your specification, is out of scope.
In closing, you will need to have very well planned documentation as well as very solid agreements with your clients to be able to pull this off 100%.
I hope this helps.
我在一个有固定成本和固定时间项目的环境中工作。我们已从瀑布/VModel 方法转向 Scrum 式方法。 Scrum 在固定成本/时间项目中可以很好地工作，因为其概念是客户处于控制之中，但是要使其发挥作用，您必须能够在一定程度上准确地确定需要哪些工作以及需要花费什么（时间、金钱） ，资源）。在这种情况下，Scrum 是一个理想的候选者。
您将优柔寡断的愿望清单/要求/屏幕截图分解为可标记的交付成果。例如，客户可能会说“我想要电子商务，使用 Paypal”，您需要将其分解为实际的可交付成果，例如“1. 客户注册和登录，2. 产品目录，3. 购物袋，4. 付款，5. 订单确认” ”。在这个阶段，仍然无法确定需要多长时间，并且我们需要交付上述所有内容才能完成该项目（即，没有付款就无法进行电子商务）。因此，一次又一次地分解它们，直到您获得细粒度的可交付成果，可以在几小时，也许几天，但肯定不是几周内进行一般性的研究，例如等等
，它可以很快完成，您现在可以猜测需要多长时间todo x（ofc，我可能会进一步分解上述内容，添加更多描述性文本来描述所需的工作，例如我可能需要什么持久数据结构、这些结构中的数据、如何添加数据，更进一步，您可能会甚至描述所需的开始和退出状态）。
一旦你完成了这个，你会注意到一些功能和其他功能的依赖关系，例如，除非你有一个目录来启动，否则你不能在目录上使用分页功能，并且目录将需要 CMS 屏幕添加和编辑项目等。在您使用的任何工具中突出显示这些“没有功能就无法生存”，这构成了核心项目，在一两天之内，您就拥有了一堆可以独立开发的功能，成本，加起来就构成了项目的成本。现在由客户负责，他们决定要添加一项功能并增加成本，很酷，这毕竟取决于他们。
上述所有内容显然只是 Scrum 或任何敏捷流程的一小部分。
I worked in a environment where we had fixed cost and fixed time projects. We has switched to a Scrum-esque methology from a Waterfall/VModel methology. Scrum can work very well in fixed cost/time projects as the concept is that the customer is put in control, however for this to work you have to be able to somewhat accuratly determine what work is required and what it will cost (time, money, resource). And this is a situtation where Scrum in an ideal candidate.
You break down the wishy-washy wish list/requirements/screenshots into tagiable deliverables. E.g. a customer may say "I want ecommerce, with Paypal", you need to break this down into actual deliverables e.g. "1. Customer Registration and Login, 2. Product Catalogue, 3. Shopping Bag, 4. Payment, 5. Order Acknowlegment". At this stage, it's still impossible to determine how long it will take, and ofc we need to deliver all of the above in order to complete the project (i.e. you can't have Ecommerce without Payment). So break them down again, and again, until you have granular deliverables, genreally delverable within hours, maybe days, but certainly not weeks e.g.
And so on, it can be done very quickly, and you can now probably guesstimate how long it would take todo x (ofc, I might break the above down even further, add more descriptive text to describe the work required, such as what persistant data stuctures Ill might need, the data in those structures, how data will be added, going further you might even desribe the required the begin and exit states).
Once you've go this, you'll notice that some features and depenant on others, e..g you can't have paging feature on a catalogue unless you have a catalogue to start witj, and the catagloge will require the CMS screesn to add and edit items etc etc. Highlight these 'can't live without feature' in whatever tool you using and this forms the core project, and within a day or two you have a bunch of features that can be developed somewhat standalone, with costs, which when added up make the cost of the project. And now the customer is in charge, they decide thay want to added a feature and increase the cost, cool, its up to them afterall.
All the above is obviously only a small portion of what scrum or any agile process is.
我不认为具有范围蔓延的固定价格合同和 Scrum 流程是不兼容的。您只需提前与客户就其运作方式达成一致即可。如果您与客户一起创建初始积压订单，并随时进行估算，则可以将其用作固定价格成本和时间表的基础。您甚至可以在一开始就同意“X”故事点的比率等于“Y”成本和“Z”时间表。
然后，您执行正常的 scrum 操作，让客户将故事分配到当前迭代等。
当客户进行范围蠕变时，您与他们一起将“蠕变”作为用户故事添加到待办事项中。每次添加新故事时，请指出，对于添加到待办事项中的每 X 个点，他们将不得不增加 Y 的成本并增加 Z 的进度，或者，他们将不得不放弃同等价值的故事点。由于他们每次迭代都会选择您的工作内容，因此他们放弃的点（如果这是选择的话）将是最不有价值的功能。当您的日程安排结束时，您将积压一些最不重要的功能，他们可以选择放弃这些功能或给您一份新合同来完成。
当然，诀窍是善于估算每个故事/任务的成本和时间表;-)
I don't think a fixed price contract with scope creep and a Scrum process are incompatible. You just need to agree up front with your customer how it will work. If you create your initial backlog with your customer, estimating as you go, you can use that as your basis for the fixed price cost and schedule. You can even agree to a rate of "X" story points equals "Y" cost and "Z" schedule at the beginning.
You then do the normal scrum thing, having the customer allocate stories to the current iteration, etc.
As the customer engages in scope creep, you work with them to add the "creep" as user stories to the backlog. Each time you add a new story, point out that for each X points added to the backlog, they will have to increase cost by Y and schedule by Z, or, they will have to give up story points of equal value. Since they are picking what you work each iteration, the points they give up (if that's the choice) will be the least valuable features. When your schedule runs out, you will be left with a backlog of the least important features that they can choose to drop or give you a new contract to finish.
The trick, of course, is to be good at estimating cost and schedule for each story/task ;-)
该项目可以分解为更小的部分，并且可以对这些部分附加固定费率。然后可以调整项目的其他阶段。
您必须能够向竞争对手推销敏捷流程。如果客户有按时、按规格和成本交付的固定投标项目的历史，那么他们为什么要浪费时间接受其他开发商的投标呢？
The project could be broken down into smaller parts and fixed rates could be attached to those. The other phases of the project could then be adjusted.
You have to be able to sell the agile process against your competitors. If a client has a history of fixed bid projects that were delivered on time, spec and cost, why would they waste their time taking bids from other developers?
固定成本并不意味着单一冲刺。范围被转移到产品待办事项列表中，并且随着冲刺的进展，范围被调整、协商和交付。 Scrum 允许快速价值交付，并提供快速验证以及识别潜在镀金的机会。
范围变更可能会导致积压项目的添加和其他项目的删除。它是投资回报率与提供的固定预算的平衡。
如果范围确实增加（并增加了价值），并且成本固定，则必须相应地管理三重约束（成本、时间和范围）。
请记住，固定成本并不意味着固定长度。
Fixed Cost does not mean single sprint. Scope gets transfered to the Product Backlog, and as Sprints progress, scope is adjusted, negotiated and delivered. Scrum allows for rapid value delivery, and provides quick validation, and the opportunity to identify potential gold plating.
Scope change may result in the addition of backlog items, and the deletion of others. Its a balance of ROI vs the fixed budget provided.
If the scope does increase (and add value), and the cost is fixed, then the triple constraint (cost, time and scope) must be managed accordingly.
Remember that fixed cost does not mean fixed length.