听人谈了一些对于这本书的看法，感觉不是很同意他所欣赏并转述的书的内容。所以昨天去书店站着看了大半本，觉得他的转述和对书的理解都没错，也就是说我的确不是很同意书中的观点。
书读着令人激动，但是感觉作者过于理想化了开发的情况。
项目开发的著作，我以为分两类。一类是着重考察项目过程本身，一类是主要考察项目的参与者。前者我以为如《人月》，后者如《最后期限》（我想《人件》应该也是的）。一本好的作品应该是承认实际环境中的种种局限，并在实际局限的基础上考虑合适的策略。但是《自适应》似乎更加象一本市面上很多的励志读物，拿来鼓励一下自己可以，不能全当得真。特别是在你开发的是一个大型应用而不是产品的时候。
系统指出我的看法有些难。摘录一些观点供大家参考。
一是强调小组成员要保持高度积极的开放心态去适应变化。我觉得大前提没有错。但是长时间的激烈变化的确是耗散小组成员斗志的最佳方式。《期限》中说：压力之下人无法很好思考。激烈的变化的确是产生压力的好途径。我不能期望我的小组成员人人在6个月以上的开发过程中一直保持这种心态，我自己首先做不到。这是大多数项目组的现实。
二是觉得客户的需求最终会是收敛的，因此总有苦尽甘来的日子。我也以为不妥。我相信很多人经历过客户需求的变化，很多不是很有理性的，甚至有很多是颠来倒去的。有很多修改在程序员看来（包括事后证明）是没有意义的，但是在客户业务人员当时看来是很重要的，小组只能屈从。这也是小组士气的杀手。
三是关于企业转型，作者以为很简单，老总用纸笔一画就万事OK。我正惊异于如何做到，作者举了MS的例子。这就没话说了，MS有几个人是能够学的？sun，hp，dell等都学不来呢。作者接着提到了微软能这样做的理由，比如成熟的价值观和卓越的领导人。可见这和所谓的自适应方法关系不大。业界有句名言：问500磅重的猩猩在哪里睡觉？答案是：想在哪里就在哪里。行业领跑者想怎么干都是可以的。至于说到学习成功者是我们成功的捷径，这个题目就更大了，有兴趣的人另外讨论。
四是强调用这种方法开发出的小规模产品能先投入使用，产生效益。这种方法有一定可行性，我做的数据分析项目也是类似做法。但是总体而言我基本不同意，特别是从我做过的大型业务系统而言，决不可行。问题不是开发组能不能做到，而是对于这样的用户，召集一次业务人员进行培训和推广都是很耗费人力物力的。新软件的推广毕竟不是买个台灯来用。业务软件的推广往往意味着业务的重新整合，风险非常大（连《期限》的作者也只敢举产品的例子），这个是不能很多次折腾的。
五是有点忽略政治的作用。这个问题比较大，但是我觉得大项目的开发肯定是要考虑的。上面的第三和第四点也都和政治有一定的关系。《期限》中的贝洛克部长就是政治影响开发的代表，现实中这样的压力会来自自己的领导和客户的领导。小说中该人物被解决了，但是实际项目中就说不清了。《期限》的作者也说了：奇迹会出现的，但是不要抱太大希望（大意如此）。
还有不少，先罗列这些吧。总的感觉是作者有点理想化，相比之下，《人月》《期限》的作者就现实得多。有兴趣的人可以对照着看这些作品。
我一直有这样的观点：不用面对最终用户的程序员是最幸福的，就象出国的人回来说：还是社会主义的祖国好啊。我的感觉么，作者似乎是一个没有面对过应用项目折磨的人。
有个疑惑：作者区分了螺旋式开发和所谓的自适应开发，我好像看不出有很大的区别。对此有人有深入的看法么？
顺便提一下：作者是个咨询顾问的经验胜过作为实际的项目管理者，而且成书于疯狂的1999年。当然这都不是判断书的内容如何的论据，只不过我在确定了自己的看法后的一点联想罢了。呵呵
个人一点浅见，方家见笑了。这书我不准备买，我等待《人件》。
