Royce：Rational实现流程自动化 提高协作效率

ZDNet至顶网软件频道消息 8月26日，以“软件无处不在”为主题的IBM Rational软件创新论坛Innovate 2011在北京召开。大会分享了Rational全球和大中华区最新的发展策略和创新理念，介绍了包括系统平台开发及嵌入式系统开发、企业现代化、协作式开发等一系列创新开发技术及解决方案。

IBM Rational首席软件经济学家Walker Royce进行了《要更敏捷地改善软件经济学》的主题演讲。Royce表示，改善软件经济学是Rational的使命，也是Rational的独特优势。改善经济学意味着创造更大的价值，而且使用更少的成本和资源。

Royce表示，软件开发更多是经济学意义上的学科，而不是一个工程学学科。软件的限制因素是用户的需要，设计部、业务部的需求，是集成、项目进化和资源预测人员想象力的边缘。而不确定性会导致下游的浪费。软件项目如果使用传统的工程管理方法，会有40%的时间和精力用在返工当中而白白浪费。认为不确定性比较低的传统的工程管理模式，对于创新性很强的软件项目是不适宜的。 

为了解决不确定性，必须要有可衡量的渐进的步骤，而优化方法是平衡各利益相关方利益的解决方案。优化包括指导、控制、工具以及动态的变化。优化首先要认清现状，然后再通过可衡量式的方法去进行改善。通过管理不确定性来指导项目，有很好的衡量尺度，并可以带来敏捷。

Rational软件和系统交付平台能够为我们的流程提供自动化，能够为我们的协作提高效率，能够给我们的流程提供在工具方面的支持，在工具方面的自动化。

以下为演讲实录：

各位早上好。改善软件经济学是Rational的使命，也是我们在市场上的独特优势，改善一个经济学意味着创造出更大的价值，而使用更少的成本和资源，意味着更多的质量、更多的特性、更多的性能，或者对你的客户更有价值的东西。少，意味着更少的时间、更少的管理费用、更少的资源投入。我们软件的生产效率实际上在你们的组织当中是非常关键的，否则的话，你们就不会今天来到这里。 

刚才Kristof Kloeckner谈了三个主要的主题，想变得更加敏捷要改善软件经济学的话，集成、协作和优化。为什么说他们这么重要呢？你怎么样去衡量他们呢？我们怎么样来去证明我们就有更好的软件经济学呢？这是我想讨论的话题。复杂既是一个机会，同时也是一个风险，我指的是在我们开发和交付更智能、更互联的系统和应用当中。对于高管，架构师和项目经理来说，这样一个复杂性可以直接的转变为不确定性。

这里我们有五个不确定性的水平，由于这么高水平的不确定性，软件的开发其实更多是经济学意义上的学科，而不是一个工程学的学科。这个说法可能会有一些争议，而且非常的激进，我给大家提供我的理由。工程有物理学和材料物理属性的规律，来限制他们的创造力。在软件当中，我们的限制主要是人的想象，是用户需要、设计、业务部需求、集成、项目进化和资源预测中人的想象力的边缘。我们的预测主要是由于价值的判断，统计学的分析，还有预测等等，更像是经济学科的一些规律的掌控。没有解决的不确定性会展现为下游的浪费，软件的项目如果是使用传统的工程管理方法，会花掉他们40%的时间和精力，放在返工当中或者是浪费。所以传统的工程管理模式，认为不确定性是比较低的，他们对于创新性的软件项目是不利的。 

为了解决这样的不确定性，我们必须要有可衡量的渐进的步骤，而且优化我们的方法来能够平衡各个利益相关方利益的解决方案。我们选择优化这个词儿，因为它有非常积极的含义，包括指导、控制、工具以及动态的变化。为了优化一件东西，你必须要能够说清楚现在的情况，同时能够可衡量式的去改善它。科学家们将衡量作为一种观察，他可以增加你的知识，同时降低对于你所衡量东西的不确定性。我们将价值的论断作为经济成果的一个概率分布，我们如果能够降低不确定性，就可以看到这些分布的变量，分布的差异会随着时间流失而减少。通过管理不确定性来指导项目，有很好的衡量尺度，是经济管理的核心实践 这可以带来敏捷。

更少的不确定性会给我们在利益相关方当中带来更诚实、更值得信任的交流。信任是一个任何敏捷团队核心能力，我们怎样能够在经济管理中取得成功，我们应该衡量什么呢？在过去20年里，我们计划、回顾和评估了上千个在100多个组织中间的转型。这里是三个方面的成功模型，还有三个方面的共同失败的教训。首先我们去规划你的节点，然后去你的活动和临时检查点，作为可显示的结果，这样能够进行提前的集合，而之后再进行单位的测试。我们错误的精确观念是我们工作出现停止的一个根源，下游的一些浪费和重复工作都是由于我们错误的观点导致的，我们建立起五位数精确的需求，而你只有一位数是精确的，消费者对需求的理解，是整个软件开发当中失败的一个主要原因。整个事实上的一些改变和质量的参数，是有可执行的代码和测试基础导致的，为了实现更加忠实的进程交换和质量的趋势，我们必须推动所有的节点和度量，以一种可持续和可显示的能力来做到所有的方面都包括了说明模式和计划，所有这些计划都是我们的一种臆想，这些是有价值的，但是我们需要去度量它。 

