确定软件需求很困难。很好地理解客户需求，在改变发生时维护文档和需求都不是容易的事情。

敏捷式 vs.瀑布式：项目和软件需求

瀑布式和敏捷式项目，在管理软件需求上十分不同。

敏捷式很有价值，因为它帮助开发团队和利益相关者更加关注软件的交付，尽快满足客户的重要需求。使用敏捷及其周期性反馈循环，开发团队和stakeholder能够关注到正确的需求上。

分解瀑布式项目

与之相反，瀑布式项目的目地是提前定义所有软件需求，详细记录所有细节，这样项目团队可以在不做任何改动的情况下开发出满意的产品。这种方式下，压力在客户身上，要求他们在原型交付之前就能考虑到所有可能需要的需求。当需求确实需要变更时，瀑布式项目使用变更管理来调整需求，这通常是费时又费钱的流程。

我看过一个瀑布式项目，开始时就有一长列软件需求，但是最终，很多功能完全没有客户使用。更为糟糕的是真正需要的功能在项目开始之初被过度评估反而根本不在需求列表里。得到正确的需求，在项目期间保持正确，这在瀑布式项目中几乎不可能。

归零的敏捷方法

现在让我们一起看看敏捷是如何用不同的方式定位软件需求，以及敏捷技术是如何帮助开发团队关注于满足正确需求的。敏捷软件开发的声明认为能工作的软件程序重于完备复杂的文档。敏捷框架，比如scrum和XP建议开发团队要用迭代的方式交付软件。用户场景的Backlog用来管理需求。在迭代开始时，团队和利益相关者在下一次交付需要完成的需求上达成一致。通过这样的合作，每个人都能够关注在交付最重要的特性上。

敏捷项目假定在一开始无法得到所有需求。持续改进，不仅在产品，也在流程上全面融入到敏捷项目中。要想改进软件项目需求，敏捷架构提供了一些有用的方式，比如计划游戏，backlog grooming session和软件演示。当使用敏捷方法时，不断得到的新信息帮助理解逐步深入，需求便会持续得到更新。

敏捷项目中关注于正确软件需求的成功要素是：

• 利益相关者和开发团队要经常沟通
• 关注于需求可以给客户带来什么价值
• 有效实施敏捷需求实践

敏捷式vs.瀑布式：都需要经常，细致的交互

团队和利益相关者之间需要经常并且细致的交互。建立互信，人们之间维持开放并且忠诚的关系非常重要。这样的氛围使得沟通更为有效，帮助大家构建对于正确需求的一致理解。

对于我来说，价值比费用更重要。如果你知道哪一个需求最为重要，那么开发它所需的成本反而不那么要紧。对价值的理解也会激励大家，帮助大家关注于持续选择并开发正确的需求。

使用敏捷项目框架，比如scrum、XP、SAFe或者LeSS并不会自动保证项目的成功。需要以适合项目需求的方式使用这些框架。选择合适的方式，在工作方法上达成一致。不用太担心项目一开始时达不到完美，反思之类的活动会帮助大家持续学习并在过程中不断改进。