在敏捷环境中该如何进行需求分析（一）

• 单向的信息传递，容易出现理解偏差。
• 文档很正式，我们会误以为它一定是对的，不去质疑它，让我们停止作出判断。
• 有了详细的文档，我们不会反复讨论它，相互确认。

• 书面文档不利于团队共享责任，它扮演了证据的角色。

首先，不同于瀑布一开始就通过功能需求说明书把需求定好了，假设这个项目可能需要一年的时间，按照瀑布的做法，我们在项目开始前的一个月内可能就要确定所有的需求，等同于说在一个月内就要预测到一年以后的事情，这个是很难的，一年会发生什么技术变化，或者市场变化，我们都无法准确得预测到。

所以，在敏捷管理中，我们认为需求是变化的，不会也无法在一开始就做好项目所有的需求规划和细节，因为我们知道后面还会有各种我们无法预测到的情况发生。

在刚开始一个新的项目时，我们通常会考虑组织知识库当中找到经验教训，不能在新的项目中继续踩坑。这也是一个正常技术型公司惯常的做法。我们就会下一些结论说：我们只要在某方面做得更努力或者更多，结果就会更好。在很多时候，可能真的如我们预料的一样，但这个用在需求的收集上是行不通的。

很多重要的项目都会有涌现的需求，而且这些需求涌现出来会引起其他问题，比如，突然涌现的需求让我们很难准确地预测进度。

• 事情会发生变化

• 不需要

所以并不需要全部预测，而是让需求就以这样涌现的方式在项目的进程中出现。

• 时间有限

需求在变化，我们应对需求的方式也可以发生变化，传统的需求功能说明书已然不适合当下，传闻中有个神乎其神的神话：如果你把需求写下来，用户就能得到他们想要的东西。

所以：少量的/简化的书面文档+沟通>全面的书面文档。

处理涌现需求的第一步就是认识到我们不可能想到每一件事情。

当需求出现时，持续地去提炼它。