写于2016.10.07，整理于2018.03.17。

1. 读书太少而想得太多

杨绛先生说，你的问题是读书太少而想得太多。我喜欢读书，但不知道自己读得是否有效。

1.1 互相冲突的观点

发现书读得越多，互相冲突的观点也会越多，这个时候免不了也想得更多。有时候想多了没结果就把它丢在一边，时间一长，再拿起这本书时会感觉这本书好像从来没读过似的。所以，不动笔就不读书，于我来说是绝对正确和有意义的一个戒条。
D曾经说我是一个吸收型的人，意思是说我只吸收书本的知识，但是不会把它们表达出来。其实我知道那是因为我并没有完全吸收，或者说吸收了之后对这个观点并不确信它是对的还是错的，所以并不敢当众表达出来。相比几年前或是十几年前，我只看了很少的书，因为是C象限的人（一个性格测评的结果，C象限的人被认为比较容易认同别人的观点，适合做教师、社会工作者等），看到一些观点就会认为是真理，因此手之舞之，足之蹈之，并迫不及待的想要和更多的人分享，这时会让人误以为我很博学，认为我高大上，因此我的观点能够获得一部分人的认同。当然，对于一些读书比我多的人，我想他们可能很明确的知道我的观点中的错误和漏洞，但可能是不屑，也可能是因为对自己的观点也并不是那么的确定，所以不会明确的指出；或者只是点出一下，但不会多加争辩。

1.2 错了又何妨？

想起刚工作的那一年，从Delphi开发转到C开发时积累了一点点经验，就写了一个经验总结文档和大家分享，其实有一些经验是明显错误的，比如把头文件包含的语句都集合到一个文件中，然后所有c文件都包含这个头文件。当时只是认为这样简单，不用在很多文件中写很多遍，维护起来方便，只要包含一个头文件就可以获得程序中所有的函数功能。但我后来才知道这是违反模块化最基本的信息隐藏原则的，增加了耦合性。

在我刚把分享文档放在公司论坛上时，就有人匿名指出文档中总结的经验是错的。我追问了一句是哪里错了求指教，没有得到任何反馈，也许是发帖人觉得我实在是太菜了，不值得继续讨论。可能是从那次我意识到自己的错误之后，就不再愿意和别人分享我自己的想法了，但我现在回过头想想，刚毕业时的我，知识和经验都很浅，但想学习和想分享的意愿很强烈，那时的我生活得很快乐；现在，我的知识和经验都有所增长，但对一些观点和看法却不是那么肯定了，也许就像前天看到的TED中的说法，内向的人会对任何事情都留有余地，不会那么绝对。也许我应该回归到刚毕业时的状态，找寻那失去已久的快乐，正如《如何做研究》中说的，学术的规律是要么发表，要么腐烂。如果我成为沉默的大多数，那就只能腐烂了。

2.《软件工程最佳实践》

最近看了Capers Jones的《软件工程最佳实践》，虽然还没有完全看完，但是他的观点我已经大致了解。

2.1 站在全行业的高度

Capers Jones站的立场是对整个软件工程行业的发展预测，希望通过对现有项目的大样本的对照分析，找到能够推动软件行业真正成为一个工程行业的最佳实践，毕竟，只有能够进行预测才能真正算是一个成熟的行业，这个起点比较高。

2.2 敏捷只是适合小项目的最佳实践？

Capers Jones从现有的数据中搜集对比，认为对于小型软件项目，敏捷方法是最佳实践，但对于大中型软件项目，更为正规化一些的PSP/TSP/UP等方法的效果更好。

2.3 数据积累和可预测性

因为敏捷方法认为所有不创造价值的工作都是应该省略的，所以对于积累数据和增强可预测性这件事情，敏捷社区兴致不高。但是对于CMMI这样正规的软件方法来说，度量是一个基础，如果没有度量数据，将无法把软件项目进行横向比较，也无法做有效的研究。从这个角度来说，Watts Humphrey, Capers Jones这些学者是本着科学研究的态度在做事情。因为敏捷方法缺少数据的积累，所以不能证实它的有效性，这里主要是指在中大规模项目中的有效性。注意：作者说的并不是它无效，而是说它的有效性没有确定的证据。

