偶然成为敏捷人士：个人回望《敏捷宣言》发布十年 ( Johanna Rothman )

本文是《敏捷宣言》10年系列纪念文章之一， 该系列文章将陆续在InfoQ上发布。

我不是《敏捷宣言》最早的签署者， 我甚至不是诸如TDD等敏捷实践的最早期采纳者。然而， 回望过去，我认为我是敏捷原则的早期采纳者， 即使当时我没有认识到这一点。

时间盒、增量式开发、持续集成、波浪式日程安排、 小石子式规划和报告、并行开发和测试等等这些实践， 我在很久之前就开始用了。多年来， 我们把这些实践跟敏捷联系在一起，因为它们确实很有成效。

相关厂商内容
首届QCon上海20个专题确认，80余场分享，全面征集演讲主题
百万大奖扶持创业，2013年阿里云开发者大赛互联网创新创业作品火热征集中！
JavaOne大会独家社区合作，InfoQ用户享75折购票
7月20-21日北京、武汉、成都百度开放云编程马拉松，关注环保，火热报名！
潘晓良 百姓网技术总监、联合创始人确认参与QCon上海2013，分享百姓网高效团队建设经验

相关赞助商

QCon全球软件开发大会（上海站）2013，特别策划上海特色专题，共计80场深度演讲，诚邀莅临。

我从来就不是“命令与控制”式项目管理的拥护者， 那样做不起作用。然而我过去担心敏捷会给不规范的工作提供借口。

回到2001年，敏捷的拥趸主要是开发人员。他们一直把“ 不要文档”放在嘴边上，而不是这样的事实： 修复缺陷的成本大幅下降，人们可以马上看到可以运行的软件， 测试人员从项目开始第一天就能真正加入到项目中来。没有这些， 我们当时听到的都是：“你不用再写任何文档了，写一些卡片就成。 ”好吧，我们确实要写卡片，而且会与人谈话， 这样我们才能了解需求，而不是仅仅试着将写得不好、 没什么内容的文档，替换成信息含量丰富的人际交流。

到了2003年的时候，发生了一件有趣的事情。 我当时在为一个组织做评估，他们采取为期6周的迭代。 他们的迭代有作用，但成效不显著。我当时很清楚： 他们需要缩短迭代周期。

当我撰写报告的时候，我建议他们将迭代周期缩短为最长三周， 两周最好。我还觉得， 如果他们能够将特性的大小减到能在几天内完成的程度， 他们就可以得到更快的进度，而且能给别人演示。 我建议他们使用持续集成，放弃原来按阶段集成的方式。 我还建议他们整合开发和测试团队，整合开发和测试活动。这时， 我已经变成了一个敏捷人士！

到了2003年下半年，我开始撰写和讲演与敏捷有关的内容， 提到类似这样的观点：“敏捷不是不按规范工作的借口， 相对其他软件开发生命周期，敏捷需要团队遵守更多纪律。”

当然，我当时并不认为我是敏捷人士。我决定实验一些实践， 比如结对和TDD。当我还是个开发人员的时候， 我跟一些人们采取了紧密的一对一工作方式， 我那时并不知道这是不是结对。于是，在一次AYE会议上， 我和同事Keith Ray一起结对实践TDD；我明确了解到： 这就是我以前的工作方式。不过有一点， 相对于80年代我的那些同事们来说，Keith要友善多了。

到了2005年，Esther Derby和我结对编写了《门后的秘密:卓越管理的故事》 的最终一稿并付梓。是的，我们坐在一起， 使用一台电脑和一个键盘，轮换写稿和指导。是的， 我们在敲出第一个单词之前有很多问题需要回答。

你看，我们从2000年开始写这本书， 我们的第一稿用了好几年才写成。送审之后，我们的审读人说：“ 内容很棒，就是太枯燥。”因此，我们又用了好几年来修订、重写， 并再次送审。审读人说：“内容很棒，但是比第一版还要枯燥。” 这下我们可麻烦大了。

