1,557
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
stoneyrh 2011-03-09
- 打赏
- 举报
持续关注中
我应用测试驱动开发有几年的时间了，现在也在带着团队去做，这一路走来，发现要想改变那些有着数年经验的程序员的想法，确实不容易。我想很重要的一点就是先要让一个团队都理解敏捷开发的本质。
我应用测试驱动开发有几年的时间了，现在也在带着团队去做，这一路走来，发现要想改变那些有着数年经验的程序员的想法，确实不容易。我想很重要的一点就是先要让一个团队都理解敏捷开发的本质。
以专业开发人员为伍 2009-03-04
- 打赏
- 举报
[Quote=引用 22 楼 PEgirl 的回复:]
呵呵，我当然理解你说说的测试驱动。
可是中国程序员（我曾经也作了多年的程序员）的通病我想你也了解，从来只有code，而不管code的结果。
我最希望你回答的问题是在这种情况下，如果把一帮无任何敏捷基础的人（而且每天都忙于修改旧的代码或者编写新的代码)引入XP的正道。或者我想了解的是你所在的项目或者组织是如何开始第一个敏捷项目的。
[/Quote]
你何必去纠缠于该如何在乎“code的结果”争论？！如果严格说起来，这个观念是本末倒置的。
先写测试代码，后写实现代码。写代码时不要做任何多余的事情，如果一段代码没有测试来管理，那么你可以试着注释它甚至删除它！
呵呵，我当然理解你说说的测试驱动。
可是中国程序员（我曾经也作了多年的程序员）的通病我想你也了解，从来只有code，而不管code的结果。
我最希望你回答的问题是在这种情况下，如果把一帮无任何敏捷基础的人（而且每天都忙于修改旧的代码或者编写新的代码)引入XP的正道。或者我想了解的是你所在的项目或者组织是如何开始第一个敏捷项目的。
[/Quote]
你何必去纠缠于该如何在乎“code的结果”争论？！如果严格说起来，这个观念是本末倒置的。
先写测试代码，后写实现代码。写代码时不要做任何多余的事情，如果一段代码没有测试来管理，那么你可以试着注释它甚至删除它！
以专业开发人员为伍 2009-03-04
- 打赏
- 举报
很明显的，知道做什么和知道如何做是完全天壤之别。空洞地说知道做什么，我们不能随便相信。
以专业开发人员为伍 2009-03-04
- 打赏
- 举报
我其实一开始不去全盘批评什么，而是很友善地问：你们是测试驱动还是事后测试？是否可以避免在没有写出某个功能的测试之前就擅自写实现这个功能的代码？那么好，请把测试程序拿出来我看看是否写的测试足够！
我自己负责的项目我可以做到这一点。其实道理是极端浅显的，其实没有什么高深的东西需要争论（例如JavaEyes上有许多关于敏捷的高深的争论），只要问问这一个问题我就心中有数了。
我自己负责的项目我可以做到这一点。其实道理是极端浅显的，其实没有什么高深的东西需要争论（例如JavaEyes上有许多关于敏捷的高深的争论），只要问问这一个问题我就心中有数了。
PEgirl 2009-03-04
- 打赏
- 举报
呵呵，我当然理解你说说的测试驱动。
可是中国程序员（我曾经也作了多年的程序员）的通病我想你也了解，从来只有code，而不管code的结果。
我最希望你回答的问题是在这种情况下，如果把一帮无任何敏捷基础的人（而且每天都忙于修改旧的代码或者编写新的代码)引入XP的正道。或者我想了解的是你所在的项目或者组织是如何开始第一个敏捷项目的。
可是中国程序员（我曾经也作了多年的程序员）的通病我想你也了解，从来只有code，而不管code的结果。
我最希望你回答的问题是在这种情况下，如果把一帮无任何敏捷基础的人（而且每天都忙于修改旧的代码或者编写新的代码)引入XP的正道。或者我想了解的是你所在的项目或者组织是如何开始第一个敏捷项目的。
以专业开发人员为伍 2009-03-04
- 打赏
- 举报
呵呵，其实我在这个帖子中的背景的概念是：我认为如果开发人员写除了实现你的测试的代码，那么再有什么问题你就不应该责怪开发人员，应该找“自己的问题”了。因此，你的帖子的主题其实不仅仅是问一个技术问题，更主要地是问一个项目组织和协调问题，既先写测试后写实现代码。包括GUI也应该这样，我在了解XP之后至少3年也以为gui无法测试驱动，所以那时就根本上对XP方法是阳奉阴违的，直到我真正确信gui也应该测试驱动，于是我才理解了XP。
如果我们写出测试代码，开发人员通过了测试，我们千万不要再去批评开发人员什么“不管code的结果质量”，此时应该批评自己了。这就是敏捷团队的快乐的团队管理原则与传统的给开发人员行政压力的管理方法的区别。
如果我们写出测试代码，开发人员通过了测试，我们千万不要再去批评开发人员什么“不管code的结果质量”，此时应该批评自己了。这就是敏捷团队的快乐的团队管理原则与传统的给开发人员行政压力的管理方法的区别。
PEgirl 2009-03-04
- 打赏
- 举报
很显然，我后面的问题偏离了我帖子的主题。
谢谢大家的解答，其实是SP1234。
谢谢大家的解答，其实是SP1234。
以专业开发人员为伍 2009-03-03
- 打赏
- 举报
XP是“拥抱变化”的。真的！“需求变更频繁，一个系统开发完了每个级别的领导都会提出自己的意见，项目处于反复修改的状态”这是XP正好适合的、痛快拥抱的！如果你哪天需要发布，只要提前3、5天通知，XP项目组就会准时发布一个质量极端稳定（最有经验的 PM 也丝毫不担心其质量）的版本。
实际上当需求修改的时候，XP开发方法并不是去删除原来的测试，而是创建新的测试，让原来的系统的继承了的模块来完成新的功能。而在产品中就可以通过配置文件来声明是使用原来的模块还是新的模块。
XP自认为没有什么可以再剪裁的了。而很多人说自己就是XP方法，可是大大了裁剪测试驱动技术强度，那么就无法做到XP。
实际上当需求修改的时候，XP开发方法并不是去删除原来的测试，而是创建新的测试，让原来的系统的继承了的模块来完成新的功能。而在产品中就可以通过配置文件来声明是使用原来的模块还是新的模块。
XP自认为没有什么可以再剪裁的了。而很多人说自己就是XP方法，可是大大了裁剪测试驱动技术强度，那么就无法做到XP。
以专业开发人员为伍 2009-03-03
- 打赏
- 举报
[Quote=引用 16 楼 PEgirl 的回复:]
有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
这样的高手在一个企业里面出现一个都不容易啊。
我们公司目前的情况，处在“营销”为先的模式，项目一般是由合同而来或者老板拍脑袋想出来的。历史项目普遍延期50%以上，基本上只有code and fix ，人员流失超过30%，几乎所有的项目经理只关心技术和最后的交付时间点（不是交付物）。需求变更频繁，一个系统开发完了每个级别的领导都会提出自己的意见，项目处于反复修改的状态。交付出去的产品很不稳定。
请教SP1234，这种情况下我能做什么？如何把这个混乱的状态梳理清楚。[/Quote]
假设有50名开发人员（不含其它辅助人员）开发了1.5年的一个大项目，如果宣称它采用了XP方法，我的第一个反应是：请问你们这个项目现在开发的自动化测试有多少？是5000个？还是3000个？还是1000个？按照我的期望数字应该是5000个左右。如果太少，那么肯定这个项目组大多数时候不是在采用到位的XP的开发方法。
有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
这样的高手在一个企业里面出现一个都不容易啊。
我们公司目前的情况，处在“营销”为先的模式，项目一般是由合同而来或者老板拍脑袋想出来的。历史项目普遍延期50%以上，基本上只有code and fix ，人员流失超过30%，几乎所有的项目经理只关心技术和最后的交付时间点（不是交付物）。需求变更频繁，一个系统开发完了每个级别的领导都会提出自己的意见，项目处于反复修改的状态。交付出去的产品很不稳定。
请教SP1234，这种情况下我能做什么？如何把这个混乱的状态梳理清楚。[/Quote]
假设有50名开发人员（不含其它辅助人员）开发了1.5年的一个大项目，如果宣称它采用了XP方法，我的第一个反应是：请问你们这个项目现在开发的自动化测试有多少？是5000个？还是3000个？还是1000个？按照我的期望数字应该是5000个左右。如果太少，那么肯定这个项目组大多数时候不是在采用到位的XP的开发方法。
以专业开发人员为伍 2009-03-03
- 打赏
- 举报
网上的翻译标题为：“只是一种正确做事的方法”，我觉得这没有翻译出神韵，所以改为“只做必要的事”，除此以外没有修改任何内容。
Kent Beck是一个大师，文中他自己说他帮助GOF创立个设计模式，但是实际上后来他几乎从来不具体谈设计模式，而是谈测试驱动辅助下的开发团队会有什么表现。他似乎认为多谈关于设计、控制的各种理论是绝对没有必要的。我想，我们主要应该琢磨他为什么会得到这个经验，而不一定要对他的经验完全模仿（例如动态地维护整个项目的几个方面的UML蓝图文档之类文档的还是很必要的）。
Kent Beck是一个大师，文中他自己说他帮助GOF创立个设计模式，但是实际上后来他几乎从来不具体谈设计模式，而是谈测试驱动辅助下的开发团队会有什么表现。他似乎认为多谈关于设计、控制的各种理论是绝对没有必要的。我想，我们主要应该琢磨他为什么会得到这个经验，而不一定要对他的经验完全模仿（例如动态地维护整个项目的几个方面的UML蓝图文档之类文档的还是很必要的）。
cmm2cmmi 2009-03-03
- 打赏
- 举报
[Quote=引用 13 楼 sp1234 的回复:]
yhufo: 但CRC 卡及故事--这些都不是文档。
Kent Beck: 你无须永远保存。你从CRC卡及故事获得内容，然后把他们丢掉。
dggh: QA 部门需要详细的需求，但我们的团队只有简单的文档，怎么办？
Kent Beck: 在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。（The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.）
[/Quote]
对XP创始人Kent Beck 2006年1月之前的一次访谈
内容挺不错的
学习～～
yhufo: 但CRC 卡及故事--这些都不是文档。
Kent Beck: 你无须永远保存。你从CRC卡及故事获得内容，然后把他们丢掉。
dggh: QA 部门需要详细的需求，但我们的团队只有简单的文档，怎么办？
Kent Beck: 在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。（The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.）
[/Quote]
对XP创始人Kent Beck 2006年1月之前的一次访谈
内容挺不错的
学习～～
Roc_Lee 2009-03-03
- 打赏
- 举报
sp1234的帖子每次都让我感觉不错
PEgirl 2009-03-03
- 打赏
- 举报
有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
这样的高手在一个企业里面出现一个都不容易啊。
我们公司目前的情况，处在“营销”为先的模式，项目一般是由合同而来或者老板拍脑袋想出来的。历史项目普遍延期50%以上，基本上只有code and fix ，人员流失超过30%，几乎所有的项目经理只关心技术和最后的交付时间点（不是交付物）。需求变更频繁，一个系统开发完了每个级别的领导都会提出自己的意见，项目处于反复修改的状态。交付出去的产品很不稳定。
请教SP1234，这种情况下我能做什么？如何把这个混乱的状态梳理清楚。
以专业开发人员为伍 2009-03-03
- 打赏
- 举报
dggh: QA 部门需要详细的需求，但我们的团队只有简单的文档，怎么办？
Kent Beck: 在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。（The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.）
simplebest: 在中国，大多数优秀的程序员不喜欢和别人坐在一起，这怎么实践XP？
Kent Beck: 在我的团队中，最优秀的程序员是最会沟通的人。或许我们对于“优秀”的定义不同。
simplebest: 关于优秀的定义：意味着你能解决别人不能解决的问题。
Kent Beck: 我对于优秀的定义是使别人解决他们曾认为他们不能解决的问题，也就是一个团队可以共同做的有多少。
阿楼: 噢，天哪，我想我的经理用不了XP，因为他喜欢控制每一件我为他做的事。
Kent Beck: 想要为你作决定的管理者就不是管理者。你可能需要离开，或可能是他们应该离开。在XP你想要从管理者那里得到的是建立及维护社会网络的能力。这个网络断裂，他们便应该去修复。客户可以指定什么层次的工作量(load)需要支持，同时他们编写测试以决定这个层次是否已被支持。如果未通过测试，技术团队修复这个系统。
fdu_se01: 什么是XP 项目的特征？例如涉及的领域，开发团队的规模，软件产品的规模。CMM 的数据（特别是在美国）是基于DoD 的。
Kent Beck: 团队大小：3-40个人（包括整个团队）。领域：可想到的任何事。产品大小：30个生产人员可以在几年内生产的任何东西。
notyy: 很难发现一个隐喻，怎么办？
Kent Beck: 找寻好的隐喻需要相关的软件经验。真正强大的隐喻并不会立即浮现。我曾经有一个大的隐喻是在处理一个程序片段12年之后获得的。我希望我现在应该更聪明了，但我怀疑:-(
zer: 作为项目经理，如果有人离开（被解雇），那应该怎么办？
Kent Beck: 如果团队中有人离开，那一般不是大问题。速度可能下降（也可能提升）。计划的实践已经可以良好地控制速度改变。
xlp223: Linus 是一位优秀的程序员，但他有时候有些害羞。
Kent Beck: 双人编程的方式可以帮助人们变得更能社交。
skyin: XP 发展的方向是什么？
Kent Beck: XP的下一步是更加拥抱整个团队--如何把一个巨大的故事切割成合理的小故事？在团队中彼此如何沟通及协调。
adylee: 你认为XP 现在是不是完美的？
Kent Beck: 你一定是在开玩笑。一般而言自然界的紧急系统使用3到5条规则（Emergent systems in nature use 3-5 rules）。很可悲的是XP似乎需要太多的规则。我一直在找寻简化XP的方法。你是否可以维持可视性及控制而无须先编写测试？我不认为如此，但我太积极投入了，以致不能了解。（but I'm too emotionally involved to know.）
notyy: 你是说XP 将更简单吗？但我想轻快的过程会更复杂。
Kent Beck: 我想让XP变得更简单，但现在我看不到怎么做。
tooliu: 你是说擅长社交比刻苦编程更重要吗？
Kent Beck: 我比较喜欢有些人是可以包括这两方面。每一个团队中的成员应该持续学习新的社交及技术技能。
simplebest: 我们是否能剪裁XP，使它适合我们的团队？特别是针对我们中国团队成员的特征。
Kent Beck: 你可以调整任何程序。你必须对你的结果承担责任，因此在你的实践上你必须有权力。不管如何，我希望人们依据经验调整，而不是丢掉一些重要的东西，只是因为他们害怕去尝试这些东西。
tooliu: 你对XP 有什么不满意的地方吗？
Kent Beck: XP Explained这本书在1999年发行。（其中有许多是我现在想要改变的，但此时我在做别的项目。）
fdu_se01: 要多长时间XP 才能在团队中生效（学习曲线？）
Kent Beck: 一般团队在几周或几个月后都能获得好的结果。一般约9-12个月后明显地变得更有效率。我在Iona辅导的一个团队花了将近一年的时间才真正觉得满意，他们仍然能变得更有效率。
xlp223: 现在有“轻快软件开发”的说法，它和XP 有什么关系？
Kent Beck: “轻快(agile)”来自一个研讨会，其中有许多趣味相投的方*者集中讨论他们的软件开发过程。我们之间的共通点多于差异点，因此我们决定使用“轻快”这个词来描述我们的共通点。
notyy: 你愿意来中国指导一些软件公司吗？
Kent Beck: 我非常希望能访问中国。我辅导的团队包括整个美国及欧洲许多地方。现在我开始在亚洲的工作。我发现在不同文化当中找寻什么比较困难或者什么比较容易是很有趣的。瑞士日耳曼人喜欢编写测试，墨西哥人喜欢双人编程，重构在美国中西部非常流行。
lovelybug28: 我是一个XP 的初学者，请问XP 是否有可操作性（maneuverability）？
Kent Beck: 假设你可以将你对一个大型软件项目的期望切割成一周可以完成的细部。我们每周可以会面，你告诉我哪一个细节是你认为在下一周是最有价值的部分。我不在乎你挑选哪一个部分，所以你可以彻底地改变对于软件的整个概念而从我这边听不到任何怨言。是否这就是可操作性？有一本不错的书“XP in Practice”，其中讨论一个实际的（如果是小的）项目。
taoxie: 关于XP 是否有一些学术研究工作在进行，或者它只是面向工业界的？
Kent Beck: 我们正在取得进展。有一些杰出的教授像Ralph Johnson，开设有XP的课程。XP有许多教育上的优点。迭代式开发让学生有机会尝试许多不同的变化。
skyin: 能不能告诉我们你自己的XP 编程工具箱？
Kent Beck: 我的工具箱？我用VisualWorks写Smalltalk程序，如果我自己编写代码时使用Refactoring Browser，如果我使用Java编写代码时，使用Eclipse及JUnit。我只使用两种语言。
lovelybug28: 关于可操作性…XP 出现之前我们已经这样做了…
Kent Beck: 如果你已经知道如何做，XP可以从你身上学到一些东西。
notyy: OOAD 必须在XP 过程中使用吗？
Kent Beck: 你必须做分析及设计决策。问题是何时及你如何用符号表示(notate)。详细分析决策在每一次迭代中决定，而符号表示就是自动测试。设计决策是在故事评估、迭代计划、及编写代码中决定而符号表示就是代码及单元测试。
tensile: 怎样在公司中执行XP？
Kent Beck: 有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
notyy: 有没有执行XP 的实际项目？效果如何？
Kent Beck: 在XP邮件列表中有超过100个实际项目。我猜，全世界可能不超过1000个项目使用XP。
charles_y，adylee: 为什么XP 叫XP，而不是别的名字？
Kent Beck: “终极(eXtreme)”就像终极运动员，这些人事前有周密的准备并且达到他们最大的极限。“程序设计(Programming)”是因为最后我们从执行的系统获得我们的报酬。起名时，名称必须是准确、好记和说得通的(defensible)。说得通是最重要的。我需要一个我的“敌人”绝不会说“他们正在做这件事”的名字。
xlp223: 谁是你的敌人？
Kent Beck: 我不是真想使用这个字眼，我只是尝试打字打得快一点。当我命名XP的时候我的心中有Grady Booch这个名字。他对于软件开发和我有不同的概念（不完全是错误，只是不同）。如果我要建立一个流行的事物，将会对Rational有一些压力说他们也在做这件事。他们不曾说过他们是“终极”，即使他们说他们是“轻快(agile)”。
zer: 在编码之前，我们必须设计软件工程里的每样东西…
Kent Beck: Zer，为什么你要设计所有的东西，如果你只设计前面一半会如何？
xlp223: RUP 和XP 在理念上有很大区别吗？
Kent Beck: XP是一种开发过程，RUP是过程的框架（process framework），RUP有预设的举例说明(instantiation)看起来非常类似制造业(manufacturing)。
morenew: 计划XP 的规则是什么？XP 的关键是什么？
Kent Beck: 协商的范围。时间、品质及成本是固定的。这是XP的方式。
fdu_se01: XP 是否推崇“每个人对组织都有不同的重要性”的理念？如果是这样，你如何处理人员的流动？
Kent Beck: XP计划中的规则是每一次迭代（1-3周）你计划要完成的与你实际在上个迭代当中完成的一样，如果你提早完成，你可以要求更多的工作。如果你快要来不及了，你要提出延迟要求。这个简单的规则优雅地控制休假、人力的成长、雇用、及项目间的转换。
Kent Beck: 这里有许多问题是关于“我们应如何在中国恰当地实施XP”。我建议你们由小的区域性的团体自行回答这个问题。你们的答案应该会比我的好。全世界有约20个这类团体，他们确实在帮助参与者。XP在长远的未来将变得脆弱及老旧，并且将有某些更好的东西来替换，在50年之内。不管如何，我期望许多XP实践被当做“仅作必要的事情”接受。先写测试、重构、快速具体的交付(quick concrete deliverables)、结合业务的团队(teams combining business)及技术才能(technical talent)。
Kent Beck: 在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。（The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.）
simplebest: 在中国，大多数优秀的程序员不喜欢和别人坐在一起，这怎么实践XP？
Kent Beck: 在我的团队中，最优秀的程序员是最会沟通的人。或许我们对于“优秀”的定义不同。
simplebest: 关于优秀的定义：意味着你能解决别人不能解决的问题。
Kent Beck: 我对于优秀的定义是使别人解决他们曾认为他们不能解决的问题，也就是一个团队可以共同做的有多少。
阿楼: 噢，天哪，我想我的经理用不了XP，因为他喜欢控制每一件我为他做的事。
Kent Beck: 想要为你作决定的管理者就不是管理者。你可能需要离开，或可能是他们应该离开。在XP你想要从管理者那里得到的是建立及维护社会网络的能力。这个网络断裂，他们便应该去修复。客户可以指定什么层次的工作量(load)需要支持，同时他们编写测试以决定这个层次是否已被支持。如果未通过测试，技术团队修复这个系统。
fdu_se01: 什么是XP 项目的特征？例如涉及的领域，开发团队的规模，软件产品的规模。CMM 的数据（特别是在美国）是基于DoD 的。
Kent Beck: 团队大小：3-40个人（包括整个团队）。领域：可想到的任何事。产品大小：30个生产人员可以在几年内生产的任何东西。
notyy: 很难发现一个隐喻，怎么办？
Kent Beck: 找寻好的隐喻需要相关的软件经验。真正强大的隐喻并不会立即浮现。我曾经有一个大的隐喻是在处理一个程序片段12年之后获得的。我希望我现在应该更聪明了，但我怀疑:-(
zer: 作为项目经理，如果有人离开（被解雇），那应该怎么办？
Kent Beck: 如果团队中有人离开，那一般不是大问题。速度可能下降（也可能提升）。计划的实践已经可以良好地控制速度改变。
xlp223: Linus 是一位优秀的程序员，但他有时候有些害羞。
Kent Beck: 双人编程的方式可以帮助人们变得更能社交。
skyin: XP 发展的方向是什么？
Kent Beck: XP的下一步是更加拥抱整个团队--如何把一个巨大的故事切割成合理的小故事？在团队中彼此如何沟通及协调。
adylee: 你认为XP 现在是不是完美的？
Kent Beck: 你一定是在开玩笑。一般而言自然界的紧急系统使用3到5条规则（Emergent systems in nature use 3-5 rules）。很可悲的是XP似乎需要太多的规则。我一直在找寻简化XP的方法。你是否可以维持可视性及控制而无须先编写测试？我不认为如此，但我太积极投入了，以致不能了解。（but I'm too emotionally involved to know.）
notyy: 你是说XP 将更简单吗？但我想轻快的过程会更复杂。
Kent Beck: 我想让XP变得更简单，但现在我看不到怎么做。
tooliu: 你是说擅长社交比刻苦编程更重要吗？
Kent Beck: 我比较喜欢有些人是可以包括这两方面。每一个团队中的成员应该持续学习新的社交及技术技能。
simplebest: 我们是否能剪裁XP，使它适合我们的团队？特别是针对我们中国团队成员的特征。
Kent Beck: 你可以调整任何程序。你必须对你的结果承担责任，因此在你的实践上你必须有权力。不管如何，我希望人们依据经验调整，而不是丢掉一些重要的东西，只是因为他们害怕去尝试这些东西。
tooliu: 你对XP 有什么不满意的地方吗？
Kent Beck: XP Explained这本书在1999年发行。（其中有许多是我现在想要改变的，但此时我在做别的项目。）
fdu_se01: 要多长时间XP 才能在团队中生效（学习曲线？）
Kent Beck: 一般团队在几周或几个月后都能获得好的结果。一般约9-12个月后明显地变得更有效率。我在Iona辅导的一个团队花了将近一年的时间才真正觉得满意，他们仍然能变得更有效率。
xlp223: 现在有“轻快软件开发”的说法，它和XP 有什么关系？
Kent Beck: “轻快(agile)”来自一个研讨会，其中有许多趣味相投的方*者集中讨论他们的软件开发过程。我们之间的共通点多于差异点，因此我们决定使用“轻快”这个词来描述我们的共通点。
notyy: 你愿意来中国指导一些软件公司吗？
Kent Beck: 我非常希望能访问中国。我辅导的团队包括整个美国及欧洲许多地方。现在我开始在亚洲的工作。我发现在不同文化当中找寻什么比较困难或者什么比较容易是很有趣的。瑞士日耳曼人喜欢编写测试，墨西哥人喜欢双人编程，重构在美国中西部非常流行。
lovelybug28: 我是一个XP 的初学者，请问XP 是否有可操作性（maneuverability）？
Kent Beck: 假设你可以将你对一个大型软件项目的期望切割成一周可以完成的细部。我们每周可以会面，你告诉我哪一个细节是你认为在下一周是最有价值的部分。我不在乎你挑选哪一个部分，所以你可以彻底地改变对于软件的整个概念而从我这边听不到任何怨言。是否这就是可操作性？有一本不错的书“XP in Practice”，其中讨论一个实际的（如果是小的）项目。
taoxie: 关于XP 是否有一些学术研究工作在进行，或者它只是面向工业界的？
Kent Beck: 我们正在取得进展。有一些杰出的教授像Ralph Johnson，开设有XP的课程。XP有许多教育上的优点。迭代式开发让学生有机会尝试许多不同的变化。
skyin: 能不能告诉我们你自己的XP 编程工具箱？
Kent Beck: 我的工具箱？我用VisualWorks写Smalltalk程序，如果我自己编写代码时使用Refactoring Browser，如果我使用Java编写代码时，使用Eclipse及JUnit。我只使用两种语言。
lovelybug28: 关于可操作性…XP 出现之前我们已经这样做了…
Kent Beck: 如果你已经知道如何做，XP可以从你身上学到一些东西。
notyy: OOAD 必须在XP 过程中使用吗？
Kent Beck: 你必须做分析及设计决策。问题是何时及你如何用符号表示(notate)。详细分析决策在每一次迭代中决定，而符号表示就是自动测试。设计决策是在故事评估、迭代计划、及编写代码中决定而符号表示就是代码及单元测试。
tensile: 怎样在公司中执行XP？
Kent Beck: 有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
notyy: 有没有执行XP 的实际项目？效果如何？
Kent Beck: 在XP邮件列表中有超过100个实际项目。我猜，全世界可能不超过1000个项目使用XP。
charles_y，adylee: 为什么XP 叫XP，而不是别的名字？
Kent Beck: “终极(eXtreme)”就像终极运动员，这些人事前有周密的准备并且达到他们最大的极限。“程序设计(Programming)”是因为最后我们从执行的系统获得我们的报酬。起名时，名称必须是准确、好记和说得通的(defensible)。说得通是最重要的。我需要一个我的“敌人”绝不会说“他们正在做这件事”的名字。
xlp223: 谁是你的敌人？
Kent Beck: 我不是真想使用这个字眼，我只是尝试打字打得快一点。当我命名XP的时候我的心中有Grady Booch这个名字。他对于软件开发和我有不同的概念（不完全是错误，只是不同）。如果我要建立一个流行的事物，将会对Rational有一些压力说他们也在做这件事。他们不曾说过他们是“终极”，即使他们说他们是“轻快(agile)”。
zer: 在编码之前，我们必须设计软件工程里的每样东西…
Kent Beck: Zer，为什么你要设计所有的东西，如果你只设计前面一半会如何？
xlp223: RUP 和XP 在理念上有很大区别吗？
Kent Beck: XP是一种开发过程，RUP是过程的框架（process framework），RUP有预设的举例说明(instantiation)看起来非常类似制造业(manufacturing)。
morenew: 计划XP 的规则是什么？XP 的关键是什么？
Kent Beck: 协商的范围。时间、品质及成本是固定的。这是XP的方式。
fdu_se01: XP 是否推崇“每个人对组织都有不同的重要性”的理念？如果是这样，你如何处理人员的流动？
Kent Beck: XP计划中的规则是每一次迭代（1-3周）你计划要完成的与你实际在上个迭代当中完成的一样，如果你提早完成，你可以要求更多的工作。如果你快要来不及了，你要提出延迟要求。这个简单的规则优雅地控制休假、人力的成长、雇用、及项目间的转换。
Kent Beck: 这里有许多问题是关于“我们应如何在中国恰当地实施XP”。我建议你们由小的区域性的团体自行回答这个问题。你们的答案应该会比我的好。全世界有约20个这类团体，他们确实在帮助参与者。XP在长远的未来将变得脆弱及老旧，并且将有某些更好的东西来替换，在50年之内。不管如何，我期望许多XP实践被当做“仅作必要的事情”接受。先写测试、重构、快速具体的交付(quick concrete deliverables)、结合业务的团队(teams combining business)及技术才能(technical talent)。
以专业开发人员为伍 2009-03-03
- 打赏
- 举报
dggh: QA 部门需要详细的需求，但我们的团队只有简单的文档，怎么办？
Kent Beck: 在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。（The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.）
simplebest: 在中国，大多数优秀的程序员不喜欢和别人坐在一起，这怎么实践XP？
Kent Beck: 在我的团队中，最优秀的程序员是最会沟通的人。或许我们对于“优秀”的定义不同。
simplebest: 关于优秀的定义：意味着你能解决别人不能解决的问题。
Kent Beck: 我对于优秀的定义是使别人解决他们曾认为他们不能解决的问题，也就是一个团队可以共同做的有多少。
阿楼: 噢，天哪，我想我的经理用不了XP，因为他喜欢控制每一件我为他做的事。
Kent Beck: 想要为你作决定的管理者就不是管理者。你可能需要离开，或可能是他们应该离开。在XP你想要从管理者那里得到的是建立及维护社会网络的能力。这个网络断裂，他们便应该去修复。客户可以指定什么层次的工作量(load)需要支持，同时他们编写测试以决定这个层次是否已被支持。如果未通过测试，技术团队修复这个系统。
fdu_se01: 什么是XP 项目的特征？例如涉及的领域，开发团队的规模，软件产品的规模。CMM 的数据（特别是在美国）是基于DoD 的。
Kent Beck: 团队大小：3-40个人（包括整个团队）。领域：可想到的任何事。产品大小：30个生产人员可以在几年内生产的任何东西。
notyy: 很难发现一个隐喻，怎么办？
Kent Beck: 找寻好的隐喻需要相关的软件经验。真正强大的隐喻并不会立即浮现。我曾经有一个大的隐喻是在处理一个程序片段12年之后获得的。我希望我现在应该更聪明了，但我怀疑:-(
zer: 作为项目经理，如果有人离开（被解雇），那应该怎么办？
Kent Beck: 如果团队中有人离开，那一般不是大问题。速度可能下降（也可能提升）。计划的实践已经可以良好地控制速度改变。
xlp223: Linus 是一位优秀的程序员，但他有时候有些害羞。
Kent Beck: 双人编程的方式可以帮助人们变得更能社交。
skyin: XP 发展的方向是什么？
Kent Beck: XP的下一步是更加拥抱整个团队--如何把一个巨大的故事切割成合理的小故事？在团队中彼此如何沟通及协调。
adylee: 你认为XP 现在是不是完美的？
Kent Beck: 你一定是在开玩笑。一般而言自然界的紧急系统使用3到5条规则（Emergent systems in nature use 3-5 rules）。很可悲的是XP似乎需要太多的规则。我一直在找寻简化XP的方法。你是否可以维持可视性及控制而无须先编写测试？我不认为如此，但我太积极投入了，以致不能了解。（but I'm too emotionally involved to know.）
notyy: 你是说XP 将更简单吗？但我想轻快的过程会更复杂。
Kent Beck: 我想让XP变得更简单，但现在我看不到怎么做。
tooliu: 你是说擅长社交比刻苦编程更重要吗？
Kent Beck: 我比较喜欢有些人是可以包括这两方面。每一个团队中的成员应该持续学习新的社交及技术技能。
simplebest: 我们是否能剪裁XP，使它适合我们的团队？特别是针对我们中国团队成员的特征。
Kent Beck: 你可以调整任何程序。你必须对你的结果承担责任，因此在你的实践上你必须有权力。不管如何，我希望人们依据经验调整，而不是丢掉一些重要的东西，只是因为他们害怕去尝试这些东西。
tooliu: 你对XP 有什么不满意的地方吗？
Kent Beck: XP Explained这本书在1999年发行。（其中有许多是我现在想要改变的，但此时我在做别的项目。）
fdu_se01: 要多长时间XP 才能在团队中生效（学习曲线？）
Kent Beck: 一般团队在几周或几个月后都能获得好的结果。一般约9-12个月后明显地变得更有效率。我在Iona辅导的一个团队花了将近一年的时间才真正觉得满意，他们仍然能变得更有效率。
xlp223: 现在有“轻快软件开发”的说法，它和XP 有什么关系？
Kent Beck: “轻快(agile)”来自一个研讨会，其中有许多趣味相投的方*者集中讨论他们的软件开发过程。我们之间的共通点多于差异点，因此我们决定使用“轻快”这个词来描述我们的共通点。
notyy: 你愿意来中国指导一些软件公司吗？
Kent Beck: 我非常希望能访问中国。我辅导的团队包括整个美国及欧洲许多地方。现在我开始在亚洲的工作。我发现在不同文化当中找寻什么比较困难或者什么比较容易是很有趣的。瑞士日耳曼人喜欢编写测试，墨西哥人喜欢双人编程，重构在美国中西部非常流行。
lovelybug28: 我是一个XP 的初学者，请问XP 是否有可操作性（maneuverability）？
Kent Beck: 假设你可以将你对一个大型软件项目的期望切割成一周可以完成的细部。我们每周可以会面，你告诉我哪一个细节是你认为在下一周是最有价值的部分。我不在乎你挑选哪一个部分，所以你可以彻底地改变对于软件的整个概念而从我这边听不到任何怨言。是否这就是可操作性？有一本不错的书“XP in Practice”，其中讨论一个实际的（如果是小的）项目。
taoxie: 关于XP 是否有一些学术研究工作在进行，或者它只是面向工业界的？
Kent Beck: 我们正在取得进展。有一些杰出的教授像Ralph Johnson，开设有XP的课程。XP有许多教育上的优点。迭代式开发让学生有机会尝试许多不同的变化。
skyin: 能不能告诉我们你自己的XP 编程工具箱？
Kent Beck: 我的工具箱？我用VisualWorks写Smalltalk程序，如果我自己编写代码时使用Refactoring Browser，如果我使用Java编写代码时，使用Eclipse及JUnit。我只使用两种语言。
lovelybug28: 关于可操作性…XP 出现之前我们已经这样做了…
Kent Beck: 如果你已经知道如何做，XP可以从你身上学到一些东西。
notyy: OOAD 必须在XP 过程中使用吗？
Kent Beck: 你必须做分析及设计决策。问题是何时及你如何用符号表示(notate)。详细分析决策在每一次迭代中决定，而符号表示就是自动测试。设计决策是在故事评估、迭代计划、及编写代码中决定而符号表示就是代码及单元测试。
tensile: 怎样在公司中执行XP？
Kent Beck: 有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
notyy: 有没有执行XP 的实际项目？效果如何？
Kent Beck: 在XP邮件列表中有超过100个实际项目。我猜，全世界可能不超过1000个项目使用XP。
charles_y，adylee: 为什么XP 叫XP，而不是别的名字？
Kent Beck: “终极(eXtreme)”就像终极运动员，这些人事前有周密的准备并且达到他们最大的极限。“程序设计(Programming)”是因为最后我们从执行的系统获得我们的报酬。起名时，名称必须是准确、好记和说得通的(defensible)。说得通是最重要的。我需要一个我的“敌人”绝不会说“他们正在做这件事”的名字。
xlp223: 谁是你的敌人？
Kent Beck: 我不是真想使用这个字眼，我只是尝试打字打得快一点。当我命名XP的时候我的心中有Grady Booch这个名字。他对于软件开发和我有不同的概念（不完全是错误，只是不同）。如果我要建立一个流行的事物，将会对Rational有一些压力说他们也在做这件事。他们不曾说过他们是“终极”，即使他们说他们是“轻快(agile)”。
zer: 在编码之前，我们必须设计软件工程里的每样东西…
Kent Beck: Zer，为什么你要设计所有的东西，如果你只设计前面一半会如何？
xlp223: RUP 和XP 在理念上有很大区别吗？
Kent Beck: XP是一种开发过程，RUP是过程的框架（process framework），RUP有预设的举例说明(instantiation)看起来非常类似制造业(manufacturing)。
morenew: 计划XP 的规则是什么？XP 的关键是什么？
Kent Beck: 协商的范围。时间、品质及成本是固定的。这是XP的方式。
fdu_se01: XP 是否推崇“每个人对组织都有不同的重要性”的理念？如果是这样，你如何处理人员的流动？
Kent Beck: XP计划中的规则是每一次迭代（1-3周）你计划要完成的与你实际在上个迭代当中完成的一样，如果你提早完成，你可以要求更多的工作。如果你快要来不及了，你要提出延迟要求。这个简单的规则优雅地控制休假、人力的成长、雇用、及项目间的转换。
Kent Beck: 这里有许多问题是关于“我们应如何在中国恰当地实施XP”。我建议你们由小的区域性的团体自行回答这个问题。你们的答案应该会比我的好。全世界有约20个这类团体，他们确实在帮助参与者。XP在长远的未来将变得脆弱及老旧，并且将有某些更好的东西来替换，在50年之内。不管如何，我期望许多XP实践被当做“仅作必要的事情”接受。先写测试、重构、快速具体的交付(quick concrete deliverables)、结合业务的团队(teams combining business)及技术才能(technical talent)。
Kent Beck: 在XP中，QA有一个前置的角色（up-front role）。在每一次迭代中，在技术团队开始把故事分解成任务之前，最好的团队随着他们的故事交付验收测试。你需要测试员编写这些测试，同时有设备支持他们。对于一个程序员最重要的事是勇气--冒险的勇气—看起来很笨，勇于挑战困难和尝试新技术，勇于清楚地与别人沟通，甚至是很难支持他们时。（The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.）
simplebest: 在中国，大多数优秀的程序员不喜欢和别人坐在一起，这怎么实践XP？
Kent Beck: 在我的团队中，最优秀的程序员是最会沟通的人。或许我们对于“优秀”的定义不同。
simplebest: 关于优秀的定义：意味着你能解决别人不能解决的问题。
Kent Beck: 我对于优秀的定义是使别人解决他们曾认为他们不能解决的问题，也就是一个团队可以共同做的有多少。
阿楼: 噢，天哪，我想我的经理用不了XP，因为他喜欢控制每一件我为他做的事。
Kent Beck: 想要为你作决定的管理者就不是管理者。你可能需要离开，或可能是他们应该离开。在XP你想要从管理者那里得到的是建立及维护社会网络的能力。这个网络断裂，他们便应该去修复。客户可以指定什么层次的工作量(load)需要支持，同时他们编写测试以决定这个层次是否已被支持。如果未通过测试，技术团队修复这个系统。
fdu_se01: 什么是XP 项目的特征？例如涉及的领域，开发团队的规模，软件产品的规模。CMM 的数据（特别是在美国）是基于DoD 的。
Kent Beck: 团队大小：3-40个人（包括整个团队）。领域：可想到的任何事。产品大小：30个生产人员可以在几年内生产的任何东西。
notyy: 很难发现一个隐喻，怎么办？
Kent Beck: 找寻好的隐喻需要相关的软件经验。真正强大的隐喻并不会立即浮现。我曾经有一个大的隐喻是在处理一个程序片段12年之后获得的。我希望我现在应该更聪明了，但我怀疑:-(
zer: 作为项目经理，如果有人离开（被解雇），那应该怎么办？
Kent Beck: 如果团队中有人离开，那一般不是大问题。速度可能下降（也可能提升）。计划的实践已经可以良好地控制速度改变。
xlp223: Linus 是一位优秀的程序员，但他有时候有些害羞。
Kent Beck: 双人编程的方式可以帮助人们变得更能社交。
skyin: XP 发展的方向是什么？
Kent Beck: XP的下一步是更加拥抱整个团队--如何把一个巨大的故事切割成合理的小故事？在团队中彼此如何沟通及协调。
adylee: 你认为XP 现在是不是完美的？
Kent Beck: 你一定是在开玩笑。一般而言自然界的紧急系统使用3到5条规则（Emergent systems in nature use 3-5 rules）。很可悲的是XP似乎需要太多的规则。我一直在找寻简化XP的方法。你是否可以维持可视性及控制而无须先编写测试？我不认为如此，但我太积极投入了，以致不能了解。（but I'm too emotionally involved to know.）
notyy: 你是说XP 将更简单吗？但我想轻快的过程会更复杂。
Kent Beck: 我想让XP变得更简单，但现在我看不到怎么做。
tooliu: 你是说擅长社交比刻苦编程更重要吗？
Kent Beck: 我比较喜欢有些人是可以包括这两方面。每一个团队中的成员应该持续学习新的社交及技术技能。
simplebest: 我们是否能剪裁XP，使它适合我们的团队？特别是针对我们中国团队成员的特征。
Kent Beck: 你可以调整任何程序。你必须对你的结果承担责任，因此在你的实践上你必须有权力。不管如何，我希望人们依据经验调整，而不是丢掉一些重要的东西，只是因为他们害怕去尝试这些东西。
tooliu: 你对XP 有什么不满意的地方吗？
Kent Beck: XP Explained这本书在1999年发行。（其中有许多是我现在想要改变的，但此时我在做别的项目。）
fdu_se01: 要多长时间XP 才能在团队中生效（学习曲线？）
Kent Beck: 一般团队在几周或几个月后都能获得好的结果。一般约9-12个月后明显地变得更有效率。我在Iona辅导的一个团队花了将近一年的时间才真正觉得满意，他们仍然能变得更有效率。
xlp223: 现在有“轻快软件开发”的说法，它和XP 有什么关系？
Kent Beck: “轻快(agile)”来自一个研讨会，其中有许多趣味相投的方*者集中讨论他们的软件开发过程。我们之间的共通点多于差异点，因此我们决定使用“轻快”这个词来描述我们的共通点。
notyy: 你愿意来中国指导一些软件公司吗？
Kent Beck: 我非常希望能访问中国。我辅导的团队包括整个美国及欧洲许多地方。现在我开始在亚洲的工作。我发现在不同文化当中找寻什么比较困难或者什么比较容易是很有趣的。瑞士日耳曼人喜欢编写测试，墨西哥人喜欢双人编程，重构在美国中西部非常流行。
lovelybug28: 我是一个XP 的初学者，请问XP 是否有可操作性（maneuverability）？
Kent Beck: 假设你可以将你对一个大型软件项目的期望切割成一周可以完成的细部。我们每周可以会面，你告诉我哪一个细节是你认为在下一周是最有价值的部分。我不在乎你挑选哪一个部分，所以你可以彻底地改变对于软件的整个概念而从我这边听不到任何怨言。是否这就是可操作性？有一本不错的书“XP in Practice”，其中讨论一个实际的（如果是小的）项目。
taoxie: 关于XP 是否有一些学术研究工作在进行，或者它只是面向工业界的？
Kent Beck: 我们正在取得进展。有一些杰出的教授像Ralph Johnson，开设有XP的课程。XP有许多教育上的优点。迭代式开发让学生有机会尝试许多不同的变化。
skyin: 能不能告诉我们你自己的XP 编程工具箱？
Kent Beck: 我的工具箱？我用VisualWorks写Smalltalk程序，如果我自己编写代码时使用Refactoring Browser，如果我使用Java编写代码时，使用Eclipse及JUnit。我只使用两种语言。
lovelybug28: 关于可操作性…XP 出现之前我们已经这样做了…
Kent Beck: 如果你已经知道如何做，XP可以从你身上学到一些东西。
notyy: OOAD 必须在XP 过程中使用吗？
Kent Beck: 你必须做分析及设计决策。问题是何时及你如何用符号表示(notate)。详细分析决策在每一次迭代中决定，而符号表示就是自动测试。设计决策是在故事评估、迭代计划、及编写代码中决定而符号表示就是代码及单元测试。
tensile: 怎样在公司中执行XP？
Kent Beck: 有关如何在一家200人的公司导入XP的问题。我发现你需要一个技术高手(champion)，他愿意深入学习并且教导这种技术，一个企业高手去说服企业组织尝试故事及迭代，及一个执行高手来保证每一个人不会因异常而导致第一次做事就出错。所有的改变都伴随着混乱。在XP中game的目的是在任何给定的日期尽可能地交付最有价值的软件。要做到这点，团队中的每一个人必须放弃完美的观念(notions of absolutes)，并且持续地学习。
notyy: 有没有执行XP 的实际项目？效果如何？
Kent Beck: 在XP邮件列表中有超过100个实际项目。我猜，全世界可能不超过1000个项目使用XP。
charles_y，adylee: 为什么XP 叫XP，而不是别的名字？
Kent Beck: “终极(eXtreme)”就像终极运动员，这些人事前有周密的准备并且达到他们最大的极限。“程序设计(Programming)”是因为最后我们从执行的系统获得我们的报酬。起名时，名称必须是准确、好记和说得通的(defensible)。说得通是最重要的。我需要一个我的“敌人”绝不会说“他们正在做这件事”的名字。
xlp223: 谁是你的敌人？
Kent Beck: 我不是真想使用这个字眼，我只是尝试打字打得快一点。当我命名XP的时候我的心中有Grady Booch这个名字。他对于软件开发和我有不同的概念（不完全是错误，只是不同）。如果我要建立一个流行的事物，将会对Rational有一些压力说他们也在做这件事。他们不曾说过他们是“终极”，即使他们说他们是“轻快(agile)”。
zer: 在编码之前，我们必须设计软件工程里的每样东西…
Kent Beck: Zer，为什么你要设计所有的东西，如果你只设计前面一半会如何？
xlp223: RUP 和XP 在理念上有很大区别吗？
Kent Beck: XP是一种开发过程，RUP是过程的框架（process framework），RUP有预设的举例说明(instantiation)看起来非常类似制造业(manufacturing)。
morenew: 计划XP 的规则是什么？XP 的关键是什么？
Kent Beck: 协商的范围。时间、品质及成本是固定的。这是XP的方式。
fdu_se01: XP 是否推崇“每个人对组织都有不同的重要性”的理念？如果是这样，你如何处理人员的流动？
Kent Beck: XP计划中的规则是每一次迭代（1-3周）你计划要完成的与你实际在上个迭代当中完成的一样，如果你提早完成，你可以要求更多的工作。如果你快要来不及了，你要提出延迟要求。这个简单的规则优雅地控制休假、人力的成长、雇用、及项目间的转换。
Kent Beck: 这里有许多问题是关于“我们应如何在中国恰当地实施XP”。我建议你们由小的区域性的团体自行回答这个问题。你们的答案应该会比我的好。全世界有约20个这类团体，他们确实在帮助参与者。XP在长远的未来将变得脆弱及老旧，并且将有某些更好的东西来替换，在50年之内。不管如何，我期望许多XP实践被当做“仅作必要的事情”接受。先写测试、重构、快速具体的交付(quick concrete deliverables)、结合业务的团队(teams combining business)及技术才能(technical talent)。
以专业开发人员为伍 2009-03-03
- 打赏
- 举报
我找到一篇文档《访谈 Kent Beck：仅作必要的事情》，你可以从中了解测试驱动与传统的测试在不同的开发技术的团队是多么大的区别，绝对是一种技术上的不可小觑的区别。
tensile: 能否谈谈XP 和UML 的关系
Kent Beck: XP是一个软件开发的社会(social)系统，UML是一个描述软件的标记法(notation)。你可以在XP中使用UML，但团队良好的进展并不需要许多文档，除了代码及测试外。
yhufo: XP 中的文档重要吗？需要写什么样的文档？
Kent Beck: 你要写的文档就是代码及测试。
superlong: XP 如何用在一个可视化项目中？
Kent Beck: XP程序员并不是不做视觉上的思考(think visually)，他们只是一般不储存图片(picture)。
notyy: XP 可以解决什么问题？
Kent Beck: 当你有许多关于需求的不确定性，XP让你快速得到一个具体、运行中的系统，同时让你以一个相当稳定的速度(pace)修改。以这种方式你无须在开始之前知道所有的事。
yhufo: 但CRC 卡及故事--这些都不是文档。
Kent Beck: 你无须永远保存。你从CRC卡及故事获得内容，然后把他们丢掉。
joe_lee: XP 是一种递归过程（recursive process）吗？
Kent Beck: 是的，或者我可能说『不规则碎片形(fractal)』。以一年为期，描述你所想要的（故事）然后去做。以一分钟为期，描述你想要的（单元测试）然后去做（编写代码）。分解的不规则碎片形是经过相当的深思熟虑的(deliberate)。
taoxie: 你提到了单元测试。我同意rerun 所有的单元测试是合理的，那么rerun 所有的集成测试也是合理的吗？
Kent Beck: 如果你有适当的准备而且够快的话，你可以随时执行测试。
yhufo: 如果我们没有文档，我怎么知道怎样能控制软件中的变更呢？我想我们必须建立文档！
Kent Beck: 当你们说『控制变更』，我则说『鼓励变更(encourage change)』。控制来自测试、双人编程、大家坐在一起讨论及持续集成。XP对于受过良好训练的程序员运作得很好，但是如果目前不觉得有良好的训练，别担心。你的搭挡可以帮你，不然你的集成工作无法达成，你必须把你的代码丢弃。
dggh: 能谈谈xp practise games 吗？
Kent Beck: 我做过一个练习让人们描绘一个咖啡壶的图像。从这里显示有更好的game。在伦敦有人建造乐高(Lego)机器人。Joshua Kerievsky有一个团队写了一个剧本（电影的脚本）。
gigix: 我想我们必须先小心地设计。如果我们忽视了设计的重要性，XP（或重构）将不能对整个项目有改进。对此你如何看？
Kent Beck: 我就知道迟早要讨论这个。我，同样地，坚持我们需要小心地设计。我宁愿等待并且在我有一些经验后再做，而不愿依据猜测(speculation)做设计。前置设计（Up front design）是一种正向反馈的循环(positive feedback loop)。你越有经验，你越可以考虑前置设计，直到你完全无用(useless)。另一种使用设计经验的方式是等待你的好想法，直到这些想法显露出来，立即就可以用得上。
joe_lee: 如果没有文档，我们怎样维护软件？
Kent Beck: 你有两个非常有价值的文档-代码及测试。如果测试总是能够100％执行而且绝不会允许逆行(regress)，你还需要什么？
yhufo: 在双人编程中，两个人应该经常变换角色吗？一天或两天，我是说多久换一次，一天或两天？
Kent Beck: 在比较大的团队中，每天变换（switch）2-4次。在一天之中我无法维持一个双人组6个小时以上，因为专注的程度太过激烈。
xlp223: 既然XP 没有专家，那XP leader 在程序员当中扮演什么角色，客户，经理？
Kent Beck: XP是有专家，但他们的角色并不像以前一样是固定的。专家的出现是由团队中的每一个人依据经验挑选出来的。促使这种专家的出现是管理者扮演的角色。
yhufo: 在双人编程中，当一个人编写代码时，另一个人在干什么？只是看和说话吗？
Kent Beck: 双人编程并不是看着别人编写代码。编写代码就像是在沟通。键盘每几分钟便传来传去。双人编程时，你们讨论相关的想法，试试一个，建议另一个测试，把你下一个想法画个草图，写成代码，做些重构等等，持续进行下去。
dggh: 如何处理“程序员很少接触客户”的情况？
Kent Beck: 我想这些接触一般运作得不是很好。这就是为什么我说XP是软件开发的社会系统。频繁地和其生活受你写的软件影响的人接触，这能使你重视它。
tensile: 软件开发的社会系统？
Kent Beck: 首先，所有的团队成员聚集坐在一个大房间内：程序员、管理者、客户、分析师、测试员、用户文档、交互设计。其次，“客户团队”(customer team)提出编程团队必须通过的验收测试(acceptance tests)。学习如何通过这些测试需要沟通。
skyin: 每个人都有自己的任务，那如何双人编程时如何分配任务呢？
Kent Beck: 今天早上我将与你共同做你的任务，下午你可以帮我做我的。
yhufo: 能否介绍一些XP 的工具？
Kent Beck: 我使用Eclipse作为Java工具，我真的很喜欢它。有时我也使用IntelliJ，还有，JUnit或它在其他语言的姊妹产品，在单元测试及建立验收测试架构时非常有帮助。
xlp223: 每对双人编程都有自己独特的风格和水平，重构怎样才能使它变得一致和平衡？and person or group to do refactoring need be arranged in addition.
Kent Beck: 合唱团中的人，每人都有自己的声调。他们是如何让这些声音和谐？他们先决定最重要的和声然后“以他们的方式”唱出。在程序员团队中也是同样的道理。团队中所有人的成功，比个人的闪耀更重要。
notyy: 安排一个“在场客户”（on-site customer）在某些情况下实在困难。
Kent Beck: 想办法找到一个，否则准备接受失败。旧的Taylorist 软件开发社会结构没有用了，要有新的社会结构。如果让软件开发运作成功是重要的，坐在一起是绝对关键的。如果想做好却不认为那是重要的，或许这个项目应该取消。
yhufo: 为什么XP 不需要文档！
Kent Beck: XP确切需要两种文档-代码及测试。如果你的团队觉得需要更多的文档，那么去做就是了。大多数的团队发现他们并不需要其他的内部(internal)文档。
taoxie: 你说客户注重合同型（Contract-style）的项目，我就碰到了这种情况。XP 怎样应用在套装软件产品开发中？
Kent Beck: 对于套装软件(shrink-wrap)开发公司而言，客户团队（行销、测试、可用性、客户服务）是比使用自制型(in-house)开发的公司要大。除此之外，大家都同意使用单一的需求序列（故事）可以让软件开发越来越平滑(smoothly)。
tooliu: 不介意解释一下WinDNA 和XP 的关系吧？
Kent Beck: XP是Extreme Programming，不是操作系统。
xlp223: 做重构的人或组需要额外安排吗？
Kent Beck: 设计是每一个人的责任。当我们坐在一起而我们看到需要重构的地方，我们就重构。如果你还需要去安排进度，那你就等得太久了。
notyy: 我们应该首先教育客户吗？
Kent Beck: 客户需要知道XP吗？绝对需要。他们是团队的一份子，因此他们需要知道团队如何运作。故事及验收测试是需要先教给他们的两个最重要的事情，然后是发行(release)（3-12个月）及迭代(iteration)（1-3周）的计划。
skyin: 看起来XP 更适合客户导向的应用软件，那其他类型的软件呢？
Kent Beck: 还有其他类型吗？如果没有客户，为什么要写这些软件？
Charity_Zhou: 因此我想XP 对客户有更高的需求。
Kent Beck: XP当然对于客户有更多的要求。他们是可以看到的而且可以控制，同时他们负责挑选系统的范围。
smilemac: 我觉得XP 和演化（evolution）过程很象，你能解释一下区别吗？
Kent Beck: XP确实使用演化或成长的隐喻(metaphor)。然而XP指定许多实践来支持长期的持续性成长。Gilb的演化式的交付工作在概念上是类似的，但对于如何达成目标。他没有说明太多。XP说：先测试、双人编程、坐在一起、随时集成然后你就能使你的软件成长及演化。
fpeng: 发行计划（release planning）和迭代计划（iteration planning）的区别是什么？
Kent Beck: 发行与业务循环同步，所以它们是3-12个月的时间。迭代与工程师需要的里程碑同步，所以它们是1-3周的时间。
dggh: XP 需要团队中的每一个人都是系统分析专家吗？这也太难了！
Kent Beck: 团队需要系统分析专家，但不意味着每一个人都需要做系统分析。类似的，团队可能需要数据库专家，但只需3-4个人深入了解数据库的知识，而其他所有的人如果需要可以协助做数据库的任务。我不认为推卸责任是在中国的特别问题，我认为这是任何地方的特别问题。我们从Fred Taylor那里获得工作的社会结构概念，一位上个世纪初的工业工程师。他假设工人是懒惰而且愚笨的，因此他们需要有人为工人计划并有人检查工人的工作（品质保证(QA)）。这个社会结构在软件中并不能良好运作，因为大部分的程序员既不懒惰也不愚笨。不管如何，Taylor的范例执行得非常深入以致多数人甚至不知道概念是来自何处。
dggh: 当团队速度变慢时，我们能做什么？
Kent Beck: 我今天刚写了一封长信到Yahoo小组的XP邮件列表中。简单的回答就是要让团队速度加快，唯一的方式就是鼓舞团队的士气。
zhujigang: 我们的团队确实使用了双人编程，但如果有一对完成了他们的故事，而其他人还没有完成时，这一对该做什么？他们需要等别的人吗？
Kent Beck: 在每一次迭代中每个程序员签认一些任务。如果一个任务完成了，开始另外一个，或帮助你的同伴开始做他的任务。
simplebest: 你是否使用设计模式？
Kent Beck: 我绝对使用模式。如果你检视JUnit，到处都是设计模式。它是我曾经做过的设计最密集的部分之一，不管如何，设计模式被应用是因为我们需要它们，而不是因为我们认为它们可能是有用的。我们写一个测试，使之运行，然后注意到，如果我们引进设计模式，代码是否可以更清晰。我们通过重构来把设计模式放到正确的地方。4 年后我们仍将做相同的事情。熟练的设计师可以通过使用设计模式，把讨论设计的时间从几小时缩短到几秒钟之内。
skyin: 你认为XP 象管理领域里的“学习型组织”吗？
Kent Beck: 是的。XP依赖整个团队持续学习如何更好地互动。
yhufo: 是不是团队中的每一个人都应该测试软件？
Kent Beck: 如果我们要协调权力与责任，那么每一个程序员，他们有权力产生缺陷，必须同时有责任去测试。我看不到其他的方式可以解决这个难题。
fpeng: 你认为我们在使用XP 时，是否需要软件来管理整个XP 的过程？
Kent Beck: 当初我对XP所做的第一件事情，就是写一个项目管理工具，实际上这是浪费时间。XP是一种新的习惯。用最简单可能的设备（几张纸贴在墙上就不错了）养成这个习惯。只要养成这种习惯同时团队找到其精神，你就可以开始引进软件来管理，而不至于破坏过程。
adylee: 你如何看待CMM 和XP？
Kent Beck: CMM起源于制造业。那是从所谓的制造业成熟模式(Manufacturing Maturity Model)复制而来。软件并不像实体的制造业。每一个软件的开发都不一样，而有时候根本就是如此（and sometimes radically so.）。
simplebest: 你认为RUP 和XP 哪种更适合中国的程序员？
Kent Beck: 这一点我不清楚。XP提出来自每一种文化的程序员的问题，其不同的部分也有提到。XP在中国最困难的部分在哪里？
tensile: XP 是依赖软件还是依赖人？
Kent Beck: XP绝对是依赖人的，好的人倾向于做好的事情，功力差的人做得差一些。
dggh: 代理客户不知道客户的需要，那怎么办？
Kent Beck: 当我上次在日本，他们说他们无法诚实地面对客户，因为客户是上帝。我问是否一个即时(just-in-time)供应商会对他们的客户诚实。“喔，是的，当然。否则是不行的”。我想这就像XP。我们需要对我们的客户诚实并且向他们保证。他们一开始并不喜欢这样，但结果是如此的棒，所以他们会学习去要求这种新层次的投入。
notyy: Kent，你应该知道这样一句话，“没有人因为使用IBM 的产品而受到惩罚”，同样，那么多公司的经理想使用RUP 和CMM。
Kent Beck: 在“没有人因使用XP而被解雇”成为现实之前会如何？我们将努力达到这个目标。“喔，你的团队已经三个月没有交付任何软件了。怎么办？你被解雇了。”我将举一个技术问题为例--模式产生架构。原来的问题是“模式与架构之间的联系是什么？”，这发生在设计模式还是新概念的时候。因此Ralph【编注：指设计模式GOF的Ralph Johnson】和我跑进一家旅馆的房间去封闭思考，尝试回答这个问题。我们找到的答案就像定理(theorem)可以从第一个原理(principles)导出，因此一个架构可以从第一个原理（模式）被导出。这个论点--没有人能够证明是或不是—就是任何架构都可以从一小撮模式的后续应用推导出来。
tensile: 能否谈谈XP 和UML 的关系
Kent Beck: XP是一个软件开发的社会(social)系统，UML是一个描述软件的标记法(notation)。你可以在XP中使用UML，但团队良好的进展并不需要许多文档，除了代码及测试外。
yhufo: XP 中的文档重要吗？需要写什么样的文档？
Kent Beck: 你要写的文档就是代码及测试。
superlong: XP 如何用在一个可视化项目中？
Kent Beck: XP程序员并不是不做视觉上的思考(think visually)，他们只是一般不储存图片(picture)。
notyy: XP 可以解决什么问题？
Kent Beck: 当你有许多关于需求的不确定性，XP让你快速得到一个具体、运行中的系统，同时让你以一个相当稳定的速度(pace)修改。以这种方式你无须在开始之前知道所有的事。
yhufo: 但CRC 卡及故事--这些都不是文档。
Kent Beck: 你无须永远保存。你从CRC卡及故事获得内容，然后把他们丢掉。
joe_lee: XP 是一种递归过程（recursive process）吗？
Kent Beck: 是的，或者我可能说『不规则碎片形(fractal)』。以一年为期，描述你所想要的（故事）然后去做。以一分钟为期，描述你想要的（单元测试）然后去做（编写代码）。分解的不规则碎片形是经过相当的深思熟虑的(deliberate)。
taoxie: 你提到了单元测试。我同意rerun 所有的单元测试是合理的，那么rerun 所有的集成测试也是合理的吗？
Kent Beck: 如果你有适当的准备而且够快的话，你可以随时执行测试。
yhufo: 如果我们没有文档，我怎么知道怎样能控制软件中的变更呢？我想我们必须建立文档！
Kent Beck: 当你们说『控制变更』，我则说『鼓励变更(encourage change)』。控制来自测试、双人编程、大家坐在一起讨论及持续集成。XP对于受过良好训练的程序员运作得很好，但是如果目前不觉得有良好的训练，别担心。你的搭挡可以帮你，不然你的集成工作无法达成，你必须把你的代码丢弃。
dggh: 能谈谈xp practise games 吗？
Kent Beck: 我做过一个练习让人们描绘一个咖啡壶的图像。从这里显示有更好的game。在伦敦有人建造乐高(Lego)机器人。Joshua Kerievsky有一个团队写了一个剧本（电影的脚本）。
gigix: 我想我们必须先小心地设计。如果我们忽视了设计的重要性，XP（或重构）将不能对整个项目有改进。对此你如何看？
Kent Beck: 我就知道迟早要讨论这个。我，同样地，坚持我们需要小心地设计。我宁愿等待并且在我有一些经验后再做，而不愿依据猜测(speculation)做设计。前置设计（Up front design）是一种正向反馈的循环(positive feedback loop)。你越有经验，你越可以考虑前置设计，直到你完全无用(useless)。另一种使用设计经验的方式是等待你的好想法，直到这些想法显露出来，立即就可以用得上。
joe_lee: 如果没有文档，我们怎样维护软件？
Kent Beck: 你有两个非常有价值的文档-代码及测试。如果测试总是能够100％执行而且绝不会允许逆行(regress)，你还需要什么？
yhufo: 在双人编程中，两个人应该经常变换角色吗？一天或两天，我是说多久换一次，一天或两天？
Kent Beck: 在比较大的团队中，每天变换（switch）2-4次。在一天之中我无法维持一个双人组6个小时以上，因为专注的程度太过激烈。
xlp223: 既然XP 没有专家，那XP leader 在程序员当中扮演什么角色，客户，经理？
Kent Beck: XP是有专家，但他们的角色并不像以前一样是固定的。专家的出现是由团队中的每一个人依据经验挑选出来的。促使这种专家的出现是管理者扮演的角色。
yhufo: 在双人编程中，当一个人编写代码时，另一个人在干什么？只是看和说话吗？
Kent Beck: 双人编程并不是看着别人编写代码。编写代码就像是在沟通。键盘每几分钟便传来传去。双人编程时，你们讨论相关的想法，试试一个，建议另一个测试，把你下一个想法画个草图，写成代码，做些重构等等，持续进行下去。
dggh: 如何处理“程序员很少接触客户”的情况？
Kent Beck: 我想这些接触一般运作得不是很好。这就是为什么我说XP是软件开发的社会系统。频繁地和其生活受你写的软件影响的人接触，这能使你重视它。
tensile: 软件开发的社会系统？
Kent Beck: 首先，所有的团队成员聚集坐在一个大房间内：程序员、管理者、客户、分析师、测试员、用户文档、交互设计。其次，“客户团队”(customer team)提出编程团队必须通过的验收测试(acceptance tests)。学习如何通过这些测试需要沟通。
skyin: 每个人都有自己的任务，那如何双人编程时如何分配任务呢？
Kent Beck: 今天早上我将与你共同做你的任务，下午你可以帮我做我的。
yhufo: 能否介绍一些XP 的工具？
Kent Beck: 我使用Eclipse作为Java工具，我真的很喜欢它。有时我也使用IntelliJ，还有，JUnit或它在其他语言的姊妹产品，在单元测试及建立验收测试架构时非常有帮助。
xlp223: 每对双人编程都有自己独特的风格和水平，重构怎样才能使它变得一致和平衡？and person or group to do refactoring need be arranged in addition.
Kent Beck: 合唱团中的人，每人都有自己的声调。他们是如何让这些声音和谐？他们先决定最重要的和声然后“以他们的方式”唱出。在程序员团队中也是同样的道理。团队中所有人的成功，比个人的闪耀更重要。
notyy: 安排一个“在场客户”（on-site customer）在某些情况下实在困难。
Kent Beck: 想办法找到一个，否则准备接受失败。旧的Taylorist 软件开发社会结构没有用了，要有新的社会结构。如果让软件开发运作成功是重要的，坐在一起是绝对关键的。如果想做好却不认为那是重要的，或许这个项目应该取消。
yhufo: 为什么XP 不需要文档！
Kent Beck: XP确切需要两种文档-代码及测试。如果你的团队觉得需要更多的文档，那么去做就是了。大多数的团队发现他们并不需要其他的内部(internal)文档。
taoxie: 你说客户注重合同型（Contract-style）的项目，我就碰到了这种情况。XP 怎样应用在套装软件产品开发中？
Kent Beck: 对于套装软件(shrink-wrap)开发公司而言，客户团队（行销、测试、可用性、客户服务）是比使用自制型(in-house)开发的公司要大。除此之外，大家都同意使用单一的需求序列（故事）可以让软件开发越来越平滑(smoothly)。
tooliu: 不介意解释一下WinDNA 和XP 的关系吧？
Kent Beck: XP是Extreme Programming，不是操作系统。
xlp223: 做重构的人或组需要额外安排吗？
Kent Beck: 设计是每一个人的责任。当我们坐在一起而我们看到需要重构的地方，我们就重构。如果你还需要去安排进度，那你就等得太久了。
notyy: 我们应该首先教育客户吗？
Kent Beck: 客户需要知道XP吗？绝对需要。他们是团队的一份子，因此他们需要知道团队如何运作。故事及验收测试是需要先教给他们的两个最重要的事情，然后是发行(release)（3-12个月）及迭代(iteration)（1-3周）的计划。
skyin: 看起来XP 更适合客户导向的应用软件，那其他类型的软件呢？
Kent Beck: 还有其他类型吗？如果没有客户，为什么要写这些软件？
Charity_Zhou: 因此我想XP 对客户有更高的需求。
Kent Beck: XP当然对于客户有更多的要求。他们是可以看到的而且可以控制，同时他们负责挑选系统的范围。
smilemac: 我觉得XP 和演化（evolution）过程很象，你能解释一下区别吗？
Kent Beck: XP确实使用演化或成长的隐喻(metaphor)。然而XP指定许多实践来支持长期的持续性成长。Gilb的演化式的交付工作在概念上是类似的，但对于如何达成目标。他没有说明太多。XP说：先测试、双人编程、坐在一起、随时集成然后你就能使你的软件成长及演化。
fpeng: 发行计划（release planning）和迭代计划（iteration planning）的区别是什么？
Kent Beck: 发行与业务循环同步，所以它们是3-12个月的时间。迭代与工程师需要的里程碑同步，所以它们是1-3周的时间。
dggh: XP 需要团队中的每一个人都是系统分析专家吗？这也太难了！
Kent Beck: 团队需要系统分析专家，但不意味着每一个人都需要做系统分析。类似的，团队可能需要数据库专家，但只需3-4个人深入了解数据库的知识，而其他所有的人如果需要可以协助做数据库的任务。我不认为推卸责任是在中国的特别问题，我认为这是任何地方的特别问题。我们从Fred Taylor那里获得工作的社会结构概念，一位上个世纪初的工业工程师。他假设工人是懒惰而且愚笨的，因此他们需要有人为工人计划并有人检查工人的工作（品质保证(QA)）。这个社会结构在软件中并不能良好运作，因为大部分的程序员既不懒惰也不愚笨。不管如何，Taylor的范例执行得非常深入以致多数人甚至不知道概念是来自何处。
dggh: 当团队速度变慢时，我们能做什么？
Kent Beck: 我今天刚写了一封长信到Yahoo小组的XP邮件列表中。简单的回答就是要让团队速度加快，唯一的方式就是鼓舞团队的士气。
zhujigang: 我们的团队确实使用了双人编程，但如果有一对完成了他们的故事，而其他人还没有完成时，这一对该做什么？他们需要等别的人吗？
Kent Beck: 在每一次迭代中每个程序员签认一些任务。如果一个任务完成了，开始另外一个，或帮助你的同伴开始做他的任务。
simplebest: 你是否使用设计模式？
Kent Beck: 我绝对使用模式。如果你检视JUnit，到处都是设计模式。它是我曾经做过的设计最密集的部分之一，不管如何，设计模式被应用是因为我们需要它们，而不是因为我们认为它们可能是有用的。我们写一个测试，使之运行，然后注意到，如果我们引进设计模式，代码是否可以更清晰。我们通过重构来把设计模式放到正确的地方。4 年后我们仍将做相同的事情。熟练的设计师可以通过使用设计模式，把讨论设计的时间从几小时缩短到几秒钟之内。
skyin: 你认为XP 象管理领域里的“学习型组织”吗？
Kent Beck: 是的。XP依赖整个团队持续学习如何更好地互动。
yhufo: 是不是团队中的每一个人都应该测试软件？
Kent Beck: 如果我们要协调权力与责任，那么每一个程序员，他们有权力产生缺陷，必须同时有责任去测试。我看不到其他的方式可以解决这个难题。
fpeng: 你认为我们在使用XP 时，是否需要软件来管理整个XP 的过程？
Kent Beck: 当初我对XP所做的第一件事情，就是写一个项目管理工具，实际上这是浪费时间。XP是一种新的习惯。用最简单可能的设备（几张纸贴在墙上就不错了）养成这个习惯。只要养成这种习惯同时团队找到其精神，你就可以开始引进软件来管理，而不至于破坏过程。
adylee: 你如何看待CMM 和XP？
Kent Beck: CMM起源于制造业。那是从所谓的制造业成熟模式(Manufacturing Maturity Model)复制而来。软件并不像实体的制造业。每一个软件的开发都不一样，而有时候根本就是如此（and sometimes radically so.）。
simplebest: 你认为RUP 和XP 哪种更适合中国的程序员？
Kent Beck: 这一点我不清楚。XP提出来自每一种文化的程序员的问题，其不同的部分也有提到。XP在中国最困难的部分在哪里？
tensile: XP 是依赖软件还是依赖人？
Kent Beck: XP绝对是依赖人的，好的人倾向于做好的事情，功力差的人做得差一些。
dggh: 代理客户不知道客户的需要，那怎么办？
Kent Beck: 当我上次在日本，他们说他们无法诚实地面对客户，因为客户是上帝。我问是否一个即时(just-in-time)供应商会对他们的客户诚实。“喔，是的，当然。否则是不行的”。我想这就像XP。我们需要对我们的客户诚实并且向他们保证。他们一开始并不喜欢这样，但结果是如此的棒，所以他们会学习去要求这种新层次的投入。
notyy: Kent，你应该知道这样一句话，“没有人因为使用IBM 的产品而受到惩罚”，同样，那么多公司的经理想使用RUP 和CMM。
Kent Beck: 在“没有人因使用XP而被解雇”成为现实之前会如何？我们将努力达到这个目标。“喔，你的团队已经三个月没有交付任何软件了。怎么办？你被解雇了。”我将举一个技术问题为例--模式产生架构。原来的问题是“模式与架构之间的联系是什么？”，这发生在设计模式还是新概念的时候。因此Ralph【编注：指设计模式GOF的Ralph Johnson】和我跑进一家旅馆的房间去封闭思考，尝试回答这个问题。我们找到的答案就像定理(theorem)可以从第一个原理(principles)导出，因此一个架构可以从第一个原理（模式）被导出。这个论点--没有人能够证明是或不是—就是任何架构都可以从一小撮模式的后续应用推导出来。
cmm2cmmi 2009-02-28
- 打赏
- 举报
[Quote=引用 4 楼 PEgirl 的回复:]
谢谢sp1234的答复。
我是一名过程改进人员。目前在组织内推CMMI，开发人员普遍不愿意写文档，还处于你所说“想到哪里才开发到哪里”的方式。项目经理以“敏捷开发”来解释为什么不需要文档。
[/Quote]
敏捷开发
呵呵
那你问问项目经理
他做估算了吗？没有文档怎么证明他做了估算
他怎么跟客户沟通的，沟通计划不就是文档吗，沟通记录不就是文档吗，没有沟通记录就说沟通了，口头沟通，不写在纸面的事情客户跟你扯皮你都扯不清
他测试用例怎么做的，测试用例不能没有文档记录吧
文档多了～～
有些都是非常必要的
我觉得你作为PPQA，有的时候还是积极引导，先找个突破点吧，而且要从利益出发，天下熙攘皆为利往，告诉项目组，项目经理这样做对他们有什么好处。
如果项目组真的很抵触，审计报告报给他的上司吧，否则项目出了问题，你脱了不了责任。
一家之言仅供参考
祝你成功～～
谢谢sp1234的答复。
我是一名过程改进人员。目前在组织内推CMMI，开发人员普遍不愿意写文档，还处于你所说“想到哪里才开发到哪里”的方式。项目经理以“敏捷开发”来解释为什么不需要文档。
[/Quote]
敏捷开发
呵呵
那你问问项目经理
他做估算了吗？没有文档怎么证明他做了估算
他怎么跟客户沟通的，沟通计划不就是文档吗，沟通记录不就是文档吗，没有沟通记录就说沟通了，口头沟通，不写在纸面的事情客户跟你扯皮你都扯不清
他测试用例怎么做的，测试用例不能没有文档记录吧
文档多了～～
有些都是非常必要的
我觉得你作为PPQA，有的时候还是积极引导，先找个突破点吧，而且要从利益出发，天下熙攘皆为利往，告诉项目组，项目经理这样做对他们有什么好处。
如果项目组真的很抵触，审计报告报给他的上司吧，否则项目出了问题，你脱了不了责任。
一家之言仅供参考
祝你成功～～
以专业开发人员为伍 2009-02-26
- 打赏
- 举报
基本上，没有技术能力做到我在1楼所说的，是几乎不可能做好真正的敏捷开发的，只会因为混乱而变成是吵架开发。如果做到甚至连大部分UI都自动化测试（更不要提底层的一些子模块接口规格的集成测试也一样做的相当全面），这样才能算是把车子开在敏捷开发这个高速路上。否则，搞敏捷开发只是时髦，没有上路。
以专业开发人员为伍 2009-02-26
- 打赏
- 举报
嗯，你反对鼠目寸光借助敏捷开发为借口逃避CMMI过程是对的！你的项目经理想尝试敏捷开发也是对的。呵呵，希望你们会取得共识。
百年树人 2009-02-25
- 打赏
- 举报
学习了。
加载更多回复（8）
