内容


改造你的软件开发能力:一种适应组织变化的框架

Comments

illustration在过去的几年中,软件开发组织中的领导者们开始意识到将公共的过程、技巧和工具标准化所带来的好处。我们这些在IBM Rational服务团队工作的人目睹了从采用项目级别的IBM Rational 产品到采用大规模标准化的IBM Rational 软件开发平台。这个大规模的应用代表了在新技术、相关工具和软件开发团队传承的技能上的重大投资。因此,组织需要相当的关注来确定这样一个成功的投资。

大规模标准化给CIO和开发领导者们提出了许多问题。这些组织如何处理这些问题?例如,如何动用3000名开发者获得一个标准化的开发平台?如何将正在进行的与业务有分歧的项目带给开发团队的影响减到最小?

在这篇文章中,我们将会陈述使用IBM Rational软件开发平台如何帮助领导者们一次性的完成从项目实施向公司标准化的转变的活动、意见和技术的架构。我们所期望的读者,是那些具有这种远景和意愿,同时具有影响力,能够在组织中去推动改变的人。这些人可能是改革领导者或是其他一些类似的人,他们对实施过程改进、配置工具和提高项目队伍的技能有着非常丰富的经验。

我们称这种架构为“开发组织转变构架”或是“DOT构架”。它包含很多细节,但为了解释基本的概念,我们提供了一个高层次的总体看法,将在架构中的重点领域去钻研细节和提供具体实例的工作留给以后的文章。1

本文呈现了对IBM Rational在软件开发中的方法的了解,在开发中提高生产力和减少软件产品上市时间的基本优势。理想情况下,在观察大型组织的变化之前,应该先具备一些在比较小的规模下使用IBM Rational产品和观念的经验,这样能够第一手的看到这些优势。又或者,推荐给您的组织一个更高层次的统一化作为策略上的回顾,或者是一个有经验的第三团队。

我们将会关注一些组织改变带来的挑战,介绍一些方法通过Kotter架构去解决一些事务,并且呈现出支持的DOT架构。

组织的变化带来的挑战

你可曾疲于组织中大量的主动改进?是否成功呢?你遇到了什么挑战?

这是我们在组织范围内首次展示时看到的一些普遍问题:

  • 无意义的紧急变化:通常,强烈感到变化需要是中层的管理人员。没有一个高级管理委员会要寻求变化,培训本身也接受这种差不多就可以的表现方式。因此,为什么变化是必需的呢?另外,以前的成功使得你和你的团队成为工作中采用以前方法的牺牲品。
  • 内部的发起人很难说清楚贯穿组织的变化的价值:在许多时候,变化的需求是可以被意识到的,但是团队努力希望把一个引人注目的商业案例和高价值的变化需求联系在一起。
  • 将活动分得过细,会导致丧失整体:在许多组织中,注意力一开始可能集中在一个看起来孤立的痛苦地方,而不是去理解整体,然后将整体分解成易于管理的相互关联的领域。有很多原因,使得部署计划并不是把注意力都集中在项目的成功之上。例如,项目中可能没有专门的领域专家,理想的情况是,团队中有人确实对过程和工具有很好的理解,并且有兴趣,这样可能会推动软件研发的成功。但是通常,这个人一般是来自IBM Rational队伍或是其他顾问团体的顾问。确实,我们能够提供帮助,但是在你们的组织中的每个层次的人员,也需要都对整体描述有一个清晰地理解。
  • 过多的过程过快的实施:过程越多,并不能自动地带来更大的成功。有时,对一个新过程的过分热情可能导致软件开发工具和/或过程过于定制化。事实上,过程架构,例如IBM Rational 统一过程®或是RUP®,应该被仔细的评估以使它恰好能在一定程度上满足你的组织能力和改进需要。组织通常依赖于英勇的个人来完成工作,这种方法已经成为了培训中的一部分。
  • 不交流成功经验:当团队成功地完成了实践,通常成功的因素并不与更大型的组织分享,这就导致其他的团队在可能会克服的挑战中依然挣扎或是最终失败。如果不交流成功经验,那么继续支持和投资将会变得困难。

DOT架构考虑了这些挑战,它利用活动或指导方针来设计去克服这些困难。

总体来说,不论什么规模的组织开始采用现代软件开发技术,它都需要适应许多的变化,如下:

  • 在个人或是项目级别,新的技能需要被掌握,新的角色需要被定义,目前的角色需要被改变。,个人经历这些变化可能会暂时感到不太舒服,一直到他们开始飞速进步这种感觉就会消失。
  • 在项目级别,新的方法可能被需要,例如,从打印的、广播的文档向电子占主导地位的模型的变迁。从瀑布方法向迭代方法和阶段的转变需要项目组织和理解的新模式。
  • 当你提升了组织的级别,另外一些挑战又出现了。按照反映应用的架构来构建组织结构是有意义的,而按据职能领域没有意义。项目经理必须从不同的侧面与员工一起工作。在项目的早期阶段,建立了应用架构,而只有很少的职工参与了这一阶段。只有当这部分完成了其余的员工才会加入。测试贯彻整个生命周期。为了适应员工级别和工作量的平衡的浮动,项目和组织的领导形式必须随之发生改变。基本上,我们应该精=将焦点放到过程中的那些切实的产物,例如通过测试的执行程序,而不是文档产物。

