拓展阅读
Devops-02-Jpom 简而轻的低侵入式在线构建、自动部署、日常运维、项目监控软件
项目管理平台-01-jira 入门介绍 缺陷跟踪管理系统，为针对缺陷管理、任务追踪和项目管理的商业性应用软件
项目管理平台-01-Phabricator 入门介绍 一套集成的强大工具，帮助公司构建更高质量的软件
Scrum
Scrum是用于开发、交付和维持错综复杂产品 (complex products) 的敏捷框架 (framework)。
最初着重于软件开发，之后已被用应用于其他领域，包括研究、销售、营销和其他先进技术领域。
一个 Scrum 团队建议为十名成员的团队而设计的，他们以迭代[2] （iterative）与增量[3] （incremental）式的方式交付工作，每个迭代称作 Sprint。一个 Sprint 的时间不超过一个月，通常是两星期。
Scrum 团队在每个 Sprint 都专注在唯一一个共同的目标 （Sprint Goal），每天会有称为Daily Scrum的站会，团队中的开发人员（Developers）会检视朝向共同目标的进度，和调适当下的计划。
在 Sprint 结束时，团队会进行 Sprint 审查 (Sprint Review) 跟利害关系人 (Stakeholders) 一起检视当下的结果与调适计划，这是互相资讯交流的机会。最后，团队会进行 Sprint 回顾（Sprint Retrospective）来持续改善。
历史
1986年，竹内弘高 (Hirotaka Takeuchi) 和野中郁次郎 (Ikujiro Nonaka) 在其1986年的《哈佛商业评论》文章“The New New Product Development Game”中，阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：
文章中在产品开发的背景下引入了术语 scrum，他们将这种新的整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而团队“作为一个整体前进，把球传来传去”。
他们对来自汽车，影印机，计算机和打印机等产业的案例进行了研究。
1991年，Peter DeGrace 和 Leslie Hulet Stahl 在《Wicked Problems, Righteous Solutions》[5]一书中将这种方法称为scrum，引用在竹内弘高和 野中郁次郎的文章中提到的 scrum 术语。
1990年代初，肯·施瓦伯 (Ken Schwaber) 在其公司 Advanced Development Methods [6] 使用了一种方法，这种方法后来发展为 Scrum。
同时，杰夫·萨瑟兰 (Jeff Sutherland) 在 Easel 公司开发了一种类似的方法，并使用单个词 scrum 来代表这方法。
1995年，在奥斯汀举办的OOPSLA ‘95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。
2001年，肯·施瓦伯 (Ken Schwaber) 与麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》[8]一书，介绍了Scrum方法。
2002年, 肯·施瓦伯 (Ken Schwaber) 与 Mike Cohn 、Esther Derby 共同建立了 Scrum 联盟 (Scrum Alliance)[9] 并建立了 Certified Scrum 认证系列。
2009年末，肯·施瓦伯 (Ken Schwaber) 离开了Scrum 联盟 (Scrum Alliance), 创立了 Scrum.org [10], 该机构负责监督并行的 Professional Scrum 认证系列。
自2009年以来，肯·施瓦伯 (Ken Schwaber) 和 杰夫·萨瑟兰 (Jeff Sutherland) 已发布并更新了名为 《Scrum 指南》(Scrum Guide)[14]的公共文件。该版本已被修订6次，当前版本为2020年11月。
2020年5月，杰夫·萨瑟兰 (Jeff Sutherland) 在2006年创立的 ScrumInc 公司，开始教授 ‘Scrum Inc 认证系列‘
Scrum的特性
Scrum是一个包括了一系列实践和预定义角色的过程骨架。
Scrum中的主要角色包括：
Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍；
产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资报酬率负责；
开发团队，一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各种技能。
在每一次冲刺或迭代（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个迭代所要实现的功能来自产品订单。产品订单按照优先级排列工作需求。在迭代计划会议中，产品负责人告诉开发团队需要完成产品订单中的哪些订单项。开发团队决定在下一次迭代中他们能够承诺完成多少订单项。在迭代的过程中，没有人能够变更迭代订单，这意味着在一个迭代中需求是被冻结的。
管理Scrum过程有很多实施方法，如即时贴、白板、甚至软件包。
Scrum最大的好处之一是它非常容易学习，而且启动Scrum应用并不需要太多的投入。
Scrum中的角色
Scrum当中定义了许多角色。
按照对开发过程的参与情况，这些角色被分为两组，即猪组和鸡组。
这个分组方法的由来是一个关于猪和鸡合伙开餐馆的笑话：
一天，一头猪和一只鸡在路上散步。
鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”
猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”
鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”
“那可不行”，猪说：“我把自己全搭进去了，而你只是参与而已。”
猪组的成员
猪是在Scrum过程中全身投入专案的各种人物，他们在专案中承担实际工作。
他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。
产品负责人（product owner）
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。
产品负责人编写用户故事，排出优先级，并放入产品订单（product backlog）。产品负责人决定团队每个冲刺（sprint）要完成哪些任务。产品负责人负责最大化产品以及开发团队工作的价值。
产品负责人通过在每个冲刺统一完整地执行Scrum流程，来保持合理开发节奏，从而保障产品的质量。
Scrum主管（或促进者）（scrum master）
Scrum主管促进Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。 Scrum主管并非团队的领导/项目经理（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰（例如某位领导对开发团队的指手画脚）的角色。
Scrum主管确保Scrum过程被按照初衷使用，即维护每个冲刺的流程，确保每个冲刺能够顺利实施。
Scrum主管是规则的执行者。Scrum主管负责团队建设，通过对士气积极主动的调节和鼓舞，来保持团队的凝聚力和战斗力。
开发团队（dev team）
负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作。
鸡组的成员
鸡并不是实际Scrum过程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的实践。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。
用户
软件是为了人而开发的。有人说，“假如森林里有一棵树倒下了，但没有被人听到，那么它算是发出了声音吗？”同样地，人们可以说，“假如软件没有被使用，那么它算是被开发出来了么？”
利益相关者（客户，提供商）
影响项目成功的人，但只直接参与冲刺评审过程。
经理
为产品开发团体搭建环境的人。
Scrum会议
在办公室中间进行的“每日站立会议”，会议的位置有助于会议准时开始
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。
每日站立会议有一些具体的指导原则：
-
会议准时开始。
-
欢迎所有人参加，但只有“猪”可以发言。
-
不论团队规模大小，会议被限制在15分钟。
-
所有出席者都应站立。（有助于保持会议简短）
-
会议应在固定地点和每天的同一时间举行。
在会议上，每个团队成员需要回答三个问题：
-
昨天你完成了哪些有助于推进Sprint目标的工作？
-
今天你打算做什么与自身Sprint目标相关的事？
-
完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
每日 Scrum 限时 15 分钟，详细讨论可于Scrum之后，另开会议讨论。
每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。
举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。
Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。
Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。
同样，Scrum采用了经验方法承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
Scrum会议一共包含以下四种：
-
冲刺计划会议
-
每日站立会议
-
评审会议
-
回顾会议。
文档
产品订单
产品订单（product backlog）是整个专案的概要文档。产品订单包括所有所需特性的粗略的描述。
产品订单是关于将要生产什么样的产品。产品订单是开放的，每个人都可以编辑。
产品订单包括粗略的估算，通常以天为单位。
估算将帮助产品负责人衡量时程表和优先级（例如，如果”增加拼写检查”特性的估计需要花3天或3个月，将影响产品负责人对该特性的渴望）。
冲刺订单
冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。
任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。
冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
燃尽图
燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。
不要把燃尽图与挣值图相混淆。燃尽图可能在一次冲刺的大部分时间内都维持平坦，但计划仍然可以按照既定时间进行。
自适应的项目管理
以下是一些Scrum的通用实践：
客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣。）
和所有其他形式的敏捷软件过程一样，Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更项目需求以适应不断变化的需求。
开发团队经常评估风险并制定缓解计划。在每一个阶段根据承诺进行风险缓解，监测和管理（风险分析）。
计划和模块开发要保持透明，让每一个人知道谁负责什么，以及什么时候完成。
参与者要经常开会以跟踪项目进展 – 平衡的（发布，客户，员工，过程）仪表板更新 – 利益所有者更新。你必须拥有预警机制，例如在可能延期交付时提出警告。
不要隐藏问题。认识到或说出任何没有预见到的问题并不会受到惩罚。
在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
Scrum在其他领域的应用
虽然Scrum最初只应用于软件开发，它也可以被成功地应用于其他产业。
现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。
Scrum用于产品开发
将Scrum应用于产品开发是在《新新产品开发游戏》[4] 第一次提出，之后野中郁次郎和竹内弘高合著的《创造知识的企业》（牛津大学出版社，1995年）进行了详细的阐述。今天Scrum被用于开发金融产品，互联网产品，以及医药产品。
Scrum用作营销项目管理方法
由于市场营销通常以专案的方式运作，许多一般专案管理的原则应用在市场营销上。市场营销也可以像专案管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做些什么，以及整个团队在朝着什么方向前进。
Scrum在市场营销中应用可以：
在早期发现可能的问题，可以更快地，最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”，Scrum鼓励每一个团队成员描述他所遇到的困难，而这个困难可能会对整个团队的工作造成影响。
降低财务风险。 在每一个冲刺周期的开始，企业所有者可以不付出任何代价的改变任何市场营销的因素：包括增加投资以扩大顾客数量，减少投资直至未知风险被减轻，或用于支持其他活动。
使得市场营销计划更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种促销方法在冲刺过程中显示无效，市场营销经理有机会将其换成另一种促销方法。向每一个团队成员说明每一个小的，但重要的任务的交付时间也变得更容易。
使得客户以不同的方式参与。
参考资料
https://zh.wikipedia.org/wiki/Scrum
