偶然成为敏捷人士:个人回望《敏捷宣言》发布十年

阅读数:1334 2011 年 3 月 10 日

话题:敏捷社区语言 & 开发架构文化 & 方法

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

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

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

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

回到 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 大会的主席。 她还是下列书籍的作者。

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

查看英文原文:The Accidental Agilist: A Personal Look Back at 10 Years of the Agile Manifesto


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