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

《SCRUM是一个用于开发和维持复杂产品的框架.docx》由会员分享，可在线阅读，更多相关《SCRUM是一个用于开发和维持复杂产品的框架.docx（49页珍藏版）》请在三一办公上搜索。

1、SCRUM Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相

2、应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum流程如下图：SCRUM框架包括3个角色、3个工件、5个活动、5个价值3个角色1. 产品负责人（Product Owner）2. Scrum Master3. Scrum团队3个工件1. 产品Backlog（Product Backlog）2. SprintBacklog3. 燃尽图（Burn-down Chart)5个活动1. Sprint计划会议（Sprint Planning Meeting）2.

3、每日站会（Daily Scrum Meeting）3. Sprint评审会议（Sprint Review Meeting）4. Sprint回顾会议（Sprint Retrospective Meeting）5. 产品Backlog梳理会议（ Product Backlog Refinement）5个价值1. 承诺 愿意对目标做出承诺2. 专注 把你的心思和能力都用到你承诺的工作上去3. 开放 Scrum 把项目中的一切开放给每个人看4. 尊重 每个人都有他独特的背景和经验5. 勇气 有勇气做出承诺，履行承诺，接受别人的尊重SCRUM理论基础Scrum以经验性过程控制理论（经验主义）做为理论基

4、础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：第一：透明性（Transparency）透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。第二：检验（Inspection）开发过程

5、中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。第三：适应（Adaptation）如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审

6、和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。SCRUM术语Scrum： Scrum无对应中文翻译Agile： 敏捷Lean： 精益Iterative：迭代式的Iteration：迭代Agile Manifesto： 敏捷宣言Empirical： 经验性的Empirical Process：经验性过程Transparency： 透明性Inspect and Adapt： 检视与调整Sprint：原意为冲刺，Scrum中的

7、Sprint无对应中文翻译，指一个迭代Sprint Goal：Sprint目标Product Owner ：产品负责人 简称POScrum Master ：简称SM, 一般不翻译Development Team ： Scrum开发团队Scrum Team：指PO,SM和开发团队Scrum Roles：Scrum角色，指PO,SM和开发团队Emergent ：涌现的Product Backlog：产品待办列表，指需求清单Sprint Backlog：Sprint待办列表，指Sprint任务清单Sprint Burn-down Chart：Sprint燃尽图，团队用于做Sprint内的进展跟踪Re

8、lease Burn-down Chart: 发布燃尽图，产品负责人做发布进展跟踪Sprint Planning Meeting: Sprint计划会议Daily Scrum Meeting：每日站会Sprint Review Meeting：Sprint评审会议Sprint Retrospective Meeting: Sprint回顾会议Product Backlog Refinement: 产品待办列表梳理Product Backlog Item: 产品待办清单条目，简称PBIUser Story: 用户故事，指一条需求Story Point：衡量用户故事的工作量大小的计量单位Veloc

9、ity: 团队速度Sprint Task: 实现一条需求需要做的一个技术任务Definition of Done: DoD，完成的定义Stakeholders： 干系人Backlog： 待办列表Artifact ：工件Estimation ：估算Collaboration： 协作Scaling Scrum：大规模ScrumSCRUM起源Scrum的原始含义Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其他前锋队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、

10、4、1阵形。然后，由犯规队的对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排的3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。1986 Scrum这个词汇首次应用于产品开发1986年，竹内弘高和 野中郁次郎在New New Product DevelopmentGame文章首次提到将Scrum应用与产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。1993年Jef

11、f Sutherland首次将Scrum用于软件开发敏捷思想深受日本工业界最佳实践的影响，尤其是丰田和本田公司推行的精益原则，以及竹内弘高和 野中郁次郎开发的知识管理策略。受到以上思想的影响，以及对世界范围内软件项目的研究，Jeff Sutherland在 1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。2001年，Ken Schwaber和Mike Beedl

12、e推出第一本Scrum书籍Scrum敏捷软件开发。2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。经验性过程软件开发是一个复杂的活动， 在软件产品开发的过程中不仅存在着需求的不确定性，也存在着技术的不确定性，再加上参与软件开发的主体通常是由多人组成的软件开发团队，加上人的因素，就让整个软件开发的活动变得非常复杂。如下图所示，软件开发活动通常处在下图的很复杂的区域。图-01为了管理软件开发的活动，我们会引入过程控制来管理它。过程控制通常有两种方式，第一种方式是预定义的过程，第二种方式是经验性过程。我们所熟知的是预定义的过程，它通常是使用已知的方法解决已知的问题。

