什么是Scrum
Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。（源自Scrum中文网）
Scrum基于经验型流程控制理论，其整体框架流程图如图2-1所示。
图2-1 scrum流程示意图（图片来源于网络）
Scrum的起源
Scrum是由Jeff Sutherland（杰夫 萨瑟兰，简称JS）和与Ken Schwaber（肯 施瓦布，简称KS）发明和总结的。两位仍然维护着Scrum Guide。
说到Scrum起源，一般认为Scrum诞生的标志为在1995 年的OOPSLA （Object-Oriented Programming, Systems, Languages & Applications）大会中JS和KS首次共同演说Scrum。那次演讲本质上记录了Ken 和Jeff 在之前几年使用Scrum 时所学到的经验，并且在会议上公布第一版Scrum的正式定义。
一、理论来源
Scrum的理论基础是实验性流程，源于日本制造业。而传授给日本人相关理论的则是一个美国人：戴明（W. Edwards Deming）。将戴明联系到日本的时代的背景是，在美占领日本时期，麦克阿瑟使用以下的手法重建日本经济：开除日本公司的高级管理人员，然后引进美国的管理专家培养基层管理人员。就这样，戴明来到了日本。说到戴明，相信最为人熟知的就是PDCA（Plan，Do，Check，Action）的戴明环。是戴明在日本提出了这个新的理念。而推动这一关键理念在制造业获得成功的是丰田汽车。这套大获成功的体系称之为“精益生产”。精益的关键推动者为丰田英二和大野耐一（5-Why法发明者）。
二、灵感闪现
从50年代，又经过了近30年，终于又是两个日本人，将这种思想、方法传到了软件开发领域。1986年竹 内 弘 高（ Hirotaka Takeuchi） 和 野 中 郁 次 郎（ Ikujiro Nonaka）在哈佛商业评论发表了他们的文章《新新产品开发游戏（The New New Product Development Game）》。这篇文章描述了一种橄榄球方法，方法中“产品开发过程是在一个精心挑选的多学科团队的持续互动中产生的，团队成员从头到尾都在一起工作”。这篇文章也就成为了JS后来Scrum的灵感来源。
1993年，JS在Easel（易索）公司工作。为了更高效的组织团队和开发产品，JS和团队阅读了大量的文章和书籍，最后他们欣喜的发现了上面的文章。他们将理论转化为软件开发过程并应用在Easel的开发项目中。就这样，Scrum诞生了。
三、发展编年史
尔后，就是1995年的正式发布了。一直至今，各种新的概念逐渐的加入到Scrum的体系中。以下是一些关键事件。
1997年：Ken Schwaber描述了“每日Scrum站会（daily scrum）”这个活动后来被Mike Beedle重新整理成了模式形式。
1998年：在最早描述极限编程的文章《走向极限编程的克莱斯勒公司（Chrysler goes to Extremes）》中描述了几个极限编程实践，例如：自选任务（self-chosen tasks）、测试先行（test first）、三周迭代（three week iterations）、集体代码所有权（collective code ownership）和结对编程（pair programming）。
2000年：Scrum的每日站立会议形式中的“三个问题（three questions）”为极限编程团队广泛采用。
2000年：Ken Schwaber首次描述了“燃尽图（burndown chart）”。在富达投资集团工作时，他视图为Scrum团队提供一个简单的工具包，于是发明它，并在其网站上做了正式描述。
2000年：术语“团队速率（velocity）”添加到极限编程相对较晚，用于替代先前的、被认为过于复杂的概念——“负载系数（load factor）”。
2001年2月11-13日：在美国犹他州瓦萨奇山的雪鸟滑雪度假村，17位从事软件开发或者帮助他人从事软件开发的人相聚一堂，以在他们各自不同的软件开发方法中寻找共识。此次会议的产物就是敏捷软件开发宣言（Manifesto for Agile Software Development）。后来几位会议成员继续合作，成立了敏捷联盟（Agile Alliance）
2001年：在英国Connextra公司，发明了用户故事的“role-feature-reason”描述形式。
2002年：Scrum社区汲取了度量“团队速度（velocity）”的实践。
2002年：燃尽图在Scrum社区中获得了普及，以及诸如仅仅反转垂直方向的“燃起图”，或者更复杂的“累积流图（Cumulative Flow Diagram）”，这与燃起非常类似，但似乎是一个独立的发明。
2002年：计划扑克的当前形式在James Grenning的一篇文章中被列出。
2003年：早期的Scrum 培训资料暗示了未来“完成的定义（Definition of Done）”的重要性，最初只是以幻灯片的形式：“关于完成的故事（The story of Done）”。
2007年：简化的三列任务板格式（“Todo”，“Doing”，“Done”）在当时变得比原始的五列版本更流行和更标准
2008年：Kane Mar以“故事时间(Story Time）”作为名称，首先正式描述了“Backlog梳理（backlog grooming）”，并建议把它作为一个例行会议。
2008年：虽然最初提到团队开始使用“就绪的定义（Definition of Ready）”的时间是在年初，但第一次正式的说明似乎是从十月开始的，并且很快就被纳入了“官方”的Scrum培训材料。
2011年：“Backlog梳理（backlog grooming）”实践升级为Scrum的官方元素，并纳入了《Scrum指南（the Scrum Guide）》。
（以上内容来自于简书网https://www.jianshu.com/p/3d40b6c856f7）
Scrum的角色
Scrum框架包括三种角色：产品负责人（Product Owner）、流程管理员（Scrum Master）、开发团队（Scrum Team）。
产品负责人（Product Owner）
产品负责人（Product Owner）主要负责确定产品的功能和产品需要达到的标准，指定产品发布的日期和需要交付的内容。在每个Sprint开始之前，Product Owner可以修改功能需求和优先级，而且，Product Owner 有权决定接受或拒绝开发团队（Scrum Team）的工作成果。在scrum流程中，Product Owner主要做产品需求管理、需求优先级定义、及产品验收等。
Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人员来担任，目前大多数企业指派产品经理担任该角色，其主要目的是根据市场需求确定产品功能，将其列入产品Backlog（Product Backlog）中，并为这些功能确定优先级。开发团队（Scrum Team）按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，以及增加某些功能需求、删除某些功能需求、修改优先级等，但这些行为只能在各个Sprint之间进行。
流程管理员（Scrum Master）
流程管理员（Scrum Master）作为团队Scrum流程的引导者，通常由传统开发中的Team Leader 来担当。
Scrum Master的主要职责是负责监督整个Scrum项目进行，调整项目计划，确保Scrum流程在项目中的顺利实施和进行；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫清障碍；保证开发团队不受外力的干扰和阻扰；掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和 Sprint评审会议。
开发团队（Scrum Team）
开发团队（Scrum Team）主要负责软件产品在Scrum规定流程下进行开发工作，他们根据需求交付产品，团队一般由5-10个全职工作的成员组成，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力，同时具有一定的表达能力。
Scrum Team的团队成员横跨各个职能，通常包括开发、测试、设计人员等，他们可以采用任何工作方式，只要能达到Sprint目标。
Scrum术语
Burndown Charts-燃尽图
燃尽图显示随着时间的推移，还剩下多少工作未完成，通常以时间为横轴，以剩余未完成的user story为纵轴。
Daily Scrum Meeting-每日站立会
每天15分钟的每日例会，每个人回答下面三个问题：
- 上次例会到现在我完成了哪些工作
- 在下次例会前我将完成哪些工作
- 有什么事情阻止我尽可能高效的工作
如果会议的讨论超出了上面的内容，Scrum Master要确保任何与会者可以发起其他会议再来讨论。
每日站立会最好作为每天必须的一件事来做，并且最好都在同一时间同一地点召开。
Impediments-障碍
阻碍任何人高效工作的任何人或事。 在每日会议上，每个队员都有权宣布任何的impediments，由Scrum Master负责解决这些impediments。
Product Backlog-产品特性列表
是指产品待办事项的集合，Product Backlog源自于Scrum方法，主要由Product Owner收集来自于各方的需要、期望、诉求等到Product Backlog中，并定义优先级。常见的Product Backlog表达形式是用户故事。
Product Backlog Item-产品特性列表中的条目
PBI（Product Backlog Item）是可以预知的所有任务，包括功能性和非功能性的任务，PBI属于计划阶段，在表述的时候建议：
- Independent 独立性，避免与其他Story的依赖性
- Negotiable 可谈判性，Scrum中的Story不必太过详细，开发人员可以给出适当的建议
- Valueable 有价值性，Story需要体现出对用户的价值
- Estimable 可预估性，Story应可以估计出Task的开发时间
- Sized Right 合理的尺寸，Stories应该尽量小，并且使得团队在1个sprint完成
- Testable 可测试性，User Story应该是可以测试的，最好有界面可以测试和自动化测试。
PBI的每个条目就是一个工作单元，大小必须限制在团队可以在一个Sprint迭代内完成，同时一个工作单元可以被分解成许多任务。
Product Backlog Item Effort-每个条目的工作量
可以用人天来衡量，推荐的方式是用Story点、功能点或T-Shirt尺寸(大，中，小)。
Product Burndown Chart-产品燃尽图
随着项目过程的开展，Product Burndown Chart基本可以被看成是项目进度的'Big Picture'，显示出每个sprint开始时整个项目还剩多少工作未做。
Product Owner Role-相当于业务代表
负责确定backlog中各条目的优先级及业务决策，同时解决任何的需求问题。
Release-发布
基于预定的时间，每个release会平衡功能，成本，质量三个方面的需求。
Release Burndown Chart-发布燃尽图
Release Burndown Chart与Product Burndown Chart比较相像，不同点在于前者展示单个release的内容，而后者会跨多个release。
Scrum Roles
在Scrum中有一些角色的划分，其中三个主要角色：Product Owner， Scrum Master， Team。 Scrum Master Role 是Product Owner和Scrum Team之间的桥梁，同时推动双方的合作。主要作用在于:
- 消除业务代表和开发团队之间的障碍，帮助业务代表直接推动开发
- 帮助业务代表最大化ROI（Return On Investment，投资回报率），并通过Scrum达到目标
- 通过促进创造力和能力提高开发效率
- 想尽一切办法提高生产力
- 改善工程实践和工具，提高产品的可用性
- 确保最新的项目进度可以让所有人看到
Sprint-一次迭代过程
Sprint规划由整个Scrum团队协作完成，一个sprint通常是1到4周。这个过程是不可被打断的，不能增加额外的需求，确保迭代结束时能够获得预期的结果。现实中会有一些变化，一些项目每次会留出20%左右的时间用于紧急事务及级别最高的产品bugs。这样做存在一定的风险，可能会导致Sprint原则被随意打破。
Sprint Backlog-一次迭代的特性列表，或者说工作列表
展示本次迭代的工作单元，源自产品特性列表。
Sprint Burndown Chart-迭代燃尽图
参考其它的Burndown Chart，粒度更细的图，用于单次迭代过程中。 Sprint Goals 单次迭代的目标，可以被详细说明，可以被衡量，而不是很模糊的一句"改善伸缩性"。
Sprint Planning Meeting-单次迭代的计划会议
每个Sprint都是从Sprint Planning Meeting开始，Scrum团队成员聚集在一起商定下个Sprint目标，决定哪些工作会被放进来，并且确定在Sprint中交付哪些功能。这个会议一般会被限制在四个小时之内。
Sprint Retrospective Meeting-迭代回顾会
Sprint Retrospective Meeting在sprint末期，评审会议之后召开。Team与Scrum Master共同讨论这次sprint中哪些地方做得比较好，哪些地方需要在下次sprint中进一步提高。通常会议时间被限制在三个小时之内。
Sprint Task-四到六小时内完成的工作单元
由队员主动认领。
Team-跨功能团队
人数限制在5-10人，可能包括的角色有工程师，架构师，分析师，QA，测试，UI设计师等。这是一个自发组织的团队，以满足sprint目标。他们自己决定如何最好地满足用户目标，并承担责任。Scrum Master充当保护层，确保Product Owner不会干涉团队工作。
Team Member-研发团队成员
为了达到sprint目标而完成sprint task的任何人。
Velocity-速率
一个团队在单次sprint中完成多少特性的数值。可以从上一次sprint中估算出，通过一次次的sprint，这个数值会为下次的sprint提供相对准确的进度计划。
Load-负载
一个Team在一个Sprint中完成的故事点数。 迭代规划时，负载最好不超过速率的80%。
（以上内容部分来自简书：https://www.jianshu.com）
Scrum过程
在团队中如何使用Scrum启动一个项目，在章节2.1.1的图2-1中有所介绍，下面将对具体实施过程做简要介绍。
- 选定一位产品负责人（Product Owner）
在使用Scrum启动一个项目之前，需要先选定一位产品负责人，这个人必须知道自己带领的团队需要做什么，开发什么产品以及要达到什么效果或者取得什么成果，需要全面考虑产品可行性、风险与回报，以及大家对做这个产品的热情度。 - 选定一个团队（Team）
团队规模不宜大，一般人数限制在5-10人，可能包括的角色有工程师，架构师，分析师，QA，测试，UI设计师等。这个团队以满足sprint目标为宗旨，他们自己决定如何最好地满足用户目标，并承担责任。Scrum Master充当保护层，确保Product Owner不会干涉团队工作。 - 选定Scrum主管（Scrum Master）
Scrum Master对Scrum过程负责，负责培训团队其他成员，确保Scrum得到正确运用，帮助团队消除一切障碍，Scrum Master是Product Owner和Team之间的桥梁，同时推动双方的合作。主要作用在于:
- 消除业务代表和开发团队之间的障碍，帮助业务代表直接推动开发
- 帮助业务代表最大化ROI（Return On Investment，投资回报率），并通过Scrum达到目标
- 通过促进创造力和能力提高开发效率
- 想尽一切办法提高生产力
- 改善工程实践和工具，提高产品的可用性
- 确保最新的项目进度可以让所有人看到
- 拟定待办事项清单，并确定优先级（Product Backlog）
确定研发的产品及团队成员后，就需要拟定产品待办事项，Product Backlog是产品待办事项的集合，主要由Product Owner收集来自于各方的需要、期望、诉求等集合到Product Backlog中，并定义优先级，通常以用户故事的形式表达。这个清单列出了为了落实产品负责人的愿景而需要完成的所有事项。 - 评估和改进待办事项清单
在产品研发的整个过程中 ，团队应审视每一个事项，看看是否切实可行，事项是否有价值等。随着产品研发过程的推进，待办事项清单一直存在，并有所演变，相当于产品研发的路线图。无论在任何时间，想知道一个团队要做的所有事项及顺序，待办事项清单都是唯一的依据。待办事项清单只有一份，这就意味着产品负责人从头到尾必须不断地调整，增加删除事项或者调整顺序。产品负责人应该与所有干系人以及团队进行协商，以确保产品待办事项清单既能反映用户的需求，又不会超出团队的能力范围。 - Sprint规划会议（Sprint Planning Meeting）
每一个Sprint都是从Sprint Planning Meeting开始，第一个Sprint会议亦即第一场Scrum会议，团队成员、Scrum Master以及Product Owner聚集在一起商定Sprint目标，决定哪些工作事项会被放进来，并且确定在Sprint中交付哪些功能。一个Sprint周期一般是固定的，不要超过一个月。Scrum团队要从待办事项清单的顶端着手，也就是最重要的事情，看看一个Sprint能完成多少事项，Scrum Master应该在每一个Sprint中逐步提高这个数字。Scrum的基石之一在于，产品负责人告诉开发团队他需要完成待办事项清单中的哪些事项。开发团队决定在下一个Sprint中他们能够承诺完成多少待办事项。在Sprint中，任何人都不能变更工作事项内容，团队必须在每一个Sprint阶段自主工作。
Sprint Planning Meeting一般会被限制在四个小时之内。 - 确定Sprint工作列表（Sprint Backlog）
在Sprint规划会议上，就确定了下一个Sprint工作事项及工作目标。 - 任务认领（Sprint Task）
确定Sprint工作事项后，由团队成员主动认领该次Sprint中自己需要完成的任务及需要达成的目标，并在该Sprint中自主工作。 - 看板（Burdown Charts）
在Scrum中，最常见的做法是通过进度看板来增加工作透明度，通常可以使用燃尽图来直观展示。
迭代燃尽图-Sprint Burndown Chart用于单次迭代过程中，Product Burndown Chart-产品燃尽图随着项目过程的开展，Product Burndown Chart基本可以被看成是项目进度的'Big Picture'，显示出每个sprint开始时整个项目还剩多少工作未做。 - 每日站立会（Daily Scrum Meeting）
这是Scrum的活力源泉。团队每天在固定时间进行内部沟通，时间一般不超过15分钟，且站立进行，每个人回答下面几个问题：
- 上次例会到现在我完成了哪些工作
- 在下次例会前我将完成哪些工作
- 有什么事情阻止我尽可能高效的工作
如果会议的讨论超出了上面的内容，Scrum Master要确保任何与会者可以发起其他会议再来讨论。同时， Scrum Master要防止每日立会变成每天每个人的工作汇报，而更要像是球队在一起鼓劲，相互帮助，分享信息和商量战术。
- 成果展示
在一个Sprint结束前，给产品负责人展示成果，也就是展示哪些工作事项已经被挪到了“已完成事项”里，并接受评价。这是一场公开的回忆，任何人都可以参与，不仅包括产品负责人，Scrum Master以及开发团队，还包括利益相关者，管理人员和客户（任何项目干系人都可以参与）。
团队应该只展示符合“完成定义”的事项。事项的状态只有已完成/未完成，没有中间状态。 - 迭代发布（Sprint Release）
基于预定的时间，每个Release在平衡功能，成本，质量三个方面的需求后，符合Sprint目标的已完成事项可以在一个Release进行发布。Release Burndown Chart-发布燃尽图用于展示单个Release的内容。 - 迭代回顾会议（Sprint Retrospective Meeting）
Sprint Retrospective Meeting在sprint末期，评审会议之后召开。Team与Scrum Master共同讨论这次sprint中哪些地方做得比较好，哪些地方需要在下次sprint中进一步提高。通常会议时间被限制在三个小时之内。 - 下一个Sprint
上一个Sprint结束后，就开始准备下一个sprint研发，从Sprint Planning Meeting开始。
Scrum会议
sprint plan meeting
sprint规划会议的主要信息如下：
序号ITEM详细说明No.1WHY为即将要开展的sprint指定计划No.2WHO全员参加No.3WHENsprint第一天No.4WHAT本sprint要交付的内容如何完成 1.一般由PO来讲product backlog 2.然后团队来进行评估，得出sprint backlog 3.拆分task以估算时间 4.领取taskNo.5HOW LONG8小时之内（1个月的sprint）No.6INPUT产品列表 最新增量 团队容量 历史数据No.7OUTPUT本次sprint的backlog
daily scrum meeting
序号ITEM详细说明No.1WHY指定24小时的计划No.2WHOScrum Master和开发团队No.3WHEN每天 固定时间 规定地点No.4WHAT3个问题 我昨天做了什么/我今天要做什么/我有什么问题No.5HOW LONG15分钟之内No.6INPUTsprint待办列表No.7OUTPUTsprint待办列表
product backlog refinement meeting
序号ITEM详细说明No.1WHY为接下来的一到两个sprint作准备No.2WHO全员参加No.3WHENsprint进行中No.4WHAT1.澄清 2.拆分 3.排序 4.更新验收标准No.5HOW LONGsprint的5-10%No.6INPUTproduct backlogNo.7OUTPUTproduct backlog
sprint review meeting
序号ITEM详细说明No.1WHY检视增量并调整No.2WHO全员参加No.3WHENsprint结束时No.4WHAT1.done和undong的check 2.问题 3.成果演示 4.下一步计划讨论和调整的讨论No.5HOW LONG4个小时之内No.6INPUT增量 / product backlog / Issue ListNo.7OUTPUT修订版product backlog/下一个sprint的sprint backlog/获取反馈促进合作
sprint retrospective meeting
序号ITEM详细说明No.1WHY为下一个sprint作改进No.2WHO全员参加No.3WHENsprint评审会议结束后No.4WHAT检视/调整/计划No.5HOW LONG1-3小时（1个月的sprint）No.6INPUTBurn Down Chart/评审会议结果/调查结果/sprint backlogNo.7OUTPUT改进计划或下次sprint的改善执行计划
本文参考自：https://blog.csdn.net/liumiaocn/article/details/52475180
Scrum敏捷开发工具
做敏捷开发，如何敏捷？我们需要一系列成熟的工具帮助我们敏捷。敏捷开发工具的适合以及选用，对开发项目起着关键性的作用。
下面介绍几款在scrum敏捷开发中常用的工具，方便更多新加入的开发者上手。
- AxosoftOnTime Scrum
AxosoftOnTime Scrum能够帮助开发团队管理待办事项、产品发布和模拟项目冲刺。这款基于HTML5特性的工具提供创建图表和管理仪表板的功能，随着工作时间的走动，它可以追踪代码特性并修复bug。除此之外，HTML5也是AxosoftOnTime Scrum平台的一部分，兼具一些其它有用的协作工具，例如Wiki和bug追踪器。
- LeanKit
LeanKit使用一个基于云的whiteboard来规划组织过程。每个卡代表一个工作项目，并提供状态更新选项。使用LeanKit的团队可以看见工作负载分配并导出历史数据。
- Leangoo
Leangoo是一款永久免费、简洁、轻量、高可视化的敏捷团队协作工具。由国内最权威的Scrum中文网精心打造，融入了先进的敏捷管理思想。它的核心是看板，通过看板共享和实时同步团队工作以实现高效协同, 团队工作体现为卡片，内容可以是需求、任务、问题等。
Leangoo看板上的主要元素包括列表和泳道，列表管理工作的不同阶段或状态，泳道实现任务的分组对应，从两个纬度让团队的工作 高度可视化、一目了然。
Leangoo可以帮助我们管理事务，需求管理，迭代管理，缺陷管理，测试管理，排列优先级等，随时随地可以了解到团队以及项目的进展情况。
它的思维导图功能也非常强大，可以多人协作，多人在线编辑，实时同步，实时共享。也引用至看板上
更有强大的统计功能：看板统计（燃尽图、任务分布、任务周期）。项目统计（项目进度、团队速度、缺陷分布）。企业级统计（项目状态、需求趋势、缺陷趋势、吞吐量）。
- Planbox
Planbox通过burndown图表来跟踪监视项目的进程，同时结合客户的反馈信息，这项工具所针对的人员是相对较广泛的。
- confluence
进行敏捷开发怎么能少了Confluence，它是一个专业的wiki程序。它是一个知识管理的工具，通过它可以实现团队成员之间的协作和知识共享。想想维基百科，你就知道confluence的便利之处。
- jira
JIRA是项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
493
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
