Salesforce开发生命周期(1)介绍

学习目标

完成本单元后,您将能够:

  1. 在生产组织中开发
  2. 用Sandbox开发
  3. 沙箱组织
  4. 快速入门:使用沙箱和更改集
  5. 创建开发人员沙箱
  6. 授权部署连接
  7. 创建和上载出站变更集
  8. 验证入站变更集
  9. 部署入站变更集

 

  1. 在Lightning平台上开发应用程序非常简单,直接且高效。开发人员可以使用Web界面的点击工具定义应用程序组件,例如自定义对象和字段,工作流规则,Visualforce页面以及Apex类和触发器。可以立即实施和部署简单更改,而不会影响生产组织中的其他用户。更复杂的功能可以保留在开发状态,直到它们经过全面测试,然后部署到生产组织中的每个人。
  2. 但是,与其他几个开发人员合作构建大型企业应用程序时,这些相同的开发实践如何运作?在使用高度自定义的逻辑和用户界面开发复杂应用程序时,在单一环境中即时配置不再有意义。这些应用程序需要时间来开发,并需要更多正式的实践来​​确保它们按预期工作并满足用户的需求。

    还有很多中间立场。您的项目可能看起来不那么大,也许您正在自己进行开发以及日常管理任务。您仍然可以使用沙箱作为开发环境 – 您可以在不影响最终用户的情况下开发自定义和代码的地方。更传统的基于项目的开发为Lightning Platform开发开辟了新的可能性,但也需要新的开发,迁移和同步流程。

    无论您是架构师,管理员,开发人员还是经理,本指南都将帮助您准备在Lightning平台上开发和发布应用程序。它从最基本的场景开始,使用开发人员沙箱和更改集。后面的章节介绍了更复杂的企业方案的其他开发环境,工具和流程。

    Develop in a Production Organization

    开发新功能的最简单方法是使用Salesforce Web用户界面自定义生产组织。 您可以使用功能强大且易于使用的声明性工具开发新对象和应用程序。 在这种情况下,所有开发都在生产组织上进行,因此不需要单独的开发或测试环境。 虽然此过程是完成开发生命周期循环的最快方法,但您可以完成的任务有限。 例如,您无法直接在生产组织中编写Apex代码。

 

典型的开发生命周期:

  1. 规划功能要求。
  2. 使用Salesforce Web工具进行开发,使用配置文件隐藏您的更改,直到它们准备好部署。
  3. 更新配置文件以显示对相应用户的更改。
  4. 通知最终用户更改。

单个管理员可以有效地开发新的仪表板,报告和电子邮件模板,或者以这种方式向现有对象添加新的自定义字段。但是,当开发更复杂并且涉及多个团队成员时,更正式的应用程序生命周期场景是合适的。

用Sandbox开发

对于稍微复杂一些或必须与生产组织隔离的开发任务,您可以使用单独的开发环境,通常是沙箱。在此方案中,所有开发和测试都在开发环境中进行,然后将更改提升到生产组织。

如果要同时在生产和沙箱组织中开发项目,请考虑跟踪在生产组织中进行的设置更改并在沙箱中复制它们。这很重要,因为如果您的沙箱具有过时的自定义设置,则在从沙箱中提升时,您可能会无意中使用这些较旧的自定义项替换生产中的较新更改。

典型的开发生命周期:

  1. 创建开发环境。
  2. 使用Salesforce Web和本地工具进行开发。
  3. 在开发环境中进行测试。
  4. 在开发环境中复制生产更改。
  5. 将您开发的内容部署到生产组织。 典型的开发项目:
    • 新的自定义对象,选项卡和应用程序
    • 与其他系统的集成
    • 涉及Apex,Visualforce,工作流程或新验证规则的应用程序

沙箱组织

沙箱是您的生产组织的副本。 沙箱包含相同的元数据 – 作为生产组织的配置信息,例如自定义对象和字段,应用程序和工作流的类型。 该元数据以及完整沙箱中的数据将复制到与生产组织隔离的新组织中。 您在沙箱中执行的操作不会影响您的生产组织。

沙盒可用于Professional,Enterprise,Unlimited和Performance Edition。 使用Unlimited和Performance Edition,您可以创建多个不同类型的沙箱副本。 使用沙箱进行开发,测试,培训或其他目的,而不会影响Salesforce生产组织中的数据和应用程序。 每个沙箱实例都与其他所有沙箱实例隔离,就像它们来自生产一样。

关于在组织之间迁移更改

将配置更改从一个组织发送到另一个组织的最简单方法是使用更改集。 要将当前组织的自定义项发送到其他组织,请创建出站更改集。 发送更改集后,接收组织会将其视为入站更改集。

更改集只能包含您可以通过“设置”菜单进行的更改,并且它们不支持可自定义的每种类型的组件。您也无法使用更改集来重命名或删除组件。如果进行更改集不支持的更改,则可以通过重复在其他组织中执行的步骤手动迁移它们。有关更改集中可用组件的更多信息,请参阅Salesforce联机帮助。

某些组件依赖于其他组件。例如,自定义对象的自定义字段依赖于该自定义对象的存在。如果您尝试将这些自定义字段迁移到不包含它们所依赖的自定义对象的组织,则部署将失败。创建更改集时,可以轻松查看和添加依赖项,以确保迁移所有必需的组件。

在两个组织之间发送更改集需要部署连接。变更集只能在与生产组织相关联的组织之间发送。例如,生产组织和沙箱,或从同一组织创建的两个沙箱可以发送或接收更改集。

仅部署连接不允许在组织之间发送更改集。 必须授权每个组织发送和接收变更集。 这种增加的安全级别强制执行代码提升路径,并防止组织设置元数据被错误覆盖。

快速入门:使用沙箱和更改集

按照以下步骤创建开发人员沙箱,并使用更改集将您在其中创建的配置更改迁移到生产组织。

创建开发人员沙箱

使用开发人员沙箱确保您的更改与生产隔离,直到您准备好部署它们为止。

沙盒可用于Professional,Enterprise,Unlimited和Performance版本。

  1. 从“设置”中,在“快速查找”框中输入“Sandboxes”,然后选择“Sandboxes”。
  2. 单击“New Sandbox.”。
  3. 输入沙箱的名称和描述。
  4. 选择Developer作为沙箱类型。
  5. 单击“开始复制”。
    此过程可能需要一段时间,具体取决于您的组织规模。沙箱完成复制后,您会收到通知电子邮件。
  6. 单击通知电子邮件中的链接以访问您的沙箱。
    您可以通过将.sandbox_name附加到您的用户名来登录test.salesforce.com/login.jsp中的沙箱。例如,如果您的生产组织的用户名是user1@acme.com,那么名为“test”的沙箱的用户名是user1@acme.com.test。
    注意:Salesforce会自动更改沙箱用户名,但不会更改密码。

