克服采用迭代开发时的文化挑战（转载Rational Edge）

克服采用迭代开发时的文化挑战

文档选项

将此页作为电子邮件发送

拓展 Tomcat 应用

下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1
级别： 初级
Clay Nelson , Sr. Technical Services Specialist, IBM Rational
2004 年 10 月 15 日
来自Rational Edge: 很多组织都理解尽早缓解风险、用户驱动的开发和其它迭代开发范例等的价值。但是由于文化和操作上的障碍，他们怀疑他们的组织能不能采用这些最佳实践。本文将描述和提出一些方法来应对在你采用迭代开发时可能会遇到的挑战。
今天，艺术级的软件开发过程都基于迭代或者螺旋开发模型。很多组织都理解尽早缓解风险、用户驱动的开发和其它迭代开发范例的价值。但是由于文化和操作上的障碍，他们怀疑他们的组织能不能采用这些最佳实践。
本文描述了在你采用迭代开发时可能遭遇的文化上的挑战，以及如何应对这些挑战的建议。将来的文章将处理那些阻碍迭代开发的问题（如财务计划、资源问题、技术操作等）。在本文中，我们描述：
迭代开发的简要概述
采用迭代开发时的文化挑战的概述
从组织变革专家得到的最佳实践以及这些实践如何应用到迭代开发的说明
克服采用迭代开发的挑战的学习
迭代或者螺旋开发模型已经提出超过十年了，Barry Boehm’的文章“A Spiral Model of Software Development and Enhancement," 1 是把这个实践引入到现代软件开发的先行者。他的工作解释了如何开发增量的系统、按照风险排列优先级、以及反对使用传统的序列的瀑布模型。
迭代开发是一种软件开发方法，它的重点在于尽早检验可执行的软件。在瀑布模型中，你在需求分析中产生大量文档，到设计，再到开发，到测试等一系列过程。与之相对，在迭代开发中，系统从应用程序的一部分的实际实现开始开发，随着时间推移不断增加它的功能。每次迭代包括分析、设计、构建、测试的组合过程。通过每次迭代，项目组关心的功能在迭代中通过对架构和商业价值等的风险评估中被确认。在每次迭代时，增量的设计，编码和测试。每次迭代都验证系统架构，保证需求和干系人的要求，以及软件质量。
迭代开发过程强调实际的、产生可见的结果的项目过程。它给最终用户和干系人以可见的项目实际进展情况，而不是感觉和主观的进展情况。这是有可能的，因为在每次迭代中都有可用的系统的版本用来检查和验证。这是一个重要的概念：在迭代开发的实践中，软件组最关注的是结果。




