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