上面的列表并不够详尽。但是它却暗示了需要变化的类型。很明显,要想利用IBM Rational的解决方法并且发现它的全部优点,必须改变组织本身。而改进一个组织需要计划和领导能力。

Kotter关于组织转型的八个步骤

这里有许多模型可以帮助我们引导组织的改变,包括软件项目协会的IDEAL模型2,和John Kotter的八个步骤3。这些模型之间有非常多的相似性,但是Kotter是最为著名的,也是我将在本文中介绍的。

Kotter的模型是基于广泛的寻找哪种行为是成功进行变化组织的特征的研究。这个模型我们使用过许多次。Kotter是商业领导的专家,他帮助许多组织成功地适应变化。他说组织变化项目典型的失败是由于人们失利于改变他们潜在的行为。他强调领导能力是实现变化和识别这八个步骤的关键,通过这八个步骤每个组织都能够实现他们的目标。

本文中解释的DOT架构与如下简要列出的八个步骤是一致的。我们将在讨论架构每个领域的时候再详细的讨论它们。

  1. 建立紧迫意识。试问:你为什么做这个?什么是紧迫的?这些简单的问题能够真正的帮助你去意识您的组织是多么的严谨。如果不紧急,您在冒险上浪费时间,将会得不到适当的支持——最初是资源和投资。
  2. 创建指导上的联合。您需要确定您组织中的那些将会帮助变化产生的人。这需要和管理团队中的重要任务、领域中的专家以及那些在大型组织中有信誉的人相结合。
  3. 开发远景和策略。您需要为您的变化过程创建一个清晰明了的远景和一个从现在起步的策略。
  4. 沟通变化的远景。在管理层的会议简单的清晰化一个远景是不够的,还需要记录下来并通过组织与管理团队进行交流。
  5. 授权全面行为。要想使变化成功,团队就需要被赋予权力去实施相应的变化,移除各种阻碍。奖励和认同感是激励人们在新方法中工作的重要动机。
  6. 产生短期的胜利。想要获得和维持支持,达到一些短期的目标是非常重要的,这样在过程中才能建立自信。这些成果需要相互交流。
  7. 巩固收获,创造出更多变化。您需要巩固正在运行的工作,并且延伸它使之能够为组织带来更多的能力上的改进。
  8. 在培训中稳固新的方法。最终,您希望在您的组织培训中稳固这些新的技术。

当您浏览每一个步骤是,我们推荐您通过对照Kotter列出的这些元素来评估您执行变化项目的能力。思考之前的努力,把做了什么、没有做什么与这些条目相对照。

DOT架构概念概述

DOT架构包含了许多等级的变化。

Figure 1: Each wave introduces to the organization a number of new capabilities that lead to results which, in turn, contribute to one or more of the business goals of the organization

Figure 1: Each wave introduces to the organization a number of new capabilities that lead to results which, in turn, contribute to one or more of the business goals of the organization

图1:每个波动都带给组织许多新的能够为组织实现一个或多个商业目标的能力。

在第一层中,正如图1中所阐释的,您正在关注一个组织的变化。您需要理解组织现在的处境,以及它在未来的远景。一次实现这些远景是不可能的,但是路标——一系列变化将会被实现——能够确定您将到达的地方。我们将这些序列表示成变化的波动,每一个代表了一个或多个变化开端。每个波动都带给组织许多新的能够为组织实现一个或多个商业目标的能力。一旦第一个波动完成,第二个变化波动就到来并附加了更多新的能力和成效。

在变化的第二层,您在研究一个具体的变化开端。图2描述了在组织中驱动执行一个变化开端的阶段。

Figure 2: Each wave can be represented as a change initiative that introduces a set of software development capabilities that get established over time within the organization.

Figure 2: Each wave can be represented as a change initiative that introduces a set of software development capabilities that get established over time within the organization.

图2:每个波动都代表了一个带来一系列在组织中通过一段时间能够建立起来的软件开发能力的变化开端。这里用蓝色标出的时间说明了一个项目新能力的引入的最初活动,并且对以后项目的这些新能力作了更为广泛的的首次展示,直到最好的实践成为组织培训的一部分——例如BAU。

每个变化开端都为组织带来了一个或多个软件开发能力,例如,获取需求的能力,在开发项目的整个生命周期中随着变化的管理能力。这些被引进的能力需要必需的进程,技能的发展和工具的支持。每一个开端,图2中的蓝色时间线显示的,每个执行部分被分为四个阶段。在阶段1中,您依照从开端获得的需求确定范围,定义商业用例和高层计划、成效。在阶段2中,这些能力被一个或两个不同的项目所控制。在成功的基础上,最好的实践都被适当的收获和打包。在第3阶段,为了要证明这个方法,打好的包要通过展开加入其他的项目的测试。在最后的第4阶段,在成功的基础上,您把这些能力再扩展到更多的团队和项目,在更广阔的范围中,直到成为通常的商务(BAU)。

这意味着您经常和越来越多的开发项目一起工作,新能力变得易于理解和完美是每个人都希望的更高级别的成功。这是第三个层次的变化,与开放项目一同工作。

图3显示了DOT架构的整体图。

Figure 3: The complete DOT Framework, showing that each wave of change introduces new capabilities, which are implemented in a pilot project, then rolled out to subsequent development projects until the capabilities are part of the organizational culture.

