敏捷并非奢侈品——项目型公司也可以敏捷

InfoQ 在 1 月 20 日标题文章中刊发了 Christopher Goldsbury 的一篇与敏捷相关的文章《为什么有些公司敏捷实施不成功？》（这里简称做“为什么”），看了之后有些感想和看法，由于之前无论是瀑布还是重量级的开发过程，又或者是敏捷实践，几种类型的项目都参与过，并且在一些项目当中作为负责人，因此有一些东西似乎不吐不快。其实进行这类题目有关的讨论都比较敏感，大凡A vs. B 有关的话题都会引起A 和B 双方阵营的PK，甚至可以达到信仰的高度，这种口水仗往往到最后都大多数会演变成一出闹剧，情绪化和宗教式信仰掩盖了讨论问题的本身，在这里我只就个人的敏捷开发经历和对敏捷的了解谈一些对这个话题的看法——可否敏捷是否依软件公司类型而论？

Goldsbury 的主要观点

概括 Goldsbury 在“为什么”一文的主要观点综合而言是这样的：行业中有典型的两大类公司，一类是以研发软件产品、销售这些软件产品或者基于这些产品进行定制的软件公司，Goldsbury 称之为 X 类，另一类是项目定制型公司，Goldsbury 称之为 Y 类，Goldsbury 认为在 X 类公司中实施敏捷可以成功，而在 Y 类公司则将导致失败。Goldsbury 的理由是在开发中无论选择什么样的开发方式都需要考虑资金预算和成本，X 类公司以软件产品作为赖以生存的根本，因此所拨的经费预算是用以维持一个长期稳定开发团队，在这种支持下面实施敏捷才有保障和意义，而 Y 类公司是对一个特定项目进行预算分配，时间周期通常较短，而且又严格受“项目三角”所制约，项目团队通常是临时组建甚至是由合同工构成，作为“奢侈品”的敏捷在这里并不适合。

这个观点在视角上跟大多数敏捷观点不同，敏捷的方法和观点通常都是正方向出发，也就是遵循最佳实践，获得最佳结果，Goldsbury 从成本角度出发，将开发划分为两类，指出 Y 类公司这种开发从成本上看采用敏捷并不适合，Goldsbury 在提出这个主要观点之后作为举证还列举敏捷在项目型开发上存在的几点不足：缺乏对项目范围进行整体估算，估算仅仅针对每一次迭代，对固定报价项目来说进行时间和成本控制不利；敏捷很少考虑成本问题，管理人员对敏捷知之甚少，无法从财务角度进行管理；故事点体现的是开发功能的复杂程度和开发效率，可以衡量一个迭代在什么时候完成，跟项目经费估算没有直接关系；迭代给项目总体估算带来困难，燃尽图只能揭示迭代的进度，而无法体现所有功能应该在允许时间段内做完。

对 Goldsbury 主要观点的理解

西方人表达自己观点的方式通常都比较严谨，一二三点，观点是什么，理由在哪里，然后有什么具体场景，Goldsbury 在“为什么”中的表达能够很好的体现这些特征，这也给我们把握这些观点理解其要旨带来一定难度，东方人的思维比较适合浅显且言简意赅的表达，将 Goldsbury 的观点以东方人思维方式表述，我的理解是：敏捷比传统开发要花钱，所以不适合固定金额合同的项目型公司，并且，用敏捷不好管理这种类型的项目，在项目一开始，怎么做范围、时间、费用总预算？项目进行的过程中，怎么做调控？敏捷专家们很少提过这些事情，敏捷方法和实践中也只说测试驱动、结对编程的好处，没提到作为管理者该怎么管理。

对敏捷作为“奢侈品”的存疑

敏捷比传统开发要花钱，这个是 Goldsbury 得出结论的一个前提假设，Goldsbury 没有对这个前提假设进行论证，因此这点值得去探讨一下。由于手头没有传统开发与敏捷开发在成本上 pk 的数据，因此对这个问题我这里只能泛泛讨论一下，另外对我个人在敏捷实践的一些经历和感受做些回顾和总结。一款汽车加速性比其他款式要强劲，我们往往可以认为这款汽车造价不菲，起码 Goldsbury 会有这么一个观点就是，敏捷的确比传统开发方式要快，而且会快很多，因此打造这么一个开发团队、采用这样一种开发方式也是需要付出代价。在一定时间和环境条件下看，的确如此，敏捷不是天上掉馅饼，Jim Highsmith 多次强调，敏捷是一种变革，既然是变革那就需要付出代价，从传统模式进入到敏捷会有很多不适应，比如，‘为什么需要我边实现业务逻辑，又要同时写单元测试代码？以前的项目可从不是这么干的，这个项目时间这么紧，写测试代码的时间完全可以实现另一个重要的功能’…诸如此类，什么事情都是由人来做，态度决定一切，当一个人有抵触情绪去做一件事的时候，这件事十有八九干不好。在一个项目中去培养团队的敏捷，最终很有可能会成为一个噩梦。

