评论

#Justin Shen 发表于2005-01-21 12:50:00  IP: 221.137.114.*

说一些我个人的看法。XP所要拥抱的变化，不光是需求变化。

开发一个大的项目，即使需求明确且不发生变化，仍然需要多次迭代开发，每次进入新的迭代时，加入新的功能(即使是已经很早就明确了的需求)，很可能会导致现有软件构架的改变。这就需要我们找到一个可行的办法来应付这种变化。重构、测试先行、每日构建都是为此而设。

当然如果你说你可以在开始开发前就完全想清楚整个软件的设计结构，并且保证不出纰漏，做到一经设计无须更改，那么或许可以不用面对任何变化，只要单纯的把设计转为代码就可以了。但这在我看来多少有点不现实。

#firingme 发表于2005-01-21 21:28:00  IP: 219.129.60.*

把国内的大牛们召集到一起还是有可能的。可是大牛太少，又天南地北，呵呵……金山他们做的事情不就是原封不动抄Word么？金山的条件和myan设想的也差不多，结果还是抄不出Word的水平，就这样了。

#小四 发表于2005-01-22 12:10:00  IP: 218.88.164.*

变更是客观，拥不拥抱是主观！

#johnkuang 发表于2005-01-22 18:23:00  IP: 218.80.194.*

我觉得马斯洛的“需求层次理论”可以用来解决您的疑问。他的理论认为人的需求可以分为五类：生理需求、安全需求、社交需求、尊重需求和自我实现需求。并且有这样一些假设：

　　* 已经满足的需求，不再是激励因素。人们总是在力图满足某种需求，一旦一种需求得到满足，就会有另一种需要取而代之。
　　* 大多数人的需要结构很复杂，无论何时都有许多需求影响行为。
　　* 一般来说，只有在较低层次的需求得到满足之后，较高层次的需求才会有足够的活力驱动行为。
　　* 满足较高层次需求的途径多于满足较低层次需求的途径。

可以认为软件的实现也是一个满足需求的过程，有几层需求：1。能跑起来2。跑的很稳3。很优雅4。到山上也能跑。。。。我是瞎说的，但绝对存在这样一个需求层次结构。如果用上面第三点就可以解释为什么XP在中国应该不一样。

#外行 发表于2005-01-22 14:04:00  IP: 222.33.96.*

呵呵呵，俺觉得严重需要这类思考。

#anonymous 发表于2005-01-23 13:21:00  IP: 211.80.44.*

你的文章也不按类别组织一下
看得真累

#ralph623 发表于2005-01-25 09:22:00  IP: 211.72.108.*

在比较大的软件项目里面，需求不变化是不太可能的。毕竟软件开发的终极目的是解决用户的问题，而实际问题本身就具有复杂性和变化性。所以我觉得对于变化，还是应该有欢迎的态度。当然如果对于需求的变化没有有效的管理，又会造成整个流程的混乱，反而不利于解决用户的问题。

我们对于用户的需求变化是用sign-off的contract来管理，如果一份需求已经sign-off了，对于其的变更就要通过用户和实施方重新开会来达成一致。

其实需求的管理往往是对于项目经理的一个性格考验。我记得很清楚，我们的一位项目经理说过，她以前在普华的时候，对于用户的需求变化一律接受，但是这样往往造成手下团队的不满；而到了现在的公司，对于用户的需求变化很谨慎，然而这样又有降低用户满意度的风险。要知道这两样都是决定一个项目经理工作成败的关键因素，这之间的权衡恐怕更多的是一种艺术和外交手腕的结合。

#最爱 发表于2005-01-26 13:51:00  IP: 60.164.15.*

最爱看孟编的文章了！！不管是什么，总能给人些思考！！

#无人能懂 发表于2005-01-26 16:08:00  IP: 218.80.198.*

垃圾

#anonymous 发表于2005-01-28 18:09:00  IP: 218.189.200.*

http://www.dearbook.com.cn/book/viewbook.aspx?pno=TS0028348

#anonymous 发表于2005-01-28 18:10:00  IP: 218.189.200.*

http://www.dearbook.com.cn/book/viewbook.aspx?pno=TS0028348

#dengyl 发表于2005-01-31 13:29:00  IP: 221.232.245.*

我蛮同意Justin Shen的话，变更不仅仅来自客户，也来自自己。拥抱它，在编码过程中，让代码不断的修正设计。通过重构和单元测试，让代码来告诉我们一个比较合适的设计方案。也避免了过渡设计。当然，在孟岩兄面前讲这番话，我真觉得是班门弄斧了。呵呵，Bob大叔还是经你介绍，才认识的。

#westxx 发表于2005-04-08 22:57:00  IP: 222.43.34.*

以前还以为不能在初期把什么东西都规划好是我水平太差，原来大虾们也做不到，看来书本上讲那套软件工程理论是有些过时了，还得多多实践才是硬道理，呵呵

#宋强 发表于2005-06-14 16:44:00  IP: 61.186.252.*

我觉得其实xp是一个方法论，其实他是进行项目管理、架构设计的一种工作方法。
中国的软件开发除了方法论欠缺，当然也欠缺其他方面，其中有模型设计、架构设计这些硬指标，目前不是改善一个方面就能改善我们的软件开发质量，必须齐头并进。老美的产品设计、风险评估、测试相对来说都比较完善，而且纪律很严明，但我们大部分还是作坊，因此不行。

#清风雨 发表于2005-06-24 12:30:00  IP: 61.186.252.*

宋强兄有道理。很少听到于我心的声音了。 每次都是被鄙视，唉！可怜啊！....... ：}

#corner 发表于2005-07-03 23:56:00  IP: 61.186.252.*

我没有看过，myan说的那本书，不过个人觉得，作这样的尝试还是值得的。
以我的看法是：一种方法总是难逃在特定环境下的定制，这是为了应对“亚文化群体”，此时此刻，“方法”就不得不有所退让，以此换得效率。所以，需求是应人的行为而变化，因此需要具有较大变更包容度的初期设计，同时需要明确的结构划分，以便并行开发，更需要进度的及时反馈。这意味着每个个体要互相学习、沟通。接下来就看是否有足够的“集体智慧”来预期、包容变化了。