我们在改变可执行软件期限，尤其是改变成本趋势方面是我们进行衡量真正的措施。敏捷意味着我们能够很容易的进行更改，而我们同时需要对于更改的趋势进行量化，仅仅是在架构方面进行，还有在流程的忠实性方面来推动变更的成本。敏捷不仅仅只是一个程序上的、流程上的特性，我们首先会做简单的事情，先做出一些进展，然后在这样做的时候是没有经济上的任何好处。我们推迟解决方案的可持续性，就减少了成功的可能性。这些建议都是不好的，现在我们希望能够跳出自己以往思维的模式，现在我想会给你提供一些判断的基础，能够给你显示一些核心的参数模型，这样能够显示我们可以去衡量我们的改进目标，同时也能够进行成功的开发转型，同时也进行健康的经济管理。

在左边的这个图，是我们典型的传统工程管理，进行软件创新项目的基准，在右边这个图是我们目标模型，特别是成果的目标模型，我们能够期待着通过健康的工程，真正的实现我们的灵活性。在过去的几十年里，我们经历了很多的上千个项目，从左边这样的项目，中间只有几十个项目能够真正的显示敏捷。下面三个方面的参数，能够很清楚的量化你所做的工作。首先是规划进展，这是在传统的工程管理中是通过节点的成绩进行度量的，而它是在所有的支持工建生产中能够实现的价值，大部分的文件都是基于活动的计划，规划的进展是可以通过我们在规划的性能、使用者故事和我们可显示的这种进展，以一种基于结果的计划才能够得到更好的衡量。 

技术上的进步，我们在可执行和可测试方面代码的比例，左边是对于大部分的软件开发组织来讲都是非常熟悉的，大部分都是通过瀑布式的模式进行开发，他们花了大约40%的资源，甚至更多，在进行过多的浪费和进行返工，特别是在最后的阶段出现这种情况，而典型的情况是这种线性的方式是在最终会造成具有灾难性的困难，而这种返工最终会导致我们整个架构忠实度的降低。右边可以显示更加忠实的进展秩序，我们工作的退步或者工作中受到干扰，不确定性能够得到解决。作为基础架构，还有我们的规划本身是进行重新规划，或者说能够和我们的利益相关者进行交流，这样是一种很好的经济管理的方案。

最左边的图显示我们传统的早期评估，当时我们看到的是一种很低的不确定性，这样会使得我们一开始获得比较错误的，我们感觉工程进展顺利的印象，会在很多方面最终出现问题的时候，会导致非常严重的后果。右边的图可以看到更加忠实的，在不同的利益相关方能够有很好的展示，还可以在很多情况下能够平衡所有的利益相关方。当我们一开始的时候就能够对一些不确定性进行介入的话，这样随着项目的进展不确定性会不断的减少。 

项目的改变越简单的话，最终要实现它的需求性能就越简单，更为重要的这种质量的参数能够帮助我们进行度量，这里有三个方面参数：成熟和缺陷趋势，很多组织都跟踪这样的参数。模块化或者是在时间尺度内的浪费的代码趋势，这种参数是在我们的可执行的参数库中所实现的。适应性和返工趋势，这是另外一个变更成本的度量方式。所有这些参数可以工具化，可以得到执行，通过一种非常简单的，在你的变更中通过工具实现，在你的测试管理平台上实现，他们可以直接通过你的代码和测试基线中得到实现，这样能够很好的得到改进。传统的项目中，很多时候是在整个生命周期很晚的阶段才会出现不好的情况。正如我们左边的图所显示的，如果说你在经历这样的情况，你肯定是在一个传统的瀑布式的开发模式中，你的流程可能会非常的成熟，但是它是非常模式化的。现在这种经济的管理，在早期就发现这种非常关键、非常有潜在后果的不确定性，当它发现的时候，我们就可以让变革变得更加简单。而且我们也可以以一种可预测的方式，在生命周期的早期就可以做到。右边的图就能够实现，我们如何去推动这种做法呢？最好的方法就是在集成的阶段，能够在你的单元测试之前就就产生集成活动，这样帮助你一开始在架构挑战方面就解决更加有风险的方面。而再去做更多的投资，去做单元的测试。当我们进行持续集成的话，我们有效的去执行，在生命周期晚期的时候就变得更加有预测性、更加的直接。这就是真正的敏捷度量。 

