敏捷开发过程0126052725Word文档格式.docx

1、现场演练：分组并推选Product Owner1第一阶段：需求结构化与需求描述本阶段培训旨在从头到尾打通需求,即从感性的产品愿景分解到可供开发的具体需求条目。传统敏捷开发使用条目化”的方法來表达需求。但具体分解和描述需求的方法停留在栏每个故事交付一 个客户价值”“从客户价值角度描述需求”等非常含糊、难以落地的层面上。这导致分析所得的需求个体差别 很大，难以作为大型、长期产品研发的正式工程文档。本课程引入了 0JML作为分界用户故事的基础,通过三层需求完成从产品愿景到可开发任务的分解:来配图中的三层分解流程见下文分步描述。三层需求分别为业务愿景（左上图），业务操作（左下图中的方框,即史诗故事），

2、业务数据（右侧三张 图中的椭圆,即用户故事）。这就解决了传统敏捷开发中存在的以下问题:1.最初的产品愿景与割裂的用户故事之间缺少必然联系2 大量用户故事之间缺少清晰的结构3 用户故事颗粒度大小不一此外,这种体系下建立起來的“用户故事树”（需求树）还能:1.直接分配到开发任务中2.直接生成代码结构3.直接用于结构化管理变更、増强、重构、缺陷等4.直接与测试用例匹配而为一人年的工作量进行这种需求分析,只霊耍1小时左右。愿景（Vision）是用户对产品的核心期望。培训中使用“角色业务图”（简称RB图）來表达和落实愿景。1.2 第二步：业务数据一一利用“实体-关系图”发掘业务数据此内容将客户愿景转化为

3、“对某些的业务数据的操作”，从而逐渐进入开发人员可理解的范畴；同时业务 数据还是早期功能点估算的核心元素。具体分析工具是实体关系图（简称ER图），而业务数据对应其中的实体（图中方框）。比如在配图中，所有实体（5个矩形）均包含一组“增删改查”或类似的操作（就是第三步中的用户故 事），由此可知此图包含1 6 5人天左右的匸作量/ 3张数据库 主表和2张关系表/5组增删改查操作页面。现场演练与指导：建立实体关系图（30分钟）案例分享：ER图详细规则与最佳实践1.3 第三步：业务操作一一利用“用例-流程图”分析业务操作借助精益需求建模方法（“用例-流程图”，一种由User Case 和状态图结合演进产

4、生的新图形，简称UCF图），找到一个最小 的、完备的业务操作集合，作为一次交付所能发布的最新功能集 合。在精益开发中，这个集合称之为MVP, Minimum ViableProduct最小可用产品。用例流程图的“一致性”非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例的数量、 名称、乃至排列顺序都惊人地相似。重要！在敏捷开发中，我们将业务操作作为用户故事。右图是QUML中的“增查查改删”模板中，通过将需求分解为增加查看所有.查看单个修改删除五层， 并将不同角色执行的操作放在其正下方（共有操作放在中间），需求分析人员可以迅速而无遗漏地获得所有用 户故事。同时，图中由业务逻辑连接的各个

5、业务操作（即椭圆形区域）形成一个1VP,多一个操作则是多余的， 少个则不能完幣交付J这対每个迭代能持汰交付至关輕建立用例流程图（60分钟）UCF图详细规则与最佳实践1.4第四步：需求树一一建立结构化的需求愿景-业务数据-业务操作。这样就很容易从之前的图形化需求形成树形的需求树，其不同层次对应不同尺度的 用户故事。注很多业界的敏捷开发工具如Jim都引入了层次化用户故事,但均没有提供层次定义和可操作的分解方 法。本培训釆用ord作为演示工具,也可对应到具体工具中。1.5第五步：用户故事一一面向用户价值的需求描述方式很多软件虽然交付了功能，却不是客户想耍的。比如，微博这类的大型 系统的管理员，是否会

6、有一个“查看所有用户”这样的功能來管理几亿个用 户？如果没有，他怎么知道有哪些用户？如果有，如何避免海量用户造成的 信息爆炸？电子节目单作为一个观众，可以查看电 子节目单，以了解一周以内 所有电视频道的节目日程。约束：1. flash存储空间：12M敏捷开发引入了一种面向客户价值而非产品功能的需求描述方式，将功 能放在具体的使用环境中讨论，从而能为客户制作出符合其价值的产品。编写口己的用户故事（30分钟）文字游戏还是价值挖掘挖掘1.6第六步：用户建模一一购买决策者/主要使用者建立口己的用户模型（30分钟）一款年收入12亿元的网络游戏对杠所有用户”的理解2第二阶段：版本规划与迭代计划本阶段以第一

