gz

我看到无数美好的理想，可是怎么实现呢？
和其他方法比能节约多少开发时间，多少开发人员，受不受维护的困扰？
如何具体应用在项目上？架构是开发的中心吗？怎么样才能尽早提交？
有具体步骤没有，gz

yangzhenhai(叉子) 
这只是一个宣言 具体的实现有不同的方法 比如XP 水晶 FFD
你可以自己选定一种

XP的理念好象就是这样的，不知道你们是如何做的？
我们已经厌倦空洞的说教和口号，给我一个实践的例子！！！

中秋节好！

xp agile 什么的都要对工程有实际作用才有用。
不然真没有什么价值！

可能来这里的人一直在变，对于我过去写的一些有关XP实践的介绍，
有一些人可能没有看过，或者觉得还不够充分，我想与其我老生常谈地
介绍我参加过的几个事例，还不如大家多做有心人，到网上多收集这方面
的信息，这样会更有说服力。只要大家做一下有心人，就会发现近期有关
XP实践的介绍的文章确实是越来越多了，最近几期的《非程序员》里也有
大量的关于XP方法的问答，介绍，实例，分析等等，都非常具有说服力。

  为什么有这么多有关XP方法的资料，这么多的实例。我们中的有一些人，
还是觉得它比较虚，还不容易接受呢？我看最主要的问题还是主观认知上
问题，因为还没有从实践中真正领悟到软件离不开敏捷这个道理，这就理所
当然地在感情上拒绝敏捷方法，会对所有有关敏捷方法论的成功案例的报道
视而不见了。

  敏捷方法是随着面向对象的软件开发技术诞生，随着我们对软件的认知
的提高而诞生的一种软件开发方法。我觉得如果还没有真正使用面向对象
方法去组织，设计，开发过软件商品（或项目）的话，对面向对象的技术
还不十分了解，或一知半解的话，确实比较难体会敏捷的重要性的。所以
我建议目前还没有使用面向对象方法开发软件的人，暂时不必急于追风搞
敏捷方法，还是先把精力放在学习面向对象方法，提高对软件的认知程度上
为妥。等对面向对象方法有了深入的体会以后，就会理解为什么几乎所有的
面向对象的倡导者和实践者，都是敏捷方法的拥护者这一事实了。

  如果真正理解了面向对象的方法的话，就会体会到软件开发的真谛是我们
对世界的“认知”。软件开发的第一道难关是什么呢？是需求，而获得需求
不真是对问题域的认知问题嘛。软件开发的第二道难关是什么？是设计，在
面向对象方法中的设计其实就是对现实世界的描述，这也是一个认知问题。
软件开发的第三道难关是维护，而当一个软件是按照现实世界的真实来设计
的话，软件的维护也就变成了还原现实世界的本来面目（重构）。真如
yangzhenhai (叉子) 在《我看软件工程 之一》中写的那样“开发软件是
一个把现实世界映射到计算机世界里一个工作过程”，在这里他说得非常
好。软件开发的过程其实就是一个对现实世界的认知过程。问题是我们是
怎么认识这个世界的呢。会不会像在同一篇文章中写得那样，走两点之间
一直线呢？显然，这里yangzhenhai (叉子)忘记了前面的有关软件是对
世界的认识这一断言了。当我们在软件开发过程中，还没有对现实世界有
足够清晰的认识的时候，也就是说我们连目的地还没有明确的时候，我们
怎么可能存在着这样的一条两点间的笔直直线呢？如果这时我们还盲目地
追求直线的话，恐怕就会因出发时的毫厘之误，造成最终的千里之差了。
其实认识论已经告诉我们了，认知的过程是一个不断循环反复，否定之
否定的过程；认识论告诉我们世界的真实只有通过实践来获得，来验证；
认识论还告诉我们世界是普遍联系的，世界本质是相通的。而敏捷方法中
的迭代开发，重视测试，简单设计等等就是这些认识论的原理在软件开发
上的具体应用。

  好了，说了这么多。可能有人会讲，道理我们都懂，问题是怎么操作。
