敏捷开发过程

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