那些年向前冲|从用户故事地图到Scrum敏捷研发管理( 五 ) 作者：人月神话

所有上面的对应后面都会方面我们进行研发过程度量分析使用。
关键功能和差异分析
首先项目和项目版本的概念分离，即项目版本即对应到迭代版本或迭代这个对象上面。
一个产品可以对应多个项目，项目可以是内部研发项目，客户是我们自己，也可以是外部项目对应具体的客户。当是内部研发项目的时候，研发完成后往往升级产品版本。
项目创建的时候重点是给出项目的执行周期，项目对应的客户，项目对应的产品，项目中的团队成员等关键信息。在项目规划完成后，规划具体的项目版本，比如南方电网ESB项目V0.1版本，南方电网ESB项目V0.2版本，
具体的需求注意不挂接在项目下面，而是必须挂接到项目版本下面。
对于版本启用大版本和小版本，注意大版本是可以直接发到客户的版本，小版本为内部版本，当然小版本还可以规划为小版本和迭代版本两个版本段。
我们来看下具体的场景，当前已经有了标准的ESB V1.0产品版本，当我们接到南方电网ESB项目后，我们首先要录入南网ESB项目，同时录入一个V0.1项目版本。然后我们将需求先录入到产品下面，录入到产品下面的意思就是一个需求可以规划到该产品下面不同的项目版本中。
我们来分析下，如果录入了20个需求点，其中5个是标准化产品需求， 15个为定制需求，同时15个定制需求我们准备分三个迭代版本来进行实现。基于上面这个场景，具体操作应该是：

选择ESB产品，在产品中录入具体的15个已经拆分后的需求功能点
新创建研发项目V0.1版本，新创建南网项目V0.1, 0.2和0.3版本
分别将上面的20个需求纳入到具体的四个项目版本中
南网项目单独拉一个分支，同时注意对于项目版本的修改需要merge到南网项目分支上

这个梳理清楚后，我们再来看关键的需求到任务的关系。
我们举个简单的例子来看：
服务实例查询是一个独立的需求功能点，那么针对这个功能点就需要拆分任务，在这里我们建议增加一个批量添加任务的功能，即针对一个需求功能点，往往存在需求，设计，编码，测试设计，测试执行，或者开发会进一步分为前端开发，后端开发。我们只需要选择存在哪些步骤，然后基于这些步骤来自动创建相应的任务名称。同时任务和人员有匹配，如果任务类型在该项目下只有一个该类型人员，则可以直接将任务默认安排到该人员。即实际可能拆分完成后为：

服务实例查询-需求开发 -- 张三
服务实例查询-编码 -- 李四
服务实例查询-测试用例编写 -- 王五
服务实例查询-测试执行 -- 王五

我们再来看下scrum里面的敏捷看板管理，一种最简单的方法就是userstory ， todo, doing, done几个关键状态进行管理，而实际上我们可以进行更细化的开发过程状态跟踪。即需求故事，待开发（任务清单），开发中，测试中，完成几个关键状态。
即我们可以设计为在编码任务，团队人员领取任务后即进入中开发中状态，在开发人员反馈任务完成的时候直接进入到测试中状态，在测试人员反馈测试执行任务完成后进入到已完成状态。跨泳道流转的主体为userStory 。
测试人员具体具体的用户故事点进行测试，测试发现的缺陷录入到缺陷管理模块中，缺陷自然挂接到具体的需求，同时能够关联到具体的项目和项目版本。方便我们后面进行质量分析和项目度量。
敏捷项目管理工具应该具备的核心功能

最后谈下敏捷项目管理软件和工具里面的以下关键业务对象和关键功能。