1,268
社区成员
发帖
与我相关
我的任务
分享XP 在国内应用的问题
转贴一篇《XP 在国内应用的问题》
来自非程序员第15期
国内的软件开发企业应该如何运用XP，会遇到那些问题呢？
根据XP 的特点，它尤其适合规模小、进度紧、需求变化大、质量要求严的项目。XP 的一切因变而设，出发点就是希望以最高的效率和质量来解决用户眼前的问题，以最大的灵活性和最小的代价来满足用户未来的需要。XP 在如何平衡短期利益和长期利益之间作出了巧妙的选择。当然，和任何一种软件方法一样， XP 也不是万灵药。Beck 曾经建议在以下环境中不宜使用XP[BECK99]：
不能接受XP 文化的组织；
中大型（超过10 个人）的项目和团队；
重构会导致大量开销的应用；
需要很长的编译或测试周期的系统；
不太容易测试的应用；
人员异地分布的物理环境。
我想XP 在国内应用有几种不同程度的实施方式。第一种，全盘接受，严格遵守XP 的定义执行，估计这种方式不太切合实际；第二种，整个开发过程采用XP 的生命周期模型，实行XP 大部分的实践方法，根据实际情况对其中个别做法进行调整或舍弃；第三种，在保持组织原有的开发过程和生命周期模型的情况下，借鉴、采取个别对项目有效的XP 做法。为了不使管理和沟通效率下降，XP 一般适合于开发小项目的小团队。但根据前面的讨论，XP 其实也适用于开发大项目中的子系统或子模块的小组，这时可以根据该模块在整个架构中的依赖关系来确定该小组的用户和需求。具体在何种环境下采用什么方式来实施XP 要根据应用类型、项目特点和组织文化而定。
在XP 的12 种实践方法中，测试驱动、持续集成、简化设计、代码规范、现场客户、每周40 小时工作制、小型发布都是我们应该积极提倡和鼓励的，而代码全体拥有、结对编程、重构、隐喻以及计划博弈等做法实施起来要小心，它们并不是在任何情况下都适用的，容易被误用。
目前国内软件开发企业的过程管理水平普遍较低，存在大量轻视或忽视需求、架构、文档、测试以及开发文化和制度建设的现象，许多管理者和开发者不知道在提高开发效率和软件质量方面应该做些什么、如何去做。
举个例子，国内常见的“噩梦”项目一般是这样开始的：草草地做计划、分析用户需求；接着，为了赶工期、赶进度，过分自信地省略必要和清醒的架构分析与系统设计，直接铺开大范围的编码开发，而且基本上不做文档，只在代码中留下一些难懂的注释；然后，没经过充分、认真的测试就急急忙忙推出运行版本；结果，移交阶段软件缺陷层出不穷，麻烦接二连三，再加上业务、市场和技术的不断变化，客户又老是提出新的功能和修改要求，开发人员只好不停地“重构”代码、到处打补丁（“code and fix”），客户却始终不满意；最终，进度一再延误，开发人员疲于奔命，根本没有工夫顾及产品质量，导致客户抱怨不断，项目似乎落入了黑洞……
对比XP，我们发现，迫于成本和进度的压力，国内的实践其实已经很“轻量化”了——在计划、分析、设计、测试、文档上花的精力和时间很少，但又像实施了半拉子的XP。在各种客观因素和借口的名义下，人们在促进沟通、简化和反馈方面做得很薄弱，勇气却很大，敢于冒由于不规范管理而导致项目失败的风险。指望通过重构来减少投入、改进软件，可是没想到一旦“重构”失败造成的影响和损失反而更大，而依赖于个人英雄和没有测试保证的项目往往是在碰运气。
此外，XP 是一个定义规范的过程方法论。它要求开发团队具备熟练的代码设计技能和严格的测试保障技术，在书中Beck 甚至想当然地假定如今精妙的技术和程序员的技能已经能够满足实施持续设计变更的要求[GLAS01]；再者，XP 的成功实施离不开高度协同的开发文化和环境。那么，国内的软件开发人员是否都已经真正理解了面向对象和模式，掌握了重构和OO 测试技术，习惯了“先写测试，后编码”，在技能和心理上做好了准备来获得XP的价值呢？
鉴于以上原因，尽管XP 有敏捷、高效等种种好处，但是现阶段国内的组织误解、误用XP 的可能性还是很大的。所以，一方面强调提高过程制度化和架构设计的水平，另一方面重视掌握运用敏捷方法的技术和技能，是国内软件开发企业应该面对的双重课题。
结语
在软件学科和许多其它领域中，针对同一个问题，通常至少有两种以上的解决方法。相对于传统的以架构设计为中心的自顶向下过程，XP 方法论的出现则证明了以代码设计为中心的自底向上过程的合理性和有效性，这正是Kent Beck、Ward Cunningham、Ron Jeffries 等XP 倡导者在多年理论探索和成功实践的基础上为我们做出的杰出贡献。
成功实施XP 的关键在于积极有效的管理，对测试驱动编程方式的工具支持，对结对编程的资源保证，用户的积极参与以及对开发人员在项目计划、测试用例编写、重构和结对编程等方面的充分培训。
不过，我对XP 的名称（“极限编程”）有些不以为然。在软件工程的管理和实践中巧妙地掌握各种平衡往往是成功之道，除了帮助吸引更多的眼球外，“极限”（极端）做法究竟有多少可行性？用“XX 编程”命名一个过程方法也真实地反映了它的局限性。
XP 显然值得我们学习、研究和借鉴。不管当代软件项目符合XP 实施条件的程度如何，我们都可以吸收其经验、汲取其价值，从中获益。实际上，CMM、RUP、XP 都不是全新的发明，它们是对几十年来国外软件开发实践成功经验的总结、继承和发展。但是，如果我们不懂得结合实际、灵活运用反而囫囵吞枣、盲目照搬，就会冒
很大的风险。国内软件开发企业尤其应当注重理解、消化这些先进思想方法的外延和内涵，从中学到最佳实践方法，取长补短、持续改进，逐步建立起一套适合自我、行之有效的过程体系。
来自非程序员第15期
国内的软件开发企业应该如何运用XP，会遇到那些问题呢？
根据XP 的特点，它尤其适合规模小、进度紧、需求变化大、质量要求严的项目。XP 的一切因变而设，出发点就是希望以最高的效率和质量来解决用户眼前的问题，以最大的灵活性和最小的代价来满足用户未来的需要。XP 在如何平衡短期利益和长期利益之间作出了巧妙的选择。当然，和任何一种软件方法一样， XP 也不是万灵药。Beck 曾经建议在以下环境中不宜使用XP[BECK99]：
不能接受XP 文化的组织；
中大型（超过10 个人）的项目和团队；
重构会导致大量开销的应用；
需要很长的编译或测试周期的系统；
不太容易测试的应用；
人员异地分布的物理环境。
我想XP 在国内应用有几种不同程度的实施方式。第一种，全盘接受，严格遵守XP 的定义执行，估计这种方式不太切合实际；第二种，整个开发过程采用XP 的生命周期模型，实行XP 大部分的实践方法，根据实际情况对其中个别做法进行调整或舍弃；第三种，在保持组织原有的开发过程和生命周期模型的情况下，借鉴、采取个别对项目有效的XP 做法。为了不使管理和沟通效率下降，XP 一般适合于开发小项目的小团队。但根据前面的讨论，XP 其实也适用于开发大项目中的子系统或子模块的小组，这时可以根据该模块在整个架构中的依赖关系来确定该小组的用户和需求。具体在何种环境下采用什么方式来实施XP 要根据应用类型、项目特点和组织文化而定。
在XP 的12 种实践方法中，测试驱动、持续集成、简化设计、代码规范、现场客户、每周40 小时工作制、小型发布都是我们应该积极提倡和鼓励的，而代码全体拥有、结对编程、重构、隐喻以及计划博弈等做法实施起来要小心，它们并不是在任何情况下都适用的，容易被误用。
目前国内软件开发企业的过程管理水平普遍较低，存在大量轻视或忽视需求、架构、文档、测试以及开发文化和制度建设的现象，许多管理者和开发者不知道在提高开发效率和软件质量方面应该做些什么、如何去做。
举个例子，国内常见的“噩梦”项目一般是这样开始的：草草地做计划、分析用户需求；接着，为了赶工期、赶进度，过分自信地省略必要和清醒的架构分析与系统设计，直接铺开大范围的编码开发，而且基本上不做文档，只在代码中留下一些难懂的注释；然后，没经过充分、认真的测试就急急忙忙推出运行版本；结果，移交阶段软件缺陷层出不穷，麻烦接二连三，再加上业务、市场和技术的不断变化，客户又老是提出新的功能和修改要求，开发人员只好不停地“重构”代码、到处打补丁（“code and fix”），客户却始终不满意；最终，进度一再延误，开发人员疲于奔命，根本没有工夫顾及产品质量，导致客户抱怨不断，项目似乎落入了黑洞……
对比XP，我们发现，迫于成本和进度的压力，国内的实践其实已经很“轻量化”了——在计划、分析、设计、测试、文档上花的精力和时间很少，但又像实施了半拉子的XP。在各种客观因素和借口的名义下，人们在促进沟通、简化和反馈方面做得很薄弱，勇气却很大，敢于冒由于不规范管理而导致项目失败的风险。指望通过重构来减少投入、改进软件，可是没想到一旦“重构”失败造成的影响和损失反而更大，而依赖于个人英雄和没有测试保证的项目往往是在碰运气。
此外，XP 是一个定义规范的过程方法论。它要求开发团队具备熟练的代码设计技能和严格的测试保障技术，在书中Beck 甚至想当然地假定如今精妙的技术和程序员的技能已经能够满足实施持续设计变更的要求[GLAS01]；再者，XP 的成功实施离不开高度协同的开发文化和环境。那么，国内的软件开发人员是否都已经真正理解了面向对象和模式，掌握了重构和OO 测试技术，习惯了“先写测试，后编码”，在技能和心理上做好了准备来获得XP的价值呢？
鉴于以上原因，尽管XP 有敏捷、高效等种种好处，但是现阶段国内的组织误解、误用XP 的可能性还是很大的。所以，一方面强调提高过程制度化和架构设计的水平，另一方面重视掌握运用敏捷方法的技术和技能，是国内软件开发企业应该面对的双重课题。
结语
在软件学科和许多其它领域中，针对同一个问题，通常至少有两种以上的解决方法。相对于传统的以架构设计为中心的自顶向下过程，XP 方法论的出现则证明了以代码设计为中心的自底向上过程的合理性和有效性，这正是Kent Beck、Ward Cunningham、Ron Jeffries 等XP 倡导者在多年理论探索和成功实践的基础上为我们做出的杰出贡献。
成功实施XP 的关键在于积极有效的管理，对测试驱动编程方式的工具支持，对结对编程的资源保证，用户的积极参与以及对开发人员在项目计划、测试用例编写、重构和结对编程等方面的充分培训。
不过，我对XP 的名称（“极限编程”）有些不以为然。在软件工程的管理和实践中巧妙地掌握各种平衡往往是成功之道，除了帮助吸引更多的眼球外，“极限”（极端）做法究竟有多少可行性？用“XX 编程”命名一个过程方法也真实地反映了它的局限性。
XP 显然值得我们学习、研究和借鉴。不管当代软件项目符合XP 实施条件的程度如何，我们都可以吸收其经验、汲取其价值，从中获益。实际上，CMM、RUP、XP 都不是全新的发明，它们是对几十年来国外软件开发实践成功经验的总结、继承和发展。但是，如果我们不懂得结合实际、灵活运用反而囫囵吞枣、盲目照搬，就会冒
很大的风险。国内软件开发企业尤其应当注重理解、消化这些先进思想方法的外延和内涵，从中学到最佳实践方法，取长补短、持续改进，逐步建立起一套适合自我、行之有效的过程体系。
...全文
请发表友善的回复…
发表回复
linghuchonglzq2000 2003-03-03
- 打赏
- 举报
好
sokcyok 2002-07-12
- 打赏
- 举报
好
ozzzzzz 2002-07-12
- 打赏
- 举报
本文如果你把XP换成任何一个软件工程的方法的名称都可以
其实关键还是一个习惯的问题 现在不管怎么样都应该有一个方法被大家接受 作为开发的指导办法 不管是RUP XP或者其他 都应该有一种 我们应该考虑的是 那一种适合各自的团队的情况 考虑实施哪个代价最小 本文章的作者把重构和打补丁混淆了 请注意 而且似乎作者对重构的概念最终也不十分清楚 其实我的看法是重构是一种设计的方法 它的有效实施可以解决我们国内的开发团队的设计薄弱问题 如果说国内的的开发者还没有满总XP的良好习惯 可是我看不出有已经有什么良好习惯可以满足别的方法的实施 作者举出的种种问题都是对所有软件工程的方法都是问题的问题 而不是只针对XP的问题 作者最后也没有说明白XP成功实施的关键是什么 很遗憾 似乎他也不知道是什么 作者似乎想指出一些问题 但是他似乎自己也不知道什么才是问题 很遗憾 UMLCHINA我是一个老读者了 但是最近发现水平有些下降 常常不知所云 看来他们似乎把精力放在培训这些可以带来直接经济利益的的事情上了 但愿我想错了
其实关键还是一个习惯的问题 现在不管怎么样都应该有一个方法被大家接受 作为开发的指导办法 不管是RUP XP或者其他 都应该有一种 我们应该考虑的是 那一种适合各自的团队的情况 考虑实施哪个代价最小 本文章的作者把重构和打补丁混淆了 请注意 而且似乎作者对重构的概念最终也不十分清楚 其实我的看法是重构是一种设计的方法 它的有效实施可以解决我们国内的开发团队的设计薄弱问题 如果说国内的的开发者还没有满总XP的良好习惯 可是我看不出有已经有什么良好习惯可以满足别的方法的实施 作者举出的种种问题都是对所有软件工程的方法都是问题的问题 而不是只针对XP的问题 作者最后也没有说明白XP成功实施的关键是什么 很遗憾 似乎他也不知道是什么 作者似乎想指出一些问题 但是他似乎自己也不知道什么才是问题 很遗憾 UMLCHINA我是一个老读者了 但是最近发现水平有些下降 常常不知所云 看来他们似乎把精力放在培训这些可以带来直接经济利益的的事情上了 但愿我想错了
ozzzzzz 2002-07-12
- 打赏
- 举报
本文如果你把XP换成任何一个软件工程的方法的名称都可以
其实关键还是一个习惯的问题 现在不管怎么样都应该有一个方法被大家接受 作为开发的指导办法 不管是RUP XP或者其他 都应该有一种 我们应该考虑的是 那一种适合各自的团队的情况 考虑实施哪个代价最小 本文章的作者把重构和打补丁混淆了 请注意 而且似乎作者对重构的概念最终也不十分清楚 其实我的看法是重构是一种设计的方法 它的有效实施可以解决我们国内的开发团队的设计薄弱问题 如果说国内的的开发者还没有满总XP的良好习惯 可是我看不出有已经有什么良好习惯可以满足别的方法的实施 作者举出的种种问题都是对所有软件工程的方法都是问题的问题 而不是只针对XP的问题 作者最后也没有说明白XP成功实施的关键是什么 很遗憾 似乎他也不知道是什么 作者似乎想指出一些问题 但是他似乎自己也不知道什么才是问题 很遗憾 UMLCHINA我是一个老读者了 但是最近发现水平有些下降 常常不知所云 看来他们似乎把精力放在培训这些可以带来直接经济利益的的事情上了 但愿我想错了
其实关键还是一个习惯的问题 现在不管怎么样都应该有一个方法被大家接受 作为开发的指导办法 不管是RUP XP或者其他 都应该有一种 我们应该考虑的是 那一种适合各自的团队的情况 考虑实施哪个代价最小 本文章的作者把重构和打补丁混淆了 请注意 而且似乎作者对重构的概念最终也不十分清楚 其实我的看法是重构是一种设计的方法 它的有效实施可以解决我们国内的开发团队的设计薄弱问题 如果说国内的的开发者还没有满总XP的良好习惯 可是我看不出有已经有什么良好习惯可以满足别的方法的实施 作者举出的种种问题都是对所有软件工程的方法都是问题的问题 而不是只针对XP的问题 作者最后也没有说明白XP成功实施的关键是什么 很遗憾 似乎他也不知道是什么 作者似乎想指出一些问题 但是他似乎自己也不知道什么才是问题 很遗憾 UMLCHINA我是一个老读者了 但是最近发现水平有些下降 常常不知所云 看来他们似乎把精力放在培训这些可以带来直接经济利益的的事情上了 但愿我想错了
