SCRUM是一个用于开发和维持复杂产品的框架

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