对于敏捷开发下需求评审的分析

引言

首先要说明，在敏捷开发语境中，几乎不使用“评审”这词，常用“验证”、“验收”、“反馈”等。本文将基于文档阅读或者观察软件运行的时效性人工检查工作定义为评审，符合此定义的敏捷实践也被视为评审。下文将选取敏捷中典型的需求评审对应实践来分析。由于Scrum是目前采纳最多的敏捷流派，选择了多个来自于Scrum的实践来分析，也兼顾了其它敏捷流派。

需求评审框架组成

为了便于分析，5个最关键维度组成了需求评审的如下表的五维需求评审框架。

表1 五维需求评审框架

可以看到各种各样的需求评审都可以按此框架来进行分析解释，也可以从此框架中寻找发现适合不同情境的有效需求评审方式方法。按以上框架中5个方面的分类，其组合总共有4×5×2×3×2=240种。可能有读者看到这里会认为，有些组合在现实中是不会出现的，比如高频结对管理方面评审，但是套用一句广告语“没有不可能”，下面将分析已经存在各类需求评审。下文也将继续探讨在不同情境下如何灵活应用，如何搭配得到高效组合，识别新的评审方式方法。

常见的需求评审举例

为了便于理解以上各方面分类，请看如下常见的需求评审。

表2 常见需求评审情况

上表中情况1的需求里程碑评审会就是传统瀑布模型中的需求评审会。

产品待办列表的优化

Scrum中，产品负责人（英文：Product Owner，缩写PO)是管理产品待办列表的唯一责任人。虽然理论上产品负责人可以一个人单独创建维护产品待办列表的全部内容，但多数情况下产品负责人是吸收他人贡献的，产品负责人然后进行整理排序调整优化等等。Scrum中的产品待办列表优化（Scrum Guide 2011版中其英文名是Grooming，Scrum Guide2013版中其英文名是refinement）指的是为列表项补充细节、估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品待办列表项的细节，并对列表项进行评审和修改。对照到本五维需求评审框架，这是定期会议的、技术方面的同级需求文档评审。因为这个过程中就算产品负责人是团队的行政上级，也是评审对象的主要作者，而不是评审者。

一般的，产品待办列表细化的结果用于未来的迭代（Scrum中称为冲刺），其起到的作用相当于瀑布模型中需求阶段的技术方面评审，但耐人寻味的是Scrum Guide说“优化的工作通常占用开发团队不超过10%的时间。然而，产品负责人可以根据自己的判断随时更新产品待办列表。”，而对于只有1～2次需求评审的传统瀑布模型而言，需求讨论评审会议所占比例恐怕不超过5%。

Scrum计划会议第一部分

Scrum中的计划会议第一部分的问题是：接下来的冲刺（等同于迭代）交付的增量中要包含什么内容?开发团队预计这个冲刺中要开发的功能。产品负责人讲解冲刺的目标以及达成该目标所需要完成的产品待办列表项。整个Scrum 团队为了更好地了解冲刺的工作进行讨论。对照到新需求评审框架，这是定期会议侧重于管理方面的同级需求文档评审，与上述产品待办列表细化同样是同级评审。

负责需求的产品负责人与团队一起交流，听取处理各种各样意见建议，在管理评审中反而是被评审的对象，这确实是对传统做法的大突破，而Scrum的流行也说明了这新做法的有效性。对比到瀑布模型，Scrum中的计划会议第一部分起到的作用相当于瀑布模型中需求阶段的里程碑管理方面评审。值得注意的是，Scrum建议1个月的迭代情况下，计划会议第一部分约需要4小时，占比约2.3%，整个计划会议需要8小时。

Scrum每日站会和燃尽图绘制

每日 Scrum 站会是以 15 分钟为限的事件，开发团队成员在这里分享各自的工作情况，并为接下来的 24小时制定计划。这需要检视上个每日站会以来的工作和预测下个每日站会之前所能完成的工作。一般的，Scrum团队每天绘制冲刺燃尽图，在冲刺中每日绘制本冲刺未来剩余的工作量，而此工作量是根据用户故事或者用例来预测估计的，用户故事和用例都是需求表达的形式。所以这也相当于需求管理评审，具体对应到新五维需求评审框架，这是会议形式高频管理方面同级需求文档评审。

