君，已阅读到文档的结尾了呢~~
SCRUM框架及基本知识SCRUM框
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
SCRUM框架及基本知识
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Scrum三大角色特点 - 流程介绍 - 十五言
灵感来自于一段冷笑话：一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆起什么名字呢？”，鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样？”，“我不这么认为”，猪说, “我全身投入，而你只是参与而已”对于Scrum来说同样的道理，猪是全身投入项目和Scrum过程的人，鸡角色并不是实际Scrum流程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使用户和利益相关者参与到过程中的实践。参与每一个评审和计划，并提供反馈对于这些人来说是非常重要的，管理者就属于鸡。
【Scrum开发流程中的三大角色】产品负责人（Product Owner）主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。流程管理员（Scrum Master）主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。开发团队（Scrum Team）主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。什么是Sprint？Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。如何进行Scrum开发？1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；下面是运用Scrum开发流程中的一些场景图：
上图是一个 Product Backlog 的示例
计划指派比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
收录了本文的主题
大家都在看
阅读下一篇
带着父亲刷副本，玩游戏也能尽孝心
点击微信右上角，可发送给朋友，或分享到朋友圈。
收录到我的主题
大家都在看> knightuniverse的博客详情
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。
它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周（最常见的是两周），并且无间歇地相继进行。Sprint是受时间箱限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。通常由Scrum团队来选定一个Sprint的时长，并且对于他们所有的Sprint都使用这一时长，直到这个团队能力提高，可以使用较短周期。
在每个Sprint的初始，跨职能团队（大约7名成员）从排好优先级的列表中选择事项（客户需求）。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见，这些交付应该是有形的并且能被真正“完成”的。
在Sprint过程中不可以增加新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。
在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。
2. 主要角色
2.1 Product Owner
确定产品的功能，负责维护产品Backlog。
决定产品的发布日期和发布内容。
为产品的投资回报率(ROI)负责。
根据市场价值确定功能优先级。
在每个Sprint开始前调整功能和调整功能优先级。
在Sprint结束时接受或拒绝接受开发团队的工作成果。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。
实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
2.2 Scrum Master
保证团队资源完全可被利用并且全部是高产出的。
保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口，屏蔽外界对团队成员的干扰。
保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
Scrum Master 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。
Scrum Master 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。
Scrum Master 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，以实现精益生产率的收益。
Scrum Master需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。
最后但并非最不重要， Scrum Master 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。Scrum Master 必须注意去确保团队资源完全可被利用并且全部是高产出的。
Scrum团队的规模控制在5-9个人
如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。
如果成员多于9人，那么成员之间就需要太多的协调沟通工作。
大型团队会产生太多复杂性，不便于经验过程控制。
对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。
Scrum团队是跨职能的团队
团队成员必须具备交付产品增量所需要的各种技能。
团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。
在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。
团队中不允许包括测试或业务分析等在特定领域工作的子团队。
Scrum团队是自组织的
任何人，包括Scrum Master都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。
每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。
团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。
2.4 用户和利益相关者（客户，提供商）
3.1 Product Backlog
产品待办事项列表存在（并演化）于产品的整个生命周期，它是产品的路线图。
任何时候，产品待办事项列表都是“团队依照优先排列顺序完成工作”的唯一、最终的概括。
一个产品只有一个产品待办事项列表，这就意味着产品负责人必须纵观全局做出优先级排列的决策，以体现利益相关人（包括团队）的意愿。
产品待办事项列表包括不同种类的事项：
全新的客户特性（“使所有用户可以将书籍放入购物车”），
也有主要的技术改进目标（如“用Java代替C++重写系统”），
还有改进目标（如“加速测试”）、调研工作（“探讨加速信用卡有效验证的解决方法”），
还可能会有已知的缺陷（“分析并修复订单处理脚本错误”），
如果问题不多的话（如果系统有很多缺陷，通常就会有单独的缺陷跟踪系统）。
一个好的产品待办事项列表要做到：
粗细适宜的（Detailed appropriately）
优先级列表顶端的事项比低级别的事项更为精确和详细，因为前者要比后者先被开发。比如，待办事项列表顶端的百分之十可能包含非常小且分析得很详细的事项，而其他的百分之九十则不是那么具体。
估算过的（Estimated）
当前发布版本的事项需要有估算，而且随着大家了解得更多和新信息的融入应当在每个Sprint中重新考虑这些估算。 团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术风险估算。 产品负责人和其他商业利益相关人提供产品需求的价值信息，其中可能会包括获得的收益、减少的成本、商业风险、对不同利益相关人的重要性等等。
涌现式的（Emergent）
为了响应学习和变化，要定期梳理产品待办事项列表。 每个Sprint，可能要加入、删除、修改、分解或者调整事项的优先级别。因此，产品负责人会不断地更新产品待办事项列表，以反映客户需求的变化、新想法或见解、竞争而导致的变化、出现的技术障碍等等。
排好优先级的（Prioritized）
在产品待办事项列表顶端的事项具有最高优先级，或者是从1开始顺序排列。 一般来说，最高优先级别的事项应当最物超所值：高收益（商业价值）低花销（成本）。 提高某事项优先级的另一诱因是在高风险来袭之前及早解决掉它。
3.2 Sprint Backlog
团队为每个Product Backlog事项建立一个工作列表，有时由产品待办事项列表中的事项分解出的任务组成。或者当产品待办事项列表中的事项很小，只要几个小时就能实现时，就简单的由产品待办事项列表事项组成。
4. Scrum开发流程事件
4.1 Sprint计划会议
通常分成两部分：
关于做什么
参与者：产品负责人、团队、ScrumMaster
长度：时间箱的小时数与Sprint的周数相等
产品负责人和团队审视产品待办事项列表中产品负责人有兴趣在这个Sprint中实现的那些高优先级的事项。通常，这些事项应当已经在前一个Sprint中（的产品待办事项列表梳理会议里）被很好地分析过了，因此在这个会上只有较少的需要在最后时刻澄清的问题。在这个会议中，产品负责人和团队讨论产品待办事项列表中这些高优先级事项的目标和上下关联，让团队洞悉产品负责人的思想，关注于理解产品负责人想要什么以及为什么需要它。
关于怎么做
参与者：团队、ScrumMaster、产品负责人（不强制参加，但是要能被找到来回答问题）
长度：时间箱的小时数与Sprint的周数相等
关注于如何实现团队决定要开始做的那些事项。团队预期他们在Sprint结尾能够完成多少事项，从产品待办事项列表的顶部开始（换句话说，就是从对于产品负责人来讲最高优先级的事项开始），并依次查看事项。以下是Scrum中的关键实践：由团队决定将完成多少工作，而不是由产品负责人分配给他们。因为团队是基于他们自己的分析和计划，这使得预期更可靠。虽然产品负责人对于团队接受多少工作没有控制权，但他明白产品待办事项列表中的事项是从顶部开始拿取的，换句话说，就是先拿那些被他评为重要的事项。团队可以为列表中很后面的事项进行游说，这通常发生在团队和产品负责人发现低优先级的某些东西很容易并可以恰当地与高优先级的事项合并时。
4.2 产品待办事项列表梳理
概述 ： 为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。
参与者 ： 团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；Scrum Master将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。
时长 ： 通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。
4.3 Sprint评审会议
概述 ： 演示产品增量，并且在会议上对于功能性的产品增量进行审视并调整。它让产品负责人了解产品和团队的当前状况（也就是对于这个Sprint的评审），也让团队了解产品负责人和市场的当前状况。
参与者 ： 团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。
时长 ： 时间箱为Sprint中的每一周对应一个小时。
4.4 Sprint回顾会议
概述 ： 针对流程和环境进行审视并调整。
参与者 ： 团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其他利益相关人，否则这些人不准参加。
时长 ： 时间箱为对应Sprint中的每一周为45分钟。
4.5 开始下一个Sprint
Sprint评审之后，产品负责人可以根据任何新的见解来更新产品待办事项列表，如添加新事项、删除过时事项或修改现有事项。产品负责人负责保证这些变化反映在产品待办事项列表中。
5.1 工作量估算
5.2 “完成”的定义
是所有代码被check-in就算故事做完了，或者是放到测试环境并且被整合测试团队验证过，才算是做完？
这一点是非常重要的，产品负责人和团队必須同意，要對“做完”有一致的定义。
5.3 每日会议
概述 ： 在团队成员间更新信息和进行协调。
参与者 ： 团队必须参加；产品负责人不是必须的；ScrumMaster通常会在场，但要保证团队自己主持会议。
时长 ： 最长15分钟。
这是一个自组织团队互相分享目前工作情况的时刻，每个团队成员一个接一个地向团队的其他成员报告三件事：
自上次会议以来完成了哪些工作？
在下次会议前有哪些工作会被做完？
遇到了什么阻碍？
5.4 Sprint过程中跟踪进度
Scrum中的团队是自管理的，想要做到这一点，团队必须要知道自己做得怎么样。每天，团队成员都会在Sprint Backlog上更新他们对还需要多少工作量来完成他们当前工作的估计。一个也很常见的做法是有人把这些剩余工作量加起来，然后在Sprint燃尽图上画点。这个图显示每天新的对团队完成工作所剩余工作量的估计。理想中，这应该是一条向下的斜线图，其轨迹指向Sprint最后一天没有剩余工作量的那一点。所以它被称为燃尽图。
人打赏支持
码字总数 46366
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥
& 开源中国(OSChina.NET) |
开源中国社区(OSChina.net)是工信部
指定的官方社区 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
scrum流程培训资料_图文
下载积分：2000
内容提示：scrum流程培训资料_图文
文档格式：PPT|
浏览次数：0|
上传日期： 23:54:39|
文档星级：
该用户还上传了这些文档
scrum流程培训资料_图文
官方公共微信