敏捷，想说爱你不容易－－从CMM向敏捷过渡的一点体会(欢迎大家讨论)

[ggokind]

http://blog.csdn.net/ggokind/archive/2008/12/23/3591376.aspx

敏捷，是把利剑，用得顺手，可以披荆斩棘；用得不顺手，反倒会伤到自己。
笔者过去经历过一次敏捷开发，有一些体会，说来分享给大家，希望对于大家有所帮助，也请各位对于文章中存在的不足之处发表意见。

项目背景：
开发测试接近40人，以前习惯于传统CMM流程；
开发人员有2/3以上的新员工，开发经验较少，几乎没有设计经验；
需求较为稳定，需要2个团队跨地域合作，两边的交付件存在较强的集成关系。

个人认为，一个成熟度一般的团队，从传统的CMM流程向敏捷过渡的话， 一定要谨慎。下面介绍一些需要注意的地方。请大家参考。

一、需要审视自己的团队，是否具备敏捷能力：
1、是否具备有了足够开发、设计经验的开发团队
这点是重中之重。敏捷对于团队成员要求极高，如果不具备分析能力、设计能力，无法应对的需求变化，无法对于后续的改动进行持续的重构，即使需求没有变化，在一个一个规格被增加进来的时候，对于已有设计的冲击还是有的，起码要考验到架构、模块设计的可拓展性。另外如果产品的性能要求较高，功能正确后的持续重构，提高产品性能的能力一定要具备，否则“抱拥变化”就是空谈。
对于可靠性要求较高或者功能较为复杂的产品，开发人员对于异常流程的理解一定要到位，否则设计时间较短，没有时间考虑这些事情，那么开发的时候开发人员还不具备识别异常流程的能力，只能等待高素质的测试人员通过人工的测试手段保证，代价极为昂贵。
不要指望个别能力突出的开发成员可以起到总揽全局，带动团队完成开发。一旦项目启动，大家都在一个一个的赶工自己的Story，即使开会讨论，也是应该是相互交流性质的，否则就会将能力较强的开发人员陷入协助其他员工检视设计、编码思路的泥潭。久而久之，骨干员工会觉得很累；其他员工虽然每天干得工作不多，但是也是跟在别人后面忙忙碌碌，精神上很疲惫，个人能力方面得到的提升也不是很明显。
2、是否可以保证对于持续集成，自动测试的投入
无法保证这两点，敏捷开发、迭代开发就是在扯淡。例如，迭代2为了拓展新功能重构了一下基本功能模块，那么迭代1的功能是否需要重新测试？如果没有覆盖层面较高（覆盖了UT、IT、ST）的自动测试的话，答案就是：恭喜你，每个迭代你都需要重新手动测试所有功能。恶梦一样的测试。
持续集成还是较为容易的，关键在于自动测试的层面。我们这个项目自动测试层面仅为UT（单元测试），个人认为，远远不够。起码重要的、基础功能需要做到ST的自动覆盖。尤其是本项目的两个团的之间存在较大的耦合性，任何一个接口上的改动都会导致两边同时发布版本。如果两个团队无法保证自身基于接口能够自动测试的话，一个团队的延时会造成另一个团队的开发进度受阻。
3、是否有对于敏捷有一定认识和积累的领路人或者顾问
咨询大师温伯格说过：使用新东西总是有风险的。
是的，当一个团队向不熟悉的流程迁移的时候，最大的风险就是没有在整个团的层面形成对于该流程的全面的、一致的认识。这点相当可怕。CMM是严谨，过程化的，但是同时附带了一些枷锁（各种规定，各种文档）；对于枷锁深恶痛绝的人们看到敏捷过程后，惊呼：终于可以抛掉这些该死的枷锁了。但是同时，过于灵活的流程中，缺乏经验的人们反倒无所适从，下一步该做什么？该怎么做？甚至项目的骨干们对于当前的各种事情也没有了清晰的优先级的划分，大家对于敏捷的理解都源于书本，理解得有都不一致。
“敏捷应该这样”，“敏捷应该那样”，当发生了这种争论的时候，请注意，你的团队面临者一种失去方向的风险。有的时候先选择一个方向走下去，也许是最快捷、代价最小的选择。
在没有具备上述必备条件的时候，最好不好考虑上来就彻底的敏捷，循序渐进的向敏捷演进应该是更好的办法
二、审视一下我们需要敏捷给我们带来什么变化。
在决定彻底采用敏捷开发之前，还是请审视一下自己的团队需要敏捷开发给带来什么好处？是否现有的CMM流程中融入一些敏捷的思路和实践就可以达到？如果可以的话，建议采用稳健的方式向敏捷过渡。尽量不要有“一步跳进共产主义社会”的想法。

[suilj]

“ 需求较为稳定”

还记得为什么会出现敏捷方法吗？
任何方法论都有其适用的情况，不必为了敏捷而敏捷

[ggokind]

这也是我质疑此次采用“敏捷”的原因之一。
我们项目能从敏捷中受益的绝对不是抵御频繁需求变化的风险。

[严于律人宽于待己]

整个团队40人，感觉这么大的一个项目做试点有点大了；
新员工多且无开发&敏捷经验，让处于学习阶段的团队去做超越(以往开发过程)级别的事是很疯狂的一件事；
需要跨团队跨地域合作，合作一次难度就不小了，如果在迭代中多次合作磨合起来很难。

