W
wangfu
Unregistered / Unconfirmed
GUEST, unregistred user!
为什么要在中国大力推广XP？
为了有效地解决这些情况：
客户总是有新要求，而且要求经常变；
到期交不了货或者交付的系统中BUG一大堆；
程序员做到一半就跳槽了，他写的程序其他人很难读懂，改起来也很难；
每天不知道到底能完成多少需求，或者这些需求什么时候才能真正完成，老是要加班；
每个人在项目里埋头干自己的一块，很少也很难相互学习，老是做重复的开发，开发人员的总体水
平提高不快；
程序员不愿意写文档，写出的文档经常不能真实地反映实际情况；
项目接得很多，但开发成本也增加得很快，开发效率上不去；
……
和传统的软件开发方法（如ISO 900X？）相比，XP从许多方面对软件开发的方式作了新的诠释和重构，
从而更加灵活有效地解决这些问题；而且，因为XP特别强调交流、反馈和合作，XP更加适合国内众多的
小规模开发队伍。
传统的重量级软件方法是对传统工程的开发方法的模仿，例如建造桥梁、高楼大厦等等。首先，开发方
要知道客户的需求，比如多大的面积、多少层、什么用途、什么风格等等，还要现场测量、钻孔等等；
然后设计人员画出一些图，向客户描述将来建好了是什么样子；客户满意了，就进入下一个设计阶段，
设计人员又弄出很多工程图纸，详细地说明这块应该如何做，那块应该如何做；接着施工人员一丝不苟
地按照图纸开工，施工过程中也有各种验收；最后做完了由客户验收，客户可能还会请一个第三方帮助
验收。
如果每个软件开发项目都和建大楼一样，当然可以而且应当使用一样的开发流程和管理方法，因为这套
流程已经被无数次地重复证明了是可行的。但软件项目有自己的特点：
1、和建大楼相比，大部分软件开发项目的投资要少很多，工期要短多很多，人员要少很多；
2、水泥、钢材、砖等很多建筑材料，很难在短期内重用，而代码和设计可以被重用；
3、大楼动工后，设计就很少再“优化”了，也不能出现什么“验收或测试时系统崩溃”的情况（如果
出现，那一定是大事了），而这些情况在软件开发中却比较常见；
4、软件开发过程中，客户很有可能提出新的迫切的需求，取消或改变原来的需求；
5、软件开发的需求相对建楼，要模糊很多，往往不能量化。而软件开发过程自始至终都是以脑力劳动
为主，开发速度也很难量化，因而开发计划也很难做得准确；
6、因为软件开发项目的人数比较少（超过10个程序员的项目绝对是大项目），每个人员的流动都可能
会对项目进度造成很大影响；
7、软件开发中的“偷工减料”更难发现。
还有很多其它重要的区别，但我们仅从以上几点就能很容易地发现，传统的重量级开发方法只能适合部
分软件开发项目。
而且，传统的重量级软件开发方法还有很多其它的局限，诸如：
1、客户和需求：开发人员不喜欢需求变化，以至于对客户有潜意识的抵触情绪。虽然大家表面上相处
得很好，一旦客户提出了新需求或者更改原有的需求，开发人员会不高兴，有时还会和客户发生激烈的
争执，而客户则甚至会以不付钱来威胁开发方答应自己的要求。
2、代码质量：程序员在写完成程序后，不能马上知道自己的程序是不是达到了要求。虽然有QA，但客
户总是发现这样或那样的错误，甚至在过了Deadline的一个月以后，程序员们还在不时地修补错误，而
且不知道这些修补工作是否又会引起新的错误。
3、文档：虽然传统的开发方法中规定了要这样那样的文档，如需求分析、概要设计、详细设计、程序
注释、白盒测试文档等等，但程序员的工作主要是开发，没有哪个人喜欢写文档。而且，不少时候，设
计变了、程序变了，相应的文档却没人去修改。时间越久，文档就越不符合实际情况，到最后，很多文
档都变成没人想看的垃圾。
4、人员流动和开发维护：开发时，通常是各自做各自的模块，一般情况下，没有人会去改其他人写的
程序；维护时，如果出现了什么问题，一般是谁写的就由谁去维护。很多程序员宁愿重写也不愿维护其
他人的程序。如果一个写某个复杂模块的程序员走了，又没有足够详细的说明，那接着写或维护这个程
序就很棘手了：接手的人有时刚改动了一个自己认为无关紧要的地方，程序就出错了，而自己还不知道
究竟错在哪里；即使当时没有出错，心里也不肯定是不是又潜在的BUG。因此，开发人员的流动给开发
和维护都带来很大的影响，传统的软件工程方法不能很好地解决这个问题。
由于上述种种原因，开发人员一直尝试着改进传统的开发方法。而且，因为软件开发方法是控制开发成
本的一个直接、重要的手段，软件项目、开发公司等的管理人员们也一直在做同样的努力。Extreme
Programming就是基于这些迫切的需求而产生的。
Extreme Programming可以被看作是一种面向User Story的开发模式，它揉合并发扬了很多其它开发模
式的优点。为了面对需求变化，它象增量型的开发模式那样，将开发过程分解成一个个小的Release和
Iteration，每个Iteration都实现了部分需求，每个Iteration中都会发布新的系统。XP引入了螺旋型
开发方法中的风险评估思想，依据商业价值和开发风险制订各项计划。XP通过测试优先于编程（Write
Test First）、Pair Programming、代码集体拥有制（Collective Code Ownership）和Refactoring来
保证设计和代码的质量；其中，测试优先、Pair Programming和代码集体拥有制也降低了人员流动带来
的风险，加强开发人员之间的知识交流与相互学习，迅速提高开发效率。通过把客户引入开发小组
（On-site Customer）、频繁地小规模发布（Small Release）以及验收测试（Functional Test /
Acceptance Test），XP强化了开发人员和客户之间的交流和反馈，更好地满足了客户需求。
而且，因为XP特别强调交流、反馈等以人为本的思想，而人数越少交流越容易，所以XP特别适合小规模
开发队伍。国内的广大中小型软件开发公司中，通常一个开发小组不会超过6人，因此很适合用这种开
发方法。
基于上述种种原因，我们认为，XP很适合国内软件业的需求，我们应该努力推广以XP为代表的众多轻量
级软件开发方法。
为了有效地解决这些情况：
客户总是有新要求，而且要求经常变；
到期交不了货或者交付的系统中BUG一大堆；
程序员做到一半就跳槽了，他写的程序其他人很难读懂，改起来也很难；
每天不知道到底能完成多少需求，或者这些需求什么时候才能真正完成，老是要加班；
每个人在项目里埋头干自己的一块，很少也很难相互学习，老是做重复的开发，开发人员的总体水
平提高不快；
程序员不愿意写文档，写出的文档经常不能真实地反映实际情况；
项目接得很多，但开发成本也增加得很快，开发效率上不去；
……
和传统的软件开发方法（如ISO 900X？）相比，XP从许多方面对软件开发的方式作了新的诠释和重构，
从而更加灵活有效地解决这些问题；而且，因为XP特别强调交流、反馈和合作，XP更加适合国内众多的
小规模开发队伍。
传统的重量级软件方法是对传统工程的开发方法的模仿，例如建造桥梁、高楼大厦等等。首先，开发方
要知道客户的需求，比如多大的面积、多少层、什么用途、什么风格等等，还要现场测量、钻孔等等；
然后设计人员画出一些图，向客户描述将来建好了是什么样子；客户满意了，就进入下一个设计阶段，
设计人员又弄出很多工程图纸，详细地说明这块应该如何做，那块应该如何做；接着施工人员一丝不苟
地按照图纸开工，施工过程中也有各种验收；最后做完了由客户验收，客户可能还会请一个第三方帮助
验收。
如果每个软件开发项目都和建大楼一样，当然可以而且应当使用一样的开发流程和管理方法，因为这套
流程已经被无数次地重复证明了是可行的。但软件项目有自己的特点：
1、和建大楼相比，大部分软件开发项目的投资要少很多，工期要短多很多，人员要少很多；
2、水泥、钢材、砖等很多建筑材料，很难在短期内重用，而代码和设计可以被重用；
3、大楼动工后，设计就很少再“优化”了，也不能出现什么“验收或测试时系统崩溃”的情况（如果
出现，那一定是大事了），而这些情况在软件开发中却比较常见；
4、软件开发过程中，客户很有可能提出新的迫切的需求，取消或改变原来的需求；
5、软件开发的需求相对建楼，要模糊很多，往往不能量化。而软件开发过程自始至终都是以脑力劳动
为主，开发速度也很难量化，因而开发计划也很难做得准确；
6、因为软件开发项目的人数比较少（超过10个程序员的项目绝对是大项目），每个人员的流动都可能
会对项目进度造成很大影响；
7、软件开发中的“偷工减料”更难发现。
还有很多其它重要的区别，但我们仅从以上几点就能很容易地发现，传统的重量级开发方法只能适合部
分软件开发项目。
而且，传统的重量级软件开发方法还有很多其它的局限，诸如：
1、客户和需求：开发人员不喜欢需求变化，以至于对客户有潜意识的抵触情绪。虽然大家表面上相处
得很好，一旦客户提出了新需求或者更改原有的需求，开发人员会不高兴，有时还会和客户发生激烈的
争执，而客户则甚至会以不付钱来威胁开发方答应自己的要求。
2、代码质量：程序员在写完成程序后，不能马上知道自己的程序是不是达到了要求。虽然有QA，但客
户总是发现这样或那样的错误，甚至在过了Deadline的一个月以后，程序员们还在不时地修补错误，而
且不知道这些修补工作是否又会引起新的错误。
3、文档：虽然传统的开发方法中规定了要这样那样的文档，如需求分析、概要设计、详细设计、程序
注释、白盒测试文档等等，但程序员的工作主要是开发，没有哪个人喜欢写文档。而且，不少时候，设
计变了、程序变了，相应的文档却没人去修改。时间越久，文档就越不符合实际情况，到最后，很多文
档都变成没人想看的垃圾。
4、人员流动和开发维护：开发时，通常是各自做各自的模块，一般情况下，没有人会去改其他人写的
程序；维护时，如果出现了什么问题，一般是谁写的就由谁去维护。很多程序员宁愿重写也不愿维护其
他人的程序。如果一个写某个复杂模块的程序员走了，又没有足够详细的说明，那接着写或维护这个程
序就很棘手了：接手的人有时刚改动了一个自己认为无关紧要的地方，程序就出错了，而自己还不知道
究竟错在哪里；即使当时没有出错，心里也不肯定是不是又潜在的BUG。因此，开发人员的流动给开发
和维护都带来很大的影响，传统的软件工程方法不能很好地解决这个问题。
由于上述种种原因，开发人员一直尝试着改进传统的开发方法。而且，因为软件开发方法是控制开发成
本的一个直接、重要的手段，软件项目、开发公司等的管理人员们也一直在做同样的努力。Extreme
Programming就是基于这些迫切的需求而产生的。
Extreme Programming可以被看作是一种面向User Story的开发模式，它揉合并发扬了很多其它开发模
式的优点。为了面对需求变化，它象增量型的开发模式那样，将开发过程分解成一个个小的Release和
Iteration，每个Iteration都实现了部分需求，每个Iteration中都会发布新的系统。XP引入了螺旋型
开发方法中的风险评估思想，依据商业价值和开发风险制订各项计划。XP通过测试优先于编程（Write
Test First）、Pair Programming、代码集体拥有制（Collective Code Ownership）和Refactoring来
保证设计和代码的质量；其中，测试优先、Pair Programming和代码集体拥有制也降低了人员流动带来
的风险，加强开发人员之间的知识交流与相互学习，迅速提高开发效率。通过把客户引入开发小组
（On-site Customer）、频繁地小规模发布（Small Release）以及验收测试（Functional Test /
Acceptance Test），XP强化了开发人员和客户之间的交流和反馈，更好地满足了客户需求。
而且，因为XP特别强调交流、反馈等以人为本的思想，而人数越少交流越容易，所以XP特别适合小规模
开发队伍。国内的广大中小型软件开发公司中，通常一个开发小组不会超过6人，因此很适合用这种开
发方法。
基于上述种种原因，我们认为，XP很适合国内软件业的需求，我们应该努力推广以XP为代表的众多轻量
级软件开发方法。
