敏捷软件开发:你对不断变化的用户需求有什么反应？

Question

在SE和其他网站上阅读这些“敏捷开发”的内容时，我一直在想一件事：

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

1. 收集用户的需求，
2. 根据这些需求编写一个规范，
3. 把它给顾客，并为他迄今所做的工作向他收费，
4. 做一个(粗略的)技术设计，这样你就可以估计实现的成本，
5. 给用户一个实现的价格报价，
6. 等待客户签署说明书并接受报价，
7. 设计，实现，测试，
8. 比尔。

如果在此过程中，需求发生了变化，您会为所需的更改发送一个报价(或者如果更改很小，则免费发送)，您喜欢客户，客户也不会经常这样做。

那么，在敏捷项目中，在频繁的需求变更是过程的一部分的情况下，这是如何工作的(财务上的)？

• 你是否为每一个设计变更写一份报盘？(这不是很乱吗？)
• 还是你协商一个固定的价格，希望客户不要太频繁地改变需求？(我知道客户在接受项目完成之前，可能会利用这一机会请求数年的新功能，这可能很冒险。)
• 或者你只是向顾客支付所需的全部时间？(对客户来说，这可能是有风险的，因为客户事先不知道成本。)

Answer 1

在一个理想的敏捷世界中，你可以预先商定一个价格和几个小时，但不同意范围。客户决定什么是最起码的有用产品，而不是他们真正想要的产品，而这应该比商定的小时数少得多。

然后你以迭代的方式向他们传递，他们想改变主意就改变主意，但你从来不超过商定的时间。在理论上，在实践中，他们最终得到的是他们真正需要的产品，而不是他们真正想要的产品。

如果他们想继续支付额外的小时后，原来商定的价值，这也没关系。如果你做得足够好，通过故事卡、绿巨人或其他任何东西，你可以让客户清楚地知道他们每次添加新的东西时会失去哪些功能(或者至少会被剥夺)，这在很大程度上阻止了琐碎的改变。

这里有两个值得注意的风险。首先，如果客户不了解敏捷，他可能会被吓跑。他似乎在冒所有的风险。只有经验表明他不是真的。

第二，他们必须参与整个过程，否则每个人都会输。许多客户都不明白他们必须如何参与，直到为时已晚。

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

Answer 2

一些 人民 已尝试 至 给解决方案在过去的固定价格项目中使用敏捷。我个人认为这是不可能的。

Scrum尤其适用于产品软件公司，在服务公司中使用较少。

你可以在你的项目中使用一些敏捷性，比如迭代、日常站立、倦怠等等，但我可以向你保证，如果你以一定的价格提供一定数量的东西，并且交付的数量少于合同中的内容，你就会有问题。

请不要提供无拘束的酱汁。对于给定的问题，我们必须使用适当的解决方案。

Answer 3

其他人的经历可能会有所不同，但我看到的一种方式基本上和你的“传统”一样，有几件事要注意：

1. 为更改构建一些开销(例如，10%)
2. 评估并单独支付大量更改或汇总和超出内置成本的账单更改(一个很好的，尽管不是编程，例如设计工作，其中的初始成本通常包括，例如3个修订，随后的修订或可能是全部的待办事项是额外的)。

通常，敏捷项目从一个“核心”项目开始，然后在必要的基础上以模块化的方式螺旋式发展(我已经在我参与的项目中看到了很多这样的事情)。所以，从核心产品开始，假设它是一个映射应用程序。第一个实现只是一个以当前位置为中心的映射(客户最初订购的是什么)。

然后，顾客决定他们希望在你周围有一些吸引人的点滴。好的，这是一个相当大的部分(相对来说)，所以你把它作为一个新的“模块”或购买订单。改变的东西，如颜色或设计的这些引脚是内置的成本，该订单。方向和覆盖是另一种采购订单，因为它们是在其他采购订单进行之后才被请求的，等等。