小型团队快速开发方法

这篇文章写的时候，正处于我探索小型团队快速开发方法的初期，虽然看了不少资料，但终究没有真正把文章中的开发方法真正实现过。因此，本文是我对小型团队快速开发方法的计划，并没有经过实践检验。现在看来，存在不少理想化的东西，在实际工作中并不实用，后来慢慢忘了这篇文章，转而探索其他的开发方法。

今天在查找资料的时候，居然从某网站找到了这篇文章（我从未公开发表），刚开始看的时候觉得作者的知识范围和思想非常符合我的许多想法（汗~~），直到看到原始研究文档时，才醒悟过来，这篇文章就是自己写的 :-)

我原来以为博客园的文章，只要不发布出去，就没人能够看见，呵呵，既然现在已经“泄露”了，就公开吧。

1.   前言

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

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

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

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

 

l   方法特点

1.      需求用例驱动

2.      原型开发

3.      领域模型分层

4.      职责垂直切割

 

l   方法适用环境

1.      3至6人的小团队；

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

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

 

l   原始研究文档

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.   总结

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

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