回页首
迭代开发模型已经证明是一个软件开发的优越的方法。但是按照November/December 2003 IEEE Software Magazine2 的描述，仅有大约30%的软件开发项目使用了迭代方法。这个统计让我们不仅要问：如果迭代方法那么好，为什么没有更多的组织采用呢？答案有四个方面：1) 很多组织使用瀑布模型已经很长时间了； 2) 我们倾向于相信关于组织变更的神话； 3) 我们过高估计了我们的变更的能力； 4) 我们过低估计了变更的阻力。 有很多传说阻碍采用迭代开发，并且使组织满足现状。
本节讨论一些围绕变更文化的说法，并给出对这些说法的回应。
神话： 我们宣称我们的组织正在采用标准化的迭代过程，并且我们的团队很高兴采用它。
现实： 这样的说法相当危险，至少会碰到一些阻力。有很多组织和个人的阻碍变更的原因。例如：
害怕失去权利和影响。 尽管变更对于组织是有益的，但是个人将相信他们将遭受痛苦。变更意味着失去，这将导致害怕和焦虑。对变更的害怕将是有力的阻碍因素。
人们满足于现在的状况 你的团队成员有对他们过去成功的强制性依赖 3 ，或者他们甚至不记得还有改善的余地。这种态度通常是： “既然我们已经这样做很多年了，为什么现在需要改变？”
例外的谬论。4 不管建立了多么好的最佳实践，或者它鼓吹得多么好，人们总是采用“这里不适合”的信念进行抵抗。换句话说，尽管有对应的证据，他们仍然认为他们是规则的例外。
无意识推理的规律。 你将听到这样的说法：我们不知道进行这样的变更会发生什么样的副作用。
我们必须认识到，进行任何类型的组织变更，包括迭代开发，都是困难的，而且经常受到抵制。迭代开发不仅仅是一个只需要理解技术的内部过程。它将改变计划和协作的方法，因此对商业组织有很大的影响。因此，你必须把引入迭代开发做为一个项目进行，并给予适当的支持。
所有这些人的问题都是非常实际的对变更的抵抗。下面，我将给出影响抵制变更的具体文化。
神话：银弹将解决我们所有的问题
现实： 这个传说在我们改善软件能力的过程中持续存在。一些组织避免使用过程，代之以个人英雄主义和他们开发组的天才发挥。另一些团队过于强调过程，试图通过给团队过多的过程来保证成功。仍有些组织寻找解决他们的问题的包治百病的软件工具。我们知道，一个单一的解决方案不能解决任何问题。实际上，最终的成功必须包括所有的单元－－在组织和项目之间平衡。
神话：每件事情都很好，我们不需要进行全面的改善
现实： 在同意“例外的谬论" 规则后，一些领导者相信他们可以通过简单第改善几个关键过程域就可以得到突破性的结果。几年钱，一家消费产品公司想要改善它的销售系统。每个部门都有不同的产品线，每个都有它们自己的运送产品到区域销售中心的卡车。通过在每个部门内部改善装载卡车的后勤工作和运输包装，可以获得一些成本的节约。但是全局的改善证明是更有效的解决方案。公司转移到一个集中的服务多个产品的销售机制，可以更好地安排优化装载、行程和仓储。这样需要更少的卡车，更少的到零售中心的路程，最后得到更低的成本和更高的效果。 5
与之类似，有些组织试图通过重组他们的团队来改善软件开发能力，这有些类似于在沉船甲板上重新安排座位。最新的一次财富50公司的CTO会议使我想起了这个谬论。“如果我们仅仅改善需求获取的过程，如果我们仅仅在设计上做的更好，如果我们仅仅做更好的测试工作，我们将最终改善我们软件的质量和发布的预期。”换句话说，CTO们认为他们通过集中在开发周期每个领域的内部过程改进，组织就可以达到更高的产品质量等级。这些改善可能可以一步一步地帮助组织，但是这就错过了突破性改进的机会。
很多应用开发问题持续存在，因为组织的不同部分优化他们的成果而浪费了全局的目标；需求做的更好是有些价值，如果开发和测试过程在组织掌握中的话。你可以采用用例 驱动的开发或者采用可视化模型得到一些改善。Jeffrey K. Liker在他的新书 The Toyota Way，中建议说这些想法与传统的过程改善相关，集中在局部的效率。你可以看到局部的有效的改善，但是很少能够影响总体的结果。Liker 解释说：“这一点特别正确，因为在多数过程中，很少有价值累加的步骤，因此改善这些步骤也不能得到更多效果。” 6 要想达到更好的效果需要跨功能的迭代的方法，而不是局部的或者简单的过程改善。使用前面的比喻，所有我们的软件部门都需要避免他们的卡车。
这些常见的说法都是在组织文化中根深蒂固的态度和行为的症状。一份Software Engineering Institute (SEI) 的报告提出：“组织已经经历了螺旋开发的困难－－归结于过分松弛的控制，风险低估，存在的顺序开发的方针，不灵活的财务机制，根深蒂固的文化，关于什么是螺旋开发和如何使用它的混淆。”
本文下一节描述阻碍迭代开发的文化表现，将来的文章会描述操作的问题。




回页首
组织文化是组织中个体共享的价值、信念和行为举止的集合。在开发中采用迭代方法通常需要改变文化。本节中，我将讨论理解组织文化的框架和一些支持迭代方法的重要的文化的属性。
一个有用的评估组织的行为和文化的框架是由Kim Cameron 和 Robert Quinn提出的竞争价值框架（Competing Values Framework）。它是一个广泛应用的用来理解存在于组织中的基本价值的方法。如果一个组织的成员都显著地追随一个突出的价值，这个维度就很大程度上定义了行为文化。理解组织中的人如何观察他们的组织，可以帮助我们预料挑战，构建我们用来应对挑战的结构，甚至可以作为我们制定我们的软件开发过程的输入。表1描述了文化价值。
表 1：竞争价值框架，由 Kim Cameron 和 Robert Quinn提出

