软件开发应该以史为鉴，还是从头再来？

作家和顾问温伯格（ Gerald M. Weinberg ）已在计算机行业活跃了半个多世纪，作为一些最具影响力书籍的作者，他在业内广为人知，备受尊敬。

最近，他在自己的博客“顾问的秘密（Secrets of Consulting）”上发表文章，指出大家对历史的漠不关心，创新和进步被炒作周期所包围，似乎大家都在重复以往，没有组织和个人从前一个周期中吸取教训。

他正在将之前写的书《系统分析与设计的反思（Rethinking Systems Analysis and Design）》重排为电子版格式，并打算对写于 20 年前的一个章节进行修改，原标题为“超越结构化编程（Beyond Structured Programming）”。结果发现，只要将短语“结构化编程”替换为“敏捷”，这章内容就会针对到时下的“敏捷编程革命”上来。

他说：

虽然这是写给上一辈人看的文章，如今经过两代人了，而且对多数程序员来说，“敏捷编程革命”也已经是明日黄花，但这文章所说的仍然适用——即使对于下一波和再下一波反思风潮，也仍然适用。我相信它在版本停止更新很长时间以后，还能有现实意义。为什么？因为我们这个行业耐不住寂寞，每十年就要闹一轮新风潮。所以，你读这篇文章的时候，也别管圈内里正充斥着哪些风潮，只要沿用同样的教训就好了。

接下来他谈到，很多公司将实践创新做为口号，实际做起来，要么是盲目套用了条条框框，要么是只重简单实践，而并未贯彻有效变革所需的原则。

他说，如果详加考察所谓的敏捷应用：

1. 5% 可认为彻底达成敏捷。
2. 20% 可认为充分遵循了敏捷实践，相对于 1990 年的平均水平，有了明显改进。
3. 50% 能部分证明是多少尝试用到了一些“敏捷规则”，但用得稀里糊涂，成效微乎其微。
4. 25% 看不出有过去二十年来各种编程思想作用的痕迹，包括敏捷在内。

他鼓励谨慎而智慧地应用敏捷实践，因为：

那些成功达成期望、从敏捷编程中获益的单位和个人，往往不是那些为常规的软、硬件卖点掏钱的家伙，而是倾听这些卖点、从中提取所需、以解决自身问题的。他们实现的是自己的想法，也并不排斥他山之石可以攻玉。总的来说，即使没有敏捷编程，他们对问题的解决也是成功的，而敏捷让成功锦上添花了。

本章结语中他呼吁三思而后行：

做我们这行，能轻松搞定的问题即便有，也不多。问题的成功解决，在于放低对“变魔术”的期待，以及努力实现自己想法的决心，哪怕这些想法出自公司年会酒足饭饱后的闲言碎语。总结以上教训，我打算在编程界另立门派，本门派信条如下：

• 没有什么能代替对问题本身的透彻认识，除非中了头彩。
• 没有什么解决方案能放之四海皆准，在某一场合的最佳方案，可能在别处偏偏是最差的。
• 好方法通常具有一定的普遍适用性，熟悉以往的成功案例，可以温故而知新。
• 解决之道不光是掌握方法，还得掌握时机，这样就能随机应变，让方法来适应问题，而不是削足适履。
• 就算懂得再多方法和时机，实战不会根据现有知识来出题，很多领域前人也未曾探索，还是谦虚第一。

请记住，本文初稿写于二十年前，本来是讨论结构化编程的，仅仅是把“结构化编程”替换为“敏捷”，就变成一篇时下适用的文章，和 1990 年一样。

类似地， Elisabeth Hendrickson 发表了题为“对敏捷的抵触，还是职业生涯的警钟？（Agile Backlash? Or Career Wakeup Call）”的文章，文章说，一提到敏捷应用，整个行业似乎充斥着抵触思维定式：

第一类思维定式中，抵触者是在那些半瘫痪的组织里，被缺心眼儿经理强加的“敏捷”恶心到无力的人们。“缺心眼儿”指的是，有些经理以为“敏捷教练”的资质，就是两天培训拿到的 CSM 证书（译注：Certified Scrum Master - 敏捷教练认证）；还有些经理以为，只要改改流程文档，搜索替换几个关键词，团队就可以敏捷、变形、出发了。几个关键词说的是：

• 阶段 --> 迭代
• 项目经理 --> 敏捷教练
• 需求 --> 用户故事
• 预计工时 --> 故事点
• 项目状况会议 --> 站立会议

