3.4 案例分析:IBM Rational中国的敏捷转型

2010年春,IBM开始着手准备整理Rational的敏捷开发过程,其目的并非统一所有产品团队的IBM式Scrum开发流程,这既不可能也不合理,而是需要将原来的Scrum落地成为一个像IPD(IBM Process Development)那样具有具体指导意义的、对于初步使用这套方法的各种角色人员都有直接指导作用的方法论。但是我们不能忽视一个客观事实,即各种团队实施Scrum这些年来形成的良好的差异性实践活动。

这项工程的价值还在于为Rational团队定义一种“框架”和“规范”,因为我们始终相信,只有在有“边界”的空间,团队才能充分实现自我的价值和发挥其创造力。

“规范”最好不是操作级别的手册(不得不说,某些时候手册却更有价值),而是一个“组织级的战略”加上有高度的“规划”。因为,在企业里,项目的透明度和团队的自由、敏捷一样重要,我们相信:

·敏捷需要纪律、需要过程,XP就是拥有各种纪律的敏捷方法,因此敏捷绝不是无政府主义。

·敏捷不需要管理是一种错误的认识,团队自我组织、自律自持、自知之明,但仍然需要管理,否则无法实现敏捷转型。

·为团队定制可持续性开展活动的过程或者方法,是真正运用敏捷核心价值实现敏捷框架的过程。

·敏捷方法、实践过程的设计、使用以及过程的管理均是敏捷转型的重要环节之一。

在着手设计、撰写Rational中国的敏捷开发过程的同时,我和我的团队踊跃地参加到全球敏捷社区领导团队的各项工作中,其中一项对我形成巨大影响的是和IBM的CoC团队以及首席方法论学者Scott Ambler对即将出版的一本新书《Disciplined Agile Delivery》进行评审。

对于我的导师、前辈Scott Ambler先生的书,我是缺乏勇气自诩“评委”的,但是令人嫉妒也罢,走运也罢,我真是太荣幸地被邀请加入此书的评审活动中了。[email protected]领导团队成员全部参与了评审,因为所涉及的章节内容非常丰富、细致,我们被分成了若干组,各自集中对其负责的一些章节开展讨论并提出评审意见,大家和Scott先生的探讨也时常发生,Scott其实是个幽默的人,这让针锋相对的风险几乎降低到零。

与其说我给书中章节提供了一些建议不如说我彻底地向导师、专家学习了IBM的敏捷方法“Discipline Agile Delivery(DAD)”和“Agile at Scale”,这些工作对我最终完成Rational敏捷开发过程大有裨益。

在敏捷转型之前,Rational在中国的研发产品有CC、CQ、RQM、RPE、RTC等,而这些产品都有着浓厚的“地方特色”,CCM产品族CC和CQ从瀑布式、RUP、敏捷开发到今天,在中国已有十多年的基础和历史,产品结构和功能非常强大,对其中任何一项功能的改动都会影响到过去十几年开发者留下来的历史代码,既是对团队技术的挑战,也为产品的后续发布带来较大的风险。

所以,CCM团队相比其他产品开发团队具有更严谨的开发流程,尽管也采用迭代式开发并召开每日的迭代会议,但团队在选择敏捷实践、改进过程和任何产品的改动上都表现出尤其谨慎的态度。当我希望他们展示流程和方法中最为“敏捷”的部分时,我感觉实在是难为这支团队。我非常清楚,对于这样稳定的产品,新功能的开发、架构的改变、新问题的解决均需要开发者有非常强的整体把控,任何一次变更都需要尤其谨慎。因而无论如何我们都不希望敏捷转型对团队的测试、开发、支持小组产生太大的负面影响,而非常理解维持目前稳定的开发过程、保证团队继续成长和技术深入发展才是重点。这也再次证明,并不是纯粹的敏捷、100%的敏捷就是对的,敏捷是一个框架,我们开发出来的流程一定要有包容性,对于产品的复杂度、团队的组成结构和规模、行业特点以及已成既定事实的做法,应该更多地去观察它的优点并加以继承,而不是一味地完全推翻重来。

RPE产品刚刚跟随Telegoic的并购进入IBM中国,产品的研发流程、方法看起来有着很好的可塑性。中国团队刚刚经历了两年的建设和成长,从测试团队发展成了开发支持团队,团队的配合比较默契,团队成员的技术、能力、工作经验也相对过去丰富和成熟了好多。但是,RPE产品在中国的市场还不成熟,同时,RPE的“元老”团队拥有最好的技术,对产品的话语权也最重,而不幸的是,这个元老团队是有控制欲的、坚持自己原有流程和方法的典型,在一年前,所有的开发工作都是在家、实验室、PC上完成,项目的透明度几乎为零,可以说,产品完全取决于个人能力而不是团队协作。元老中的每个人都是独当一面的专家,除了架构师本人,没有人对产品有全面的理解。他们拒绝在工作中履行“不认同的任何一套方法”,并且坚持自己掌控绝对领导力。整个团队约40人,结构复杂,分散于世界各地,产品经理在加拿大、架构师和元老们在罗马尼亚、测试团队在印度、需求团队在美国、支持和主力开发团队在中国、项目发布经理在英国,这个团队想要建立同一个目标、适应新的开发方法和流程的挑战绝对不小。这个时候让团队参与流程改进一定得不到足够的支持,也会受到元老们的挑战。因此,在不影响大局面的情况下,我们只能围绕团队本身的成长和成功来实施敏捷,先“齐家”再“治国”,取得阶段性的成绩,等到这些成绩得到大家的普遍认可后,再来考虑系统级的改进测试、设计、产品清单优先级排列等较弱的环节和过程。在此之前,我们期望可以获得本土团队的支持、配合,并让员工体会到敏捷的优势和好处,以实际表现来说话。