理解个体如何看待文化将使你洞察你在处理的组织的类型，并因此确定在你采用迭代开发时哪些行为需要改变。例如，如果你的组织集中在结果上，而忽略如何达到这些结果，这些组织很可能遭受比较低的信任，因此有比较低的士气。正如我们下一节的讨论，这种缺乏信任将导致组织严酷地细化合同和规格。这种早期关注细节将导致与迭代或自适应方法相反的僵化。人们可能害怕自己做决定，并不履行组织的意见，这经常导致改变现状。这将导致在突然出现问题时产生阻碍成功的影响，没有人想要冒着组织责难的风险提出组织不想处理的问题。在后面的节中，我们给出了一个评估你的组织文化的方法，以及如何帮助你计划移植到迭代开发。
现在，让我们调查阻碍采用迭代开发的文化问题。图1显示了这些问题：

图 1： 阻碍采用迭代方法的文化问题
不管你的组织有内部的开发组还是有外部第三方的采购项目，在商业组和开发组的对抗关系都是存在的。两个组经常以对抗的态度共同工作。
缺乏信任经常导致一种被文档中每件事情困扰的文化。组织倾向于过度在创建合同和规格上工作，而不是在设计、开发和集成上。实际情况是这些合同从来不会产生有意义的结果；他们只是在一旦出现问题时定义一个同对手作战的战场。当你有证据说“项目失败的原因时我们没有正确的需求”时，你的胜利实际上是没有意义的，没有人，包括你的用户，实际上赢了。
不要误解，我并不是建议文档没有用处，他们是商业世界生活的一部分。高度的信任并不意味着每个人都必须到处收集，互相联合，唱“Kum Ba Ya." 然而，当软件需求的细节嵌入到合同中时，你的组织可能有信任问题。要点是在与其它人的信任和高层文档协定之间找到平衡。
我们应该集中在保证我们有的好的工作关系和通讯上，以便我们不会在碰到第一个麻烦时就结束。如果主要领导者能够鼓励好奇新和创造性思维，如果他们集中在共享的前景，你可以创建一个有开放和诚实的通信的组织。我们下面将讨论这一点。
在太多的组织中，文化并不鼓励它的成员寻找和面对风险，揭出那些不愉快的实施，或者询问难啃的问题。实事上，在他们听到坏消息时，有一种“干掉报信者”的倾向。为了描述怎样不和影响组织的残酷的事实对抗，Jim Collins, 在他的书 Good to Great中，描述了同Admiral Jim Stockdale, 越战期间北越最高司令官的会见。Collins boils 用下面的陈述简述了面对事实的训练：“你必须从不怀疑你将成功的信念－－你从来不会负担失败－－在面对最残酷的事实时保持纪律，不管它们可能是什么”
Collins 称这个训练为 Stockdale Paradox，并认为这种对矛盾的认可是一个组织变得伟大的共同特征。这个训练也适用于软件开发领域。很多开发组织开始于不切实际的过于理想的日程、范围和预算。与现实相比，我们更愿意处理希望。这种倾向将导致低信任的环境，给组织带来灾难。