7、阶段生成的各层次用户故事为输入,进行宏观的版本规划和微观的迭代计划。传统敏捷开发缺少版本规划的具体实施方法,按客户价值优先级进行排序”听起來有道理但却难以实 施。尤其是在初期无法获得全部用户故事的情况下,优先级排序非常困难。本培训中的方法可以:1.在开发的初期即可提供颗粒度可控的高层需求（史诗故事）进行排序:2.产品经理根据业界统计数据即可进行版本规划:3在版本规划的同时自动完成工作量规划,从而准确安排迭代的数量;在每个迭代的计划会上通过“敏捷扑克估算”，借助集体智慧解决个体问题:1.迅速找到最快的解决办法:2发现高手与新手的差距，并通过讨论弥补差距:3.以10分钟代价提前发现上千行代码的浪费

8、;2.1第一步：版本规划一一项目早期的量化分层规划方法版本1Q瞬1.1皈本12时1.3商關孑荻店碣 建応申UI购枷子痰8?商品订单文宇评价 tr値评分收发券孑疏-发卸6录 堵帳记录广告子荻约伽纽人月削人月版本规划涉及到立项时的战略性规划、迭代间的发布 规划、随时可能发生的产品升级规划等不同层次。培训中 会建立三级规划方法与之对应，分别是业务愿景规划、业 务数据规划和业务操作规划。由于业务数据的定义兼容FPA （功能点分析）中ILF （内部逻辑文件）的定义，因此每个业务数据无需知道细 节即可按业界数据2人月计算（精确数值为35人天）。配图中展示了一个电商网站不同阶段规划的情况。左 侧业务愿景每个

9、对应士20人月规模的需求：中间业务数据级别每个对应2人月规模的需求：右上角黑体字则是业务操作，每个对应士5人天规模。2.2第二步：迭代规划若一个版本需要在三个迭代后才能完成，那么每个迭代 应该完成哪些功能？本培训中引入了精益创业（Lean Start-up）中MVP （最 小可用产品）的概念，介绍如何聚焦于最少的工作量完成一 个可以供用户使用并提交反馈的产品。在完成迭代规划厉，产品经理就得到了一个意向性的迭代列表，以及每个迭代中的需求分布情况。接下來 在每个迭代开始第一天，需要召开计划会议对详细需求进行讲解和估算。23第三步：迭代计划会本阶段通过讲解计划会的完整过程及背后的思想好酋遍过实际练习

10、，对之前需求分析阶段获得的用户故事进行估算。详细内容包括：猪与鸡的故事一一敏捷计划会背后的分权思想如何通过放权提升开发人员个体的积极性。产品经理如何讲解故事如何从大到小、从整体到局部、从背景到功能地分层讲解用户故事；如何在客户环境中理解需求。开发人员扑克估算如何让团队成员说出真实的估算值：如何让高手在估算时就能帮助新手：如何通过估算來澄清需求。讲师在从事开发时，曾将已经完成的、多达TOOO行代码圧缩为55行代码。在实施墩捷估算后，在计划会 即可避免这种浪费，而无需等待编码实际结束后才发现。小游戏：世界口 （保密内容）有多高？（演示估算扑克的使用方法，10分钟）我的故事耍多少工作量？（使用客户内

11、部开发需求，15分钟）3第三阶段：敏捷日常工作本阶段的核心内容是如何在顺利在迭代期内跟踪项目进展。此阶段培训将涉及到传统的每日立会燃尽图、故事板等工具,但同时也会介绍多家公司根据口身情况 对敏捷开发活动的改良:3.1日常活动第一步：每日立会与敏捷生态系统无数敏捷团队因为每日立会简单易行而将其作为第一个推广的敏捷活动：无数敏捷团队也在无奈中亲口见 证了这个简单易行的会议最后如何变得死气沉沉，不得不依靠“迟到罚款箱”来维持。培训中将介绍每日立会一一乃至所有敏捷开发活动一一背后的运行原理：敏捷生态系统。看似无关的敏捷 实践与团队模型之间其实存在着隐形的联系。3.2日常活动第二步：看板启发式演练：如何