开发中心还有RTC和RQM团队,这两支团队在Jazz统一的敏捷模型下工作,但因为Jazz团队非常庞大,中国的队伍所占比例很小,参与具体的开发和测试工作比较多,而鲜有参与产品团队建设和过程改进、架构设计的讨论。团队埋头于细节工作,很难看到全局,因为没有对比,也感觉不到敏捷实施前后以及将来会对他们有何影响,对于整合一套适用于Rational中国的统一开发过程显然缺乏兴趣。如果真的以他们做为过程改进工作的切入点,恐怕团队会因此力不从心,反而招致不必要的来自投资方的挑战和压力。

3.4.1 统一的研发流程

Rational中国团队的高级经理层希望建立中国实验室的领导力品牌形象,指出我们需要开发出、至少是发掘出一套适用于中国团队的开放的、统一的开发流程,在此基础上建立相应的标准和分析、度量手段,就可以从大量看似无序的数据中分析出有序的规律,例如,预测项目的健康程度、更快地预知可能的风险并建设性地提供解决方案等。我们希望通过团队在大型项目上的经验优势、数据分析上的工具优势,以及高端技术人才优势发掘出更有深远意义的研发理论,这个理论将指导我们解决企业级应用结构调整不够灵活的问题,降低企业级软件的整合难度,预知下一代企业级应用开发过程,揭示软件全生命周期中尚未被人发现的规律,具有诸多意义。

这项工作的开展必须有愿景设计并充分理解当前环境下“存在即合理”的最佳实践模式,而这些实践必须可以从这个完整的过程中摘取出来,经过改进后普及于一般团队的活动。例如,敏捷开发的持续化集成、测试驱动开发等实践活动,以及更多等待我们去发现、总结的智慧和规律。

每个团队对自己的优秀实践活动的发掘、抽象、提升已经潜移默化地对团队自身产生了有益的影响。这些输出不仅直接提升了团队的工作热情、工作认同感和工作效率,也让团队有了更多的使命感。我们不仅仅在写代码、找缺陷,我们是在研究和指导企业级应用开发,让越来越多同我们一样的工程师更卓越、更有成就感。

优秀的过程设计、方法论设计能够指导不同成熟度的团队,适用于不同习惯、规则、复杂程度的领域,以及不同分布程度的组织结构。这个过程有意忽视企业软件研发、甚至是一般软件研发价值体系中的细枝末节,用“最少的步骤实现最大的价值流(Value Stream)”,即促使产品安全、快速投入市场的商业价值。同时,可以通过调整“过程参数”来满足团队各自的差异性附加价值,即在公式中调整某些数值后,就能够实现“额外的期望”,例如“团队的成长”。我们把这套寄予厚望的方法称为“Rational敏捷之路”。

3.4.2 流程开发的利器

开发“Rational敏捷之路”需要绘制流程图,定义角色、阐述职责,还需要绘制框图、流图、包图等,以各种形式方便大家一目了然地看懂流程,流程是一个有层次、有进入和退出的过程,在组织和开发流程的同时,还要以粗细不同的粒度展示流程图,换句话说,为了更好地向不同层面和角色的人展示流程,必须做到既能够通过一组节点和线条的关联来说明这个流程,又能够只用一个节点特写出这个流程在大流程框架下所处的位置和作用。因此,在没有得心应手的“省力”工具前,我们迟迟没有开工。

我的“零起步”开始于Rational Method Composer(RMC)的入门(见图3-10)。RMC的设计思想是将所有的过程、方法定义成“方法内容+流程=方法”(见图3-11),即RMC的描述既可以提供工作描述又能给出工作顺序(见图3-12)。

00113.jpeg

图3-10 使用RMC工具进行过程开发的工作一览

00118.jpeg

图3-11 RMC实现方法和过程的描述所依赖的元素——方法内容+流程

00121.jpeg

图3-12 RMC视图中基本要素之间的抽象关系

方法内容。方法内容是对工作的描述,它作为关键方法构建的块可以重复使用。方法内容描述任务、角色、工作输出和指南等包含在完整工作中的静态元素。

流程。流程表示将以上定义的静态元素及其内容组织成为一个个鲜活的、有生命周期的动态流,并且为内容提供了一个有序的结构。

任何一个方法或方法单元(局部方法),一定是由角色、任务和工作输出以及之间存在关系视图构成的,RMC可以将任意复杂或简单的方法展示为宏观或微观的视图。

在“Rational敏捷之路”的开发过程中,RMC团队开发出的“开箱即用”等方法插件(Method Plugin)(见图3-13)帮助我们减少了许多重复劳动,也激发了我们的创作“灵感”。这些插件可以独立存在,也可以依赖和继承,其设计的过程类似于从一些父类和接口中选择生成子类和实例的代码过程。

00124.jpeg

图3-13 RMC提供了可以继承和实现的大量方法插件

3.4.3 研发转型的困境

即使CCM在中国已经开始向成熟产品的轨迹偏移,但产品研发团队仍然要解决许多独特的问题。而类似RPE这样的新型产品,产品的研发流程还在形成期,而且因为内部人员对新过程的接受程度和对目标的期待不统一,敏捷转型也未能像我们想象的那样大刀阔斧般地成为“敏捷变革之楷模”。

这一系列的困难使我们意识到,不能成为“理想主义者”或者“敏捷狂热之徒”,为了改革而蛮横地强迫团队服从个人意志,破坏了团队生态,忽视团队自我改良的愿望;也不能以粗放的方式任由团队走入误区却视而不见。任何不切实际地追求形象、模式而不是追求卓越的做法都不应该成为过程改进的目标,相反,我们应该基于数据分析,采用循证型方式将团队引导进入敏捷的领域,在改进团队外围环境(领导层充分信任与支持)的基础上,在团队充分得到所需的资源和支持的前提下,在团队产生自我持续改进的愿望后,系统地规划团队的敏捷转型。在转型环境建立的同时,努力完成Rational敏捷开发过程才有实际意义。

然而,我们的大多数项目和团队的敏捷转型要么处在传统迈向理想敏捷的某一中间状态,要么处在一种“存在即合理”的真实敏捷状态。这个状态的下一个转型绝不是“理想敏捷”、“核心敏捷”,而是另一种由独特需求和环境决定的“多态性敏捷”。

