软件工程 敏捷的酒后问答
王屋村移山公司的程序员果冻最近请假参加了一系列敏捷的培训, 有好事者传言他和 “a-girl”勾搭上了, 其他年轻同事有点坐不住了, 也表示要参加此类活动。 几天后, 果冻回到公司, 给所有人发了一枚写有 “Agile” 的胸章。 他纠正大家的发音, 这个词不是发 “a-girl”， 而是“爱脚儿”！ 果冻希望大家一起在公司里掀起一股爱脚儿的热潮, 把公司的软件工程质量从 CMM5 再提高一个档次。
小飞给他讲了一个笑话:
软件团队开会, 领导说: 我们要采用敏捷的开发流程. 很简单, 就是木有计划, 木有文档, 马上写代码, 随时发牢骚。
工程师问: 培训有木有?
领导说: 有, 刚才就是培训. 散会! 现在可以写代码和发牢骚了.
以上图片从 dilbert.com 提供的链接得来
果冻说, “我不觉得可笑, 我认为敏捷是瀑布模型发明以来的另一个巨大的进步。”
大家笑完之后, 问那 爱脚儿模式到底是什么玩意儿? 能管用么? 能挣更多的钱么?
果冻说, 大家稍等几天, 多种敏捷大会的 PPT 就上线了. 到时大家就敏了!
晚上大家在顶球酒吧喝酒的时候, 碰到阿超, 于是就有这样的问答:
问: 爱脚儿 - 敏捷到底是什么东东? 好像有很多名词, 缩写和传说…
答: 敏捷 (Agile) 是一股思潮, 它包括了好几种软件开发的方法论 (methodology); 这些方法论又是建立在许多业界证明行之有效的最佳实践方法 (best practices) 上面的。 如图所示:
问: 敏捷的思想是从天上掉下来的么?
答: 不是, 是人们自己总结出来的。
问: 敏捷的方法论有哪些?
答: 比较有名的是:
- 爱抚弟弟 (FDD)
- 史克朗姆 (SCRUM), 又叫丝瓜茻, 屎壳郎木, 死磕浪漫等。
- 极限编程 (XP)
问: 那比较有名的最佳实践是什么?
答: 这就太多了, 你把任意三个字母组合一下, 说不定就是一个最佳实践, 例如 TDD (踢弟弟) 就是一个最佳实践。很多程序员老大哥都很喜欢踢弟弟。
问: 为什么人们以前没有总结出来敏捷, 而是最近这几年才醒悟呢?
答: 这个… 当原始人没有东西吃的时候, 为什么他们不知道吃方便面? 稍稍正经一点来说 - 有几个原因导致敏捷在互联网时代出现:
- 最初的软件 (20 世纪60-70 年代) 的顾客都是大型研究机构, 军方, NASA 这些, 他们需要软件系统来搞科学计算, 军方项目, 和登月项目等, 这些系统相当庞大, 对准确度要求相当高。
- 20 世纪 80年代到90年代中, 软件进入了桌面软件的时代, 开发的周期明显缩短, 各种新的方法开始进入实用阶段. 但是软件发布的媒介还是软盘, CD, DVD, 做好一个发布需要较大的经济投入, 不能频繁更新版本。
- 互联网时代, 大部分的服务是通过网络服务器端实现, 在客户端有各种方便的推送 (push) 渠道. 由于网络的转播速度和广度, 知识的获取更加容易, 很多软件服务可以由一个小团队来实现。 同时技术更新的速度在加快, 那种一个大型团队用一个固定技术开发2-3 年再发布的时代已经过去了。 用户需求的变化也在加快, 开发流程必须跟上这些快速变化的节奏。
问: 什么样的牛人一夜之间想出了这么多敏捷的东东?
答: 首先, 很多方法已经在实践中运用了很多年, 不是牛人们一夜之间想出来的; 其次, 很多方法论把原来单个的实践方法结合起来, 运用到极致, 吸引了不少眼球。 不过, 一些牛人的确在几个晚上搞出了一个 “敏捷宣言”:
2001年2月，17 位软件绿林好汉聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。白天除了滑雪, 没啥鸟事; 晚上除了喝酒侃大山, 鸟没啥事… 但是他们都感觉世变时移, 变法宜矣。 经过讨论，《敏捷宣言》应运而生:
敏捷思潮的价值观：
Individuals and interactions over processes and tools
个人和交互 重于 过程和工具
Working software over comprehensive documentation可用的软件 重于 完备的文档
Customer collaboration over contract negotiation和客户协作重于 合同谈判
Responding to change over following a plan响应变化 重于 遵循计划
后者并非没有价值，只是我们更加关注前者。
敏捷的原则中文版在这里。
问: 为啥很多研究都证明敏捷很有效果?
答: 大多数被测试, 被研究的新东西都很有效果, 这是 Hawthorne 效应。例如你可以测试 “给每一个程序员发毛绒玩具 - 然后测试劳动生产率“， 你会发现劳动生产率提高了!
问: 敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”, “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?
答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:
| 客观因素\最适用方式 | 敏捷 (Agile) | 计划驱动 (Plan-driven) | 形式化的开发方法 (Formal Method) |
| 产品可靠性要求 | 不高, 容忍经常出错 | 必须有较高可靠性 | 有极高的可靠性和质量要求 |
| 需求变化 | 经常变化 | 不经常变化 | 固定的需求，需求可以建模 |
| 团队人员数量 | 不多 | 较多 | 不多 |
| 人员经验 | 有资深程序员带队 | 以中层技术人员为主 | 资深专家 |
| 公司文化 | 鼓励变化, 行业充满变数 | 崇尚秩序, 按时交付 | 精益求精 |
| 实际的例子 | 写一个微博网站; | 开发下一版本的办公软件; 给商业用户开发软件 | 开发底层正则表达式解析模块; 科学计算; 复杂系统的核心组件 |
| 用错方式的后果 | 用敏捷的方法开发登月火箭控制程序, 前N 批宇航员都挂了。 | 用敏捷方法, 商业用户未必受得了两周一次更新的频率。 | 敏捷方法的大部分招数都和这类用户无关, 用户关心的是: 把可靠性提高到 99.99%, 不要让微小的错误把系统搞崩溃! |
在实际情况下, 有许多号称敏捷的项目好像也敏捷不到那里去 （这两天在博客园看到的 例子1, 例子2， 例子3）。 要记住, 有许多最佳实践在各个开发方式下都在使用， 所以各个开发方式并不是井水不犯河水, 老死不相往来的那种关系.
问: 敏捷难道不是通吃一切的? 你列这个表, 好像没有给敏捷应得的名分呀?
答: 我酒后的见解就是这样。 比如有穿全套制服, 开警车出行的警察; 也有很多便衣警察; 他们各有最佳的适用范围，对吧？ 如果你觉得便衣的名分没得到, 给他们统一打扮起来, 就成了下面的情况:
名分是有了, 但是他们的最佳适用范围呢?
问: 听说有大写的爱脚儿, 和小写的脚儿之分?
答: 有的, 有些激动的人士把敏捷当作一种宗教, 所以大写 Agile; 另一些人只是把敏捷当作一个形容词, 所以小写 agile.
"we follow an agile process" 一般指团队的流程比较灵活。 "we follow the Agile process" 指按照官方敏捷流程的教义开展工作。 当敏捷变成了宗教, 你说它还会敏捷么? 当实事求是的做法和教条发生了冲突， 你怎么办呢?
举个例子, 果冻晚饭吃了 “小葱拌豆腐”, 这是历史悠久的一道素菜。
果冻的朋友不会说-
哇, 这不是最近某大师推荐的么？ 你成了他的粉丝？你要吃素?! 你要做和尚么? 有什么想不开的？
我们不要把一些 “有益健康的饮食”和 “投靠某大师/宗教的教义”混淆起来。 当然, 有些大师希望把天下每一道素菜都当作自己首创的, 这另当别论。 如果有人说 - 有些人不适合吃小葱拌豆腐 (例如痛风病人)。 你可以想象有狂热者反驳 - 你难道说豆腐不好? 你有没有搞错？ 你们看到现在吃豆腐多么流行！这么多吃豆腐的人都错了么?!
半年前果冻还经常吃生的茄子呢, 那滋味怎么样 。。。 哦, 扯远了, 我们是在聊什么？ 哦, 爱娇娥, 爱脚儿…
回到敏捷 (agile) ， 它是一个形容词， 不是一个东西， 它修饰的是做事情的方式，不是这事情本身。 所以“敏捷”需要一个动作的执行者和一个动作。 光说“敏捷好”是没有用的。
问: 我怕宗教，那么如何分清原教旨主义的爱脚儿, 和把爱脚儿当作实践工具的人士?
答: 很简单, 你有礼貌地问对方: 敏捷方法有不适用的场合么? 然后冷静观察对方的回答和表情, 就可以了. 必要的时候要准备好逃跑的路线。
问: 现在俺们村里有很多发传单, 推广敏捷培训的人士, 他们是哪一种?
答: 他们是卖东西的，挣钱不容易, 我们不必挡别人的财路。无语微笑, 避免过多目光接触, 走自己的路即可。
问: 要敏捷的话, 是不是手头用惯了的工具都不能用了?
答: 那倒未必, 有很多工具支持敏捷的方法论, 例如 微软的 Visual Studio Team System 就支持 Agile 的方法论 （叫 msf-agile）。 它也有自己的一套方法论 - 以前我们不是有一个 白话MSF 的讨论么?
有理论而没有工具, 那理论也是白扯
有工具而不懂理论, 那工具不能发挥最大作用
问: 敏捷的思想是不是能指导软件开发以外的工作?
答: 当然可以, 例如把下面文章的某某思想换成 敏捷思想, 也是能讲得通, 你看那pair-programming 的两个妙龄少女身手多么敏捷!
问: 我想敏捷，但是项目的期限不能往后拖, 敏捷能帮我早日完成任务么?
答: 敏捷不是万能的。 敏捷的方法能帮助你更早地知道你是否能如期完成任务, 仅此而已。 敏捷的方法（迭代的方式）能帮你尽快让用户看到项目的 部分 价值。 当你尽早交付 部分 价值的时候， 也许用户对你目前交付的东西已经很满意了，这样你就不用再花时间来实现其它事情。 另一种可能是， 用户看到了部分系统，他们有新的需求，这样你就可以实现新的需求，而不用再浪费时间实现过时的需求了.
问: 软件开发领域还有其他一些思想, 例如大集市 vs 大教堂, 你对它们怎么看?
答: 百花齐放当然好, 但是都有各自的适用范围。北京潘家园有古董大集市, 在那儿买到真正古董的几率是多大呢? 更深入的研究请看这篇文章和有关的讨论:
http://www.ituring.com.cn/article/9363
**************
注: 果冻, 小飞, 阿超都是 《移山之道》中的人物. 问答都在酒后进行, 也许有很多不准确的地方.