12、按需改进看板?分析失控的燃尽图3.4高级敏捷实践介绍实际企业在推广敏捷时所作的改进。包括：NEC的预估会与预评审会制度 金山的渐进式评审与跟进人制度 DSDI方法中的MoSCoW方法 当前流行的看板开发面向MVP与持续交付的的可变 周期开发3.5场景演练：迭代计划+每日立会+任务分配策略实践此1小时的练习环节模拟一个士轮的迭代，演示：迭代计划，优先级排序：“必须完成/尽可能完成的工作” 每日立会，团队协作，燃尽图：项目进展控制变更管理：在发生意外时如何选择最佳结果此演练仅限丁人数低人、有充足活动空间的公开课或企业内训。4第四阶段：自组织团队建设本阶段的核心内容是如何把一个普通团队,打造为跨职能

13、.自组织的敏捷团队,并在建设团队的同时培养 个人。很多团队在实施敬捷时采取了“极端敏捷主义团队”，比如团队个体口行估算和领取任务、任何人不过问 其他人的工作（为了充分“放权”）这种听起來很“敏捷”的团队却存在以下问题:I.个体能力差异很大，完成任务的工期、质量可相基10倍以上:2新手得不到指导,长期无法提高（与之前各口为战的游击队没有区别）此阶段培训还将涉及以下内容:2.大型敏捷开发团队的结构;2敏捷开发绩效管理_一从团队考核到个人考核;4.1团队建设第一步：自组织团队原理与同行压力团队认为10个月才能完成的项目，被领导拦腰砍成5个 月。领导刚刚离开会议室，队员们哈哈大笑：原來他们早就知 道进

14、度会被腰斩，所以提前多估了一倍！为了提高生产率，公司加强了绩效管理：凡是延期交付的 项目全部会被扣奖金！于是，所有团队都为口己的项目预留了 100%的额外时间结果是：一年后，公司除了生产率下降一 半之外，什么都没有得到。领导压力似乎总是失效，那么到底是什么在驱动敏捷团队 呢？同行压力本内容会介绍神秘的“同行压力”是如何在计划会、每日 立会上驱动团队努力前行的。4.2团队建设第二步：项目经理转型如2】敏捷开发來了，项目经理该怎么办？很多公司尝试废弃项目经理，启用Scrum Master,这反而令原來的项目经理成为推广敏捷的阻力。培训中会介绍项目经理应该如何升级为PM2.0,从而成为符合敏捷开发原

15、则的项目领导者。6JheTedrnld*j ThcTearnldJ. JhcTearnldU当团队超过io人时，众多敏捷开发中未曾想到的问题就 浮出了水面越來越难以实现众多人员之间的“跨职能”，甚至在纯 软环境中分工也越來越难以打破；高手总是认为白己很忙， 因而提供帮助的应该是别人；计划会上越來越多的人开始弃 权，因为只有个别人感觉自己是潜在的任务执行者1-3-9团队创造了一种大团队分组的方法，即通过产品需 求树将团队分解为多个Feature Team,独立运行敏捷开发，从而降低了团队的规模。4.4团队建设第四步：松结对编程项目中的顶尖高手应该做什么？各口为战？安排攻坚？在敏捷开发“团队协作”

16、的语境中如何使用高手？如果他们 为新手提供帮助，如何保证其自身的生产力不会降低？“松结对编程”提供了一种有别丁两个人同时编程的“结对 编程”。具体实践包括：高手与新手一起估算任务，在发现由能力造成的匸作量分歧后，约定某个时间点高手协助新手，以极短 的时间解决新手遇到的困难；每天执行代码审查，确保每一行代码的质量。4.5团队建设第五步：代码审查与编码规范如何才能做到“只耍高手能避免的缺陷，其他人也一样能避免”？在“松结对编程”中一个重要工作是代码审查，目的是令高手每天都有机会协助新手改善编码质量。高手 同时将各种避免缺陷的方法总结为编码规范。这种“避免缺陷”的规范远比“编码整洁”的规范更受欢迎。