从计量经济学的角度，我们的改善可以通过集成、协作、优化方面来共同的实现。这些方面可以在我们的平台上都能够实现，而我们的组织可以依靠我们的分析引擎来得到更强有力的统计数据。我们如何去为投资、已经改善的软件经济学找到理由呢？这是一个非常简单的框架来帮助提升我们的业务成果，特别是在软件交付中的成果。等于是大致显示我们这种软件成本评估的模型，这些模型可以非常准确的去预测我们的，准确度只能达到20%，时间上是75%。我已经通过一种更加简单的方式在四个参数方面减少20%到30%的参数。首先是复杂度，包括人为产生的东西，包括代码、模式、文件、测试。二是敏捷，这就包括有1到1.2这样的数字，量化我们程序中的有效性，这就意味着你的软件在这个过程中没有实现经济上的规模效应。三是协作，使得量化我们技能经验和团队合作。最终是自动化，能够帮助我们的流程能够工具化，如果来看这个等式，在我们的认知实证的数据中进行研究的话，这四个参数是有优先秩序的，10%的复杂度的减少，要比10%的敏捷度的增加更加有价值。这就意味着超过10%的更好的协作或者是10%更多的自动化，工具非常重要，在我们的经验中知道，我们需要在减少复杂度、增加敏捷度和增加协作方面有更多经济上的好处。

还有在中心使用方面所进行的投资，可以帮助大家，只需要也大概几千条的这样人类所创造的大脑，就可以实现几百万条的程序。我们对于敏捷的方法的投入，也可以帮助你们避免失败的循环，从而实现成功的循环，我们在Jazz当中的评论投资也是可以促进你们的协作。还有我们的服务以及我们的合作伙伴的生态系统也可以提供更多的支持。

我们同时也认识到，我们需要将我们的工具作为一种成功的工具方法，让他们在所有的工作人员当中传播。大家可以看到，这是有几点是改善我们软件经济学的方法和维度，这里是参数成本的模型，在很多书里都提到这些内容。因为我们知道价值会比取得价值的成本会高很多，也就是这里面每一个维度都可以帮我们实现很高的投资回报。我们要能够提高自动化的能力、协作的能力，都可以使得我们的投资回报提高。方法主要是通过改善我们的敏捷性，同时通过我们组织的重新使用来降低复杂性。这里的范围是展现我们不确定性的内容、创新的内容以及我们现有文化变化的情况。在过去的几年当中，Rational一直是主要关注点是增强协作，以及实现规模性的敏捷性。在保护我们市场这一块，因为这些发展非常重要，我们看到市场的领导者会鹤立鸡群。在开源的工具和自主知识产权的工具可以让你非常低的成本实现自动化，但是如果没有一个整合的协作层以及对于流程实施的支持，他们是没有办法为改善团队或者组织的生产效率提供有效的基础，也无法为提供在高水平实现基于资产的重新使用提供很好的基础。我们Jazz的努力，尤其是它的架构是非常好的例子，它说明了能够实现一个敏捷平台的以集成、以整合为主的精神，我们Jazz的架构是不同层次服务的整合，我们的协作是所有的整合努力的基础。我们将会尽可能对这样的平台投资，使得优化你们经济的管理以及你们以整合为先的团队精神。 

可度量的改善和敏捷性，其实是和其他的竞争对手的区别，因为我们要提高软件的经济学，所谓可度量的改进是意味着在持续不断的整合里程碑的过程当中不断的改善、不断的增长。它实际上是可以帮助一个团队更好的协作，同时在他们的流程和产品当中解决不确定性，尽量在早期解决这样的问题。敏捷意味着快速的反应，你的改变速度应该是你的资产，而不是你的负面因素。敏捷最好是能够通过以整合为先的焦点，同时敏捷最好是随着时间的流失所带来变更的成本来作为一个衡量的标准。当你发现你们的一个团队在做软件更改的时候，如果从几周的时间变成几天的时间，这个团队就变得更加敏捷。同时，我们减少浪费、减少返工，而且能够更多的进行创新，可以更加具有进取心，增加更好的质量和更多的特性，或者是更早的交付，这些都是我们可以实现的优势。 

你可能读过很多关于敏捷方法的书籍，但是你可能没有看到那么多成功的项目，其中有很多的关于敏捷结果的资料。如果写一本书，写一本关于抽象的、关于项目管理的书是很容易，但是管理一个真正的项目是很难的。因为这里有很多的地雷阵，有不确定性，你做任何决策的时候都是有很多风险的，这就是很难的，我们应该去推崇那些、尊重那些行业当中的从业者，而不仅仅是思想、舆论的领导者，好的想法是很容易想到的，但是好的实践却是摸爬滚打出来的，我们从业者的领导人，他们解决了不确定性，同时把项目由抽象变成实际，他们对于软件行业的创新至关重要。我们在今天的会议上会给大家提供很多技术的峰会，这里会跟大家分享从业者的经验，我们将会谈到可度量的改进维度，希望今天的会议能够向你们展现在我们的客户以及我们IBM公司的从业者的领袖风采。

如果大家需要更多的关于我谈的一些技术问题的信息，可以从三个地方获得：一是可以从开发者的网络，或者是从我的Walker Royce的网站，还有请你们当地的团队来获得这样的信息，来了解他们所有的知识可以应用到你们的业务当中去。谢谢各位。