敏捷项目管理工具(11.30)

今天是11月的最后一天，也完成了自己连续不间断的半年6个月跑步计划，在12月准备进行下休整和调理。今天主要谈下敏捷项目管理软件和工具里面的以下关键业务对象和关键功能。

需求-产品-项目-任务-用户故事-测试用例

这个可以说是整个敏捷开发过程管理的一个关键业务对象链条。我们再来对这个关键对象链条做下说明。

定义一个产品，产品是一个总的概念，一个产品下会有诸多的产品需求，或者说需求提交上来后应该属于某一个产品。产品本身会涉及道产品版本规划，产品版本往往是产品通用性的功能迭代。

一个产品下面有很多需求，对于需求的实现我们需要安排到具体的项目里面。

项目本身也有项目版本，一个项目版本本身可以关联多个产品需求。将多个产品需求规划到一个项目迭代版本里面，后续的重点就是项目的计划，任务和跟踪。

产品需求需要细分为用户故事，往往产品需求并不一定到用户故事的粒度，因此建议是产品需求本身有一层细分能力，即将产品需求拆分为粒度更小的用户故事。后续的驱动和跟踪完全以用户故事为最终的粒度。即设计，开发，测试等完全围绕用户故事而进行。

项目版本规划好后，涉及到任务安排，任务仍然是基于用户故事为粒度，但是任务本身分了不同的类型，不如一个最小化的用户故事点，往往也涉及到前端开发，后端开发，数据库设计，测试用例编写，测试执行等细分的任务，但是这些任务本身完全是基于用户故事展开和跟踪。

即我们基于用户故事进行工作量估算，任务拆分，进行测试用例编写等动作，形成细粒度的任务跟踪。

项目和项目版本本身又是两个概念。

即我们首先要有项目的概念，再有项目版本的概念，比如我们同样的ESB产品，可能会涉及到移动和联通两个客户，那么就是两个独立的项目。但是两个客户都会存在定制开发，因此在移动项目下会规划V1, V2等不同的版本，在联通项目下也会规划不同的版本。

如果是通用性的功能开发，实际上就属于通用项目下规划版本来展开，表示新功能开发适合所有项目。

简单来说就是先收集需求，然后再将需求规划到不同的项目版本里面，再进行任务分解和安排，最后对任务执行跟踪和监控。同时以用户故事为最小化跟踪单位完成全流程的跟踪和监控。

项目集或项目群

一个项目群可以关联多个项目，实际上这种关联是一种弱关联。起到的作用就是我们可以根据项目集进行相应的项目授权和安全管理，可以根据项目集进行相应的统计分析。可以总体视角来看一个项目集的交付过程。

举例来说

我们是一个团队，团队成员同时兼顾了三个项目，那么我们建立一个项目集，加入最底层的三个项目，那么我们就能够对整个团队建立可视化的工作进度和绩效看板，实时了解整个团队的情况。或者说，我们面对现场一个客户，但是该客户同时采购我们我们SOA，MDM，BPM三个子产品，那么我们可以将三个子产品对应的项目加入到一个项目集中进行统一管理，这样我们就能够很方便的看到整体项目集交付进度。

项目集管理不会复杂到传统项目组合管理里面那么复杂，体现一种弱关联和数据聚合。

缺陷管理能力

缺陷管理是研发过程管理里面的一个重点功能。简单来说就是Bug的提交和跟踪。

需求会对应到测试用例，而实际的缺陷又基于某个测试用例。通过这种方式建立了用户故事-》测试用例-》缺陷之间的关联和映射关系。

缺陷提交后需要进行审核，或处理指派，由开发人员修改完成缺陷后转到待部署状态，由部署完成后转回到测试人员进行验证和最终关闭。而这个缺陷状态流转过程，需要结合DevOps实现一个自动化状态流转。

变更管理

需求本身就包括了新增需求和变更需求，实际上对应需求提交和处理分析流程完全用一套，同时支持新增需求和变更需求。唯一就是对应变更需求需要增加变更影响分析。在微服务架构下，变更影响分析需要分析到究竟影响到哪些微服务模块，哪些具体的责任人，然后基于该影响分析进行任务拆分，在任务拆分后再进行任务跟踪。

那么如果对于前后端开发分离的情况下，一个变更就需要在前后端配套的修改都全部完成后才能够进行完整的黑盒功能测试。但是在后端功能完成后我们已经可以进行自动化的接口单元测试。