敏捷开发过程中需求的澄清和确认

在敏捷开发环境下，由于不要求在开始时就有一份完整详细的需求说明，所以在开发过程中就需要诸如现场客户或客户代表来澄清和确认需求。这是各敏捷流派共有的实践。敏捷方法鼓励面对面的交流，所以开发过程中对需求的澄清和确认往往采用桌查，这其实也是一种需求评审的形态，对照到新需求评审框架，这是双人结对即时高频技术方面同级评审，而且不再仅仅基于需求文档，还可以基于软件运行来判断需求是否得到满足，虽然也许不能完全运行，但能够部分运行，能够展现界面或接口。在Scrum中，产品负责人承担响应此类评审（澄清解释并按需要修改补充）的责任，这个过程中，就算产品负责人是团队成员的行政上级，也是按同级的身份参与。 这同样是最高效率的需求评审类型之一，最高效特征有交流反馈快，颗粒度小，针对性强，甚至可结合半成品或者成品来核对。

启示1：需求分析人员和开发人员值得在开发过程中，结合半成品或者成品进行需求桌查，能够更早更快的避免需求理解偏差带来的缺陷。

迭代展示

迭代展示是各敏捷流派共有的实践，常见的做法是在迭代末期向各方干系人展示迭代的成果，甚至直接交付给用户试用或使用。Scrum对此环节有清晰的定义，即是其冲刺（等同于迭代）评审会议：冲刺评审会议在冲刺结束时举行，用以检视所交付的产品增量并按需调整产品待办列表；在冲刺评审会议中，Scrum 团队和相关干系人讨论冲刺中完成的工作；然后，根据完成情况和冲刺期间产品待办列表的变化，与参会人员讨论接下来可能要做的事情来优化价值。值得说明的是对于典型一个月的冲刺，其冲刺评审会议的时间箱是4小时。冲刺评审会议可以算作为需求评审和给客户展示演化的原型[21]。对照到新五维需求评审框架，这是无预审的会议形式、定期的、侧重于管理方面也兼顾技术方面、基于软件运行的非同级评审。 这样的评审也是最高效率的需求评审类型之一，其高效特征有需求以直观运行方式展现，客户或者客户代表参加，当场收集反馈，当场根据反馈来计划未来。

启示2：让客户或者客户代表定期结合软件运行来进行评审，更加直观更能发现改进，可以让客户更加满意。

敏捷需求评审小结

综合以上分析，为便于整体理解，得下表。

表10 敏捷开发下常见需求评审相关实践情况

可以看到，敏捷软件开发常见的需求评审竟然没有采纳任何一种标准评审，顶多可以说对审查和走查有所借鉴。

启示3：为了更高效且更高质量的开发软件，敢于突破原有需求评审标准和权威指南，敢于寻求更高效率的需求评审方式方法。

启示4：根据启示3，结合此新五维需求评审框架，结对定期需求文档或软件运行管理评审是值得推荐的新评审方式。具体是指管理者每几天或每周或每双周与开发人员结对来评审需求相应的状态、进度、困难和风险，具体形式可以采用师徒制、主程序员制、一对一会议等等。

启示5：根据启示4，结合此新五维需求评审框架，非即时按需高频需求文档技术方面同级评审也是值得推荐的新评审方式。结合需求条目化管理工具，可以实现逐个需求的同级评审。

启示6：根据启示4，突破此五维需求评审框架，值得寻求其它更高效更人性化的需求评审方式，比如将游戏做法、积分升级等等引入到评审中。

启示7：Scrum对于管理评审的应用是关注于当前和下个迭代，缺失对整体更长过程的关注。虽然已经有在Scrum中补充了发布计划和发布燃尽图，但并没有明确定义如何评审或校验，因此值得开展关注整体产品更长时间范围发展的定期管理评审会议。

向作者提问

本订阅号近期其它文章