如果您想在将更改集用于开发项目之前尝试使用更改集,请立即在开发人员沙箱中使用自定义字段创建测试自定义对象。 您可以在接下来的步骤中练习部署这些自定义项,并在完成后删除它们。

授权部署连接

在您可以从沙箱或其他组织接收更改集之前,请在接收更改的组织中授予部署连接。

  1. 登录将接收入站变更集的组织。 通常,这是与您的沙箱关联的生产组织。
  2. 从“设置”中,在“快速查找”框中输入“Deployment ”,然后选择“Deployment Settings
  3. 单击要从中接收出站更改集的组织旁边的“Edit”。 通常这是你的沙箱。
  4. 选择“Allow Inbound Changes”并单击“Save”。

创建和上载出站变更集

通常,您在沙箱组织中创建出站更改集并将其部署到生产中。 但是,根据您的开发生命周期,您可以选择在相关组织之间以任一方向迁移更改。

  1. 从“设置”中,在“快速查找”框中输入“Outbound Change Sets”,然后选择“Outbound Change Sets”。
  2. 单击“New”。
  3. 输入更改集的名称,然后单击“Save”。
  4. 在“更改集组件”部分中,单击“Add”。
  5. 选择组件类型(例如,“自定义对象”或“自定义字段”),要添加的组件,然后单击“Add To Change Set.”。
    如果您正在尝试测试自定义对象和自定义字段,请尝试首先将其中一个添加到更改集。
  6. 单击“View/Add Dependencies”以查看您添加到更改集的组件是否依赖于其他自定义项。
    对于测试自定义对象和自定义字段,将列出相关组件和页面布局。
  7. 选择要添加的从属组件,然后单击“Add To Change Set”。
  8. 单击“Upload”并选择目标组织。
    出站更改集详细信息页面显示一条消息,并在上载完成时收到电子邮件通知。

验证入站变更集

通过验证更改集,您可以在不提交更改的情况下查看成功或失败消息。

  1. 从“设置”中,在“快速查找”框中输入“入站变更集”,然后选择“入站变更集”。
  2. 单击更改集的名称。
  3. 单击“验证”。
    我们建议在非高峰使用时间开始验证,并在验证过程中限制对组织的更改。验证过程会锁定正在部署的资源。在验证过程中对锁定资源或与这些资源相关的项目所做的更改可能会导致错误。
    注意:如果将字段类型从Master-Detail更改为Lookup,反之亦然,则在使用Validate选项测试部署时不支持更改。测试部署不支持此更改,以避免数据丢失或损坏。如果部署包中包含测试部署不支持的更改,则测试部署将失败并发出错误。
    如果部署包将字段类型从Master-Detail更改为Lookup,反之亦然,则仍可在部署到生产之前验证更改。对另一个测试沙箱执行完全部署。完整部署包括在部署过程中验证更改
  4. 验证完成后,单击“查看结果”。
    如果收到错误消息,请在部署之前解决它们。 最常见的错误原因是未包含在更改集和Apex测试失败中的相关组件。

部署入站变更集

部署更改集会将其包含的更改提交给目标组织。

  1. 从“设置”中,在“快速查找”框中输入“入站变更集”,然后选择“入站变更集”。
  2. 在“更改集等待部署”列表中,单击要部署的更改集的名称。
  3. 单击“部署”。
    变更集部署在单个事务中。 如果部署由于任何原因无法完成,则回滚整个事务。 部署成功完成后,所有更改都将提交到您的组织,并且无法回滚部署。

Scrum和Kanban

完成本单元后,您将能够:

  • 解释什么时候使用Scrum,什么时候使用看板来管理工作。
  • 定义中断驱动的工作。
  • 解释为什么有些团队使用Scrumban。

在Salesforce,70%的团队使用Scrum,20%使用看板。其余的团队使用两者的混合物,因为它们是兼容的工具。

那么您的团队如何决定哪个工作流程最适合成功? Scrum或看板,还是两者?这实际上取决于你的团队的工作类型,以及工作是如何变化或中断的。我们可以帮你解决这个问题。

首先,在考虑使用哪个工作流程时,要问自己的主要问题如下。

  • 您的团队是否专注于大型项目的可预测性和生产力?
  • 您的团队计划提前多久?
  • 新工作真的是紧急吗?
  • 你需要多久才能完成新的工作?
您的团队是否专注于大型项目的可预测性和生产力?
看看这两种不同类型的工作项目。

Scrum案例研究

想象一下,如果你的团队需要创建一个新的网站。团队可以将工作分解成较小的项目。随着较小的工作项目完成,团队可以检查每个冲刺的进度并进行调整,以确保整个项目成功交付。如果项目需要一个可预测的交付时间表,Scrum是首选的工作流程。

看板案例研究

你的团队是否必须处理服务中断?这是中断驱动工作的一个例子。你不能总是提前2周知道或计划停电。从事建筑,服务或平台支持工作的团队倾向于在刚刚弹出的项目上工作,并创建不断变化的优先事项。

在这种情况下,看板是更好的过程,因为其灵活的工作流程允许这种不可预测的中断。

团队计划提前多久?
你想确定团队可以完成多少计划并完成一个项目。团队使用Scrum时,其积压充满了大块容易提前计划的大型项目。

你的团队的优先考虑经常改变吗?每次工作两周是否很困难?你的工作至少有25%是否改变了中期冲刺?如果您的团队被要求很少通知新的工作项目,看板可以为您更好地工作。这就是我们所说的中断驱动的工作。

新工作真的是紧急情况吗?
但是什么构成了中断驱动的工作呢?

理想情况下,我们想限制团队的变化。在将新工作项目分类为紧急或优先事项之前,团队需要考虑一些事项。

  1. 这个项目是否会造成耗时和沮丧的中断?
  2. 这种干扰是否阻止了团队完成更有价值的工作?
  3. 中断是否会妨碍团队首先完成最重要的事情?

