敏捷时代来临(转与 Rational Edge)

2004 年 10 月 15 日 2004 年 9 月 22 日 更新 来自于Rational Edge：此专栏追踪敏捷软件开发的增长和发展，主要是通过查看关注于XP和敏捷开发的研讨会的参加者、会议和讨论。 正如孩子们要经历连续的身体和精神上变化，直到他们成熟成为成人一样，随着他们逐渐长大和成熟，思想和智力也会经历相似的转变。他们被构想出来，不断进行精炼和丰富，最终被接受为知识体系的合法成员。有些比其他的成熟得更快一些，并且我们会抛弃那些不再发展和不能低档住严格详细审查的思想。 在过去几年里，我一直关注敏捷软件的发展，从其幼年期到成年期，伴随着笑声、泪水进行奋斗，有时会有一种恐惧的感觉。尽管我已经看到了敏捷实践上的价值，但我还不是一个早期的采纳者－－我通常是只有在风险和利害关系较低时的一个角色。现在，我已经相信这些实践在软件工程师的工具包中有了一个适当的位置；如果得到正确的使用，他们可以帮助团队更加优秀。要将一个敏捷的过程应用到一个重要的、高风险的项目上，如果项目和过程匹配得很好，我已经变得越来越不困难了。本专栏描述了我考虑这种方式的原因，记录了从早些年来通过最新的（和最近的）XP/敏捷领域的研讨会上的敏捷活动中的变化。 敏捷：较早时期 我的第一个敏捷研讨会，XP2001，是在Sardinia与好几百参与者一起召开的。我们中的许多人来到那里，了解了“敏捷事物”都是关于什么。我已经读了关于极限编程（XP）的许多书和文章，但是还没有接触过使用过XP的任何人。 在那时，XP和敏捷活动有一群差不多类似下面的信徒－－他们使用一些可笑的缩写词，如YAGNI和DTSTTCPW。 1 我一直在等待有人向我说明这个神秘符号。尽管一些软件开发中的旧的守护者用类似的事物来谈论敏捷方法论，但通常它都是作为一种将被忽略的疯狂想法被摒弃掉了。 许多XP2001的参与人是咨询者，他们讨论将XP出售给客户组织的工作和他们碰到的问题。有些人讨论有关提升XP用于大的项目，但是还没有人证明它可以以小的配置重复地工作。这些咨询者都是非常聪明的、受人尊重的人，包括Kent Beck、Martin Fowler和Robert Martin。这些人很了解如何构建软件。他们中的一个人，Heck，写了一本流行的有关UML的书。 2 因此我认为他们值得听听。 我离开研讨会时，对敏捷和XP有了一个比较好的理解，尽管还不完全。我知道你可以在某些软件开发项目上有效地使用XP。我也明白你不需要使用所有的XP实践，或者按照一种传统的方式使用它们，以得到一些益处。事实上，我多年以来使用过几种实践，用一种方式或另一种方式。并且我清晰地看到，XP与Rational统一过程，RUP，有很多相同的东西。 3 第二年，XP/敏捷领域研讨会在芝加哥的郊区召开。研讨会再次吸引了许多咨询者，他们中的一些人是会议发起人。在那时，Rational软件公司是敏捷联盟的一个成员；Grady Booch代表公司，并且我们出席了此次研讨会。尽管Rational仍然看起来像一个局外人，但是它正在团体中形成联盟，并从中学习。这个研讨会也吸引了一些著名的学术和研究团体成员。南加利福尼亚大学的Barry Boehm（以COCOMO和螺旋生命周期闻名的Barry Boehm）提交了一个主旨，并且Watts Humphrey，在软件工程组织的能力成熟度模型（CMM）发展中的一个关键人物，提交了另外一个。 在他的谈话中，Boehm说他认为敏捷运动对于产业是一股新鲜空气的气息。这个简单的陈述包含着敏捷运动的许多内容；它打开了与不同的敏捷相关问题集对话的方式。尽管坚定的追随者仍然不愿意承认XP不是一个银弹，但有些表现为更适度的位置。Humphrey的谈话甚至激起了更激烈的辩论。他谈论了度量，为对话引入了一种工程和控制观点，并最终培养了更多思想启发。 在研讨会上的经验式的专题会议上，许多参与者，大多数是来自学术界，一些来自产业界，表达了收集数据和进行试验的兴趣，以帮助确定敏捷方法的效力。在这之前，Laurie Williams在有关配对编程的有效性方面的度量工作是我们唯一看到的有关敏捷方法上的研究。她的结果说明配对编程是有益的，但是需要更多的数据以证实她的决定。许多人看起来都很热心于收集有关于此的数据和其它流行的敏捷实践。 4 在下一次的XP/敏捷领域研讨会于2003年8月在新奥尔良召开时，出席的人数下降了。经济萎靡不振，并且此研讨会之前不久在犹他州召开了敏捷开发研讨会，吸引了否则可能要到新奥尔良的参与者。我也发现这个研讨会是令人气馁的；看起来就像是自上次会议后没发生过什么，而上次会议唤起了敏捷方法传播的希望。但是方法学似乎仍然是咨询者的领域，他们互相庆贺另一年将敏捷带给了大众。尽管有像Ivar Jacobson这样人的关键提示，他们注意到有多少敏捷原理在XP出现很久之前就已经有了，在我看起来，这个社团没有得到多少进展。 然而，更多的公司－－包括微软－－派出了代表，并且这种经验式的研讨会也有可取之处。我们讨论很多实践，包括了加拿大国家研究委员会的Hakan Erdogmus的一项实践。在一项实践中，他显示了确定首先测试编程或TFP的效率的趋势。 5 他得到了与我的学生在一次实验中所得到的比较相似的结果，那次实验是在我的软件工程实践课中进行的。TFP看起来改进了代码质量，但是结果从统计上看并不足以支持对此效果的确信。Erdogmus告诉我们，需要更多的实验才能确证他的发现。 在这次研讨会上的教育家的对话也很平常。我将要转到学术界上，想找出哪些教育家正在他们的课程中进行敏捷方法。据许多报告，他们正在尝试许多不同的方法将方法引入到他们的课程中，但是要这样做他们不得不将一些东西从课程中砍掉。 在研讨会后，我认识到缺少了什么。我们有大量的咨询者和学院派，但是却很少有真正使用XP和敏捷方法的用户。一个值得注意的显著的例外是实施和维护Saber航线预定软件的公司的一位副总裁。他报告说，他的团队已经成功使用了XP，但很少有用户往前进一步。我想知道，这些方法真正影响到商业环境了吗？ 回页首 敏捷的一个巨大飞跃 今年，我得到了答案。XP/Agile Universe2004，第四次XP/敏捷领域研讨会，于8月在加拿大Alberta的卡尔加里市召开。（另两个研讨会集中在敏捷开发上－－XP200n， 6 最早从2000年在欧洲召开，以及敏捷开发研讨会开始于2003年－－也在今年召开了）。 在这次研讨会上，很明显，敏捷时代正在来临。首先，事情有了一个不同的感觉，因为它包括了许多用户－看到的所有论文的四分之一都来自用户。也有更多学院派（一半论文），并且很多都工作在重要的问题和想法上，这些将会影响方法论的未来。 在一个有关脚本化Web测试的指南中，我的合作伙伴是一个来自华盛顿公司的IT部门的质量工程师。用户们在会议中大声地谈论，问了很多好的问题，并想知道他们如何改进他们的组织。他们清楚地感觉到，敏捷和XP不是他们曾经所认为的那么极端。 今年的研讨会的另一个值得注意的特点是，咨询者和专家更多地是在幕后；许多呈现者都是新参加讨论会的，并带来了许多新的思想。Kent Beck，Martin Fowler，Ward Cunningham，以及其他老资格的人都没有出席。但是，研讨会兴旺起来了。 依我来看，经验式的研讨会是最能够给人深刻印象的指示器，这次的事情是不同的。我们有超过二十个的参与者，他们中的十三位都是真正的软件开发专家！我们集中在度量什么以及什么对度量是重要的上面。我们分成了两个组，我们分别关注哪些度量对商业和实践者是重要的。我们的目标是非常雄伟的。我们希望不只是确定我们应当度量的东西，还应当确定我们应当如何度量和分析数据，以及哪些种类的实验是最合适的。研讨会的结果将马上被贴出来，并且我将会在将来的专栏中包含他们的链接。 另一个有益的迹象是，研讨会比往年吸引了软件开发团体的更广泛的领域。进行了其它过程的讨论，如RUP和DSDM（动态系统开发方法）。Philippe Kruchten，他在RUP的发展方面很有影响力，并且现在在Vancouver的大不列颠哥伦比亚大学授课，提议了一个有关XP中体系构架角色的讨论，以及在Open Space区域中的其它敏捷方法。 7 参加此次研讨会的大多数人看起来都认为，体系构架应该单独进行构建，特别是在大的项目中。然而，有少数人争论说，体系构架只是在你关注XP实践时自然而然地进行发展。 在整个研讨会中，都是参与者之间的有益辩论和对话。Mary Poppendieck谈论了社团为了跨越分歧而讨论主要方面应当关注哪些内容。她谈到，关键是要获取好的用户参考。早期没有采用的组织将会做出一个采购决定，该决定是基于在他们的地区中一直使用一个产品的其它组织有多成功，而不管其它数据销售商可能展现了什么。 与Mary Poppendieck形成对比的是，Craig Larman主张，收集有关实践有效性的实际数据是获得更多用户的关键。依我来看，她结束时的主要讲话是研讨会的重点。他谈论了敏捷过程的“历史和根据”，回顾了瀑布模型，螺旋模型，以及DoD的 8 2167和2167A生命周期模型。他仔细地看了一下像Winston Royce这样人的想法如何被误解了，以及Royce后来是如何由于将瀑布模型强行用于产业界而受到了不公正的惩罚。Craig指出了一些人们被错误引用的详细地方，导致了多年的误解和错误传播。 真正使得他的谈话那么重要的是他没有同样地去推动敏捷。他真正关心的是人们成为高质量软件的有效开发人员；敏捷实践只是工具包中的工具。他的主要观点是，隐藏在敏捷后面的许多概念已经存在了一段时间了，现在我们正在重新发现它们－－即使许多人在这些年里迷了路。 回页首 一个成熟的XP将会导致更宽广的过程采用 我前面提及到，XP/Agile Universe 2004是最新的XP/敏捷领域研讨会。这是好的。下一年，它将会与敏捷开发研讨会合并，成为敏捷方法方面的主要研讨会。让两个研讨会分开会伤害敏捷活动。许多人承认这一点，但是还需要花时间将所有会议汇集在一起，形成一个单一的研讨会。 明年我会有两个预测。首先，敏捷实践的使用将会有一个非常显著的增长。敏捷方法，特别是XP，非常适用于小团队，并且像Grady Booch几年以前说明的那样，大多数的软件开发是由五到九个人的团队进行的。我的第二个预测是，随着敏捷实践的采用不断增长，其它方法和过程的采用，例如RUP，将会怎样呢。为什么？尽管XP在合适的时候是有效的，但是大多数团队不能简单地采用所有实践；它们对于较大的组织不太适合，并且不能覆盖全部的软件开发生命周期。 作为替代，许多人将会看到，裁减一个像RUP这样的一个过程框架以得到一个敏捷实例，进行产品的每次发布，这样会变得更容易些。更多的中等规模和大的组织将会认识到拥有一个灵活的、可定制的过程的好处，并且将想要他们的过程得到可用的最佳实践。如果经验论者持续进行下去，度量和宣扬这些实践可以产生的益处，那么越来越多的组织将会看到光明。 今天，艺术级的软件开发过程都基于迭代或者螺旋开发模型。很多组织都理解尽早缓解风险、用户驱动的开发和其它迭代开发范例的价值。但是由于文化和操作上的障碍，他们怀疑他们的组织能不能采用这些最佳实践。 本文描述了在你采用迭代开发时可能遭遇的文化上的挑战，以及如何应对这些挑战的建议。将来的文章将处理那些阻碍迭代开发的问题（如财务计划、资源问题、技术操作等）。在本文中，我们描述： 迭代开发的简要概述 采用迭代开发时的文化挑战的概述 从组织变革专家得到的最佳实践以及这些实践如何应用到迭代开发的说明 克服采用迭代开发的挑战的学习 回页首 什么是最佳实践？为什么它这么重要？ 迭代或者螺旋开发模型已经提出超过十年了，Barry Boehm’的文章“A Spiral Model of Software Development and Enhancement," 1 是把这个实践引入到现代软件开发的先行者。他的工作解释了如何开发增量的系统、按照风险排列优先级、以及反对使用传统的序列的瀑布模型。 迭代开发是一种软件开发方法，它的重点在于尽早检验可执行的软件。在瀑布模型中，你在需求分析中产生大量文档，到设计，再到开发，到测试等一系列过程。与之相对，在迭代开发中，系统从应用程序的一部分的实际实现开始开发，随着时间推移不断增加它的功能。每次迭代包括分析、设计、构建、测试的组合过程。通过每次迭代，项目组关心的功能在迭代中通过对架构和商业价值等的风险评估中被确认。在每次迭代时，增量的设计，编码和测试。每次迭代都验证系统架构，保证需求和干系人的要求，以及软件质量。 迭代开发过程强调实际的、产生可见的结果的项目过程。它给最终用户和干系人以可见的项目实际进展情况，而不是感觉和主观的进展情况。这是有可能的，因为在每次迭代中都有可用的系统的版本用来检查和验证。这是一个重要的概念：在迭代开发的实践中，软件组最关注的是结果。 回页首 采用迭代开发的组织将面对什么样的挑战？ 迭代开发模型已经证明是一个软件开发的优越的方法。但是按照November/December 2003 IEEE Software Magazine 2 的描述，仅有大约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：The Competing Values Framework，由 Kim Cameron 和 Robert Quinn提出 理解个体如何看待文化将使你洞察你在处理的组织的类型，并因此确定在你采用迭代开发时哪些行为需要改变。例如，如果你的组织集中在结果上，而忽略如何达到这些结果，这些组织很可能遭受比较低的信任，因此有比较低的士气。正如我们下一节的讨论，这种缺乏信任将导致组织严酷地细化合同和规格。这种早期关注细节将导致与迭代或自适应方法相反的僵化。人们可能害怕自己做决定，并不履行组织的意见，这经常导致改变现状。这将导致在突然出现问题时产生阻碍成功的影响，没有人想要冒着组织责难的风险提出组织不想处理的问题。在后面的节中，我们给出了一个评估你的组织文化的方法，以及如何帮助你计划移植到迭代开发。 采用迭代开发的文化阻碍 现在，让我们调查阻碍采用迭代开发的文化问题。图1显示了这些问题： 图 1： 阻碍采用迭代方法的文化问题 工作在高或者低信任的组织中 不管你的组织有内部的开发组还是有外部第三方的采购项目，在商业组和开发组的对抗关系都是存在的。两个组经常以对抗的态度共同工作。 缺乏信任经常导致一种被文档中每件事情困扰的文化。组织倾向于过度在创建合同和规格上工作，而不是在设计、开发和集成上。实际情况是这些合同从来不会产生有意义的结果；他们只是在一旦出现问题时定义一个同对手作战的战场。当你有证据说“项目失败的原因时我们没有正确的需求”时，你的胜利实际上是没有意义的，没有人，包括你的用户，实际上赢了。 不要误解，我并不是建议文档没有用处，他们是商业世界生活的一部分。高度的信任并不意味着每个人都必须到处收集，互相联合，唱“Kum Ba Ya." 然而，当软件需求的细节嵌入到合同中时，你的组织可能有信任问题。要点是在与其它人的信任和高层文档协定之间找到平衡。 我们应该集中在保证我们有的好的工作关系和通讯上，以便我们不会在碰到第一个麻烦时就结束。如果主要领导者能够鼓励好奇新和创造性思维，如果他们集中在共享的前景，你可以创建一个有开放和诚实的通信的组织。我们下面将讨论这一点。 寻找现实或从现实隐藏起来 在太多的组织中，文化并不鼓励它的成员寻找和面对风险，揭出那些不愉快的实施，或者询问难啃的问题。实事上，在他们听到坏消息时，有一种“干掉报信者”的倾向。为了描述怎样不和影响组织的残酷的事实对抗，Jim Collins, 在他的书 Good to Great中，描述了同Admiral Jim Stockdale, 越战期间北越最高司令官的会见。Collins boils 用下面的陈述简述了面对事实的训练：“你必须从不怀疑你将成功的信念－－你从来不会负担失败－－在面对最残酷的事实时保持纪律，不管它们可能是什么” Collins 称这个训练为 Stockdale Paradox，并认为这种对矛盾的认可是一个组织变得伟大的共同特征。这个训练也适用于软件开发领域。很多开发组织开始于不切实际的过于理想的日程、范围和预算。与现实相比，我们更愿意处理希望。这种倾向将导致低信任的环境，给组织带来灾难。 术语 迭代开发。一种计划好的重新工作的有序方法，应用软件或系统是以较小的增量方式进行开发的。 Competing Values Framework。理解组织文化的关键维度的一种模型。 The Stockdale Paradox。保留你将在最后获胜的信念，而不管困难和同时所面临的你目前现实的最残酷的事实，无论它们可能是什么。 执行导向。关注于结果，而不是活动。 有无数的组织在面对严酷的事实失败的故事，如失去市场优势，破产，和其它财富的逆转。失败现在也经常出现在软件开发项目中。这种失败如何在软件项目中表现？ 高的目标通常可以激励商业组，同时他们经常受挫于工程组。在工程组更加集中在缺乏注意的严酷事实中时，商业组正在“射月亮”。 鼓励或阻碍好奇心 在项目进展时，没有人想要问项目是否能够真正达到它的目标。项目成员习惯于忽略在项目出轨时应该觉察到的风险。这种满足，或者至少是如意算盘，是对项目成功的潜在的危害。有点偏执狂是一件好事。正如 IBM Rational的Walker Royce说的：“没有人挖开石头，寻找下面的丑陋的弯曲的东西。”开发和接受预先寻找风险的习惯是采用迭代方法的基础点。 为什么我们不愿意提问题？为什么我们象鸵鸟一样把脑袋埋到沙子中？我涉及的一些项目正在遭受这些问题。我们总是让我们变得太乐观。我们不去问诸如：“你怎么知道我们在集成原有系统时不会出问题？”或者“如果我们必须构建而不是买这个部件时会发生什么？”这样的问题。不问那些棘手的问题可以给你自己以错误的安全感。仅仅由于你没有踩到地雷上并不意味着没有地雷。 我以前的Georgia州立大学组织行为学教授 Dr. Louis St. Peter说过， “在我们长大时我们经常停止好奇心，是由于我们学的变得有智慧了，有智慧的意思就是已经知道了正确的答案（而不是问更好的问题）。”BusinessThink 7 的作者也认为，好奇心是找到正确的问题的解决方法的基本元素。不幸的是，开发组的成员简单接受在他们在开发确实必要被问及的问题的解决方案。相对于为客户解决理解被处理的问题，我们简单地“做那些告诉我们的事情”，去构建系统。 当他们真正去问那些他们应该问的问题而收到惩罚时，开发者经常学会不问问题。他们也会因为害怕被人知道他们的无知或者缺乏专业知识而不问问题。我们在会议中试图听从那些不理解的讲述。我们环顾房间，我们点头同意。我们并没有认识到身体语言覆盖的更多的是什么－－没有人理解那些讲述。它给你举手澄清问题的勇气。 人们也为了避免导致冲突而不问问题。冲突可以是好事也可以是坏事，依赖于冲突的类型和冲突双方的回应。正确的冲突形式将导致更好的作决定。这里讨论两种类型的冲突： C-型冲突，或者“认知冲突," 集中在问题和与问题相关的不同意见上。在这种冲突中，团队成员不同意主要是由于他们不同的经验和专门知识引导他们对问题和可能的解决有不同的看法。C-型冲突将使人们主动检查、对比、妥协这些不同之处，并产生最好可能的结果。 A-型冲突, 或者 “情感冲突," 在产生不同意见时引入了个人情绪的反应而不是职业。A-型冲突经常导致的结果是：敌意、愤怒、怨恨、不信任、冷嘲热讽和冷漠。因此，不象C-型冲突，A-型冲突通过阻止团队通过类似C-型冲突的活动而破坏团队的效能。这对团队是关键的问题。 8 不管在你的组织中人们出于什么原因不问问题，要保证迭代开发成功，这种行为必须改变。文化必须培养C-型冲突，并允许任何人问尖锐的问题并得到真正的、合理的答案。 执行 vs. 活动的吸引 当然，软件开发的目标是产生工作软件。你的过程－－你创建软件的方法－－影响最终产品的质量。因此你的过程就意味着产生高质量的产品，而不是集中在你的努力上。在本节，我们讨论执行和在工作时遭遇的阻碍。 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时鼓吹adoption through execution。 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：既然团队变换到迭代开发，项目领导和执行者能够挑战他们认为困难的角色和责任 适合迭代的文化特征 是否有一个理想中的迭代开发的文化的轮廓？这个问题只能在进行更多研究后回答；但是，可以有把握地声称，一个和谐的文化是重要的。不管现存的文化是什么样子，总有同哪些功能紊乱的文化单元斗争的路线。下面列出一些文化特征，它们描述了如果我们希望采用迭代开发，我们的组织必须构建的文化和环境的一些特征。 High trust. 客户，干系人和软件团队都相信他们正在朝向同一个目标工作。 Open and collaborative. 风险被按照现实的风格公开讨论。我们重视指导和建立易于助人的领导。 Passion for problem solving. 团队积极寻找问题的根源，并致力于解决问题。我们不仅仅是由于有人那样说了才构建和部署解决方案；我们真正理解在问题和解决之间的关系。 Curiosity is encouraged.问每件事情，理解假设 Customer results driven. 什么与用户接受他们需要的结果有关，不仅仅是文档化的需求。 Team members are empowered and accountable. 项目组被授予解决发生问题的权威，而不是相反，被很多监督委员会、功能管理组和过程堆捆住手脚。 Organizational politics are spurned. 高于一切的价值是我们共享我们的目标：给我们的客户提供价值。我们不去关心在成功完成项目后谁获得荣誉，谁得到提升。 Execution oriented. 优先让事情完成－－并不是简单地按照活动顺序做－－是显然的 。 回页首 结论 很多试图采用迭代开发的组织都失败了，因为这些拥护者在面对组织特有的文化问题时没有足够的准备。你可以通过在转变前有效地评估，然后理解文化来克服这些迭代开发的挑战。通过实际执行来采用过程的变更是使变更实际和能够为干系人接受的关键因素。文化的改变不是来自于陈词滥调和口号，而是来自于创建新的成功的故事并变成标准。 回页首 注释 1Boehm, B. W., “A Spiral Model of Software Development and Enhancement," Computer magazine, May 1988, Vol. 21, Issue 5, pp. 61-72 2Michael Cusumano, Alan MacCormack, Chris F. Kemerer, Bill Crandall, “Software Development Worldwide: The State of the Practice", IEEE Software, November/December Volume 20. No 6, p p. 28-34 3Gordon MacKenzie, Orbiting the Giant Hairball, Viking, 1996 4Joseph H. Boyett, Jimmie T. Boyett, The Guru Guide, Wiley, 2000 5Murray Cantor, from his presentation at the IBM Rational Software Developer and User Conference 2004 6Jeffrey Liker, The Toyota Way: 14 Management Principles From the World’s Greatest Manufacturer, McGraw-Hill, 2003 7Dave Marcum, Steve Smith, Mahan Khalsa, businessThink: Rules for Getting It Right -- Now and No Matter What!, Franklin Covey Co., 2002 8Dr. Louis St. Peter 9Larry Bossidy and Ram Charan, Execution, Crown Publishing, 2002 10Ibid. 11Kim S. Cameron, Robert E. Quinn, Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework, Addison-Wesley, 1999 12John P. Kotter, Leading Change, Harvard Business Press, 1996 13June 2004: http://www.ibm.com/developerworks/rational/library/4866.htm 14J. Steward Black and Hal B. Gregersen, Leading Strategic Change: Breaking Through the Brain Barrier, Financial Times Prentice Hall, 2002 15Adapted from Per Kroll 回页首 致谢 Kurt Bittner, Murray Cantor, Saif Islam, Walker Royce, 和 Dr. Louis St. Peter的思想和文章都帮助我构思了本文的关键章节。也感谢很多读过本文并反馈的其他同事、朋友和客户 回页首 注释 1YAGNI 意思是 “You Ain’t Gonna Need It," ，并且 DTSTTCPW 意味着 “Do the Simplest Thing That Could Possibly Work." 2Martin Fowler 是 UML Distilled的作者，曾经出版的最流行的UML书之一。 3我在The Rational Edge的 March 2001 和 April 2001 期刊中写了有关内容。 4Laurie Williams写的有关她的度量配对编程的效率和其它实践。参见她的Web主页：http://collaboration.csc./laurie/publications.html 5参见The Rational Edge的2002年10月 期刊中的有关实践描述信息的文章。 6研讨会的名字每年改一个数字。第一次研讨会是XP2000，并且今年是XP2004。 7Open Space就是参与者提出讨论主题的地方，并且如果有足够的人感兴趣，一个讨论就开始了。 8DoD 是美国国防部。 参考资料 敏捷联盟Web站点：http://www./home 这是一个查找有关敏捷的最新发展的好地方。 Alistair Cockburn, Agile Software Development. Addison-Wesley, 2001. Craig Larman, Agile and Iterative Development: A Manager’s Guide. Addison-Wesley, 2003. Giancarlo Succi 和 Michele Marchesi, Extreme Programming Examined. Addison Wesley, 2001. Laurie Williams, et al., “Strengthening the Case for Pair Programming." IEEE Software, July/August 2000. 关于作者 Gary Pollice是地处伍斯特的伍斯特工学院的一名教授。他教授软件工程、设计、测试和其它计算机科学课程，也指导学生项目。在进入学术界之前，他花了三十五年多的时间开发各种不同种类的软件，从商业软件到编译器和工具。他的最新行业工作是在IBM Rational软件，在那里以“RUP老怪物”而闻名，并且是最初的Rational Suite团队中的一名成员。他是由Addison-Wesley于2004出版的Software Development for Small Teams: A RUP-Centric Approach,的主要作者。他拥有一个数学学士学位和计算机科学硕士学位。