http://blog.csdn.net/ggokind/archive/2010/06/07/5654173.aspx
一点心得，大家分享。
公司推“敏捷”了，我们的产品“被敏捷”了。
本人所在的子产品，在经历过几个版本的对于敏捷的自行摸索之后，随着整个产品进入了浩荡的敏捷进程，后CMM时代拉开序幕。
前段时间公司内部针对敏捷培训，本来不屑这种材料，但是仔细看过之后，我对项目成员说，这个材料的是公司下大力气准备的，很多敏捷的误区都是前期各版本我们所经历过的。如敏捷准备度（自动测试，持续集成），不要将敏捷活动当做走过场等等。
敏捷开始，在敏捷开始前，需求分析、界面设计、外部系统接口、内部模块间设计基本完成。
近期一次敏捷回顾。发现几个问题，让我感触颇多。
1、敏捷活动中，模块级设计方案由谁来写？
大家认可部分story是需要写一些设计文档的。
项目成员普遍认为，应该由“专业”的设计人员来写作模块设计文档，并给出专门的时间。
理由如下：
1）项目成员自认为对于本系统没有全面认知，无法承担模块设计工作
2）每个story时间并不充裕，算上写设计的时间，消耗比较多，对于绩效而言，不是好事
2、敏捷过程中的测试活动由谁来做？测试人员还是开发人员？
先说明一下，我们产品敏捷之后，开发测试在团队管理上逐步融合，但是技能上差距很大。
说说我的看法。
在开发团队不具备一定快速设计能力、持续重构能力、自动测试能力的情况下，强行上马敏捷，代价很大，效果一般。
1、开发团队不具备快速设计能力，在需求、外部接口、整体方案明确的情况下，无法快速给出模块级设计方案，或者直接构思出代码实施方案，基本无法满足敏捷快速开发、快速交付的要求。团队中具备设计能力的人员，将会不堪重负。成为团队向前推进 的瓶颈
2、持续重构能力不具备，对于快速设计方案，在需求变化情况下，无法迅速的进行代码重构、解决技术债务，同时应对新的变化。在后续迭代中，将会举步维艰，渐行渐慢。
3、不具备自动测试能力，随着迭代交付的进行，修改引入问题将会无法得到有效控制，敏捷过程中通过手动测试基本是人力上无法承担的。
4、开发成员，不具备基本的测试技能。将会直接影响开发质量。传统的CMMV字形过程的中，开发人员要针对SRS、HLD、LLD进行对应的测试设计和测试活动：ST、IT、UT。从流程上能够牵引开发人员主动思考基本测试原则。如果敏捷过程中一味依赖原有测试人员进行把关，相当于去除了UT和 IT，直接让测试人员ST。效果可想而知。
时间有些晚了，先谢这么多吧，后面有时间，再续。
------解决方案--------------------------------------------------------
欢迎分享～～
在成熟的开放架构下进行敏捷开发是比较现实的
如果连框架都没有的话，就很不好做了
------解决方案--------------------------------------------------------
基本上来说,我的观点也是,如果从来没有完整地走过至少一次瀑布的话,讲敏捷其实是扯淡.
------解决方案--------------------------------------------------------
学习了。
------解决方案--------------------------------------------------------
除这句话外，其他是同意的