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

　　作家和顾问温伯格（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也不能例外。我怀疑的是，类似前面提到那些领域，能否成为必要且充分的条件。

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