《敏捷开发过程》由会员分享，可在线阅读，更多相关《敏捷开发过程（19页珍藏版）》请在金锄头文库上搜索。
1、Scrum敏捷开发过程实战产品级，大团队的敏捷实战方法与传统灌输理念的培训不同，此实战培训中不只包含“按客户价值进行优先级排序”“利用自组 织团队发挥主观能动性”等含糊的指导性思想，更在每个阶段均介绍一种或多种直接可以使用的方法 来完成落地。按照实际项目的开发顺序，培训分为三个环节，其主要内容如下：需求结构化与需求描述（主要受众为产品负责人Product Owner、团队骨干）将产品愿景转换为可实现的业务需求；将高层业务需求分解为具备层级结构的需求树；编写用户故事，面向用户使用场景而非产品功能描述单条需求；版本规划与迭代计划（主要受众为产品负责人、Scrum Master ，团队骨干）在宏观层
2、面上，确认整个产品中所有子系统的优先级，并将其顺序计划到版本和迭代中;在微观层面上，利用 Scrum计划会估算每个迭代中任务的工作量；日常活动与团队建设（主要受众为Scrum Master ，团队成员）日常活动中，利用每日立会、故事板、看板跟进开发进度；团队建设中，利用自组织团队、松结对编程等方法建立师徒制度，在实际工作中培养队员；在大型、跨职能团队研发时的团队结构与工作方式附：敏捷设计与工程实践（仅出现于3天培训中，主要受众为团队成员及技术管理者）如果从用户故事经过简单设计得到代码结构如何利用用户故事来产生、管理测试用例如何利用用户故事来管理变更、缺陷和客户反馈课程将围绕每个小组实际工作中各
3、自产品或项目的自身需求展开，通过对其进行结构化、用户故事化、用户建模、模拟计划会估算、设定验收标准等，从而演练Scrum各个环节所需的技能。知识及案例讲解约占70%，实际练习约占30%。注：本大纲中以一个易于理解的电子商务系统的研发为例，实际应用时可应用于银行、电信、政府、电子商务、互联网社区娱乐、仪器仪表等各种主流行业。XXXXXXXXXXXXXXXXXXXXXXXXX第一天 XXXXXXXXXXXXXXXXXXXXXXXXX0概述本阶段培训通过简短介绍，让学员大致了解敏捷开发的历史及其尝试解决的问题。敏捷开发尝试解决的问题Scrum及其历史产品负责人Product Owner产品负责人团队
4、产品负责人的职责现场演练：分组并推选 Product Owner1第一阶段：需求结构化与需求描述本阶段培训旨在从头到尾打通需求，即从感性的产品愿景分解到可供开发的具体需求条目传统敏捷开发使用“条目化”的方法来表达需求。但具体分解和描述需求的方法停留在“每 个故事交付一个客户价值” “从客户价值角度描述需求”等非常含糊、难以落地的层面上。这导致分 析所得的需求个体差别很大，难以作为大型、长期产品研发的正式工程文档。本课程引入了 QUML作为分界用户故事的基础，通过三层需求完成从产品愿景到可开发任务 的分解：*配图中的三层分解流程见下文分步描述。三层需求分别为业务愿景（左上图），业务操作（左下图中
5、的方框，即史诗故事），业务数 据（右侧三张图中的椭圆，即用户故事）。这就解决了传统敏捷开发中存在的以下问题：1. 最初的产品愿景与割裂的用户故事之间缺少必然联系2. 大量用户故事之间缺少清晰的结构3. 用户故事颗粒度大小不一此外，这种体系下建立起来的“用户故事树”（需求树）还能：1. 直接分配到开发任务中2. 直接生成代码结构3. 直接用于结构化管理变更、增强、重构、缺陷等4. 直接与测试用例匹配而为一人年的工作量进行这种需求分析，只需要1小时左右。1.1第一步：业务愿景一一利用“角色-业务图”来支撑产品愿景愿景（Vision ）是用户对产品的核心期望。培训中使用“角色-业务图”（简称RB图）
6、来表达和落实愿景。比如在配图中：“购物子系统”核心愿景是“建立一种有保 障的网上购物方式”；图中使用“确认收货 -转账”的第三方监 管业务实现。这样软件开发人员就能得到确切的技术方案，而不 是面对描述非常虚的愿景；而技术方案实现后，又能支撑愿景。有了愿景，产品就不会简单停留在“能用”的状态，而是要 积极增加可以实现愿景的功能。现场演练与指导：建立角色业务图（20分钟）案例分享：RB图详细规则与最佳实践1.2第二步：业务数据一一利用“实体-关系图”发掘业务数据ER图），而业务数据对应其中的实体（图中方框）此内容将客户愿景转化为“对某些的业务数据的操作”，从而逐渐进入开发人员可理解的范畴; 同时业
7、务数据还是早期功能点估算的核心元素。具体分析工具是实体-关系图（简称实体-关系图（教学过程中进行了简 化）中分析了实体及其依赖关系，通过适 当定义，不但可以保障不会遗漏实体，甚 至能直接协助进行早期估算和部分设计工 作。重要！在敏捷开发中，我们将业务数 据作为史诗故事进行开发。比如在配图中，所有实体（5个矩形）均包含一组“增删改查”或类似的操作（就是第三步中的用户故事），由此可知此图包含16 5人天左右的工作量/3张数据库主表和2张关系表/5组增删改查操作页面。现场演练与指导：建立实体关系图（30分钟）案例分享：ER图详细规则与最佳实践1.3第三步：业务操作一一利用“用例-流程图”分析业务操作
8、借助精益需求建模方法（“用例 -流程图”，一种由 User Case和状态图结合演进产生的新图形， 简称UCF图），找到一个最小的、完备的业务操作集合，作为一次交付所能发布的最新功能集合。在精益开发中，这个集合称之为 MVP， Minimum Viable Product最小可用产品。用例-流程图的“一致性”非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例 的数量、名称、乃至排列顺序都惊人地相似。重要！在敏捷开发中，我们将业务操作作为用户故事。右图是QUML中的“增查查改删”模板中，通过将需求分解为增加-查看所有-查看单个-修改-删除五层，并将不同角色执行的操作放在其正下方（共有操
9、作放在中间），需求分析人员可以迅速而无 遗漏地获得所有用户故事。同时，图中由业务逻辑连接的各个业务操作（即椭圆形区域）形成一个MVP，多一个操作则是多余的，少一个则不能完整交付。这对于每个迭代能持续交付至关重要。现场演练与指导：建立用例流程图（60分钟）案例分享：UCF图详细规则与最佳实践1.4第四步：需求树一一建立结构化的需求传统用户故事组织方法均呈现“列表结构”，在用户故事数量庞大时（注：每人年大约能完成用户故事50个，外加子故事50200个），很难看到整个需求的全貌。培训中，会借助业务愿景-业务数据-业务操作的层次，对需求条目进行结构化表达，形成一棵有层次的需求树。如图，看似是一个很普通
10、的“增删改查表”，但图中的第二至四级目录实际上来自于之前的业务愿景-业务数据-业务操作。这样就很容易从之前的图形化需求形成树形的需求树，其不同层次对应不同 尺度的用户故事。注：很多业界的敏捷开发工具如Jira都引入了层次化用户故事，但均没有提供层次定义和可操作的分解方法。本培训采用Word作为演示工具，也可对应到具体工具中。XXXXXXXXXXXXXXXXXXXXXXXXX第二天 XXXXXXXXXXXXXXXXXXXXXXXXX1.5第五步：用户故事一一面向用户价值的需求描述方式电子节目单作为一个观众,可以査看电 子节目单，以了解一周以内 所有电视频道的节目日程。约束：1.flash存储空间
11、:1-2M很多软件虽然交付了功能，却不是客户想要的。比如，微博这类的大型 系统的管理员，是否会有一个“查看所有用户”这样的功能来管理几亿个用 户？如果没有，他怎么知道有哪些用户？如果有，如何避免海量用户造成的 信息爆炸？敏捷开发引入了一种面向客户价值而非产品功能的需求描述方式，将功 能放在具体的使用环境中讨论，从而能为客户制作出符合其价值的产品。现场演练与指导：编写自己的用户故事（30分钟）案例分享：文字游戏还是价值挖掘挖掘/主要使用者1.6第六步：用户建模一一购买决策者“今年过节不收礼，收礼就收脑白金”。尽管多数 收礼者（主要使用者）并不知道脑白金到底包含何种成 分，服用后到底有哪些好处，但
12、是确有无数的送礼者（购买决策者）选择购买。本内容介绍如何区分购买决策者和主要使用者，并 面向核心用户编写用户故事。现场演练与指导：建立自己的用户模型（30分钟）案例分享：一款年收入 12亿元的网络游戏对“所有用户”的理解2第二阶段：版本规划与迭代计划本阶段以第一阶段生成的各层次用户故事为输入，进行宏观的版本规划和微观的迭代计划。传统敏捷开发缺少版本规划的具体实施方法，“按客户价值优先级进行排序”听起来有道理但却 难以实施。尤其是在初期无法获得全部用户故事的情况下，优先级排序非常困难。本培训中的方法可以：1. 在开发的初期即可提供颗粒度可控的高层需求（史诗故事）进行排序；2. 产品经理根据业界统
13、计数据即可进行版本规划；3. 在版本规划的同时自动完成工作量规划，从而准确安排迭代的数量；在每个迭代的计划会上通过“敏捷扑克估算”，借助集体智慧解决个体问题：1. 迅速找到最快的解决办法；2. 发现高手与新手的差距，并通过讨论弥补差距；3. 以10分钟代价提前发现上千行代码的浪费；2.1第一步：版本规划一一项目早期的量化分层规划方法龄1.1k mmmui裔器g sn记At兗李评桶数佰评好广告子至烧亠腰丁惘1纳人月为4朋豹4人月版本规划涉及到立项时的战略性规划、迭代间的发布 规划、随时可能发生的产品升级规划等不同层次。培训中 会建立三级规划方法与之对应，分别是业务愿景规划、业 务数据规划和业务操
14、作规划。由于业务数据的定义兼容 FPA （功能点分析）中ILF （内部逻辑文件）的定义，因此每个业务数据无需知道细 节即可按业界数据2人月计算（精确数值为 35人天）。配图中展示了一个电商网站不同阶段规划的情况。左侧业务愿景每个对应 420人月规模的需求；中间业务数据级别每个对应2人月规模的需求；右上角黑体字则是业务操作，每个对应 45人天规模。2.2第二步：迭代规划若一个版本需要在三个迭代后才能完成，那么每个迭代 应该完成哪些功能？本培训中引入了精益创业(Lean Start-up )中MVP(最小可用产品)的概念，介绍如何聚焦于最少的工作量完 成一个可以供用户使用并提交反馈的产品。在完成迭
15、代规划后，产品经理就得到了一个意向性的迭 代列表，以及每个迭代中的需求分布情况。接下来在每个迭 代开始第一天，需要召开计划会议对详细需求进行讲解和估算。2.3第三步：迭代计划会本阶段通过讲解计划会的完整过程及背后的思想，并通过实际练习，对之前需求分析阶段获得的用户故事进行估算详细内容包括：猪与鸡的故事一一敏捷计划会背后的分权思想如何通过放权提升开发人员个体的积极性。产品经理如何讲解故事如何从大到小、从整体到局部、从背景到功能地分层讲解用户故事；如何在客户环境中理解需求。开发人员扑克估算如何让团队成员说出真实的估算值；如何让高手在估算时就能帮助新手；如何通过估算来澄清需求。讲师在从事开发时，曾将已经完成的、多达4000行代码压缩为55行代码。在实施敏捷估算后，在计划会即可避免这种浪费，而无需等待编码实际结束后才发现。小游戏：世界口（保密内容）有多高？（演示估算扑克的使用方法，10分钟）现场
