需求条目化管理是指需求的主体分条目管理，比如对于用例、用户故事、特征点的条目化列表管理，有些工具中条目称为工作项(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：在需求条目化管理工具的支持下，值得探索和应用多级小瀑布生命周期模型，其兼有传统瀑布模型和敏捷迭代开发的好处，又规避了传统瀑布模型的弊端。
本多级小瀑布模型已经在笔者工作或者辅导过的几家公司实施，取得了良好的效果。原先传统瀑布模型中上下环节衔接问题在需求变更的情况下是巨大的困难。而在多级小瀑布模型下此问题得到了明显的改善。上下游衔接以小颗粒度的需求条目为根据，下游能够及时的针对性的督促上游，也能基于上游先期完成的部分条目尽早开展工作，不必等待上游里程碑结束后再开始；而上游同样能以小颗粒度来跟踪需求条目在后续的情况，及时尽早发现潜在不一致问题。各级上下游形成了高效的、互相监督、互相督促、闭环的自适应机制。

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

需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法,全面涵盖系统性评审和非系统性评审,提出五维需求评审框架. 首先确定对于需求评审的定义,结合传统需求阶段评审和敏捷迭代开发中相关需求实践,得如下定义. 定义 ...
需求评审五个维度框架分析及其带来的启示-5-结束语
本文整理归纳了需求评审的各种类型,分析识别了需求评审的5大关键方面,提出了五维需求评审框架,并分析验证了此新需求评审框架的有效性.结合此新需求评审框架,对软件开发主要情境进行了分析,得到了15个高效需 ...
需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指软件开发的常见情境,本文选择如下来进行分析: 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审传统瀑布模型下的需求评审对 ...
需求评审五个维度框架分析及其带来的启示-总起
摘要近年来随着CMMI.敏捷软件开发的推进,出现了多种多样的需求评审类型,这些类型超出了标准评审类型的范围.根据这些情况进行分析,得到了一个新的软件需求评审框架,这个新框架由5个维度组成: 1,组织 ...
如何进行需求测试/需求评审
由于软件系统的复杂性,在需求分析阶段可能存在着开发方对委托方业务需求理解不全面.不准确的情况.在这种情况下,如果不进行相关的质量控制,往往会造成开发结果与用户需求不一致的后果.需求测试的目的就在于保证 ...
测试人员如何进行需求评审
最近一直在忙于各种工作上的事情,加上周末设计与录制在腾讯课堂上放的各种课程,没有太多的去写文档,以至于最近微信公众号上发布的都是以往收集的内容.鉴于最近在和大家交流的过程中,发现不少同学的功能测试的基 ...
一文掌握需求评审常见难题及改进策略【一杯咖啡谈项目】
在IT软件行业,软件需求是软件产品开发最重要的输入,需求风险也常常是软件开发过程中最大的一个风险. 降低需求风险的重要手段之一就是需求评审,但是需求评审是所有的管理评审活动中最难的,也是最容易被忽视的 ...
软件项目中如何开展有效的需求评审
1.需求评审的重要性在软件项目中,需求分析是最开始的工作,同时也是最重要的工作.需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将 ...
图解项目产品需求评审流程及详细的评审规范实例
项目过程中产品需求评审至关重要,需求评审会议组织的如何直接决定了后续项目的实施是否顺利,而产品评审流程设置的如何直接考验了项目经理的管理水平,今天分享给大家一个产品需求评审流程图及详细的说明实例,供大 ...

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

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

全程的需求跟踪评审

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

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

最新文章

热门文章