敏捷实战之——硝烟中的Scrum和X.pptx_第1页
敏捷实战之——硝烟中的Scrum和X.pptx_第2页
敏捷实战之——硝烟中的Scrum和X.pptx_第3页
敏捷实战之——硝烟中的Scrum和X.pptx_第4页
敏捷实战之——硝烟中的Scrum和X.pptx_第5页
已阅读5页,还剩44页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

PM沙龙-Scrum实战分享,分享者:张欣,硝烟中的Scrum和XP:我们如何实施Scrum,Scrum敏捷产品管理:打造用户喜爱的产品,敏捷软件开发宣言,个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划,12条原则,灵活!,产品负责人 VS Scrum Master,产品负责人 负责“目标” 开发正确的产品,Scrum Master 负责“方式” 使用正确地方式实施Scrum,彼此制衡,所以绝不要让一个人兼任产品负责人和Scrum Master,进入正题怎样实行敏捷,Step1.规划产品愿景,对未来产品的简略规划,作用: 设定产品总体目标(以此来激发并引导员工),阐述产品的意义,重点: 客户需求 产品属性,Backlog ,Step2.编写产品Backlog,里面包含的是客户想要的东西,并用客户的术语加以描述,让Backlog停留在业务层面上,详尽适当的 Detailed appropriately 经过估算的 Estimated 涌现的 Emergent 按优先级排序的 Prioritized,Backlog的DEEP特征,价值 知识、不确定性、风险 可发布性 依赖性,依据什么来判断一个故事的优先级?,Sprint计划会议之前,确保产品Backlog井然有序 只能有一个Backlog,一个产品负责人 所有重要的Backlog条目都已根据重要性评分 产品负责人应当理解每个故事的含义 使用JIRA(或Excel等)存放Backlog 使用敏捷过程工具(VersonOne、ScrumWorks),Step3.准备Sprint计划,oKit,Sprint计划会议产生的成果: Sprint目标(业务术语) 团队成员名单(投入程度) Sprint Backlog 确定好Sprint演示日期 确定每日Scrum会议的时间、地点,Step4.制定Sprint计划 Scrum中最重要的活动,整个团队和产品负责人都必须参加Sprint计划会议,范围 估算 重要性 质量外部质量 内部质量,每一个故事都有:,产品负责人 团队 产品负责人 团队绝不可让步,Sprint中包含的故事多少由团队决定,而不是产品负责人,调整优先级 缩小故事 拆分故事,那么,产品负责人如何对Sprint中放入哪些故事产生影响?,产品负责人能做什么?,Estimated velocity,A,B,E,F,C,D,I want D,Option 1,Estimated velocity,A,B,E,F,C,D,抛出C,Option 2,Estimated velocity,A,B,E,F,C,D,缩小A,Option 3,Estimated velocity,A1,B,E,F,C,D,拆分A,A2,本能反应 生产率计算,那么,团队如何决定把哪些故事放入Sprint中?,得出估算生产率 计算在不超出生产率的情况下可加入多少故事,技巧一 索引卡+便签,Story,Story,Story,Story,Story,Story,Less Important,More Important,重要性和分工,技巧二 计划扑克,时间估算,延长时间,直到有结果? 明天再开? 到此为止,开始Sprint?,会议时间到了,但要讨论的东西还没完,如果时间不够了,最后的界限在哪里?,Sprint目标和演示日期 经团队认可,要添加到当前Sprint中的故事列表 Sprint中每个故事的估算值 Sprint中每个故事的“如何演示” 生产率和资源计算,用作Sprint计划的现实核查 明确每日例会固定举行的时间地点 把故事拆分成任务,Step5.怎样让别人了解我们的Sprint,oKit Team , Sprint 20,Sprint goal: Beta-ready release! Sprint backlog: story 1 (3) story 2 (11) Estimated velocity : 14 Schedule: Sprint period : 2014-8-1 to 2014-8-14 daily scrum : 9:15 9:25 , in the team room Sprint demo : 2014-8-15 , in the meeting room Team: Jim , Erica (Scrum Master) , Tommy,会议结束,Scrum Master 给别人发邮件 放到公司wiki,即将完成,Scrum Master 发送演示通告,Step6.怎样编写Sprint Backlog,Story,Not Checked Out,Checked Out,Done!,Sprint Goal : XXXXXXXXXXX,Unplannned Items,NEXT,Story,Story,Story,Story,Step7.怎样布置团队房间,多余的椅子,设计墙(大的白板),公用计算机,Sprint墙 (大型任务板),大量足以闲逛、站立、指指点点、做手势的空间,设计角,让团队坐在一起!,“一起”: 互相听到 互相看到 隔离(与团队外的人) 产品负责人:应该离团队很近,但不应该与团队坐在一起 Scrum Master:应尽可能贴近团队,但不久之后就离开,每隔一段时间去参加Sprint演示、看任务板、听晨会,不超过15分钟 任务板前 例会结束,有人修改燃尽图,Step8.怎样进行每日例会,Scrum注重的是管理和组织实践 XP关注的是实际的编程经验,Step9.作者:我们怎样结合使用Scrum和XP,结对编程 测试驱动开发 增量设计 持续集成 代码集体所有权 充满信息的工作空间 代码标准 可持续的开发速度/精力充沛地工作,不能取消验收测试阶段 把验收测试阶段缩到最短,Step10.我们怎样做测试 作者:这是最困难的部分,全力提高交付代码质量 把测试人员放到Scrum团队里来 每个Sprint少做点工作 全力提高人员测试效率 好的测试人员 好的测试工具 减少开发到测试的间隔 每当开发人员开发出一个功能时,测试人员可以先测试,不需要测试时测试人员做什么?,与开发人员一起结对编程 明确需求 搭建测试环境 改进构建脚本 将故事拆分成任务 与运营部门讨论部署的一些细节 编写部署文档(任何在团队中要写的东西) 和外界的资源进行联系(GUI设计师) 标识出来来自开发人员的核心问题并协助解决,测试人员可以做这么多事情,那么在测试人员有困难的时候,其他人员一样要帮助他完成团队里的工作。如果在Sprint的最后,突然测试人员根本没有时间测试完所有的东西,那么这个时候测试人员可以指挥 一下Scrum成员做一些事情。让他决定哪些事情自己来做。,有的团队把验收测试当成了Sprint一部分,但大部分团队没有这样做,原因如下: 如果有多个团队开发同一个产品时,那就要等所有团队把各模块集成以后再测试。而就算每个Sprint中都有测试过。到最后还是要再测试一个遍。,改良后的Sprint,Sprint 1,Sprint 2,1.0验收测试,1.1验收测试,1.0.1,1.0.0,1.0.1,1.1.0,BUG,对待BUG的两种方式,发布,Sprint 2,发布,Sprint 3,Sprint 1,在旧版本可以产品化之前,不构建新特性,可以开始构建新东西,但是要给“将旧功能产品化”分配高优先级,Sprint演示检查列表: 确保清晰阐述了Sprint目标 不要花太多时间准备演示 节奏要快 让演示关注于业务层次,不要管技术细节 可能的话,让观众自己试一下产品 不要演示一大堆细碎的BUG修复和微不足道的特性,Step11.怎样进行Sprint演示,怎么处理无法演示的工作? 给出报告!,确保能够进行回顾 这是做改进的最佳时机,Step12.怎样做Sprint回顾,作者认为,回顾是Scrum中第二重要的事,根据要讨论的内容范围,设定时间为13小时 参与者包括产品负责人和Scrum Master 在一个封闭的房间中、或舒适的沙发角等任何能够在不受干扰情况下讨论的地方 我们一般不会在团队房间中回顾,会分散注意力 制定某人当秘书 Scrum Master向大家展示Sprint Backlog,在团队帮助下对Sprint做总结,包括重要事件和决策等 轮流发言,什么是好的,什么可以改进 对预估生产率和实际生产率进行比较。若差异大,分析原因 快结束时,Scrum Master对具体建议进行总结,得出下一个Sprint需要改进的地方。,每个Sprint只关注几个改进就可以!,Step13.Sprint之间的修整时刻,“实验日”,Step14.制定发布计划,处理固定价格的合同,定义你的验收标准 对重要条目进行时间估算 让团队来做估算 不要让他们花太多时间 确保他们的估算只是粗略估计,而不是承诺 估算生产率 统计一切因素,生成发布计划 调整发布计划,“大团队” better than “多团队” 59人被公认为是“最佳”团队人数 同步多个Sprint 一个产品负责人,一个Backlog,Step15.怎样管理多个Scrum团队,想尽办法把物理位置上分散的团队成员之间的沟通带宽增至最大,Step16.怎样管理分布式团队,Step17.Scrum Master检查列表,开始阶段: Sprint计划会议之后,创建Sprint信息页面 给每个人发邮件,声明新的Sprint已经启动,邮件中包括Sprint目标和指向Sprint信息页面的链接 更新Sprint数据文档,加入估算生产率,团队大小和Sprint长度等,每一天: 确保每日Scrum会议可以按时开始和结束 为了保证Sprint可以如期完成,需要适当地增删故事(确保产品负责人了解这些变化) 确保团队可以及时得知Spri

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论