规范点驱动开发(Specification Driven Development,简称SpecDD)是一种全新的软件开发概念性框架,它贯穿于应用生命周期管理(Application Lifecycle Management,简称ALM)的各个阶段,支持各种成熟开发模型,旨在帮助开发团队提高项目质量,促进软件项目成功。

一、        SpecDD的概念

SpecDD概念性框架用规范点(Specification,以下简称Spec)来表述/定义产品或版本功能,并通过中央知识库与整个团队有效共享,使Spec成为贯穿ALM各阶段的要素,从需求分析到项目规划,从编码到QA测试(如图1所示),驱动整个开发流程。

Spec是SpecDD概念性框架中的最小单元。通常情况下,由来自各种渠道的客户需求和产品需求,结合以往积累的知识文档,可以提炼出多个Spec。它们可以是正规表达的新功能、功能增强或缺陷修复,并与对应的需求和知识相关联。Spec是高度结构化的,其树形结构准确地对应产品/版本功能树,以保证开发人员不丢失任何需求。

图2以Browser产品为例,要完成6.0版本,开发团队需要开发“OS Support”、“Tabbed Browsing”等几类新功能,实现“User Interface”、“AJAX”、“Application” 三类基于之前版本的功能提升,修复客户或内部发现的一些缺陷,所有这些Spec都体现为分支上的树叶。

项目管理论坛

SpecDD的关键思想有如下体现:

l  由精通业务逻辑的需求团队主导项目的规划设计,形成完整表达的“概念产品”,通过一个个基本单元Spec的组合来体现;

l  业务逻辑通过“概念产品”准确地传达给实施团队,驱动并指导开发、测试活动,并能在“实际产品”的研发中及时落实需求变更;

l  所有的设计规划、开发编码和QA测试都必须围绕Spec进行。

二、         “知识为核心”的SpecDD

“以知识为核心”是TechExcel公司ALM的宗旨,它也体现在SpecDD中。

首先,知识不仅包括项目的各种文档,也涵盖了注释、web链接和email等内容,使用户对知识的使用和积累变得更加方便快捷。通过算法对知识项目排序,也提高了知识使用的效率。

另外,知识管理细化了需求管理的颗粒度,通过插件从word格式的需求文档中直接check-in需求片断,就能在需求描述页面中查看相关的那部份内容,而不需要打开附件中的整个需求文档。

三、   定性和定量地度量软件开发质量

对项目质量的度量关乎软件企业切身发展,也是ALM解决方案长期以来所关注的。SpecDD通过对项目需求、时间和成本以及需求变更等多方面的控制,实现了对项目质量定性和定量的度量。

如前所述,SpecDD通过定义Spec集合来指导开发工作,因此,决策团队在项目设计阶段的引导将直接决定项目的质量。而管理决策本身是一个定性和定量的分析过程,需要评估需求、分配资源、预测项目的发布和里程碑日期、分析开发和QA测试过程。Spec作为需求的正规表达方式,不仅贯穿项目开发的各个阶段,还与需求、知识项目、其他Spec、开发和测试任务相关联,从而保证了任务的可追溯性。

如图3所示,对于“软件界面支持富文本格式”这个Spec,可分解为“description field” 、“results field”和“custom fields”三个开发任务;对于每个开发任务,不仅状态能够被跟踪,还能与相应的测试任务及其状态关联。这些环环相扣的关联关系使需求的实现过程处在透明化管理之下,可以随时查看和追溯。

这种可追溯性使得以下几个方面的度量成为可能:评估开发每个需求所需要的资源和时间、关联每个功能所消耗的所有费用、度量和评估需求是否成功实现、通过需求验证指标来管理开发和测试工作。SpecDD还提供了一系列度量指标,主要包括:项目规划和资源数据、日程表、任务实际花费时间、测试数据等。

对于每一个需求或Spec,产品和项目的决策人员可以参考项目成员的投票进行决策。例如,对于Browser产品的最新版本,根据公司VP或产品经理等成员的不同意见产生了两个候选方案,Option1和Option2,每个候选方案都是一些功能或Spec的组合。团队成员可以针对每个需求或Spec进行投票,选择自己认为适合于该版本的需求或Spec。最终的投票结果对决策人员都有很大的参考价值。

另外,SpecDD还实现了对需求变更成本的度量,当特定的功能或需求变更提交时,需要所有相关人员都做出反馈,度量其对成本和收益的影响,得到批准方可执行。

四、        SpecDD之于敏捷开发

虽然敏捷开发在中国还处于刚刚起步阶段,但近几年来发展迅速。调查显示,近几年来,使用极限编程(敏捷方法中最典型的一种)的程序员数量显著上升,敏捷开发已经逐渐从“软件开发”层面渗透到整个应用生命周期。