17、本课程的讲师为超过1000人的大型研发企业编写过编码规范，并总结出7条代码审査最佳实践。5附：敏捷设计与开发工程实践本内容仅出现在3天课程、墩捷咨询咨询、敏捷咨询等场景中。本阶段旨在依据之前的需求模型,通过极轻量级的设计,即转化为代码结构,从而完成从用户愿景到代 码、测试的完整过程。此环节需耍结合 mvc或ava struts/spring mvc框架。从实现功能性盡求的角度看,设计有两个主要目的:1.作为从需求到代码的桥梁:2.以更少的代码完成更 多的需求。然而传统设计过程缺少一个步骤化的、一致性的设计方法。不设计,新手无法完成高质量的代码:设计, 在代码完成之后几乎没有人再去看设计文档。此

18、章介绍如何使用朝ML从需求文档直接产生代码。第一,从QpUL己有的RB图、ER图、UCL图,可 以迅速得到MFC架构中的小侦、Controller Jetton,无需任何额外的设计环节:第二,配合QJJIL中的 VCblD代码分层原理,一个Action中的代码会自动被分解到仁en、Controller. Model. Data四个层次中,即使 是初学者也可以掌握。子系统二Aren 业务数据二Controller 业务操作=Action经过这种对应关系之后，只耍拿到前文提到的需求树，MVC中的所有ea/Controller/Action均被唯一地 确定下來，其数量、名称、顺序几乎不会发生变化。除

19、了节省大量设计时间之外，这种做法还使得需求与代码建立了意义对应关系，为今后的需求变更贯穿打 下了基础。如右图，从代码结构中即可看出它实现了 “商铺管理子系统”（Stores）中的业务数据栏建店申请” （StoreApplicntions） 的 创建（Create） 至lj 扌比准（Approve） 的所有业务操作。案例分析：电商系统的MVC代码结构5.2第二步：VCMD代码结构（1小时）QUML将MVC的代码扩展为四层结构：View,仅包含页面布局代码Controller,仅包含业务控制代码（做什么）Model,仅包含业务逻辑代码（怎么 做）Data,仅包含数据访问代码有了这种四层代码规范后，

20、一个方法中的大约200行代码将被分解到至少四个文件中，平均每个仅包含50 行代码，从而达到分层设计的目的。通过 3.1 中的 Area/Controller/Action 切分和 3.2 中的 View/Controller/Model/Data 切分，不需要任何文 档，代码就会被口动切分到12处，多数时候不需要任何设计活动（或仅需要进行一些代码重用和局部设 计），即可安排开发。此方法即使是刚上手的新人也很容易理解和应用，大大降低了设计工作量。电商系统的VCMD代码分层5.3综合应用：L型代码结构（1.5小时）L型代码结构可以用1/3左右的代码完成相同功能的需 求。其中融合了以下工程、管理、团

21、队实践：NWC框架VCMD分层设计 基于需求的团队分工（FeatureTeam）139团队（师徒团队）可复用底层库的建设 分层复用与口动化集成代码质量控制右图中介绍的“L型代码结构”的方法，通过高手/新手的合理搭配，形成业务/底层代码的分离，将最复 朵最容易出错的代码由高手封装成可复用库（Model与Dmx层），而新手只调用可复用库完成业务功能（View 与 Controller 层）。讲师所在的团队开发的软件产品，通过此种代码结构将代码有效性提高到QSM发布的业界数据的3倍： 某银行的大型软件，也己经做到能利用此种结构超过QSM数据的10%。5.4第三步：基于需求树的测试用例/缺陷管理（0.

22、5小时）传统需求用例的编写往往部分独立r需求文档，很难保证 测试覆盖率和测试强度，甚至无法简便地度量两者。在培训中，通过QUML的需求树，可以有效发现需求； 进而依托需求树进而开发出测试用例树，以保证测试用例的完 备性。5.5第四步：基于需求树的需求变更管理（0.5小时）由于缺少一致性的从需求、设计.编码到测试的方法， 分析需求变更影响一直是个难题。但在上述使用3.13T打通需求到测试的全过程后，需 求变更可以一致性地、快速地从需求追溯到代码。图中展示了经过各种变更（増强.重构、技术债务修 复、缺陷等）后需求的情况。所有变更均被置卜其影响的需 求树相应的位置上，变更的实施者很容易由此理解前后文， 并评估变更是否可能影响到父、兄弟等霊求条目。