数据说明我们的推测和预期是正确的。IBM中国敏捷社区的年度调研显示,IBM中国开发中心76%的员工认为自己的组织内采用了超过一种的敏捷方法做项目开发。那么,Rational敏捷开发流程该如何构建?是抽象还是具体?会被大家接受吗?

回忆2009年春和Scott Ambler的一次座谈,我记录了这样的一段话:“随着敏捷像风暴一样进入了各行各业,敏捷正变得更加普遍。敏捷项目团队相对于传统的项目团队享有更高的成功率,提供更高质量的产品,利益关系人的满意度更高,提供更好的投资回报率(ROI),并提供系统能更快进入市场的保障。由于这些优势,才使敏捷如此声势浩大。”但是,我们均认可的一个观点是:平均意义上,敏捷团队比传统团队更成功,并不意味着所有的敏捷团队都成功,也不意味着所有的组织都能相同程度地实现敏捷的价值。敏捷既有显著的优点也有很大的改进空间,这为我们完成Rational敏捷开发过程增添了一股动力。

3.4.4 定制企业开发过程

我们尝试和各个团队合作,试图建立统一的、既有包容性又能够反映出各自需求的Rational敏捷开发过程,这一过程将是未来持续改进的基础构建。目标很理想,但不可避免地遇到了不少问题,其中最为主要的是人的惰性和对变化的恐惧。

大家均表示还是愿意继续使用和开发当下的流程和工具,尤其是已经认可了先前的成功经验后,他们相信现有流程已经“成熟”,不愿意接受外来的改变。而我们要做的正是将DAD和ASM的概念输送给这个组织,事实上我们需要更多的资源来完成这项工作。

除了请IBM全球社区中经验丰富的敏捷领导人帮忙出谋划策和提供信息支持外,我们还积极地邀请公司内的敏捷支持者、传播者一起参与过程改进的规划。同时,找到各个部门经理,了解他们对过程改进、敏捷开发方法的期望。最后,就是寻求RMC团队开发经理的技术协助,将流程的定制技术难度降到最低,最可贵的是,我们的流程定制也发布在RMC的官方Wiki上,所有IBM员工都可以看到,这也增加了流程的置信度。

最终促成敏捷具体方案设计的步骤,可归纳为以下的重要事件:

1)邀请好友、《Disciplined Agile Delivery》这本书的中文译者、IBM中国区的社区负责人Kevin Yan,向部门中做过程改进和流程设计的同事和管理层介绍DAD。

2)安排组织内部的几次头脑风暴,由部门经理选送部门代表,与其他部门交流当下流程的“利与弊”,将大家共同的重点问题作为下几次会议的主要主题进行讨论和经验分享。

3)联结IBM全球敏捷社区领导团队,寻找可借鉴的转型案例,并且从领导团队中寻找方案的支持者和反对者,将话题提上领导团队的日常会议日程,使得各种意见都能够被充分地探讨,即使是反对者的意见,也能够帮助我们提升工作质量。

4)申请RMC开发团队的技术支持,将过程、方法、实践活动的流程发布到公司内网,接受来自各团队的意见和建议,并将更新后的版本再发布。

5)制作组织内的新闻栏目,每隔一定时间发布工作总结和团队的阶段性收获,分享国内外有影响力的专栏内容转载、国际敏捷社区的文章和经验等。这些内容帮助组织内部在转型和统一流程之前,从组织外的成功案例中获得信心。

6)将工作的创新点、成绩和组织目标结合,在组织内部寻找高阶的支持者,通过他们的长期影响力,为组织内的过程统一和转型寻找资源和长期支持。

7)当然,很难让所有的关键人物认同我们做的事情,所以,我们与组织内部几位有影响力的技术、管理人士进行了一对一的沟通,在他们希望“干掉”这个想法之前,获得他们的支持或者“宽容”。

8)在组织内的各个团队中寻找对敏捷感兴趣的、愿意做深入研究的人才组成“敏捷学习小组”,参与过程改进和开发,通过他们影响周围的同事、上级和管理团队,并让他们从这项工作中受益,例如,帮助其发表文章、参与跨团队的经验分享,或者通过过程改进中随之而来的个人和团队效率、质量的可度量的提升影响个人绩效评分。

正是因为把上面的工作做足了,后来公司才顺其自然地接受了DAD方法。针对各自独特的环境,团队调整了有影响的几个缩放因子,很快形成了各自成熟的敏捷过程。我们把这种“私人定制”的过程保存在各自团队的研发资产中,将大家共同遵守的“团队定制”,即基于DAD的Rational敏捷开发过程发布在了企业内部的知识平台上。

在图3-14中,软件解决方案全生命周期过程可以分成三个阶段,从左至右依次是“构想、构建和发布”阶段。在构想阶段我们组建团队、初始化项目、设定高层的目标和计划,对于新产品研发(如RTC和RPE),这个过程还意味着架构和原型产品的定义。对应于传统项目的CCM产品线,这个过程意指一个发布版本的计划阶段。

00128.jpeg

图3-14 基于DAD的Rational敏捷开发过程

3.4.5 规范性敏捷管理

将DAD方法运用在IBM Rational中,除了支撑团队的敏捷性以外,对于项目的透明度,如风险预估和控制、架构的原型需求,以及构建过程中的迭代管理、测试管理、变更管理等,都需要融入到开发和测试流程中。为了保证管理与控制的透明度,又不打扰团队的专注和协作,不破坏团队自我管理的氛围,我们需要做的是通过工具集成,渗透到项目的细枝末节,再将统计和组合的数据分析和归纳为尽可能直观的方式进行传递,而团队(包括管理者)可以通过定制视图来达到对项目的方方面面了然于心的目的。

在构建阶段,即核心敏捷所关注的高优先级产品清单的实现、测试、验收过程,这个阶段由多个迭代组成。每个迭代均有可以工作的产品交付,最后的几个迭代交付的产品将是潜在可发布的。

既然流程定制与开发已经在RMC平台中完成,下面通过RMC的生成过程视图来分析每个阶段的详细流程设计。例如,图3-15为构建阶段流程图。

00130.jpeg