悲催的是，我们眼看“敏捷”这个词变了味儿，谁都无能为力。每个流行语都这样——

ISO（国际标准化认证）、CMM（软件能力成熟度模型 - Capability Maturity Model）、CMMI（能力成熟度模型集成 - Capability Maturity Model Integration）、RUP（统一软件开发过程 - Rational Unified Process），你随便挑……

第二类思维定式更让她担心：

我发现还有一类思维定式，更让人上火，却又值得深究。这些抵触情绪，并非针对“敏捷”的误解误用，而是攻击敏捷实践本身：站立会议、结对编程、协作组、开放办公室等等。

我猜想，这里有些人是内向型性格，他们工作在一群外向型的人中间，而敏捷中包含的社交特性，让外向型的人一下子如鱼得水。内向型的人需要时间和空间，好让自己处理事情。如果一天到晚都没有足够属于自己的时间，他们会抓狂。如果这里说的就是你，希望你别把敏捷当成仇人，尝试跟大家一起工作，为协作时间和独处时间找一个可接受的平衡。

接下来她谈到，有许多社会行为放在以前可以容忍，而敏捷团队不能接受，而社会和心理成熟度对现今团队更加重要。

事实情况是，具有一定复杂度的软件系统创作，属于社会行为，需要集体合作。光凭才气是不够的，历来如此。真正有能力的团队成员，都有社交技巧，他们倾听、协作、分享，并做出贡献。

InfoQ 最近一篇文章探讨了敏捷炒作周期“敏捷是否到了梦醒时分？（Is Agile in the Trough of Disillusionment?）”

所以，计算机行业能否从历史车轮中学到某些东西？或者注定要一次次重复炒作新思潮？

注： 本文作者 Shane Hastie 是一位敏捷指导、教练和顾问，在澳大利亚和新西兰的软件教育联盟工作。另外这篇新闻的讨论也非常有意思，特摘出几个以飨读者，也希望我们能继续讨论。

Amr Elssamadisy：

浪花淘尽英雄……

我一边读一边点头，“风潮论”深合我心；而且悲哀的是，“敏捷之殇”的说法也深合我心——敏捷不灵了，因为获益的人越来越少，因为敏捷越长越大，大到真正重要的事说不出也做不到了。

另一方面，还没发现有谁进行结构化编程实践（也许是我没在意）。然而我可以想象，敏捷的核心原则，对个体和互动的关注等等……从现在起适用 5 年、10 年、20 年。

我们正在整理 Steve Peha 的一篇文章，即将发表在 InfoQ，内容是如何将敏捷原则应用于美国的教育系统。想想结构化编程，能适用于其他领域吗？

Udayan Banerjee：

迭代开发怎么样？试误法（trail and error）是否进化的关键因素？我认为这是敏捷的重中之重。

一个思考——20 年后，我们是与人互动，还是与一个系统互动？

Jens Meydam：

Amr 你好，

……因为获益的人越来越少，因为敏捷越长越大，大到真正重要的事说不出也做不到了。

你觉得“真正重要的事”是什么？

Amr Elssamadisy：

你觉得“真正重要的事”是什么？

嗯……仅举几例：

1. 瓶颈在于学习；
2. 所有权；
3. 改进别人之前，先改进自己；
4. 在每个迭代，对“完成”的狂热偏执；
5. 重视实际商业价值，而非抽象概念；
6. 改变环境，以达到上述要求。

列这些的时候，我知道敏捷社区中已经有一些模糊的提法，大家都在说“文化”，但每个人对文化都有不同的理解。但我发现，包括上述在内的一些特性，在应用敏捷和精益成效明显的团队都有体现。

Jens Meydam：

谢谢，这个列表很有分量！

说实话，我感兴趣的是，你没把重点放在技术上（除了第四点“完成”之外）。好多 XP 出身的教练似乎觉得，人们半推半就被敏捷的主要原因，是技术能力缺乏，而且有人批评 Scrum 脱离工程实践。

你眼光独到地指出问题所在——学习、所有权、创造真正的商业价值——我非常同意。技术能力是必要条件，但远远不是充分条件。

Amr Elssamadisy：

多谢。你说的对，技术能力是必要但不充分条件，Scrum 也不能例外。我怀疑的是，类似前面提到那些领域，能否成为必要且充分的条件。

非技术因素与技术因素相辅相成。你认为重要事情的列表有哪些呢？