后CMM时代的思考（1）

公司推“敏捷”了，我们的产品“被敏捷”了。

本人所在的子产品，在经历过几个版本的对于敏捷的自行摸索之后，随着整个产品进入了浩荡的敏捷进程，后CMM时代拉开序幕。

 

前段时间公司内部针对敏捷培训，本来不屑这种材料，但是仔细看过之后，我对项目成员说，这个材料的是公司下大力气准备的，很多敏捷的误区都是前期各版本我们所经历过的。如敏捷准备度（自动测试，持续集成），不要将敏捷活动当做走过场等等。

 

敏捷开始，在敏捷开始前，需求分析、界面设计、外部系统接口、内部模块间设计基本完成。

 

近期一次敏捷回顾。发现几个问题，让我感触颇多。

 

1、敏捷活动中，模块级设计方案由谁来写？

大家认可部分story是需要写一些设计文档的。

项目成员普遍认为，应该由“专业”的设计人员来写作模块设计文档，并给出专门的时间。

理由如下：

1）项目成员自认为对于本系统没有全面认知，无法承担模块设计工作

2）每个story时间并不充裕，算上写设计的时间，消耗比较多，对于绩效而言，不是好事

2、敏捷过程中的测试活动由谁来做？测试人员还是开发人员？

先说明一下，我们产品敏捷之后，开发测试在团队管理上逐步融合，但是技能上差距很大。

 

说说我的看法。

 

在开发团队不具备一定快速设计能力、持续重构能力、自动测试能力的情况下，强行上马敏捷，代价很大，效果一般。

1、开发团队不具备快速设计能力，在需求、外部接口、整体方案明确的情况下，无法快速给出模块级设计方案，或者直接构思出代码实施方案，基本无法满足敏捷快速开发、快速交付的要求。团队中具备设计能力的人员，将会不堪重负。成为团队向前推进 的瓶颈

2、持续重构能力不具备，对于快速设计方案，在需求变化情况下，无法迅速的进行代码重构、解决技术债务，同时应对新的变化。在后续迭代中，将会举步维艰，渐行渐慢。

3、不具备自动测试能力，随着迭代交付的进行，修改引入问题将会无法得到有效控制，敏捷过程中通过手动测试基本是人力上无法承担的。

4、开发成员，不具备基本的测试技能。将会直接影响开发质量。传统的CMMV字形过程的中，开发人员要针对SRS、HLD、LLD进行对应的测试设计和测试活动：ST、IT、UT。从流程上能够牵引开发人员主动思考基本测试原则。如果敏捷过程中一味依赖原有测试人员进行把关，相当于去除了UT和IT，直接让测试人员ST。效果可想而知。

 

时间有些晚了，先谢这么多吧，后面有时间，再续。