迭代开发。一种计划好的重新工作的有序方法，应用软件或系统是以较小的增量方式进行开发的。
竞争价值框架。理解组织文化的关键维度的一种模型。
Stockdale Paradox。保留你将在最后获胜的信念，而不管困难和同时所面临的你目前现实的最残酷的事实，无论它们可能是什么。
执行导向。关注于结果，而不是活动。
有无数的组织在面对严酷的事实失败的故事，如失去市场优势，破产，和其它财富的逆转。失败现在也经常出现在软件开发项目中。这种失败如何在软件项目中表现？
高的目标通常可以激励商业组，同时他们经常受挫于工程组。在工程组更加集中在缺乏注意的严酷事实中时，商业组正在“射月亮”。
在项目进展时，没有人想要问项目是否能够真正达到它的目标。项目成员习惯于忽略在项目出轨时应该觉察到的风险。这种满足，或者至少是如意算盘，是对项目成功的潜在的危害。有点偏执狂是一件好事。正如 IBM Rational的Walker Royce说的：“没有人挖开石头，寻找下面的丑陋的弯曲的东西。”开发和接受预先寻找风险的习惯是采用迭代方法的基础点。
为什么我们不愿意提问题？为什么我们象鸵鸟一样把脑袋埋到沙子中？我涉及的一些项目正在遭受这些问题。我们总是让我们变得太乐观。我们不去问诸如：“你怎么知道我们在集成原有系统时不会出问题？”或者“如果我们必须构建而不是买这个部件时会发生什么？”这样的问题。不问那些棘手的问题可以给你自己以错误的安全感。仅仅由于你没有踩到地雷上并不意味着没有地雷。
我以前的Georgia州立大学组织行为学教授 Dr. Louis St. Peter说过， “在我们长大时我们经常停止好奇心，是由于我们学的变得有智慧了，有智慧的意思就是已经知道了正确的答案（而不是问更好的问题）。”BusinessThink7 的作者也认为，好奇心是找到正确的问题的解决方法的基本元素。不幸的是，开发组的成员简单接受在他们在开发确实必要被问及的问题的解决方案。相对于为客户解决理解被处理的问题，我们简单地“做那些告诉我们的事情”，去构建系统。
当他们真正去问那些他们应该问的问题而收到惩罚时，开发者经常学会不问问题。他们也会因为害怕被人知道他们的无知或者缺乏专业知识而不问问题。我们在会议中试图听从那些不理解的讲述。我们环顾房间，我们点头同意。我们并没有认识到身体语言覆盖的更多的是什么－－没有人理解那些讲述。它给你举手澄清问题的勇气。
人们也为了避免导致冲突而不问问题。冲突可以是好事也可以是坏事，依赖于冲突的类型和冲突双方的回应。正确的冲突形式将导致更好的作决定。这里讨论两种类型的冲突：
C-型冲突，或者“认知冲突," 集中在问题和与问题相关的不同意见上。在这种冲突中，团队成员不同意主要是由于他们不同的经验和专门知识引导他们对问题和可能的解决有不同的看法。C-型冲突将使人们主动检查、对比、妥协这些不同之处，并产生最好可能的结果。 A-型冲突, 或者 “情感冲突," 在产生不同意见时引入了个人情绪的反应而不是职业。A-型冲突经常导致的结果是：敌意、愤怒、怨恨、不信任、冷嘲热讽和冷漠。因此，不象C-型冲突，A-型冲突通过阻止团队通过类似C-型冲突的活动而破坏团队的效能。这对团队是关键的问题。 8
不管在你的组织中人们出于什么原因不问问题，要保证迭代开发成功，这种行为必须改变。文化必须培养C-型冲突，并允许任何人问尖锐的问题并得到真正的、合理的答案。
当然，软件开发的目标是产生工作软件。你的过程－－你创建软件的方法－－影响最终产品的质量。因此你的过程就意味着产生高质量的产品，而不是集中在你的努力上。在本节，我们讨论执行和在工作时遭遇的阻碍。
Larry Bossidy 和 Ram Charan, 在他们的 Execution一书中，解释说：执行是让事情做起来的艺术 9 ，要给面向结果的行动而不是对话或者纸面的承诺以比较高的奖励。正如个体生产力专家告诉你的，欺骗你自己认为你是在生产是很容易的；活动有错误的诱惑力。它将导致你相信保持忙碌就可以产生结果。我们如何判断我们的政治家的能效？是提出很多立法，产生很多想法，处理很多语言？还是他们实际通过了能够影响他们的支持者的生活质量的法律？如果我们用后面的情况判断，我们就会集中在结果上，而不是在程序和过程上。
组织和项目都会落入同样的陷阱，混淆活动和成果。在软件开发项目中，缺乏执行表明它们包括了太多的会议、过量的文档和低效的活动。
什么因素阻止组织朝向成功？有时，人们害怕行动，因为他们害怕为他们可能导致的失败负责。这种对风险的排斥嵌入在文化中，结果导致整个组织的停滞。在更一般的情况下，人们害怕未知的事情。从而，个体和组织都从在开始时就知道所有答案和风险中得到安慰。他们坚持常规，即使有事情可以改善的强烈的可能。不管事情变得多坏，他们总是会更糟。我们的项目计划反映了这一点。我们在早期构建详细的计划，因为他们能够给我们一种安全感，即使我们知道这个早期的计划很快就会变成废纸。
迭代开发是一个挑战，因为它承认我们不知道面对的全部事情，它需要我们为了未知的事情调整计划。在不鼓励问题的文化中，很难想象迭代开发会成功。在一个培养办公室政治的环境中，它灌输害怕大声说、或者鼓励满足现状，低信任的文化。这种特性导致一种文化，真相被几个关键人物隐藏。减轻风险变得很困难。这种环境很难有益于引入风险驱动的、迭代的开发。