Figure 3: The complete DOT Framework, showing that each wave of change introduces new capabilities, which are implemented in a pilot project, then rolled out to subsequent development projects until the capabilities are part of the organizational culture.

图3:整体DOT架构,显示出每个变化的波动都引入了新的能力,这些能力首先在试验项目中被执行,然后在接下来的开发项目中展开指导改能力变成组织培训的一部分。

如同上面所描述的一样,DOT架构在组织的三个层次上支配着变化:

  • 层次1:确定您所追寻的整体组织变化,该变化受变化波动的驱动。每个波动都导致具体商业成果的实现。
  • 层次2:确定每个波动的具体变化开端。这些变化开端依照阶段和里程碑运行,这有助于我们控制变化的风险。清晰的、确定的成果显示了开端的优点。每个变化开端应当通过建立新的软件开发能力来独立的表现价值。一旦一个变化开端成功地被采纳,并且顺利变成“通常的业务”方法,下一个变化开端或是波动就可以开始了。
  • 层次3:确定具体的软件开发项目可以帮助您执行与变化开端有关的软件开发能力。起初,您可能影响一个或是两个项目去提炼范围和开始建立工具架构。通常来说,一个项目是不够的,但是不同类型的项目可能需要不同的试验,例如,主机和分布式的。另外的项目可以帮助我们稳定工具架构,证明被打包能力可以被延展得更加广泛。在这个阶段,您将会看到许多中心化的需要被阐明的活动,例如,确定和支持中心的基础架构。注意,在这篇文章中,我们检验一个项目执行是作为一个执行变化开端的子集。然而,项目的执行可以跟在独立练习之后,并且为了证明一个新的方法,通常被放在组织开始的第一步。

应当清楚的是,这里描述的DOT架构并不代表一个适合所有型号的方法。有些组织可能只能应对项目级别的变化,有的面对更广泛的第2层的开端,其他的可以应对组织级别上的变化。Kotter的八个步骤可以被应用到所有这些级别上,并且同时在不同的级别上。把这些分解成可以管理的小部分同样允许投资侧面上随意的分解点。

将DOT架构概念转化为实际的步骤

现在,对于每一个级别上的变化,让我们来检验一下开发组织需要在很大范围内采纳IBM Rational解决方法的阶段、目标和活动。正如前面提到的,一些组织无法接受用到前面部分提到的全部三个级别的整体的组织变化。但是我们还是整体的介绍DOT架构。

活动依照变化被分成许多层次。整体架构可以被用来驱动组织的变化,或是将一些适当的层次提取出来,这种情况下有一些具体的技术能够帮助你来完成。每个活动都有一个接口来连接Kotter的架构,因此您可以看到是什么导致了您的变化项目。

列出的这些活动都是相当积极的。您的具体情况将毫无疑问的要求您增加注释和标注。在您前进的过程中,关注哪些做好的需要被约定,哪些依然需要重点关注,哪些其他相关的部分可能会工作。给工作添加注释使得您可以在心里做,也可以了解哪里需要来自IBM Rational顾问或是其他顾问团对的外界的帮助。

这里的目的是给您提供一个可以被剪裁的、被用来作为讨论帮助的架构。每个情况都有所不同,因此您需要添加一些具体的活动。4

当你浏览这个架构时,你会注意到它不仅把焦点放在技术活动上。变化的一个很大的方面是为了取得人们的信任,因此您会看到许多活动都是在组织内帮助人们投入到提升他们的技能,影响他们,交流、维持和提高支持。这些人的关注点是在任何类型的大型变化上都是一个重要导致成功的因素。

现在我们要对每个级别的变化做一个更加细致的回顾。在每个层次中我们都能看到适用的Kotter发展进程、阶段、目标和可用的活动与技术。同时,把每层的变化和Kotter的理论联系起来非常有用,因为尽管已经有许多定义好的计划,每个发展阶段不断的需要整个生命周期支持和援助。那些对RUP富有经验的人,您可以假想将Kotter的发展进程放在RUP图表的上方:当你在生命周期的变化种实现发展时,每个部分都是可用的,但是他在您发展的时候更强调了变化。

变化的第一个层次:确定组织变化计划的内容

在这个准备阶段,您开始确定高级别的变化计划。起初,再Kotter的发展进程中有三个关键的步骤给予需要关注:

  1. 紧迫感。您,特别是您的团队需要了解您的组织在制定一项变化的时候是非常谨慎的,并且将其付诸实践是很紧迫的。没有紧迫感,变化计划很快就会失败。在我们的经验中,组织经常意识到他们需要一些东西,但是又不能总是清楚的指出紧迫性。您需要帮助他们确定这种紧迫性。
  2. 指导联合。这需要立刻去建立,只有这样人们才能指导相应的变化。这需要人们拥有岗位上的相应的权利,广泛的专业技术和高度的信任感。那些在以前的经验中成功进行变化计划的人应当被纳入都组中来。这个团队应当包括领导和管理技能。一旦成立了团队,就需要建立信任和找到一个共同的目标。
  3. 开发远景和策略。为了帮助将注意力集中在变化计划的对象和背景原因上,策略或是路标在组织中应当被分享。DOT架构的第一步开始抓住Kotter的原理。

目标:创建变化时机,理解当前形势和未来远景