如果工作没有真正的中断驱动,看板不会帮助一个团队。这里有一些方法可以确定你的工作是否中断驱动(因此,如果Scrum是更好的选择)。

  • 问问自己:是否需要的工作停止,或者如果现在还没有完成,我们是否会失去业务?通常情况下,情况并非如此,这些工作项目由于计划不周而急需。
  • 这项工作的根本原因是什么,为什么在规划阶段没有确定呢?
    • 是因为我们没有提前计划吗?
    • 这是一个新的利益相关者或客户的要求吗?
    • 产品不能正常工作吗?

如果紧急工作仅仅是计划不周的结果,那不是中断驱动就足以证明搬到看板。

如何快速做出新的重点工作项目必须交付?
在任何有竞争力的,成功的公司中,高优先级的中断是一个事实。重要的是这些防火演习是如何管理的。

因此,当紧急请求进入时,请询问:“您或利益相关者等待紧急工作要完成多久?”这一点很重要,因为Scrum和看板过程在不同的时间表上进行。如果需要尽快开展工作,看板就不那么具有破坏性的工作流程。

请记住:Scrum通过专注于他们的2周的部署来限制容量。看板限制基于防止在作业限制内进行多任务的能力。

下面是一个表格,介绍了Scrum和Kanban工作流程之间的一些关键区别。想象一下,客户为我们正在构建的应用程序请求一个新功能。

Scrum 看板
谁优先? 产品负责人优先考虑产品积压 产品负责人优先考虑产品积压
它在哪里? 产品积压被重新排序以用于下一个冲刺。 产品待办事项不断地为下一个有能力的可用人员重新排序。
工作什么时候开始? 在冲刺计划期间,团队承诺在下一次冲刺中的工作。 只要有能力来处理。
为什么会有延迟? Scrum专注于团队来实现他们的冲刺承诺,并且阻碍中期冲刺。 看板注重于高效的工作流程,所以积压的最高处总是接下来要处理的事情。
交付需要多长时间? 它可以是2周或更长时间,取决于冲刺状态。 一旦完成。

如果需要经常更换路线,请使用看板,尽量减少对计划的干扰,并尽快开始紧急工作。

如果您正在管理一个大型计划项目,那么使用Scrum,您的团队可以承诺为期两周的工作,利益相关方可以等到冲刺结束后开始工作。

你可以使用两个:Scrumban
Salesforce的许多团队都从使用Scrum和看板部分来管理工作负担中获益。通常,团队喜欢Scrum常规计划和审核节奏的结构,这使得他们可以更轻松地管理进度。他们还使用看板的工作进度限制来应对紧急工作,同时尽量减少看板提供的中断。

在此过程中,我们强调了人们工作的共同主题和方式,用检查和适应的精神为客户创造最大的价值。

Kanban(1)

完成本单元后,您将能够:

  • 描述看板的四个关键特征。
  • 列出如何使用看板过程测量和预测进度。
  • 描述看板如何拥抱优先事项的变化。

Salesforce将部分Scrum应用到我们使用的另一个框架:看板。这是更多支持生产或客户问题使用的基础架构或以运营为中心的团队的一种方法。

一般来说,看板比Scrum更不具说明性,使其更容易实现。在Salesforce,即使一个团队采用了看板过程,他们仍然使用相同的Scrum角色和会议(阅读上面的单元),因为它们被证明是良好的实践。这叫做Scrumban!

但看板仍然与Scrum大不相同。这里有看板的四个关键特征。

  • 可视化工作流程: 工作被分成几部分,每一部分写在放在墙上(物理或虚拟)的卡上。在Salesforce,我们使用一个名为Agile Accelerator的虚拟墙。工作流被映射到列中,说明每个项目在工作流中的位置。
  • 限制工作进度(WIP): 团队在每个工作流程阶段一次限制多少个工作项目正在进行中。如果他们达到了极限,他们会互相帮助,把他们作为一个整体解决问题。
  • 渐进式和渐进式的变化: 与Scrum不同,Scrum是一个需要在工作过程中进行深远转变的过程,Kanban让团队在这个过程中能够接受更小更多的变化。
  • 看板包括指标: 看板中使用了几个测量系统:提前期,即完成一个项目的平均时间,有时称为周期时间。这有助于团队优化流程,使交货时间尽可能小且可预测。吞吐量:定义为在一段时间内完成的工作量。

可视化工作流程

看板的基本要素之一是使所有东西都可见,创造一致的工作项目透明度。这个过程是基于看板卡,这在日文意味着可见的标志。

image shows a screenshot of a Kanban card in Agile Accelerator, a tool that teams at Salesforce commonly use to record each work item.

通过看板,当一个队伍完成一个阶段,一张牌被移动到下一个阶段,表示完成。这是看起来像什么。

image shows a screenshot of a Kanban board in Agile Accelerator, a tool that teams at Salesforce commonly use to record each work item.

限制在制品(WIP)

Scrum通过限制每次Sprint(每2周)的工作量来进行工作,而Kanban则限制每个工作流程状态的工作量 – 对此没有设定的时间框架,但它是衡量的。我们使用在制品限制来防止瓶颈,提高整体效率,并防止未完成的工作,就像在Scrum中一样。

WIP的限制在于帮助团队根据其容量和带宽设定切合实际的目标。当然,所有这些都可以在任何时候改变,而且团队总是随时准备好转(这是敏捷的一部分!)。

每当一个团队开始新的工作时,会员就会聚在一起问:“我们想要什么样的WIP限制?”这就是乐趣的来源:实验!设置在制品限制,并查看它是如何工作(或不)为您的团队。您可以随时在下一次回顾会议上进行调整。

看板拥抱最后一分钟的变化

想象一下这个场景:利益相关者希望你的团队现在就交付一个高优先级的项目。如果您使用的是Scrum,那么团队总是会说:“不,谢谢,把它放在产品积压的优先级上。”这就是Scrum的用处:在冲刺中保护团队不要承担新的工作。

但是在看板的情况下,团队可以向同一个利益相关者回答:“好的,我们有两个在制品 – 我们可以从这个紧急项目开始。”

看板团队没有做出同样的承诺 – 他们也没有冲刺积压。换句话说,使用这个工作流程的团队更愿意接受最后一刻的请求。当他们完成一个工作项目时,他们转到下一个最高优先级的任务。

衡量成功

我们如何使用看板来预测和确定我们的进度?我们测量。看板指标依靠平均提前期来确定我们的产出。换句话说:在工作完成之前,需要多长时间才能完成所有工作状态?

简单的说一下:如果你的交货时间开始增加,看看你的过程出了什么问题。

