软件经济学四：改进软件开发过程



本文来源：谢老师的博客

现实中的软件项目过程与计划都是极为复杂的，他们象蛛网一样既互相支持又互相影响。在整个过程体系中，既有并行关系，又有串行关系。而且，随着项目越来越大，计划中所增加的管理性步骤也就越来越多，管理成本越来越高。如何建立合理的过程体系？如何降低管理成本？如何在变动的环境下而不至于发生混乱？事实上，过程体系越复杂，应变能力就越差，但是没有合理的过程，一个大型项目开发是根本无法运转的，这中间如何实现平衡？这都是在过程改进中需要仔细斟酌的问题。
   
    1，从系统的角度看软件过程
   
    我们强调了软件易于变化的特点，但并不等于说不需要规范，正是软件的这种易于变化性，规范就显得极其重要。这里有一个关于东西方文化的讨论：西方文化的特点是对于规则的不懈追求，由此衍生出了历史上写下灿烂篇章的伟大科学家。东方文化的特点是追求变化，在千变万化的世界中寻求一种抽象。这两种文化事实上各有利弊：钢铁般的规则往往缺乏灵活性，象水一样的流动往往难以控制，只有把这两者结合起来，才可能形成伟大的世界级的文化。因此，在定义规则的时候，我们必须考虑如何让变化变得可控？或者说如何让变化处在一个可以控制的范围内？这些都是极其考验我们智慧的东西。
    规范的价值观是来自于这样的基本信念：如果我们仅仅是做一个纸飞机，那我们就没有必要写下详细计划（花20分钟写计划再花20秒把飞机折出来，无疑是个愚蠢行为），这样也是安全的，你可以快速的修改，即使返工也是经济和高效的。但是，如果你是制造一家大型客机，那么用纸飞机的方法来实现同样也是愚蠢的，如果没有详细的前期设计，那整个飞机制造过程就是一个漫长、混乱和昂贵的过程。它将产生大量应该避免的返工，甚至永远不可能完成，
    项目越复杂，规范的意义就愈重要。在一些非常大的项目中，很多人试图避开这个过程，结果大多数都失败了。大量实践表明，规范方法尽管在管理上的成本提高了，但远远比不遵从这些方法（游击队似的疯狂开发）更经济有效，因为它减少了意外和返工的工作量。更重要的是，它可以保证每个人都知道自己该干什么事情，确保组织运转成为可能。严格的基线和工作产品的静态测试，帮助人们提高了整体质量，并有助于人们尽早发现更多的缺陷。
    正确的“规范化”并不会抑止人们的创造力，相反它使得团队可以大规模地复用前人积累的智慧和财富。如果没有计划和规范，那一定是混乱和不一致的。尽管某些局部可能成功，但整体上可能永远也不会完成，所带来的管理成本可能更高。管理层所做的事情可能就是周而复始的协调、协调、再协调，这无疑是管理上的一场噩梦。
    为了解决这个问题，在一些高标准高质量的场合，人们开发出了符合系统工程的标准方法，供具体实施部门使用，例如中华人们共和国国家军用标准GJB5000A-2008，这也是目前国内最值得我们参考的过程模型。其中基本的过程之间的关系如下图所示。
 

 

    研究与改进软件过程需要更多地关注过程之间的关系，只有宏观把握住了关系，每一个具体的过程才能真正发挥作用。让我们仔细观察一下GJB5000A-2008过程之间的关系：从集成过程体系的角度来看，我们就会发现这个标准已经摒弃了传统的瀑布方法，各个过程之间充斥了复杂的增强和调节反馈回路、非线性的行为。整个体系的构造思想是迭代的、反馈的、不断进化的。因此，仅仅用传统的工程思想是无法构建符合GJB5000A-2008规范的过程体系的，我们的过程定义必须有这些反馈回路存在的位置，并把它们集成为一个现代的反馈过程体系。
    EPG小组成员必须成为系统思考者，与同事们一起从系统的角度寻求它们之间最佳的配合，在即将改变的大环境下，深入讨论因果关系、反馈回路以及由此带来的管理机制的变化，而不能仅仅成为一个按图索骥的教条主义者。如果不具备集成过程体系的能力，仅仅把某个过程看成独立的东西，文档写了一大堆，但是这些文档的效用却未必能发挥出来，   
    未经整合的各个领域过程定义，是不宜于指导项目的实施和控制的，只有整合成一套集成过程体系之后，才具备指导实践的实质性意义，对此我们要有充分的理解。集成过程体系并不是一套约定俗成的概念和知识，而是一种观察问题的观念和解决问题的方法，最终体现为一种理解和实施的能力。
    过程改进的主要目的是：改进生产性活动的结果，最小化管理性活动对于人员和进度安排的影响。在过程改进中，有三个方面的问题最需要我们来关注：
    1）如何使迭代式过程成为一种可控的规则？
    2）如何采用优先关注架构的策略以及使用基于组件的开发来解决一些重要的风险？
    3）如何寻找团队目前采用的工程实践的缺陷加以改进？其中最需要关注的点在于：需求获取、需求管理、变更管理以及贯穿整个生命周期的质量评估。

   

    2，把迭代式过程定义为可控的规则

   

    当我们强调迭代过程的时候，很多人告诉我说：我们现在的工作方法就是迭代的甚至是敏捷的，为什么还要强调这个道理呢？确实，迭代本身就是人们面对困境的时候一种自然反应，迭代之难并不是难在迭代本身，而是难在要与现代的软件开发规范结合起来，变成一种互相协调的规则，这就变得难度很大了。从管理学的角度来看，静态的线性的管理是相对容易的，但是动态的非线性管理难度是很大的。如何在动态过程中仍然保持有序？如何在有序的状态下实现高效？如何在规范框架之下通过迭代过程实现更高的经济效益？这都是考验我们智慧的难题。
    过程改进是否能产生深远影响，关键是我们如何把传统的瀑布工作方式转换为现代的迭代方式，并且把迭代工作模型以一种有序与规范的方法被定义出来，变成一种公共的可控的工作模型。传统瀑布工作方式的目标是每一阶段交付物都保持高度的精确性，以及前后之间精确的可追朔性。我们应该知道传统方法论的问题在于会导致如下缺陷：
    1）很晚才能够对需求达成真正的一致。
    2）项目集成被延至后期，很多缺陷直到最后在被发现。
    3）风险的发现也延至了项目的后期，导致项目更高的风险。
    4）功能分解是由需求驱动的，这在很多情况下并不一定是最佳解决方案。
    5）利益相关人员的关系敌对，而不是一个利益共同体。
    6）只关注文档和评审会，而没有关注用户真正需要的是可使用的软件。
    这些表现一般都会导致严重的非规模经济（项目规模越大，产品成本越高）。为了解决这个问题，我们需要理解现代敏捷软件开发（Agile Software Development）的价值观，其表述如下：
    我们正在揭示更好的软件开发方法，通过亲身实践和帮助他人实践，我们实现了下列价值： 
    个人与交互      胜过  开发过程与工具；  
    可用的软件      胜过  复杂的文档；
    寻求客户的合作  胜过  对合同的谈判；
    对变化的响应    胜过  始终遵循固定的计划。
    虽然右项也具有价值，但是我们认为左项具有更大的价值。 
    这个价值观认为：过程和工具是重要的，但流畅的人与人之间的交流更为重要。完备的文档并非坏事，但是首要的是，必须把注意力聚焦在最终的产品，也就是交付可用的软件上。无论是内部的项目规约或外部的法律合同，都不是坏的做法。但是仅有这些还不够充分。合同和项目规约也许界定了一些使合作双方能一起工作的边界范围，但是只有通过不断的协作，开发团队才可能期待互相理解，并最终交付出客户真正所需的东西。计划是重要的，但是不能是僵硬的无法变化的计划。对大多数软件开发项目而言，响应变化的能力是取得成功的关键要素。这些非常精辟的观点，能不能在我们制定的项目过程中体现？
    为了把现代迭代式开发过程嵌入到我们制定的标准工作框架中，使软件开发经济效益得到提高，我们需要考虑如下几个方面的问题：
    1）过程能不能在不断演进的抽象层次上，连续不断的重复从需求到测试的活动，这种连续不断的循环反馈有规则吗？如何控制？
    2）过程支不支持尽早获得对于架构级重要决策的高精确度的理解？
    3）过程能不能按照风险管理的优先级，让交付物在深度和广度上不断演化，而不是一个固态的东西？
    4）过程支不支持把一致性分析推迟到生命周期的后期？
