敏捷软件开发：您如何*在财务上*响应不断变化的用户需求？

在SE和其他网站上阅读所有这些“敏捷开发”内容时，我总是想知道一件事：

在“传统”软件工程中，您

1. 收集用户的需求，
2. 根据这些要求编写规范，
3. 把它交给客户，并向他收取到目前为止已完成的工作的费用，
4. 做一个（粗略的）技术设计，以便您可以估算实施成本，
5. 为用户提供实施的价格报价，
6. 等待客户签署规格书并接受报价，
7. 设计，实施，测试，
8. 法案。

如果在此过程中需求发生变更，则您发送所需变更的报价（有价格）（如果变更很小，则免费提供，您喜欢客户，而客户却不经常这样做） 。

那么，这在敏捷项目中是如何工作的（财务上），而频繁的需求变更是流程的一部分？

• 您是否为每次设计变更都写报价？（这不是很乱吗？）
• 还是您协商固定价格并希望客户不要经常更改要求？（可能会有风险，我知道客户会在接受该项目完成之前利用这个机会请求多年的新功能。）
• 还是只向客户收取所需的总时间费用？（对于事先不知道成本的客户可能会有风险。）

在理想的敏捷世界中，您同意预先支付价格和几个小时的费用，但不能确定范围。客户决定什么是最低有用产品，而不是他们真正想要的产品，这应该远远少于商定的小时数。

然后，您可以迭代地交付给他们，他们会改变他们的想法，但是您永远不会超过约定的小时数。从理论上并且通常在实践中，他们最终得到的是他们真正需要的产品，而不是他们真正想要的产品。

而且，如果他们想继续向您支付原始商定价格后的额外时间，那也可以。如果您通过故事卡，Greenhopper或其他方式做好了使进度可见的出色工作，那么您可以在客户每次添加新内容时使其失去（或至少降低优先级）功能，这对客户来说非常明显。停止琐碎的变化。

这里有两个值得注意的风险。首先是，如果客户没有预先了解敏捷性，则可能会感到害怕。看来他承担了一切风险。只有经验表明他不是真的。

第二个是他们必须在整个过程中参与进来，否则每个人都会迷失方向。直到为时已晚，许多客户都无法理解他们必须如何参与。

但是，如果您作为一家公司解释得足够好，那么每个人都是赢家。

有些 人 试图 以 给予解决方案，在过去使用敏捷的固定价格项目。我个人认为这通常是不可能的。

Scrum特别适合于产品软件公司，而很少用于服务公司。

您可以在项目中使用一些敏捷性，例如迭代，日常站立，累死等，但是我可以向您保证，如果您以一定的价格提供一定数量的东西，并且交付的价格低于合同规定的价格，你会有问题。

请不要供应敏捷àtoutes les sauce。对于给定的问题，我们必须使用适当的解决方案。

这实际上与敏捷编程或您使用的任何模型无关。作为自由职业者，我混合使用Waterfall和V模型，但仍然遇到相同的问题：如果客户想在详细设计期间进行更改，该怎么办？如果他在实施过程中进行了更改怎么办？

您必须使用的方法取决于客户和您的关系。

如果联系人对于您为该客户所做的一切都是必不可少的，因为您知道他会尽力不付款，或者他会尽可能地起诉您，那么是的，您必须为每个客户写一份要约需求的微小变化。这不是一团糟：如果您组织得当，在开发过程中适应新需求可能并不难。但是可以肯定的是，这是浪费时间和金钱的，而且不得不签署一份变更要约要花两个小时才能实施，这很奇怪。

对于其他客户，效果较好的方法如下：

• 签署第一个报价时，请指定估计成本和最大成本。估算费用在法律上并不代表任何意义，仅是估算值。最大成本具有法律价值：如果您说该产品对客户的成本为3,000美元，而最终最终使您的成本为3,157.24美元，那么客户仍然需要支付3,000美元。实际上，在大多数情况下，实际成本将小于给定的最大值，并且更接近于您的估计。

• 当客户要求更改需求时，估算其成本并将其与实际成本和状态进行比较。如果您几乎完成了该产品，并且实际成本为$ 2,108.36，并且更改成本估计为$ 150，请执行此操作。另一方面，如果存在达到最大风险，请告诉您的客户，您必须一起重新评估总成本。

敏捷和“写要约”似乎是一个对立的问题:)-后者不是有效的软件工程：D

好的，既然我们开玩笑了，那就回到真实的世界。

“它在敏捷中如何工作？” -合同使事情复杂化，但我希望弄清楚。敏捷建立在“信任”和“共同工作”的原则之上，这意味着客户可以随时更改任何内容，并且了解到它可能会花费更多，或者如果是非侵入式的，则可能无需额外费用。

这是什么意思？这意味着合同说明我们（客户）确定了成本的初步估算以及我们可以处理的+/-方差百分比，例如10万美元的出价，但我愿意提高到12万美元（这可能不是合同的一部分，但要在客户心中）。

现在，当进行设计变更时，您可以灵活地进行估算和计划-将您的团队召集在一起，并询问他们“理论点”估算因素的复杂性。由于有一些速度估算，您可以将它们相乘并给出计划估算。如果您知道团队及其相对薪水，应该相对容易地得出每个故事点的成本（请不要对每个人的薪水取平均数，您将屈服于平均数的缺陷）。

您是否需要与客户联系财务？没有。不必要。您将让客户优先处理这些问题，并将它们插入积压的正确位置。既然您已经知道了待办事项的大小（如果还没有，那么应该知道），并且根据财务状况（每个故事点的成本），您已经知道在给定的预算下哪些低优先级要求可能无法实现。向他们显示重新优先处理的积压订单，以及根据$$合同的可用功能估算。然后让THEM决定是否愿意/如果您/何时/他们到达那里，付出更多。如果他们要免费使用...您请站起来告诉他们，价格会更高。

如果您可以将此图放在某个地方供客户查看，则无需不断返回财务状况，这应该会有所帮助。

希望这可以帮助！

其他人的经历可能会有所不同，但是我所看到的一种方式与您的“传统”方式大致相同，需要注意以下几点：

1. 为更改增加一些开销（例如10％）
2. 评估并单独计费较大的变更或汇总并计费超出内置成本的（虽然不是编程的好项目，但很好的例子是设计工作，通常初始成本包括3个修订，而随后的修订或总重做是额外）

通常，敏捷项目也是从“核心”项目开始的，然后根据需要以模块化的方式从那里螺旋出来（我已经在我参与的项目中发生了很多）。因此，从一个核心产品开始，假设它是一个映射应用程序。第一种实现方式只是以您当前位置（客户最初订购的商品）为中心的地图。

然后，客户决定要在您周围放一些景点的大头针。好的，相对而言，这是一个很大的部分，因此您可以将其记为新的“模块”或采购订单。更改这些引脚的颜色或设计之类的东西都包含在该订单的成本中。方向和叠加层是另一个采购订单，因为直到另一个采购订单开始执行后才被要求，依此类推。