敏捷开发过程.pdf

: .
”“从客户价值角度描述需求”等非常含糊、难以落地的层面上。这导致分析所得的需求个体差
别很大，难以作为大型、长期产品研发的正式工程文档 。

本课程引入了QUML作为分界用户故事的基础，通过三层需求完成从产品愿景到可开发任务的分解：*配图中的三层分解流程见下文分步描述。

三层需求分别为业务愿景（左上图），业务操作（左下图中的方框，即史诗故事），业务数据（右侧三
张图中的椭圆，即用户故事）。

这就解决了传统敏捷开发中存在的以下问题：
1. 最初的产品愿景与割裂的用户故事之间缺少必然联系
2. 大量用户故事之间缺少清晰的结构
3. 用户故事颗粒度大小不一

此外，这种体系下建立起来的“用户故事树”（需求树）还能：
1. 直接分配到开发任务中
2. 直接生成代码结构
3. 直接用于结构化管理变更、增强、重构、缺陷等
4. 直接与测试用例匹配

为一而 人年的工作量进行这种需求分析，只需要 1 小时左右。
第一步：业务愿景——利用“角色-业务图”来支撑产品愿景
愿景（Vision）是用户对产品的核心期望。
培训中使用“角色-业务图”（简称 RB 图）来表达和落实愿景。比如在配图中：“购物子系统”核心愿景是“建立一种有保
障的网上购物方式”；图中使用“确认收货-转账”的第三方监
管业务实现。这样软件开发人员就能得到确切的技术方案，而不
是面对描述非常虚的愿景；而技术方案实现后，又能支撑愿景。
有了愿景，产品就不会简单停留在“能用”的状态，而是要
积极增加可以实现愿景的功能。

现场演练与指导：建立角色业务图（20 分钟）
案例分享：RB 图详细规则与最佳实践

第二步：业务数据——利用“实体-关系图”发掘业务数据
此内容将客户愿景转化为“对某些的业务数据的操作”，从而逐渐进入开发人员可理解的范畴；同时业务
数据还是早期功能点估算的核心元素。
具体分析工具是实体-关系图（简称 ER 图），而业务数据对应其中的实体（图中方框）。

实体-关系图（教学过程中进行了简
化）中分析了实体及其依赖关系，通过适
当定义，不但可以保障不会遗漏实体，甚
至能直接协助进行早期估算和部分设计工
作。

重要！在敏捷开发中，我们将业务数
据作为史诗故事进行开发。

比如在配图中，所有实体（5 个矩形）均包含一组“增删改查”或类似的操作（就是第三步中的用户故
事），由此可知此图包含１６５人天左右的工作量／３张数据库
主表和２张关系表／５组增删改查操作页面。

现场演练与指导：建立实体关系图（30 分钟）
案例分享：ER 图详细规则与最佳实践
第三步：业务操作——利用“用例-流程
图”分析业务操作借助精益需求建模方法（“用例-流程图”，一种由 User Case 和状态图结合演进产生的新图形，简称
UCF 图），找到一个最小的、完备的业务操作集合，作为一次交付所能发布的最新功能集合。在精益开发中，
这个集合称之为 MVP， Minimum Viable Product 最小可用产品。
用例-流程图的“一致性”非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例的数量、名
称、乃至排列顺序都惊人地相似。

重要！在敏捷开发中，我们将业务操作作为用户故事。

右图是 QUML 中的“增查查改删”模板中，通过将需求分解为增加-查看所有-查看单个-修改-删除五层，
并将不同角色执行的操作放在其正下方（共有操作放在中），需求分析人员可间 以