BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

精益和敏捷:完美的结合还是冲突中的孽缘?

| 作者 Dave West 关注 0 他的粉丝 ,译者 王菲菲 关注 0 他的粉丝 发布于 2009年9月16日. 估计阅读时间: 11 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

毫无疑问,我正在试图煽动大家。在某些方面,我对这个话题的后半段是确信无疑的。

在软件开发领域,LeanAgile似乎已经成为一个单词,提出这样的问题或许会让人感到很惊讶。所以先陈述一些附加说明。

我认识Mary和Tom Poppendieck夫妇十几年了。我们是朋友,同时也是世界上最大的面向对象用户组的同事,都在明尼阿波利斯。Tom是我在圣托马斯大学(位于明尼苏达州,维尔京群岛,不是太糟糕的寒冷气候)的学生,他是我出版的有关面向对象的书籍的技术评论家之一。

除了无法忍受他们的书比我的更热销外,我是由衷地敬重和钦佩他们的内容和思想。他们的书是专业领域的独鳌,所陈述的内容理应被世界各地的软件开发者(包括敏捷方法论开发者)学习和应用。

那倒底是怎样的问题呢?

简单来说,精益和敏捷的基础是根本不同的世界观,因此也毋庸置疑地在一些关键论点上呈对立势态。在接下来的段落里我会尽量展现他们的相反世界观,阐明冲突,然后给出如何尽可能和解的建议。

精益世界观 = 生产

一些出自精益软件开发(Lean Software Development, An Agile Toolkit)的引言介绍了我的断言,精益的世界观是一种生产世界观。

Jim Highsmith的前言,“Mary和Tom Poppendieck把精益工业实践运用到了一个新的层面,他们告诉我们怎样在软件开发里使用精益理论。” 以及,“…为将精益技术从工业环境引向软件开发用提供了丰富的信息资源。”

摘自Ken Schwaber的前言的一些字眼和语段,“工业过程控制”, “敏捷过程”, “Mary在制造业和产品研发的背景。” 以及在22页的介绍中, “虽然认识到误用隐喻的危害,但我们相信软件研发与产品开发是类似的,软件开发行业可以从检测产品开发方案对产品开发过程的改进中的变革来学习更多的经验。”

生产和流程之类的词汇,以及隐喻贯穿于整本书的纹理中。虽然有对19世纪生产思想的明确否决(比如Taylorism),但是同样有也对开明生产模型的完全采纳(比如丰田生产模式)。

具体的敏捷实践是从对生产的贡献角度评估而来的。如果某个特定的敏捷实践被认为与精益生产过程模型相冲突,那么这种实践必须予以修改或取消。

精益并不完全是关于过程的。例如,下面是精益的七项基本原则,

  • 消除浪费
  • 增强学习
  • 尽可能迟缓做决策
  • 尽可能迅速给交付
  • 增强团队
  • 构建完善
  • 纵观全局

只有第一个是毫不含糊地相系于流程,相系于生产。

这些基本原则暗示了在精益的其他方面超越生产世界观的方式。我们会在本文的最后部分回到对这个话题的的阐述上。

敏捷世界观 = 理论构建

我非常荣幸能够和很多的敏捷理论的发明者和倡导者共同参与和讨论。我曾经和圈内人士讨论关于敏捷的哲学基础,并且发现它们的一致性。但只有Alistair Cockburn,把这种思想记载到了书中。

在附录B,227页到239页,Cockburn的敏捷软件开发一书中包含了一篇Peter Naur在1985年写的文章,题为“编程理论构建。”

Naur认为把开发软件的行为看成生产程序和其他文件的行为是错误的。他举出几个例子来论证经验数据不匹配生产模型的发展模式,包括文档的草草了断,以及是否有一些形式可以向那些没有参与初始阶段创作的成员转达对项目计划的理解,而这体现了规格化的欠缺。

理论构建,Ala Naur,得益于个人和集体的努力:

  • 理解世界
  • 理解软件如何在世界中形成,又如何与世界相整合
  • 理解软件的实质以及如何最好地阐明这个本质
  • 理解你是否已经得到前三个认知权

观测活动和理论构建包括叙述大量的故事(Story),探索思想,尝试更多途径,测试你的理解,通过唤起认知来扩大对自己的物理内存,并迭代地完成对这些事情的增量。

看上去非常像一个敏捷环境,但是一点没有与生产环境的相似之处。

除了引用了Ryle的关于理论持有的思想,Naur并没有明确制定理论构建的基本原则。如果他有制定的话,那肯定是和XP的简单,交流,勇气和反馈的价值观一致的。

世界观的冲突

精益把软件开发看成一种从概念到产品的过程。精益想通过完全不同于传统概念优化的方式和价值观来提升整个过程。

敏捷把软件开发看成一个构建协商一致的概念理论的过程,同时把所得的产物看成一个副产品,只是对这个理论的一种诠释。

由于两种理论的基本世界观是完全不同的,有冲突自然在所难免。而这些冲突体现在工具和实践的层面中。

例如,产品backlog。

敏捷的前提是基于用户故事的模块化思想。用户故事就是“客户希望系统可以去实现的”。(Kent Beck)

用户故事来自于用户、别名、客户或者业务等。故事的产生要远远快于他们的能够被执行,特别是在一个大型项目的初始阶段,或者当目标是“敏捷化”为整个企业的时候。