图3-15 构建阶段

图3-16中,通过一个迭代[1..n]的图标元素来代表多个迭代过程,这个元素是可以展开的,单击这个图标展示迭代的内部流程图,如图3-17所示。

00001.jpeg

图3-16 构建阶段流程图

00004.jpeg

图3-17 构建阶段迭代内部流程图

在一个核心构建迭代中,团队需要完成“迭代规划(Plan Iteration)、完成故事(Complete Story)、稳定构建(Stabilize)以及准备用户文档”四项主要任务。同时,在这个流程结构中,有一个特别的任务是“持续性任务(ongoing tasks)”,它记录的是在项目过程中,那些支持团队完成故事、稳定构建等一系列核心过程所需的“辅助、支持”工作,包括管理、计划和各种报告的输出。在分析迭代规划和完成故事之前,我们先看看持续性任务是如何通过“迭代管理(Manage Iteration)、风险管理(Manage Risks)、监控和测试管理(Monitor&Control Test)、变更管理Request Change”四部分工作来支撑团队的(见图3-18)。

00008.jpeg

图3-18 构建期迭代内的持续性任务过程图

1.迭代管理

发展团队其实也是迭代执行的一部分。如何提高团队成员之间的协作和新人的培养,以及如何更好地将“团队建设”融入到项目开发的活动中来,这正是迭代管理需要考虑的问题。所谓迭代管理是一个以目标驱动而不是随着迭代结束而结束的事务,在项目内外,我们都对这个过程予以坚持。

迭代管理事务试图通过系统对项目进度、工作项剩余时间的监控,帮助团队去除“政治化、部门墙”等制约因素,而达到团队的迭代目标(见图3-19)。当团队落后于预期进度时,系统将会报警,此时项目管理团队需要帮助团队评估如何通过减少工作量而仍然可以满足迭代的目标。例如,利益关系人,如产品负责人、团队负责人将在关键时刻参与决策,审批项目范围变更、工作项延期、任务删减的计划和行为。总之,就是通过危机响应,帮助团队解决影响重要目标的关键问题和风险。

00012.jpeg

图3-19 展开RMC的任务节点图——持续性任务迭代管理

理想的迭代管理是由系统自动收集数据、自动度量并提交预警报告。系统将通过事先定义的几个度量尺度或者度量矩阵,实时监控项目过程。当然,在不满足全自动化的条件下,也可以靠人工收集和处理,或两者兼而有之。

2.风险管理

在早期项目的迭代中,我们和团队坐在一起,讨论并创建该项目的潜在风险清单。为了减小风险列表的大小且将关注力保持在高风险上,我们将类似的风险合并,且按照风险对项目的影响和发生可能性由大到小的顺序排列风险清单。要确定风险大小需要估计以下信息。

·风险的影响。计算如果风险发生,对项目计划进行调整会对日程、人力资源、成本规划造成的偏差。

·风险发生可能性。该风险实际发生的概率(通常以百分比表示)。

·风险值。“风险的影响”乘以“风险发生可能性”,表示风险的实际大小。

根据风险大小优先排序制定风险应变计划,典型的策略应遵循如下。

·风险的缓解计划。通过关键问题的解决,减少发生风险的影响和可能性。

·风险的应急计划。通过预留额外的时间、资源的B计划,以应对风险。

·风险的回避计划。重组项目,将风险的行为减到零,以消除风险。

在软件开发中,我们制定的风险应对策略如下。

·为了减少产品X和Y不能整合的风险,需要在项目初期就建立一个原型用以研究整合的难度及风险。设计一系列的测试点(通过列表形式),以确保整合是成功的。

·为了减少数据库A不正常运作的风险,需要模拟目标软件在并发访问、压力的环境下访问数据库,可能还需要虚拟出数据流,在目标软件没有建成之前实现数据库的验收。

·为了减少测试工具Z无法有效执行应用程序回归测试的风险,需要在即将到来的迭代中使用它。

风险评估实际上是一个持续的过程,而不是一个只发生在特定时间的过程。至少,应该在迭代或一个里程碑抵达时评估风险,重新聚焦迭代目标时重新评估风险,尤其是以下几点。

·消除已经完全缓释、不在存在的风险。

·寻找、发现新近引入的风险。

·重新评估风险值,重新排列风险列表。

如果可能的话,最好每周都重新审视风险清单,看看它们发生了什么变化。让最靠前的十大风险可以在整个项目过程中保持足够的曝光度、可见度,并坚持采取、执行风险应对的计划和行动。通常,应该将风险状态评估报告附加到周报、月报(如果有)中去。

3.监控和测试管理

既然采用敏捷方法,为什么还需要监控和管理呢?在企业环境中,适当的纪律和度量是有益的。正如DAD方法中,构建迭代的质量管理和测试工作经由核心团队和独立测试团队负责,显然在不同时期(迭代、软件生命周期的不同阶段)均有不同的测试关注点。为了使测试工作条理清晰、资源充分利用,团队目标的适时调整需要从全局测试的角度进行规划。为了在测试工作中赢得宝贵时间并准确地调整测试策略,需要对测试工作进行监控和管理。

测试工作量的监控。这个任务的重点是监控测试工作的进展状态和工作量,以提高测试有效性为目的进行适时调整。应该评估工作的质量和完整性,并将其用于后续质量评价工作。如果可能的话,使用检查表,以验证质量和完整性是否足够好(见图3-20)。

00014.jpeg

图3-20 随时更新的测试进展状态报告

寻找积极的迹象,如发现缺陷的消除,或随着时间的推移持续增加或减少的规律。寻找尖锐波峰和波谷的出现点,这表明测试团队可能会遇到的过程或协作方面的压力,我们需要适时给出支持和问题的解决方案。

