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

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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2011 年 3 月 10 日 00:00 1676
用户头像

发布了 479 篇内容, 共 121.9 次阅读, 收获喜欢 21 次。

关注

评论

发布
暂无评论
发现更多内容

Element-UI实战系列:Tree组件的几种使用场景

brave heart

vue.js 前端 Elemen

每周学习总结-架构师培训一期

Damon

程序员的晚餐 | 6 月 5 日 爆炒鱿鱼

清远

美食

【ARTS打卡】Week02

Rex

架构师训练营-命题作业1

水边

极客大学架构师训练营

架构师训练营-每周学习总结1

水边

极客大学架构师训练营

Flink源码分析之Flink 自定义source、sink 是如何起作用的

shengjk1

flink flink源码 flink源码分析 flink自定义source flink自定义sink

如何用一台 MacBook 创造高额年化收益 | ETH2.0 Staking 教程

陈东泽 EuryChen

区块链 Ethereum

软件架构第一章总结

itrickzhang

Java 25周年:波澜壮阔的25年

北风

「Java 25周年」

食堂就餐卡系统设计

饶军

不可不知的 7 个 JDK 命令

武培轩

Java 程序员 jdk 后端 JVM

Flink源码分析之-如何保存 offset

shengjk1

Flink源码分析之Flink是如何kafka读取数据的

shengjk1

flink flink 消费 kafka flink源码分析 flink消费kafka源码解析

Flink源码分析之FlinkConsumer是如何保证一个partition对应一个thread的

shengjk1

flink flink 消费 kafka 实时计算 flink源码分析

架构师训练营第一周作业

芒夏

极客大学架构师训练营

食堂就餐卡系统架构设计

Karl

dnsmasq-域名访问及解析缓存

一周思进

《OKR工作法》读书笔记

大饼土博

读书笔记 管理 OKR

repo 导出本地 git tag 给他人

zqb-all

git

因为 MongoDB 没入门,我丢了一份实习工作

沉默王二

mongodb

Flink源码分析之Flink startupMode是如何起作用的

shengjk1

flink flink 消费 kafak 实时计算 flink源码 flink源码分析

极客时间-架构师培训-1期作业

Damon

程序员摆地摊?你别痴心妄想了,还不如当「在地青年」呢

非著名程序员

程序员 提升认知 职业规划 认知提升

架构师训练营第一周学习总结

王鑫龙

极客大学架构师训练营

UML练习1 食堂就餐卡系统设计「架构师训练营」

Young

【架构师训练营-作业-1】食堂就餐卡系统设计

小动物

系统设计 极客大学架构师训练营 作业

程序员的晚餐 | 6 月 4 日 最好吃的土豆

清远

利其器

宋胖子

IDEA

[ARTS打卡] week 02

Mau

ARTS 打卡计划

人人都是产品经理

二鱼先生

产品经理 个人品牌 职场成长 产品思维

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