确实一般来讲认识论中的方法都是一些如“细观察，多动脑”之类的较
抽象的东西。但是这也不是说就不能操作了，比如XP方法中的十二条
规则，每一条都是非常具体的，可操作的。XP方法是一个完全来至于实践
的方法论，它的每一条规则都是被具体操作过，被具体的实例验证过的。
虽然XP方法提倡同时执行这十二条，但是我觉得只要有条件从关键的几条
开始执行，每执行一条都会给你的开发工作带来益处的（请严重注意，
执行XP方法是有条件的，有关条件请参考有关资料）。如果说这样还不够
具体的话。可能就和国内的教育比较有关了，因为国内的教育只培养对
具体的知识的理解能力，而对于认识论这样一个有关知识获取的方法论的
理解能力的培养还是有欠缺的。

原来软件开发和可观世界的发展规律一样，都是螺旋上升的，

坚定支持软件开发的马克思主意方法论，呵呵

能推荐基本好书吗？期待ing

赞同。理念的长久性优于其正确性。
可惜又是洋人的，国内有没有类似的公司？

我的观点是，不适合中国国情。

up,gz

希望多多指点

学习，再学习

To bydpdwz(蚊子):

  谢谢你的支持。有一点补充一下，据我所知我们平时讲的马克思
哲学思想是辩证唯物主义，而不是认识论。认识论和马克思主义无关。

To yan_stone():

  最近邮电出版社出了一套XP的丛书，我觉得还是不错的。还有下面
的网页，有有关XP方法的网站连接很不错。
http://www.iturls.com/SoftwareEngineering/SE_Agile.asp
还有我上一贴也提了，要了解敏捷方法，首先必须先了解面向对象的
方法，了解以架构为核心的软件构成方法。所以先要把那部分知识
掌握好。

To lishu1980(IT工人):

  我不知道你的论据是什么？凭什么得出这样的结论。是实践后
得出的结论，还是凭你对中国国情的主观认识？

  我到觉得在中国推广敏捷方法的主要障碍是面向对象，设计模式，
软件架构知识的缺乏，以及对软件的认知的不足上。

谢谢 AiWangji(爱忘记) 捧场 
我不可能在这个贴中介绍完整的敏捷方法 我只是想介绍一下大概的敏捷的原则 也就是什么就是敏捷了 什么不是敏捷 看来很多人还没有体会

个体和交流优先于过程和工具＝就是尊重人 把个性和交流放在软件过程和工具之前 就是认为过程应该服务于人的需要 交流是人合作的基础 也是项目进行的基础 和后面的面对面谈话相对应 可以看出敏捷对文档在交流中的看法

可以工作的软件优先于全面的文档＝这一点非常有争议 虽然很多人羞羞答答的说XP符合CMM2或者3级的KPA 但是那是他们不肯面对事实 敏捷对文档的太多是使用和适用的式的 

顾客的合作优先于契约的协商＝对项目成员的态度问题 这个不用作很多介绍 但是大家一定要考虑这样做的后果 其实在敏捷下隐含这说明项目的周期是长久的

面对变化优先于遵守计划＝预知未来是不可能 这一点已经有数学的证明 而且由于周期的长久 变化的快速 于是决定了敏捷对变化的态度 就像开车 以前的方法认为只要在出发前定好了路线就可以直达 所以就要在出发前多做工作 一定要把车的方向定准 而敏捷认为应该只给一个大概的目的地 然后要在路上不断地调整方向 

敏捷的做法现在越来越是主流的做法 比如水晶本来就是IBM内部的一些人的成果 而且如果你研究msf 就会发现其实很多原则就是敏捷的

看看

好，马上就去买书看

up

up

gz帮忙UP

up

