内容


Rational Edge

Oz 大陆上的瀑布

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Rational Edge

敬请期待该系列的后续内容。

此内容是该系列的一部分:Rational Edge

敬请期待该系列的后续内容。

illustrationMARVEL 教授:让我们看看您是在乔装旅行中。不,不是那样。您正要去拜访某人。不,我想那也不对。您离家出走了... 您想要见识其它地方--大城市--大山--大海。

DOROTHY:为什么会这样,好像您能够读出我的内心想法1

我们的工作就是改变。作为 IBM 的咨询师,我们有责任引导软件开发实践,以便在提高质量的同时降低时间和成本,并最终提高公司的创新能力,使公司走向成功。在我们和许多客户的交往中,我们有幸遇到了很多有才能的和有奉献精神的人。他们绝大多数的动机很简单,就是做好工作。

但是事实是,那些软件开发部门邀请我们的原因就是有人认识到这些人都需要我们的帮助。作为开发咨询师(按照电影《绿野仙踪》的说法,您可以说我们是一个好巫师),我们的工作是激励和培训这些人用不同的方式做他们的工作,以进行整体上的改善。

作为咨询师,我们经常有那些重复的体验:Rational 的迭代开发的原则确实可以用来改善软件开发工作。但是客户仍然在瀑布方法下面努力奋斗,我们的指导经常会遭到个人或者组织的抵抗,他们信仰瀑布方法。每个与客户的工作就像是在他们的信仰已经发展为他们自己独特的办公室达尔文主义的时候,参观一个新的大陆。2尽管这些信仰会变得混乱,他们也会建立一个限制将来可能性的地盘。“Territorialization” ,由现代哲学家 Gilles Deleuze 引用的词,从字面上来看,是建立“分类、组织和解释世界的一种占统治地位的、保守的方法”的“措辞” 。 3

因此就像 Dorothy 和 Toto 一样,我们咨询师就是被一阵灾难性的旋风卷到新的大陆, 在那里我们的出现自然会导致现状的破坏。在我们拜访的地方,我们会经常导致很熟悉的东西变得陌生,以及很陌生的东西变得熟悉。这个破坏是可以预期的,因为我们带来了新的方法,经常可以瞄向深层问题。因此,我们的工作不仅仅是改变,而且是说服。

本文组织整理了常见的反对意见,这些意见是我们从那些精通瀑布开发的概念和实践的团队收集的。作为咨询师,我们必须首先认可客户工作的方法、客户如何思考,他们如何描述他们的问题。然后,我们用来自我们的 RUP 大陆的新的“措辞”来劝导用户。

“我们知道我们在做什么。”

我们的回答:这可能是真的,但是是否每个人,包括涉众(stakeholder),都知道您们在做什么吗?

迭代开发提供了一个涉众参与的很好的论坛。在开发过程的任何时间,开发组都可以把他们最新的版本给客户看,然后说:“这是最新版本,您对此有什么想法?”

有上千家公司的数十亿美元白白浪费掉,主要是由于这些公司的开发工作在评审时被真正的涉众否决,而否决的原因经常是使用的技术超出了内部业务需要或者外部市场需要 。4 如果您回顾过 Ralph Grabowski 在他的文章“谁会买打过补丁的东西?”中的证据5,您就会看到历史上充满了技术上很稳定,但是在迎合市场和用户方面失败的产品和工具。

一般来说,在“我们”断言“我们知道我们在做什么”的时候,是没有足够的能力来确保成功的。

“相信我们,我们的工作对于迭代开发来说太复杂了。

我们的回答:听起来像是“强有力的 Oz 说过的话。”。让我们拉开帷幕,看看所有这些设想中的复杂性。

帷幕后面经常是什么?在这里,并不是一个人简单地拨动开关或控制杆,而是整个软件开发团队。团队经常坚持他们的过程的“可怕的复杂性”,以此作为阻挡变化的盾牌。管理人员也接受这种想法,变得非常保护的他们管理的团队。尽管对团队来说,把他们复杂的过程归结于他们的项目需求的复杂性似乎是合理的,但这仅仅是一个在黑幕后面为了维护他们原有的业务模式的一个借口而已。

实际上,过程中的复杂性通常是来自设计的不足,而设计的不足则来自于在设计过程中过少的参与。

