敏捷开发过程

ScrumScrum 敏捷开发过程实战敏捷开发过程实战 产品级，大团队的敏捷实战方法产品级，大团队的敏捷实战方法 需求结构化需求结构化 需求描述需求描述 日常活动日常活动 团队建设团队建设 版本规划版本规划 迭代计划迭代计划 与传统灌输理念的培训不同，此实战培训中不只包含“按客户价值进行优先级排序”“利用自组织团队发 挥主观能动性”等含糊的指导性思想，更在每个阶段均介绍一种或多种直接可以使用的方法来完成落地。 按照实际项目的开发顺序，培训分为三个环节，其主要内容如下： 需求结构化与需求描述需求结构化与需求描述（主要受众为产品负责人产品负责人 Product OwnerProduct Owner、团队骨干、团队骨干） 将产品愿景转换为可实现的业务需求； 将高层业务需求分解为具备层级结构的需求树； 编写用户故事，面向用户使用场景而非产品功能描述单条需求； 版本规划与迭代计划版本规划与迭代计划（主要受众为产品负责人、产品负责人、Scrum MasterScrum Master，团队骨干，团队骨干） 在宏观层面上，确认整个产品中所有子系统的优先级，并将其顺序计划到版本和迭代中； 在微观层面上，利用 Scrum 计划会估算每个迭代中任务的工作量； 日常活动与团队建设日常活动与团队建设（主要受众为 Scrum MasterScrum Master，团队成员，团队成员） 日常活动中，利用每日立会、故事板、看板跟进开发进度； 团队建设中，利用自组织团队、松结对编程等方法建立师徒制度，在实际工作中培养队员； 在大型、跨职能团队研发时的团队结构与工作方式 附：敏捷设计与工程实践附：敏捷设计与工程实践 （仅出现于3 天培训中， 主要受众为 团队成员及技术管理者团队成员及技术管理者 ） 精品文档 如果从用户故事经过简单设计得到代码结构 如何利用用户故事来产生、管理测试用例 如何利用用户故事来管理变更、缺陷和客户反馈 课程将围绕每个小组实际工作中各自产品或项目的自身需求展开，通过对其进行结构化、用户故事化、 用户建模、模拟计划会估算、设定验收标准等，从而演练Scrum 各个环节所需的技能。知识及案例讲解约占 70%，实际练习约占 30%。 注：本大纲中以一个易于理解的电子商务系统的研发为例，实际应用时可应用于银行、电信、政府、电 子商务、互联网社区娱乐、仪器仪表等各种主流行业。 ×××××××××××××××××××××××××第一天×××××××××××××××××××××××××××××××××××××××××××××××××××××××第一天×××××××××××××××××××××××××××××× 0 0 概述概述 本阶段培训通过简短介绍，让学员大致了解敏捷开发的历史及其尝试解决的问题。本阶段培训通过简短介绍，让学员大致了解敏捷开发的历史及其尝试解决的问题。 敏捷开发尝试解决的问题 Scrum 及其历史 产品负责人 Product Owner 产品负责人团队 产品负责人的职责 现场演练：分组并推选 Product Owner 1 1 第一阶段：需求结构化与需求描述第一阶段：需求结构化与需求描述 本阶段培训旨在从头到尾打通需求，即从感性的产品愿景分解到可供开发的具体需求条目。本阶段培训旨在从头到尾打通需求，即从感性的产品愿景分解到可供开发的具体需求条目。 传统敏捷开发使用“条目化”的方法来表达需求。但具体分解和描述需求的方法停留在“每个故事交付 一个客户价值”“从客户价值角度描述需求”等非常含糊、难以落地的层面上。这导致分析所得的需求个体差 别很大，难以作为大型、长期产品研发的正式工程文档。 本课程引入了QUML作为分界用户故事的基础，通过三层需求完成从产品愿景到可开发任务的分解： . 精品文档 *配图中的三层分解流程见下文分步描述。 三层需求分别为业务愿景（左上图），业务操作（左下图中的方框，即史诗故事），业务数据（右侧三 张图中的椭圆，即用户故事）。 这就解决了传统敏捷开发中存在的以下问题： 1. 最初的产品愿景与割裂的用户故事之间缺少必然联系 2. 大量用户故事之间缺少清晰的结构 3. 用户故事颗粒度大小不一 此外，这种体系下建立起来的“用户故事树”（需求树）还能： 1. 直接分配到开发任务中 2. 直接生成代码结构 3. 直接用于结构化管理变更、增强、重构、缺陷等 4. 直接与测试用例匹配 而为一人年的工作量进行这种需求分析，只需要1小时左右。 1.11.1 第一步：业务愿景——利用“角色第一步：业务愿景——利用“角色- -业务图”来支撑产品愿景业务图”来支撑产品愿景 愿景（Vision）是用户对产品的核心期望。 培训中使用“角色-业务图”（简称 RB 图）来表达和落实愿景。 . 精品文档 比如在配图中：“购物子系统”核心愿景是“建立一种有保 障的网上购物方式”；图中使用“确认收货-转账”的第三方监 管业务实现。这样软件开发人员就能得到确切的技术方案，而不 是面对描述非常虚的愿景；而技术方案实现后，又能支撑愿景。 有了愿景，产品就不会简单停留在“能用”的状态，而是要 积极增加可以实现愿景的功能。 现场演练与指导：建立角色业务图（20 分钟） 案例分享：RB 图详细规则与最佳实践 1.21.2 第二步：业务数据——利用“实体第二步：业务数据——利用“实体- -关系图”发掘业务数据关系图”发掘业务数据 此内容将客户愿景转化为“对某些的业务数据的操作”，从而逐渐进入开发人员可理解的范畴；同时业务 数据还是早期功能点估算的核心元素。 具体分析工具是实体-关系图（简称 ER 图），而业务数据对应其中的实体（图中方框）。 实体-关系图（教学过程中进行了简 化）中分析了实体及其依赖关系，通过适 当定义，不但可以保障不会遗漏实体，甚 至能直接协助进行早期估算和部分设计工 作。 重要！在敏捷开发中，我们将业务数重要！在敏捷开发中，我们将业务数 据作为史诗故事进行开发。据作为史诗故事进行开发。 比如在配图中，所有实体（5 个矩形）均包含一组“增删改查”或类似的操作（就是第三步中的用户故 事），由此可知此图包含１６５人天左右的工作量／３张数据库 主表和２张关系表／５组增删改查操作页面。 现场演练与指导：建立实体关系图（30 分钟） 案例分享：ER 图详细规则与最佳实践 1.31.3 第三步：业务操作——利用“用例第三步：业务操作——利用“用例- -流程流程 图”分析业务操作图”分析业务操作 . 精品文档 借助精益需求建模方法（“用例-流程图”，一种由 User Case 和状态图结合演进产生的新图形，简称 UCF 图），找到一个最小的、完备的业务操作集合，作为一次交付所能发布的最新功能集合。在精益开发中， 这个集合称之为 MVP， Minimum Viable Product 最小可用产品。 用例-流程图的“一致性”非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例的数量、名 称、乃至排列顺序都惊人地相似。 重要！在敏捷开发中，我们将业务操作作为用户故事。重要！在敏捷开发中，我们将业务操作作为用户故事。 右图是 QUML 中的“增查查改删”模板中，通过将需求分解为增加-