学习目的
- 预习系统管理员的培训内容
- 更好的吸收理解系统管理员的培训内容
- 巩固系统管理员的知识
作者： ponybai
DEX450培训作业
学习目的
- 预习开发1的培训
- 更好的吸收理解开发1的培训内容
- 巩固开发1的知识
| Day | NAME | URL |
| 第1天 | Salesforce Platform Basics | https://trailhead.salesforce.com/en/content/learn/modules/starting_force_com |
| 第1天 | Data Modeling | https://trailhead.salesforce.com/en/content/learn/modules/data_modeling |
| 第1天 | Formulas & Validations | https://trailhead.salesforce.com/en/content/learn/modules/point_click_business_logic |
| 第2天 | Advanced Formulas | https://trailhead.salesforce.com/en/content/learn/modules/advanced_formulas |
| 第2天 | Quick Start: Apex | https://trailhead.salesforce.com/en/content/learn/projects/quickstart-apex |
| 第2天 | Apex Basics & Database | https://trailhead.salesforce.com/en/content/learn/modules/apex_database |
| 第3天 | Database & .NET Basics | https://trailhead.salesforce.com/en/content/learn/modules/database_basics_dotnet |
| 第3天 | Apex Triggers | https://trailhead.salesforce.com/en/content/learn/modules/apex_triggers |
| 第3天 | Data Security | https://trailhead.salesforce.com/en/content/learn/modules/data_security |
| 第4天 | Data Leak Prevention | https://trailhead.salesforce.com/en/content/learn/modules/data-leak-prevention |
| 第4天 | Apex & .NET Basics | https://trailhead.salesforce.com/en/content/learn/modules/apex_basics_dotnet |
| 第4天 | Developer Console Basics | https://trailhead.salesforce.com/en/content/learn/modules/developer_console |
| 第5天 | Apex Testing | https://trailhead.salesforce.com/en/content/learn/modules/apex_testing |
| 第5天 | Visualforce Basics | https://trailhead.salesforce.com/en/content/learn/modules/visualforce_fundamentals |
| 第5天 | Quick Start: Visualforce | https://trailhead.salesforce.com/en/content/learn/projects/quickstart-visualforce |
在Lightning Experience中使用Apex和Visualforce进行编程开发（DEX450）
概观
您是一名想要了解如何在Salesforce平台上以编程方式自定义应用程序的程序员吗？在本课程中，您将学习Apex编程语言和Visualforce标记的核心，以便自定义Salesforce应用程序。您将获得构建数据对象（sObjects）以及以编程方式检索，操作和存储与这些对象关联的数据的实践经验。您将使用Apex触发器和类编写自定义逻辑，并使用内置测试框架测试该逻辑。您将探索Apex代码如何与平台上的声明性自定义交互，以及在多租户平台上工作的细微差别。然后，您将研究在Apex中设计解决方案的常用技术。这些活动最终将在构建复杂触发器的练习中发挥作用，该触发器利用平台的声明性方面。您将获得编写Visualforce页面以定制用户界面的实践经验
谁应该参加这门课程？
本课程面向不熟悉Salesforce平台的程序化开发人员，他们需要能够使用Apex和Visualforce将编程自定义编写到业务逻辑和用户界面层。
完成本课程后，您将能够：
- 使用声明性接口创建和修改对象
- 使用Apex触发器和类编写业务逻辑自定义。这些自定义将使用SOQL和DML。
- 设计利用声明式自定义的程序化解决方案
- 在“保存执行顺序”的基础知识中描述触发器代码的工作原理
- 描述在多租户平台上设计程序的一些基本方面
- 编写Visualforce标记和代码以自定义用户界面
- 使用内置测试框架来测试Apex和Visualforces
课程和主题
对象和领域
- 描述Salesforce平台上对象的功能
- 创建自定义对象
- 创建自定义字段
- 创建关系字段
有效地使用自定义对象和字段
- 创建公式字段
- 创建汇总汇总字段
- 描述记录类型的功能
用Apex编程
- 描述Apex的主要方面，将其与其他语言区分开来，例如Java和C＃
- 描述在编写Apex时必须考虑Apex事务和调控器限制的原因
- 执行简单的Apex
- 在Apex中使用sObject数据类型，原始数据类型和基本控制语句
使用SOQL查询您的组织数据
- 使用Salesforce的查询语言SOQL编写基本查询
- 在Apex中处理查询结果
- 在运行时动态创建查询使用SOQL查询父子关系
- 描述关系查询
- 编写一个遍历子到父关系的查询
- 编写一个遍历父子关系的查询
DML Essentials
- 列出可以调用DML操作的方式之间的差异
- 编写Apex以调用DML操作并处理DML错误Trigger Essentials
- 描述触发器的用途
- 描述触发器定义的语法
- 使用触发器上下文变量类
- 描述如何使用Apex类
- 定义Apex类
- 确定Apex类可以访问的数据
保存执行顺序和Apex交易
- 描述执行顺序中的关键点
- 描述触发器如何适应并可能受执行顺序的影响
- 描述Apex交易的生命周期
- 描述静态变量的内存生命周期
测试要点
- 描述Apex的测试框架
- 创建测试数据
- 编写并运行Apex测试
测试策略
- 描述编写易于维护和扩展的代码的实践
- 编写假设批量数据作为输入的触发器和类
- 编写与数据库一起高效工作的代码，包括查询和使用DML
设计高效Apex解决方案的策略
- 确定您的代码覆盖率百分比
- 使用最佳实践创建测试
触发设计策略
- 列出声明性机制，可用于实现复杂的业务逻辑，最佳使用的问题类型及其局限性
- 描述可以使用声明性功能来改进程序化解决方案的方法
创建Visualforce页面
- 创建一个Visualforce页面
- 参考标准控制器
- 使用自定义按钮启动Visualforce页面
- 显示Visualforce页面中记录的数据
探索Visualforce的视图和控制器层
- 创建一个Visualforce页面
- 显示相关数据
- 调用标准控制器操作
使用自定义控制器和控制器扩展
- 创建控制器扩展
- 创建自定义控制器
- 使用属性
- 使用PageReferences
- 在Visualforce页面中调用自定义方法
使用列表控制器和SOSL查询
- 在Visualforce页面中使用标准列表控制器
- 创建SOSL查询
- 创建自定义列表控制器
Visualforce开发注意事项
- 确定是否存在符合您要求的声明性解决方案
- 描述常见的州长限制问题和安全问题
- 描述Visualforce策略测试Visualforce控制器
- 描述Visualforce控制器如何与视图交互
- 编写控制器构造函数的测试
- 编写动作方法，getter，setter和属性的测试
服务云管理（ADM261）
概要
对于需要为其组织配置和维护Service Cloud的有经验的管理员而言，服务云管理是必需的。使用真实场景，本课程将教授管理员如何配置Salesforce Knowledge，设置具有里程碑和权利的服务合同，创建Console for Service应用程序，使用Open CTI配置SoftPhone以及设置Live Agent。本课程还将教授管理员如何配置客户社区。
谁应该参加这门课程？
使用Salesforce和/或已完成Administration Essentials for New Administrators课程的管理员至少六个月使用经验的管理员
完成本课程后，您将能够：
- 使用队列，分配/升级规则和工作流设置案例管理流程以自动化支持流程
- 配置Salesforce知识以帮助您管理知识文章的创建，发布和维护
- 启用权利以设置具有里程碑的服务合同
- 设置Salesforce Console for Service并帮助您的支持代表更有效地工作
- 了解控制台中CTI界面的功能
- 使用Live Agent配置与客户的在线聊天
- 了解并设置社区
课程和主题
案例管理，自动化和权利
- 创建支持流程以满足业务需求
- 通过案例评论，案例队列，分配规则和升级规则的Web到案例工作流，将Salesforce自动化扩展到服务和支持环境
- 了解权利管理
Salesforce知识
- 了解Salesforce Knowledge的关键概念
- 使用文章类型，数据类别和案例集成完成部署知识所需的功能
- 了解以知识为中心的支持
- 定义文章类型工作流程和审批流程的用例
控制台中的多渠道支持服务
- 了解Salesforce Console for Service的功能•为用户分配Service Cloud User许可证
- 创建服务控制台应用程序
- 在控制台中了解并启用Live Agent
- 了解CTI的基础知识
- 启用Salesforce Open CTI演示并将其添加到控制台
Salesforce自助社区
- 了解社区的用例，目标和设置
- 在Salesforce组织中启用社区
- 创建和自定义社区
- 创建社区仪表板
- 理解并设置声誉
销售云管理：产品，报价，订单和协作预测（ADM251）
概要
对于需要为其组织配置和维护这些功能的所有管理员而言，此课程是必须的。使用真实场景，本课程将教授管理员如何设置产品，价格手册，报价和订单以简化流程。本课程还将教授管理员如何配置协作预测以生成准确的预测并跟踪配额实现情况。
谁应该参加这门课程？
使用Salesforce至少六个月经验的管理员; 和/或已完成“新管理员管理基础”课程的管理员。
完成本课程后，您将能够：
- 设置产品，价格手册，报价和订单以简化流程
- 设置协作预测
课程和主题
设置产品，价格手册，报价和订单
- 描述产品，价格手册，报价和订单的功能
- 描述机会，产品，价格手册，报价，合同和订单之间的关系
- 创建和定制产品和价格手册以跟踪产品及其销售的各种价格
- 将产品添加到商机中
- 生成报价，显示产品和服务的建议价格
- 将报价与机会同步
- 将产品添加到订单中以跟踪客户对产品和服务的请求
设置协作预测
- 描述协作预测的功能。
- 为用户启用预测
- 根据机会，产品系列，机会拆分和自定义字段配置多个预测类型以进行预测
- 将机会阶段映射到预测类别。
- 定义预测经理并启用调整。
- 为用户添加配额数据
- 构建预测和配额报告
Salesforce登录和缓存
学习目标
完成本单元后，您将能够：
- 清除手机端和浏览器缓存
- 设置离线使用Salesforce
- 自助判断Salesforce无法登录现象的原因
用户在使用Salesforce手机端的时候，经常遇到下面的现象
- 用户体验应用程序中的白色屏幕。所有记录都无法加载。关闭应有再次打开，该应用程序永远不会恢复。
- 用户不断看到启动页面
- 用户看到“再试一次”屏幕。该应用程序可能会或可能不会恢复。与验证相关的其他错误消息。
这些原因通常是因为Salesforce使用了LEX缓存技术。通常这种技术使应用和网页执行的更快，不需要每次操作都去访问服务器。但是Salesforce的版本更新速度实在太快。而缓存内容在版本之间是不兼容的。导致新功能使用旧的缓存，使网页或应用加载时显示不正常。这就需要清理你的缓存了。
注意：在清楚缓存之前，先判断是不是网络的问题。
- 通过 https://status.salesforce.com/ 查看服务器状态。
- 通过查看其他海外站点（比如 https://www.yahoo.co.jp/ ）判断是不是整体海外路由问题。
- 执行Traceroute命令定位到Salesforce主机之间的所有路由器。
- 执行PING命令检查网络是否连通。
- 通过Log Case和热线电话获取Salesforce 技术支持。
- 打电话给网络公司或运营商。告诉他们salesforce.com访问速度慢。提供给他们Traceroute的结果。他们会调查问题，优化路由，更新DNS等操作。而且他们的相应速度还挺快的。（这个我试过）
更多细节参考处理Salesforce无法访问情况。
清理缓存
清理Salesforce iOS移动版本的缓存
清理Salesforce Android移动版本的缓存
找到设置，试一试设置里面的高级中有一个Lightning设置。点击一下重新加载Salesforce。
清理Salesforce 谷歌Chrome移动版本的缓存
打开Salesforce的，点击鼠标右键，点击检查。在浏览器下方出现如图所示。
找到Application下面的Clear storage，点击Clear the data。之清楚该站点的缓存。
清理Salesforce 苹果Safari移动版本的缓存
清理Salesforce微软IE和Edge移动版本的缓存
打开浏览器设置，选择开发人员工具。显示如图画面
找到存储下面的本地存储。选择该站点。全选后点击右键，删除项。
敏捷模型（7）CA Agile Vision 可以帮助您的十种方式
学习目标
完成这个单位后，你会知道：
- 将您的技术融合在一起
- 增强团队的能力和学习能力
- 让您的商业生活更轻松
CA Agile Vision是当今最强大的在线敏捷开发环境之一。该软件专门为您的组织无缝地提供Scrum技术。本章致力于了解CA Agile Vision软件是否可以为您的业务提供帮助。
改善沟通
当您拥有分布式Scrum团队时，几乎不可能只保留一份重要文档和日程表 – 除非您在线操作。使用CA Agile Vision，您可以在线完成所有计划，日程安排和积压任务，以便在分布式团队成员之间立即进行协调。
节省时间
您的敏捷团队是否花费大量时间向管理层提供有关其进度的报告？ CA Agile Vision可帮助您的团队自动创建报告，只需点击几下，即可节省大量时间。通常，报告要求会推动传统的项目管理报告，这些报告是为预先计划的项目而设计的。
CA Agile Vision与CA Clarity on Demand的集成可以提供从敏捷方法和词汇到管理层习惯的术语和报告的翻译。
赋予你的团队权力
传统的项目管理要求团队规划整个项目，并获得对在此过程中遇到的变更的批准。这些变更和原始计划通常要求团队完成现有的治理流程，从而剥夺了Agile建议的功能。
CA Agile Vision和CA Clarity On Demand可以为那些习惯于定义为传统工作分解结构（WBS）的项目提供安慰，并在许多传统项目经理不确定他们是否可以从敏捷项目中获取信息时提供可见性和反馈。
合并产品负责人
CA Agile Vision专注于让产品负责人参与您的项目 – 这对任何Scrum项目都至关重要。产品负责人拥有各种在线工具，可以立即访问项目的所有内容。
由于能够创建和管理产品Backlog，以及通过仪表板的冲刺跟踪产品的进度，产品负责人可以感觉更像是团队的一部分，其中包含专门为开发团队设计的许多其他解决方案。敏捷项目。
发展你的学习
CA Agile Vision在各个级别提供了许多支持Agile的工具。随着您对Agile开发的深入了解，CA Agile Vision随您而来。 CA Agile Vision专为敏捷成熟的各个级别的团队而构建，因此该解决方案适用于所有人。
自动化您的流程
您的敏捷团队是否难以使用手动流程进行积压和Sprint计划？ CA Agile Vision中的一切都是自动化且易于使用的。界面直观而自然，使得积压工作和Sprint计划变得轻而易举。
用不同语言与您的团队交流
CA Agile Vision通过为使用德语，意大利语，日语，西班牙语，法语和巴西葡萄牙语的工作人员提供翻译和本地化版本，为非英语用户提供支持。
降低成本
您是否希望零管理和运营成本具有高性能，安全性和可靠性？ CA Agile Vision可作为订阅服务提供，不需要您的组织购买和维护昂贵的硬件，从而占用关键的管理资源。
教育你的初学者
您的组织中是否存在不同级别的敏捷成熟度？并非每个开发人员都精通敏捷方法和技术。为了让新手加快速度，预先构建的Agile框架以及所需的所有工具都是非常宝贵的。 CA Agile Vision的设计考虑到了这个问题，对于新手敏捷团队成员来说是平易近人的，并且还可以支持更成熟的团队。
集成解决方案
您是否有团队成员致力于敏捷和传统项目？当团队成员必须在工具和方法之间进行转换时，这在许多大型组织中很常见，能够跟踪和管理您的工作，项目以及最终在一个集成解决方案中的时间可以节省时间和减轻压力。
CA Clarity on Demand和CA Agile Vision的集成解决方案使团队成员可以进行集成，并且资源管理员和项目管理办公室（PMO）员工可以了解一个解决方案中发生的情况。
更有效地管理您的项目
敏捷是一套令人兴奋的原则，可为客户带来价值。 它通过特定的实践和技术来体现，使产品开发更具迭代性和渐进性，并通过在关键步骤中让客户参与，使您更接近客户的需求。 使用迭代方法，客户可以不断提供反馈，以获得他们真正想要的产品，然后他们可能最终购买并建立公司收入。 产品和工具也支持敏捷。 了解CA Agile Vision如何帮助您有效管理实施敏捷的项目。
敏捷模型（6）决定敏捷是否适合你的十种方法
学习目标
完成这个单位后，你会知道：
- 使敏捷融入您的工作环境
- 了解您的团队如何使用敏捷
- 了解您是否满足所有要求
敏捷技术并不适合每个组织。本章中的问题可以帮助您决定是否
敏捷是否适合您的项目开发。
你的团队是否并列？
当团队位于同一个地方时，敏捷和Scrum技术会蓬勃发展 – 分布式团队可能会引入问题，因为没有并置需要团队更加努力地进行沟通和协作。但是，如果您可以将您的团队聚集在一个地方或利用在线解决方案来管理敏捷工件，那么这就是支持敏捷开发的一个重点。
你能容忍一个有能力的团队吗？
敏捷团队必须尽可能自主，才能使敏捷方法发挥作用。个人内化自己的纪律。如果你能够在不需要繁重的外部管理的情况下生活，那么这对Agile有利。
在具有强大管理风格的组织中，CA Clarity PPM和CA Agile Vision等解决方案可以帮助实现管理和敏捷团队的目标。
项目规模大吗？
大型项目可能不适合敏捷和Scrum方法，这些方法针对较小的团队。虽然您可以将较大的项目分解为较小的团队，但您必须为将出现的协调问题（例如Scrums of Scrums的创建）做好准备。 Scrum of Scrums的创建有所帮助。有关Scrum of Scrums的更多信息，请参阅第3章。
使用Agile可以成功实现大型项目。实际上，许多组织使用传统的项目管理方法使用Agile和其他部分运行项目的一部分非常成功。随着更大的项目及其相关的挑战增加，您的团队将需要额外的沟通。
是一种迭代的方法吗？
有些组织需要在项目开始之前从头到尾规划项目的所有方面。敏捷以连续的周期以迭代的方式工作，没有一个全面的，前期的，必须做的计划。
你有经验丰富的开发人员吗？
经验丰富的开发人员知道开发过程中涉及的内容，并且不需要太多的外部指导。他们已经知道了这些绳索并对项目开发非常熟悉，因此他们知道对他们的期望 – 新手开发人员可能不知道的事情。
你的团队是否受到激励和承诺？
敏捷和Scrum团队需要内化项目所需的动力，以便他们能够以最少的外部管理完成工作。如果您的团队有动力并且能够参与项目，那么这是支持敏捷开发的另一个观点。
你有有效的团队领导力吗？
Scrum团队依靠ScrumMaster，团队领导者，通过项目看到他们，处理障碍，并运行每日Scrum。
理想情况下，您对ScrumMaster的想法应该是Scrum知识渊博的人，以及没有命令和控制风格的有效领导者。
您能否容忍持续的客户存在？
Scrum方法要求持续的客户参与 – 理想情况下，将客户代表（产品负责人）与Scrum团队并置。如果你不能容忍这样一个持续的客户存在，敏捷和Scrum可能不适合你。但是，持续的客户参与是您了解自己为客户构建正确产品的方式。
团队是否有他们需要的一切？
Scrum团队应该拥有完成项目所需的一切。他们不应该与组织的其他人员和组件进行重要的协调来完成他们的工作。
客户代表能否提出所有要求？
在Scrum开发中，产品负责人理想情况下应该是团队的项目要求的首选人。产品负责人是产品方向和要求的最终负责人。
敏捷模型（5）让每个人都保持联系
学习目标
完成这个单位后，你会知道：
- 检查每日Scrum的最佳实践
- 与分布式团队沟通
- 处理大型项目
- 使用CA Agile Vision中的虚拟墙
沟通是Scrum开发过程的核心。 Scrum实践是关于会议 – 每日Scrum会议，如何处理与分布式团队的会议，Scrum of Scrums详细介绍大型项目（有关Scrum of Scrums的更多信息，请参阅第3章）。本章有助于让每个人保持联系。
在本章的最后，我们将向您展示CA Agile Vision提供的一些工具，以便让每个人保持联系 – 特别是虚拟墙和报告。
作为一个团队进行沟通
沟通对任何Scrum团队都至关重要。团队成员应该与ScrumMaster保持联系。应该在Scrum团队中进行持续的与工作相关的对话。
内部和外部通信都在Scrum团队中进行。本节向您展示两者的活力。
内部沟通
团队成员之间的内部沟通是Scrum流程的核心部分。团队内部必须存在自由和轻松的沟通，因为团队通常由不习惯沟通的跨学科成员组成。这是ScrumMaster的工作，以确保团队成员相处融洽，但ScrumMaster只能做很多 – 沟通完全取决于团队成员。最终，不能很好地沟通的团队成员可能需要更换。
Scrum流程的结构有助于沟通。每日Scrum是一个站立式会议，所有与会者都站起来强调会议的简短性质（大约15分钟），而且都是关于沟通的。每个团队成员都要报告他们前一天所做的事情，他们今天将要做的工作，以及他们面临的障碍。
这里ScrumMaster的工作是确保团队成员充分参与会议，避免对这些问题做出简短的，两个对应的单词回答。理想情况下，每个团队成员必须明白他们的答案必须完整，好像他们的目标对象是需要知道但可能无法快速掌握其特定专长的人，例如产品负责人。
ScrumMaster还应该注意每个团队成员提到的障碍，并努力消除这些障碍;一些关于Scrum的评论员说，这是ScrumMaster所有工作中最重要的，如果团队运作良好，很可能就是这样。
外部沟通
外部沟通意味着团队与客户之间的沟通，这通过产品负责人进行。作为客户的代表，产品负责人必须知道完成项目所需的所有内容，并且始终可以访问 – 甚至可能与Scrum团队并置。
Scrum团队与团队所属的大型组织之间进行了额外的外部沟通。这种沟通主要关注项目资源和边界 – 访问所需的资源，如数据库服务器;边界包括预算问题和时间限制。
这种类型的外部通信几乎总是在需要时通过ScrumMaster进行。换句话说，ScrumMaster通常是Scrum团队与团队所属的大型组织之间的联络人。必须尽可能地允许团队完成其工作，而不必受到无关细节的困扰。
每日Scrum：最佳实践
每日Scrum或每日站立会议是Scrum开发的核心。这次会议就是沟通。请所有与会者在可能的情况下站起来强调会议应该简短。保持会议简短会做两件事：
- 保持一个新的，专注的会议，不会拖延
- 当团队成员的工作时间更好时，可以避免过度拖延
让每日Scrum保持新鲜特别重要 – 你可能会遇到永远喋喋不休的会议，浪费时间并向每个人强调会议主要是为了形式而举办，而不是为了功能。 每日Scrum的功能非常强大 – 这个名字很好地取自橄榄球，在开始行动之前，球队会暂时收集橄榄球。 另一个重要方面是所有团队成员都要准时，以确保没有人浪费别人的时间。
每日Scrum的重点在于沟通 – 它让每个团队成员都知道每个人在工作中的位置，他们下一步打算做什么，以及他们面临的障碍。 它为团队保持至少最小量的面对面互动，其成员可能只是消失在小隔间里。
每日Scrum的好处包括
- 促进承诺
- 向团队传达进展
- 识别障碍，以便团队可以删除它们
- 保持专注
- 促进团队合作
预计所有Scrum项目都会持有每日Scrums – 这就是方法的名称来源。
每日scrum如何实际运作
每日scrums是在sprint期间发生的每日会议，从第二天到sprint结束（Sprint的第一天用于Sprint计划）。每日Scrums快速，专注，非常协作。 ScrumMaster为他们提供了便利，但每个团队成员都必须参与并发言。每个团队成员和ScrumMaster（以及产品负责人，如果适用）都有责任参加每日Scrum并准时出席。
每个团队成员和ScrumMaster的出席尤为重要，因为每日Scrum也可以作为识别问题的一种方式。一个团队成员面临的特殊挑战可能是另一个团队成员的特殊挑战，这个问题可以启动团队成员之间的正确联系，然后在每日站立后脱机谈话。每日Scrum还让每个团队成员了解每个其他团队成员正在做什么以及他们面临的障碍。
每日Scrums限制为15分钟，但如果一切顺利，它们可以短至5分钟。如果讨论可能会持续超过几分钟，那么它们应该推迟到Scrum结束，所以只有那些感兴趣的人才能在单独的会议中继续讨论。坚持这些会议的短时间框架对Scrum流程来说非常重要，以保持这些会议的新鲜感。
每日Scrum寻求实现许多目标：
- 促进承诺：在每日Scrum期间，团队成员承诺每天都在做什么。作为一个团队每天做出相互承诺是每日Scrums最重要的目标之一。
- 沟通进展：认识到团队成员应该对团队负责是很重要的。每日Scrum都会提升责任感 – 而不是向经理报告进度，每个团队成员向团队报告。
- 识别障碍：当出现障碍时，面对问题的团队成员通常不应该单独奋斗。如果其他团队成员可以提供建议或解决方案，则不会延迟进度。这种协作是Scrum实践的全部。
- 保持专注：在每日Scrum期间，ScrumMaster将注意力集中在Sprint积压上。 Scrum用于不断提醒团队该方向是什么，以便团队可以专注于这些任务。
- 促进团队合作：通过定期沟通，协作和互相帮助，建立有效的团队。团队成员的联系越多，他们就越能相互依赖。
所以我们已经告诉过你关于会议以及会议的重要性，但你可能会想，“那些会议中发生了什么？”有趣的是你应该问。以下是每日Scrum的详细信息：
- ScrumMaster每天在同一时间和地点发出定期会议通知。
- 团队成员准时出现。
- 每个团队成员回答以下问题：
- 昨天我完成了什么？
- 今天我会做什么？
- 阻碍我进步的障碍是什么？
- ScrumMaster记录进度并更新sprint burndown图表。列表中添加了任何障碍，以确保它们得到缓解。
- 任何较长的项目都可以跟那些有兴趣讨论这些项目的团队成员进行跟进。
在每日Scrum期间，团队成员可以查看Sprint积压，燃尽图，虚拟墙和障碍列表，以深入了解进度。
遵守游戏规则
当你年轻的时候，你可能已经知道生活是由一系列规则决定的。那么，作为一个成年人，在一个非常成功的公司工作也没有什么不同。每日Scrum的规则包括以下内容：
- 每天的Scrum应该在每天的同一时间举行，以提供稳定感和所有权。有兴趣的人应该能够观察每日Scrum，以避免安排其他会议。
- 团队成员不得强制延迟或更改每日Scrum的位置。
- 一般而言，任何人都不应该能够更改时间表或地点。这应该是Sprint Planning或回顾期间的团队讨论。
- 只有整个团队同意，才能修改时间表。
- 每个人都应该参加。每日Scrum是为了团队的利益，所有Scrum成员都必须参加。
- 如果有人迟到，会议不会被推迟（Scrum方法非常清楚，不是“奖励”后来者）。
- 每个团队成员都应与整个团队交流。在会议期间，团队成员轮流发言，有时会通过令牌表示当前有意发言的人。
- 如果团队成员不能参加Scrum，他应该向代理（例如另一个Scrum团队成员）提供他的信息。
- 承诺。在每日Scrum中发言的所有人都必须是分配到该项目的Scrum团队成员和Sprint（有时在第3章中说明承诺的故事中称为“猪”）或者
- 产品拥有者。其他人可能会参加，但不允许发言（这些人被称为“鸡”）。
- 保持简短。每日站立的目标是简短的。确保它实现了这一目标。
捆绑松散的目标
在每日Scrum会议上发生的事情很多，我们可以在会议上写一整本书。你有一些挥之不去的问题吗？我们希望通过给你一些最后的记忆来回答本节中的一些内容。
如果团队落后会发生什么？
如果团队注意到它落后了，如燃烧图表所示，它应该将这个事实引入ScrumMaster的注意力而不是简单地希望它能够在没有任何纠正措施的情况下赶上。
一些加班时间可能会纠正这个问题，但不推荐长时间和极端加班 – 至少部分是因为它会影响团队速度的真实衡量标准（未来的项目可能期望加速速度相同）。可以在回顾中讨论进度和速度问题，并在下一个Sprint的下一个Sprint计划会话中进行调整。
如果某些加班时间不足以纠正问题，ScrumMaster应该调查添加临时团队成员的可能性。额外的临时团队成员应尽可能与项目结盟，项目目标应属于他们的专业领域。
如果团队确定了其他任务怎么办？
您的团队可能会识别Sprint计划中未出现的其他必要任务。如果您有这个问题，答案取决于新任务是否延迟项目或影响冲刺。如果新任务不会引入重大延迟，团队成员应该承诺并执行任务。
如果新任务在项目完成时引入延迟或影响sprint，则必须由ScrumMaster将其输入到Sprint backlog中，并将其视为任何其他任务。可以向产品负责人请求确认新任务。
每日Scrum不被视为解决问题的会话。每日Scrum是一个沟通会议 – 如果有需要更多关注的问题，有兴趣的各方应该在每日Scrum之外见面。
保持分布式团队的联系
传统上，Scrum团队在同一地点并置。它们共享相同的物理工作环境，包括列出Sprint积压任务的相同图表和电路板。这些项目可以放在共享的团队空间中，每个人都可以平等访问它们。
分布式团队实现统一要困难得多。在这种情况下，您没有共享的物理团队空间 – 没有并置，没有物理图表，也没有列出Sprint任务的板。相反，您需要建立一个在线协作空间，并使用CA Agile Vision等敏捷规划工具来共享信息和文档。
特别是，分布式Scrum团队面临两个重大挑战：
- 缺乏有效的会议：对于其他地方的部分或大部分团队而言，举行高效，协调的会议是一项挑战。
- 文档复制：如果每个团队网站都有自己的项目文档副本，例如燃尽图，积压工具等，那么这些文档很快就会变得不协调。
本节将详细介绍解决这两个问题。
创建高效的分布式会议
如果每天Scrum的一半发生在加利福尼亚州的圣地亚哥，另一半发生在印度孟买，那么你将面临一些沟通问题。
简单地将每日Scrum分成两个独立的会议是最不具吸引力的选择。这有效地减少了团队之间的沟通，这显然是不可取的。
幸运的是，有大量的网络工具可以提供帮助，以及其他一些要点：
- 使用简短，专注的会议。短期会议比长会议更好。可以运行会议以仅包含关键信息。应在会议召开前至少24小时向所有团队成员提供会议支持文档。
- 使用Web会议工具。微软LiveMeeting等工具非常适合为远程团队成员提供服务。分布式团队可以使用基于Web的会议软件的正确组合来体验并置的每日Scrums的体验。
- 尽量缩短时间和地区差异。尽你所能选择最适合每个人的会议时间。团队应避免根据会议安排会议
- 单一地点，并了解时间表中的地区差异，例如当地假期。
- 记录所有内容：应使用基于Web的工具（如CA Agile Vision）来支持信息和详细信息。
协调文件虚拟
发展取决于与团队共享文档 – 产品积压，Sprint积压，燃尽图，发布计划积压。
当存在多个文档副本时，共享此类文档会变得更加困难。伊利诺伊州芝加哥市的燃烧图表存在与中国北京类似燃烧图表不同步的风险。如果它们是两个独立的图表，它们应该代表相同的进展，那么它们会慢慢地彼此不同步（可能）都不是真相。那时，你必须在sprint结束时调和。
该解决方案涉及在Web上托管共享文档，图表和计划。这些解决方案包括以下功能：
- 积压管理：如果所有积压项目描述，优先级，验收标准和状态都保存在一个地方，那么对于要完成的工作范围和规模的错误沟通的可能性就会降低。
- Sprint管理：此工具使用通用任务板，因此每个团队成员都知道其他团队成员正在做什么。
- Sprint报告：Burndown图表和其他sprint报告指标可以让整个团队快速了解团队和团队成员的进度。
- 时间跟踪：为了使图表和报告中的指标有意义，团队成员需要跟踪他们的时间。
- 用于团队沟通的虚拟墙：团队成员可以随时在墙上张贴，当墙在世界各地立即共享时，该沟通可以保持团队的协调。
所有这些分布式Scrum团队成员之间的即时通信都可以通过CA Agile Vision等基于Web的工具立即实现。 CA Agile Vision为您提供了托管Scrum团队在线所需的所有共享文档的工具，以使每个人都能够处于循环中。
内部审视CA Agile Vision：将任务添加到虚拟墙
当团队首先使用Scrum时，他们会使用记事卡来捕获用户故事和任务。然后他们将它们放在墙上并在那里管理它们。使用CA Agile Vision，任务墙变得虚拟，可供各地团队使用 – 并且清洁人员不会意外地将卡刷掉。
CA Agile Vision专注于保持团队成员和其他人的联系。虚拟墙作为一个中心焦点，让人们了解冲刺的方式。虚拟墙使团队成员能够以图形方式管理任务。
虚拟墙遵循一个比喻，许多团队手动工作将遵循。这些团队在记录卡上创建用户故事和/或任务，并通过将它们附加到按状态划分的墙来跟踪其优先级和进度。
团队成员可以查看为sprint提交的所有用户故事和任务，并可以在页面中编辑任务并更新其状态。通过这种方式，团队中的每个人 – 以及产品负责人等其他感兴趣的团队 – 都可以一目了然地看到冲刺的方式。
您可以快速将任务添加到CA Agile Vision中的虚拟墙;只需按以下步骤操作：
- 单击“导航”菜单，从“计划”菜单中选择“Sprint详细信息”。
- .显示用户故事所属的sprint的详细信息，然后转到Virtual Wall。
- 单击要添加任务的用户素材的“新建任务”。
用户素材中添加了一个新的任务窗口。 - 双击名称下方的任务窗口。
任务窗口将重新显示您可以编辑的字段。 - 填写字段，其中包括以下内容：
清除顶部字段并输入任务标题。
在第二个字段中输入将分配给任务的团队成员的名称。
在第三个字段中输入估计完成任务的小时数。
如果任务已启动，请输入工作小时数。
如果任务已启动，请单击向右箭头按钮将任务状态从“计划”更改为“正在进行”。 - 单击复选按钮以保存设置。
您可以在图中的虚拟墙上看到示例任务。
敏捷模型（4）满足您的Sprint 规划目标
学习目标
完成这个单位后，你会知道：
- 发现Sprint Planning的细节
- 将Sprint计划划分为多个细分市场
- 审查整个过程
- 在实际示例中使用CA Agile Vision
sprint规划对Scrum至关重要。 Scrum在一系列称为sprint的迭代中攻击一个项目，并且在sprint期间工作完成。这就是为什么确保正确规划冲刺的重要原因 – 这就是您设置冲刺目标和选择故事的地方。在sprint结束时，团队应该有一个潜在的可交付产品呈现给客户。
这就是Scrum中项目的完成方式 – 您通过从产品积压中剥离任务开始Sprint Planning并将其移至Sprint积压 – 然后团队执行这些任务，然后在结束时向客户和产品负责人演示可交付成果。 -Sprint Review然后这个循环再次从sprint开始到sprint。以这种迭代方式，产品发展。
本章是关于规划sprint的。
设定您的目标：Sprint计划
Sprint是在Scrum开发中完成工作的地方，在开始sprint之前，您花了一天时间来规划sprint。这是Scrum的一项规则 – 每个sprint都以Sprint Planning会话开始。
Sprint Planning背后的想法是确定团队在该sprint期间将准确处理哪些故事。 Sprint Planning完成了以下事情：
- 它确保你知道你在sprint中关注的是什么。
- 结合Sprint End Sprint，Sprint Planning确保团队提供的服务与客户的需求和需求更紧密地结合在一起。
- 它可以及时做出决策。将Sprint计划与有效的故事编写实践相结合意味着可以在项目中更快地交付产品。
如果没有Sprint Planning，您将面临风险
- 显着降低对工作重点的关注，这可能导致优先级较低的工作取代优先级较高的工作
- 减少团队对工作的理解，并限制经常发生的澄清量
- 冲刺期间的澄清数量增加，降低团队速度和实际承诺的交付
- 缺乏对团队燃烧速度和估算数据的理解
Sprint Planning是所有与项目有关的人员（从产品负责人到团队成员）之间进行交流的绝佳场所。本次交流的参与者应遵循以下几条规则：
- 产品负责人不应强迫团队承诺更多的故事点，而不是他们对承诺感到满意。经过一系列冲刺后，团队的速度变得清晰。
- 在团队承诺冲刺后，冲刺不会改变：团队组成没有变化，冲刺要求也没有变化。当然，可以提供澄清。
- 团队可以执行任务并将其分解为两个或更多任务。团队可能会发现不需要给定任务，可以取消此任务。对于添加，编辑或删除的每项任务，团队会在Sprint Review期间讨论更改的原因，尤其是在他们无法完成sprint目标的情况下。
Sprint Planning看起来似乎有很多规则，因此在下一节中，我们会打破规划以帮助描绘流程。
两个不同细分的规划
Sprint计划发生在冲刺的第一天 – 您计划在开始冲刺工作之前。每个Sprint计划会议通常持续一整天，或八个小时。
每个Sprint计划会话由两个部分组成。每个细分市场设计为持续约半天，大约或约四小时。 （这样可以节省两个段之间方便的午休时间。）
虽然Scrum指南说Sprint Planning通常需要8个小时，并且分为两个四小时段，但这些时间可能会有所不同。许多因素会影响规划sprint的实际时间：
- sprint中要进行的复杂性和深度工作
- 团队的成熟程度（并且已经合作）
- 冲刺的长度
- 团队规模
- 积压的故事准备得多好
细分＃1：从产品待办事项中移动商品
Sprint Planning的第一部分专注于从Product积压中选择高优先级积压项目，并将其移至Sprint积压并定义Sprint目标。将Sprint Planning的这一部分限制为四小时，可确保有效地实现这两个目的。
谁来参加会议？
谁参加了Sprint规划的第一部分？产品负责人，Scrum Master，Scrum团队以及其他人员：
- 产品负责人：产品负责人必须出现在Sprint计划会议的第一部分。产品负责人负责根据团队的建议设置sprint目标。产品负责人还负责向团队提供产品积压中最高优先级的项目。
- Scrum Master：使计划会议按计划进行。 Scrum Master促进了产品负责人和Scrum团队之间的会议，确保不熟悉Scrum实践的任何人都能加快速度。
- Scrum团队：团队审查产品所有者优先考虑的产品积压项目，并询问有关不清楚项目的问题。最终，该团队的目的是估计每个故事所需的时间并承诺Sprint积压，因此他们必须知道他们正在做什么。他们必须分析每个故事并将其分解为可以执行的任务。整个团队必须承诺进行此迭代的工作，因此尽管产品负责人提供了产品待办事项中的项目，但团队需要对其进行适当的估算和提交。
- 其他：如果有其他人可以提供信息，其他人可以参加Sprint计划会议。他们只能以顾问身份行事，不能分配工作或指导。
识别高优先级产品待办事项
Sprint计划会议的第一部分将以产品负责人为中心开始。产品负责人必须在Sprint计划会话开始之前准备产品待办事项中的故事并确定其优先级。
产品负责人以故事格式向团队提供高优先级产品积压项目（这些故事可以分解为产品积压中的任务，通常将分解为Sprint积压中的任务）。这促进了产品负责人和Scrum团队之间的开放式沟通。
通常情况下，产品负责人需要准备并优先考虑比预期使用的Sprint计划会话多50％的故事。
每个故事都应附有一套验收标准（产品负责人应明确说明每个故事成功完成的内容，因为故事会呈现给团队）。估计实施每个故事的时间尚未进入图片中，除非粗略地说 – 在Sprint计划会议的第二部分中，Scrum团队负责完善这些估算（请参阅“第2部分：估算积压项目”一节） “）。
第一部分是关于产品负责人和Scrum团队之间的面对面沟通，ScrumMaster充当促进者。这个机会让团队有机会了解产品负责人在此sprint中的期望。
重要的是，每一方都要在这里理解另一方 – 尤其是在冲刺中实现每个故事的期望。如果合适，预计该团队会提出许多问题并提出建议。
因此，例如，产品负责人可能会出现这样的故事，“作为客户，我想将我的卡插入自动柜员机。”验收标准可以指定在一定的秒数内读取卡，并在某个特定的秒内验证秒数（并且可以指定如果客户无法验证卡片该怎么做），并且卡片会在另一秒钟内被推回给客户。
定义sprint的目标
有关sprint的所有内容必须尽可能在Sprint计划会议期间进行布局，包括sprint本身的目标。如果想要创建产品负责人想要的东西，了解Sprint目标对团队至关重要。始终坚持冲刺的目标对团队来说非常重要。
sprint可能有不止一个目标，但产品负责人应该将任何sprint的目标数量限制为三个 – 比这更多，sprint可能变得没有重点。
Sprint的目标在Sprint End的最终评论中进行了审核，以确保它已得到满足。因此，例如，sprint的目标可能是“通过使用客户的PIN与ATM完成卡验证过程”。
团队中的测试人员应特别关注sprint的目标，以确保迭代符合该目标，然后才能进行充分测试。
细分＃2： 估算积压物品
Sprint Planning的第二部分是关于磨练Sprint Backlog并更详细地了解积压项目。该部分有三个主要目的：
- 团队精心准备要传递的故事
- 团队估计工作
- 团队致力于工作和冲刺
全力以赴：团队精炼要传递的故事
此时，团队会考虑所有Sprint目标以及要从Product积压转移到Sprint积压的故事。这里的一个重要问题是，在为sprint分配的时间内是否可以满足sprint的总体目标。
我必须参加这次会议吗？
谁参加Sprint计划会议的第二部分？看看这个列表，看看你是否在上面：
- Scrum团队：团队在创建Sprint积压时改进积压项目，并将每个故事分解为任务。它还必须估计工作。该团队还致力于这一领域的工作。它从产品负责人和该细分市场中的其他来源寻求信息，但此时所有方向都取决于团队和Scrum Master。
- Scrum Master：Scrum Master确保流程顺利进行 – 创建Sprint积压，团队承诺冲刺，等等。如果团队需要更多信息，Scrum Master还可以充当其他人的联络人。
- 产品负责人：产品负责人的出席非常重要，并且需要根据团队的澄清需求而定。
该团队查看优先级积压项目，确保他们了解每个故事。成员通常将每个故事分解为Sprint积压中的任务。
故事或任务的每个接受标准也会转移到Sprint积压。如果团队认为需要进一步澄清任何验收标准，则可以与产品负责人进行协商。随着故事被分解为任务，接受标准也可能会发生变化。
在这个阶段完成后，Sprint的积压已经开始成为焦点，积压的故事和任务已经到位。如果故事足够清晰且范围足够小，故事可以从产品积压转移到Sprint积压 – 否则，它们将被分解为任务。
拿出你的时间表：团队估计工作
Sprint积压已经形成，团队必须知道在分配给sprint的时间内完成工作是否切合实际。
估计工作时间是一个棘手的过程，但却是必要的过程。 Scrum实践依赖于随着时间的推移而变得高效，并且团队越接近估计sprint中的所有任务所花费的时间越多越好。经验丰富的球队将比新手队更好。
时间估计的首选方法是在Scrum团队中使用Story Points。故事点是可以分配给每个任务的时间单位 – 通常，故事点是一个人工作的一天，但这是适应性的。大多数组织实际上使用相对大小来决定故事点。
在名为Planning Poker的过程中，团队成员估计每个故事或任务的故事点。这为每项任务分配了特定数量的工作和时间。
在计划会议的这个阶段之前，团队成员应该考虑：
- 他们在最后一次冲刺中提供了多少个故事点？这有助于设置在此sprint中可以完成多少工作的基线。
- 即将到来的冲刺计划是否有任何假期？这可以调整团队在冲刺中完成的总分数。
- 是否存在可能影响流程的重大里程碑/事件？这可能会影响可以交付的工作量。
然后该团队考虑冲刺速度目标。冲刺速度是完成冲刺所需的时间，并指示团队的开发能力。
在此尝试计划当前冲刺的速度时，查看团队的历史冲刺速度非常有帮助。通过将预测速度设置得过高，团队不应该过于雄心勃勃，这会让产品负责人（和团队）感到失望。
每个任务都会估计一段时间，通常是在故事点中，直到达到潜在的Sprint速度。通常，团队将首先从最高优先级的故事和任务开始，估计他们将花费的时间，然后继续使用较低优先级的故事和任务。
一些团队让每个成员负责故事或任务，估计故事或任务将采用多少故事点（或小时），然后比较他们的独立估计。如果估计数不够充分，则需要进行讨论。让让我们这样做：团队致力于工作和冲刺
这一阶段是Sprint Planning第二部分的最后一步。在将故事添加到Sprint积压工作之后，团队根据速度估算确定了什么适合冲刺，现在是团队承诺执行任务的时候了。
致力于工作是在逐个成员的基础上完成的。第二部分的这一部分由ScrumMaster提供便利，ScrumMaster审核每项任务并将其呈现给团队。
当提交任务时，团队成员自愿承担任务。如果多个团队成员承诺执行特定任务，ScrumMaster应该促进讨论（并且任务可能最终被共享）。
ScrumMaster通常以最高优先级的故事或任务开始，要求团队成员依次提交每个故障，然后在优先级较低的项目中继续执行优先级较高的项目。
通过这种方式，任务不会简单地分配给团队成员 – 团队成员必须前进才能接受任务。
这个承诺过程尽可能地对Scrum很重要。团队成员应该觉得他们做了一个
选择“拥有”某项特定任务，接受对其负责。
承诺过程有助于团队自治，确保团队可以对sprint的任务负责。自治对Scrum团队很重要，让成员选择承诺协助这个过程的任务。
一些低优先级的任务可能仍未提交 – 接近这个阶段的结束，并且由Scrum Master决定是否将它们分配给团队成员。如果这里有问题，团队应该讨论它们;任何团队成员都不应该公开强迫他们承担比他们认为他们在冲刺期间可以管理的工作更多的工作。
当Sprint积压中的所有故事和任务都已提交时，Sprint计划会话的第二部分结束。
为了获得额外的责任，每天都有一个站立式会议（Scrum），其中团队成员将他们所做的事情，他们将要做的事情以及他们面临的障碍联系起来。每日Scrum用于保持团队协调和正常进行。关于Daily Scrums的更多讨论可以在第5章找到。
该团队还通过在燃尽图上绘制完整的故事点来跟踪其进度。这些图表是设计的
显示团队在实现目标方面的表现。如燃烧图表所示，任何与预期速度的偏差都必须由ScrumMaster解决。
在Sprint计划会话结束时，团队应该能够检查表4-1中核对表中的所有项目。
| 表 4-1 | Sprint计划清单 |
| 清单项目完成？ | Y / N |
| 清除冲刺目标 | |
| Sprint Backlog中的积压项目（又名，故事） | |
| 每个故事/任务的接受标准 | |
| 估计的故事/任务 | |
| 团队成员对故事/任务的承诺 |
所有事情都被考虑：Sprint的最终评论
当Sprint完成后，会有一个Sprint结束时的审查会议。 ScrumMaster，Scrum团队和产品负责人都参加了。产品负责人还排列了几位可以参加的客户。
该过程如下：
- 在End-of Sprint会议上审查sprint的目标，以查看是否已满足sprint。
列出每个故事和/或任务及其验收标准，以查看是否已满足这些标准。 - Sprint的结果将呈现给产品负责人（以及可用的客户）。
理想情况下，这是所需产品的潜在可交付成果。产品负责人确定Sprint End-End Review的结果是否可接受。 - 如果一切都可以接受，则计算Sprint速度作为未来冲刺的指导。
内部审视CA Agile Vision
使用CA Agile Vision进行Sprint计划非常简单。本节将向您介绍CA Agile Vision的内部视图，以及如何将故事从待办事项拖动到sprint以及如何跟踪Sprint进度。
如何将故事移至Sprint积压
您可以轻松地从产品backlog创建Sprint积压。只需按以下步骤操作：
- 在“待办事项”页面中，显示要使用的项目的待办事项。
- 单击“显示Sprint”链接以显示Sprint待办事项，并过滤视图以显示要使用的sprint的待办事项。
- 选择您计划的发布，冲刺和团队。
- 从项目待办事项中单击并拖动用户素材，然后将其放入sprint backlog中
用户素材将添加到sprint backlog并分配给选定的团队。团队的速度反映了新故事给团队的分配。
您可以在图4-1中的CA Agile Vision中看到Sprint待办事项创建的示例。
跟踪Sprint进度
CA Agile Vision为您提供了许多方法来跟踪Sprint进度并在团队的所有成员之间共享该信息。团队成员，产品负责人和管理人员可以通过执行以下操作来监控sprint任务并跟踪团队成员进度：
- 在“CA Agile Vision仪表板”页面中查看Sprint进度图表和报告，在“Sprint详细信息”页面中查看用户故事和图表
- 查看和更新Sprint信息和用户故事详细信息页面中的注释和注释。
- 监控项目虚拟墙的进度（见第5章）
Sprint详细信息页面上的故事和图表显示了图表，以提供冲刺进度的综合报告。视图可以通过项目，sprint和团队进行过滤。
例如，Sprint燃尽图表比较了团队在用户故事上燃烧的实际小时数与sprint的预期燃尽率。
x轴显示sprint中的天数。包括周末在内的所有日子都被视为有效的工作日。 y轴显示sprint中的任务小时数。剩余实际小时数显示为绿线。预期的燃尽或指南以红色显示。线上的每个点都是表示冲刺中一天的数据点;你可以在图4-2中看到一个例子。
