软件开发是一个发展很快的行业，作为一名程序员需要具备开放的心智，以应对不同的环境下不同的开发模式。提出有用的软件开发方法并不容易。困难不在于定义它们，而是说服别人遵循。本文作者从《人类简史：从动物到上帝》一书中透过现象看本质，解析初创团队到大规模团队的软件开发模式不同之处，分享其 20 年的软件开发经验。
智人和集体创作模式
最近我阅读了 Yuval Harari 的《人类简史：从动物到上帝》一书。这本书的基本论点是：人类需要“集体创作”，因此我们可以在多于 150 人的情况下进行合作，我们的大脑足以应付。集体创作针对那些无法在现实世界中看见和摸到的事物。诸如宗教、民族主义、自由民主或波普尔哲学。虽然这些事物不存在，但是当我们像他们一样行事时，我们很容易忘记他们并不存在。
IT 行业的集体创作模式
1. 瀑布模型
这促使我联想到当今一些关于软件工程领域的事情，它们困扰着我。20 年前当我投身软件行业时，瀑布模型占据统治地位。我加入了一个约 400 人的咨询公司，他们在着手项目之前会写很长的软件规格说明书，这些规格非常细致，精确到每一个 Java 类和属性。这些规范写好之后会提交给客户，但是有时候并不知道具体是谁和客户确定的需求并且书写了这些规范。之后开发人员就按照这个规范开始开发、交付，直至收到项目款项。然后皆大欢喜，其乐融融。
但是实际上大多数时候都会出现另一种情况：客户抱怨规范与交付不符，并且交付的产品往往与规范不一致，因为在项目进行的过程中，很多“事情”发生了变化。换句话说，瀑布模型是一个“集体小说”，给了我们足够的稳定性和一致性来合作，我们按照事先定好的规范把产品开发出来并得到报酬。
这个咨询公司在我加入后不久就倒闭了，无疾而终。
2. 初创公司的一段经历
之后我以第 39 号员工的身份加入了另一家软件公司，公司的开发工作量很大并且没有使用瀑布模型。事实上，公司内部根本没有任何的项目文档，需求和规范都是通过电话确认。设计、原型和产品开发很难区分。我感觉这样的情形混乱不堪，完全和我学到的软件工程理念相违背。但是没有更多时间思考应对方法，因为公司项目很多，开发任务繁重，这样的开发状态就这样一成不变地继续。
事实是，我们公司小到甚至不需要命名一个集体小说。项目需求和相关细节可以保留在我们的脑海里，如果你需要帮助直接在办公室喊一声就行。基调是这样的
当然，这是集体小说，我们只是没有为其命名：
- 我们永远不会有任务说明。
- 我们不需要人力资源或企业的沟通。
- 我们只雇用最好的员工。
随着我们公司规模的逐渐壮大，有客户开始询问我们的软件开发方法和规范。我肯定不能说我们的开发方法就是写代码。更不能告诉客户我们有现成的使用 C 语言开发的服务器程序，它运行速度很快，针对不同项目我只需花费一周左右对其做简单的调整即可完成开发工作。
事实上有一种叫做“快速应用程序开发”（RAD）的东西强调了原型设计。我们告诉客户我们做了RAD，他们似乎很高兴。听起来感觉我们很专业，但说实话，我不知道我们当中是否有人真正理解或者阅读过它。
作为“集体小说”模式它是有效果的，仿佛客户在监视我们的开发。
很快，我们公司的规模翻了一番，从狭窄的小办公室搬到了一个更大的场所，办公桌更加宽敞，楼层更多。因此你不能在办公室喊出你的问题了。团队变得更大，一些名为“项目经理”的人开始出现，他们谈论“规范”并且收集“需求”。我们试图从零开始重写整个平台，但是失败了。
是的，我们好像又回到了瀑布模型的开发模式，但是又有所不同，因为工作周期越来越短，但是因为客户不断变化的需求而产生的争议依然存在。到底是不是瀑布模型呢？我们也不太清楚。
3. 敏捷
我首次听到“敏捷”一词大概是在 2003 年。但是，实际上我并没有深入了解它。我对敏捷的了解源于网上的零散介绍，以及客户和敏捷拥护者谈论的只言片语。当我咨询那些声称自己对敏捷很了解的人时，不同人的解释和理解好像出入很大。实际上那些深谙敏捷模式的开发者在向非敏捷客户发布软件时依然充满压力。因此，我们继续依照传统的规格书进行软件开发，也会使用少量的敏捷术语。比如，会议被称为“scrum”，但是其他的情况却与之前的情形并无太大差异。
作为一个集体小说它是有效的，因为在我们编写软件时，它使我们保持和客户以及项目经理的沟通。
此后，我曾在一家拥有 700 人的公司工作，目前在一家拥有 10 万名员工的公司工作，但模式基本相同。
你不相信吗
我不会排斥这些开发模式，因为排斥是无意义的。即使软件开始模式不存在，也会有其他的模式被发明出来，因为我们需要借助这些模式进行有效地合作。有了这些开发模式才能扩大软件开发规模。敏捷模型对于员工流动性大的公司来说非常有用，并且这不是巧合。
《人类简史》一书中有许多有趣的论点，其中之一是：由于这些集体小说不能充分地解释世界，往往相互冲突，文化的有趣部分在于感受到这种紧张局势。幽默通常源于这些紧张局势。
“对于心智最高级的考验是能够同时持有两个相反的想法，仍然正常运转，互不干扰。” -- F. Scott Fitzgerald
当在一个小团队之外使用敏捷时，我不知道其他人是怎样，我个人反正是感觉非常紧张的。当一个我从未见过的并且对我的工作一无所知的人提议我删掉我的任务计划（这些任务是外部决定且没有商量余地的）时，我除了苦笑还能干嘛？
当你的控制权在每一个环节都有人否决时如何保持敏捷？基础设施、审计、安全、财务规划、财务结构都有助于快速提供有意义的产品迭代的能力。这里的客户是谁呢？我们很绝望：
当我看到这样的代表敏捷的图表时，我只能用我与同事分享的黑色幽默来回应：像在教堂后面咯咯笑的小孩。
在一个规模较小且运作良好的团队中，敏捷的理念会忽略，剩下的是（当它很好的时候）一个相互信任的团队、对自己的试验的开放、可以找到协议和解决方案的清晰的结构（正式或非正式）以及有效的合作。谷歌最近对其进行了阐述。
换种方式阐述
你可能会认为答案是提出一种更好的新方法，而不是像我们曾经尝试过的：