在 Brian Foote 和 Joseph Yoder 在他们著名的文章 "Big Ball of Mud" 中,对最常见的架构提出了很明显的证据。我们非常熟悉那些“显示出很明显的迹象:没有节制的增长,以及不断重复的临时的修补。”6 这是一种缺乏参与的权宜之计--例如一两个“英雄人物”进行非凡地、经常是神秘地调整,使得系统再次工作。但是这种快速的修补不是大家都理解的架构的一部分,它仅仅能运行直到下一次的崩溃。

架构是为一些特定的目的设计的元素的一种组织形式。它是一种能够简化设计需求的结构,这种结构可以保证系统的行为完全符合现在和将来的目的。但是有时,由于无节制的增长或者人们需求的发展,架构会加入以前没有设计的新的目标。

迭代开发就意味着在每次迭代的最后,系统就可以工作,从而系统行为、架构和设计的规格就可以得到验证。这种对实际工作的验证可以得到广泛的业务方面的关注。而在瀑布模式下,一种为长期架构考虑的简单化设计最后就会变成“仅仅让它工作”。

即使不考虑规格说明的原因,复杂性也能通过广泛参与的需求开发、仔细规划的步骤、在一个成果基础上学习而得到控制,还句话说,就是迭代开发。

拉开帷幕,Toto!

“我们的工作在后台,对最终用户不可见”

我经常问:“那么 iPod 里有什么?”回答经常是“闪存”,“一个微硬盘”或者其它一些技术。然后我解释说,我的答案是我要寻找的是“音乐”7 (和最新的视频)。

这里我们引出的重要概念就是,业务需求规格说明应该描述系统的行为,而不是它的设计。我们经常从客户那里得到类似的反应。他们经常习惯于描述他们要构建的系统的细节,而不是用户如何和系统进行交互。最后我们指导客户如何使用用例和场景进行开发和最终测试。

那些反对这个建议的人一般都没有看到定义或者说明系统行为的原因。这类似于那些内核编码者的虚张声势,"我们做的是后台的逻辑,"或者“我们不做界面”。但是这只能导致技术专家和涉众对事实的苛刻评价的隔离。事实上,他们必须接受那些要付钱买产品的人的看法8

这些是咨询师在面对迭代开发时遇见的最常见的问题。应该让使用瀑布模型的开发团队和涉众习惯于在每次迭代结尾进行工作回顾。

当然,涉众和开发人员也有他们不这么做的原因,可以预料到提出有可能导致项目延迟的意见对个人是有风险的。而在项目结束时则很容易指出错误,因为那是错误已经由其他人实现出来了。

对开发人员来说,展示一个没有完成的项目也是有风险的。对于已经完成的冻结的规格说明很容易解释他们工作的情形,然后他们就会在项目结束时给涉众指出任何差异的原因--显然很清楚,涉众在某个时候改变了他们的想法,也就是说已经冻结的规格说明是不完全正确地。

这里发生的事情是,开发人员和涉众都没有意识到,他们都是人,有可能犯错误。这有可能导致设计走向错误的方向,如果太晚改正错误的话将导致高额的费用。

有太多很好构思的概念被毫无道理的私下的限制所妥协。并且对“强有力的”技术的敬畏也将破坏把拥有很好的产品应用到新的市场的勇气。

“我们的工作不是面向对象的,因此我们不能使用迭代开发技术”

我们的回答是:我们很恭敬地建议您考虑以下两点:

第一,迭代开发--包括它的想法、行为、建模、构建、测试和适合的计划--已经被应用在其他工程领域几个世纪了,包括电子、化学、机械等领域。在那些领域,标准化制造的部件、子系统集成和反作用,已经成为基准测试。在进行更进一步的完整系统的开发前,这些早期迭代测试的结果用来刻画系统的总体特性。这些物理系统的测试依赖于对作用力、质量和能量守恒定律的标准设计实践。后面的迭代更加促进了构建子系统集成,是实际系统或模型则依赖于标准单元的个数。在后面的集成中进行更多的测试。

迭代开发--换句话说,从实践中学习"--有着数千年的传统。它在我们社会的开发中的存在是如此的普遍,以致于我们把它作为物理世界的快速的可预期的组件。现在到了软件工业追上它的时候了。