在变化的第一层或是最高层,您寻找机会去创建世纪,对方法的生存能力达成一致看法。您需要去理解当前形势和未来远景。您应该去了解更广泛的组织结构,哪些运行而哪些不运行,这样您才能够提出您目前的基线并制定去如何实现未来远景的路标。征募一些熟悉工业最佳实践方法的外部人员对于这些活动的帮助是很大的。5

在这一阶段与管理团队和赞助者建立信任感是非常重要的。这一阶段为变化计划的开始做好了准备。

为级别1层面上的变化而准备的重要活动在下面的表1中。

表1:为级别1层面上的结构性范围的变化而准备的重要活动

重要活动Kotter的贡献描述
工业最佳实践工场 用善于思考的领导层来激励管理团队紧急情况的感知力,对于远景和策略做出可能的输入,对于指导联合做出可能的辨别工场为获得大步迈进的高级管理提供方法。一些被公认的行业认为领导者应当完美的传达这一点。我们的目标是同管理团队——IT主管和指导报告一起讨论现代软件开发的实践工作。善于思考的领导者要求本团队思考“在今天哪些仍旧发挥作用,哪些已经失效了?”,并且指导本开发团队向未来挺进。请一位非常有经验人来传达是问题的关键;一个可靠的,外部的第三方经常担任这一角色。
当前形势的评估同出资方面谈,回顾已经存在的实践工作紧急情况的辨别力,为远景和策略提供输入,识别可能的短期盈利当前的形势需要被分级评判。您需要考虑一下这些:
  • 应经存在的实践工作
  • 将要从事的有所察觉的问题和事务
  • 当前进行的项目
  • 适当的技术
  • 开发流程和使用的工具
评估价值和能力是深入理解当前状况的一种非常好的手段。这有助于我们找出关键的问题并将注意力集中到最有价值的领域。同样有助于请一个独立的在该领域极富经验的第三方来进行回顾。
定义软件开发的远景并且将路标接合起来开发一个远景和策略,确定接合方向理解IT远景。这将涉及到在当前形势和未来远景之间产生一个分析的隔阂。您需要辨别商业结果,联结软件开发主动性,以及所要完成的关键技术结果。您所进行的向未来前进的工作将会使您的组织朝这一远景迈进。路标通过关联的结果将会被分解为一系列变化的波动,以及每一项被引入到您的组织中的软件开发能力。

成果和活动

在这阶段的最后,您应该拥有一个当前情况的基线,一个未来远景的规划图,和一个达成一致的路标或是策略。许多变化的开端/波动需要识别。图4阐释了这些活动图如何成为我们路标的绘制图。

Figure 4: Activities within a complete Level 1 organizational change

Figure 4: Activities within a complete Level 1 organizational change

图4:级别1中的组织变化的活动

您的远景或是高层次的路标一旦确定了,您将开始将成为变化开端的第一个波动的工作。

变化的第二层次——执行变化开端

这一阶段着眼于需要执行一个单一的变化开端的阶段和活动,另外在整体变化计划中被认为是单一的波动。执行一个变化开端包含向组织中引入一个或多个新的软件开发能力。这些能力被分组打成包,每个都包含必需的过程,技术开发和支持该能力的工具。这一阶段检查如何从计划过渡到变化开端,验证试验项目中的方法,将其展开面向更为广泛的观众,最终大量生产。

阶段1:计划变化开端

与Kotter发展进程接轨

在这第一阶段,前面的Kotter发展进程依然受用,只是关注的焦点转移到了变化开端。在最初的开端,紧迫感将会成为目标,远景和策略将会被充实,您也将继续指导联合作。

目标:在生存能力、范围和开端价值上达成一致

这个开端将会趋势采用一个或多个软件开发能力。这一阶段的目标是仔细研究、制定计划和突出开端的价值,正如表2中阐述的一样。包含建立商业用例,确定您将获得的技术成果,制定恰当的计划并实现之。这一阶段与RUP称作“初始阶段”的阶段有着许多相似的特征,例如,他们都将注意力集中在远景、商业用例和高层次的计划上。

表2:在变化的主动或者波动中设计一个单一的变化所要采取的重要活动

重要活动Kotter的贡献描述
需求工场的主动性带来的一致范围是远景和策略的一个子集通过组织与关键的出资方/拥护者在主动性的范围上达成一致。这是实现高级别远景的一个具体的子集。
建立商业案例/评估建议支持紧急情况的感知力,以及远景和策略的需求商业案例将证明对于下一阶段进一步投资的可靠性。
定义收益实现计划并且联结有章法的框架结构测量远景的实现,通过组织为突出的短期收益和巩固已有的收获准备框架这个框架结构将通过您的组织被定义为测量变化的影响力/ROI。这些方法将在当前项目以及接下去的一些阶段中被用来测量它们的效力。定义短期、中期、长期的方法是非常有用的。短期方案就是您为实现短期盈利所制定的目标。请记住——要简单。
回顾项目,辨别拥护者为短期盈利确定项目对这些项目需要进行初步的回顾。拥护者需要被确认——这些需要关键的个人,他们将通过从事这些项目来获得经验,并进一步成长为指导者。
为主动性制定执行计划为交流和短期盈利制定计划执行计划的制定将会把结果需求以及帮助我们达到这些结果的工作包聚集在一起。高级别的计划被用来规划整个主动性,而更多的细节性计划为下一阶段服务。