改进协作

由于所有工作在看板系统中都是高度透明的,因此团队很容易知道什么时候发生延迟,而且他们的反应很快。随着延误的发生,团队将找出延迟的根本原因,寻找方法来改善他们的周期时间或减少未来的瓶颈。

这些都是看板原则团队用来有效地为客户提供价值。但是在Scrum或看板之间哪个最好?我们将讨论不同类型的工作,以及下一个单位中Salesforce将使用哪些框架团队。

Scrum(3)实施

完成本单元后,您将能够:

  • 定义两种基于Scrum的会议。
  • 列出进入计划的会议类型。
  • 解释我们如何检查和调整我们的流程和可交付成果。

现在您可能想知道Salesforce如何实施Scrum。那么,这一切都归结为会议!我们知道你在想什么:会议是浪费时间。可是等等。这不仅仅是召开更多会议的会议。 Scrum会议旨在提供行动项目。我们会告诉你我们的意思。

Salesforce有两种主要的Scrum会议类型。

  1. 规划会议: 在项目的所有不同阶段都会发生,看起来像一个分层的蛋糕。无论项目在哪个阶段,团队都会定期会面,以确保他们与最终结果保持一致。
  2. 检查和调整会议: 我们谈了很多关于团队学习新知识并将其应用于下一个冲刺的重要性。这是他们这样做的时候。这些会议旨在改进流程和产品。

让我们更详细地看看这些会议,以便您更好地了解Salesforce上的Scrum过程的机制 – 并自行采用它们。

规划会议

我们的年度计划是我们用来确保每个人,团队和云都采用自上而下的业务路线图的最终对齐工具。敏捷团队然后用它来继续他们的计划。

每4个月发布一次

我们每4个月发布一次新版本的核心平台,其他产品更新频率更低。我们根据需要部署基础架构版本。在每个主要发布周期的开始,我们都有一个高级计划会议来为每个云创建一个路线图。

这些会议的主要目的:

  • 协调业务和客户的优先事项。
  • 提供对新功能的高层次了解。
  • 协商时间表并设定交货期望。

每一个版本都包括我们的前瞻性陈述,其中说我们的计划和交付是基于我们在计划时所掌握的知识,而且在我们开始工作时,事情会发生变化。我们之所以这样做是出于各种原因,但它确保我们的长期计划有能力改变和适应新的学习。

积压细化计划每两周进行一次

规划过程中的下一步是准备即将到来的冲刺。团队提前计划了几次冲刺,他们在那里审查他们的产品积压,以确保最高优先级的项目已准备就绪。

这些会议的目的是什么?

  • 该团队提供了输入,并清楚了解管道正在进入的内容。
  • 工作分解成更小的块。
  • 起草满意的条件,有助于澄清预期的结果。
  • 确定尚未准备好的工作。

冲刺规划每两周进行一次

在冲刺开始之前,团队将聚集在一起,为未来2周内打算完成的目标制定路线图。在这次会议上,小组同意并承诺制定工作计划。

通常在这些会议上,团队从产品积压开始,查看列表顶部的项目,并决定现在可以提交哪些项目。

每日站立发生(几乎!)每一天 

尽管Scrum要求每天都要开会,但大多数团队都采取了不间断的周四规则,这听起来像是:星期四不开会。

它是什么样子的?

  • 这是一个非常简短的同步,团队成员确保他们全天都专注于正确的目标,并在需要的地方提供帮助。
  • 频率是为了防止团队成员旋转车轮,瓶颈进展。
  • 它提供了日常进度的可见性。

检查和修改会议

当我们从计划阶段转到实践阶段时,我们往往会议较少。我们碰到两个在这里开会的人。关键在于学习会议,旨在确保我们能够在正确的时间为合适的客户提供正确的产品和服务。

回顾展望:每一次冲刺的结尾

这是一个团队可以为自己的进步或失败负责的会议。

每次冲刺,团队都花费一点时间分析他们工作或者工作的状况。在这个评估期间,他们把重点放在两件事上:流程和团队。

在这个时候,团队会检查他们在这个冲刺中的工作方式,然后决定如何改变和适应下一个冲刺。最终目标是改善每个冲刺的过程和交付。

在Salesforce,我们希望一个团队在每个冲刺之后都有一些“可操作的实验” – 他们可以在下一个冲刺中尝试新的东西。这些新的行动项目被添加到他们的冲刺或看板上,一个人让团队对这些人负责。

例如,在回顾过程中,一个小组抱怨说,会议时间过长,浪费时间。 该小组选择在每次会议上为下一次冲刺创建一个清晰的议程,并制定明确的行动项目。 这确保会议仍然重点突出,并有可行的结果。

冲刺演示发生在每个冲刺

在两次检查和适应会议的第二天,团队向产品所有者和利益相关者展示完成的工作,以获得反馈和意见。 他们检查他们的交付成果,把他们学到的东西和适应他们的过程向前推进。

没有这些会议,团队就错失了改进的机会。

Scrum(2)元素

完成本单元后,您将能够:

  • 列出交付的Scrum元素。
  • 解释为什么每个冲刺都需要完成工作。
  • 描述团队产品待办事项列表的关键部分

现在您已经理解了Scrum价值观和角色的重要性,接下来我们将介绍如何将所有事情组织起来,并确保我们按时,持续地交付。

产品积压

这是我们可能需要的有序工作清单,并不是所有将要完成的工作。我们将其定义为真实的单一来源,根据我们的最佳知识来描述我们认为必须做的所有变更,更新和要求。

产品积压是什么,它包含了什么?

  • 随着团队学习有关产品的新信息,它不断完善。
  • 更高优先级的项目有更多的细节,以便他们准备好工作。
  • 它不仅包括与项目相关的工作,还包括支持或维护工作,非功能性需求和研究。
  • 产品拥有者拥有它,他们的工作是确定工作项目的优先顺序。

Sprint积压

仅仅因为工作项目放入产品积压队列中并不意味着它完成了。在每次冲刺之前,团队都会查看产品积压,并评估他们可以在两周内处理哪些高优先级的工作项目。他们把这些项目纳入冲刺积压。

潜在可发运的工作

最重要的是团队在每个冲刺阶段为客户提供有价值的东西。要做到这一点,我们关注的是结果,而不是产出 – 这是Scrum过程中的一个重要区别。

简单地说:我们的目标是生产质量的工作,而不是一个工作量。

