《Scrum精髓：敏捷转型指南》—Scrum能给你带来帮助吗？

Scrum能给你带来帮助吗？

Genomica公司在采用Scrum之前，构建出来的特性都没人要，不仅延期交付，质量还很差。类似Genomica这样的情况并不少见。像很多其他公司一样，Genomica之所以能够生存下来，仅仅只是因为竞争对手比我们做得还要烂。20世纪80年代中期，我刚刚开始涉足商业软件开发时，看到的也是这个问题。30年过去了，很多公司的状况并没有得到改善。

今天，如果把业务人员和开发人员找到一起，问：“你们对软件开发工作的结果感到满意吗？”或者“你们认为我们是否及时、经济、高质量地交付了良好的客户价值？”他们会怎样回答呢？

通常，我在世界各地提供培训和指导时，人们对这两个问题都给出一个响亮的回答：“否。”接下来大家的说法如同一辙：“项目失败率高得让人无法接受”；“交付日期延迟了”；“投资带来的回报常常达不到预期”；“软件质量很差”；“生产率低得让人羞愧”；“没有人对结果负责”；“员工士气低落”；“员工离职率太高”。一阵低声窃笑之后又会假惺惺地说：“肯定有更好的方法。”

虽然有诸多不满意的地方，但大多数人都普遍接受这样的事实：“不满意”是软件开发现状的组成部分之一。但实际上未必如此。

认真踏实地使用Scrum的团队和组织，却是另一番不一样的现实（参见图1.2）。

图1.2  Scrum带来的好处

这些组织总是让客户感到满意，他们不仅交付了客户第一天在对真正需求知之甚少的情况下提出的功能，而且交付了客户真正想要的功能。他们还更频繁地发布了较小的版本并由此提升了投资回报。而且，毫不留情地暴露组织功能失调和浪费的地方，还为他们降低成本。

Scrum关注在每个迭代交付可以工作、集成好的、经过测试的、具有业务价值的特性，力争更快交付成果。处于复杂域的组织必须根据竞争对手、客户、用户、监管部门和其他利益干系人之间的互动快速做出调整，Scrum能很好地帮助他们取得成功。而且，Scrum还为所有参与者带来更多喜悦。不仅客户满意，做工作的人也很喜欢这种方式！他们喜欢经常的、有意义的合作，团队成员之间的人际关系和相互信任也因此得到提高。

不要误会我的意思。虽然Scrum在很多情况下都是优秀的解决方案，但不是所有场合都适用。Cynefin框架^[1]（Snowden and Boone，2007）是一个很有意义的框架，可以帮助我们更好地理解工作环境并确定合适的工作方式。这个框架定义并比较了5种不同域的特征：简单（Simple）、复杂（Complex）、混乱（Chaotic）、繁杂（Complicated）和无序（Disorder）（参见图1.3）。我将使用Cynefin框架讨论Scrum的最佳（差）使用情景。

首先，重要的一点是认识到，软件开发和支持活动的很多方面都不可能只是与某一个Cynefin域相吻合。软件开发工作内容丰富，各方面又有重叠，所以各个活动可能属于不同域（Pelrine 2011）。因此，虽然大多数软件开发工作都处于复杂域或繁杂域，但如果冒然说软件开发活动是一个复杂域，也未免太幼稚，特别是，如果我们定义的软件开发活动包含从创新产品开发、现有产品维护到运营与支持等各种工作，情况就更是这样了。

图1.3  Cynefin框架

复杂域

在处理复杂问题时，不可预测性于可预测性。如果有正确答案，我们也只能事后知道。这是涌现域。需要在研究之后才能认识问题，然后根据我们的认知来检视与调整。在复杂域中工作时，需要采取创造性的、创新的方法。常规、轻而易举的解决方案是不适用的。我们需要为试验活动建立一个容忍失败的环境，以便发现重要信息。在这个环境中，大量的互动与交流是必不可少的。创新的新产品开发活动属于这个类别，通过创新的新特性改进已有产品也属于这个类别。

Scrum特别适合复杂域。在这个环境中，探索（研究）、感知（检视）和响应（调整）的能力非常重要。

繁杂域

繁杂问题是专家控制的良好实践域。可能有很多正确答案，但是需要专家诊断并找出这些答案。Scrum当然能够处理这些问题，但可能不是最优的解决方案。例如，性能优化工作需要调整参数来找出系统的最佳整体性能，这个工作最好能找到专家，让他们评估情况，调研几种备选方案，根据良好实践做出响应。很多日常软件维护（处理一系列的产品支持或缺陷问题）都属于这一类。虽然很多类似于六西格玛等策略性量化方法也适合简单域，但这些方法最适合繁杂域。

简单域

在处理简单问题时，因果关系是显而易见的。通常，正确的答案明显而且毫无争议。这是合乎常规的最佳实践域。有已知的解决方案。我们对情况做出评估后，就可以确定使用哪一种最合适的解决方案。Scrum可以用来解决简单的问题，但对这类问题可能并不是最有效的工具。更适合使用一组明确、可重复的、已知能够解决问题的步骤。例如，如果需要重复性生产同样的产品，一个明确的、流水线过程就优于Scrum。或者如果是在第100个客户环境中部署同一个商用（COTS）软件，最好重复使用一套明确的、经过证明的产品安装和配置步骤。

混乱域

混乱问题需要快速做出响应。我们深陷危机，需要立即采取行动以防止损失进一步扩大并至少需要重新建立一定的秩序。比如说，假设某所大学发表一篇文章称我们产品中的算法存在缺陷，会造成计算错误。客户在我们产品上已经投入了一大笔资金，针对我们给他们造成的巨大损失，他们正准备提起诉讼。我们的首席算法设计师正在加里曼丹岛的丛林中度假，两周后才能赶回来。对于这种情况，Scrum不是最佳解决方案。我们没有兴趣排列优先顺序并确定下一个迭代要做什么工作。我们需要能够立即采取行动，果断止损。对于混乱问题，需要有人控制局面并采取行动。

无序

如果不知道自己处于哪个域，就说明是在无序域中。因为无法理解自己的处境，所以这个域很危险。此时，人们一般会根据个人的行为偏好进行解释并采取行动。在软件开发中，很多人都熟悉适合解决简单问题的、基于阶段的顺序方法，也因此喜欢使用它们。但遗憾的是，正如我在第3章将要讨论的，一般来说，那些方法并适合大多数软件开发工作。如果处于无序域，摆脱无序就只能依赖是把问题分解为一些小的组成部分并分配到另外4种域之一。要考虑的不是在无序域中如何使用Scrum，而是要尽量摆脱这个域。

事务性工作

Scrum不太适合事务性工作。假设客户支持行业，你想使用Scrum组织并管理客户支持活动。要求提供支持请求的电话或邮件接二连三，产品列表也随之不断增加。在任何一个时刻你都无法并不适合大多数列表在未来很长一段时间内保持稳定，列表的内容和顺序可能会频繁变化（也许每个小时或每隔几分钟）。

在这种情况下，因为不知道今后很长一段时间中会有多少工作，所以无法为一周或更长时间的迭代制定可行的计划。而且，即使认为自己知道有多少工作要做，也很可能收到高优先级的支持请求并把预先制定的长远计划替换掉。

对于事务性工作，最好考虑另一种敏捷方法，即看板。看板不是一个独立的过程解决方案，而是一种与现有过程重叠的方法。具体而言，看板提倡以下要素。

l  通过看板，让工作流程可视化（例如，提供支持的组织为解决支持请求而需要采取的步骤）。

l  限制每一步的WIP数量，确保所做的工作不超出自己的能力（容量）。

l  通过使用系统，度量并优化工作流程，实现持续改进。

软件维护和支持领域最适合使用看板。有些看板实践者指出，看板关注于消除过重的负担（采取的方式是让WIP与能力保持一致），减少流程中的反复无常，同时鼓励采用渐进式变革，这些特点决定着看板也适用于复杂域。

Scrum和看板都是敏捷开发方法，在认识到工作所处的域后，要分别考虑这两种方法的利与弊。在某些组织中，Scrum和看板都可以用来满足不同系统同时存在的要求。例如，Scrum可以用于新产品开发，看板用于常常被打断的支持与维护工作。