一、组建高效的团队
采用 unlocked packages 和模块化开发不仅仅是一次技术变更，更是一次组织转型。本模块为你铺路：组建兼具业务与技术利益相关者的合适团队、盘点组织的定制以识别包化机会、为独立部署制定发布管理策略，并通过展示价值与留出试错空间来获得利益相关者的支持。
为模块化成功组建团队
在传统 Salesforce 开发生命周期中，应用构建者用沙箱创建和测试变更，真相来源是一个不断变化的目标。Salesforce DX 带来的工具与特性提供了转变应用开发生命周期管理方式的机会，其中最激动人心的变化之一就是 unlocked packages。
Unlocked Packages 提供了一种可重复、可脚本化、可跟踪的方式，用于在组织中引入和管理变更。使用 unlocked packages 后，包成为组织元数据的容器，也成了在环境之间迁移元数据的方式。采用包化会影响你管理和思考 Salesforce 组织结构本身的方式。
要采用 unlocked packages，团队还必须采用模块化应用开发及其带来的好处，包括：更好的功能所有权、更高效的变更管理、更高效的开发流程（更快的测试运行、更易维护的代码等）、以及更低的交付新功能成本。
但采用模块化开发需要付出努力——它不仅仅是学习使用 Salesforce CLI 或采用 Git/Subversion 之类的版本控制系统（尽管这些都是必要步骤），它还会影响你组织和管理的各个应用开发阶段，以及参与应用开发的团队。最大的影响之一是需要拆解你的组织（untangle your org）：在组织元数据中寻找模式，把元数据组织成有意义的单元，这些单元随后成为模块化开发与 unlocked packages 的基础。而这一切的第一步，是让你的组织和团队做好准备。
识别利益相关者：你的 Salesforce 组织影响整个公司。应用变更会波及整个组织，所以开始思考如何变更应用管理方式时，务必纳入全公司依赖这些应用的人的声音与视角。有效团队的建设始于识别正确的利益相关者——既要从技术角度，也要从业务角度了解组织的人。需要寻找具备这些特质的人：能准确回答业务问题、了解公司及内部政策、知道自己的团队如何使用应用、遇到答不上来的问题时知道去哪里找信息。
利益相关者分两类：
- 业务利益相关者（Business Stakeholders）——将使用应用的人：终端用户（反馈什么好用、什么不好用）、部门负责人（按业务需求排定功能优先级）、高管发起人（提供预算与组织支持）。
- 技术利益相关者（Technical Stakeholders）——构建和维护应用的人：架构师（设计包边界与依赖）、开发者/管理员（在包内构建、拥有自己的领域）、发布经理（协调版本化与部署）、运维（管理环境与监控）。
识别出利益相关者后，把他们组织成有效的工作组。一种策略是围绕组织中的不同业务单元组建团队，另一种是围绕你在组织中构建的不同应用组建。无论选哪种策略，都要确保把利益相关者分组与组织中的真实功能对齐，并记录任何缺口或重叠。
看两个零售公司的例子：公司 A 是一家较小的在线零售公司，使用 Sales Cloud、Commerce Cloud 和 Marketing Cloud Engagement 管理直营业务，员工身兼多职，业务更多按流程而非正式部门组织，于是决定围绕为支持流程而构建的应用组建团队。公司 B 是一家较大的在线零售公司，使用 Sales Cloud、Service Cloud、Commerce Cloud、Communities 和 Marketing Cloud Engagement 管理分销与直营业务，公司按部门组织、各部门与各业务线有不同关系，于是决定按部门组建团队。两家公司都需要确保跨团队沟通，但这两种不同方法都给了各自一个可管理的方式来启动拆解过程。
这是康威定律（Conway’s Law）的体现：你的系统架构会映射你的沟通结构——要有意识地让两者对齐。组织团队围绕包，让每个团队端到端地拥有一个或多个包（例如团队 A 拥有 Recruiting 包，独立构建、测试、部署所有与招聘相关的内容；团队 B 拥有 Sales 包，独立开发、独立发布），团队之间通过包依赖而非协调会议来沟通。
二、评估、制定策略并获得支持
第 2–4 单元处理就绪工作的实操步骤：先盘点你的组织（有哪些元数据、哪些紧密耦合、自然的包边界在哪里）；再为新的多包世界制定发布策略；最后通过识别好机会、尽早展示价值、并留出失败空间来获得利益相关者支持。
组织评估、发布策略与采纳
盘点你的组织（Take Stock of Your Org）
诗人兼哲学家 George Santayana 曾说：「不能记住过去的人注定重蹈覆辙。」构建应用的团队也是如此——花时间识别组织里已经构建了什么、为什么构建、构建时用了什么标准，能为未来的成功奠定基础。盘点当前状态能让你在开始变更前就清楚地识别问题，例如识别技术债（那些早期合理、如今却阻碍创新的实现决策），也能找到更好地与合适利益相关者互动、在流程走得太远前调整团队的机会。
检查代码：理解组织中各代码块如何相互关联，是以更精确、更有意义的单元管理组织的必要一步。针对不同类型代码，要寻找的模式与要问的问题如下：
- Triggers（触发器）：是否每个对象只有一个触发器？业务/应用逻辑是否直接写在触发器里？触发器是否把逻辑「移交」给其他类（即 trigger handler）？
- Apex Classes：是否用公共前缀或命名空间来分组代码？类名是否基于功能、是否相似？代码的目的与作者是否记录在注释中？类使用什么 API 版本？
- Apex Tests：测试与代码如何关联？每个类是否都有自己的测试？测试是否按功能组组织？代码库中是否有未覆盖的部分？测试是否依赖公共数据因素或静态资源？是否有测试用了
seeAllData=True注解、或运行在早于 24 的 API 版本上？ - Lightning Components and Events：组件是否用公共前缀或命名空间创建分组？名称是否清晰、与功能相关？Lightning 事件被限定为应用事件还是组件事件？组件与事件的目的和作者是否记录在注释或 Aura 文档文件中？组件是否使用 Apex 控制器？组件与事件使用什么 API 版本？
- Visualforce：页面与组件是否用公共前缀或命名空间分组？名称是否清晰、与功能相关？页面是否使用 Apex 控制器？页面使用什么 API 版本？页面是否与任何邮件模板一起使用？
如果这些技巧仍不足以理解整个代码库，或代码库组织得不够一致，可以借助新的 Dependency API 运行新类型的查询，识别代码与元数据如何组织——例如查看某页面上的 Lightning 组件、或某 Visualforce 页面的 Apex 控制器，并回溯所有与该控制器/组件相连的其他元数据；也可以用这些查询识别已不再使用的元数据，判断能否安全删除。
检查流程与声明式定制：对于「用点击而非代码」构建的内容，可以从 Salesforce Optimizer 入手——这个工具能推荐改进 Salesforce 实现中某些功能的方法。看完 Optimizer 报告后，再深入检查组织中的流程与声明式定制：
- Flow/Visual Flow：Flow 是否用前缀或相似名称分组？名称是否与功能清晰相关？描述是否清晰、最新？Flow 与哪些对象交互？非活动 Flow/版本与活动 Flow 是什么关系？Flow 是否把公共功能放入子流程、可调用操作或快速操作？有界面的 Flow 是否基于 Lightning 组件？界面是否依赖特定对象与字段？是否有过时的自动化需要转换为 Flow？
- Objects and Fields：是否创建了重复标准对象行为的自定义对象？多个业务单元是否使用相同的对象或字段？业务逻辑与验证是否按记录类型区分？对象与字段是否有清晰、最新的描述？
你要对流程与声明式定制的组织程度形成清晰认知。如果发现组织不如你所愿地有序，也没关系——现在正是识别团队可以提高质量、建立标准、清理组织部分之处的好时机。
制定发布管理策略（Develop a Release Management Strategy）
除了看已构建的东西，还要看构建和交付应用的人如何协作。在采用支持更小、更聚焦变更的模型时，别制造让团队做冗余或冲突工作的机会（也就是别新建一个「更光鲜的孤岛」）。
- 对齐开发团队：看团队今天如何一起构建应用——哪些用敏捷方法？哪些用其他框架？是否各自为政？获得跨团队可见性是更好管理应用的关键。在规划与开发早期识别重叠（或冲突）区域，避免后续更昂贵的冲突。同时建立强有力的团队沟通规范，并确保公司对组织有整体治理计划。
- 管理新环境与发布：团队如何沟通发布到生产的变更？谁负责培训终端用户、与各组分享更新？谁负责环境间的部署与迁移？开发不同区域的团队如何协调谁发布什么、何时发布？转向让团队更快在环境间移动变更的发布模型，意味着团队需要新方式去了解其他发布及其时间。还要为团队如何使用沙箱与 scratch orgs 之类新环境建立强有力的系统。
- 规划源代码管理：你今天用源代码控制吗？团队如何把工作签回源代码控制？代码审查在哪里、如何发生？需要限制对某些分支或环境的访问吗？CI/CD 等自动化如何影响应用管理生命周期？如果刚接触源代码控制，先从 Git 与 GitHub 基础入手；然后评估如何组织仓库与分支——有意义的源代码控制与分支计划能简化日常开发工作流。要确保仓库与分支的管理计划支持你已确立的团队协作与交付计划，别让源代码控制模式让团队孤立、制造冗余或冲突定制。如果已有源代码控制但与团队工作方式不一致，找出原因（缺乏培训？工具问题？）——现在正是解决这些悬而未决问题、让团队有效使用源代码控制工具的好时机。
采纳新工具并获得支持（Adopt New Tools and Get Stakeholder Buy-In）
在决定采纳某个工具前，先花时间学习其能力以做出明智决策，并对采纳之旅保持现实态度。一个健康的采纳计划应在早期就交付一些积极或令人兴奋的部分，同时建立对挫折或不确定时刻的现实预期。如果你无法识别切实的早期回报、或无法具体说明风险，你的计划可能还不够扎实。
- 识别好的采纳机会：成功的采纳始于识别正确的机会。想想变更涉及的资源（人、时间、技术）与所需技能（沟通、产品知识、公司知识、类似项目经验）。正确的采纳机会要在「需要最密集学习的领域」与「团队已有技能」之间取得平衡。如果团队对管理源代码或 Salesforce DX 所需的许多工具不熟悉，可以从组织的一小部分入手；或者，如果能与一个沟通体系强、流程文档好的团队合作，也可以选择一个稍复杂的组织部分。无论哪种方式，都要考虑某功能需要变更的频率以及它对业务的关键程度。
- 获得支持（Get Buy-In）：识别出最佳机会后，下一步是让利益相关者上船。他们可以成为最早、最坚定的采纳者，你希望他们为帮助自己团队成功的潜在艰苦工作做好准备、投入其中。获得支持不是只讲好处、淡化风险，而是要公开、易懂地谈论令人兴奋之处与未知/风险之处。尽早让利益相关者参与，给他们真实的方式来帮助构建和影响采纳计划；讨论如何最好地分享反馈（正面的和负面的）、利益相关者如何有效收集和传递来自未深入参与者的信息、哪些渠道最有效（邮件？Chatter 群组？）。
- 为失败留出空间（Build in Room for Failure）：不是每个计划都能按计划进行——不经历失败的时刻，就无法创新。成功的计划应当考虑如何处理失败。一种方式是建立清晰的沟通渠道；另一种是识别可能遇到的风险，并明确指出其中哪些可能是项目的关键失败点。针对每个失败点，团队应讨论「成功或失败是什么样子」，在开始前设定清晰的成败判断标准。还要制定现实的时间表，为潜在挫折留出余地——因僵化或不切实际的截止日期而仓促完成关键部分，只会增加挫败与怀疑。公开、现实地谈论失败，还能帮助团队与失败建立健康的关系，让每个人都更善于提出可能对规避失败至关重要的信息。
最后是采纳曲线：第一个包很难（你要同时学习一切）；第二个包更容易（模式开始浮现）；第五个包成为常态（团队内化了工作流）；第二十个包则理所当然（你无法想象回到过去）。开始 → 学习 → 改进 → 重复。