利用适当的管理和努力的调和,开端应当被当作一个项目来运作。在IBM Rational咨询和约中,我们指定一个技术承诺顾问(TEM)来负责指导和指引该架构中的活动,并且确定采用的解决方法是成功的。这个人在执行和实施期间对IBM顾问工作的各个方面负责。他们的责任包括资源的分配,进度的开发,辨认危险的领域,延缓计划,开发适当的培训计划,外加适当的指导和改变活动。理想的,这个人应当在开端的项目经理(PM)身边工作,在这些活动中指导PM。

结果

在这阶段的最后,您将确定范围,商业用例和相关的买进用例,技术成果,达成协议的活动计划和一个具体的可以工作的项目,包括试验项目。

图5阐释了这些活动图如何转化成我们路标的绘制图的。注意这部分活动在异地部分的时间线中下降了,标注着“在这里”字样。

Figure 5: Activities for planning the change initiative, as seen within the larger scope of the entire change program, indicated at We are here

Figure 5: Activities for planning the change initiative, as seen within the larger scope of the entire change program, indicated at We are here

图5:计划变化开端的活动,在整体变化计划中的更大范围中可以看到,标记着“在这里”字样。

重要的成功因素

当考虑试验项目时,我们马上能想起一下这些我们学习了多年的成功因素:

  • 使用一个商业临界项目,是用最有技能的团队来使得试验更为成功。
  • 总是关注项目的成功,意味着得到了实在的成果。例如,传授一个培训课程并不是成果。但是,通过应用和测试建立架构来消除其危险是项目成功的一个有用的成果。
  • 设定恰当的期望:不止一个项目会成为RUP的专家,各种类型的IBM Rational产品都能支持它。所有的项目都需要指导者的支持。
  • 不要等待完美的试验项目的出现,因为它从未出现过。
  • 如果您花钱来获得顾问的援助,一定要确定顾问是知道您的项目团队而不是为它来做工作。分清楚谁要获得这些技能并且让他们自己去完成。

人在这个转变过程中是一个关键因素;相关的成功因素包括:

  • 理论并不是问题,恰当的应用想法是难点所在。最好的学习途径就是在指导下实践。
  • 在第一个项目中亲自挑选您的拥护者。
  • 不情愿学习的人永远也不会学习。一定要确认您的项目团队成员是积极向上的,这笔技能本身更加重要。
  • 在团队开始取得成果是给与积极的反馈,您需要让团队品尝到胜利的快感。奖励和认同感能够在组织内帮助您更好的达到您所希望的行为。

阶段2:论证方法

这一阶段集中于通过在真正的项目中应用技术、建立加工架构来支持项目的论证方法。这个阶段的位置在图6的时间线“在这里”上。

Figure 6: The second phase in the change initiative.

Figure 6: The second phase in the change initiative.

图6:变化开端的第二阶段

与Kotter发展进程接轨

Kotter的被使用的重要步骤包括:

  • 变化远景的交互。对您的组织的变化计划的目标和方向有一个普遍的理解是非常有力的。
  • 授权广泛的行为。随着变化计划的前进,您需要克服所有遇到的阻力和障碍。这可能包含障碍和暗沟,改变测量方法和相关的报酬,提供恰当的技能去转换。为了支持这些行为,宣扬与这些变化有关的成果是非常关键的。
  • 赢得短期胜利(项目层)。这是一个经常被遗忘的领域,团队采用新方法并得到了积极的成果,但是却没有人在组织中推进他们。您需要提供证据来证明投资是有价值的。变化代理需要在反面进行推进,管理团队需要清楚地了解变化开端建立的要素。

记住之前Kotter的步骤也是非常重要的,因为它同样适合于这个阶段,紧迫感应当维持动力,您需要开始关注如何实现远景和策略,对指导联合的支持在这阶段依然很重要。

目标:验证过程和加工的架构

在这阶段,目的是验证您的解决方法中的加工架构,这经常和RUP的精化阶段拿来做对比。这个架构被一个或多个试验项目所证明,引入到一个或多个软件开发能力包中。通过这样做,被建议的变化策略得到了证实,现在您可以开始建立和巩固中心的加工基础架构。正如在RUP的精化阶段,这一阶段的变化开端致力于减少危险。

重要活动

在这阶段中的活动中有三个重要的组:

  1. 与试验项目一同工作。(这和我们第三层次的变化有关,在变化开端中嵌套在这里。)
  2. 开展核心活动来支持开端。例子包括建立加工的基础架构,在组织中交流远景。
  3. 回顾进步、收获成果、准备下一阶段的活动。这些活动将在这一阶段的最后完成。

这三种类型中的每一种都在下面的表格中详细阐述。

与试验项目一同工作

这可能是负责活动的人们最为熟悉的领域,因为他把注意力集中在项目的级别上,我们在架构中并不重视它,详见表3。您需要定制这部分来满足项目的需要。IBM Rational顾问有着广泛领域的培训,顾问工作包会帮助项目团队提高工作速度。

表3:试验项目活动

重要项目活动Kotter的贡献描述
项目评估这个项目活动有助于我们获得短期盈利,并为在接下来的阶段中巩固成果打下坚实的基础。这是一项当前状况的回顾,关于每一项被题意得当行项目,用来将组织性的变化爱找项目的需要排列目标。这项工作的成果表现为,一个执行计划将被制定出来,它将在指定的时间段内详细说明变化需求以及随之带来的所期盼的商业利益。