我也曾看到有一些公司一些想尝试敏捷的“Leader”是这么实现 TDD 的，向老板申请给团队增派一个人手，专门负责单元测试其他人的代码，后来发现问题很多效果很差，老板最终忍无可忍对该人手进行精简，敏捷革命宣告失败。以上这些案例可以为 Goldsbury 的“敏捷需要不小花费”观点做很好的旁注，在你还不“敏捷”的时候你想要“敏捷”，你需要付出应有的成本，这也是为什么 Goldsbury 认为 Y 公司会敏捷失败的一个理由，相比 X 公司的长远规划长远投资，一个固定金额合同的项目经不起折腾，那会严重影响项目时间和项目预算。但是如果 Y 公司在正确和恰当的方式下推动敏捷变革，在开发团队获得敏捷能力的时候，情形会完全相反，最初的投入成本会被敏捷化后的项目所摊平，项目的显著生产力和成功率可以带来长久的回报。还是以 TDD 为例，TDD 固然会提高 LOC 的数量，在 LOC 经济学上这会增加项目成本，但是不能否认 TDD 增加的那部分代码在每行单价上要远低于业务代码，而且，TDD 带来的优势是：避免过度设计、缩短开发时间、降低开发沟通成本、减少缺陷数量、缩短缺陷修复时间、获得变更能力并减少变更成本等等，这些成本优势很难再说敏捷是一个“奢侈品”。

再以敏捷的另一个常见实践持续集成为例，不使用持续集成的团队通常都会遇到这样的问题，某位成员在提交代码的时候有遗漏，整个项目编译不通过，其他成员在更新本地代码后，出现一大堆编译错误，然后开始抱怨。这种差错很影响团队的效率和气氛，采用持续集成后，编译失败或者不通过测试都会发出预警，在最短时间内自动通知整个团队，目前项目代码存在问题，需要检入代码的成员尽快解决问题，所带来的好处是节省查错和沟通的时间，团队开发比较平滑。持续集成的自动化使得构建成本几乎为零，这也很好的说明敏捷并非是“奢侈品”，其他敏捷实践也有类似说服力的“反证”，这里就不再一一列举。另外值得一提的是怎么从传统开发转向敏捷，一些敏捷框架比如 Scrum 可以帮助 Y 公司完成这一转变过程，关键是能把握敏捷的思想内核，而不是仅仅沿袭它的形式，还有那种找一个人专门帮别人写测试代码这种南辕北辙的错误更不应该出现。

项目管理角度的敏捷估算

在项目型的 Y 公司中，项目经理被老板问得最多的就是——“这个项目什么时间干完？”，老板通常很少问人够不够，在国内大多数公司中，老板给你最大的预算就是几个人和项目合同中已经写好的最后期限，而且项目经理大多手头大都没有项目财政大权，但似乎这并不妨碍老板或者财务部门向你要求提交一份项目预算报告。如果你在项目中初次使用敏捷，诚如 Goldsbury 所提，作为项目经理的你可能会不知所措。与传统重量级方法相反，敏捷是一种“自底向上”的开发方式，之所以这么说是因为传统方法非常注重事前的计划，过程中的管理控制，比如在项目开始之初需要进行详尽的需求调查分析，编写各种设计文档，而敏捷提倡要尽快的进入编码实现阶段，在实现过程中根据情况进行调整。传统开发倚重于管理者、过程，敏捷倚重于开发者个人的技能、自发性、彼此之间或者与用户间的沟通，根据变化灵活进行调整。

