首页 > 3电动设备 > 小型团队快速开发方法

小型团队快速开发方法

2011年4月26日 发表评论 阅读评论

1.前言

小型团队快速开发方法是力求找出中小型项目开发的最佳实践。

小型团队快速开发方法以敏捷开发为核心,结合中小型软件公司的实际情况,制作从需求调研到项目验收的“标准”过程。

小型团队快速开发方法以简明实用为主,以能够对项目小组有用、能够辅助项目顺利为研究方向。

小型团队快速开发方法也算是我从业7年来,近20个项目的亲身经历的开发总结。

  • 方法特点

1.需求用例驱动

2.原型开发

3.领域模型分层

4.职责垂直切割

  • 方法适用环境

1.3至6人的小团队;

2.有一个时间稳定、经验丰富的主力成员;

3.有至少两个在需求明确的情况下(用例完备),能独立完成模块的队员。

  • 原始研究文档

1.《数据驱动开发——对项目开发的总结和反思》(原创)

2.《快速迭代与原型开发》(原创)

3.《分层架构》(原创)

4.《彩色UML建模》

5. 腾讯敏捷框架TAPD

6.《大象UML》

2.系统分析:用例

本方法是用例驱动开发,用例 = 需求,即需求以用例的方式来表达。

本方法只需要业务用例,其它用例不使用。

业务用例的目标非常清晰,它就是用于系统分析上的,具体一点说是系统分析中的需求分析这一步。

用例不但是用来记录分析的结果,同时也是一种分析方法,它通过寻找系统边界、涉众、场景等元素,从而确定系统的业务内容,并用UML用例图绘制出来。注意,简单的用例直接用UML用例图绘制即可,复杂的用例必须适当地加上文字说明。

如何找出用例是系统分析的核心。

RUP有成熟的步骤去发现用例。

建议用RUP发现用例的手段去和领域专家研讨,但并不需要按照RUP的所有步骤去所有编写文档,只需要编写业务用例这一部份就可以了。

注意,虽然调研时最好编写领域中的所有业务用例,但其中的核心业务才需要编写详细用例。

实际上,在业务流程的背后,有一个更加根本的因素——商业需求。商业需求才是真正的需求,业务流程只是一种实现手段而已。

注意,需求调研要避免掉进“业务流程”调研的陷阱。用例是以问题域/商业模型为核心的,它是领域模型的基础,而业务流程是商业模型的实现手段,是为商业模型的服务的。业务流程是企业当前的实践方法,而有时候业务流程受其它因素干扰(可能是电子信息化水平低下,或者是行政法规等),导致当前的业务流程并不是最佳实践。我们要在调研的过程中分析出用例,然后再构造出用例之间的关系,这样就会得到最佳的业务流程。当然,我们也会不可避免地遇到外界因素干扰,导致理想化的业务流程不合实际,但我们继续不断地沟通,对流程进行重组,就可以让流程不断地贴近最佳实践。

3.系统设计:领域模型

用例之后就是建模。

FDD是横跨系统分析和领域建模的轻量方法。

FDD中根据模板(其实就是动宾短语)寻找概念类,和RUP中“用例必然以动宾短语形式出现”的意思完全一致——我们的用例就是FDD的概念类。从这方面看,FDD是系统分析的一种方法。

FDD不使用用例,它直接进行概念建模。系统分析师与领域专家提炼出特征,然后系统分析师就开始总体建模。总体建模采用的是四色原型法,四色原型的本质是描述“什么人(PPT-party)在一个什么时间(MI)以一种什么身份(Role)做什么样的事情(PPT-thing)”。从这方面看,FDD又包含了系统设计。

FDD的最大优点就在这里:我们可以依据FDD的模板指导,把用例平滑转为概念类。

4.使用RUP & FDD进行系统分析和设计

4.1. 总体流程

我们用RUP的步骤发现和编写用例(客户需求),然后通过FDD的模板(动宾短语)进行概念类建模,最后我们根据分析模式,把概念类转为领域模型。

4.2. 发现需求和用例

因为RUP明确提出了“用例 = 需求”,RUP里有非常详细的发现客户需求的方法,准确地说,RUP里有如何发现用例的步骤:

1.确定系统边界。

2.确定参与者(涉众)。

