敏捷实施的起点--需求分析的思考

就目前我所待过的两个项目组，包括我了解到其他一些项目组的情况，基本都遵循了瀑布模式的实施方式，简单来说就是需求分析--设计--开发--测试--投产。

从入场开始需求调研到交付详细需求文档，我们称之为需求分析阶段。这个阶段基本都是需求人员入场，而开发团队并不参与，这就使得需求与开发团队是异步的。而需求人员在现场想要提供一份无偏差的高质量文档几乎是不可能的，这就造成了开发人员入场之后，包括开发之后才会发现的一些需求上的不合理，不明确，没有条件实现等等诸多问题。

而且即使需求写的比较细，开发人员在开发过程中依然需要不断的需要与需求人员沟通，而这些沟通中又有相当一部分是无效沟通。再加上并不是每个开发都很善于沟通，还会让一些问题进入测试阶段才能暴露，从而影响项目进度。

但是我们反过来想一下，为什么需求必须是讨论出来，而不能是通过一个详细设计文档去传达，使得每个成员都对需求来负责，而不是仅仅被动的接受。

对此，项目可以要求各团队的 PO，不再写详细的需求文档，而是出需求列表。强制要求，需求的传递必须通过需求澄清方式完成。

也就是需求、开发、测试人员，同时参与需求的分析工作。步骤如下：

1. 需求人员列出项目组所有的业务场景，并进行排序；
2. 开发、测试人员，听 PO 对每个场景进行讲解，注意 PO 不再提供详细需求的文档了，然后开发、测试人员可以要求 PO 对每个需求讲解清楚，直到听懂理解并能开始进行设计工作为止；
3. 开发人员将 PO 讲解的需求给记录描述出来，需要包括基本的业务流程图以及接口说明，同时要求测试人员将需求的验收条件给写出来，整合成针对每个场景的需求澄清文档；
4. 由 PO 确认需求澄清文档内容的准确性，如果无误可以开始进入开发过程了。

通过这样的方式，可以节省 PO 详细需求文档的时间，同时将需求的责任分担到每个角色的身上。因为，即使再详细的文档，研发和测试人员 还是需要阅读消化同时也需要多次找 PO 确认。直接通过讲解确认，我们也称为"需求的三次握手"过程，开发、测试、需求人员，实际完成了对需求的传递、需求验证规则的统一。