在我们开始新事物之前,我们也推动完成工作。没有人想吃一个半熟的蛋糕!我们以这种方式工作是有原因的:每4个月,Salesforce发布其平台的更新。这并不是说我们每4个月才完成一次交付。这不会像我们现在所做的那样,每两周就不断地学习和整合这些学习内容。

我们在整个发布周期中一直以这种方式提供最佳解决方案。

为什么我们强调整理?

在Scrum世界里,正在进行的项目是一种浪费。那是因为WIP项目意味着你没有学习和适应创造更好的交付和解决方案。未完成的工作(签入,测试和部署)会延迟整个工作流程。我们倡导团队合作的文化,互相帮助,把项目带到终点。我们称之为蜂群或狗群堆 – 人们互相帮助完成了最后的20%的工作。

Scrum工作流程:一摞书代表产品积压;一个大蛋糕代表冲刺积压;一个闹钟代表每天的scrum会议;而蛋糕代表可运送的产品作为最终交货

Image shows four icons to describe Scrum workflow: A stack of books represents the product backlog; a big cake represents the sprint backlog; an alarm clock represents the daily scrum meeting; and a cupcake represents the shippable product as final delivery

Scrum(1)介绍

完成本单元后,您将能够:

  • 描述Scrum的关键特征。
  • 列出Scrum值。
  • 在Salesforce解释Scrum角色。

在Salesforce,我们使用两种不同的工作流程:Scrum和看板。我们在前面的模块中介绍了这些内容,但现在我们将深入到两个项目管理流程,并向您展示他们是如何使Salesforce成功的。

成功的Scrum,Salesforce的方式

正如我们所讨论的,Scrum过程是我们在Salesforce使用的更流行的敏捷框架之一。我们在2006年实施了这个项目,并且继续成为我们70%的团队的首选框架。

在我们向您介绍在Salesforce中如何使用Scrum之前,让我们快速回顾一下它是什么。 Scrum是角色,会议和可交付成果明确定义的工作流程,该流程允许团队不断测试和改进其产品和流程。

Scrum的一些关键特性。

  • 它提供了一个框架,可以更快地为客户提供高质量的价值。
  • 每个人都组织成小型的跨职能团队。
  • 团队在短暂的迭代中工作(我们称之为冲刺)。

Scrum值

Scrum有五个核心价值。我们来看看这些。

1.重点

在最后一个模块中,我们将Salesforce所做的工作定义为复杂的,有许多未知数。为了及时交付宝贵的成果,我们必须始终关注整个过程。这对我们来说是什么样子?

  • 不同的人在不同的工作项目上独立工作,我们协作处理所有事情。我们的团队一起完成一个任务,然后继续下一个任务。
  • 我们制定了明确的重点,让团队把重点放在最重要的项目上。
  • 每个团队都同意一个冲刺计划。这个共同的问责制使他们专注于结果,而不是个人的进步。
  • 我们对产品的清晰构想提供了一个通知团队日常工作的议程。

2.勇气

冒险是创新的关键因素。冒险需要勇气。当提倡这种勇气时,我们要求团队:

  • 对进展保持透明,并在需要帮助时说出来。
  • 当假设错误,或者他们遇到错误和新的学习时,向他们报告。

当我们团队攻关时,我们有更大的勇气承担新的挑战和风险。

3.开放

透明度是促进合作和成功的关键。以下是我们保持开放的几种方法。

  • 当我们作为一个团队一起工作时,我们总是口头表达我们如何做,标记障碍和声音问题,所以他们不会徘徊。
  • 团队之间可以互相帮助,互相提供帮助。
  • 团队成员对时间安排,计划和障碍都是诚实而明确的;他们如何工作;以及他们在做什么。这可以防止任何不必要的意外和最后一分钟的防火练习。
  • 当队伍开放的时候,他们承认错了什么,纠正错误,改善前进的意图。

4.承诺

当团队承诺流程时,他们更能控制结果。承诺没有被定义为按特定里程碑提供设定范围的承诺。这是我们如何定义承诺。

  • 信任:每个团队成员都投入到团队的整体成功,而不是他们个人的成就。
  • 选择像Scrum这样的流程是一个承诺。当这是一个团队的决定,每个人都明白他们为什么要使用它时,团队更可能坚持这个过程。
  • 如果持续改进是目标,那么团队总是愿意根据新的信息或经验数据尝试新事物。
  • 团队共同决定工作项目,工作协议,完成的定义和角色。每个人都尊重这些决定。

5.尊重

当我们一起工作,分享成功和失败时,我们学会彼此尊重,每个人都有贡献。

  • 这包括尊重我们不同的背景和经验。
  • 如果我们假设每个人都有最好的意图,我们就可以进行更有成效的对话,更快地解决冲突。
  • 当我们拥抱所有的意见和观点,并听到所有的声音,我们建立更强大的产品和团队。

Salesforce的Scrum过程看起来像什么?

在最后一个模块中,我们学习了Scrum过程如何让我们实时学习足够的时间,以纠正我们冒险的潜在损害。这让我们不断创新,同时改进我们的产品和流程。

简而言之,Scrum使我们能够:

  1. 交付或演示每个sprint的东西,以便团队可以收集有关可交付成果的反馈。 (这使我们不断创新!)
  2. 不断提高自己,团队和成果,每一天都在冲刺。
  3. 组装一个胜任的团队,让团队做出所有的决定。
  4. 指定一个人去除障碍,以便有人负责。
  5. 指定一个人为团队设定工作议程和优先项目,以便团队专注于重要的事情。

Scrum角色:谁做什么?

Salesforce上的Scrum角色不是职位名称,而是团队成员承担的职责清单。这里是对这些角色的简要总结。

The ScrumMaster

ScrumMaster就像团队镜像一样。这个人让每个人都对他们的承诺负责,并在他们不执行的时候把他们叫出来。他们管理团队的交付过程,包括如何检查和调整他们的过程和项目。他们一边教导球队出色地完成了这一切。

此外,他们还努力在团队中建立社区,帮助他们彼此成长和互相信任,从而更好地合作。考虑这个人Scrum Sherpa!

Salesforce ScrumMasters:

  • 删除阻止程序
  • 不要微观管理
  • 引导团队避免不良习惯和低效率流程
  • 使团队变得协作和高效

从历史上看,ScrumMasters是工程经理,但这已经改变了:在很多情况下,ScrumMasters也是个人贡献者。 ScrumMaster并不是Salesforce的全职演员,更像是一个额外的责任,让每个人都有机会发展新的领导技巧。

