敏捷开发之路

1. 引言

最近有个企业软件开发项目，用户要求采用敏捷开发的方法实施项目。以前也参加过敏捷方法的培训，结合最近找的敏捷开发材料，形成了下面的敏捷实施过程内容。

以下采用了QAD量化敏捷开发方法，关于此方法详细参考内容见最后章节。

QAD量化敏捷开发：QAD是QuantitativeAgile Development的缩写，是一个覆盖从需求到发布, 端到端的, 相互衔接的团队级工程实践框架。

1、SEAj需求分析法是QAD方法的基石，SEAi方法极简定义：用无修饰词的人类语言描述每个场景, 找到被增查改删的宾语作为实体, 为每一个实体分析增查改删行为, 按成败快慢程度与字段排列将行为分解为需求实例。

2、SEAj需求需求拆分: 用于将需求迅速拆分为 4 个固定的层次, 其中某些层次具有严格的定义和相似规模, 可直接用于估算、度量与量化管理; 并可以替代史诗故事、用户故事; 且数值兼容各种体系的功能点, 如 IFPUG和 NESMA 。

2. 敏捷开发过程

如下图所示，项目实施过程分成了需求设计、开发测试、上线测试三阶段。项目各角色包括项目经理、产品经理（需求分析）、技术经理（架构师）、UI设计人员、开发人员、测试人员。

QAD方法我理解仅包含了需求调研和概要设计之后的内容，所以下图中补充了需求调研和概要设计的过程。

需求调研和概要设计也可以采用迭代的方式？我理解是不可以的，总体设计（概要设计）应该是建立在对需求基本全面了解的基础之上进行的，如果需求获取了50%或甚至是30%，是不无法做总体设计的。

2.1. 召开迭代计划会

1、每个迭代第一天召开，目的是选择和估算本次迭代的工作项。

2、产品负责人逐条讲解最重要的产品功能。

3、产品负责人参与讨论并回答与需求相关的问题。

注意：

1、会前准备：产品功能列表（条目化的需求、用户故事），优先级排序，最近1～2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事

产品功能列表必须从客户价值角度描述，描述用户如何使用，而不是描述技术层面如何实现。比如“实现手写输入”“实现游戏排行榜”，而不是“编写数据库底层”。用户故事的语法“作为一个……，可以……，以（以便）……”很好地保证了这一点。

2、会上讲解：较难以文字表述的内容，如游戏的文化背景，嵌入式设备的手感，OA系统背后的人事关系……讲解过程中团队可以随时发问，产品负责人要予以解答。若产品负责人感觉答案没想清楚，可推迟故事的开发，或将故事分解为“已想清楚的”和“未想清楚的”，后者推迟到下一迭代或更晚。

3、这里的“用户故事”完全采用面向对象分析方法中的系统用例去表示。更为详细的内容可以参照面向对象的需求分析和设计内容

2.2. 制定迭代开发任务（场景）

1、迭代开发任务（场景）编写：描述要有完整的主 (角色) 谓 (行为) 宾 (实体) , 字数越少越好, 但逻辑要连贯、清晰、合理

2、编写原则：首尾完整、过程连贯、各得其所、无修饰词、宾语不重

3、例子：

2.3. 数据库设计（实体）

1、实体是在系统内部可以被外界增查改删的业务数据

2、实体表述形式：用半角或全角方括号表示，如【商品】、【订单】、【结算记录】

3、识别方法: 场景描述中的动宾词组中的 "宾语" ,就是实体。

4、例子：

2.4. 详细设计（分析行为）

1、行为Action 是用户或外部系统对业务实体的增查改删, 或本系统对其他系统行为的调用。

2、在 QAD 中, 行为用来替代敏捷开发中定义模糊的 "用户故事 (简称故事) " , 并承担着迭代内估算和度量的核心职责。

3、例子：

2.5. 测试用例(实例)

1、针对所有的增查改删等行为, 通过成败的快慢、字段的排列组合这两个维度, 测试人员快速编写了测试用例。

2、例子：

2.6. 每日立会

1、由于每次会议只持续10～15分钟，人们习惯在工位附近的空地上站着开会，所以被叫做“每日立会”。 2、每日立会上每个人汇报三个问题：我昨天做了什么，我今天要做什么，我遇到了什么困难。由于小组曾经共同估算任务，所以如果出现偏差，可以沟通出现的问题以相互帮助。 3、如无特殊原因，迭代期内产品负责人不会增加、改变、删除工作项，但却会协助开发人员进行产品功能细化。

2.7. 评审会

1、评审的标准是整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事“差一点就完成了”也算没有完成。 2、常常发生很多故事都已经开始开发，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。 3、一般在迭代计划会上设定每个故事的完成标准，如是否需要测试，是否需要考虑性能，是否需要说明文档等等。这些标准一般由项目组提前列好，每个故事只需要选中是否需要即可。 4、尽管有正式的评审会，但很多团队习惯在单个故事完成时，就让产品负责人进行单个故事评审，以确保交付时不会有“惊喜”。 5、评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中开发，而是由优先级排序决定何时开发。

2.8. 复盘会

1、会上讨论三个问题：我们上个迭代有哪些事情做的好希望继续，那些事情做的不好希望改进，有何改进计划。 2、经常出现一些问题多次被提到，但却始终没有解决。应该每次仅就1～3个关键问题做出可行的解决方案，在下一个迭代执行改进。“可行”的概念包括两个含义：第一是方法简单，影响面小，见效快；第二个是目标不要激进，而要现实可行，积少成多。 3、如果必要可以执行领导回避制度，即具有管理职能的人不参加反思会，即使这些人是产品负责人，项目经理等。