理解为什么 Salesforce 采用敏捷开发
完成本单元后，您将能够：
- 说明为什么 Salesforce 采用敏捷开发
- 列举敏捷开发的一些优势
- 定义 Scrum
- 解释“完成的定义”
- 理解为什么敏捷开发流程对 Salesforce 来说更有效
设想您兴冲冲地前去 Dreamforce，却发现没有主旨演讲、没有新的产品或服务发布、明年没有创新或准备投产的功能。
2006 年 Salesforce 差点也发生这种情况，但是通过实施新的工作流程，革新我们开发和交付产品的方式，我们得以幸免。
从 1999 年 Salesforce 创立的时候开始，我们的技术和产品 (T&P) 团队就像时钟一样准时交付。T&P 团队内部的沟通和协作一直是顺畅、简单的。但是到 2006 年，我们经历了井喷式增长——我们拥有更多客户、更多收入、更多产品，成为了一家更大的公司。跟任何井喷式增长一样，它不是一帆风顺的。
过去轻而易举的所有事情变得不再那么容易。于是，我们开始遭遇创新乏力。
大规模的沟通、协作和管理，同时还要遵守发布日期，变得极具挑战性。显然我们需要一种新的方式，一种围绕顺利的产品交付流程构建的方式——一种能够确保不会延迟发布的方式。
所以我们做了自己最擅长的事情：我们冒着一定风险，重塑了我们交付解决方案的方式。我们采用了一套敏捷开发原则和实践。
为什么要敏捷？
我们在 Salesforce 做的大部分工作是创新驱动、迭代性的。也就是说，最终结果未必总是提前知晓，到达那里的路径是一个在制品。它永远是一次新的冒险！
那并不是说 Salesforce 的所有团队都采用敏捷开发流程。有些团队采用瀑布流框架，这是一种灵活性逊色很多的项目管理流程。您选择哪种流程取决于开始工作项目的时候您知道什么，或不知道什么。
我们来快速看一下瀑布流实践。
- 一切都是提前计划好的。
- 实施之前详细采集要求。
- 每一步都必须完成，然后继续下一步。
- 一开始就注定了结果是什么。
计划 vs. 适应
要确定哪种流程最适合您，可以思考这件事情：假设您在画画，已经决定好了用色、构图、花多少时间来画，以及最终的成品画看起来是什么样的，那么后面就没有多少改动空间了。并不是说这幅画一定不会成为毕加索级别的画作，但是您的流程在设置上无法采纳可能改变成品画（当然是为往好的方向改）的新想法或反馈意见。这种情况下您可以采用瀑布法。
但是当您迭代式作画时，您可以预见会根据早期的反馈、新的想法或者甚至是新的学习（那些色彩的碰撞！）做出改动，而不是按部就班渐进式画画。这是一种更敏捷的方式。
这是那两种画画流程的可视化展示。
图片基于 Jeff Patton 的作品，经许可使用，jpattonassociates.com
工作的复杂性
现在您知道不同流程适合不同类型工作。那么，如何确定哪种流程最适合您和您的团队呢？
试图选择工作流流程的时候，问自己这些问题。
- 关于手上的这个项目我们了解多少？
- 这个项目的目标和要求是否清楚？
- 解决方案是否清楚、明确？
- 团队和利益相关者对于这些方法论有多少经验？
- 这个工作有多复杂？
何时选择瀑布法
简单的工作：
- 工作简单，可预测。
- 任何人都可以确定如何完成工作。
复杂的工作：
- 工作可预测，但是要求专业知识。
- 工作可以自动化。
何时选择敏捷法
复杂的工作：
- 工作立足于一贯的反馈、风险和创新。
- 您想尝试某种东西，看看它效果如何，并且根据新的学习改变路线。
- 您在开发新的产品、软件和服务，您在做一些以前从未做过的事情。
敏捷式扩展 Salesforce
这一次，Salesforce 的领导层开始在多个团队试点实施敏捷开发实践。遭遇了一些抵触，但是 Salesforce 的高管支持这个理念，然后在 2006 年，Salesforce 技术和产品团队重组成一支敏捷开发团队。
当时是什么情况？我们做了下述事情。
- 采用了一种新的交付思维
- 实施了标准化流程
- 提倡精益原则（我们将在以后进一步介绍这个！）
- 将“已完成工作”的含义标准化
我们的全新敏捷开发思维
这种敏捷开发流程到底是什么？简单地说：敏捷开发是各种技术实践、流程、框架、原则和价值观的统称，提倡工作流程的灵活性和对产品的迭代修改。
它是一种迭代式工作方法，团队从项目启动起逐步构建交付物，而不是试图在最后一次性交付成品。敏捷开发有助于团队之间的协调、提高质量、迫使每个人衡量和管理进度，更快为客户交付更多价值。
它完美契合 Salesforce，因为我们当时正在寻求解决在沟通和扩展方面成长的烦恼。
我们的全新敏捷开发流程：从五万英尺高空俯瞰
我们选择在 Salesforce 实施的敏捷开发流程之一是 Scrum，并且有一些配套的具体原则定义我们今天如何工作。
什么是 Scrum？
Scrum 是一种流程，定义了角色、会议和交付物，提供框架来为我们的客户更快交付高品质的价值。
我们为什么采用 Scrum？
Scrum 为我们提供一个灵活的框架，发现我们的产品什么行得通、什么行不通，并且相应地加以修改。通过 Scrum，对于他们面前的工作，每个人都有主人翁精神和共同的期望。
在 Salesforce 中 Scrum 流程是什么样的？
我们采用它的时候，150 个人被分成了小型的跨职能团队，以短期迭代的方式工作（我们称之为短距离冲刺）。目标是稳定地交付并且组织我们的流程。目前，大部分 Salesforce Cloud 团队采用 Scrum 的一些变体形式。
什么是精益原则？
我们也提倡精益原则。这是七条陈述，描述我们的工作流程和交付流程。它们反映我们的 Ohana 文化，强调人们如何最好地合作以推广我们的成功架构。我们稍后会详细介绍。
“已完成”工作的新定义
既然我们有了一种新的工作方式，团队可以随着他们了解到工作流程和产品的新信息，成功地迭代他们的流程。但是我们怎么知道我们真正完成工作项目了呢？
很简单。我们在所有技术和产品团队创建了一个标准的完成的定义 (DoD)，这样每个人都可以清楚地知道什么时候某件事情已经做好了！
这是需要考虑的一种情形：假设您需要创造一个新的产品功能。您把这项新任务分派给了您的团队，让他们在本月实施。他们做完了，然后做别的去了。快进几个月，已完成的工作项目暴露出了新问题。也许是因为集成没有经过充分测试，客户投诉了。也许安全问题没有解决，或者性能不达标。结论：这项工作实际上并没有完成，至少不足以进入部署阶段。
完成的定义是一套指引，规定工作可以称之为真正完成之前团队必须做的每件事情。制定这个标准对于秉持我们的核心 Salesforce 价值观之一：信任至关重要。
简而言之
我们继续问自己：“我们是否在以正确的方式做正确的事情？”如此我们确保我们做的每一件事都以客户为中心。
Scrum 流程的严格加上敏捷开发和精益思维，是改进我们的交付、确保更顺利发布的核心。这是关键，因为 Salesforce 每年面向客户有三个主发布版本。