13、制造业的生产线就是典型的预定义过程，例如生产饼干、啤酒、汽车的生产线等。预定义的过程的特点是给予固定的输入，得到固定的输出，过程可重复。它的优势在于可以大规模批量生产。预定义过程的缺点在于一旦过程定义出现错误，或产品设计上存在瑕疵，会造成比较大的损失。图02如果我们期望解决的问题比较复杂，并且存在着较大的不确定性的时候，我们需要使用经验性过程。经验性过程的特点是过程是不能够完全预先定义好，结果是不可预知的，生产过程是不可重复的。比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断的获得真实的反馈，然后进行适应和调整，使得过程能够产出我们需要的结果。“在过程运行机制相当简单

14、易懂的情况下，典型的做法是采用预定义的建模方式。如果过程复杂程度超出预定义方式的能力范围，便应用经验性方式。” B.A.Ogunnaike and W.H.Ray过程动态学、建模与控制软件产品的研发通常存在多很多的不确定性，并且生产的过程非常的复杂，所以更适合使用经验性过程来管理。Scrum以经验性过程控制理论做为理论基础的过程。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum过程框架的基石包括如下三个方面：第一：透明性（Transparency）透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理

15、生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。第二：检验（Inspection）开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。第三：适应（Adaptation）如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不

16、合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。SCRUM团队的三个角色Scrum团队中包括三个角色，他们分别是产品负责人、开发团队和 Scrum Master。Scrum 团队是自组织、跨职能的完整团队。自组织团队

17、决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他 们。跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了 每个迭代都有潜在可发布的版本。Scrum角色之：产品负责人产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同。产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括: 清晰地表达产品代办事项列表条目 对产品代办

18、事项列表中的条目进行排序,最好地实现目标和使命 确保开发团队所执行工作的价值 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作 确保开发团队对产品代办事项列表中的条目达到一定程度的理解产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求

19、开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。Scrum角色之：开发团队开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点: 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。 Scrum 不认可开发团队成员的头衔,无论承担哪种

20、工作他们都是开发者。此规则无一例外。 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队 开发团队不包含如测试或业务分析等负责特定领域的子团队。开发团队的规模开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于 3 人的开发 团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在 Sprint 中可能会 受到技能限制,从而导致无法交付可发布的产品增量。大于 9 人的团队需要过多的协调沟 通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和 Scrum Master 的角色不包含在此数字中,除非他们也参与执行 Sprint 代表事项列表中的工作

21、。Scrum角色之：Scrum MasterScrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。Scrum Master 服务于产品负责人Scrum Master 以各种方式服务于产品负责人,包括: 找到有效管理产品代办事项列表的技巧 清晰地和

22、开发团队沟通愿景、目标和产品代表事项列表条目 教导开发团队创建清晰简明的产品代表事项列表条目 在经验主义环境中理解长期的产品规划 理解并实践敏捷 按需推动Scrum活动Scrum Master 服务于开发团队Scrum Master 以各种方式服务于开发团队,包括: 指导开发团队自组织和跨职能 教导并领导开发团队创造高价值的产品 移除开发团队进展过程中的障碍 按需推动Scrum活动 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队Scrum Master 以各种方式服务于组织,包括: 领导并指导组织采用 Scrum 在组织范围内计划 Scrum 的实施 帮助员工及干系人理解并实施

23、Scrum 和经验性产品开发 发起能提升Scrum 团队生产力的变革 与其他 Scrum Master 一起工作,帮助组织更有效的应用ScrumSCRUM的三个工件Scrum 的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum 中所定义的工件能最大化关键信息的透明性,来保证 Scrum 团队成功地交付完成的增量。Product Backlog 产品待办事项列表产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的

24、和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列，每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。排序越高的产品待办事项列

25、表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何 一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的

26、变化都会引起产品待办事项列表的变化。若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人可以随时更新产品代办事项列表条目或酌情决定。梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发 团队有自行优化的领域知识。然而,何时如何完成优化是 Scrum 团队的决定。优

27、化通常占用不超过开发团队 10%的时间。开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但是,最后的估算是由执行工作的人来决定的。监控向目标前进的进度在任何时间,达成目标的剩余工作量是可以被累计的。产品负责人至少在每个 Sprint 评审的时候追踪剩余工作总量。产品负责人把这个数量与之前 Sprint 评审时的剩余工作 量做比较,来评估在希望的时间点完成预计工作达成目标的进度。这份信息对所有的干系人都透明。Scrum 不考虑已经花在产品代办事项列表条目上的工作时间。我们只关心剩余工作和日期这两个变量。各种趋势燃尽图、燃烧图和其他计划实践都能用来预测进度。它们已