产品负责人

产品负责人对我们的流程的内容和原因负责。这个人与客户密切合作,以确保他们的Salesforce投资获得良好的回报。他们通过优先处理产品积压和沟通最高价值的工作来实现这一点。他们还负责向内部团队传达愿景,为他们提供优先的工作清单。我们把这个列表称为产品积压。

在Salesforce,产品负责人:

  • 促进利益相关者,团队成员和ScrumMaster之间的沟通。
  • 定义,优先考虑和批准团队的工作。
  • 与客户合作定义所需的功能。

就像ScrumMasters一样,几乎Salesforce的任何人都可以加强成为产品所有者 – 我们有经理,技术主管和产品经理担任这个角色。

团队

我们的目标是保持团队小巧灵活(因此敏捷!) – 三到九人之间。我们确保我们的团队拥有不同的专业知识,在每个冲刺结束时提供项目。多元化的专业意味着团队拥有所有合适的参与者;他们把项目带到每个冲刺的终点线上。换句话说,他们不需要寻求其他团队的帮助。

在Salesforce,团队是:

  • 自组织和授权
  • 根据他们学到的经验,不断调整和更新他们的流程和产品
  • 自主性
  • 分别负责
  • 合作每个冲刺的承诺

共享服务主题专家(SMEs)

在像Salesforce这样的大公司,我们依靠主题专家(如技术撰稿人或设计师)来帮助我们交付我们的产品和服务。他们为许多交付团队工作,提供最新的信息和数据通知我们的项目。

技术项目经理 (TPMs)

我们的TPM在每个云(服务,销售,市场,平台)的领导层面工作,经常处理高层云依赖性跟踪和其他后勤问题。他们的注意力跨越所有的云层,这意味着他们变得相当忙碌!

职能经理

在我们的矩阵组织中,我们的职能经理(例如工程经理)可以在Scrum团队中工作。而当他们这样做时,他们经常充当ScrumMaster或产品所有者。无论他们担当什么角色,他们都要对所有员工成功人员和组织事务负责。

Salesforce 敏捷(3)精益

完成本单元后,您将能够:

  • 解释精益原则。
  • 描述精益原则如何影响我们的敏捷过程。

在我们新的敏捷旅程中,我们需要创造强大的文化价值观来补充我们新的工作方式。所以,我们从精益软件开发实践中获得了一个页面,并拥有相同的价值观。

这七个值的Salesforce版本是:

  • 尊重人
  • 消除浪费
  • 提供快速
  • 准时决策
  • 优化整体
  • 创造知识
  • 建立质量
尊重人

我们不相信人们需要被告知如何去做他们的工作。我们认为管理者是“仆人领袖”,这意味着他们倾听他们的团队。我们喜欢雇用好人,然后让他们做自己的工作。如果我们把团队成员当作完成工作的手段,那么我们就不会有创造力和创新空间。

团队的成功发生在每个人都相互尊重,一起工作的时候。当个人努力超越自我时,团队往往不太成功。

那么这如何融入Salesforce呢?我们相信我们的Ohana文化对于我们的客户和我们的组织的成功至关重要。在夏威夷的文化中,奥哈纳表达了这样一个观点,即血缘关系或者被采纳关系的家庭是相互联系的,家庭成员是相互负责的。

消除浪费

难道你不想讨厌那些从未需要的东西?我们也讨厌这个。这就是为什么作为一家公司,我们努力优化资源,只为那些为我们的客户创造最大价值的项目工作。

这里有一些浪费时间的例子。

  • 多任务处理
  • 经营不善的会议
  • 工作分配的反应
  • 未完成的工作

为了确保我们不浪费任何时间,我们创建了ready的标准定义。这听起来就像是一个标准的事情列表,我们认为这是从一个工作项目开始所必需的。它旨在促进正确的对话,然后再浪费任何时间去处理某些事情,而只是为了发现它尚未准备好黄金时段,或者根本不需要。

你明白了。所以我们不要在这个特定的话题上浪费更多的时间。

提供快速