回页首
指出挑战要比描述如何去做更容易。幸运的是，有很多书籍和从数千案例中总结出的经验可以帮助我们。
Bossidy 和 Charan 10 提出，在执行者认识到他们的组织需要改变的时候，他们经常试图去改变“硬件”。他们花费时间重新思考战略计划、组织架构、角色和职责、高层过程－－换句话说，组织的“硬件”。但是正如计算机的硬件如果没有正确的软件就没用一样，一个组织的硬件（它的策略和架构）如果没有软件，它的人的思想和精神，也就没有用处。如果你想改变，你必须处理他们的信念，他们关心的事情，他们的问题。
文化是一个非常难讲清楚的概念。我们可以检查组织的架构和过程文档来确定可能需要那些改变，哪些值得改变。但是第一步是理解它今天存在和团队如何相信它需要改变的文化。
在 Diagnosing and Changing Organizational Culture一书中，Cameron 和 Quinn 提出了一系列称为Organizational Culture Assessment Instrument (OCAI). 11 的问题。组织成员回答这些简短的问卷，通常需要5到10分钟来完成，以评估他们对组织当前和期望的文化的看法。
图 2 显示了最近在一个很大的政府机构完成的软件能力评估的OCAI问卷的一部分

图 2: IBM Rantional完成的Organizational Culture Assessment Instrument (OCAI) 的一部分
OCAI评估包括下面几部分：
Dominant Characteristics. 什么是我们文化中最重要的？例如，构建真正酷的方案比可预期的结果更重要吗？
Organizational Leadership. 你如何刻划领导层的类型？我们的管理者是没有废话、积极进取的还是更加关心驱除低效？
Management of Employees. 如何对待员工？是象齿轮上的齿还是把他们做为有价值的资产培养和成长？
Organizational Glue. 什么维持着组织？
Strategic Emphasis. 我们的价值是什么？高度信任？成功？
Criteria for Success. 我们如何度量我们的成功？市场份额？协作？变革？
每个团队成员在每节的四个描述中分配100点，分配最多点的就是组织最合适的描述。
理解关键团队成员是如何看待组织的是很有意思的，但是它是否有助于我们采用迭代开发？是的，通过分析文化的概况，我们能够增加在组织中如何进行变更的具体的洞察力。用图形的方式分析是一个快速理解数据的方法。对每个答案组，给出一个文化的概况，并给出平均值。
让我们看看从分析这些概况给出的洞察。
分析差距. 在团队成员今天对文化的感觉和他们相信他们应该是的之间有多远？（在图2中，这个差距用Now 和 Desired 列描述）我们当前的文化是否是“命令和控制”类型，过度结构化？我们是否需要应我们客户的要求更加创新一些？这个差距告诉我们需要做多少工作。
寻找不一致 分析那些组织说是重要的和组织做的。例如，如果管理人员声称我们最重要的价值是组织的人，但是我们的领导类型和管理员工强调的是严格坚持文档化的程序和规则，会发生什么？在这样的组织中引入变更是困难的，文化的差异可以帮助找到这些问题点。
分析重要的不同意见 在不同的个体和团队之间发现文化的不同感觉是不寻常的。然而，如果在组织不同部分之间有显著的不同，或者没有清楚的模式，这是一个潜在问题的信号。例如，假设你注意到，组织认为管理信任的优势文化价值是Human Relations culture (表 1中的 Collaborate) ，但是员工认为优势价值是提交结果（完成）。在这种情况下，管理将会远离真实，从上到下的改变过程的努力也将受到阻碍。
既然明确了理解文化如何帮助我们采用迭代开发。没有容易的答案。到现在为止，我们只给出了更多的轶闻和定性的证据而不是经验数据。然而，因为我们已经开始理解Competing Values Framework，我们可以对和迭代软件开发和它的使用相关的文化属性进行一些逻辑假设。表2显示了在前面提到的四个文化类型中工作时可能正面或者负面的影响。
表 2：在四种文化类型中工作时的可能正面或负面的影响