看看缺陷闭合的趋势。确定当下情况有没有测试关闭待验证不足的问题,或者开发修复问题不充分性的问题。对问题进行量化和分析,例如,开发者标记缺陷为“不可再现(Not reproducible)”而关闭问题的趋势,或“代码按设计工作(work as design)”而关闭问题的数量和趋势等。请注意,在这些问题凸显的时候,关注是否因为过度的开发工作量、或者因为害怕审查工作而采取的行动所致。此外,还要分析修复缺陷又再次引入新缺陷可能导致的后续版本中的问题。总而言之,从趋势分析可以发现团队工作效率降低、个别队员超负荷工作的问题,并据此改善团队的工作状态。

测试覆盖范围监控。这个任务的重点是对迭代、版本测试工作的覆盖范围、测试组织进行充分的监控,以及判断跨迭代的独立测试团队与迭代内团队自主测试的配合是否恰好充分,测试的增量计划是否满足了增量型开发持续增长的需求。

测试覆盖包括功能点覆盖、配置覆盖和测试环境的覆盖,有效地了解测试的覆盖程度需要类似RQM(Rational Quality Manager)的工具,借此设计测试覆盖规划,以及监控测试实际覆盖状况(见图3-21)。

00018.jpeg

图3-21 设计最佳的覆盖面和最高效的执行路径

将度量测试覆盖率的公式集成为工具,例如RQM和RTC,可以回答“测试完成了百分之多少?多少设计的测试案例还没有被测试过?多少需求和功能点还未和相应的测试用例关联?”等问题。最为常用的测试覆盖度量矩阵是“单元测试的代码覆盖率”。

任何有计划的测试任务至少基于一个测试覆盖策略,覆盖策略指导着测试者的测试用例设计。基于需求的测试覆盖率可能足以产生满足测试完整性的量化评定。例如,如果所有的性能测试要求已经确定,且所有测试执行的结构可以关联需求,则很可能得到性能测试要求的75%已被验证的结论。

类似地,如果应用基于代码的覆盖技术,这种类型的测试覆盖率就可能足以说明系统的白盒测试覆盖率,这也是目前大多数企业所认可的。

这两种测试覆盖策略可能需要人为干预,而最佳且最科学的方式是通过系统自动化抽取数据形成报告,尽量避免引入人为因素。

测试工作个人仪表。个人仪表盘的首要工作是让个人在工作中以最小的代价了解自己的工作进展、合理安排工作计划。个人仪表盘是根据以人为本、团队自我管理的初衷来设计的,将质量和测试监控的度量指标和个人仪表盘的视图规则联系起来,个人就能够更有纪律地完成自己的工作,配合团队和项目的整体进度。每个人也非常清楚自己的工作对整体所产生的影响,了解自身的价值,有效建立自我认同感(见图3-22)。

00020.jpeg

图3-22 测试者根据团队规则和个人意愿设计的个人仪表盘

测试的持续性。在DAD的流程图中,无论是构建阶段的测试还是发布阶段的独立测试都需要在整体的测试策略下,以阶梯式覆盖、节省资源和时间的方式合理安排测试。应当有效地组织已有资源将测试覆盖范围尽可能扩大,如果有时间甚至可以尝试不依照测试用例做随机测试。但是,毕竟我们不可能做完整的测试,需要优选最需要测试的资源,再来考虑测试覆盖的完整性,这就需要对整个生命周期内所有阶段的测试活动采取统一规划。

统一规划不一定要详细到测试用例,而应该依照项目的发布计划对测试做一个完整的规划。例如,我们将产品生命周期分为4个阶段,即初建阶段、构建阶段、产品发布阶段和产品维护阶段(见图3-23),在产品的建设阶段中,展开测试策略的讨论,从测试方式上来看基本可以分成两大部分,即合规性测试(Confirmatory Test)和调查性测试(Investigative Test)。

00022.jpeg

图3-23 Rational敏捷开发流程测试的生命周期

合规性测试的目标是对每个潜在发布构建的有效性和关键功能进行验证。测试者将依据项目的背景和时间合理安排工作,不注重测试交付物,基本不用考虑详细的测试用例和测试脚本的输出,可以简单地使用表格、图片、录音等多种形式描述测试计划和规则。合规性测试所追求的是客户对迭代交付物的“足够”认可:足够证明迭代工作的成功,但可以有些小瑕疵。Rational敏捷开发流程中,测试策略规定合规测试包含了开发人员的单元测试和被称为敏捷验收测试的两部分工作,这两种测试用来保障迭代的必要基本输出,重心放在按时完成迭代目标上。测试者与开发者的工作密切相关,测试者其实可以是开发者自己,这使得测试非常提前,除了参与需求、设计等静态测试的工作外,还有白盒代码级单元测试和“自动化测试”等。在测试交付时间上需要严格要求,测试必须提前,甚至可以做到在代码完成前,测试就已经可以独立运行和工作的程度,使合规性测试和开发工作保持一致的节奏。

值得一提的是,在这个阶段所涉及的测试可能是功能的,也可能是非功能的;但凡是在迭代计划中承诺的,也是对用户需求的理解,哪怕是很繁琐的细节,都要在测试中充分验证。这部分的测试工作存在很大的可变性(可能在下个迭代就被重新改写),测试用例、计划、脚本形式都很灵活。

调查性测试是对合规性测试的丰富,合规性测试关注的是迭代成功,而调查性测试更关注产品的成功,所有调查性测试从整体功能、文档完整、系统测试和与其他产品的整合角度等来验证产品是否达标(见图3-24)。这部分工作在Rational的敏捷开发流程中属于“独立测试”,由“独立测试团队”负责完成。

00026.jpeg

图3-24 Rational敏捷开发构建期的测试流程

调查性测试需要测试计划、用例、脚本,因为这段测试工作周期长、跨度大,包含功能测试、文档测试、系统测试,以及和其他产品、环境之间的整合测试。所以,最好使用工具帮助管理,我们的独立测试团队会使用得心应手的自动化工具,以减少自己在执行工作和人机交互上的等待。除了RQM外,RFT(Rational Functional Tester)可以进行图形化自动化测试,RPT(Rational Performance Tester)可以进行性能测试,RBF(Rational Build Forge)可以进行远程跨多平台、并行、多线程指挥测试机执行测试等工作。

Rational的CCM团队采取的就是这种策略,产品进入8.1.*版本后趋于成熟,因为客户的基数非常之大,核心开发团队正向开发–支持型团队转型。CCM团队选择了2周为一个迭代的长度,在每个迭代的第一个周一进行产品开发任务的规划,团队90%的成员都会做开发性工作,例如,选择产品清单中的质量缺陷、客户需求来进行开发、单元测试等,只有10%的人会专注于测试环境的准备、规划和自动化测试的支持以及上一迭代完成工作的手动、自动化测试;第二个周一做调研性测试的规划,100%的团队成员会转职成为测试者,为满足测试规划的要求,对产品做系统的、有计划的测试,在这一周,几乎所有人都在努力验证,除了严重的缺陷(导致产品挂起、宕机或者客户的紧急事件)外没有人会递交新代码。

在Rational项目中,还有些项目团队灵活地调整了测试比重的分配(ASM允许在可变因子的维度上根据因子复杂度调整过程)。例如,RPE团队的独立测试团队是后来建立的,从经验上和技能上都还需要时间成长;团队也很小,与产品核心团队的比例是1:4,所以无法承担这么多的独立测试;再加上独立测试团队位于印度,在沟通上和核心团队存在时差和语言差异的障碍。RPE团队最后决定将大量的调研性测试工作纳入合规性测试,由核心团队主力完成。同时,将模型和流程调整如下(见图3-25和图3-26)。

00030.jpeg

图3-25 Rational CCM团队敏捷测试流程

00035.jpeg

图3-26 RPE团队敏捷测试流程

在独立测试团队初建期,RPE核心团队中的2名开发人员会在迭代中花费近50%的时间转职成为测试负责人,负责独立测试部分的测试用例设计和测试团队新人的培养。因为这个时间还只是个短暂的过渡期,我们没有对流程做更多的定制。

RPE团队的合规测试、调研性测试的范围与Rational的构建器敏捷测试中的两部分测试有很大差异。事实上RPE的测试工作许多都依靠核心团队来完成,因为项目的技术复杂度、行业复杂度比其他产品要轻,核心团队规模15人,团队整体规模约40人,比其他Rational的团队要小。换句话说,项目级的产品、解决方案研发,团队不超过40人的情况下,我们可以将主要资源和投入放到核心团队的建设上;相对地,如果团队规模很大,超过100人,产品研发任务很多,技术复杂度和行业复杂度已经上升到企业级大规模的应用场景,那么我们需要用Scrum of Scrum的方式划分团队外,还需要投入较多资源发展独立测试团队,培养专业的测试人员,加强测试的监控和管理等,因为测试是一项持续性的工作。

4.变更管理

一个项目从开始就处于不停的变化中。用户需求变了需要调整计划或者设计;测试发现了问题需要对错误代码进行变更;甚至人员流失了,也需要对项目进行一定的调整以适应这种情况。缺陷管理、需求管理、风险控制等本质上都是项目变更的一种。传统的变更管理是为了保证项目在变化过程中始终处于可控状态,并随时可跟踪回溯到某个历史状态。而在敏捷和Rational的敏捷开发过程中,变更管理是保证项目永远可持续化地追寻最高商业价值的产出。

为了保证项目可控,项目领导团队需要充分了解变更的价值,衡量变更实施对项目的冲击,以决定是否要修改。比如,质量缺陷是否严重到必须马上得到修改,缺陷的修改是否复杂到会牵扯很多方面。在项目接近尾声时,团队会启动变更管理严格管控的流程,即未批复的代码不得进入产品,而项目领导团队需要对这个变更做100%的批复,代码才能够递交,这个批复团队的名称为CCB(Change Control Board),由开发、产品、售后、测试、发布工程师代表组成。团队一旦进入CCB控制,即产品即将发布期间,开发团队需要在将私有构建流(private stream)更新到系统主要构建流(main stream)之前,在RTC中相应的代码变更工作项上留下如下几个问题的答案。

步骤一 提交CCB所需问题答案(见图3-27)。

·这个修复是针对当下客户所遇到的严重问题吗?

·这是一个质量回退的问题吗?

·这个修复会改动前台吗?

·这个修复对应的变更设置是什么?

什么是质量回退(regression)?作为一个软件产品,从一个版本向另一个版本发展,总是会有些风险,某些功能虽然可以在先前版本中工作,却可能在以后的版本中被意外破坏。

00037.jpeg

图3-27 RTC工作项中描述问题和答案

步骤二 在RTC工作项里创建一个“批复列表(approval list)”,命名为“CCB approval for code delivery”,并且选择一个时间点作为批复的最后时间,系统将在最后时间发送提醒给未完成批复的审阅者,并将所有CCB的批复人录入批复人列表,且等待批复(见图3-28)。

00040.jpeg

图3-28 RTC工作项中的批复列表

反之,开发者认为此时不应该交付变更所引入的代码,则也需要通过CCB提交延期交付的申请,这也可以通过RTC来完成,只是开发者需要回答的问题有所不同:

·从客户角度来理解:这是一个对客户影响很小的问题吗?

·能否提供一个变通的解决方法以降低该影响?

·从技术角度来理解:这个问题的修复非常复杂吗?会导致质量的回退吗?

虽然变更管理的形式是“控制”,上面的CCB例子看起来也是在“控制”;但DAD的变更管理目的却不是“控制”而是支持,是有规范的、不随意破坏原有成果的过程。针对需求的变更也是一样,我们需要通过变更管理保护团队不在迭代内产生变更,尽量减少可能推翻前面的工作重新开始的状况,减少浪费。而正是从减少浪费的目的出发,我们的变更管理需要更“快”完成。

回顾1.4.4节的价值流模型,带上“客户”的眼镜来看这个价值流,相对于实际价值工作交付所需的时间,括号内的时间是指在价值流中浪费在等待、整理、文档、会议等不直接输出价值的事务上的时间,显然实际花费的时间超出了价值工作所需的时间。如果将整个软件开发、软件交付的时间轴作为分析参照物,那么开发工作效率只有9%~33%(从客户需求至产品发布:3/(3+30);从客户需求至产品部署到生产环境:15/(15+30))。

整个Rational敏捷开发过程变更管理的故事,也都在一定程度上重复着这个价值流中的各个环节,而我们调整和解决浪费的方式就是在努力降低等待、整理、文档、会议的时间,这才是和普通变更管理的差异,也是Rational开发过程高效、敏捷的关键。而除了缩短浪费时间外,团队也同时要掌握“延期承诺”的哲学。

何为“延期承诺”的哲学呢?在DAD方法里,团队、设计、需求均在一个迭代内完成,这意味着不是所有的需求都已经清楚,需要甄别和细分需求的过程,在需求完善之前,尽量不做详细的设计、开发、测试工作。这种观点可以归纳为:

·明确需求前,团队不得承诺将其作为高优先级迭代任务,直至需求细节讨论清楚,方可承诺至计划中。

·所有的需求产品清单中,优先开发、设计理解清晰的功能点,后开发正在探讨和完善的功能点。

持续性任务是DAD核心构建中的持续性敏捷管理过程,它同时展示了ASM、DAD是如何将企业项目管理与敏捷团队的敏捷性相结合的。总之,ASM可以理解为通过系统自动化渠道的、基于数据分析的循证型管理方式,在团队的管理和纪律性上形成明确的定性和定义,在定性和定义的范围内,团队将有足够的自由来完成设计、开发和测试等工作。

作为补充,我们再展开迭代内部构建的“计划”和“完成故事”两个任务。

在之前的RMC迭代内部流程视图中,单击“迭代计划”即可打开迭代计划的阶段流程图,这个过程是敏捷迭代计划阶段团队从产品清单选择工作项、评估工作量的过程。一般来说,团队会根据环境因素和自身可容纳的最大工作量来评估开发和测试工作。

Rational项目中,一般定义“史诗”是可以包含“史诗、故事和任务”的大颗粒用户故事,而“故事”又可以包括“故事或任务”。通常,在我们的项目中,故事(Story)和任务的区别在于,故事是那些需要源代码递交的任务,任务仅仅是任务,例如文档、管理工作等。“完成故事(Complete Story)”描述了对一个包含源代码的典型性工作项构建的全过程(见图3-29)。

00042.jpeg

图3-29 构建期迭代内完成故事过程图

当用户故事进入迭代后,团队负责人将领导团队做的第一件事情就是细分这个故事,将故事的需求和目标定义清楚,业务人员和团队的其他关系人将一起探讨设计的细节,这个过程将持续约1/4个迭代时间,在这个工作完成后,也就形成了团队一致的“迭代范围和目标设定(图3-29中的迭代范围和目标设定)”。紧接着团队开始做增量型的开发、构建和测试工作,直至有一个可以运行的构建,然后便开始执行测试,直至产品发布。

3.4.6 满足客户

就像大多数IT企业所面临的挑战一样,我们需要面对许许多多的,越来越聪明、越来越挑剔的客户。有的客户乐意参与IBM的设计、评估和发布决策,但有的客户不愿意付出额外时间、精力帮助我们完成宏远的目标。在市场越来越多元化的细分发展中,客户期待越来越模糊,同时越来越喜爱简洁的产品,IBM软件部旗下所有品牌都因为自身的辎重巨大而倍感危机。对于任意一个产品,平均每个月、每个国家或者地区的客户会提出10个左右的新需求。在这种强大的内外压力下,在客户和我们没有对产品的使用方法达成一致的阶段,我们仍然要关注产品和方案的发展方向,使产品或者方案能够在增量型研发中最快、最灵活地真正产生最大的商业价值。

如图3-30中2008年的调查报告和右侧的柱状图不难得出:固定投入或者固定时间都不是最重要的,最重要的是我们的团队能够产出高质量的产品并快速发布,要更加关注那些正好满足需求的正确功能,做到比传统开发团队输出更好的“投入产出比”。

00046.jpeg

图3-30 Dr Dobb 2008项目成功率统计

从左侧柱状图可以看出,迭代和敏捷的方法使得项目有更高的成功率,而越来越多的人认为,项目的成功已经不仅仅是“对时间、预算的控制,以及产品与项目设计合同的完美一致”。有83%的人认为项目中满足客户当下的需求比一丝不苟按合同执行更重要,82%的人认为关注产品本身质量比时间和预算的控制更重要,70%的人认为将优先级放在最好的投入产出比上比成本控制更重要。

而敏捷项目开发快速、质量高,迎合需求以实现最大化的投入产出,比传统开发给企业带来更多价值。所以,我们和客户不是单从甲乙双方的合同约束来履行责任,而是双方需要培养共患难、同享福的战略合作伙伴关系。

3.4.7 培养客户关系

在后台工作的6年里,我基本上不见客户。我畏惧客户,因为前端带来的需求变更、客户的抱怨总会让我加上一阵子班。我领受的第一个有关于客户的理念就是IBM的价值观“客户为要”。今天,尽管我对客户立场有了更理性的认知,但心中敬畏犹存。

我会对客户的声音极度紧张和关注,面对大量的客户及其个性化的需求,我不得不承认很难平等对待所有客户。从2013年起,我开始涉及许多与客户打交道的工作,工作重点是将客户带入到企业产品研发的需求、设计、开发、测试等各个环节,使客户成为产品的忠实使用者,愿意将自身将来的成功与公司产品的成功绑定到一起。开始,我负责大中华区Rational旗下所有产品的客户,2013年下半年,我又承担了大区售后Rational品牌的所有客户关系。这项工作颠覆了我的一些最基础的认识,帮助我将对待客户的态度和对Rational未来的思考结合起来,而卓有成效的客户管理也带来了良好的业绩。

从简单地把客户的事情做好而创造价值到管理客户关系,我的工作从满足“朋友的需要”向“将客户看成公司一员的立场”来解决客户困扰、满足客户需求而转变。一次面谈、电话或者为客户解决实际问题,我都理解为是向客户提供着或者新颖、或者改善产品和服务性能、或者定制产品和服务以满足具体细分客户特定需求的重要工作。在与客户的交互中,始终把产品和服务提供给客户的可达性作为目标,在可控风险范围内给客户承诺并严格完成。因为我的一部分工作性质,与客户的不愉快经历时有发生,我的“超理智”思维让我顶住了当时的压力,尽管后来花费了好几天的时间倒空“不愉快”。

