我已经阅读了敏捷宣言，并花了一天的时间浏览网页，寻找这个难以捉摸的答案。但遗憾的是，我没有得到涵盖所有基础的答案。
在观看敏捷传教士的所有博客文章和新闻广播时，您只需了解开放范围或开放“时间”项目。您如何将此应用于修复成本项目？
据我所知，最大的问题是范围管理。您如何确定某些内容是否在预计的范围内？您如何为您的决定制定论据？由于您实施软件的敏捷方式，没有详细的设计可供争论。在大多数情况下，您只有一个模糊的愿望清单，客户会向您提供。并且非常通用，您可以将任何特征解释为其中。
随着固定成本项目比例的上升，这对我来说是一个真正的问题。
所以问题是：
答案 0 :(得分：10)
对我而言，关于敏捷和固定价格的简短回答是你不能这样做，至少不是固定范围。
我知道有些人会说“这不是真的，我们正在这样做”但是，在充分尊重的情况下，我不认为他们真的在做敏捷，我会解释原因。实际上，解释非常简单：固定价格意味着固定的范围，并且基于可预测性，其中敏捷是关于可变范围，范围管理和适应性的。因此固定价格的固定价格基本上与敏捷相反。
使用敏捷方法，固定价格可为您提供针对特定团队规模的多次迭代。在这些迭代期间，客户将能够让团队首先构建最有价值的功能，从而最大化生成的业务价值。当迭代的成本大于生成的值时，整个想法就是停止迭代。这就是敏捷的工作原理。
因此，当人们说他们以灵活的方式确定固定价格的固定价格时，他们实际上会引入一些与敏捷理论并不完全兼容的约束 - 比如对一组特定功能进行预先估算并冻结这些功能和估计 - 他们放弃了敏捷的重要优势（除非他们对技术和业务领域有完美的了解，并掌握它们足以预测一切，但我知道很少有类似的项目）。
无论如何，这是对各种敏捷合同的良好汇编：10 Contracts for your next Agile Software Project可能会有所帮助。但我认为它们都需要对客户进行一些教育，特别是那些用于定价固定价格（以及延迟交货）的客户。
答案 1 :(得分：6)
Scrum不会取代有适当的要求，甚至不会取代偶尔的主要版本或里程碑。相反，它为您提供了一种方法，可以让您的团队保持高效和专注，并避免瀑布流程浪费时间的副作用。
事实上，像Scrum这样的敏捷流程的最大优势之一就是它会导致您在项目的有问题区域“快速而大声地失败”。如果在几次冲刺之后，您的团队仍然无法有效地估计实施特定功能所需的时间和资源，那么可能值得回顾该领域的要求 - 可能需要澄清，简化，或完全报废。然而，在传统的瀑布流程中，这些“问题特征”通常可以推迟到最后一刻，从而导致大多数项目下放的通常死亡和交付不足。
但是，在使用具有大量要求的Scrum的团队中，产品负责人的角色更为重要。留给他们自己的设备，大多数开发团队将首先关注最有趣/有趣/令人讨厌的功能（服务API，缓存，搜索），并留下“混乱”的东西，如支付流程，用户体验设计和i18n直到最后一分钟。强大的用户声音对于确保对最终用户至关重要的那些功能得到公平的关注至关重要。
答案 2 :(得分：0)
我最近回答了similar question on SO。您可能会发现该答案很有用。
答案 3 :(得分：0)
好的，这不是您正在寻找的理想答案，但可能会帮助您做到这一点。
关于你的第一点：
对于敏捷，特别是Scrum，该样式适合使用迭代模式更改规范和不固定的截止日期。能够在固定范围项目中管理这将是一场噩梦。通常做的是为指定的范围设定预算，对此的任何附录都会产生超出范围预算的可计费小时数。在Scrum中执行此操作将毫无意义，因为产品待办事项将不断由利益相关者填补。如果对固定预算中的范围变更没有“惩罚”，那么就没有任何东西可以阻止人们加载到你身上。
这里的替代方案是具有固定范围的sprint继承，例如：
5x Sprints = x Cost with minimal scope change。
第二点：
使用分析和设计是一个非常宝贵的工具。通过使用用例，事件表，序列图，状态机等;从长远来看，你将拯救自己的眼泪。基本上，一旦规划完成，任何需要额外的附录（请注意其他内容，而不是被忽略的内容）的用例和大代码更改都将超出范围。实际上，任何在规划中未被忽视且不在您的规范中的内容都超出了范围。
最后，您需要拥有非常精心设计的文档以及与客户达成的非常可靠的协议，才能将其提升至100％。
我希望这会有所帮助。
答案 4 :(得分：0)
我在一个固定成本和固定时间项目的环境中工作。我们已经从Waterfall / VModel方法学转向了Scrum-esque方法学。 Scrum在固定成本/时间项目中可以很好地工作，因为概念是客户被控制，但是为了工作，你必须能够准确地确定需要什么工作以及它将花费多少（时间，金钱） ，资源）。这是一个让Scrum成为理想候选人的场所。
您将可疑的愿望清单/要求/屏幕截图分解为可标记的可交付成果。例如。客户可能会说“我想要电子商务，使用Paypal”，您需要将其分解为实际的可交付成果，例如： “1.客户注册和登录，2。产品目录，3。购物袋，4。付款，5。订单确认”。在这个阶段，仍然无法确定需要多长时间，而且我们需要提供上述所有内容才能完成项目（即，您无法在没有付款的情况下拥有电子商务）。所以再次打破它们，直到你有细粒度的可交付成果，在几小时，几天内完全可以进行，但肯定不是几周，例如。
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
...
依此类推，它可以很快完成，你现在可以猜测需要花多长时间才能完成x（ofc，我可能会进一步打破上面的内容，添加更多描述性文字来描述所需的工作，例如正如我可能需要的持久性数据结构，这些结构中的数据，如何添加数据，进一步发展甚至可能需要开始和退出状态所需的数据）。
一旦你去了这个，你就会注意到一些功能和依赖于其他功能，例如，你不能在目录上有分页功能，除非你有一个目录启动witj，并且catagloge将需要CMS screesn添加和编辑项目等。在您使用的任何工具中突出显示这些'不能没有功能'，这构成了核心项目，并且在一两天之内您就有了一些可以开发的功能独立的，有成本的，加起来会产生项目的成本。而现在客户负责，他们决定想要增加一项功能并增加成本，很酷，它毕竟取决于它们。
以上所有内容显然只是scrum或任何敏捷过程的一小部分。
答案 5 :(得分：0)
我不认为具有范围蔓延和Scrum流程的固定价格合约是不兼容的。您只需要与客户就如何运作达成一致。如果您与客户一起创建初始待办事项，则可以使用它作为固定价格成本和计划的基础。您甚至可以同意“X”故事点的比率在开头等于“Y”成本和“Z”时间表。
然后你做了正常的scrum事情，让客户将故事分配给当前的迭代等等。
当客户参与范围蔓延时，您可以与他们合作，将“creep”作为用户故事添加到积压工作中。每次添加新故事时，都要指出，对于添加到积压的每个X点，他们必须按Y增加成本并按Z计划，否则他们将不得不放弃具有相同价值的故事点。由于他们在每次迭代中选择你所做的工作，他们放弃的点数（如果这是选择）将是最不重要的特征。当你的日程安排用完时，你将留下积压的最不重要的功能，他们可以选择放弃或给你一个新的合同来完成。
当然，诀窍是善于估算每个故事/任务的成本和时间表; - ）
答案 6 :(得分：0)
该项目可以分解为较小的部分，固定费率可以附加到这些部分。然后可以调整项目的其他阶段。
您必须能够针对竞争对手销售敏捷流程。如果客户有按时，规格和成本交付的固定投标项目的历史记录，为什么他们会浪费时间从其他开发商那里获得投标？
答案 7 :(得分：0)
固定成本并不意味着单一冲刺。范围被转移到产品Backlog，并且随着Sprint进展，范围被调整，协商和交付。 Scrum可以实现快速的价值交付，并提供快速验证，并有机会识别潜在的镀金。
范围更改可能会导致添加待办事项，并删除其他项目。它是ROI与提供的固定预算之间的平衡。
如果范围确实增加（并增加值），并且成本是固定的，则必须相应地管理三重约束（成本，时间和范围）。
请记住，固定成本并不意味着固定长度。