概括地说,敏捷开发具有以下基本特征:

l  客户提出需求列表并确定需求优先级;

l  开发团队按照客户的详细需求提交产品所需增加的模块;

l  客户可以在任何时间增加、删除或修改需求;

l  每次迭代/增量都可用于项目最后的评审。

正是由于开发过程上的敏捷,使得产品或服务能更好地反应客户的需求,及时沟通降低了项目失败率,避免开发一些不必要的功能,缩短产品发布周期,更快占领市场,从“开发敏捷”最终实现“业务敏捷”。

然而,敏捷开发也存在一系列问题。例如,往往只有小型的、人员集中的开发团队更愿意采用敏捷方法;项目进展常常过度依赖于频繁的面对面沟通;沟通过程缺乏必要的知识记录;开发人员不能完全准确地理解业务需求等。

SpecDD很大程度上弥补了这些不足:

l  SpecDD渗透到敏捷开发的每一次迭代过程中。“概念产品”在每次迭代过程中都能得到进一步改进,每次迭代的结果对概念产品的实现又有参考价值。

l  用Spec这种正规表达形式完整地描述产品,使客户更容易理解修改后的设计。

l  以知识为核心的SpecDD概念性框架,不仅能将敏捷方法运用到日常开发中,通过日积月累总结出成熟的开发实践,还能依托于中心知识库积累的大量设计和实施数据,为不断总结和完善开发实践提供了坚实的基础。

l  SpecDD真正解决了分布式团队敏捷开发的问题(如图4所示),实现了关注点的有效分离。核心团队专注于设计“概念产品”,并通过Spec对产品进行正规描述;分布式团队专注于开发、测试最终实现“实际产品”,随时比对“实际产品”和“概念产品”,做出及时修正,严格控制项目质量。

l  应用SpecDD,即使大型的分布式团队也能建立小型团队般的敏捷开发环境,提高开发效率,真正发挥分布式团队合作的规模效应。

五、        有序管理变更

敏捷开发的一个重要特点在于利用变化来为客户创造竞争优势,任何时候都欢迎客户改变需求。但是,无论是变更已有需求,还是增加新的需求,都会对项目最终交付的日程造成不同程度的影响。例如,需求变更可能会影响到与之相关的功能、开发任务和测试工作;编码延期会延误与该功能相关的其他开发任务和测试工作。因此,理解需求变更可能产生的效应,并有效控制,对于软件项目的成功至关重要。

如何在变更发生之前对其进行评估?这就需要将需求管理与所有开发、测试行为进行集成,用户可以通过跟踪编码、测试等行为对变更带来的潜在影响进行评估。

SpecDD的设计实现了对需求变更的有序管理。变更可能发生在开发或需求分析过程中的任何时间,包括对文档、设计以及图表的修改。对于每一个变更,都要跟踪其可能产生的费用、时间,以及它可能会影响到的开发和测试任务。对某些功能或需求的变更还会被慎重管理,需要通过特定工作流,进行成本和利润分析。团队成员的反馈意见需要与变更相关联。SpecDD主要通过以下几点的控制有序管理变更:

l  变更控制:变更请求需要由独立的工作流控制,通常包括请求、复查、讨论、调整和批准等;在变更被批准之前,需求不能被改变。

l  实用性:变更请求的控制应接近实际的需求管理实践,易于被客户理解,易实现对重要的变更进行跟踪。

l  各部门协同工作:需求、功能和开发等部门人员都被纳入变更管理体系,在各个阶段参与变更请求;让开发团队参与到变更请求的批准过程中,会比被动地接受或拒绝变更要更科学、更有效;在变更得到批准或拒绝之前,分析针对该变更在资源和时间上的分配。

六、   SpecDD的实现平台DevSuite

TechExcel的DevSuite是SpecDD的实现平台,它将软件开发过程中的所有文档文件视为知识,包括设计文档、客户需求、详细功能和行为图以及所有相关的支持文档等,并以知识为核心,提供了一个积累以往经验和产品需求的平台。所有知识与客户需求相关联,能帮助设计团队提炼出符合需求的、正规表达的Spec,为研发团队开发出实际功能迈出了坚实的第一步。之后,开发团队只需专注于在开发过程中随时比对“实际产品”与“概念产品”的差距,就可确保产品开发始终符合业务目标。

七、        关于TechExcel 公司

TechExcel公司是世界领先的应用生命周期管理(ALM)、IT服务管理(ITSM)和客户关系管理(CRM)解决方案提供商,倡导“以知识为核心”的管理理念,为企业实现产品开发与服务支持间的沟通,在管理软件研发全过程的同时,促进服务支持流程规范化,通过成熟的管理实践,实现企业战略目标。