几乎所有的敏捷项目都会建立一个产品backlog,一系列的故事会被付诸实施。这一系列的故事可能会非常大,我曾经看到在一些项目里,产品backlog有数百个故事。

精益把产品backlog看成是目录清单或者是废物。Mary Poppendieck建议产品backlog应该被消除或者削减尺寸使其与团队集体速度相吻合。

敏捷把产品backlog看成新兴理论的快照视图。即使这种快照试图会以贴满墙壁的故事卡片来展现,它也仍然不是目录清单!这些卡片就像外部存储卡一样,而每一块卡片都可以唤起对于事件如何处理的详细对话和理解。

当产品backlog足够大,并且其成分中有大量churn时,敏捷化更能显示它的作用。Churn来自于一系列的对话,故事的实质,故事的优先级,开发者对尚未理解的故事的反馈,那些与预期想象不同或易或难的故事,需要重新定义影响因素来帮助开发的故事,或者用户接受故事完成的反馈。

最后,churn减少了,产品backlog也会逐渐稳定。新故事的加入只会被视为点滴,而故事的优先权也只是象征性地调整一下。单从这一点看来,也许更容易把产品backlog看成是目录清单。但不管怎样,backlog仍然是理论的物理表现。它提供了所有正在进行的研发工作的精髓内容。

Backlog为软件研发提供的关键性支持等同于电影制作的连贯性编辑和技术策划。当注意力都集中在单一场景中,很容易忘了主角在前一场景最后一帧中穿的蓝色衬衫,而不是红色的。你会忘了在太空中听不到爆炸声。类似的错误也会在故事贯彻执行中发生,而产品backlog提供了连贯性以及对精髓误解的更正。

在我所接触过的所有敏捷化项目中,我一直坚持以类似于信息极速跟踪的故事卡片信息墙的方式来使用产品backlog。故事即时聚焦和整体产品backlog的故事的简单检查被安排为每天的基本任务。在每个案例规划和回溯中,产品backlog会被重新过目和具体讨论,从而达到更新每个成员对合成理论状态的了解。

这个例子的关键点在于,你的世界观必然会丰富你对事件的解释。一个简单的产物,比如产品backlog,基于你的世界观的层次,会展现出不同的现实因素、目标、价值和功能等。在这种情况下,基于“生产世界观”来做出解释只会对敏捷软件开发不利。

我知道这只是很一般的论证,并且只用了一个单一的例子来论证。但这只是空间有限的原因,而非缺乏实例。

和解

婚姻是幸福的,除了一些误解,争执和相互起冲突的目标。精益和敏捷作为这样美妙的一对,这段姻缘会持久吗?

当然可以,但是有三个前提忠告。一个是给精益的,一个是给敏捷的,最后一个是给双方的。

精益需要拿掉“生产理论的有色眼镜”,从包含七个精益基本原则的全盘角度去审视敏捷和敏捷开发过程。如果不单单是从“消除浪费”的基本原则去评估产品backlog,那么backlog在“增强学习,延缓决策,增强团队,构建完善,纵观全局”等方面的贡献还是相当明显的。

当然了,敏捷从业者也必须做同样的改变。当你听到敏捷从业者谈论他们所做的事情-他们的词汇,暗喻,贯彻实施,无不反映了敏捷是生产的替代模式的观点。但问问关于Naur和理论构建的敏捷话题,却只会得到一片空白。

精益和敏捷都应该杜绝使用纯文字或者死记硬背的方式,工具和做法。工具和做法只不过是对价值,原则和哲学的表达。而他们不是唯一可能的表达方式,也不可能是最好的一种。 除非能够理解为什么要这么做,这些工具倒底是什么,否则任何一方都不能够实现他们各自创始人的关于“使用,适应和超越”的告诫。

AgiLean(类似于tabloids, bennfier, brangelina)属于一见钟情的案例。他们的蜜月就是用新方式来合并思想的激动人心的时刻。但是那个时代已经过去。如果这段结合想要持久,双方需要超越彼此表层的吸引-因为如果只是停留在那个层面上,冲突再所难免。

查看英文原文:Lean and Agile: Marriage Made in Heaven or Oxymoron?


译者简介:王菲菲,朱拉隆功大学计算机科学与技术硕士,现就职于某外资IT咨询公司。主要从事银行电信业商业智能和数据挖掘分析的咨询工作。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

"完美的结合"可以翻译成“天作之合” by Jacky Li

如题。

精益把产品backlog看成是目录清单或者是废物? by 起步 停车

精益把产品backlog看成是目录清单或者是废物? 从消除浪费的目的来看,backlog真的会造成浪费吗?
--我的理解:1)临近开发的backlog的粒度应该是比较详细的,否则如何进行开发工作呢?2)未来(也许1,2个月以后)的需求可以粗略一些。推迟一些对细节的投入。3)过度的开发backlog会造成浪费。

取其所长,多实践 by cao Alex

敏捷和精益各有各的优势在各自的领域。如作者所说杜绝用纯文字或死记硬背。多实践才能更深入的体会两者。我个人倾向两者结合起来使用。

Re: 取其所长,多实践 by Fan Jun

两者应该不冲突吧,敏捷的很多理念也是来自于精益。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT