《Scrum 精髓》之敏捷原则
发布网友
发布时间：2022-09-15 19:00
共1个回答
热心网友
时间：2023-01-21 00:04
Scrum 关注的是在每个迭代中交付可以工作、集成好的、经过测试的、具有业务价值的特性，这样能够更快地交付成果。处于复杂域的组织必须根据竞争对手、客户、用户、监管部门和其他利益相关者之间的互动而快速做出调整，Scrum 能很好地帮助这些组织取得成功。而且，Scrum 还为所有参与者带来更多喜悦。不仅客户满意，做工作的人也很喜欢这种方式！他们喜欢经常的、有意义的合作，团队成员之间的人际关系和相互信任也因此得到提高。
-客户满意
-投资回报提高
- 成本降低
- 迅速取得成果
- 有信心在复杂世界里取得成功
- 更加愉快
虽然 Scrum 在很多情况下都是优秀的解决方案，但不是所有场合都适用。Cynefin 框架（Snowden and Boone，2007）是一个很有意义的框架， 可以帮助我们更好地理解我们工作的环境并确定适合于这种环境的方法。
复杂域 ：在复杂域中工作时，需要采取创造性的、创新的方法。需要为试验活动建立一个容忍失败的环境，以便发现重要信息。在这个环境中，大量的互动与交流是必不可少的。创新的新产品开发活动属于这个类别，通过创新的新特性改进已有产品也属于这个类别。Scrum 特别适合应用于复杂域。在这个环境中，探索（研究）、感知（检视）和响应（调整）的能力非常重要。
繁杂域 ：繁杂问题是专家控制的良好实践域。可能存在多个正确答案，但是需要专家诊断并找出这些答案。Scrum 当然能够处理这些问题，但可能不是最优的解决方案。很多日常软件维护（处理一系列的产品支持或缺陷问题）都属于这一类。
简单域 ：处理简单问题时，原因和结果是显而易见的。通常，正确的答案明显且毫无争议。这是合乎常规的最佳实践域。存在已知的解决方案。我们对情况做出评估后，就可以确定使用哪一种最适合的预定*决方案。Scrum 可以用来解决简单的问题，但对这类问题可能并不是最有效的工具。更适合使用一组明确、可重复的、已知能够解决问题的步骤。
混乱域 ：混乱问题需要快速做出响应。我们深陷危机，需要立即采取行动以防止损失扩大并至少需要重新建立一定的秩序。对于这种情况，Scrum 不是最佳解决方案。我们没有兴趣排列优先级并确定下一个迭代要做什么工作。我们需要立即采取行动的能力，果断停止损失。
无序 ：如果不知道自己处于哪个域，就说明是在无序域中。如果处于无序域，摆脱无序就只能依赖于是把情况分解为一些小的组成部分并分配到另外 4 种域之一。要考虑的不是在无序域中如何使用 Scrum，而是要尽量摆脱这个域。
Scrum 则奉行另一套不同于瀑布模式的敏捷理念，该理念很好地处理了因不确定性程度高而很难做出宏观预测这个问题。 本章所描述的敏捷原则来源较多，包括敏捷宣言（Beck et. all，2001）、精益产品开发（Reinertsten 2009b；Maryand Tom Poppendieck，2003）和“Scrum 指南”（Schwaber and Sutherland, 2011）。
Scrum 巧用产品开发的可变性和不确定性来产生创新解决方案。
1、积极采用有帮助的可变性
在产品中构建的每个特性都不同于该产品的其他特性，所以即使在产品层面也存在可变性
2、采用迭代和增量开发
迭代开发 承认我们在把事情做对之前有可能做错， 在把事情做好之前有可能做坏。（Goldberg and Rubin，1995）迭代开发本身是一种有计划的修改策略。通过多次开发来改善正在构建的特性，逐步得出一个完善的解决方案。
增量开发 基于一个古老的原则：先构建部分，再构建整体。 我们把产品分解成更小的特性， 以便先构建一部分，再从中了解它们在目标使用环境中的具体情形， 然后根据更多的理解来做出调整，构建更多的特性。
3、通过检查、调整和透明性充分利用可变性
Scrum 的核心原则是检验、适应和透明性（Schwaber and Beedle 2011 中将它们统称为“经验过程控制”）。在 Scrum 中，我们不仅要检验和适应正在构建的产品， 还要检验和适应构建产品的方式。
透明性：参与创建产品的每一个人都必须能够得到与在制品相关的所有重要信息。
4、同时减少各种形式的不确定因
开发新产品是一个很复杂的工作，具有很高的不确定性。这种不确定性可以分为两大类（Laufer 1996）：
结果不确定性 （不确定做什么）——围绕最终产品特性的不确定性；
方法不确定性 （不确定怎样做）——围绕产品的开发过程和技术的不确定性；
特定环境或特定产品还可能有 客户不确定性 （不确定用户是谁）。
在使用 Scrum 时， 经常需要平衡预测性的事前工作与适应性的适时工作之间的关系。
1、保持选择开放
在使用 Scrum 时，我们倾向于“保持选 择开放”这个策略。这个原则常被称为“最后责任时刻”（LastResponsible Moment， LRM） （Poppendieck and Poppendieck， 2003） ，意思是推迟做出承诺，直到最后责任时刻再做出重要的、不可逆转的决定。最后责任时刻是什么时候呢？这个时刻就是不做决定的成本大于做决定的成本时。
2、承认无法一开始就把事情做对
在 Scrum 中，我们承认自己不可能事先确定所有需求或计划。事实上，我们认为这样做可能很危险，因为可能漏掉重要的知识而产生大量低质量的需求。
在 Scrum 中，我们也会预先产生需求和计划，但原则是够用就好一旦了解更多在建产品的相关知识， 我们就会填充需求和计划的细节。
3、偏好适应性、探索式的方法
使用（或利用）现在已知的东西并对未知的东西进行预测，这是计划驱动的顺序过程关注的重点。Scrum 则更倾向于恰当运用探索式方法，在此基础上采用适应性的试错法。
探索指的是通过某些活动来获得知识，例如构建原型、创建概念验证、实施研究或进行试验。换句话说，则是面对不确定，我们通过探索来获取信息。工具和技术对探索成本有很大的影响。在过去，软件产品开发的探索成本很高，因而采用预测性的、尽量一开始时做对的方法是有利的。
在 Scrum 中，只要具备足够的知识，就可以得出明智、合理的最终解决方案。然而，在面对不确定性时，不要一厢情愿地预测，要用低成本的探索方式来换取相关信息，并综合利用这些信息得出明智、合理的最终解决方案。
4、用经济合理的方法接受变化
使用顺序开发方式时，后期变更成本比早期变更成本高很多。
不管使用哪种方式来进行产品开发，我们都希望有这样的关系：小的需求变更所造成的实现方式变更也相应较小， 因而成本变更也小（不难想象，大型变更带来的成本显然更高）。我们从这种关系中希望得到的另外一个特征：不管变更请求何时出现，都要保持这种关系。
在 Scrum 中，我们认为变更是很正常的。我们相信，产品开发所固有的不确定性是无法事先通过加班加点来预测的。因此，必须准备好积极主动迎接变更。
5、平衡预测性的事前工作和适应性的刚好及时工作之间的关系
在 Scrum 中，我们承认不可能事先精确获得所有需求和计划。这是否意味着不应该事先做需求和计划呢？当然不是！Scrum 的要义是找到平衡点， 即使平衡预测性的前期工作和适应性的刚好及时工作之间的平衡（参见图 ，改编自 Cohn 2009 中的图）。
由这几个因素推动： 所建产品的类型、待建产品（结果不确定性）和产品构建方式（方法不确定性）的不确定程度以及开发中的*。过度预测要求我们在普遍存在不确定性的情况下做出假设。过度调整可能会让我们处于动荡中，让人觉得工作效率低下、混乱。
在使用 Scrum 时，我们对工作进行组织，快速产生经过验证的认知。
1、快速验证重要的假设
假设， 是指即使某些猜测或看法并没有被之前验证过的认知确认，也认为它是正确、真实或可靠的。
假设本身就意味着重大的开发风险。在 Scrum 中，任何时候的重要假设都要力求最少。我们也不想重要的假设久久得不到验证。在使用 Scrum 时， 如果某个假设本质上就很糟糕，我们就可能很快发现错误并借机恢复。
2、利用多个认知循环并行的优势
在 Scrum 中，我们知道持续获取认知是成功的关键。使用 Scrum时，我们要找到并利用反馈循环来提高认知。在这种产品开发方式中，有一个反复出现的模式，即提出一个假设（或设定一个目标），构建一些东西（执行一些活动），针对构建成果获得反馈，然后利用这个反馈，对照我们提出的假设来检视工作成果。
3、组织妥善工作流程以获得快速反馈
在 Scrum 中，快速反馈对较早截断错误路径有非常重要的帮助作用， 对快速发现并利用时效性强、 突然出现的商机至关重要， 所以更要力争获得快速反馈。
在 Scrum 中，我们组织好工作流，在认知循环中移动，尽快获取反馈。这种做法能够确保工作一完成就能得到及时的反馈。快速反馈能提供较较好的经济效益，因为如果反馈滞后，会加重错误，导致故障呈指数级增长。
在制品（work in process，WIP）指的是已经开始但尚未完成的工作。在产品开发过程中，必须识别出在制品并进行妥善管理。
1、批量大小要经济、合理
“全完方行”（all-before-any） ，即在开始后续活动之前，必须先全部完成当前阶段的所有事情（或者大体完成所有事情）。
如果小批量比大批量好，是不是说明批量大小就应该是 1，也即一次只处理一个需求， 做完所有活动后准备交付给客户？有人将这个过程称为“单件流”（single-piece flow）。
2、识别并管理库存以达到良好的流动
计算机希望做更多事情，但实际完成的高成效工作却更少。一旦进入这个状态，就很难摆脱困境（可能得终止作业或重启机器）。如果使用率保持在 80%左右，计算机的效率会更高一些。
在 Scrum 中，我们敏锐地认识到：需要找出工作流的瓶颈并集中精力消除，相较于努力让每个人都 100%连轴转，这样做更加经济合理。
3、考虑延迟成本
延迟成本是工作延迟或里程碑延迟达成所产生的财务成本。如上图，随着处理能力利用率的增加，队列大小和延迟也有增加。在降低人员空闲浪费的同时（通过增加他们的使用率），也增加了与工作停顿相关的浪费（在队列中等待服务的工作）。
不幸的是，85%的组织都没有对延迟成本进行量化（Reinertsen2009b）。而且，大多数开发组织都意识不到还有正在排队等待处理的工作和积压下来的工作（库存），综合考虑这两个事实，就容易明白他们的默认行为是聚焦于消除人员空闲所造成的可见浪费。
在产品开发过程中，我们会持续面临这种权衡；从经济角度来做合理的决定时，延迟成本是一个需要考虑的、最重要的变量。
在使用 Scrum 时，不是用既定计划的执行情况来衡量进度，也不是看某个特定期间或开发阶段的工作有多大的进展， 而是用已交付且验证过的结果来衡量。
1、根据实时信息来重新制定计划
在 Scrum 开发过程中， 我们的目标不是满足某个计划或者某个事先认为事情如何进展的预言。相反，我们的目标是快速地重新制定计划并根据开发过程中不断出现的、具有重要经济价值的信息进行调整。
2、通过验证工作结果来度量进度
在 Scrum 中，通过构建可工作、已验证的成果来度量进度，这些工作成果交付了价值并且可以被用来验证重大的假设。
3、聚焦于以价值为中心的交付
Scrum 是一种客户价值为中心的开发方式。它是基于优先级排序的增量交付模型， 价值最高的特性持续构建并在下一个迭代中交付。 这样一来， 客户就可以尽快且持续不断地获得高价值特性。
在 Scrum 中，价值的产生是通过向客户交付可运行的成果、验证重大假设或获取有价值的认知来实现的。在 Scrum 中，我们认为中间工件并不能向客户提供直接可以感知的价值， 如果它们本身不能用来产生重要反馈或获取重要认知，就只能是达到目标的一种方式而已。
1、快速前进，但不匆忙
在 Scrum 中，核心目标是灵活、自适应、快速。通过快速前进，我们快速交付、快速获得反馈并尽快将价值交于客户手中。快速的认知和反应能够及早产生收入或降低成本。
不然，很有可能违反 Scrum 可持续节奏的原则——人们应该以长期稳定的节奏工作。而且，匆忙还可能付出牺牲质量的代价。
2、内建质量
在 Scrum 中，质量并不是测试团队在最后阶段“测试”出来的，而是由跨职能的 Scrum 团队负责并持续内建于每个冲刺中。 我们对创建的每个价值增量信心十足，认为这部分工作已经完成，可以放到生产环境或交付给客户 。这样便大大减少了为提高质量而在后期做大量测试的情况。
3、采用最小够用的仪式
计划驱动的开发过程倾向于重仪式、 以文档为中心、 重过程的方法。 Scrum 是以价值为中心的，它带来的一个副作用是，几乎不强调以 过程为中心的仪式。在 Scrum 中，我们的目标是消除可有可无的繁文缛节。因此，我们为仪式设定了一个较低的标准，也就是“最低限度够用”或者“够好即可”。
在使用 Scrum 时，我们是从经济角度仔细审查需要创建哪些文档。如果写了文档却把它束之高阁，并没有增加任何价值，就是浪费时间和金钱创建无用的文档。
做这种对比的目的并不是说服你相信 Scrum 好而瀑布式不好。 说明瀑布方式的基本理念决定着瀑布方式和 Scrum 分别适用于不同的问题。 可以根据具体情况来评估自己的组织到底要解决什么类型的问题，在此基础上选择更合适的工具。