3.确定参与者的目标。

4.定义满足参与者目标的用例,根据其目标对用例命名。

这些步骤包括了客户访谈、有效用例测试等实用的手段。

FDD可以看作是确定参与者目标的一种简洁有效的方法。FDD根据RUP确定出来的系统边界和涉众,通过与领域专家交流(客户访谈),确定用户的目标。

4.3. 把用例映像为模型

把需求表述为用例不算太难,因为用例基本上算是用文字忠实描述用户的需求,并且用例的格式很简单,非常容易掌握。

用例真正的难点是如何发现用例,而不是描述用例。

不过把用例映像为模型(概念模型)就很有难度,这个难度表现在两方面:

模型的阻抗、模型的可实现性。

4.3.1. 业务模型与计算器模型的阻抗

因为模型是计算器抽象出来的,而用例是现实世界中具体存在的,这是两种完全不同的东西。用例的信息和关系必须通过一定的规则转换,才能映像为模型。如果是数据模型,那么就是ER规则;如果是领域模型,那么就是OO规则。

阻抗不是这么容易消除的,UML总结了大量的模式,可以作为参考。

4.3.2. 模型不能直接实现

当我们没有有效方法的时候,把用例映像为模型很大程度上依赖系统分析师的经验和水平。不过即使两个水平相近的分析师,他们做出来的模型(UML表达)也会相差很大——这会导致使用者对设计者的意图理解错误。

那么,有没有一种方法可以让用例能够平滑映像为模型,并且模型能够遵循一定的范式(Pattern),使得设计者与使用者能够理解一致?

四色原型和DDD的分析模式就是为了这个目标而提出的。

四色原型与FDD同出一门,FDD的“特征”在很大程度上是四色原型的文字表达方式,而四色UML类图是四色原型的图表表达方式。基本上用文字描述的“特征”与用UML类表现的类图,两者能够做到信息无损转换。

因为我们在定义用例的时候,已经使用了FDD的特征(动宾短语)进行分析,而特征本来就是四色原型的“用例”,所以从用例映像为四色原型是非常容易的,而且其中也有规律可寻。

四色原型离领域模型已经很接近了,只不过四色原型更注重业务模型,而领域模型更趋于计算机模型。四色原型并不一定能够直接被OO语言实现,而领域模型会遵循DDD的分析模式,一定能够直接被OO语言实现。

在这里“直接实现”的意思是,模型在不作修改的情况下,被程序员用代码表达出来,并且代码完全没有违背模型的地方。

所以我们只要按照DDD的分析模式对四色原型进行“修正”,就可以得到领域模型。

5. 使用敏捷指导软件开发

XP和FDD侧重于软件开发,而Scrum侧重于项目管理。

RUP太重了,不适合小团队的开发。

5.1. 关于结对编程

结对编程不容易推广,因为绝大数的程序员有天生的反感,况且选择合适的结对对象也不容易,搞不好两个人还会产生矛盾,影响团队团结。所以轻易不推荐结对编程,但如果有新人加入,可以考虑用结对编程,以熟手带新手。

虽然不推荐结对编程,但也不能完全让一个人独立写代码,一定要让两个人互相依赖对方。这样做的目的是为了防止有人偷懒,也是为了防止技术狂人为钻研高深技术而忽略了实现业务。

横向切割的MVC/MVP模式是一种方法,一个人写Presentation层,另一个人写Controller/Presenter层,可以互相依赖。但MVC/MVP模式本身有一定的技术深度,不经过培训及一段时间的培养是无法使用的。

基本上没有太好的办法,每日代码检查和每日例会虽然可以这个解决问题,但这样会加重主力成员的工作量。

6.使用Scrum指导项目管理

7.文檔

多用单元测试代替编程文档。多为代码加上注释。只有业务非常复杂,代码和注释都无法清晰地表述的时候,才使用图表和文字编写文文件表达。

8. 总结

从繁杂的需求到健壮的代码,这是我们的最终目标,而这一系列的步骤给人的感觉很流畅,并且每一步都有规范的指导,不再是只凭经验行事。

注意,这种方法注重于项目开发(分析、设计),我们还需要一种注重于项目管理的方法。

分类: 3电动设备 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.

无觅相关文章插件,快速提升流量