28、经被证实有用。 然而,这并不能代替经验主义的重要性。在复杂的环境下,将要发生的东西是未知的,只有已经发生的事情才能用来做前瞻式的决策。SPRINT BACKLOGSprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工作的预计。Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。Sprint 代办事项列表使开发团队确定的、达到 Sprint 目标所需的工 作清晰可见。Sprin

29、t 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,比如开发团队按照计划工作并对完成 Sprint 目标所需的 工作有更多的了解。当出现新工作时,开发团队需要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意 义,就可以将其除去。在 Sprint 内只有开发团队可以对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是

30、对团队计划在当前 Sprint 内完成工作的实时反 映,并且,该列表只属于开发团队。Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:1. 随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中。2. 程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作。Product Owner也许会和Scrum team一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更

31、多商业价值。监控 Sprint 进度在 Sprint 中的任意时间点,Sprint 待办事项列表的所有剩余工作总和都可以被计 算。开发团队至少在每日例会时追踪所有的剩余工作。开发团队每天追踪剩余总和并预测 达成 Sprint 目标的可能性。通过在 Sprint 中不断追踪剩余工作,开发团队可以管理自己 的进度。Scrum 不考虑已经花在 Sprint 待办事项列表上的工作时间。我们只关心剩余工作和日期这两个变量。燃尽图（BURN-DOWN CHART)Sprint燃尽图（Sprint Burn-down Chart)Sprint Burndown Chart 显示了Sprint中累积剩余的工作

32、量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能略微呈上升趋势。发布燃尽图（Release Burn-down Chart）在Scrum项目中，团队通过每个Sprint结束时更

33、新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期，以Sprint为单位， Y轴代表的是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。SCRUM的五个活动Scrum活动:产品待办事项列表梳理产品待办事项通常会很大,也很宽泛,而且想法会变来变去、优先级也会变化,所以产品待 办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容: 保持产品待办事项列表有序 把看起来不再重要的事项移除或者降级 增加或提升涌现出来的或变得更重要的事项 将事项分解成更小的事项 将事项归并

34、为更大的事项 对事项进行估算产品待办事项列表梳理的一个最大好处是为即将到来的几个Sprint做准备。为此,梳理时会特别关注那些即将被实现的事项。需要考虑不少因素,这包括但不限于以下的内容:理想情况下,下一个Sprint的备选事项都应该提升“商业价值”。 开发团队需要能够在一个Sprint内完成每一个事项。每个人都需要清楚预期产出是什么。产品开发决定了,有可能需要其它的技能和输入。因此,产品待办事项列表梳理最好是所有团队成员都参与的活动,而不单单是产品负责人。Scrum活动：Sprint计划会议每个Sprint都以Sprint计划会议作为开始， 这是一个固定时长的会议，在这个会议中,Scrum团

35、队共同选择和理解在即将到来的Sprint中要完成的工作。整个团队都要参加Sprint计划会议。针对排好序的产品待办事项列表(Product Backlog),产 品负责人和开发团队成员讨论每个事项,并对该事项达成共识,包括根据当前的“完成的定 义”,为了完成该事项所需要完成的所有事情。所有的Scrum会议都是限定时的。Sprint计划会议推荐时是Sprint中的每周对应两时或者更少(译者注:比如,一个Sprint包含2个星 期,则Sprint计划会议时长应为4个小时或者更少)。因为会议是限制时长的,Sprint计划会议的成功分依赖于产品待办事项列表的质量。这就是产品待办事项列表梳理十分重要的原

36、因。在Scrum中,Sprint计划会议有两部分:1. 决定在Sprint中需要完成哪些工作2. 决定这些工作如何完成第一部分:需要完成哪些工作?在会议的第一部分,产品负责人向开发团队介绍排好序的产品待办事项,整个Scrum团队共同理解这些工作。Sprint中需要完成的产品待办事项数目完全由开发团队决定。为了决定做多少,开发团队需要考虑当前产品增量的状态,团队过去的工作情况,团队当前的生产能力,以及排好序的产品待办事项列表。做多少工作只能由开发团队决定。产品负责人或任何其它人,都不能给开发 团队强加更多的工作量。通常Sprint都有个目标,称作Sprint目标。这将十分有效地帮助大家更加专注于