第二:每种语言,即使是机器码,都有一些组件部分,可以按照商业和技术的目标进行合理的组织和安排,这与第一点相关。

“我们不能花时间学习新的方法”

我们的回答是:那么您们现在一般在项目上花多少时间?

一个很奇怪的事实是,那些经常表示他们这个问题的人却没有时间度量和客观地回顾一下他们自己的时间支出。

这个论点类似于一句古话,“我们忙着砍树,没时间磨斧子。”这句话很经常用来表达那些真实世界中必须主张的事实。我经常听到人们引用林肯的格言:“给我六小时砍倒一棵树,我会花头一个小时磨锋利我的斧头。”

迭代开发的目的是节约项目计划、开发以及重新计划正确的方法的时间和成本--这一点已经由那些已经做过项目时间花费的测量所证明。

“我们需要准确地了解和规划我们从开始就要做的内容。”

我们的回答是:是的,我们很也愿意能这么做。

我注意到很多公司,他们执著于过度细致的计划,经常最后用这样的表达:“它很难起到好的帮助”,然后把责任放在那些显然没有能力按照计划执行的人的身上。更进一步的鼓励有时来自一句咒语“Plan the work -- work the plan.”。这句回文也赞美了没有错误的计划的优点,但是人们却不能做到没有错误。这经常不是由于缺乏才能,而是当面对上千的未知项时人们没有能力精确地计划细节。

Peter Sandman9,是一个风险顾问,他指出感觉到的风险不同于实际的风险。人们对风险的感觉主要取决于我们觉得我们对事情控制的程度。因此,尽管因疯牛病死的人很少,但人们它的恐惧远甚于更常见的在自家厨房里感染细菌而死亡的危险。10这也适用于飞机和开车的对比,以及迭代开发和瀑布开发的对比。

对于详尽的、完全的、固定的规格说明和计划--也就是瀑布开发--的信任能够幸存的主要原因是,它表面上看能够控制一切,这就创建了一个它能够减轻所有风险的幻想。这种每件事情都能在前面做好细节计划的想法称为乐观主义,但这种态度显示了真正的傲慢--这种态度认为软件开发中的所有变化都能够按照详细的、一步一步的计划得到管理和控制。

项目面对的最大的风险不是计划失败,而是调整计划失败。新需求的成功构建真正反馈出在构建过程期间哪些东西工作,哪些不工作。计划改变的程度指示出我们在项目开始阶段不知道的内容的深度。事实上,好的计划幸免于难的原因是他们在如何改变的行动准则方面打好了基础,而不是机械化的执行。

美国宪法11 是一个很好的计划的例子,它的基础是在人们的需要改变时它允许灵活性。

“我们没有时间进行这所有的迭代”

我们的回答是:这个问题不是开发时间,而是从项目开始到交付的全部时间。在针对市场的努力的例子中,这个时间就意味着利益。

每个项目都把代码分为片段开发。因为开发人员写代码,他们在代码提交前进行测试。在瀑布开发中,设计人员和开发人员试图达到他们期望的行为,就是代码满足需求规格说明。这一般包括“冻结”规格说明的借口,它有可能是不完整的或者是有错误的。因此开发人员在没有得到指定规格的人的反馈情况下工作得越久,他们就会做越多的“让它工作”的解释,从而使它们远离规格说明,到达不希望到达的地方。不久以后,有效的架构设计就退化为“仅仅让他运行”,开发人员就变得不受控制了。

在迭代开发中,在开发代码和测试片段时,他们的策略是进行广泛的检验,以确认架构的有效性以及与涉众需求的一致性。结果就是,制定出更现实的计划。这就保证规格说明的实际性,并提供了更加符合涉众需求的实际的指导和现实的架构。

时间是问题的根本--不是让系统能运行的时间,而是您让正确的系统能运行的时间。

“我们现在有所有的东西。我们已经文档化了我们的新过程。”

我们的回答是:很好,那么他们出现了什么问题,他们是如何出现问题的?

在这里,显然有个暗示就是,有任何文档化的过程比一点也没有要好。但不幸的是,这不是真的。正如对完全规格化的瀑布开发规格说明的信任一样,一个人可以全部文档化一个导致拙劣开发的过程,正如可以文档化一个能够改进开发的过程一样。文档化正确的过程包括定位问题更甚于缺乏文档。

