1、SCRUM 敏捷管理知识一、 什么是 scrumScrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个 Sprint 的建议长度是 2 到 4 周(互联网产品研发可以使用 1 周的 Sprint)。在 Scrum 中，使用产品 Backlog 来管理产品的需求，产品 backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 团队总是先开发对客户具有较高价值的需求。在 Sprint 中，Scrum 团队从产品 Backlog 中挑选最高优先级
2、的需求进行开发。挑选的需求在 Sprint 计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为 Sprintbacklog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。Scrum 起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum 流程如下图：SCRUM 框 架 包 括 3 个 角 色 、 3 个 工 件 、 5 个 活 动 、 5 个 价 值 ， 具 体 说 明 如 下 ：3 个角色1. 产品负责人（ProductOwner）2. ScrumMaster3. Scrum 团队3 个工件1. 产品 Backlog（ProductBacklog）2.
3、 SprintBacklog3. 产品增量（Increment）5 个活动1. 产品 Backlog 梳理会议（ProductBacklogRefinement）2. Sprint 计划会议（SprintPlanningMeeting）3. 每日站会（DailyScrumMeeting）4. Sprint 评审会议（SprintReviewMeeting）5. Sprint 回顾会议（SprintRetrospectiveMeeting）5 个价值1. 承诺愿意对目标做出承诺2. 专注把你的心思和能力都用到你承诺的工作上去3. 开放Scrum 把项目中的一切开放给每个人看4. 尊重每个人都有他
4、独特的背景和经验5. 勇气有勇气做出承诺，履行承诺，接受别人的尊重SCRUM 理 论 基 础Scrum 以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验,以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum 的三大支柱如下：第一：透明性（Transparency）透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的
5、内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。第二：检验（Inspection）开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。第三：适应（Adaptation）如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，
6、以减少进一步的偏差。Scrum 中通过三个活动进行检验和适应：每日例会检验 Sprint 目标的进展，做出调整，从而优化次日的工作价值；Sprint 评审和计划会议检验发布目标的进展，做出调整，从而优化下一个 Sprint 的工作价值；Sprint 回顾会议是用来回顾已经完成的 Sprint，并且确定做出什么样的改善可以使接下来的 Sprint 更加高效、更加令人满意，并且工作更快乐。二 、 SCRUM 术 语Scrum：Scrum 无对应中文翻译Agile：敏捷Lean：精益Iterative：迭代式的Iteration：迭代AgileManifesto：敏捷宣言Empirical：经验性的
7、EmpiricalProcess：经验性过程Transparency：透明性InspectandAdapt：检视与调整Sprint：原意为冲刺，Scrum 中的 Sprint 无对应中文翻译，指一个迭代SprintGoal：Sprint 目标ProductOwner：产品负责人简称 POScrumMaster：简称 SM,一般不翻译DevelopmentTeam：Scrum 开发团队ScrumTeam：指 PO,SM 和开发团队ScrumRoles：Scrum 角色，指 PO,SM 和开发团队Emergent：涌现的ProductBacklog：产品待办列表，指需求清单SprintBacklo
8、g：Sprint 待办列表，指 Sprint 任务清单SprintBurn-downChart：Sprint 燃尽图，团队用于做 Sprint 内的进展跟踪ReleaseBurn-downChart:发布燃尽图，产品负责人做发布进展跟踪SprintPlanningMeeting:Sprint 计划会议DailyScrumMeeting：每日站会SprintReviewMeeting：Sprint 评审会议SprintRetrospectiveMeeting:Sprint 回顾会议ProductBacklogRefinement:产品待办列表梳理ProductBacklogItem:产品待办清单
9、条目，简称 PBIUserStory:用户故事，指一条需求StoryPoint：衡量用户故事的工作量大小的计量单位Velocity:团队速度SprintTask:实现一条需求需要做的一个技术任务DefinitionofDone:DoD，完成的定义Stakeholders：干系人Backlog：待办列表Artifact：工件Estimation：估算Collaboration：协作ScalingScrum：大规模 Scrum三 、 SCRUM 起 源Scrum 的原始含义Scrum 原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有 8 个队员参与，各方出 3 名前锋队员，并肩各站
10、成一横排，面对面躬身互相顶肩，中间形成一条通道，其他前锋队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成 3、2、3 或3、4、1 阵形。然后，由犯规队的对方队员在对阵一侧 1 码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排的 3 对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。1986Scrum 这个词汇首次应用于产品开发1986 年，竹内弘高和野中郁次郎在 NewNewProductDevelopmentGame 文章首次提到将 Scrum应用与产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市
11、场需求，而整体或“橄榄球式”的方法团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。1993 年 JeffSutherland 首次将 Scrum 用于软件开发敏捷思想深受日本工业界最佳实践的影响，尤其是丰田和本田公司推行的精益原则，以及竹内弘高和野中郁次郎开发的知识管理策略。受到以上思想的影响，以及对世界范围内软件项目的研究，JeffSutherland 在 1993 年首次在 Easel 公司定义了用于了软件开发行业的 Scrum 流程，并开始实施。1995 年 JeffSutherland 和 KenSchwaber 规范化了 Scrum 框架，并
12、在 OOPSLA95 上公开发布。2001 年敏捷宣言及原则发布、敏捷联盟成立，Scrum 是其中一种敏捷方法。2001 年，KenSchwaber 和 MikeBeedle 推出第一本 Scrum 书籍Scrum 敏捷软件开发。2002 年 KenSchwaber 和 MikeCohn 共同创办了 Scrum 联盟。四 、 经 验 性 过 程软件开发是一个复杂的活动，在软件产品开发的过程中不仅存在着需求的不确定性，也存在着技术的不确定性，再加上参与软件开发的主体通常是由多人组成的软件开发团队，加上人的因素，就让整个软件开发的活动变得非常复杂。如下图所示，软件开发活动通常处在下图的很复杂的区域
13、。图-01为了管理软件开发的活动，我们会引入过程控制来管理它。过程控制通常有两种方式，第一种方式是预定义的过程，第二种方式是经验性过程。我们所熟知的是预定义的过程，它通常是使用已知的方法解决已知的问题。制造业的生产线就是典型的预定义过程，例如生产饼干、啤酒、汽车的生产线等。预定义的过程的特点是给予固定的输入，得到固定的输出，过程可重复。它的优势在于可以大规模批量生产。预定义过程的缺点在于一旦过程定义出现错误，或产品设计上存在瑕疵，会造成比较大的损失。图02如果我们期望解决的问题比较复杂，并且存在着较大的不确定性的时候，我们需要使用经验性过程。经验性过程的特点是过程是不能够完全预先定义好，结果是
14、不可预知的，生产过程是不可重复的。比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断的获得真实的反馈，然后进行适应和调整，使得过程能够产出我们需要的结果。“在过程运行机制相当简单易懂的情况下，典型的做法是采用预定义的建模方式。如果过程复杂程度超出预定义方式的能力范围，便应用经验性方式。”B.A.OgunnaikeandW.H.Ray过程动态学、建模与控制软件产品的研发通常存在多很多的不确定性，并且生产的过程非常的复杂，所以更适合使用经验性过程来管理。Scrum 以经验性过程控制理论做为理论基础的过程。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum
15、过程框架的基石包括如下三个方面：第一：透明性（Transparency）透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。第二：检验（Inspection）开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸
16、运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。第三：适应（Adaptation）如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。Scrum 中通过三个活动进行检验和适应：每日例会检验 Sprint 目标的进展，做出调整，从而优化次日的工作价值；Sprint 评审和计划会议检验发布目标的进展，做出调整，从而优化下一个 Sprint 的工作价值；Sprint 回顾会议是用来回顾已经完成的 Sprint，并且确定做出什么样的改善可以使接下来的 S
17、print 更加高效、更加令人满意，并且工作更快乐。五 、 SCRUM 团 队 的 三 个 角 色Scrum 团队中包括三个角色，他们分别是产品负责人、开发团队和 ScrumMaster。Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他们。跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了每个迭代都有潜在可发布的版本。Scrum 角色之：产品负责人产
18、品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组织、Scrum 团队以及单个团队成员的不同而不同。产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括: 清晰地表达产品代办事项列表条目 对产品代办事项列表中的条目进行排序,最好地实现目标和使命 确保开发团队所执行工作的价值 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作 确保开发团队对产品代办事项列表中的条目达到一定程度的理解产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是负责任者。产品负责人是一个人,而不是一个委员会。产品负责人可能会在产
19、品代办事项列表中体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。Scrum 角色之：开发团队开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产品增量。只有开发团队的成员才能创造增量。开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化开发团队的整体效率和效力。开发团队有以下几个特点: 他们是自组织的,没有人
20、(即使是 ScrumMaster 都不可以)告诉开发团队如何把产品代办事项列表变成潜在可发布的功能。 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。 Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队 开发团队不包含如测试或业务分析等负责特定领域的子团队。开发团队的规模开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于 3 人的开发团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在 Sprint 中可能会受到技能限制,从而导致无法交付可发布
21、的产品增量。大于 9 人的团队需要过多的协调沟通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和 ScrumMaster 的角色不包含在此数字中,除非他们也参与执行 Sprint 代表事项列表中的工作。Scrum 角色之：ScrumMasterScrumMaster 负责确保 Scrum 被理解并实施。为了达到这个目的,ScrumMaster 要确保Scrum 团队遵循 Scrum 的理论、实践和规则。ScrumMaster 是 Scrum 团队中的服务式领导。ScrumMaster 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。ScrumMast
22、er 通过改变这些交互来最大化 Scrum 团队所创造的价值。ScrumMaster 服务于产品负责人ScrumMaster 以各种方式服务于产品负责人,包括: 找到有效管理产品代办事项列表的技巧 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目 教导开发团队创建清晰简明的产品代表事项列表条目 在经验主义环境中理解长期的产品规划 理解并实践敏捷 按需推动 Scrum 活动ScrumMaster 服务于开发团队ScrumMaster 以各种方式服务于开发团队,包括: 指导开发团队自组织和跨职能 教导并领导开发团队创造高价值的产品 移除开发团队进展过程中的障碍 按需推动 Scrum 活动 在
23、Scrum 还未完全被采纳和理解的组织环境下指导开发团队ScrumMaster 服务于组织ScrumMaster 以各种方式服务于组织,包括: 领导并指导组织采用 Scrum 在组织范围内计划 Scrum 的实施 帮助员工及干系人理解并实施 Scrum 和经验性产品开发 发起能提升 Scrum 团队生产力的变革 与其他 ScrumMaster 一起工作,帮助组织更有效的应用 Scrum六 、 SCRUM 的 三 个 工 件Scrum 的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum 中所定义的工件能最大化关键信息的透明性,来保证 Scrum 团队成功地交付完
24、成的增量。ProductBacklog产品待办事项列表产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。产品待办事项列表是一个持续完善的清单,最初的版本只列出最初始的和众所周知的需求。产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列，每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何一