2.4 西医 vs. 中医

在敏捷和精益社区中，大家的关注点不是整个行业，而是自己的公司或者别的公司中一个具体项目的成败情况，社区中的人员关注的是我用自己坚信的一个方法来做项目，应该会取得很好的结果，前提是客户必须先充分相信。这和西医与中医的区别有点类似。
西医之所以是科学，是因为它可以证伪，有大量的实例数据可以用于帮助证实一种方法是有效还是无效，但西医无法治疗所有的疾病，或者说对于无法分解得很明白说清楚规律的事情，西医是无能为力的；中医没法做大样本随机双盲对照试验，因为中医是有整体观的，不能头痛医头脚痛医脚，同时中医也认为每个个体都是有差异的，对这一个个体有效果的治疗手段，对另一个个体未必能复制（Scrum中的团队产能计算，是基于每个团队的实际情况评估），但所有敏捷社区都信奉敏捷宣言，正如中医信仰阴阳五行，这是很可能找不到（或者说凭现在的认知水平和手段还找不到）科学依据的，或者很难有数据支撑。

敏捷的迭代方法，范围是不确定的，它的基本原则是要让团队做的工作产生价值，为客户产生价值，而价值又是最难评估的，所以如果应用敏捷方法，将会影响到和客户谈判验收条件，项目的范围界定等复杂问题。一个公司的所有部门都要按照敏捷的原则改造，比如财务制度不能采用年度预算制，因此才有了《精益企业》这本书的探讨。

传统的软件工程方法，项目成功的标志遵循项目管理理论，即满足范围、进度、成本等的约束条件就算是成功的（质量往往是被牺牲的）。这种方式传统、易理解、可度量、能预测，所以应该是会被大多数人接受的，正如西医的方式，医生会根据病情检查情况，大致给出治疗方案，并告知患者需要的治疗周期和花费情况。中医就完全不同，无法给出上述的建议，只能说每隔一段时间来复诊，根据望闻问切的情况调整下药方，不知道什么时候能够治好，也不知道要花多少钱。对于名医来说，患者在每次逐步感觉到病情好转，就会继续看下去，如果没发现明显好转，病人会中断治疗。所以能否治好，跟病人对医生的信任程度是严重相关的。虽然如此，因为中医往往能治好西医已经束手无策的案例，很多是疑难杂症，所以中医的受信任程度非常高。
治病犹如打仗，西医基于还原论，从外部增派援军打赢战争；而中医基于系统观和复杂理论，强调激活人体自身的潜能。

2.5 规模化扩展？

中医和西医一定会在很长一段时间并存下去，但不可预测以及高度依赖医生经验的现实决定了中医不大可能规模扩张，而西医却可以快速复制和推广，扩大规模，这也是为什么西医已经统治了医疗行业，而中医凭借其玄妙仍然存在着并且继续发扬光大，有很多的拥趸（我也是其中之一），如果用西医手段无法治好的病，我肯定会去求助中医，但常规的疾病，我可能还是会用西医的手段来处理。

3. 后记

对于软件行业来说，如果一个公司始终是挣扎在生存线上，那么它自然没有足够的动力去积累度量数据来为软件工程的成熟做贡献，因为对它并没有直接的好处，我想这也是为什么软件工程行业总是由IBM这样的大公司来推动的原因，因为它们的产品可以获得超额的利润，足以支撑这些额外的开支。《人月神话》的Brooks，《质量 管理 软件》的温伯格，《软件工程最佳实践》的琼斯，无一不是来自IBM。度量方法的基石：功能点方法，也是IBM发明的。但是这些方法似乎不是那么性感，很难引起技术人员的兴趣，因此它也不是那么流行，我想这应该是原因。其实真正行业内的大公司，如苹果、微软、google等，从来没听说它们倡导敏捷方法（虽然实际是按照敏捷的方式在做事情），它们只是把最基本的软件工程实践应用到极致，或者创建自己的理论或实践体系。