1,268
社区成员
发帖
与我相关
我的任务
分享敏捷宣言
很多人不知道敏捷是怎么回事 所以就把这个贴出来 你可以不同意 但是你不能不注意
敏捷软件开发宣言
我展示开发的更好途径
软件通过它实现并且帮助别人使用它
通过这项工作我们实现下列价值：
个体和交流优先于过程和工具
可以工作的软件优先于全面的文档
顾客的合作优先于契约的协商
面对变化优先于遵守计划
这些时在这个项目体现的直接价值，我们认为还有更多的价值。
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
敏捷的法则
我们重视通过尽早、连续的提供有价值的软件来满足顾客。
欢迎更改需求，即使是在开发的后期。敏捷过程为了顾客有竞争力的利益来管理这些变化。
经常性的发布可以工作的软件，从几个星期到几个月，我们偏爱短的时间周期。
在项目中业务人员和开发人员必须日常共同工作。
通过激发个体的努力完成计划。
给他们需要的环境，提供他们需要的支持，并且相信他们可以做好他们的工作。
最有效和最实际在开发团队内部传递知识的方法是面对面的交谈。
可以工作的软件是进度的主要度量指标。
敏捷过程促进持续的开发。
发起人，开发者，使用者能维持一个不确定的恒定的步调。
持续地注意技术优势和良好设计来提高灵活性。
简单--不使工作最大化的艺术--才是本质。
最好的架构、需求、和设计出现在有组织的团队中。
每隔一定时间，团队反省如何更加有效，然后调整他们的行为。
www.agilealliance.com
敏捷软件开发宣言
我展示开发的更好途径
软件通过它实现并且帮助别人使用它
通过这项工作我们实现下列价值：
个体和交流优先于过程和工具
可以工作的软件优先于全面的文档
顾客的合作优先于契约的协商
面对变化优先于遵守计划
这些时在这个项目体现的直接价值，我们认为还有更多的价值。
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
敏捷的法则
我们重视通过尽早、连续的提供有价值的软件来满足顾客。
欢迎更改需求，即使是在开发的后期。敏捷过程为了顾客有竞争力的利益来管理这些变化。
经常性的发布可以工作的软件，从几个星期到几个月，我们偏爱短的时间周期。
在项目中业务人员和开发人员必须日常共同工作。
通过激发个体的努力完成计划。
给他们需要的环境，提供他们需要的支持，并且相信他们可以做好他们的工作。
最有效和最实际在开发团队内部传递知识的方法是面对面的交谈。
可以工作的软件是进度的主要度量指标。
敏捷过程促进持续的开发。
发起人，开发者，使用者能维持一个不确定的恒定的步调。
持续地注意技术优势和良好设计来提高灵活性。
简单--不使工作最大化的艺术--才是本质。
最好的架构、需求、和设计出现在有组织的团队中。
每隔一定时间，团队反省如何更加有效，然后调整他们的行为。
www.agilealliance.com
...全文
请发表友善的回复…
发表回复
ozzzzzz 2002-09-29
- 打赏
- 举报
敏捷让你更容易深入
vvyjp 2002-09-29
- 打赏
- 举报
希望都能敏捷
但现实很不一样，
没有深入的理解业务
不能做出很好的东西，
深入就要花时间
但现实很不一样，
没有深入的理解业务
不能做出很好的东西，
深入就要花时间
popsea 2002-09-27
- 打赏
- 举报
相对于重量级的编程方法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
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
ajoo 2002-09-27
- 打赏
- 举报
哎，我不是想偷了懒，让高手给俺深入浅出一下嘛。
生也有牙，而知也无牙呀！
生也有牙，而知也无牙呀！
ozzzzzz 2002-09-27
- 打赏
- 举报
popsea(前程百汇)
不知道你要做什么调查
“相对于重量级的编程方法uml等而言” 只是错误的 UML是一种语言 不是方法 xp也会使用uml
你应该去www.chinaxp.org看看
不知道你要做什么调查
“相对于重量级的编程方法uml等而言” 只是错误的 UML是一种语言 不是方法 xp也会使用uml
你应该去www.chinaxp.org看看
AiWangji 2002-09-26
- 打赏
- 举报
非常赞成ajoo(聪明的一猪) 上面的这段话。
我认为简单设计其实就是最佳设计。不经过反复优化是绝对
得不到简单设计的。
我认为简单设计其实就是最佳设计。不经过反复优化是绝对
得不到简单设计的。
ajoo 2002-09-26
- 打赏
- 举报
我只是觉得，refactor不能成为糟糕设计的借口。
因为refactor还没有万能到，可以一般性地补救非常糟糕的设计。
否则，也就没有必要谈refactor啦。
只要，你设计出来，无论多糟糕，最后找个懂refactor的高手refactor一下就好了。
相反，我倒是觉得refactor更加强调设计，所以它才在开发的过程中反复地优化设计。也就是说：它强调的是在现有的对需求的理解范围内最优的设计。
因为refactor还没有万能到，可以一般性地补救非常糟糕的设计。
否则，也就没有必要谈refactor啦。
只要，你设计出来，无论多糟糕，最后找个懂refactor的高手refactor一下就好了。
相反，我倒是觉得refactor更加强调设计，所以它才在开发的过程中反复地优化设计。也就是说：它强调的是在现有的对需求的理解范围内最优的设计。
ozzzzzz 2002-09-26
- 打赏
- 举报
谢谢 AiWangji(爱忘记)
其实重构就是设计
但是重构是这样的设计 它不添加什么 只是改变什么
只有在你添加有困难的时候 才会重构 重构是对现有代码结构的改变 所以你才有可能keep it simple 和keep it stupid
而且由于refactoring的强大 可以对糟糕的设计做补救 关于AiWangji(爱忘记)说的第四条4）使用最少数量的类，及类的方法 我认为应该是最小的类 然后是最小的数量 和方法
其实重构就是设计
但是重构是这样的设计 它不添加什么 只是改变什么
只有在你添加有困难的时候 才会重构 重构是对现有代码结构的改变 所以你才有可能keep it simple 和keep it stupid
而且由于refactoring的强大 可以对糟糕的设计做补救 关于AiWangji(爱忘记)说的第四条4）使用最少数量的类，及类的方法 我认为应该是最小的类 然后是最小的数量 和方法
AiWangji 2002-09-26
- 打赏
- 举报
to ajoo(聪明的一猪):
我来替 ozzzzzz(希望敏捷) 来回答一下你的问题，你不介意吧。
问：“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”
心态设计开发，再用自动测试工具武装起来？”
不知你读过我前面写的帖没有。是不是我还没有表达清楚呢，那个帖
的主题就是软件的本质是对世界的认知，而认知必然是一个循序渐进
的过程；需要实践不断验证的过程。也就是说，敏捷方法是由于我们
提高了对软件的认识后，必然会产生的符合软件开发这一对现实世界
认知过程的方法。而决不仅仅是几个程序员的一时心态。
请注意：Ivar Jacobson 这一次到中国来的演讲主题已经是“面向对象
的软件工程”了。可以这样讲真正了解面向对象的人，都已经认识到
面向对象的软件工程不可能沿用传统的软件工程方法了。
问：“感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？
OO的最小接口原则本身似乎就和xp的宗旨不谋而合。”
对，可以讲XP方法就是为面向对象而诞生的。我想如果你真的实施过
XP方法的话，你还为发现，用XP方法做发面向对象，是再和谐不过了。
而你讲的“不断求精，逐渐更改设计”，真是你自己不自觉地在使用
敏捷了，这恰恰说明了敏捷的重要，你离不开敏捷。而它并不是传统
软件工程方法所提倡的。请不要混淆。
问：“一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？
可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生
不老药。”
敏捷确实赞成重构，但是它还有一个最主要的前提就是：简单设计。
XP方法要求任何时刻的设计都应该是简单设计，而简单的设计是指满足
下列四个条件的设计。
1）通过所有测试。
2）呈现所有的设计意图。
3）避免一切重复。
4）使用最少数量的类，及类的方法。
请问能时刻满足这种要求的简单设计会成为“一些不懂设计的人”的
上方宝剑吗？我看你是多虑了。相反，XP方法完全是一种以人为本
的方法论，它以人性化的方法逼迫你必需不断学习，对设计精益求精。
所以任何不了解对面向方法的人，不懂得什么才是重构的人，在XP方法
下，都是没有立足之地的。这些人只会恐惧XP，排斥XP，而绝不敢拿
XP做为上方宝剑的。
我来替 ozzzzzz(希望敏捷) 来回答一下你的问题，你不介意吧。
问：“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”
心态设计开发，再用自动测试工具武装起来？”
不知你读过我前面写的帖没有。是不是我还没有表达清楚呢，那个帖
的主题就是软件的本质是对世界的认知，而认知必然是一个循序渐进
的过程；需要实践不断验证的过程。也就是说，敏捷方法是由于我们
提高了对软件的认识后，必然会产生的符合软件开发这一对现实世界
认知过程的方法。而决不仅仅是几个程序员的一时心态。
请注意：Ivar Jacobson 这一次到中国来的演讲主题已经是“面向对象
的软件工程”了。可以这样讲真正了解面向对象的人，都已经认识到
面向对象的软件工程不可能沿用传统的软件工程方法了。
问：“感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？
OO的最小接口原则本身似乎就和xp的宗旨不谋而合。”
对，可以讲XP方法就是为面向对象而诞生的。我想如果你真的实施过
XP方法的话，你还为发现，用XP方法做发面向对象，是再和谐不过了。
而你讲的“不断求精，逐渐更改设计”，真是你自己不自觉地在使用
敏捷了，这恰恰说明了敏捷的重要，你离不开敏捷。而它并不是传统
软件工程方法所提倡的。请不要混淆。
问：“一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？
可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生
不老药。”
敏捷确实赞成重构，但是它还有一个最主要的前提就是：简单设计。
XP方法要求任何时刻的设计都应该是简单设计，而简单的设计是指满足
下列四个条件的设计。
1）通过所有测试。
2）呈现所有的设计意图。
3）避免一切重复。
4）使用最少数量的类，及类的方法。
请问能时刻满足这种要求的简单设计会成为“一些不懂设计的人”的
上方宝剑吗？我看你是多虑了。相反，XP方法完全是一种以人为本
的方法论，它以人性化的方法逼迫你必需不断学习，对设计精益求精。
所以任何不了解对面向方法的人，不懂得什么才是重构的人，在XP方法
下，都是没有立足之地的。这些人只会恐惧XP，排斥XP，而绝不敢拿
XP做为上方宝剑的。
AiWangji 2002-09-26
- 打赏
- 举报
to ajoo(聪明的一猪):
我来替 ozzzzzz(希望敏捷) 来回答一下你的问题，你不介意吧。
问：“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”
心态设计开发，再用自动测试工具武装起来？”
不知你读过我前面写的帖没有。是不是我还没有表达清楚呢，那个帖
的主题就是软件的本质是对世界的认知，而认知必然是一个循序渐进
的过程；需要实践不断验证的过程。也就是说，敏捷方法是由于我们
提高了对软件的认识后，必然会产生的符合软件开发这一对现实世界
认知过程的方法。而决不仅仅是几个程序员的一时心态。
请注意：Ivar Jacobson 这一次到中国来的演讲主题已经是“面向对象
的软件工程”了。可以这样讲真正了解面向对象的人，都已经认识到
面向对象的软件工程不可能沿用传统的软件工程方法了。
问：“感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？
OO的最小接口原则本身似乎就和xp的宗旨不谋而合。”
对，可以讲XP方法就是为面向对象而诞生的。我想如果你真的实施过
XP方法的话，你还为发现，用XP方法做发面向对象，是再和谐不过了。
而你讲的“不断求精，逐渐更改设计”，真是你自己不自觉地在使用
敏捷了，这恰恰说明了敏捷的重要，你离不开敏捷。而它并不是传统
软件工程方法所提倡的。请不要混淆。
问：“一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？
可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生
不老药。”
敏捷确实赞成重构，但是它还有一个最主要的前提就是：简单设计。
XP方法要求任何时刻的设计都应该是简单设计，而简单的设计是指满足
下列四个条件的设计。
1）通过所有测试。
2）呈现所有的设计意图。
3）避免一切重复。
4）使用最少数量的类，及类的方法。
请问能时刻满足这种要求的简单设计会成为“一些不懂设计的人”的
上方宝剑吗？我看你是多虑了。相反，XP方法完全是一种以人为本
的方法论，它以人性化的方法逼迫你必需不断学习，对设计精益求精。
所以任何不了解对面向方法的人，不懂得什么才是重构的人，在XP方法
下，都是没有立足之地的。这些人只会恐惧XP，排斥XP，而绝不敢拿
XP做为上方宝剑的。
我来替 ozzzzzz(希望敏捷) 来回答一下你的问题，你不介意吧。
问：“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”
心态设计开发，再用自动测试工具武装起来？”
不知你读过我前面写的帖没有。是不是我还没有表达清楚呢，那个帖
的主题就是软件的本质是对世界的认知，而认知必然是一个循序渐进
的过程；需要实践不断验证的过程。也就是说，敏捷方法是由于我们
提高了对软件的认识后，必然会产生的符合软件开发这一对现实世界
认知过程的方法。而决不仅仅是几个程序员的一时心态。
请注意：Ivar Jacobson 这一次到中国来的演讲主题已经是“面向对象
的软件工程”了。可以这样讲真正了解面向对象的人，都已经认识到
面向对象的软件工程不可能沿用传统的软件工程方法了。
问：“感觉你自己正常设计程序，不也是不断求精，逐渐更改设计吗？
OO的最小接口原则本身似乎就和xp的宗旨不谋而合。”
对，可以讲XP方法就是为面向对象而诞生的。我想如果你真的实施过
XP方法的话，你还为发现，用XP方法做发面向对象，是再和谐不过了。
而你讲的“不断求精，逐渐更改设计”，真是你自己不自觉地在使用
敏捷了，这恰恰说明了敏捷的重要，你离不开敏捷。而它并不是传统
软件工程方法所提倡的。请不要混淆。
问：“一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？
可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生
不老药。”
敏捷确实赞成重构，但是它还有一个最主要的前提就是：简单设计。
XP方法要求任何时刻的设计都应该是简单设计，而简单的设计是指满足
下列四个条件的设计。
1）通过所有测试。
2）呈现所有的设计意图。
3）避免一切重复。
4）使用最少数量的类，及类的方法。
请问能时刻满足这种要求的简单设计会成为“一些不懂设计的人”的
上方宝剑吗？我看你是多虑了。相反，XP方法完全是一种以人为本
的方法论，它以人性化的方法逼迫你必需不断学习，对设计精益求精。
所以任何不了解对面向方法的人，不懂得什么才是重构的人，在XP方法
下，都是没有立足之地的。这些人只会恐惧XP，排斥XP，而绝不敢拿
XP做为上方宝剑的。
ozzzzzz 2002-09-26
- 打赏
- 举报
ajoo(聪明的一猪)
看来你对REFACTORING没有什么了解 建议你注意最近的出版动态
keep it simple和keep it stupid的关系是一个问题的两个方面
XP设计的方法是这样的在开始的时候采取最方便的方法实现 然后是在添加前看你的设计是否可以很合适添加（看看味道好不好） 然后如果有必要就重构
重构之后才添加 重构不添加任何东西 添加就不出够
看来你对REFACTORING没有什么了解 建议你注意最近的出版动态
keep it simple和keep it stupid的关系是一个问题的两个方面
XP设计的方法是这样的在开始的时候采取最方便的方法实现 然后是在添加前看你的设计是否可以很合适添加（看看味道好不好） 然后如果有必要就重构
重构之后才添加 重构不添加任何东西 添加就不出够
ajoo 2002-09-26
- 打赏
- 举报
门口卖菜的也可能听过重构这个词的。就象有谁不知道OO呢？又有多少人真正懂得OO呢？
我的意思是，要重构，也应该有一个至少是有弹性的初始结构。否则重构也是会有很大难度的。举个例子，就象某人写了个类，放了若干个不该放的方法，公开了很多不该公开的实现细节，甚至包括一些共有变量。
那么，如果这个类已经被广泛使用了，重构的难度就很大。
所以，keep it simple我是同意的。但keep it stupid我就不同意了。至少这个"stupid"不是可以随便瞎写的代名词。接口和封装一定是要从开始就注重的。你可以很方便的加东西，但一旦一个东西发布出去了，再想删改，不是那么容易的事。
我的意思是，要重构，也应该有一个至少是有弹性的初始结构。否则重构也是会有很大难度的。举个例子，就象某人写了个类，放了若干个不该放的方法，公开了很多不该公开的实现细节，甚至包括一些共有变量。
那么，如果这个类已经被广泛使用了，重构的难度就很大。
所以，keep it simple我是同意的。但keep it stupid我就不同意了。至少这个"stupid"不是可以随便瞎写的代名词。接口和封装一定是要从开始就注重的。你可以很方便的加东西，但一旦一个东西发布出去了，再想删改，不是那么容易的事。
ksyou 2002-09-26
- 打赏
- 举报
xuexi
ozzzzzz 2002-09-26
- 打赏
- 举报
ajoo(聪明的一猪)
XP是商业环境变化的结果
===一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生不老药。？？？？？？？？
不太明白你的意思 我想你可能不理解重构 重构就是设计阿 而且现在重构是OO下得到验证的最好设计方法阿 如果不懂设计 怎么可能知道重构呢
XP是商业环境变化的结果
===一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生不老药。？？？？？？？？
不太明白你的意思 我想你可能不理解重构 重构就是设计阿 而且现在重构是OO下得到验证的最好设计方法阿 如果不懂设计 怎么可能知道重构呢
ajoo 2002-09-26
- 打赏
- 举报
ozzzzzz兄，能否对我的认识，做一下批评？
“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”心态设计开发，再用自动测试工具武装起来？”
这就是我目前对xp得全盘认识了。
再有，就是加上，一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生不老药。
“xp方法是否就是一两个有经验的程序员抱着“一口吃不了个胖子的”心态设计开发，再用自动测试工具武装起来？”
这就是我目前对xp得全盘认识了。
再有，就是加上，一些不懂设计的人拿到了上方宝剑，可以说：“我这个设计不好？可以以后refactor嘛”。好像，一有了refactoring, 就找到了长生不老药。
AiWangji 2002-09-26
- 打赏
- 举报
还有要看XP的详细资料，我前面已经给出了一个很好的网站，
http://www.iturls.com/SoftwareEngineering/SE_Agile.asp
那里罗列了许多有关XP的重要网站。
http://www.iturls.com/SoftwareEngineering/SE_Agile.asp
那里罗列了许多有关XP的重要网站。
AiWangji 2002-09-26
- 打赏
- 举报
To ajoo(聪明的一猪):
我不知道你的直观地理解是什么？要看我的实例吗？我过去介绍
过很多自己参加过的XP的实例的。要看具体的实施方法吗？XP的十二
条还不具体吗？
我不知道你的直观地理解是什么？要看我的实例吗？我过去介绍
过很多自己参加过的XP的实例的。要看具体的实施方法吗？XP的十二
条还不具体吗？
AiWangji 2002-09-26
- 打赏
- 举报
首先补充一下。上面四条对简单设计的定义是，是Kent给出的，并不是
我写的。
据我的经验，要得到简单的设计，就是在脑子里时时提醒自己要保持
设计的简单（keep it simple）。简单的设计虽然需要经过不断的优化
而来。但是时刻都应该是“现有的对需求的理解范围内最优的设计”，
而不必经过简单-复杂-简单的过程形成的。有时设计变复杂了，是因为
我们面对的问题域变复杂了，或者说我们对问题域的认识还不够清晰
造成的，而绝不应该是我们主动要求复杂的结果。其实这时我们更需要
提醒自己追求对问题的最简练，最明了的描述。
我写的。
据我的经验，要得到简单的设计，就是在脑子里时时提醒自己要保持
设计的简单（keep it simple）。简单的设计虽然需要经过不断的优化
而来。但是时刻都应该是“现有的对需求的理解范围内最优的设计”，
而不必经过简单-复杂-简单的过程形成的。有时设计变复杂了，是因为
我们面对的问题域变复杂了，或者说我们对问题域的认识还不够清晰
造成的，而绝不应该是我们主动要求复杂的结果。其实这时我们更需要
提醒自己追求对问题的最简练，最明了的描述。
ajoo 2002-09-26
- 打赏
- 举报
aiwangji,
我只是感觉你的话对我来说还是太空泛了。我希望能比较直观地理解一下xp.
我只是感觉你的话对我来说还是太空泛了。我希望能比较直观地理解一下xp.
mach 2002-09-26
- 打赏
- 举报
简单设计不等于简单的设计过程。简练的、能够达到预先要求的设计才是优美的设计，但是要做到这一点并不容易，象这样的简单设计可能需要比较长的时间和经验才能做到，它是经过简单-复杂-简单的过程形成的，这样从字面上来说和keep it simple不太一样。
加载更多回复（27）