请教ozzzz,
xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”心态设计开发，再用自动测试工具武装起来？
感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？OO的最小接口原则本身似乎就和xp的宗旨不谋而合。

敏捷方法，有些认识了，但是对于敏捷建模，还不太明白，可否讨论一下？

ajoo(聪明的一猪) 
其实说敏捷是由程序员推动的 还不如说是有顾问们发起 商人推动的 
敏捷带来的适配性对于现代企业和组织的吸引已经足够的大 即使是RUP现在也在说自己并不重 而且他们自己也搞了一个符合xp的dx cmm的人也在说xp符合他们的2、3级 可是我怎么就发现不了 总之现在敏捷的势头太大没有什么人干忽视它 特别是OO体系下的人 如果不知道敏捷简直就是笑话

arfayr(阿飞) 
AM现在还没有成型 不过已经有了一些说法 你可以去WWW.agilechina.ORG那个地方 有些介绍和链接 最好还要参加他们的maillist 如果有什么问题 我们也可以在这里讨论

商人们懂什么叫xp吗？那不是外行领导内行？如果xp不合适，岂不是削足适履？xp除了refactor-test, refactor-test, 还有什么更可操作可控制的方法吗？

问题是这种方法适合中国的国情吗？

适合5-8人的小团队吗？ 
如果可以，那具体要如何实施呢？有什么成功的经验吗？

看过一本XP的书，其中有一种做法是，两个人成对编程。
一个人编，一个人在旁边看？ 这样做是不是。。。？

我对这方面懂得很少,向楼主和各位前辈指教了!

ajoo(聪明的一猪) 
商人们看重的是效率和效益 而xp给他们带来的东西让他们吃惊 
 Go_Rush(阿舜) 
xp无国界 xp适合效团体 如果团体是大型的反倒要做修改 
关于PP已经有很多讨论 基本上都是没有实施PP的对其不理解和经验不足带来的问题 
还有关于面向对象 是最重要的 如果你们不是OO 那么最好学习一下

ozzzzzz兄，能否对我的认识，做一下批评？
“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”心态设计开发，再用自动测试工具武装起来？”
这就是我目前对xp得全盘认识了。
再有，就是加上，一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生不老药。

ajoo(聪明的一猪) 
XP是商业环境变化的结果 

===一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生不老药。？？？？？？？？

不太明白你的意思 我想你可能不理解重构 重构就是设计阿 而且现在重构是OO下得到验证的最好设计方法阿 如果不懂设计 怎么可能知道重构呢

xuexi

门口卖菜的也可能听过重构这个词的。就象有谁不知道OO呢？又有多少人真正懂得OO呢？

我的意思是，要重构，也应该有一个至少是有弹性的初始结构。否则重构也是会有很大难度的。举个例子，就象某人写了个类，放了若干个不该放的方法，公开了很多不该公开的实现细节，甚至包括一些共有变量。
那么，如果这个类已经被广泛使用了，重构的难度就很大。
所以，keep it simple我是同意的。但keep it stupid我就不同意了。至少这个"stupid"不是可以随便瞎写的代名词。接口和封装一定是要从开始就注重的。你可以很方便的加东西，但一旦一个东西发布出去了，再想删改，不是那么容易的事。

ajoo(聪明的一猪) 
看来你对REFACTORING没有什么了解 建议你注意最近的出版动态 
keep it simple和keep it stupid的关系是一个问题的两个方面 
XP设计的方法是这样的在开始的时候采取最方便的方法实现 然后是在添加前看你的设计是否可以很合适添加（看看味道好不好） 然后如果有必要就重构 
重构之后才添加 重构不添加任何东西 添加就不出够

to ajoo(聪明的一猪):

  我来替 ozzzzzz(希望敏捷) 来回答一下你的问题，你不介意吧。

问：“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”
心态设计开发，再用自动测试工具武装起来？”