经过一段时间的工作,我更加理解客户,他们许多人都在忍耐着比我更大的压力,无论是从内部发出的的合规、业务需求,还是部门关系、舆论、或者来自上层的绩效考核的多重压力,他们表现出的对于乙方的苛刻和低忍耐都是可以理解的。即使换上我们披挂上阵,也未必能像他们那么抗压和从容。而我需要通过我的工作,帮助IBM与客户保持着积极的联结力。

我的工作,事实上也是软件交付全生命周期中对“客户参与”这个原则的具体实现。客户只有通过客户项目才能真正参与并直接影响IBM产品。我们来看看客户项目的内容。

客户项目。邀请客户直接参与到产品生产的全生命周期各阶段中来,帮助提高IBM产品质量和客户满意度。这即是我的工作,在工作中,我挑选有战略合作价值的客户展开深度合作。

客户项目之顾问团项目(BOA)。小规模、动态的组织模式下,重要客户的总监、高级总监将参与指导Rational品牌的技术和业务方向,通过与Rational总经理及其资深领导团队成员的合作,帮助客户了解Rational定位的市场和商业目标,并引导客户提出意见和反馈以对Rational的发展策略以及方向产生影响。

客户项目之Beta项目。通过对早期发布版本的试用和免费培训,客户将获得新发布产品的使用权,了解之、评估之,客户将通过这个项目直接向开发、产品团队提供产品质量评估(质量缺陷、新需求)报告,而同时客户将从使用过程和产品培训中受益。

客户项目之设计合作伙伴项目。设计合作伙伴的项目允许客户参与Rational的产品/解决方案的设计。IBM与选定的一群客户建立长期的战略合作伙伴关系,专注于产品系列版本的设计活动。客户的技术经理、架构师、卓越的实践者将和Rational的技术专家、产品研发的决策者一起,在建立Rational产品/解决方案的未来上提供优秀的设计理念。参与该活动需涉及到常规的小组网络、电话会议。

客户项目之客户声音项目(VoiCE)。通过参与IBM面对面的基于区域的客户声音项目,客户们将有机会听到IBM的产品发展战略部署,并有机会向IBM开发团队提供改进意见,并接触到Rational的广大客户群体。此项目旨在收集客户在产品路线图和Rational产品战略计划方面的反馈信息。

客户项目之倡导者项目(Lab Advocate)。Rational的倡导者项目提供一条便捷的与实验室团队的快速沟通途径,与IBM的一位甚至多位关键领袖、经理或者品牌总监建立长期战略合作关系。倡导者将与IBM客户团队合作确保客户在自身环境中充分发挥出IBM产品的全面能力,很好地理解IBM产品的发展趋势,以及IBM解决方案将如何促进业务的持续成长。客户项目与研发周期的关系如图3-31所示。

00050.jpeg

图3-31 客户项目与研发周期的关系

IBM还设有商业价值研究中心,会根据行业专业顾问和市场的预期,对各行业未来趋势进行展望和战略设计。在此基础上,各大事业部也同样有自己的战略研究部门,帮助事业部设计未来产品,例如产品的路线图、投资规划等。

与此同时,各事业部分布在各国家和地区的市场部门也会通过收集产品销售数字,按照区域、产品和行业来划分统计并分析产品的受欢迎程度。每年各地还会举办大小展会,通过新媒体和社会化的普及宣传等市场活动收集客户对产品的直接反馈。

尽管如此,未来IBM的产品更多地还是掌握在客户们手中,顾问规划和市场预期对产品战略的影响是宏观的,具体的产品设计仍然基于客户声音项目、开放式Beta或者设计合作伙伴项目所收集到的客户反馈。客户对于产品的想法、建议、不满都会反馈到相应的客户专员或者经理手上,并将输入数据库系统,从而对其进行跟踪,而产品经理将根据客户反馈内容的商业价值和市场影响进行优先排序。仅2013年中国区一家大型国企为IBM相关产品提供的需求就多达15条,产品咨询和建议达55条。因为产品的全球化,客户数量很大,通过客户项目组渠道收集的需求和建议不小于每月一百条。仅排序、优选且回复客户的工作就会让产品经理忙上一阵,而产品经理最为重要的工作还根据这些不同声音的反馈设计出产品的未来。

一旦客户需求对于产品的影响逐渐降低,或者产品客户经理、客户代表不再积极收集客户的需求,通常只有一个原因,那就是产品将进入生命周期的最后阶段——维护期。IBM是一家对客户负责的企业,尽管没有新的改进计划,但对于产品的维护和各种服务仍然会持续3~5年,并在此期间为客户提供换代产品和版本的升级服务。

采用这种做法的还有知名的国内企业华为,带领华为的任正非总裁曾经说IBM是最好的老师,但是在我看来华为已然成为传奇,这家企业甚至比IBM更加珍视客户。华为的企业文化中,第一条也是“以客户为中心”。“华为作为一家百分百的民营企业,26年来生存不是靠政府,不是靠银行,客户才是我们的衣食父母。”华为的第五位员工,现任三位轮值执行董事之一的郭平接受采访时如是说。

华为可以因为一通电话就立刻派工程师到达现场,与客户一起解决问题,不像其他企业为了节省成本,多半用远程视频遥控,即使这个产品是在乞力马扎罗火山出现了问题,华为也毫不犹豫。满足客户需求和客户服务到位是华为胜出的关键,华为是一家典型的会为了客户利益甚至牺牲自己一到两年短期利益的企业。能让员工甘心为公司、客户卖命,除了配股分红的激励机制外,也与华为强烈的企业文化有关,“你们脑袋要对着客户,屁股要对着领导”,这是任正非反复对员工说的话。他认为,大部分公司会腐败,就是因为员工把力气花在讨好上司方面,而非思考客户需求。