邀请在专业领域中富有实践经验的第三方来进行此项评估是非常有好处的。
培训提供一系列的培训是必要的——内部的局部化培训以及IBM Rational培训。每人接受五天的培训——项目中的12人参加定点培训课程。培训将同项目特定的要求密切相关。
指导指导包括执行预先制定的活动,目的是使知识在不同人员中传播。在启始阶段从您的组织中确定未来的指导者是最关键的,他是一个你在该项目上所训练的,并能够最终成为未来指导者的人。根据技术的开展情况,建议在最初两个星期提供三天的指导,在接下来的四个星期提供两天的指导。

更为重要的是,表3中展示的项目活动可以帮助您赢得短期胜利。为了维持现有的支持,这些项目需要在你的解决方法中展示他们的商业价值,通过获得技术成果来清晰的阐述。

支持开端的核心活动

通常,在组织中都有在项目团队之外的一个附加工作要做,例如一个过程工程师团队或是一个加工团队。这种类型的活动,列在表4中,着眼交流远景,创建一个强健的适应组织需要的技术解决方法。这些集中化的团队不应该工作在“象牙塔”中,而应当与项目团队紧密联系,去验证和提炼解决方法,在前进的同时收获经验。与项目团队一同工作能够帮助他们给组织确定适当的、被支持的解决方法。

表4:基层团队的活动

中心活动——基层团队Kotter的贡献描述
交流研讨会交流变化远景交流研讨会可以将主动性和远景的进展情况广泛的告知整个组织。
回顾已经存在的流程与远景和策略接轨回顾内部流程的框架。目标是回顾在结构框架中如何流程的最佳排列,提供一个在两者(也叫做开发实例)之间的原始计划。您需要关注于确认什么可以重用,什么需要补充进最佳流程。请记住不要在倒洗澡水时将孩子一同丢掉。随着进程的开展,您将最终选择一种适合于本组织的框架结构,并配之以一些实例模型,例如legacy,J2EE,.NET,开发包等等。
回顾已经存在的基础架构——健康检查为变化的巩固做准备,同远景和策略接轨在今天,IBM Rational工具集可能已在您的IT组织中的一系列项目上使用,可能是在ClearCase或者ClearQuest领域。在进一步拓展技术解决方法之前,通过一些方面的健壮性检查来回顾已经存在的基础架构是很有意义的。健壮性检查应该包括一套清晰的诊断和评估来真正认清当前状况,以及对已经存在的IBM Rational环境改进的领域,例如,SCM健壮性检查。健壮性检查从系统管理员(们)和终端用户的角度出发来进行。在中央的基础架构中与系统管理员(们)紧密协作,使得传递得以开展,从而使这些人员在未来进行的健壮性检查中能够胜任。典型的,外部的专家被用来确保打造良好的基础架构。
为开发桌面拓展/验证技术解决方案为变化的巩固做准备,同远景和策略接轨同中央的基层团队一起工作,拓展中央工具来支持IBM Rational产品线的额外方面:例如,ClearCase,ClearQuest,RequisitePro,Rational RSA/RSM,RAD,以及SoDA,也包括综合体。瞄准文档,构建,测试,以及在试验项目上利用工具体系结构。流程回顾和健壮性检查的输出将加强这项工作。允许内部和数员来开展工作以及回顾方法步骤,从而确保工作是沿着内部审计的流程进行的,这是非常有好处的。注意:其中一些工作可能会涉及到检查综合选项,所使用的工具也并非IBM Rational解决方案的一部分。就像每一个开发实例,随着主动性的进展,您将会最终选择一种工具框架结构/体系结构,其中包含了许多用法的模型,例如,legacy,J2EE,.NET,开发包等等。
支持被建立的基础架构为变化的巩固做准备若要准备更广泛的推广,思考该项目团队如何获得支持是一个关键。这有许多办法。许多组织设立一个或者多个“卓越中心”来协调具体的手段和技术,所以您可能拥有一个中心支持团队。另外,IBM Rational提供“服务补贴”,它能够将您的团队推广到IBM Rational支持的组织。

有了这些活动,您可以开始准备巩固这些变化——您需要使您的架构基础适合于支持组织的延展。

回顾,收获成功和计划

活动的最后一部分,在表5中,是一个经常被遗忘的部分,但却是成功的关键。您应当通过短期取得的成功来回顾那些曾经完成的优秀工作,收获那些优秀的实践经验或是可用的模型,并把他们从新带入组织加以改进。

表5:回顾,收获和计划活动