不知你读过我前面写的帖没有。是不是我还没有表达清楚呢，那个帖
的主题就是软件的本质是对世界的认知，而认知必然是一个循序渐进
的过程；需要实践不断验证的过程。也就是说，敏捷方法是由于我们
提高了对软件的认识后，必然会产生的符合软件开发这一对现实世界
认知过程的方法。而决不仅仅是几个程序员的一时心态。

请注意：Ivar Jacobson 这一次到中国来的演讲主题已经是“面向对象
的软件工程”了。可以这样讲真正了解面向对象的人，都已经认识到
面向对象的软件工程不可能沿用传统的软件工程方法了。

问：“感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？
OO的最小接口原则本身似乎就和xp的宗旨不谋而合。”

对，可以讲XP方法就是为面向对象而诞生的。我想如果你真的实施过
XP方法的话，你还为发现，用XP方法做发面向对象，是再和谐不过了。
而你讲的“不断求精，逐渐更改设计”，真是你自己不自觉地在使用
敏捷了，这恰恰说明了敏捷的重要，你离不开敏捷。而它并不是传统
软件工程方法所提倡的。请不要混淆。

问：“一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？
可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生
不老药。”

敏捷确实赞成重构，但是它还有一个最主要的前提就是：简单设计。
XP方法要求任何时刻的设计都应该是简单设计，而简单的设计是指满足
下列四个条件的设计。
1）通过所有测试。
2）呈现所有的设计意图。
3）避免一切重复。
4）使用最少数量的类，及类的方法。
请问能时刻满足这种要求的简单设计会成为“一些不懂设计的人”的
上方宝剑吗？我看你是多虑了。相反，XP方法完全是一种以人为本
的方法论，它以人性化的方法逼迫你必需不断学习，对设计精益求精。
所以任何不了解对面向方法的人，不懂得什么才是重构的人，在XP方法
下，都是没有立足之地的。这些人只会恐惧XP，排斥XP，而绝不敢拿
XP做为上方宝剑的。

to ajoo(聪明的一猪):

  我来替 ozzzzzz(希望敏捷) 来回答一下你的问题，你不介意吧。

问：“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”
心态设计开发，再用自动测试工具武装起来？”

不知你读过我前面写的帖没有。是不是我还没有表达清楚呢，那个帖
的主题就是软件的本质是对世界的认知，而认知必然是一个循序渐进
的过程；需要实践不断验证的过程。也就是说，敏捷方法是由于我们
提高了对软件的认识后，必然会产生的符合软件开发这一对现实世界
认知过程的方法。而决不仅仅是几个程序员的一时心态。

请注意：Ivar Jacobson 这一次到中国来的演讲主题已经是“面向对象
的软件工程”了。可以这样讲真正了解面向对象的人，都已经认识到
面向对象的软件工程不可能沿用传统的软件工程方法了。

问：“感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？
OO的最小接口原则本身似乎就和xp的宗旨不谋而合。”

对，可以讲XP方法就是为面向对象而诞生的。我想如果你真的实施过
XP方法的话，你还为发现，用XP方法做发面向对象，是再和谐不过了。
而你讲的“不断求精，逐渐更改设计”，真是你自己不自觉地在使用
敏捷了，这恰恰说明了敏捷的重要，你离不开敏捷。而它并不是传统
软件工程方法所提倡的。请不要混淆。

问：“一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？
可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生
不老药。”

敏捷确实赞成重构，但是它还有一个最主要的前提就是：简单设计。
XP方法要求任何时刻的设计都应该是简单设计，而简单的设计是指满足
下列四个条件的设计。
1）通过所有测试。
2）呈现所有的设计意图。
3）避免一切重复。
4）使用最少数量的类，及类的方法。
请问能时刻满足这种要求的简单设计会成为“一些不懂设计的人”的
上方宝剑吗？我看你是多虑了。相反，XP方法完全是一种以人为本
的方法论，它以人性化的方法逼迫你必需不断学习，对设计精益求精。
所以任何不了解对面向方法的人，不懂得什么才是重构的人，在XP方法
下，都是没有立足之地的。这些人只会恐惧XP，排斥XP，而绝不敢拿
XP做为上方宝剑的。