更重要的是，当我们在按照GJB5000A-2008标准定义过程的时候，这些理念和方法被嵌入进去，还符不符合标准的共同目标和专用目标的要求，如何才能够符合？这些都需要我们对问题有更深入地研究。
    迭代并不是一种被人误解的随意方法，迭代方法的规则可以很严格，甚至可以用相当传统的语言来表达。关键的一点并不是在于是采用迭代描述、敏捷描述还是瀑布描述，而是从经济学角度是不是解决了根本问题，我们可以通过回顾来发现我们的问题所在。现在来看一下迭代和瀑布两种方法论在开发进度上的统计区别，如下图所示。

 

    很多企业的工作现实都告诉我们这样的场景：初期为了收集需求耗用了大量时间，严重推迟了项目真正开始的时间。当项目做到最后开始集成的时候，各个组件的接口和行为的不一致才被发现，开发团队被迫修修补补（重新设计根本没可能）。为了对这些不一致的修补进行测试，又耗用了更长的时间。当项目初步交付以后，用户的问题又到来，又是加班加点似乎永无休止的改动，结果最后交付的是一个迟到的、超预算的、脆弱的、维护起来极其昂贵的系统。我们需要问一下，过去我们是不是经常发生这样的情况？如果是，那采取什么方案来解决？

    从另一个方面来说，很多企业会花60%的时间来做集成和测试，包括修复瑕疵、频繁的返工。能不能尽可能利用自动化测试和集成工具？这些都是我们在过程改进中需要关注的问题。

 

 

    3，应用架构驱动的开发早期应对风险

 

    如何避免后期大范围长周期的系统集成呢？一个受到推荐的方法，就是利用架构驱动的开发。在大型复杂项目中使用迭代开发的时候，软件开发团队应该首先完成架构，架构是一个产品并且早期经过验证，这样一来就可以早期检测出设计的瑕疵并且得到解决。这种开发风格的结果，就是每个迭代周期快要结束的时候都有集成活动，以避免到了后期那种爆炸式的集成。所以在项目开始之初，我们应该首先透彻理解架构级别的需求，进行详细的架构设计，并且把它稳定下来，这样就能降低废品率和返工率，而且早期缓解高风险。
    将集成活动放到每个迭代周期，就可以利用每次迭代结束的演示来推动项目的进展。有缺陷可以在早期暴露出来，便于早期修复缺陷而不至于到后期发现缺陷束手无策。这些所谓缺陷有的是由于设计上的，更多的是由于双方对需求的理解不同造成的。在这样的迭代过程中，架构也会有一个不成熟的原型逐步成长为一个稳定的骨架，最后成长为一个可发布的产品。从认识论的角度，软件开发就是一个人们认识事物的过程，这也是一个对问题的理解逐步深入螺旋形上升的过程，符合人们认识事物的规律。
    在定义新的过程的时候，我们要注意著名的“80/20”原理。架构设计实际上考虑的是占20%的功能，但需要投入80%的精力。我们可以用这个视角来确定迭代开发哲学的一些关键特性。
    20%的需求消耗了80%的工作：不要在一开始就追求需求的高的精确度，这实际上是做不到的。在项目之初，主要需要理解那些关键的起驱动作用的需求。
    20%的组件消耗了80%的成本：要优先细化那些对成本影响最大的组件，以便在早期就透彻理解成本的驱动因素，并寻找解决方案。
    20%的组件导致了80%的错误：优先细化那些对于可靠性影响最大的组件，以便评审有足够的时间来优化这些组件。
    20%的变更导致了80%的废品和返工：应该优先细化那些对于变更敏感的组件，以便后期进行那些影响力大的变更。
    20%的组件消耗了80%的资源（性能、磁盘空间、内存）：早期细化那些对于性能影响大的组件，以便尽可能在早期完成对于可靠性、可变性和成本效益的工程权衡。
    20%的人完成了80%的工作：要保证早期团队是一个人数很少但高质量的团队，包括计划、需求、架构团队。高质量的架构交给一个平庸的构建团队也能成功。糟糕的架构及时交给一个专家及构建团队照样失败。
    无数事实告诉我们，越是早期发现和解决风险，项目的成功率就越高，项目的成本也就越低。架构驱动的开发是一种早期缓解高风险的艺术，在过程改进的时候是需要我们认真对待的。

 

    4，军用软件产品开发应用架构驱动的方法案例

 

    为了对质量要求严格的军用软件产品架构驱动的迭代开发有一个直观的理解，我们来看一个案例。本案例取自于Barry Boehm，Richard Turner所著的Balancing Agility and Discipline-A Guide for the Perplexed（平衡敏捷与规范-一个令人困惑问题的指南）一书，描述的时候经过了简化。虽然这个项目本身已经年代久远，但是他展现的方法论直到今天还对我们有所启迪。
    项目名称：命令中心处理和显示系统置换
    项目背景：这个项目是对美国早期的导弹警报系统命令中心进行再工程，它是典型的计划驱动项目，但使用了恰当的敏捷要素使项目获得成功。
    该项目客户为美国空军电子系统中心（USAF/ESC）使用者为美国太空指挥部、美国战略指挥部、美国国家指挥局以及所有具有核能力的指挥人员。这个项目的核心功能开发是1987-1991年间，虽然项目本身已经年代久远，但是他展现的方法论直到今天还对我们有所启迪。这个项目的特点如下：
    1）项目风险高而且很复杂：这个项目含有很多高风险因素，首先就是可靠性；另一个风险在于传感器接口、形势评估、应用关键算法再工程的能力；还有一个风险是美国国防部要求使用Ada，但项目中75个程序员虽然受过培训，但没有任何使用Ada的经验。
    2）项目使用军用软件标准：这个项目使用了美国国防部（DoD）确定的规程，包括一份合同和极其强调文档的DoD-STD-2167A软件开发标准。
    他们的做法有如下特点：
    1）在选择工具和修订过程中侧重于双赢
    这里所说的工具包括计划、标准、文档，项目团队在解决这个问题的时候采用了如下做法。首先他们发现，在军方项目办公室中，有许多特别开通而且面向结果的管理者。而开发团队公司的管理者也认为：取得成功的最好办法，是客户、维护者、开发者都成为赢家。于是他们把考虑问题的重点放在能带来双赢的个体和组织交互上面。首先，强调使用的过程和工具必须适应人与人之间的的交互而不是相反。其次，团队选择的工具必须是有助于相关人员成为赢家的过程和工具。
    2）应用工具和过程的例子
    开发团队认可DoD规定的标准，但对于其中里程碑内容重新定义为能反映涉众得成功条件。团队还根据规格说明开发了一些自动化工具用来验证完整性、一致性和可跟踪性，这种开发是一种重要的投资。
    3）建立高水平架构师队伍
    系统架构是围绕项目成员开发的，让经验不足的成员去开发Ada有很大的风险。在这个项目中，软件架构是由经验丰富的Ada人员开发的，而随后的模块分配给了经验按不足的人员，同时还开展了Ada技能方面的培训，以保证团队开发水准的快速提高。在架构设计的时候他们注意到：
    在处理Ada任务和并发处理的消息传递中间件中投入了大量的资源。
  提供了消息端口以便后来插入不同的应用功能包。
  为了早期验证性能，可以查入模拟器来确定系统性能和实时特征。
  软件接口和系统性能都可能在代码开发前进行验证。
  可以开发一些代理模块取代用于单元测试和继承测试的输入、输出模块。
  外部传感器和通信输入输出的模拟器，都已经提前开发出来，以支持持续测试。
    4）用可以工作的代码作为评审的基础
    DoD-STD-2167A的设计预审（PDR）通常要求在第6个月进行一次书面文档和概要图表的评审，在这个项目中则被替换成在第14个月用可以工作的软件展示那些高风险的部分，特别是网络操作系统、消息传递中间件和GUI软件。
    5）自动生成大部分要求的文档
    由于项目面对的是一个广泛的客户群，有些客户和他的管理者仍然坚持认为，收到格式正确的文档是重要的，因此项目组在开发文档生成器的时候考虑了两种情况，既能生成符合开发习惯和效率的文档，也能生成满足标准检查要求的文档。尽管这不是理想的解决方案，但与其要用户失望，还不如满足他们的要求。这是一种注重实效的、折中的解决方案。 
    6）自动生成的计划和规格说明易于更改
    很多人都发现，遵循计划往往是响应变化的最好方法。由于这个项目的计划和规格说明是机器处理的，所以项目可以在相当详细的层面跟踪进度和变更。尽早修正变更，要比推迟问题发现通过昂贵的技术性合同谈判来修正更有利。
    7）度量值显示出该方法的有效性
    大量的项目实践告诉我们，变更越是出现在后期，变更成本越大，而且上升曲线相当陡峭。对于大型项目，交付期的变更成本大约是需求期的100倍，对于小型系统来说，5倍的数字是有代表性的。而在这个项目中，由于使用了具有敏捷要素的计划驱动方式，最后的统计表明，可以实现接近零成本的重构，下图“ECP”表示“工程变更提议”，这张实际项目的统计图反映了后期的变更成本并不会急剧上升。

    8）软件架构和设计允许项目响应变更
    在这个项目中，消息传递中间件和模块化的应用设计，使项目在相应变化方面高度敏捷，上图的变更成本的低增长反映了这一点。此外，项目在确定和计划三个用户团体和装置之间共同点和不同点方面所作的预先工作，使三个相关的系统版本能够实现重用，从而节省了大量的成本。
    这个项目组的成员通过创造性的理解军用标准，最后在预算内如期交付了产品，完全满足了用户要求，获得美国空军授予的杰出成效奖。
（待续）