|
沙发
楼主 |
发表于 2008-9-17 16:48:15
|
只看该作者
|
三、我们的对策
针对国内软件过程改进的现实,我们应该采取什么对策?本文试图提出一种初步的解决方案。
1. 选择正确的生命周期模型
首先,选择一个合适的生命周期模型对于任何软件项目的成功都是至关重要的。大量项目严重拖延、产品迟迟不能交付,究其根本原因往往是与错误运用了存在明显缺陷的瀑布模型有关,所以现代过程方法论,不论轻型、重型, XP、RUP或TSP,无一例外地都推荐、主张采用能显著减少风险的迭代演进式生命周期模型。早在1994年美国国防部就作出了一个重大决定,用新的软件开发标准MIL-STD-498取代旧标准DoD-STD-2167A,而在498所要解决的20个关键问题中就包括:去除隐含的对瀑布型开发过程的偏好,改进与递增演进式开发方法的兼容性以及改进与Ada等其他OO方法的兼容性 [8] 。这一态度的明显转变为我们提供了重要信息。
然而,由于种种原因,上世纪 70年代提出的瀑布模型多年来一直被我们的软件工程教育奉为经典来传授。而在实践中,我们采用的许多生命周期模型却不伦不类地介乎瀑布模型和正确的迭代模型之间,毫无规律性可言,从而为软件开发的成功埋下了严重隐患。应该说这是一个历史性错误,可惜国内许多客户和开发商对该问题的重要性长期没有引起足够的重视,美国人已经为此付出了惨痛的代价,却不知道我们有多少人现在还蒙在鼓里,愿意继续支付学费。
迭代是 OO开发的本性(Grady Booch)。正确做到迭代开发远比字面理解要难得多。世界领先的软件组织其项目迭代开发周期往往呈现图1的形态,每个迭代开发的内容、速度和质量都很稳定,这也是RUP、XP团队所能达到的理想状态(参见《软件架构》节奏原则一章 [3] )。如果度量我们许多组织的开发工作,结果可能都会表现为类似图2的形状:迭代速度不均,每次交付的内容忽多忽少,而且往往迫于外部压力而牺牲质量。时常见到,开发人员加班随意而频繁,问题却始终层出不穷,进度也总是无法保证。可悲的是类似的现象屡见不鲜,反而让我们认为开发节奏紊乱是一种正常态。
2. 适度度量
CMM/PSP/TSP度量体现的是一切用数字和文档说话。企业要转变粗放式管理,提高效益,就应该注意对度量数据和实践经验的积累。有了历史与今天的对比,才谈得上明天的进步。另一方面,SEI开发CMM/PSP/TSP的主要目的就是为了评估美国军用软件承包商的过程能力。在巨额国防经费的驱动下,显然保证软件的可靠性和质量、过程可预测可度量往往是军用软件项目应该满足的首要目标,甚至可以为之不惜代价,提高生产率和降低成本则在其次。PSP/TSP基于历史统计数据的收集分析对过程进行预测、管理、控制、评估和改进,这必然需要长期积累,而大量样本、数据的收集、维护相对成本很高,如果没有自动化工具支持、严格的纪律保障和在基础设施上大量投入,全面度量的实效将难以保证。这种度量强度适合于组织内外环境和需求相对稳定,综合实力强、开发生命关键或可靠性要求高的大中型软件组织,以及那些需要对过程能力作出客观预测和评价的大型工程、异地外包项目。
任何过程的成熟度都应该以最终交付产品 /服务的质量和ROI为最高评判标准。在民用商业软件开发环境中,及时推出满足客户和市场需求、适用的产品是第1位的,速度常常比尽善尽美更为重要。因此,RUP、XP与倡导统计过程控制的PSP/TSP在度量的范围和强度上有着较大差别,但这不意味着RUP、XP不需要度量,不能在敏捷、统一过程的框架中引入必要的度量机制。度量产品本身与度量开发产品的过程有所不同(如图3)。在测试水平还较低、质量保证相对薄弱的国内软件组织中,加强产品度量也尤其重要。我们不应为了追求过程成熟度而使度量面面俱到,应该在敏捷思想的指导下实现适度(按需)度量。
3. 建立 AUPF
是否一定要采用类似 XP那样极限的做法项目才能取得成功?答案显然是否定的。实施过程改进以达到SW-CMM目标,是否只有走PSP/TSP一条道路呢?相信答案也是否定的。组织一旦选定某种过程方法论,就在所有项目上一成不变地照搬执行,排斥其他方法,是不明智的。Alistair Cockburn指出,“不同的项目需要不同的方法论,一个项目的最佳过程是这个项目所能负担的最小过程”,选择过程的原则:1)越大的团体需要越大的方法论;2)越关键的系统在构建的正确性方面需要越多的透明度/更大的密度;3)在方法论体积或密度上相对小的增加会导致项目成本相对大的增长;4)最有效的沟通方式是面对面的互动。
Barry Boehm根据几种过程模型计划性的强弱,描绘了它们在计划谱系中的相对位置 [1] 。可以看到,里程碑风险驱动的RUP位于最极端的敏捷过程XP和里程碑计划驱动的TSP之间。Mark Paulk建议,“应该在组织业务环境中恰当的地方仔细考虑采纳敏捷运动的想法。” [5] CMM、XP是互补的,RUP可以和PSP、 XP集成,XP、ASD与Scrum也天然地相吻合,这些事实都说明重型、轻型过程方法论之间并不存在根本性的矛盾冲突。把这些互补方法论拼在一起,恰好可以发现整个软件过程体系全貌的一部分,可能这就是事物复杂性的原本反映吧。
基于以上讨论,我建议,软件企业可根据自身的实际情况,以统一过程(如 RUP)为基础建立起符合ISO 9001、SW-CMM 和CMMI SE/SW等基准的组织软件过程体系,同时包含敏捷过程(如XP、Scrum)和重型过程(如TSP)等内容。我把这种混合/集成过程体系叫做“敏捷统一过程框架”(Agile Unified Process Framework,AUPF)。这就像饭店的厨师准备了丰盛的自助餐,吃些什么,吃多吃少,按照什么顺序来吃,企业的各个项目团队应该独立作出最恰当的选择。
AUPF为什么不以XP或TSP为基础?首先,尽管XP有敏捷高效等好处,但它很容易被误解误用。现阶段,国内过程管理和软件工程水平还比较低。迫于固定工期和预算的压力,客户和开发商往往只重视编码,轻视/忽视需求分析、计划估算、架构设计、文档编写、有效测试以及良好的开发文化和制度,指望减少前期投入通过事后重构来改进软件,可是重构一旦失败造成的损失往往更大。架构设计正是复杂项目成功的关键,AUPF参照以架构为中心的RUP,通过构造出稳定可靠的架构原型可以为适应需求变化奠定稳固的基础。
其次,针对许多管理者、开发者在提高开发效率、改进软件质量方面应该做些什么、如何去做尚感到千头万绪、束手无策的局面,与大踏步跨越到重型的 PSP/TSP相比,从在短期内相对更容易取得成效的敏捷、统一过程入手,可能更符合国内大部分企业的实际。
企业实施 AUPF,应抛弃旧有的不规范的软件过程,做到适度度量,采用正确的生命周期模型和敏捷、统一过程的最佳实践,并根据实情对个别做法进行调整或舍弃。即使组织已有的过程很成功,也可以借鉴吸收AUPF方法以加强过程的敏捷性。能否让大型复杂软件的开发过程敏捷起来呢?任何大系统、大组织都是由小系统、小团队组成的,所以应该也可以把敏捷方法运用到大项目的子系统子模块的开发中。例如,在起始和细化阶段采用RUP完成需求和架构基线,在构造阶段采用XP实现某个模块。
TRW公司于1987-1994年间为美国空军开发的导弹预警和地面指挥控制系统CCPDS-R是历史上非常著名的、融合统一过程(该项目所采用的过程方法后来形成了RUP的一个主要来源)和敏捷思想的成功范例。该获奖项目的规模为75人、6年、100多万行Ada代码,采用了类似RUP 4个阶段的迭代递增、架构优先过程。它不仅按进度和预算交付了大型关键任务系统,而且还使用户获得了超出预想的功能,在生产率和质量方面取得了2倍的增长。 [1][6]
在整个项目过程中, CCPDS-R承受了大量需求的变化,甚至包括开发后期的一个合同范围变更。同等程度的需求变化扼杀了大部分采用传统管理方法的项目,而CCPDS-R却由于采用了风险管理、设计阶段架构的不断集成以及基于演示的评审方法,有效控制和稳定了变更成本,取得了超乎寻常的成功。CCPDS-R在注重个人互动、可用的软件、客户协作和响应变化等方面都做得非常出色,可以说完全实现了敏捷价值观和目标。(10年前!)
4. 提高组织和个人的软件工程基础技能,全面提升竞争力
过程能力并不是保障成功的惟一因素,影响产品 /项目质量的关键因素还包括开发技能和组织管理(图5),这三者相辅相成、缺一不可。一味地强调提高过程成熟度而忽视组织建设、提高技能,对企业的短期成功和长期健康的全面发展都是不利的。
过程就像武术套路,开发技能就像内功。如果功力不到,招数学得再多再好,也不过是花拳绣腿,摆摆样子。反之,如果功力达到一定程度,就可以运用自如,无招胜有招。许多敏捷、统一过程的发起者、倡导者如 Ivar Jacobson、Kent Beck、Robert Martin、Martin Fowler等人都是全球最著名的OO大师,他们既是令人敬佩的软件思想家,能够不断推陈出新引领软件开发潮流,又是具有丰厚积淀的程序员之优秀表率,达到了真正高手的境界。
与 OO方法紧密结合的敏捷统一过程要求开发人员具备更高的专业素质。XP要求开发团队具备熟练的OO编码、测试和重构等技能,RUP也对OO需求分析、架构设计提出了较高要求。没有真正理解OO范式与传统结构化方法的本质区别,缺乏OO技能,敏捷统一过程恐怕就玩不转了。
由于历史发展和自身局限等原因,应该承认,我们与北美、欧洲的项目经理、架构师、程序员的能力竞争是不在一个层次上的竞争。我们的软件企业和个人,无论在过程能力,还是在技术技能、管理素养上都与国际先进水平存在着明显差距。如果对此不加以重视,老是抱残守缺、自欺欺人,沾沾自喜、不求进取,这些差距还有可能进一步拉大。
5. 弘扬敏捷文化
“敏捷”的意思大概有:轻巧、机敏、迅捷、灵活、高效、活力 …… 轻载——让编程之外的一切工作减到最少的办法——并不能等同于敏捷(当然,组织在重载的情况下也很难做到敏捷)。
我想,实现敏捷过程的真正含义应该是:以满足客户需要、创造客户价值为首要目标,使企业的软件过程容易洞察、适应市场、竞争、技术、需求等内外环境的变化,对此能够迅速做出反应、自我调优和完善,并且在保证产品和服务质量的前提下,对交付内容、速度和资源做出正确的权衡,从而实现企业、员工、客户和社会等多方利益的最大化。
因此,敏捷作为一种快速响应变化、客户 /受益人利益至上的文化,应该是一切现代商业组织的生存手段和终极目标。事实上,上世纪90年代国内制造业就早已开始学习国外敏捷制造、并行工程的先进经验了。RUP迭代递增的开发方式实质上就是一种软件开发的并行工程。历史再一次给了软件行业学习借鉴他人优秀经验的大好机会。
敏捷文化是企业的核心文化。 AUPF的成功实施离不开高度协同的开发文化和良好的人文环境。以人为本的敏捷价值观——注重个人及互动胜于过程和工具、注重可用的软件胜于详尽的文档、注重客户协作胜于合同谈判、注重响应变化胜于恪守计划——正是对刻板僵化的传统过程文化的有力反叛!我们应该在现代软件企业管理中大力提倡和培育敏捷文化,加强多方沟通与信任, 强调领导—协作而非命令—控制,尽量发挥每位员工的潜能和主观能动性;同时,还应该防止把敏捷统一过程奉为新的教条,重蹈官僚形式主义的老路。 |
|