敏捷画卷：中国软件史的精彩侧影

如果把软件开发当成一个谜题，那么数代软件人在过去的50年里都在前赴后继地尝试解决这个谜题。迄今为止，全世界不管是码农还是码神，仍在这个谜题中痛苦挣扎。

从1965年到1985年，软件危机逐步浮现，这让刚刚进入科学管理时代的人们极其不爽，1931年建成的帝国大厦只用了410天，还是提前完工，写个软件还能比盖摩天楼更复杂？那肯定是方法有问题。供职于洛克希德软件技术中心的Winston W. Royce，在其1970年的论文“Managing the Development of Large Software Systems”中提出了一个长得像瀑布的流程。业界似乎找到了一剂灵丹妙药，虽然这位研究了多年航天器的Royce博士并没有在他的文章中提到任何有关瀑布的字眼。之后，以1988年CMM的发布为重大里程碑，剩下的似乎就是沿着既定的路线：细化，标准化，量化，优化，再优化……直到在一线干活的人们发现事情并非如此，于是生长出了各家敏捷流派，以期解决Fred Brooks在“No Silver Bullet”（没有银弹）一文里提出的复杂性（complexity）、配合性（conformity）、隐蔽性（invisibility）、易变性（changeability）这些现代软件开发中本质性（essence）的难度。

中国用20年的时间迈过了西方50年的软件工程发展史。本书通过一个个鲜活的故事和严谨的考证，绘制了一幅敏捷方法在中国软件产业的土壤中生根、发芽、传播的画卷，构成了中国软件史一个精彩的侧影，不仅帮读者在宏观层面厘清了中国软件工程领域在过去20年里发展的关键脉络，更让读者透过一系列从业者的经历从个体视角体验历史，了解众多普通的软件人参与和创造历史的过程。我个人的从业经历跟这本书的跨度大致重叠，因此格外有感触。拿着这份书稿，本以为早就遗忘的画面在脑海之中一页页闪过。

我还记得2001年在新加坡的一个社区图书馆，第一次翻开Kent Beck的Extreme Programming Explained给我带来的冲击。不过一番琢磨之后，我得出了几个轻率的结论：迭代开发玩不转，甲方的预算和立项流程根本不可能让乙方这么干（我当时在新加坡的一个系统集成商工作）；结对编程太奢侈，没有老板会让团队这么干；测试驱动开发（Test-Driven Development，TDD）真是好东西，不过只要团队里有一个人不这么干，其他人也干不下去，让所有人都用TDD不现实。所谓纸上得来终觉浅，直到四年之后，我自己卷起袖子，在全面采用敏捷实践的团队中沉浸工作了几个月，才真正体会了那些理念和实践的价值和可操作性。让我很有共鸣的是，书中不少人和公司初步接触敏捷的经历和感受其实也很类似。

看到敏捷中国大会的举办，大型通信企业的敏捷转型，DevOps、设计思维、精益企业、精益创新的推广，ThoughtWorks相关的记述唤醒了我的记忆。那些熟悉的名字把他们的面容带回我的眼前，与他们合作过程中所体验到的酸甜苦辣又从心中流过。虽然是书中很多事件的亲历者，我看到的也只是点点滴滴，从没想到有人能如此全局又生动地把握和呈现当时的脉动。

说到合作，我2007年加入ThoughtWorks，那是我真正认识熊节的开始，不过我知道熊节却要更早一些。那时经常在JavaEye上津津有味地旁观一个叫熊节的人跟人吵架，觉得这人吵得很有见解，而且吵得很有文笔。于是，我有了无数的机会在现场和邮件里看熊节怼人，以及被熊节怼，从中学到很多。

为什么专门把怼人拿出来说？这其实跟ThoughtWorks的风格有关。不满足于现状，寻求更好的理念、方法和工具，追求软件卓越，这是ThoughtWorks的使命。ThoughtWorks期望员工不盲从主流意见，要持怀疑挑战的态度，以求找到不一样的路径，做到比当前更好。熊节就是这种风格的典型代表。

20年中国软件工程方法的变迁过程也是中国软件行业追赶国际先进水平的历史过程。巨大的国内市场已经让我们成为一个软件大国，但我们在工程方法领域并没能够取得匹配的领先地位。我理解这本书不仅仅是对历史的记录和纪念，更是要我们以史为鉴。正是书中一个个致力于改善工作成效的一线从业者和致力于推广新方法新工具的布道者，吸引了一批又一批热衷于软件开发的人加入进来，一起推动行业的发展。

张松

ThoughtWorks中国区总经理