《Scrum精髓：敏捷转型指南》—执行

执行

在使用Scrum时，我们期望有一些特定的、与执行相关的特点。下面三个原则与这个主题相关：

l  快速前进，但不匆忙。

l  内建质量。

l  采用最小够用的仪式。

快速前进，但不匆忙

计划驱动的开发方式认为，如果遵循计划且第一次就把事情做对，就能避免高成本、耗时长的返工。能够一步步快速前进当然值得期待，但这不是主要目标。

在Scrum中，核心目标是灵活、适应、快速。通过快速前进，我们快速交付、快速获得反馈并尽快将价值交到客户手中。快速的认知和反应能够及早产生收入或降低成本。

但是，不要着急忙慌地快速前进。在Scrum中，虽然时间很重要，但并没有要我们匆忙行事。不然，很有可能违反Scrum可持续节奏的原则——人们应该以长期稳定的节奏工作。而且，匆忙还可能付出牺牲质量的代价。

有一个例子可以帮助澄清快速和匆忙的区别。我研习泰拳（泰国跆拳道）。与其他大多数武术一样，泰拳靠速度来提高水平。能够轻快并准确完成套路或者对打，可以提高运动的趣味性或提高成绩。但是，如果怀着赶紧完成的意图匆忙移动，就会从根本上降低效果，而且，在对打时还会造成严重的身体伤害。在表演泰拳时，要快速适应当时的情况，轻快、灵巧并谨慎地移动。换句话说，要快，但不要匆忙。

以质量为魂

计划驱动的开发过程秉承这样的理念：小心、顺序地执行工作以得到高质量的产品。但是，只有对集成后的产品进行测试，否则不能真正验证质量，然而，集成测试在整个流程中是置后的。如果测试结果表明质量欠佳，就必须进入高成本的“测试—修复”阶段，通过测试来改进质量。而且，因为不同的团队经常做不同阶段的工作，所以测试团队常常被认为是产品质量的最终负责人。

在Scrum中，质量并不是测试团队在最后阶段“测”出来的，而是由跨职能的Scrum团队负责并持续内建于每个冲刺中。我们对创建的每个价值增量信心十足，认为这部分工作已经完成，可以放到生产环境或交付给客户（对完成标准的深入讨论，请参见第4章）。这样便大大减少了为提高质量而在后期做大量测试的情况。

采用最小够用的仪式

计划驱动的开发过程倾向于重仪式、以文档为中心、重过程的方法。Scrum是以价值为中心的，它带来的一个副作用是，几乎不强调以过程为中心的仪式。我并不是说所有的仪式都不好。例如，每周五下班后都去酒吧集体活动并增强关系，这种仪式就很好。我说的仪式是指不必要的繁文缛节。有人称之为“为过程而过程”。这样的仪式消耗成本，但产生的价值却很小，甚至不产生任何价值（换句话说，简直就是一种浪费）。

例如，下面这些仪式就是可有可无的、形式化的。

l  为通过审批而将代码从开发环境迁移到测试环境，这得需要经过一个为期三天的重量级过程才能开始测试。

l  所有异常现象都必须录入软件工具以便追踪和报告，但实际上只需要轻轻拍一下坐在旁边的人，对他说：“嘿，这个不好使，能改一下吗？”等他修复之后，我就可以继续工作了。

l  因为到了规定的写文档时间而写文档，即使没人搞得清楚为什么需要文档以及它有什么价值。

在Scrum中，我们的目标是消除可有可无的繁文缛节。因此，我们为仪式设定了一个较低的标准，也就是“基本够用”（也有人称之为“勉强够用”）或者“够好即可”。当然，不同的组织对于最低限度或者够好的定义也不一样。如果我们开发的是一个新的社交媒体网站，可能只需要很少的仪式。但如果开发的是一个医用起搏器，就得遵守政府的很多规定，这些规定需要某些类型的仪式，这时勉强够用仪式的标准就会更高一些（参见图3.17）。

Scrum关注最小够用仪式，这常常被人们曲解为“Scrum是反文档的。”Scrum并不反对文档。相反，在使用Scrum时，我们是从经济角度仔细审查需要创建哪些文档。如果写了文档却把它束之高阁，并没有增加任何价值，就是浪费时间和金钱创建无用的文档。然而，也不是所有文档都没用。例如，针对下面几种情况，可能就需要写文档。

l  文档要作为产品的一部分交付（例如，安装指南、用户指南等）。

l  我们的目标是保存重要的讨论、决定或协议，以便大家今后能清楚想起讨论过的内容、决议或协议。

l  文档是很有价值的，可以帮助新的团队成员迅速跟进。

l  监管要求提供文档（在受监管行业开展业务就有这个成本）。

尽量避免不增加任何短期和长期经济价值的工作。在Scrum中，我们深信，时间和金钱最好用于交付客户价值。

敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。