正如经典的“先有鸡还是先有蛋”的问题一样，有人会问：“我们应该先改变文化还是先采用迭代开发？”就象Bossidy 和 Charan说的那样，“我们不把我们自己放到新的行动路线上去；我们把自己放到新的思想路线上去。”这也是Harvard 变革大师，John Kotter的意见：
“文化不是你能够容易操纵的东西。试图抓住它并弯成合适的形状是不可能的，因为你不可能抓住它。仅仅在你已经成功地改变了人们的行动后，在新的行为产生了好的结果一段时间以后，在人们看到新的行动和取得的改善之间的联系之后，文化才会改变。” 12
在你必须承认我们已经讨论的文化和操作问题，并且有一个处理问题的计划时，改变看法的关键是 产生可证实的结果 。换句话说，你不能带着拉拉队去把他们哄到新的行为上。
基于Bossidy, Charan, 和Kotter提出的很多原因， IBM Rational Software 在部署迭代开发和IBM Rational Unified Process, RUP时鼓吹全程采用。 Kurt Bittner 和 Saif Islam 最近在 Rational Edge 的文章，“Adoption through execution: Project-level mentoring to improve software capability," 13 中，进行了详细的解释。基本上，采用迭代开发需要有一个“从做中学”的方法。目标是给软件开发组织示范，在项目组成员协作中的改变是如何产生更加可预期的结果的。成功的示范一个迭代开发方法可以提供改变态度的必要的证据。这个证据可以带来实际的可工作的软件，即使在早期阶段只能产生部分功能。
一旦我们有了文化评估的结果，我们必须指出如何改变文化。在我最近的报告中，IBM Rational 过程领导Per Kroll 提出，我们通过在“old way”和“new way”之间的对比，来改变我们在软件开发中思考我们的角色的方法。 Black 和 Gregersen的书， Leading Strategic Change，中附和了这个观点，它指出，要改变组织文化，你必须改变个体的“头脑图”。 14 改变我们团队的头脑、心脏和灵魂，在我们组织文化中提升新的思维模式， 可以帮助开发更加适合迭代开发的氛围。表3给出一些你可以用来挑战你的团队的例子
表 3：既然团队变换到迭代开发，项目领导和执行者能够挑战他们认为困难的角色和责任

是否有一个理想中的迭代开发的文化的轮廓？这个问题只能在进行更多研究后回答；但是，可以有把握地声称，一个和谐的文化是重要的。不管现存的文化是什么样子，总有同哪些功能紊乱的文化单元斗争的路线。下面列出一些文化特征，它们描述了如果我们希望采用迭代开发，我们的组织必须构建的文化和环境的一些特征。
高度信任。 客户，涉众和软件团队都相信他们正在朝向同一个目标工作。
公开和协作。 风险被按照现实的风格公开讨论。我们重视指导和建立易于助人的领导。
对于解决问题的激情。 团队积极寻找问题的根源，并致力于解决问题。我们不仅仅是由于有人那样说了才构建和部署解决方案；我们真正理解在问题和解决之间的关系。
孤立置疑。问每件事情，理解假设
客户结果驱动。 什么与用户接受他们需要的结果有关，不仅仅是文档化的需求。
授予团队成员权利和规定职责。 项目组被授予解决发生问题的权威，而不是相反，被很多监督委员会、功能管理组和过程堆捆住手脚。
不看重组织内的事务。 高于一切的价值是我们共享我们的目标：给我们的客户提供价值。我们不去关心在成功完成项目后谁获得荣誉，谁得到提升。
以执行为导向。 优先让事情完成－－并不是简单地按照活动顺序做－－是显然的 。




回页首
很多试图采用迭代开发的组织都失败了，因为这些拥护者在面对组织特有的文化问题时没有足够的准备。你可以通过在转变前有效地评估，然后理解文化来克服这些迭代开发的挑战。通过实际执行来采用过程的变更是使变更实际和能够为干系人接受的关键因素。文化的改变不是来自于陈词滥调和口号，而是来自于创建新的成功的故事并变成标准。