[严于律人宽于待己]

认同测试自动化对于迭代/敏捷来说重要性极高。
一般敏捷方法提到的UT有一定的字面欺骗性，他是比传统的纯UT范围大的开发者测试（包含UT、IT以及适合项目组做的ST），
单个人要做好自己的测试，
整个project要做好持续集成，
专职的测试人员要做好验收测试，
这些测试最好都是自动化的，所以XP实质上是更纪律化的方法，严格执行起来估计和CMM一样惹人嫌:-)

[以专业开发人员为伍]

楼主说他们的40人的团队是尝试了一把“敏捷”，我看纯粹是书本知识上的敏捷。他所说的内容，从我参与过的少则5个人多则超过100个人的项目，都是有过的，那写项目的组织都是泛泛而已（根据当时的需要来），我没有看出他们真的敏捷过了。我看他们不过是做了两件事：

1. 强调了一次UT，强调和普及UT这竟然可以让一些程序员感到很新奇？这是悲哀。写断言或者UT应该是程序员的基本素质，跟项目组使用什么管理方式无关。项目组如果想敏捷，就从强调提前进行ST开发开始。首先写好ST程序，然后直接运行，此时肯定不能运行，因为根本编译不过去（连基本的class、interface都没有写呢）。然后程序员的职责就是写代码，让测试最终通过。一旦测试通过，这个任务就完成了。所以，敏捷所谓测试驱动开发，此种开发不是先实现功能代码然后考虑测试，而是先写测试然后让测试可以通过。质量管理过程完全倒过来了。

2. 强调了迭代但是纯粹是空谈迭代。如果内部开发过程没有配套的技术，空谈迭代反倒真的是鼠目寸光、想到哪里写到哪里去了的。

[以专业开发人员为伍]

连基本的class、interface都没有写呢 -> 连基本的class、interface都只有初步的面向ST的接口没有写任何实现和补充呢

[以专业开发人员为伍]

我可以放一个“狠话”，传统的测试理念放到让敏捷团队里，变成臭味是一定的了。

[ggokind]

非常赞同sp1234所说的："楼主说他们的40人的团队是尝试了一把“敏捷”，我看纯粹是书本知识上的敏捷。"
sp1234的意见一针见血，我始终在向PL提醒：到底哪里敏捷了？一些形式上的东西不能说明真的就敏捷了。

这里交代一个信息，项目过程中一个项目组是印度团队，印度团队对于敏捷非常热衷，但是我认为不符合敏捷的入口条件：人这个因素不满足要求。
敏捷的形式，CMM的质量控制，较为初级的人员素质（PL素质尚可，但是对于敏捷的认识过于肤浅，对于人员的培养，丝毫没有建树），结合在一起，“变成臭味”算是很客气的说法了:)。

[xhan2000]

有道理

[以专业开发人员为伍]

每当看到一些测试论坛上动不动就“UT->IT->ST”，我往往没有一点对此测试认同的感觉。从单元测试开始？那么还体现什么story？很多时候，说的头头是道并不能保证做的时候保持一致。我们才能够一个用户与系统交互脚本开始计划测试，那么核心就是就要掌握写出模拟交互操作的测试程序的技术，而单元测试只能给出一点点次要的功能测试结果。

[以专业开发人员为伍]

我们才能够一个用户与系统交互脚本开始计划测试 --> 认清测试驱动不是从单元测试而是从交互系统集成测试来驱动，我们才能够一个用户与系统交互脚本开始计划测试

[以专业开发人员为伍]

实际上，首先写好ST并且评估ST是否达到了Story的要求这才是涉及客户交互的系统开发的测试驱动管理的先决条件。编码前最后时刻才写UT，甚至很多时候不用写UT而是直接在源代码中插入大量断言（这基本上可以消除UT的必要）。

许多人费劲精力写了许多UT，然后把ST放在系统后期而且此时往往已经感觉到黔驴技穷不知道改怎样写ST或者找出无数理由来证明不需要费力气做ST了，这哪里还有敏捷，哪里把脚本测试策略放到实现功能之前去开发了呢？典型的非敏捷做法。

[ACMAIN_CHM]

的确很难

[以专业开发人员为伍]

大家都知道照抄测试书上的V字形模型，但是第一个斜杠中仅仅是做形式上的所谓测试计划，这就给很多人提供了模糊测试技术的借口。其实敏捷就是在第一个斜杠时写出测试程序的高层代码，而不是仅仅做所谓计划。

[书中的虫子]

很受教。以前听过微软的项目管理模式课，跟敏捷开发的观点有些类似，在每次程序员提交成果后都对系统（未完成开发）进行测试，以保证提交的模块不会降低整个系统的质量。测试周期以天为单位，对测试工作提出很高要求，如果没有详细的测试计划和方案、自动化测试工具，简直无法想象。

其实，很多国内的开发人员在说使用什么开发模式（XP、RUP、敏捷开发）时，都是理论的东西多，或者说很机械的搬书进行操作。而实际上开发水平、人员素质都不具备的时候，实施这些模式实际上能有多少效果，也就难说的很了。

[DJ2008]

学习了，顶一个

[selam123]

学习。
不过 敏捷，现在还不太适合我们呢吗？
敏捷的各方面要求都很高吗？