Scrum敏捷开发浅谈

1、1 Scrum敏捷开发浅谈2目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量软件开发p 总结3理解敏捷 何为敏捷？敏捷核心价值是什么？4理解敏捷敏捷开发是“一种以人为核心、迭代、循序渐进的开发方法 ! ”在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。5理解敏捷敏捷开发核心价值观是什么呢？答案是： 沟通，简单，反馈，勇气6理解敏捷敏捷开发的核心思想是：以人为本，适应变化。敏捷宣言敏捷宣言7谁在用敏捷8敏捷更符合软件开发规律软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客

2、观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品传统开发传统开发敏捷开发敏捷开发9目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量软件开发p 总结10敏捷开发流程11敏捷开发流程12目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量开发p 总结13Scrum特点Scrum将小型团队转化为自身命运的管理者-强调每个人的主动性与参与性-快速实现“频繁变更的需求”-关注交付与产出的商业价值目的：促使整个开发过程迅速、自我驱动14Scrum框架迭代迭代每30天Daily SCRUM每24小时高优先级可运行的软件工作项分解产品订单Product Backlog迭代订单Sprint

3、 Backlog新的功能增量迭代规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排迭代复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况迭代回顾会议Sprint Retrospective一般3个小时， Scrum Master将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议Daily Scrum Mee

4、ting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗? 产品负责人产品负责人Scrum主管主管开发团队开发团队15Scrum角色及职责16Scrum角色分类 - 各种“猪”Product Owner-传递来自市场的声音、提升项目的回报-确定产品Backlog中的优先级-从产品的角度确保团队工作方向Scrum Master-管理Scrum流程，确保Scrum运转-确保每个Sprint目标的实现与产出，不受外界干扰团队 -由5-9人组成（开发，测试

5、等）、评估每个Sprint工作17非Scrum角色 - “鸡”利益相关者（客户，供应商）-产品使用者、项目相关者-仅在Sprint回顾展示中参加会议 -经理 -设置环境的产品开发组织管理层-公司管理层（比如总裁办公室等）-垂直职能经理层（比如开发经理等）18Scrum角色敏捷团队包括3个核心角色: PO(Product Owner)、Scrum Master(Scrum教练)和Team(开发产品)19Scrum角色职责角色名称角色定义角色职责注意事项Product Owner（产品负责人）确保Team做正确的事l代表利益相关人（如用户、Marketing、用服、管理者等），对产品投资回报负责l

6、确定产品发布计划l定义产品需求并确定优先级l验收迭代结果，并根据验收结果和需求变化刷新需求清单和优先级l除了客户需求之外，内部任务如重构、持续集成环境搭建等也由PO纳入统一管理Scrum Master（Scrum教练）确保Team正确地做事l辅导团队正确应用敏捷实践l引导团队建立并遵守规则l保护团队不受打扰l推动解决团队遇到的障碍l激励团队l不命令和控制TeamTeam（开发团队）负责产品需求实现l负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量l向PO和利益相关人演示工作成果（可运行的软件）l团队自我管理、持续改进l一般由5-9名跨功能领域人员组成l坐在一起工作l有共同的目标

7、，共担责任l团队成员严格遵守团队规则20Scrum工具-PO：准备Product Backlog-团队：-Sprint计划会议（Sprint Backlog）-Daily 简会-评审会议、总结21Scrum工具Product Backlog-所有需要完成的产品清单，包括优先级、商业诉求，PO负责Sprint Backlog-由团队主动选择完成的每个Sprint需要完成的Story列表-每个Story包括了需求、优先级、工作量-一旦确定，不亦更改Sprint Burn down-显示工作量趋势变化的图表-每天由Scrum Master更新22Sprint 计划会议Product Backlog团

8、队资源现有软件Sprint目标Sprint Backlog1. PO讲解需求以及项目目标2. 通过讨论，由PO确认功能的优先级1. 按照优先级讨论和设计功能2. 逐项评估时间，确定和生成Sprint Backlog项目计划23Story列表故事是用来讲的、分享的、讨论的-有价值：从商业的角度阐述（非技术术语）-小、独立：简单的功能-可讨论：关于故事的交流更重要-动态的：伴随交流，确定细节、优先级-优先级、需要交付的截止日期大需求可先写下大故事，再提炼、分解24Story列表XXXXX备注：XXX内容优先级P1Sprint Sprint 1细节1：XXX细节2：XXX细节3：XXXTask 1：

9、3 hourTask 2：2 hourTask 3：3 hourTask 4：3 hourTask 5：2 hourTask 6：3 hourDeadline2015XXXXSP825估算时间(story point) 计划纸牌26Daily Meetingl每天 15 分钟，团队面对面站立成圈l晨会是为项目信息同步可视化,不是为了解决问题l避免无关的讨论(SM引导)l欢迎各界人士，但只有“猪”可以发言 27任务看板-燃尽图28迭代结果的验收(Review)迭代结果的验收(Review)n团队需要演示所完成的迭代工作n典型的做法是使用演示形式展示新功能或者底层架构的实现n非正式的n2小时的提前

10、准备n不需要正式演示文档n相关的利益相关者n邀请所有关注产品的人参加29一个好Demo的效果1. 促进PO融入团队 PO真正被团队认可成为团队的一员，不再是“那个被Boss传递需求”2. 判定演示成效： 符合故事结果预期 没有Bug 亮点可以是技术的革新，界面好，生产力提升等 每个评委都必须把不足点表达出，并请团队改进3. 沟通： 每个故事Demo后，有1 3分钟沟通和提问，团队会直接直面客户的反馈30目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量开发p 总结31误解误解一： 敏捷开发意味着可以不需要文档、设计和计划误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合误解三： 敏捷只

11、适用于小项目开发误解四： 敏捷只会对研发产生改变误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了误解六： 引入敏捷只需要按照既定的步骤去做就可以了误解七： 敏捷是CMM的替代品，是另一种流程误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了32统一认识：敏捷=理念+优秀实践+具体应用理念优秀实践具体应用 理念（敏捷核心思想）敏捷包括3个层次 优秀实践（敏捷的经验积累） 具体应用（能够结合自身灵活应用才是真正敏捷）33敏捷软件开发典型场景PO和开发团队对产品业务目标形成共识PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序PO每轮迭代前，Review需求列表，并筛选高优先