中心活动——基础架构团队Kotter的贡献描述
回顾和收获最佳的流程从短期收益中收获并为变化的巩固做准备同中心的基础架构团队以及试验项目一同工作来回顾开发实例,并加以适当精炼,通过试验获得最佳流程实例来作为开发实例的一部分。在这里,您将完善流程,看到那些在实践中起作用,并确保它像是一个开发团队的流程。
建立一个内在的案例学习机制有助于短期收益通过当行项目建立一个围绕结果实现的案例学习机制。再评估将从初始的评估中看到改进,收益的实现计划中章法也将得到巩固。案例学习将被用来在您的组织中进一步提升服务支持。
阶段回顾有助于短期收益这种回顾确保您在本阶段中达到了一个里程碑——使开发计划能够得以顺利实施。在您进入下一阶段之前,需要进行一次回顾来理解哪些方面工作的好,哪些需要进一步改进。重新回访您所取得的技术上的成果是很好的一点,这些成果中存在一些被漏掉的,或者多余的东西,可以在您重新制定计划时得以改进。
为下一阶段制定计划为变化的巩固做准备要区分额外的项目和计划要采纳的。您需要回顾所取得的进展并且为下一阶段制定计划。
管理工场和团体更新有助于短期收益并且为变化的巩固做准备再次提到管理团队——当前进展,案例研究,课程学习。您需要向您的导向接合和管理团队传达报告,在一次适时地保持动力和支持。这一过程同样应当于更广泛的组织沟通。

拥有这些试验项目但是却不推进它们的价值是什么?这些活动定位于为未来的变化建立持久的支持。

成果

在这阶段的最后部分,您将利用已经验证过的、可以为更广大用户提供延展性的基础架构,通过远景中的目标来验证技术解决方法。

关于授权广泛的行为?

在这点上,您可能会发现没有任何具体的活动与Kotter的“授权广泛行为”步骤相联系。很难去查明一个活动的某一个具体部分与之相联系,因为这个步骤趋向于比全面的哲理性的对变化开端的指导更多的指导。但是这个原则依然很重要,这里列出您需要思考的一些问题:

  • 克服抵抗和阻碍:
    • 从一个组织结构的远景,您可以看到去移出障碍和暗沟。应用架构还可以帮助来提供改进的交流和协作。
  • 文化上的考虑:
    • 改变评估方法和报酬应当反映出您希望的团队要注意的行为。您应当将报酬同远景和成果结合起来。
    • 您应该使用进程来推进成果的可视性。压缩了利益实现的实例研究的结合,架构的韵律,交流的焦点都能够提供帮助。韵律的使用应该是基于成果的,例如,被执行的和被测试的架构场景的数量。
  • 技能的发展:
    • 提供当时的培训和指导。注意架构中的方法要提供与具体采用的项目相一致的培训和指导。
    • 工场应当适于巩固和申请培训。尽管工作车间并没有被具体的涉及到,它应当是指导活动中的一个重要部分。
    • 传递真实的项目制品,而不只是练习这点非常重要。指导着重于在该领域中有帮助的技能的转变。

除了这些考虑,发布成果非常重要,将这些成果带入市场去发现它们的不同。同样,在该领域中,用例研究材料、韵律和交流活动都会提供帮助。

第3阶段:有效的开端延展到企业

在这点上,你拥有了一个在小规模被测试过的加工架构,并且团队的工作在进程和加工架构上有所收获。这一阶段关于更广泛的延展。这一阶段的位置在图7的时间线上,标有“在这里”的字样。

Figure 7: The third stage of the change initiative.

Figure 7: The third stage of the change initiative.

图7:变化开端的第三阶段

与Kotter发展进程接轨

既然加工架构在一个小范围内被证实,这一阶段关注在较大的范围内延展方法是更广泛的受众接触到。Kotter的实施的关键步骤包括:

  • 短期取得胜利。您需要继续高度关注成果,扩展用例研究,回顾获取的韵律,并把成果反馈给管理团队。
  • 巩固所得。这个阶段中的这个活动致力于在较大的范围内证实方法的延展性,并且建立从试验员那里得来的经验。这种在不同类型的项目中的规模的增加证明了IBM Rational解决方法在组织中的延展性。您需要继续为项目提供支持,收获经验并未为新的项目培育未来的指导者。您还需要提炼原始的工作评估方法去获取当前的进程。

目标:验证组织的延展性

这一阶段共享了RUP称作是精化的阶段的许多特征,这里来重复看一下这一阶段:有了前一阶段提供的证实了的加工架构,这一阶段需要通过更多的项目在更大的范围内去证明。在前一阶段中,您拥有两个或者三个试验项目。在这一阶段中,您可能要扩宽采用采用五到十个项目来进行测试。

这样做的目的是为了通过多个项目开始把改进嵌入到开发能力,使得变成成为通常商务的一部分。

活动

活动分为两部分:主要项目活动和集中化基础架构活动。表8和表9描述了这两部分。

表8: 变化开端第三阶段的重要项目活动

重要项目活动Kotter的贡献描述
回顾项目,计划执行方法进一步证实策略,开始巩固收益的进程在这一阶段,您需要对组织需要努力的重点有一个非常清楚地了解。 这是一个对当前每个被提议的试验项目运行状态的轻度的回顾。这个工作的结果是,会产生一个执行计划来详细指出变化需求和随后产生的为具体时间计划所期待的商业利益。项目的选择应当折射出不同种类的开发项目,例如J2EE,.NET,包,CRM,遗产开发。
培训各种各样的培训都可以 -- 室内的用户化和外部的IBM Rational。
指导指导是在预先确定好地从一个人向另一个人传递知识的活动中开展的——集中于是团队独立化——两天支持前两周,一天支持接下来的四周。以前项目的导师现在将帮助您驱动这些项目,如果使用IBM Rational或是外部的顾问,他们将会给导师予以指导。

表8中显示的活动与上阶段的活动有些类似;总体思想是要在一个更广泛的范围内证明该解决方法。注意到这时对外界帮助的依赖减少了,因为内部的指导在这阶段起到了非常积极的作用。这保证了长期的支撑性。

