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

     作家和顾问温伯格（    <a href="/misc/goto?guid=4958190520086294367">Gerald M. Weinberg</a>）已在计算机行业活跃了半个多世纪，作为一些最具影响力    <a href="/misc/goto?guid=4958190520824679296">书籍</a>的作者，他在业内广为人知，备受尊敬。    <p> 最近，他在自己的博客“<a href="/misc/goto?guid=4958190521547009658">顾问的秘密（Secrets of Consulting）</a>”上发表文章，指出大家对历史的漠不关心，创新和进步被炒作周期所包围，似乎大家都在重复以往，没有组织和个人从前一个周期中吸取教训。</p>    <p> 他正在将之前写的书《系统分析与设计的反思（Rethinking Systems Analysis and Design）》重排为电子版格式，并打算对写于20年前的一个章节进行修改，原标题为“超越结构化编程（Beyond Structured Programming）”。结果发现，只要将短语“结构化编程”替换为“敏捷”，这章内容就会针对到时下的“敏捷编程革命”上来。</p>    <p> 他说：</p>    <blockquote>     <p>虽然这是写给上一辈人看的文章，如今经过两代人了，而且对多数程序员来说，“敏捷编程革命”也已经是明日黄花，但这文章所说的仍然适用——即使对于下一波和再下一波反思风潮，也仍然适用。我相信它在版本停止更新很长时间以后，还能有现实意义。为什么？因为我们这个行业耐不住寂寞，每十年就要闹一轮新风潮。所以，你读这篇文章的时候，也别管圈内里正充斥着哪些风潮，只要沿用同样的教训就好了。</p>    </blockquote>    <p> 接下来他谈到，很多公司将实践创新做为口号，实际做起来，要么是盲目套用了条条框框，要么是只重简单实践，而并未贯彻有效变革所需的原则。</p>    <p> 他说，如果详加考察所谓的敏捷应用：</p>    <ol>     <li>5%可认为彻底达成敏捷。</li>     <li>20%可认为充分遵循了敏捷实践，相对于1990年的平均水平，有了明显改进。</li>     <li>50%能部分证明是多少尝试用到了一些“敏捷规则”，但用得稀里糊涂，成效微乎其微。</li>     <li>25%看不出有过去二十年来各种编程思想作用的痕迹，包括敏捷在内。</li>    </ol>    <p> 他鼓励谨慎而智慧地应用敏捷实践，因为：</p>    <blockquote>     <p>那些成功达成期望、从敏捷编程中获益的单位和个人，往往不是那些为常规的软、硬件卖点掏钱的家伙，而是倾听这些卖点、从中提取所需、以解决自身问题的。他们实现的是自己的想法，也并不排斥他山之石可以攻玉。总的来说，即使没有敏捷编程，他们对问题的解决也是成功的，而敏捷让成功锦上添花了。</p>    </blockquote>    <p> 本章结语中他呼吁三思而后行：</p>    <blockquote>     <p>做我们这行，能轻松搞定的问题即便有，也不多。问题的成功解决，在于放低对“变魔术”的期待，以及努力实现自己想法的决心，哪怕这些想法出自公司年会酒足饭饱后的闲言碎语。总结以上教训，我打算在编程界另立门派，本门派信条如下：</p>     <ul>      <li>没有什么能代替对问题本身的透彻认识，除非中了头彩。</li>      <li>没有什么解决方案能放之四海皆准，在某一场合的最佳方案，可能在别处偏偏是最差的。</li>      <li>好方法通常具有一定的普遍适用性，熟悉以往的成功案例，可以温故而知新。</li>      <li>解决之道不光是掌握方法，还得掌握时机，这样就能随机应变，让方法来适应问题，而不是削足适履。</li>      <li>就算懂得再多方法和时机，实战不会根据现有知识来出题，很多领域前人也未曾探索，还是谦虚第一。</li>     </ul>    </blockquote>    <p><strong> 请记住</strong>，本文初稿写于二十年前，本来是讨论结构化编程的，仅仅是把“结构化编程”替换为“敏捷”，就变成一篇时下适用的文章，和1990年一样。</p>    <p> 类似地，<a href="/misc/goto?guid=4958190522289256437">Elisabeth Hendrickson</a>发表了题为“<a href="/misc/goto?guid=4958190523024851483">对敏捷的抵触，还是职业生涯的警钟？（Agile Backlash? Or Career Wakeup Call）</a>”的文章，文章说，一提到敏捷应用，整个行业似乎充斥着抵触思维定式：</p>    <blockquote>     <p>第一类思维定式中，抵触者是在那些半瘫痪的组织里，被缺心眼儿经理强加的“敏捷”恶心到无力的人们。“缺心眼儿”指的是，有些经理以为“敏捷教练”的资质，就是两天培训拿到的CSM证书（<strong>译注：</strong>Certified Scrum Master - 敏捷教练认证）；还有些经理以为，只要改改流程文档，搜索替换几个关键词，团队就可以敏捷、变形、出发了。几个关键词说的是：</p>     <ul>      <li>阶段 --> 迭代</li>      <li>项目经理 --> 敏捷教练</li>      <li>需求 --> 用户故事</li>      <li>预计工时 --> 故事点</li>      <li>项目状况会议 --> 站立会议</li>     </ul>     <p>悲催的是，我们眼看“敏捷”这个词变了味儿，谁都无能为力。每个流行语都这样——</p>     <p>ISO（国际标准化认证）、CMM（软件能力成熟度模型 - Capability Maturity Model）、CMMI（能力成熟度模型集成 - Capability Maturity Model Integration）、RUP（统一软件开发过程 - Rational Unified Process），你随便挑……</p>    </blockquote>    <p> 第二类思维定式更让她担心：</p>    <blockquote>     <p>我发现还有一类思维定式，更让人上火，却又值得深究。这些抵触情绪，并非针对“敏捷”的误解误用，而是攻击敏捷实践本身：站立会议、结对编程、协作组、开放办公室等等。</p>     <p>我猜想，这里有些人是内向型性格，他们工作在一群外向型的人中间，而敏捷中包含的社交特性，让外向型的人一下子如鱼得水。内向型的人需要时间和空间，好让自己处理事情。如果一天到晚都没有足够属于自己的时间，他们会抓狂。如果这里说的就是你，希望你别把敏捷当成仇人，尝试跟大家一起工作，为协作时间和独处时间找一个可接受的平衡。</p>    </blockquote>    <p> 接下来她谈到，有许多社会行为放在以前可以容忍，而敏捷团队不能接受，而社会和心理成熟度对现今团队更加重要。</p>    <blockquote>     <p>事实情况是，具有一定复杂度的软件系统创作，属于社会行为，需要集体合作。光凭才气是不够的，历来如此。真正有能力的团队成员，都有社交技巧，他们倾听、协作、分享，并做出贡献。</p>    </blockquote>    <p> InfoQ最近一篇文章探讨了敏捷炒作周期“<a href="/misc/goto?guid=4958190523765788470">敏捷是否到了梦醒时分？（Is Agile in the Trough of Disillusionment?）</a>”</p>    <p> 所以，计算机行业能否从历史车轮中学到某些东西？或者注定要一次次重复炒作新思潮？</p>    <p><strong> 注： </strong>本文作者<a href="/misc/goto?guid=4958190524503712509">Shane Hastie</a>是一位敏捷指导、教练和顾问，在澳大利亚和新西兰的软件教育联盟工作。另外这篇新闻的讨论也非常有意思，特摘出几个以飨读者，也希望我们能继续讨论。</p>    <p> Amr Elssamadisy：</p>    <blockquote>     <p>浪花淘尽英雄……</p>     <p>我一边读一边点头，“风潮论”深合我心；而且悲哀的是，“敏捷之殇”的说法也深合我心——敏捷不灵了，因为获益的人越来越少，因为敏捷越长越大，大到真正重要的事说不出也做不到了。</p>     <p>另一方面，还没发现有谁进行结构化编程实践（也许是我没在意）。然而我可以想象，敏捷的核心原则，对个体和互动的关注等等……从现在起适用5年、10年、20年。</p>     <p>我们正在整理Steve Peha的一篇文章，即将发表在InfoQ，内容是如何将敏捷原则应用于美国的教育系统。想想结构化编程，能适用于其他领域吗？</p>    </blockquote>    <p> Udayan Banerjee：</p>    <blockquote>     <p>迭代开发怎么样？试误法（trail and error）是否进化的关键因素？我认为这是敏捷的重中之重。</p>     <p>一个思考——20年后，我们是与人互动，还是与一个系统互动？</p>    </blockquote>    <p> Jens Meydam：</p>    <blockquote>     <p>Amr 你好，</p>     <p>……因为获益的人越来越少，因为敏捷越长越大，大到真正重要的事说不出也做不到了。</p>     <p>你觉得“真正重要的事”是什么？</p>    </blockquote>    <p> Amr Elssamadisy：</p>    <blockquote>     <p>你觉得“真正重要的事”是什么？</p>     <p>嗯……仅举几例：</p>     <ol>      <li>瓶颈在于学习；</li>      <li>所有权；</li>      <li>改进别人之前，先改进自己；</li>      <li>在每个迭代，对“完成”的狂热偏执；</li>      <li>重视实际商业价值，而非抽象概念；</li>      <li>改变环境，以达到上述要求。</li>     </ol>     <p>列这些的时候，我知道敏捷社区中已经有一些模糊的提法，大家都在说“文化”，但每个人对文化都有不同的理解。但我发现，包括上述在内的一些特性，在应用敏捷和精益成效明显的团队都有体现。</p>    </blockquote>    <p> Jens Meydam：</p>    <blockquote>     <p>谢谢，这个列表很有分量！</p>     <p>说实话，我感兴趣的是，你没把重点放在技术上（除了第四点“完成”之外）。好多XP出身的教练似乎觉得，人们半推半就被敏捷的主要原因，是技术能力缺乏，而且有人批评Scrum脱离工程实践。</p>     <p>你眼光独到地指出问题所在——学习、所有权、创造真正的商业价值——我非常同意。技术能力是必要条件，但远远不是充分条件。</p>    </blockquote>    <p> Amr Elssamadisy：</p>    <blockquote>     <p>多谢。你说的对，技术能力是必要但不充分条件，Scrum也不能例外。我怀疑的是，类似前面提到那些领域，能否成为必要且充分的条件。</p>     <p>非技术因素与技术因素相辅相成。你认为重要事情的列表有哪些呢？</p>    </blockquote> 转自：    <a href="/misc/goto?guid=4958190525245787531">http://www.infoq.com/cn/news/2011/06/learning-from-history</a>    <br />