在中国推广敏捷方法的难点

我从2000年开始接触xp，之后看了不少敏捷方法的书，曾试图在两家公司推广敏捷方法，但效果一直不好。我认为在中国推广敏捷方法存在两个仅靠软件公司和技术人员难以克服的困难。

第一个困难主要存在项目范围、进度、成本三个变量的弹性程度上。

所有的敏捷方法，无论是否明确提出，我认为都是要求项目范围、进度、成本是可协商的。拥抱变化意味着：
1. 能随时接受需求变更，但同时也能对项目进度进行相应的调整。
2. 在发现事先制定的项目进度不合理的情况下，能对项目进度进行调整，以完成规划的项目功能。 或者对项目功能范围进行调整，以满足事先制定的项目进度。
也就是说，范围，进度，成本，三个变量，只少要有一个是可变的。而且，当范围或进度发生变化的情况下，成本要仍然保持不变，也是比较困难的。

但目前国内签订的软件委托开发（或称项目外包合同）几乎都是闭口合同（在我所知的范围内）。在合同中都是明确规定项目的交付期限和开发费用的。虽然很多合同不会包含详细的需求规格说明书，或在合同签订的时候不会包含，但往往都会有一份技术附件，规定了系统必须提供的功能。在这个技术附件规定的范围内，对项目功能项的调整和协商的余地都不会是很大的。在范围，进度，成本限定的情况下，无疑地，拥抱变化就意味着拥抱死亡。而不能拥抱变化，那我认为敏捷也就无从谈起了。

所以在签订闭口合同的情况下，软件公司的最佳选择就是尽早完成项目的详细需求分析，然后冻结需求，尽一切方法把用户的需求变更挡回去。这样就不能实现真正的迭代开发。最多只能在分析、设计、开发、测试阶段实现“走了样”的迭代开发。

那么在企业的内部软件开发部门，情况是否会好一些呢。当然，因为是一个企业内，往往不会有硬性的合同规定，在范围、进度、成本这些方面，协商的余地必然会大一些。但情况也未必会好到哪里去。

我曾经在一家国有大型企业下属的软件开发公司工作，该软件公司曾是母公司的内部软件开发部门，后来独立出来的。不过至今其主要业务仍然来自母公司。这种情况在国内是非常多见的。该软件公司无论在独立前，还是独立后，都有一个引以为自豪的口号：“后墙不倒”。“后墙”就是指项目的交付日期，这句口号的意思就是不惜一切代价保证项目按期交付，而不论这个最后期限是多么的不合理，或者根本就是领导拍脑袋的结果。

“后墙不倒”，意味着项目最后期限是没有商量余地的。“后墙不倒”同时也隐含着项目范围也是不可商量的。因为不存在“为了满足最后期限，可以调整项目范围”的规定。 既然“后墙不倒”，那“后墙”以后的开发计划是不存在的，因此必须在最后期限交付事先规划的所有功能。把某些功能移到最后期限以后，也意味着对“后墙不倒”这一政策的违反。

能不能对项目范围进行调整，以满足最后期限，则往往取决于项目经理的沟通能力，与项目主管或用户部门的关系，以及用户部门的“通情达理”度。

对内部软件开发部门来说，项目成本方面可以考虑的比较少一些。因此如果项目进度紧，可以多扑一些人上去。但我们都知道，增加开发人员对缩短开发进度的帮助是有限的。

就我所知，上述情况在很多企业的内部软件开发部门都是存在的。对于以承接母公司的软件开发项目为主的独立核算的软件公司来说，情况也差不多。毕竟，项目是否按期完成往往是作为领导和部门业绩考核，发放奖金的依据的。

因此，对于很多企业的内部软件开发部门来说，要完全按照敏捷方法的要求去做，仍然是存在很多制约因素的。

第二个困难在于程序员的素质。
目前无论是正规大学还是职业培训结构培训出来的程序员，普遍缺少面向对象编成的基本概念和基本感觉。这里我说的，不是仅仅知道什么叫类，什么叫继承，而是要能写出基本象样的面向对象程序。而现在很多程序员，即使会用Java，C++，写出来的仍然是面向过程的程序。而现在，无论是从学校，还是从社会，要招到具有一定OOP基础的程序员实在太困难了。

我认为OOP是敏捷的基础。没有OO的基本概念和基本感觉，是没有办法进行诸如TDD, Refactoring这些工作的。没有TDD, Refactoring，也就几乎不可能作到代码共享，短迭代。没有了短迭代，也就没有敏捷了。

目前中国学校的计算机人才教育已经成为了不仅是敏捷方法的推广，也是中国软件行业发展的制约因素。

说明：原发于“Java视线论坛”（http://www.hibernate.org.cn）