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

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

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

你可能感兴趣的:(敏捷开发)