由于我们是一家始终走在创新前沿的领先企业,我们必须快速转型,跟上变化,保持竞争力。我们短暂的冲刺意味着我们不断学习什么是有效的,哪些是行不通的,并相应地做出改变。 (我们目前在技术和产品团队工作2周。

准时决策

我们避免了前期设计,而是倾向于拖延关键决策,直到最后一个负责任的时刻。这种做法有助于我们更好地了解客户需求当然,最后一个负责任的时刻是由团队自己决定的,这取决于工作的范围。

优化整体

Salesforce生态系统不仅仅是其部分的总和。为了保持对客户的信任和高质量,我们必须确保团队不在真空中工作。

我们授权我们的团队思考大,行动小,协作,失败,快速学习。

创造知识

我们希望尽可能地扩大学习和持续改进。我们短暂的冲刺使我们能够构建可持续测试的解决方案。

换句话说,我们的短周期使我们脚踏实地,始终学习,适应和创新。我们用这种工作方式 – 快速和激烈 – 与客户建立信任;我们始终将客户反馈纳入我们所做的一切。我们通过客户的成功来定义我们产品的价值。

我们在Salesforce分享知识的方式之一就是通过Chatter。团队可以去Chatter分享文件,文件和见解。我们甚至还加入了代码审查,配对编程和棕色包分享会等方面的知识,以保持团队的知名度。

我们也希望通过获得新的技能来确保我们团队中的每个人都在成长。如果团队中的每个人都只有一个专业知识,那就会使团队的生产力下降。我们希望创造一个人人分享知识和责任的均衡的学习环境。

建立质量

信任是我们的核心价值之一,这就是为什么我们一直在努力创造高品质的服务和产品,以建立客户的成功。

为了做到这一点,我们实施了一些技术实践,使我们所有的产品具有灵活性,可维护性,高效性和响应性。通过在工作中重构(或重构代码),我们帮助保持简单,清晰和简单。

与客户建立信任关系的另一个重要部分:确保我们拥有一套健全有效的测试流程。在我们转向敏捷之前,由于其他任务的出现,我们往往没有及时完成产品测试。这导致了延误。但是现在每个人都拥有质量的所有权 – 它不属于一个人。

我们所做的一件事情就是创建“混合工程师”,在技术和产品部门内废除质量工程师的职位。 这个新的工程师涵盖了完整的编码和测试周期 – 不再有单独的人员在流程的不同部分工作。

敏捷软件包

人们经常会问:“Salesforce的流程是什么?”那么,没有一个单一的流程。

我们的团队在工作类型上是多种多样的,所以我们不要求一种流程或实践。 最终,每个团队都必须根据精益原则和持续改进的概念来定义自己的流程。

我们倾向于让Ohana的文化和精益告知团队如何工作,授权他们做正确的事情,经理们支持他们实现一系列共同的目标。

Salesforce 敏捷(2)学习

完成本单元后,您将能够:

  • 解释敏捷宣言。
  • 定义敏捷原则和实践之间的区别。
  • 描述如何真正敏捷。

现在您已经明白了为什么Salesforce变得敏捷了,接下来我们将介绍如何将敏捷应用于实践。

这听起来很尴尬,但是敏捷和敏捷之间还是有区别的。敏捷意味着你知道你为什么这样做,而不是盲目地遵循一个过程。有一些最佳实践可以使你的团队敏捷。最终,如果您对以下三个问题可以回答“是”,那么您正在变得敏捷。

  • 我们的活动是专注于人吗?
  • 我们是否不断学习和改进以改进我们的流程和产品?
  • 我们是否经常向客户传递价值和喜悦?
敏捷的价值观

我们喜欢把我们的敏捷过程想像成一种美味的冰激凌圣代,层层叠叠,令人高兴。那么我们先来谈谈我们的敏捷思维的基础:冰淇淋圣代碗!

Image shows a representation of an ice cream sundae as a metaphor of how the Scrum values, principles, frameworks and practices are layered and how they relate to each other.

早在2001年,在该公司采纳敏捷之前,来自整个行业的17名软件工程师起草了敏捷宣言 – 一系列为Scrum奠定基础的价值观。这个宣言是浪费时间,金钱和精力的大型,昂贵的,经常中止或失败的软件项目的结果。他们寻找替代以往失败的文件重复,设计全部前沿的过程。

今天,这些价值观为我们提供了一个敏捷的思维方式。这个宣言是以人为基础和与创造一个成功和愉快的组织目标的合作。

这是“宣言”的一个片段:

“我们正在发现更好的方法来开发软件,并帮助其他人这样做。通过这项工作,我们已经开始重视:

  • 个人和流程和工具上的交互
  • 通过全面的文档工作软件
  • 客户协作合同谈判
  • 根据计划做出回应

也就是说,虽然右边的项目是有价值的,但我们更看重左边的项目。“

现在让我们深入这四个值。

过程和工具的个人和互动

敏捷的一部分意味着让你的团队指定他们自己的工作流程,而不是让传统的流程​​决定这个工作流程。在Salesforce,我们使用一个名为Agile Accelerator的平台,帮助团队管理工作流程和产品开发。

在我们这个规模的公司,你可以把团队分散在不同的建筑,州和国家。敏捷平台使我们能够保持无缝的通信规模 – 无论我们的时区如何。

在综合文档上工作的软件

那么我们如何确认我们正在取得真正的进展呢?我们依靠一个有形的结果:一个经过验证的软件,服务或可交付成果。换句话说,规范性文件本身并不能证明我们做的是正确的事情,也没有提供客户的价值。

客户协作合同谈判

作为一个以客户为中心的公司,部分意味着我们不只是假设我们知道什么对客户是最好的,我们实际上正在实施他们所说的最适合他们的事情。我们短暂的冲刺和持续改进流程帮助我们快速响应客户所需的变化。我们使用IdeaExchange(客户为我们提出想法的论坛)等机制来理解我们的客户发现的吸引力,实用性和令人兴奋的特点。

回应计划后的变更

我们在Salesforce所做工作的性质是创造性的,过程也是如此。我们不可能对每一个结果都确切地说,我们也不能提前预测旅程的每一个步骤 – 当你在冒险的时候,总会有一些弯路。不仅如此,我们需要快速响应客户反馈,这意味着发生了变化,而且发生得很快。

这就是为什么我们开始我们的所有介绍与安全港通知,告诫客户购买我们的服务,根据目前可用的功能做出购买决定,而不是我们所做的前瞻性陈述。

这并不是说我们靠裤子的位置来做事。我们的团队定期进行规划,从我们全公司的规划流程到发布规划,增量规划和每日计划会议。

敏捷原则一览
在下一层冰淇淋圣代上有12个敏捷的原则,为我们的迭代过程添加了味道。考虑一下你碗里的冰淇淋勺(当然是各种口味的)。

它们包括如下内容:

  • 保持简单
  • 拥抱变革以保持竞争力
  • 面对面沟通是最好的
  • 业务人员和开发人员在整个项目中一起工作

你可以阅读更多关于这里的原则。

构架

现在我们已经把所有的冰淇淋放在碗里了,现在是时候用软糖酱发疯了!继续吧,把你的冰激凌与各种确定的框架混合在一起,为角色和会议提供方法和指导,帮助我们将自己的思维和愿望付诸实践。 Salesforce使用的一些框架:Scrum,Kanban,Scrumban(两者兼有)和eXtreme Programming(这是一组技术最佳实践)。

实践

就像我们的圣代上洒满五彩斑斓,有许多敏捷,精益和技术实践,使人们以灵活和精益的方式制定框架。在Salesforce,这些实践包括计划的节奏,团队如何检查和调整,以及人们的角色和责任。每个员工都会制定年度计划文件和积压工作来管理和优先考虑工作。这是我们的混合工程实践和自动化测试环境的补充。

正是这些敏捷的价值观,原则,框架和实践帮助我们构建了Salesforce Ohana。

Salesforce 敏捷(1)理解

完成本单元后,您将能够:

  • 解释为什么Salesforce使用敏捷
  • 列举敏捷的一些好处
  • 定义Scrum
  • 解释“完成的定义”
  • 了解为什么敏捷过程为Salesforce更好地工作

想象一下,前往Dreamforce,只能了解到没有主题演讲,没有新的产品或服务公告,也没有可用于明年的创新或生产就绪功能。

这在2006年几乎发生在Salesforce,但是我们通过实施新的工作流程来避免这种情况,这个工作流程彻底改变了我们开发和交付产品的方式。

从1999年Salesforce成立以来,我们的技术和产品(T&P)团队像发条一样交付。 T&P团队之间的沟通和协作始终顺畅而简单。但是到了2006年,我们经历了惊人的增长 – 我们拥有更多的客户,更多的收入,更多的产品和更大的公司。就像任何增长的冲刺一样,这不是无痛苦的。

所有过去容易发生的事情都不再那么容易了。结果,我们开始经历创新的放缓。

扩大沟通,协作和管理,同时满足我们的发布日期已成为挑战。很明显,我们需要一种新的方法,一种以顺利的产品交付流程为中心的方法 – 一种确保没有发布延迟的方法。

Image is a graph showing how the time between major releases increased while the features delivered per team decreased over the time period of 2000 to 2006

所以我们做了我们最擅长的事情:我们冒了风险,重新提供了解决方案。我们采取了一套敏捷的原则和做法。

为什么敏捷?

我们在Salesforce所做的大部分工作都是基于创新和迭代的。也就是说,最后的结果并不总是事先知道,到达那里的路径是一个正在进行的工作。这总是一个新的冒险!

这并不是说Salesforce的所有团队都使用敏捷流程。有些团队使用瀑布框架,这是一个不太灵活的项目管理过程。您选择哪个流程取决于您知道什么 – 或不知道何时启动工作项目。

这里快速浏览一下瀑布的做法。

  • 一切都在前面计划。
  • 要求在实施之前被详细收集。
  • 继续前,每一步都必须完成。
  • 结果是在开始时确定的。

计划与适应

如果你想要决定哪个过程最适合你,请考虑这一点:如果你正在画一幅画,并且你已经决定了你的颜色,你的设置,你将花费多少时间来绘画,以及你的最终形象会是什么看起来像,那么你已经没有多少空间去改变。这并不是说这幅画不会是一幅毕加索的作品,但是你的过程并不是为了将新的想法或反馈结合在一起,以改变最终的形象(当然是更好)。那时你可能会使用瀑布方法。

但是当你迭代绘画的时候,你可以期望根据早期的反馈,新的想法,甚至是新的学习(那些颜色冲突!)而不是以有计划的,增量的顺序进行绘画。这是一个更敏捷的方法。

以下是这两个绘画过程的视觉效果:

Image shows an illustration of a painting of a person in progress. It shows what the painting would look like in the various stages when using the Waterfall process and the Agile process.

图片基于杰夫·巴顿的工作,经许可使用,jpattonassociates.com

工作复杂性

所以现在你知道不同的过程对于不同类型的工作更好。那么如何确定哪个流程最适合您和您的团队呢?考虑这些事情。

何时选择瀑布

简单的工作:

  • 工作简单而可预见。
  • 任何人都可以决定如何完成这项工作。

复杂的工作:

  • 这项工作是可以预测的,但需要专业知识。
  • 工作可以自动化。

何时选择敏捷

复杂的工作:

  • 这项工作是基于一致的反馈,风险和创新。
    • 你想尝试一下,看看它是如何工作的,根据新的知识改变课程。
    • 你正在创造新的产品,软件和服务,而你正在做的事情从未做过。

试图选择一个工作流程时,问问自己这些问题。

  • 我们对手头项目了解多少?
    • 项目的目标和要求有多清晰?
    • 解决方案有多清晰明确?
    • 什么是团队和利益相关者使用这些方法的经验?
    • 这项工作有多复杂?
以敏捷的方式扩大Salesforce

此时,Salesforce领导层开始尝试在各个团队实施敏捷实践。有一些推迟,但Salesforce高管支持这个概念,并在2006年,Salesforce技术与产品团队重组为一个敏捷开发团队。

这是什么样子?那么,我们做了以下。

  1. 采用了新的交付思维模式
  2. 实施标准化流程
  3. 接受精益原则(我们稍后会告诉你更多!)
  4. 标准化“完成的工作”的含义

我们新的敏捷思维

这个敏捷过程究竟是什么?简而言之,敏捷是各种技术实践,流程,框架,原则和价值的总称,它们要求工作流程的灵活性和对产品的迭代改变。

这是一个时间盒式的迭代方法,工作团队从项目开始阶段逐步建立可交付成果,而不是试图最终交付最终产品。敏捷帮助团队协调一致,提高质量,并迫使每个人衡量和管理进度,以更快地为客户创造更多价值。

对于Salesforce来说,它非常合适,因为我们正在寻求解决我们的沟通和扩大成长的痛苦。

我们新的敏捷过程:从五万英尺的视野

我们选择在Salesforce选择实施的敏捷流程之一是Scrum,我们以特定的原则来支持这些流程,这些原则定义了我们今天的工作方式。

什么是Scrum?

Scrum是一个过程,具有明确的角色,会议和交付物,提供了为客户提供高质量价值的框架。

为什么我们采用Scrum?

Scrum为我们提供了一个灵活的框架,以找出哪些产品可行,哪些不适用于我们的产品,并相应地进行更改。在Scrum中,每个人都拥有所有权,并且在面对他们面前的工作时有着共同的期望。

什么Scrum过程看起来像在Salesforce?

那么当我们通过它时,有150人被组织成小型的跨职能团队,短时间迭代(我们称之为冲刺)。目标是稳定交付和组织我们的过程。目前,大多数Salesforce云团队使用敏捷和Scrum的一些变化。

什么是精益原则?

我们也接受精益原则。这七条陈述描述了我们的工作流程和交付流程。他们反映了我们的Ohana文化,突出人们如何共同努力,促进我们的成功结构。我们稍后会更详细地介绍它们。

“成就”工作的新定义

现在我们有了一种新的工作方式,团队可以在学习关于工作流程和产品的新信息时成功地重复他们的流程。但是,我们怎么知道我们真的做了工作?

简单。我们为技术和产品团队创建了完成(DoD)的标准定义,以便每个人都可以在什么时候明确地清楚完成。

这里有一个需要考虑的场景:想象一下你需要创建一个新的产品功能。您将这个新任务分配给您的团队,并要求他们在本月实施。他们这样做,继续前进。快进几个月,完成的工作项目重新出现新的问题。也许有客户抱怨,因为集成没有得到充分测试。也许安全问题没有得到解决,或者性能没有达到标准。结论:工作项目实际上没有完成,至少不够部署。

我们对“完成”的定义是一套指导方针,指导团队在完成任务之前所要做的一切。为此创建一个标准对于维护Salesforce的核心价值至关重要:信任。

简而言之
我们不断地问自己:“我们做对了吗?”这就是我们如何确保将我们的客户放在我们所做的一切的中心。

Scrum流程的严密性以及敏捷和精益的思维方式是提高我们的交付和确保顺畅的发布的核心。这是Salesforce每年为我们的客户提供三个主要版本的关键。