表9: 变化开端第三阶段的集中化基础架构活动

核心活动 -- 基础架构团队Kotter的贡献描述
扩展并收获最佳实践强调更多的胜利, 驱动收益的巩固与核心基础架构的团队和试验项目一同工作来回顾开发实例,适当提炼,从包含一部分开发实例的试验中提取实例和有用的模型。这样能够从不同种类的项目中获取有用的模型,例如,遗留开发。
拓展内部实例研究强调更多的胜利, 驱动收益的巩固试验项目实现了在成果上拓展现有实例的研究。重新评估将会着眼于对原先评估的的改进;韵律通过实现利益的计划得以巩固。
回顾和提炼韵律架构证实策略,为成功提供具体证据,驱动收益的巩固这个架构的回顾和提炼使得你可以通过组织衡量变化的影响/投资回报。试验是用到的韵律在这个活动中作为输入,但是这一阶段的活动到达了一个更为宽广的范围。
阶段回顾验证策略这个回顾保证了您能在这一阶段取得了阶段性的成果,证实了方法和气可以拓展的能力。在您进入下一阶段之前,还需要一个回顾来理解开端中哪些工作做得好,成功实现了,哪些方面需要改进,以及随后的建议。
为下一阶段作计划从正确途径实现远景和策略为下一阶段作计划
交流研讨会交流远景和策略的进步交流依然非常重要,在这一阶段让随后的交流研讨会重访一下远景和展示在更宽广的组织中取得的进步是非常有意义的。

成果

在这阶段的最后,你可以在一个比较广泛的范围里验证技术解决方法,并且为它在组织中的延展做好准备。

第4阶段:通过组织延展开端

在这一阶段,被验证的变化在组织中被实行。将会有更多的项目在这一阶段采用这种新方法,但是随着这种方法称为通常的商业,同时在开发团队中稳定性级别也将会提高。根据增长的尺度,需要更进一步的培训和来自顾问团队层次的支持。

这一阶段的位置在图8的时间线上显示“We are here”处。

Figure 8: The final phase of a change initiative

Figure 8: The final phase of a change initiative

图8:变化开端的最后阶段

与Kotter发展进程接轨

Kotter发展进程在这一阶段的重点是在文化中开始巩固这些新方法。

最终阶段的特征

在这一阶段中,会有一个从十几个试验项目向一个组织化(200以上个项目)的增长。在这一阶段中劳动和相关的花费将会被回顾和再上一阶段的最后达成协议。给出一个范围,你就必须保证能够有效支持大量数据;加工基础架构和支持机制在这阶段非常重要。在这阶段的最后,需要制定一个回顾来评估:1)与您最原始的商业目标相背离的改进,2)变化开端的总体成功(这一单一的波动包含在整体变化计划中),以及具体的技术成果。现在这一波动已经完成,您开始检验哪里是您要关注的下一个地方。需要注意的是波动的变化时可以重叠的——一旦成功地建立了第一个波动,您不需要等待它的完成就可以利用其他的能力和成果来进行第二个波动的变化。

总结

这篇文章展示了一个可以帮助您完成从项目执行到组织采用的转变的高级别的活动架构。变化主要有三层,您需要仔细斟酌哪一层适合您的组织。您可能还不满足这里提到的大型(第一层)组织变化方面的要求。然而,在开端层(第二层)工作也能获得很多。这个架构提供了一个比较大的画面和一种把它分离成可管理的小部分的方法。这些易于管理的小部分对分离投资需求也存在优势。

成功的变化有许多重要的方面。首先,您需要掌握文中阐述的Kotter的八个步骤。不要走捷径,并且总是去思考您采用的DOT架构方法与Kotter推荐的一致性。记住,成功孕育成功。最初的需求需要有抱负,但也要实际。这对一个重要的商业目标有很大价值。确认成果的计划并且在取得成功时发表它们。更相像的是,巨大的成功是传递在一次执行的可测量的有益成果的开端。最终,成果驱动了动机。如果团队成员被按照其他标准评估——例如他们今天完成了多少活动?——他们的先进性就会被注意到了。真实的成果是衡量成功的准绳。

进一步阅读:

  • Kurt Bittner and Saif Islam, "Adoption Through Execution: Project-Level Mentoring to Improve Software Capability," in The Rational Edge, June 2004. http://www.ibm.com/developerworks/rational/library/4866.html
  • Stefan BergstrÖm and Latta RÅberg, Adopting the Rational Unified Process: Success with the RUP, Addison-Wesley, 2003.
  • Be sure to look for a forthcoming book by Joshua Barnes on enterprise deployments of RUP and IBM Rational Tools, due out next year from Addison-Wesley.

注释

1 如果您想要更细致的讨论这些方法,请与IBM Rational联系作者。

2 启动,诊断,建立,行动和提高。想要获得更多IDEAL模型,请登录http://www.sei.cmu.edu/ideal/

3 John P. Kotter,《领导变化》,哈佛商学院出版社,1996年。

4 如果您发现有应当被包括的活动,请您联系作者,他们将考虑将其加入到架构中。

5 IBM Rational拥有有经验的顾问可以来帮助您。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文

评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=161859
ArticleTitle=改造你的软件开发能力:一种适应组织变化的框架
publish-date=12152005