37、需要完成的工 作的本质,而不必花太多精力去关注那些对于我们需要完成的工作并不重要的小细节。第二部分:如何完成工作?在会议的第二部分里,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增 量。他们进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作。头几天的工作会 被分解成小的单元,每个工作单元不超过一天。之后要完成的工作可以稍大些,以后再对它 们进行分解。决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。在计划会议的第二部分,产品负责人可以继续留下来回答问题,以及澄清一些误解。不管怎样,团队应该很容易找到产品负责人。Sprint计划会议的产出 Spri

38、nt计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,并预期在一个合理的条件范围内完成它们。开发团队预测并共同承诺他们要完成的工作量。 总而言之:在Sprint计划会议中,开发团队和产品负责人一起考虑并讨论产品待办事项,确保他们对这些事项的理解,选择一些他们预测能完成的事项,创建足够详细的计划来确保他们能够完成这些事项。最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。Scrum活动:每日Scrum会议开发团队是自组织的。开发团队通过每日Scrum会议来确认他们仍然可以实现Sprint的目标。 这个会议每天在同样的时间和同样的

39、地点召开。每一个开发团队成员需要提供以下三点信息:从上一个每日Scrum到现在,我完成了什么; 从现在到下一个每日Scrum,我计划完成什么; 有什么阻碍了我的进展。每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。通常,许多团队 会在每日Scrum之后马上开会处理他们遇到的任何问题。每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报。它是一个开发 团队内部的沟通会议,来保证他们对现状有一致的了解。只有Scrum团队的成员,包括 ScrumMaster和产品负责人,可以在会议中发言。其他感兴趣的人可以来旁听。在必要时, 开发团队会基于会议中

40、的发现重新组织他们的工作来完成Sprint的目标。每日Scrum是Scrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助 快速发现问题,并促进团队的自组织和自立。所有Scrum会议都是限定时长的。每日Scrum通 常不超过15分钟。Scrum活动:Sprint评审会议Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长 的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint 包含2个星期,则Sprint评审会议时长为2个小时)。讨论围绕着Sprint中完成的产品增量。由于Spr

41、int的产出会涉及到一些人的“利益”,因此一个明 智的做法是邀请他们参加这个会议,这会很有帮助。这个会议是个非正式的会议,帮助大家 了解我们目前进展到哪里,并一起讨论我们下一步如何推进。每个人都可以在Sprint评审会议 上发表意见。当然,产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表 (Product Backlog)。团队会找到他们自己的方式来开Sprint评审会议。通常会演示产品增量,整个小组也会经常讨论他们在Sprint中观察到了什么、有哪些新的产品想法出现。他们还会讨论产品待办事项列表 的状态、可能的完成日期以及在这些日期前能完成什么。Sprint评审会议向每个人展示

42、了当前产品增量的概况。因此,通常都会在Sprint评审会议中调 整产品待办事项列表。Scrum活动:Sprint回顾会议在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在 的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的 推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则 Sprint回顾会议时长为2个小时)。Scrum团队总是在Scrum的框架内,改进他们自己的流程。SCRUM的五个价

43、值观1. 承诺 愿意对目标做出承诺2. 专注 把你的心思和能力都用到你承诺的工作上去3. 开放 Scrum 把项目中的一切开放给每个人看4. 尊重 每个人都有他独特的背景和经验5. 勇气 有勇气做出承诺，履行承诺，接受别人的尊重SCRUM的四大支柱迭代开发在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。增量交付增

44、量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。自组织团队Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。高优先级的需求驱动在Scrum中

45、，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。SCRUM团队在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，

46、程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）,Scrum Master和开发团队。我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的团队，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体

47、前进，在这样的环境下单打独斗，各自为政没有任何胜算。Scrum的开发团队对实现Sprint目标需要做的所有事情负责，包括技术方案和决策，团队分工（谁做什么），执行Sprint开发任务等，而且作为自组织的团队，他们也对他们的工作进度的跟踪和管理负责。Scrum开发团队的主要职责包括如下五个方面： 执行Sprint 梳理产品Backlog 做Sprint计划 每天跟进工作进展，并对他们的工作做检查和调整 每个迭代对产品和团队的工作过程做检查和调整开发团队有如下10方面的特征： 自组织 多元化、跨职能的完整团队 团队成员符合T型技能，即一专多长 持续改进 最大限制的沟通 透明沟通 2个披萨的团队大小（5-9人） 专注、投入 按照可持续的节奏工作 团队长期存在，人员稳定自组织团队什么是自组织团队？自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。自组织团队和经理