谢谢 AiWangji(爱忘记) 
其实重构就是设计 
但是重构是这样的设计 它不添加什么 只是改变什么 
只有在你添加有困难的时候 才会重构 重构是对现有代码结构的改变 所以你才有可能keep it simple 和keep it stupid
而且由于refactoring的强大 可以对糟糕的设计做补救 关于AiWangji(爱忘记)说的第四条4）使用最少数量的类，及类的方法 我认为应该是最小的类 然后是最小的数量 和方法

我只是觉得，refactor不能成为糟糕设计的借口。
因为refactor还没有万能到，可以一般性地补救非常糟糕的设计。
否则，也就没有必要谈refactor啦。
只要，你设计出来，无论多糟糕，最后找个懂refactor的高手refactor一下就好了。

相反，我倒是觉得refactor更加强调设计，所以它才在开发的过程中反复地优化设计。也就是说：它强调的是在现有的对需求的理解范围内最优的设计。

非常赞成ajoo(聪明的一猪) 上面的这段话。
我认为简单设计其实就是最佳设计。不经过反复优化是绝对
得不到简单设计的。

简单设计不等于简单的设计过程。简练的、能够达到预先要求的设计才是优美的设计，但是要做到这一点并不容易，象这样的简单设计可能需要比较长的时间和经验才能做到，它是经过简单-复杂-简单的过程形成的，这样从字面上来说和keep it simple不太一样。

aiwangji,
我只是感觉你的话对我来说还是太空泛了。我希望能比较直观地理解一下xp.

首先补充一下。上面四条对简单设计的定义是，是Kent给出的，并不是
我写的。

  据我的经验，要得到简单的设计，就是在脑子里时时提醒自己要保持
设计的简单（keep it simple）。简单的设计虽然需要经过不断的优化
而来。但是时刻都应该是“现有的对需求的理解范围内最优的设计”，
而不必经过简单-复杂-简单的过程形成的。有时设计变复杂了，是因为
我们面对的问题域变复杂了，或者说我们对问题域的认识还不够清晰
造成的，而绝不应该是我们主动要求复杂的结果。其实这时我们更需要
提醒自己追求对问题的最简练，最明了的描述。

To ajoo(聪明的一猪):

   我不知道你的直观地理解是什么？要看我的实例吗？我过去介绍
过很多自己参加过的XP的实例的。要看具体的实施方法吗？XP的十二
条还不具体吗？

还有要看XP的详细资料，我前面已经给出了一个很好的网站，
http://www.iturls.com/SoftwareEngineering/SE_Agile.asp
那里罗列了许多有关XP的重要网站。

哎，我不是想偷了懒，让高手给俺深入浅出一下嘛。
生也有牙，而知也无牙呀！

相对于重量级的编程方法uml等而言，极限编程这个轻量级的方法，在很多人看来还很新，那么它在中国的发展趋势如何，是否具发展的前景？有多少企业需要这种方法？这种方法适合中国的哪些企业？……请各位发表意见。我在正在做这方面的调查，请求支援，下边是为大家提供的一些参考资料：
http://www.agilechina.org/extremeprogramming/index.html
http://www.agilechina.org/
http://www.csdn.net/subject/125/
人民邮电出版社极限编程系列图书可以参看以下网址
http://www.ptpress.com.cn/books/Book_Series.asp?CID=380

popsea(前程百汇) 
不知道你要做什么调查 
“相对于重量级的编程方法uml等而言” 只是错误的 UML是一种语言 不是方法 xp也会使用uml 
你应该去www.chinaxp.org看看

希望都能敏捷
但现实很不一样，
没有深入的理解业务
不能做出很好的东西，
深入就要花时间

敏捷让你更容易深入