小型团队快速开发方法
小型团队快速开发方法
Jay
这篇文章写的时候，正处于我探索小型团队快速开发方法的初期，虽然看了不少资料，但终究没有真正把文章中的开发方法真正实现过。因此，本文是我对小型团队快速开发方法的计划，并没有经过实践检验。现在看来，存在不少理想化的东西，在实际工作中并不实用，后来慢慢忘了这篇文章，转而探索其他的开发方法。
今天在查找资料的时候，居然从某网站找到了这篇文章（我从未公开发表），刚开始看的时候觉得作者的知识范围和思想非常符合我的许多想法（汗~~），直到看到原始研究文档时，才醒悟过来，这篇文章就是自己写的 :-)
我原来以为博客园的文章，只要不发布出去，就没人能够看见，呵呵，既然现在已经“泄露”了，就公开吧。
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. 总结
从繁杂的需求到健壮的代码，这是我们的最终目标，而这一系列的步骤给人的感觉很流畅，并且每一步都有规范的指导，不再是只凭经验行事。
注意，这种方法注重于项目开发（分析、设计），我们还需要一种注重于项目管理的方法。