为了最好地理解和改正制造中的问题,人们需要检查废品堆。在拙劣的设计中,人们需要检查垃圾桶。在有个拙劣的过程时,人们需要检查返工的类型和数量。让我们看一下下面的三个例子:

  • 如果系统预期的行为一直发生变化,过程改进需要着眼于更好地建立市场和业务需求的建立工作方面。
  • 换句话说,如果行为定义得很好,但是代码仍然一直返工,则过程需要着眼于改进设计和架构。
  • 最后,如果规格说明是一系列业务、行为和设计问题的混合,那么过程应该着眼于更好地分离责任。

对每个客户来说,实际上在某个地方都有个过程。它可能是非正式的、没有文档化的、以及有问题的,但是它总是包含了给定组织某种程度上的工作单元。对于那些拙劣的方法,不管他们是否文档化,都会把过程带往很难回头的道路,并有将阻止将来试图改革的充分的理由。

因此,迭代开发的经验也可以用于迭代过程改进。没有让过程一次就很好运转的规格说明。人们必须在实践中学习,再进一步让过程工作的更好。

经常,他们在第一时间宣称他们使用 RUP,然后他们转向使用瀑布模型的方法来安装“新的过程”。过程的采用,就像构建系统一样,自己也需要一个迭代的过程。人们开始建立过程的业务目标的前景,建立期望的实践或者行为,然后逐渐实现那些技术、工具,以及需要的学习和培训。

因此,确立一个有效的过程需要多长时间?只要它能够稳定您的业务目标,以及可以用一系列技术、培训等实现,不要等待了,马上开始。

必须要指出的是,一个人能够文档化一个好的过程或者差的过程。但是象 Sandman 先生的警告一样,一个很好地文档化的过程仅仅是表面上可以控制,也仅仅是觉得可以减少风险。这只是一个幻想。应该从正确的远景和实践开始,在实践中学习过程。工作的文档应该基于您达到的正面的结果。

总结

正如开始提到的,作为咨询师,我们遇见过很多公司和一些非常有才能的人。但是他们中最好的是那些能够逐步超越他们的办公室规范,客观地回顾他们自己的结果,使用这些客观事实来提高他们对将来改进的信心。

最后,对您的项目最有效的指导就是对您同一个项目的客观地评估的体验。毕竟在收集最有效的经验方面,“没有比家更好的地方了。”

注释

1The Wizard Of Oz -- 最初由 L. Frank Baum 所作。由 Noel Langley,Florence Ryerson,以及 Edgar Allen Woolf 所作的 1939 电影脚本。

2“办公室进化论”是“适者生存”的官方形式。这里应用于那些开发想法,它们已经获得了可信性,通过办公室政治的主观选择过程来生存,而不是基于对他们的度量绩效的客观分析来生存。

3 Ronald Bogue Deleuze's Wake: Tributes and Tributaries。State University of New York Press,2004。

4 对于那些开发面向市场产品和服务的项目,市场所扮演的角色对于理解驱动产品特性的外部市场需要来说,是极为重要的。对于那些开发内部基础设施自动化的项目,这项角色通常被分派给内部业务分析师。

5http://www.marketingvp.com/download/whois.pdf -- 由 Ralph Grabowski 所作

6 Brian Foote 和 Joseph Yoder,"Big Ball of Mud"。计算机科学系,Urbana-Champaign 的伊利诺斯大学,http://www.laputan.org/mud/

7 一个从 I 属性到亲密朋友的交换,Richard Morley,可编程逻辑控制器的发明者。参见 http://www.barn.org/

8 来自亚当·斯密,国富论,1776“According therefore, as this produce, or what is purchased with it, bears a greater or smaller proportion to the number of those who are to consume it, the nation will be better or worse supplied with all the necessaries and conveniences for which it has occasion.”

9http://www.psandman.com/

10 Peter M. Sandman "The Mad Cow Crisis: Health and the Public Good"。Journal of Health Psychology,2000 年 1 月,Vol. 5。

11http://www.nccs.net/constitution/us_constitution.html


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=248784
ArticleTitle=Rational Edge: Oz 大陆上的瀑布
publish-date=08152007