Esther建议我们改变形式，还要结对写作。 我不记得我们中是谁建议在编写每章之前提出问题， 这就采取了测试驱动的方式，而且很有效。但是， 这个版本并没有花费我们两个人两年的时间， 我们用了6个星期就完成了草稿。而且，它一点也不枯燥！

就算回到1994年，当时我刚刚开始教授项目管理， 我就让大家使用黄色即时贴和迭代式方法做日程安排，还告诉人们： 他们的日程安排方法取决于他们的软件生命周期。现在， 我将敏捷放在我的软件生命周期列表之中， 教给人们如何使用迭代日程安排来应对所有类型的软件生命周期。

到了2000年早期， 当从未尝试过敏捷的人们认为敏捷会为不规范工作提供借口时， 我开始担心。我对他们的经验表示怀疑，他们高傲地说： 他们不需要任何经验就能知道，没有文档的项目就是不规范。 我问他们能不能提供一些成功项目的例子。无一例外， 他们都提到自己的成功项目都使用了原型化方法（迭代的例子）， 还有功能特性（增量式开发）。 我解释说他们已经描述了敏捷的元素，而且跟他们说： 如果他们的客户需要文档，比如美国FDA或是其他监管机构， 他们才可能会写文档；听到这些，他们就对敏捷没有那么多敌意了。

还是有人不相信所有的项目都可以使用敏捷。我就是其中之一。 不是因为有些产品的开发还不能敏捷实践， 我就在硬件项目中用过敏捷方法，包括芯片设计项目。

不是这样的。不能用敏捷，是因为还是有人、 团队和组织无法接受敏捷带来的透明度。

顺序式流程让人们得以隐藏：

    管理层可以藉此隐藏多任务以及缺少决策的现象， 这是管理债务的表现。
    在顺序式生命周期中，架构师可以隐瞒这样的事实： 在做出架构上的决策时，他们知道得不够多，没有足够的数据。
    开发人员可以避开缺陷和测试代码。
    顺序式生命周期让项目经理编制出甘特图童话， 并邀请其他人也相信其中的日程安排，这是一次编写， 永不阅读的日程，然后隐藏在这样的日程之后。
    顺序式生命周期让测试人员可以避开自动化测试， 即使这样做很有意义。

简而言之，对于所有我们已知的、能够提升代码质量、

项目水平和技术水平的实践，顺序式生命周期让所有人避开它们。

等到我们愿意拥抱敏捷带来的透明度时，我们都在口头上谈论“ 变得敏捷（becoming agile）”，却没有将其视为一个系统—— 一种整体的工作方式。“变得敏捷”已经说得很多了，至于怎么做， 却言之甚少。

现在，在2010年，我扩展了自己在时间盒内对看板的使用， 而且在某些情况下用看板替代时间盒。 这是因为有些客户不愿意承诺在时间盒内完成工作， 而是愿意承诺完成某个特性或是缺陷修复， 这对我来说算是足够好了，更重要的是，这对他们很好。

回到2001年，我当时认为自己是个实干的人，现在我也这么看。 我希望工作有成效，我希望我的客户的工作有成效， 不管采取什么方法，只要是适合他们特定的环境。很多时候， 这意味着综合方法、时间和技术等多个方面。

我也许是偶然成为敏捷人士，但是我现在坚定地站在这个阵营。 对我来说，最重要的是看到人、产品和项目所处的环境和上下文， 然后帮助人们做出最佳决策，尽力转向有成效的敏捷。

关于作者

Johanna Rothman与企业一起，帮助他们改善产品研发的管理水平， 最大化管理和技术人员的生产力，提升产品质量。 Johanna是Agile2009大会的zhuxi。 她还是下列书籍的作者。

    《Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects》
    2008 Jolt生产力大奖获奖图书：《项目管理修炼之道》
    《门后的秘密:卓越管理的故事》
    Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

她为Stickyminds.com和Gantthead. com的"extreme project management"撰写专栏文章，还在自己的网站jroth man.com上开了两个博客。她刚刚开始在http:// www.createadaptablelife.com/上撰 写博客。Johanna还是Amplifying Your Effectiveness大会的主持人之一。

查看英文原文：http://www.infoq.com/articles/Accidental-Agilist