需求评审五个维度框架分析及其带来的启示-4-需求条目化管理

需求条目化管理是指需求的主体分条目管理，比如对于用例、用户故事、特征点的条目化列表管理，有些工具中条目称为工作项(work item)。条目化管理的特征是1，状态流转实现工作流；2，条目属性字段可定制。3.3节所分析的敏捷开发下的需求绝大多数是已经实现了条目化管理，产品待办列表就是Scrum进行条目化管理的载体。而条目化需求管理并不是敏捷开发的专利，当前已经有不少组织在非敏捷环境下采用条目化需求管理。在需求条目化管理的情况下，按照新需求评审框架，可以识别到如下高效的评审方式。

逐条开展高频非即时技术同级评审

逐条开展高频非即时技术同级评审是指当需求条目到达指定状态（如下图1中的“已分析”）时，邀请相应评审者按工作流功能进行逐条评审，每条评审的结果是独立记录跟踪的。虽然这是非即时评审，但在工具支持下，能够方便的记录评论和发现，相应人员能够自动的收到电子邮件，甚至即时通讯消息，能够像论坛一样评论参与，各方针对指定条目展开线上讨论，这样就获得了部分即时评审的好处。而且非即时评审时间安排更灵活，也更有深入思考的机会，也能留下全部的记录。这点得到了[22]文的支持。
启示13：在需求条目化管理工具帮助下，非即时需求评审可以高效的开展。

全程的需求跟踪评审

全程的需求跟踪评审是指在需求条目化管理下跟踪需求条目的全部生命周期，进行全程关键点的评审。结合需求条目化管理工具的工作流功能，可以对需求条目全程跟踪评审。典型的需求条目工作流如图1所示。

图1 需求条目状态流转示意图

在这样的全程跟踪的情况下，对需求阶段里程碑评审的依赖大大降低，甚至可以不再需要需求阶段里程碑。因为每条需求都得到全程跟踪，每个步骤相当于一次评审。而且随着开发进展，有更多信息帮助进行正确的评审，多个角色参与此全程跟踪，结合图1，跟踪过程见下表
表11 需求条目流程关键点的评审

状态流转	关键点的评审
从草稿到已分析	需求分析人员内部评审（比如同级互查），通过后状态流转到“已分析”，显然这是基于文档的。
从已分析到已评审	由对产品需求负责的人员担当，常见有产品经理、项目经理或者产品负责人，如果工具有并行审批功能，可让多人参与此审批，这相当于需求里程碑评审的签署。
从已评审到已设计	由开发人员跟踪需求得到设计的覆盖，这仍然是基于文档的。
从已设计到已实现	由开发人员内部校验需求是否被正确实现，这是基于软件运行的评审。
从已实现到已核对	由需求分析人员来验证实现是否符合当初的需求，这是基于软件运行的评审。
从已核对到已测试	由测试人员根据测试来校对需求是否得到正确实现，这也是基于软件运行的评审，这里与测试有所重叠，但这里是对需求本身的跟踪，与测试对于测试用例的执行是不一样的，当然可以根据需求对应测试用例的执行结果来跟踪需求。

也即是说，通过条目化管理工具，可以将原来传统瀑布下需求阶段里程碑评审分解到每条需求的多个角色的多次评审，更加全面的保证需求得到实现。
对于需求变更的情况，条目化管理工具天然支持具体内容的需求变更，与需求评审天然的整合在一起。上述需求条目状态流程图中已经支持了需求变更，当发生需求变更时，状态退回到草稿，然后是相同的流转过程，变更得到严谨的归一化管理，这是高效的特征，也满足软件需求变更管理的要求[6][26]。上述整体流程使得各方清晰的承担责任，全过程可审计可回溯，能够及时发现问题，并跟踪直到解决。所以整体流程具备极佳的自适应能力，出现异常或者问题时，各方会迅速联动解决。
根据以上分析，得到如下启示。
启示14：采用需求条目化工具来管理需求，多方全程跟踪评审需求，从文档阅读评审到软件运行评审，多种验证和确认手段得到应用，确保需求得到正确实现，也能及时发现不一致，并且也能灵活的变更。

需求条目化管理下优化瀑布模型

结合以上所有启示来优化瀑布模型，此优化瀑布模型的主要特征是：
1)采用需求条目化管理，采用如图1的需求流程，全程跟踪评审需求；
2)组建产品经理组（可以只有一位产品经理），由产品经理组对需求分批次甚至逐个进行需求评审，多采用离线和双人即时互动方式，不再进行沉重的需求里程碑会议评审，由产品经理根据需要来组织会议讨论评审。部分需求条目到达“已评审”状态后，即可开展设计，全部需求条目到达或超过“已评审”，即是达成需求里程碑；
3)设计的颗粒度为组件与组件之间关系，如有必要，识别到少数核心类，但不要求识别所有类。也即是设计对于需求条目的覆盖是粗粒度的，需求条目能够被识别出的组件覆盖到即可。部分需求条目到达“已设计”状态后，即可开展编码，所有需求条目到达或超过“已设计”即是达成设计里程碑；
4)开发人员进行编码实现。所有需求条目到达或超过“已实现”即是达成实现里程碑。部分需求条目到达“已实现”状态后，即可开展核对；
5)核对是由产品经理组执行，根据代码实现的结果来判断实现是否符合原需求条目。核对不算是测试，只判断主要功能和界面是否符合需求。部分需求条目到达“已核对”状态后，即可开展测试，所有需求条目到达或超过“已核对”即是达成核对里程碑；
6)测试是由测试人员执行。测试用例应当关联到对应的需求条目，需求条目对应的全部测试用例测试通过后，该需求条目可跟踪到“已测试”。当所有需求条目到达“已测试”，即时完成测试里程碑，可以进行后续交付上线等；
7)演示，试用，或者交付上线；
8)以上活动按需求条目分别迭代进行，由于需求条目化管理后的便利性，一个瀑布的时间长度可以像敏捷短迭代一样在1周～8周，可以形象的称为多级小瀑布。
启示15：在需求条目化管理工具的支持下，值得探索和应用多级小瀑布生命周期模型，其兼有传统瀑布模型和敏捷迭代开发的好处，又规避了传统瀑布模型的弊端。
本多级小瀑布模型已经在笔者工作或者辅导过的几家公司实施，取得了良好的效果。原先传统瀑布模型中上下环节衔接问题在需求变更的情况下是巨大的困难。而在多级小瀑布模型下此问题得到了明显的改善。上下游衔接以小颗粒度的需求条目为根据，下游能够及时的针对性的督促上游，也能基于上游先期完成的部分条目尽早开展工作，不必等待上游里程碑结束后再开始；而上游同样能以小颗粒度来跟踪需求条目在后续的情况，及时尽早发现潜在不一致问题。各级上下游形成了高效的、互相监督、互相督促、闭环的自适应机制。