这周学习到了敏捷开发，老师讲解了敏捷开发的相关细节，课下在网上看了相关的有关于敏捷开发SCRUM方面的资料，敏捷开发是团队合作的一个高效途径，是使团队开发成果快速高效呈现的方式
一.什么是SCRUM
SCRUM 是一个用于开发和维持复杂产品的框架
Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
SCRUM框架包括3个角色、3个工件、5个活动、5个价值
3个角色:产品负责人（Product Owner）、Scrum Master、Scrum团队
3个工件:产品Backlog（Product Backlog）、SprintBacklog、燃尽图（Burn-down Chart)
5个活动:Sprint计划会议（Sprint Planning Meeting）、每日站会（Daily Scrum Meeting）、Sprint评审会议（Sprint Review Meeting）、Sprint回顾会议（Sprint Retrospective Meeting）、产品Backlog梳理会议（ Product Backlog Refinement）
5个价值:承诺 – 愿意对目标做出承诺、专注– 把你的心思和能力都用到你承诺的工作上去、开放– Scrum 把项目中的一切开放给每个人看、尊重– 每个人都有他独特的背景和经验、勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
SCRUM理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱：透明性（Transparency）、检验（Inspection）、适应（Adaptation）。Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
二.SCRUM起源
Scrum的原始含义：Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其他前锋队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、4、1阵形。然后，由犯规队的对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排的3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。
1986 Scrum这个词汇首次应用于产品开发
1993年Jeff Sutherland首次将Scrum用于软件开发
1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。
三.经验性过程
软件产品的研发通常存在多很多的不确定性，并且生产的过程非常的复杂，所以更适合使用经验性过程来管理。Scrum以经验性过程控制理论做为理论基础的过程。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
四.SCRUM团队的三个角色
Scrum团队中包括三个角色，他们分别是产品负责人、开发团队和Scrum Master。
Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他们。
跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。
Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了每个迭代都有潜在可发布的版本。
Scrum角色之：产品负责人
产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。
产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:
- 清晰地表达产品代办事项列表条目
- 对产品代办事项列表中的条目进行排序,最好地实现目标和使命
- 确保开发团队所执行工作的价值
- 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作
- 确保开发团队对产品代办事项列表中的条目达到一定程度的理解
产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是负责任者。
产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。
为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。
Scrum角色之：开发团队
开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。
开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:
- 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。
- 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。
- Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。
- 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队
- 开发团队不包含如测试或业务分析等负责特定领域的子团队。
开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于3人的开发 团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在 Sprint 中可能会受到技能限制,从而导致无法交付可发布的产品增量。大于9人的团队需要过多的协调沟通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和Scrum Master的角色不包含在此数字中,除非他们也参与执行Sprint代表事项列表中的工作。
Scrum角色之：Scrum Master
Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。
Scrum Master 帮助 Scrum 团队外的人员了解他们如何与Scrum团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。
Scrum Master 服务于产品负责人
Scrum Master 以各种方式服务于产品负责人,包括:
- 找到有效管理产品代办事项列表的技巧
- 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目
- 教导开发团队创建清晰简明的产品代表事项列表条目
- 在经验主义环境中理解长期的产品规划
- 理解并实践敏捷
- 按需推动Scrum活动
Scrum Master 服务于开发团队
Scrum Master 以各种方式服务于开发团队,包括:
- 指导开发团队自组织和跨职能
- 教导并领导开发团队创造高价值的产品
- 移除开发团队进展过程中的障碍
- 按需推动Scrum活动
- 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队
Scrum Master 以各种方式服务于组织,包括:
- 领导并指导组织采用 Scrum
- 在组织范围内计划 Scrum 的实施
- 帮助员工及干系人理解并实施 Scrum 和经验性产品开发
- 发起能提升Scrum 团队生产力的变革
- 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum
五.SCRUM的三个工件
Scrum 的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum 中所定义的工件能最大化关键信息的透明性,来保证 Scrum 团队成功地交付完成的增量。
六.SCRUM的五个活动
Scrum活动:产品待办事项列表梳理
产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容:
- 保持产品待办事项列表有序
- 把看起来不再重要的事项移除或者降级
- 增加或提升涌现出来的或变得更重要的事项
- 将事项分解成更小的事项
- 将事项归并为更大的事项
- 对事项进行估算
产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。需要考虑不少因素,这包括但不限于以下的内容:
理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。
产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。
Scrum活动：Sprint计划会议
每个Sprint都以Sprint计划会议作为开始， 这是一个固定时长的会议，在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。
整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog),产 品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定义”,为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时⻓的。Sprint计划会议推荐时长是Sprint中的每周对应两小时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议是限制时⻓长的,Sprint计划会议的成功十分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原因。
在Scrum中,Sprint计划会议有两部分:
- 决定在Sprint中需要完成哪些工作
- 决定这些工作如何完成
决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。
在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。总而言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。
最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。
Scrum活动:每日Scrum会议
开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。这个会议每天在同样的时间和同样的地点召开。每一个开发团队成员需要提供以下三点信息:从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我的进展。每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。通常,许多团队会在每日Scrum之后马上开会处理他们遇到的任何问题。每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解。只有Scrum团队的成员,包括 ScrumMaster和产品负责人,可以在会议中发言。其他感兴趣的人可以来旁听。在必要时, 开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的目标。
每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助 快速发现问题,并促进团队的自组织和自立。所有Scrum会议都是限定时长的。每日Scrum通常不超过15分钟。
Scrum活动:Sprint评审会议
Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则Sprint评审会议时长为2个小时)。
讨论围绕着Sprint中完成的产品增量。由于Sprint的产出会涉及到一些人的“利益”,因此一个明智的做法是邀请他们参加这个会议,这会很有帮助。这个会议是个非正式的会议,帮助大家 了解我们目前进展到哪里,并一起讨论我们下一步如何推进。每个人都可以在Sprint评审会议上发表意见。当然,产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表 (Product Backlog)。
团队会找到他们自己的方式来开Sprint评审会议。通常会演示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。
Sprint评审会议向每个人展示了当前产品增量的概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表。
Scrum活动:Sprint回顾会议
在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则 Sprint回顾会议时⻓长为2个小时)。Scrum团队总是在Scrum的框架内,改进他们自己的流程。
七.SCRUM的五个价值观
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
八.SCRUM的四大支柱
迭代开发
在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。
增量交付
增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。
自组织团队
Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。
高优先级的需求驱动
在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。
九.SCRUM团队
在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）,Scrum Master和开发团队。
我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的团队，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。Scrum的开发团队对实现Sprint目标需要做的所有事情负责，包括技术方案和决策，团队分工（谁做什么），执行Sprint开发任务等，而且作为自组织的团队，他们也对他们的工作进度的跟踪和管理负责。Scrum开发团队的主要职责包括如下五个方面：
- 执行Sprint
- 梳理产品Backlog
- 做Sprint计划
- 每天跟进工作进展，并对他们的工作做检查和调整
- 每个迭代对产品和团队的工作过程做检查和调整
开发团队有如下10方面的特征：
- 自组织
- 多元化、跨职能的完整团队
- 团队成员符合T型技能，即一专多长
- 持续改进
- 最大限制的沟通
- 透明沟通
- 2个披萨的团队大小（5-9人）
- 专注、投入
- 按照可持续的节奏工作
- 团队长期存在，人员稳定