关于敏捷

在一家以敏捷开发和咨询著称的公司工作了一年了，以下是我当前对敏捷的认识：

1.敏捷宣言：

个体与交互胜过过程与工具

可以工作的软件胜过面面俱到的文档

客户协作胜过合同谈判

响应变化胜过遵循计划

以上是大家熟悉的四句箴言，但还有一句话也许常被忽略：“即，虽然右侧条目有其价值，但我们更重视左侧条目”。这句话也放在了宣言不显著的地方。宣言的官网背景是几位敏捷先贤讨论问题的画面，中间的大胡子应该是老马（MartinFowler）。这副背景画颇有宗教油画的风格。

2.CMMI

一个叫德里克·布鲁克斯的人曾经领导开发过一个失败的大型计算机操作系统：System/360。他离开这个项目后写出了古典名著《人月神话》。接替布鲁克斯来擦项目屁股的人叫做瓦茨·汉弗里。汉弗里惊讶的发现这么大的项目居然没有正式严格的计划，不知道汉弗里到底经历的多少麻烦，他退休后加入了一个五角大楼开办的软件工程学院，在那儿他和同事们建立了软件成熟度模型（CMM），其中最有名的是其五个台阶：

台阶一：组织基本没做啥

台阶二：组织做一些计划，跟踪，配置管理工作，也讨论质量保证等话题

台阶三：组织为各种活动定义了过程

台阶四：组织有了准绳，活动可以跟踪和度量

台阶五：组织有持续改进的过程

有时，敏捷和CMMI被人们一起谈论作对比，从我对它们目前的了解来看，两者似乎没太多联系。而且CMM5的“持续改进的过程”似乎比“敏捷”还敏捷。

3.Scrum

我第一次真正对敏捷产生兴趣是两年前听说了这个词，随后参加了公司的Scrum的兴趣小组，也读了些Scrum的书，其中对这本印象深刻。有一阵子还傻乎乎的自己给自己写Backlog，Sprint和Story，还关注下Burningdownchart。对于很多人，或许Scrum就是敏捷，敏捷就是Scrum。依我看来，Scrum像是CMM3+敏捷，或者是基于敏捷理念的开发流程。有趣的是：几乎每本Scrum的书和文章都要提到一鸡和猪的故事。Scrum之所以流行可能是其提供一整套可操作的过程，容易上手，如同方便面一般方便。但是教条的执行Scrum我看还真一点都不敏捷。

4.极限编程（XP）

极限编程的名字起得颇有邪教的感觉。XP要比Scrum历史悠久，但没有Scrum那么流行。XP中的TDD和结对编程常常引起很大的争议。在我一年的XP实践中，我却很对这两个玩意产生了极大的兴趣。、

反感TDD的人往往是没有真正尝试过TDD的人，想玩玩TDD的最佳方式也许是跟一个熟悉TDD程序员结对一会儿。很多场合下，用TDD开发非常有趣并且能写出高质量的代码。但是任何时候都教调的使用TDD不一定能带来多大好处，测试代码也有维护成本的。

对于结对编程，大多数人都是很难理解的。有些拥有结对编程经验的程序员对它又爱又恨。结对最大的好处或许是知识传播，想学习某种技术时和一个高手结对是效率非常高的方式。新人加入团队，和老成员结对能非常迅速的进入状态。但是两个水平差异不大，但开发习惯迥异的人坐在一起结队是一种煎熬。一个经常发生的事情是：经过长时间无意义的讨论甚至争吵后，双方妥协写出一段折中的代码，这段代码仅仅是折中的而不是最好的代码。

5.精益（Lean）

敏捷宣言已经发布十年了，已经不是新鲜玩意了。业界需要点新潮点的词汇。精益来自于丰田公司的生产模式。在朝鲜战争时期，丰田汽车公司为了为美军提供更多品种的汽车，来自丰田纺织公司的大野耐一根据以往的经验并通过不断的实践发明了丰田生产方式。这种生产方式在学术界被称为精益生产。精益生产中有不少实践跟一些敏捷开发实践不谋而合，如自动化，可视化等。但是生搬硬套精益思想中的一些理念到软件开发中多少有些别扭。

6.敏捷实践

以下是我接触过的敏捷实践：

结对编程：尤其适合老人带新人，和老艺人传帮带很像，和高手结对真是职业生涯的幸事

TDD：有趣，值得尝试

站立会议：不错的交流方式，站会讲究简短不展开，有问题会后交流

故事卡：一种很有效的需求分析方式

故事墙：可视化项目进展，很有趣，但我个人认为作用不大

燃烧曲线：没感觉，或许客户喜欢看

回顾会议：回顾会议的召开需要些技巧，需要个好的主持方式，确实能暴露问题

ShowCase:需要客户配合才有作用

迭代开发：讨厌僵化的迭代开发，迭代计划还是有弹性的好

看板方式：来自精益生产，能够取消迭代，减少浪费，赞

持续集成：见7

7.持续集成

每当Build成功，就有小鸟唱歌；Build失败就是一声闷雷，团队中必须有人站出来为此负责。这种开发模式我去年才刚刚接触到，但恐怕我的职业生涯会离不开它了，我认为它是最有用的敏捷开发实践。甚至有些同事对持续集成的评价是持续集成就是敏捷。

8.传说中的敏捷团队

传说中的敏捷团队，每个人都是多面手，沟通畅通，有效协作，共同成长并且持续改进，心心相通，众志成城，快速响应变化，为客户带来最大的价值。我相信这样的团队是存在的，因为我现在所处的项目团队已经让我看到了敏捷团队的雏形。

有幸和老马有了一次面对面的交流，和老马介绍了下我们的项目，但他也没有给出什么建议。

最后我问了两个问题：

我：您是我的偶像，请问我如何才能成为一个像您这样的软件开发高手？

老马：我无法回答，我不是开发者了，我只是个演说者。

我：项目中和客户交流，客户说你们不用搞太多测试和TDD之类，我们希望你们做的更快些，多实现功能为主。我认为我们的主要目的是为客户多交付价值，所以我们确实应该减少测试的力度，您怎么看？

老马：你需要权衡（Tradeoff），但在我看来写测试只会让我更快些。

一篇对敏捷讽刺的帖子，的确，如果教条的使用一些敏捷实践恐怕没什么好处。在公司内部，也有很多质疑敏捷的声音，我想如果没有质疑和反馈来促使改进，敏捷就不是敏捷了。

11. 技术 > 任何方法论

我到现在还一直持有这个偏激的观点：软件开发不是工程而是艺术，开发者的技术水平决定了软件的水平。敏捷实践能够帮助优秀的发者们做的更好更快。但追求更高的技术才是软件开发的王道。