这点还体现在目前大多数的敏捷书籍上面，在这些书籍当中，很多敏捷实践得以介绍，但是对于计划和管理比较少提及，这种现象与敏捷的内在开发哲学相符。以国内出版物时间来看，关于敏捷下如何管理的著作开始比较多的出现是 5－6 年之内的事情，比如，清华大学出版社在 2005 年发行 Jim Highsmith 的《敏捷项目管理》（Agile Project Management）第一版。在 2004 年年底，Kent Beck 的《解析极限编程：拥抱变化》（Extreme Programming Explained: Embrace Change, Second Edition）再版发布，在第十二章“计划：管理范围”中，Kent Beck 把计划比作一个人怀揣着 100 块到超市里边购物，超市货架上的商品是故事（Stories），每个商品标价是预估（Estimate），你的 100 块钱是你可以拥有的项目时间，即预算（Budget），货架上的商品有些是你需要的，有些是不需要的，有些是你想要的，你能做的就是把你需要想要的放入你的购物车，最后在结账的时候不超过你的总预算 100 块，如果超过预算，那么对不起，请把购物车的一些货物放回货架上。Kent Beck 这里所要表达的观点就是你有多少钱办多少事，项目计划也是如此，在固定期限和金额的项目合同中，你所获得的资源和时间是确定的，那么你所能做完成的故事也会在一定范围，如果完不成所有合同规定的故事你该怎么办？那么你就需要跟相关人协商（negotiate），把该放回货架的”货物”放回到货架上。

在实际项目中，我们也遇到类似的情况，有时候有些需求放到二期项目实现，当然能否有二期就需要看你与客户的关系以及协商的结果了。Kent Beck 还指出计划不是对未来的预言，只是基于你今天知道的事情来推测明天将会是什么一个样子，因此你的计划应该是随着时间的推进而不断进行调整，也就是以迭代方式进行计划演变，以求计划更符合实际情况。那么如何在项目一开始提交预算报告给老板？这个问题很简单，就是在项目开始时基于所了解的情况作出对整个项目的估算，当然这通常比较难，敏捷给出的方案是必须要团队中的每一位成员参与一起做估算。Kent Beck 明确指出第一版中用故事点来估计并不理想，在第二版他提出以时间来估算：

极限编程解析的第一版包含一个较为抽象的估算模型，模型中的故事以点来计算，在对大型故事点进行计划之前需要先将其分解。一但开始实现故事点，你将很快得出一周当中究竟可以完成多少点。而现在我更倾向于用实际的时间来估算，这样可以使得沟通尽可能的清楚、直接和明了。
——《Extreme Programming Explained Embrace Change, Second Edition》之“Chapter12. Planning: Managing Scope”

因此回过来看看 Goldsbury 的观点，他说的没错，故事点和燃尽图能够反映有多少事情要做，多少事情已经做完，以及团队的开发效率，但是于计划用的项目估算意义不大。在我的项目经历中，燃尽图每日掉落的曲线以及其掉落的幅度形象表达出一种积极的变化，鼓励整个团队的人继续朝前努力，它跟墙上的 check out 的“便利贴”效果是一样的，它们是真实的，是实实在在的在朝前迈进。

小结

综合上述所言，我认为软件公司根据自身的特征和环境去实施敏捷是稳妥的做法，如果你是 Y 类型的公司，那么在项目中引入敏捷，一开始可能会遇到问题，以及从成本花费上看会有所增长，但是当你渡过这段时期之后敏捷所能带给你的优势会超过你最初的投入，那种 Y 类型公司实施敏捷将会失败的预言并不准确，但是我们应该看到相比于 X 类型公司它面临的问题会更为严峻。在敏捷实践中，结对编程是我没有触碰过的一种，但是根据 Kent Beck 在书中提到过的，实践中结对编程效率比非结对编程效率高两倍，如果真是如此，那么更没有理由说敏捷是一种奢侈品，不过不要高兴太早，Kent Beck 也在书中说这并不意味着你可以干完于两倍更多的活儿。Kent Beck 还说，只有所有实践加起来，那么敏捷才会爆发其最大的威力，这句话我确信，比如在 TDD 中，当你的代码测试覆盖率达到 100％后，基于 100% 之上的开发是效果最好的，而且好到“极限”，当然，到达这 100％也需要团队付出更多努力。

关于作者：黄维勇，多年从事 IT 技术开发和软件项目管理，对企业应用、互联网、移动开发、项目管理、敏捷等有浓厚的兴趣，主要开发语言为 Java/Ruby/Php，Sun 认证 Java 程序员 / 开发师 / 架构师。

感谢郑柯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。