Salesforce 生命周期管理（二）Agile & Scrum 浅谈

本篇参考：

https://trailhead.salesforce.com/content/learn/modules/salesforce-agile-basics

https://www.scrumcn.com/agile/scrum_guide.html

https://www.scrum.org/resources/what-is-scrum

https://www.atlassian.com/software/jira

前几天刚考完 development and lifecycle，其中有一部分就是敏捷的内容，加上现在项目基本上也基本严格遵循着Scrum框架进行项目开发管理，所以顺便整理一下基础知识。这种知识网上一堆，感兴趣的可以去官方或者更详尽的地方查看，自己只是整理一下，好记性不如烂笔头，用于自己后期好好的理解理解，自己学习一下。

一. Agile & Scrum 框架

Plan vs. Adapt: 世界上唯一不变的就是变化本身，项目也是，随着客户的需求不断地清晰不断调整，或者产品项目上线以后用户反馈不断的完善，需求和迭代也是不断的增强和完善。salesforce本身就具备了很多的feature和tool，也特别适合快速原型去构建项目，然后不断的迭代，所以salesforce的项目，大部分都是基于敏捷的模式来开发。

接下来说 Scrum， Scrum只是实现敏捷模式的一个主流的框架。我们可以先通过英语单词来认识一下。

橄榄球比赛的特点： 多人合作，技术复杂、战术多样，通过运用个人技术的相互配合，以达攻守的目的。引申到项目，项目中也会面临着需求不清晰，需求变更等复杂的场景，使用传统开发的模式，敏捷性不够，无法做到在瞬息万变的今天达成更好的交付。通过Scrum的框架的好处是在不断的小的周期中总结分析问题，从而更好的进行迭代和交付。

二. Scrum框架的335

我们官网也好或者随便百度一下 Scrum的内容，通常都会发现一堆的文章描述 Scrum的原则，价值观以及335。这里就只是提一下335，因为实际项目中了解好这些确实可以更好的带入。

3个角色： PO（产品负责人），Scrum Master(敏捷大师)，Dev Team（开发团队）
3个工件(artifact)： Product Backlog， SprintBacklog， Increment
5个事件：Sprint，Sprint Plan Meeting，Daily Standup Meeting， Review Meeting， Retrospective Meeting（Sprint回顾会议）

1. 三个角色

PO（产品负责人）：产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨织、Scrum 团队和团队成员个体的不同而有所不同。
产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：

• 清晰地表述产品待办列表项；
• 对产品待办列表项进行排序，使其最好地实现目标和使命；
• 优化开发团队所执行工作的价值；
• 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及确保开发团队对产品待办列表项有足够深的了解。

产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。
产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。实际项目中，PO最常见的是甲方的IT负责人或者IT人员。

Dev Team（开发团队）：开发团队具有下列特点：

• 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
• 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
• Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。

Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。当然，这些都是理论上的场景，实际场景大家都清楚。

Scrum Master（敏捷大师）： 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master 以各种方式服务于产品负责人，包括：

• 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域；
• 找到有效管理产品待办列表的技巧；
• 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
• 理解在经验主义的环境中的产品规划；
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
• 理解并实践敏捷性；以及，按要求或需要引导 Scrum 事件。

Scrum Master 以各种方式服务于开发团队，包括：

• 在自组织和跨职能方面给予开发团队指导
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按要求或需要引导 Scrum 事件；以及，在 Scrum 还未完全采纳和理解的组织环境中指导开发团队。

Scrum Master 以各种方式服务于组织，包括：

• 带领并指导组织采纳 Scrum；
• 在组织范围内规划 Scrum 的实施；
• 帮助员工和干系人理解并实施 Scrum 和经验产品开发；
• 引发能够提升 Scrum 团队生产率的改变；以及，与其他 Scrum Master 一起工作，增加组织中 Scrum 应用的有效性。

理论上 Scrum可以由一个PM担任或者一个团队成员担任，而且 Scrum和PO不能为同一个人，因为PO代表客户的利益，Scrum用于做各方协调工作。但是实际场景中，可能PO和Scrum作为了同一个人，官方会讲述这两种如果都是一个人是不正确的，但是实际的场景还是要应了开篇的话语： 计划 VS 适应~~~

2. 三个工件

Product Backlog（产品待办列表）： 产品待办列表由 Product Owner 负责维护，包括增删及优先级,用户故事是其中一种最佳实践,每项需求都需要描述其外部价值，是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。产品待办列表永远是不完整的。我们经常在项目中听到的更加熟悉的名字： user story。产品待办列表我们可以理解成拥有外部价值的一些 user story的集合。

产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精化过程中，产品待办列表项被重新评审和修改。Scrum 团队决定如何来完成精化以及何时来完成。

SprintBacklog： 排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容和更详尽的细节信息就能做出更为准确的估算；同样，排序越低，则细节信息越少。一个项目可能几个月或者更长时间，我们不可能无序的对产品待办列表进行开发，而是将这个项目周期按照指定周期切割成多个小周期，每个周期按照优先级和资源做相关的产品列表里面的user story，每个sprint所作的product back log即可以理解成 sprint backlog.

Increment（可交付产品增量）: 产品待办列表项中那些即将会占用开发团队下一个 Sprint 大部分时间的项会被加以精化，因此，任一产品待办列表项都能够在 Sprint 的时间盒期限内适当地“完成”。这些能够被开发团队在一个 Sprint 中“完成”的产品待办列表项称为 Increment。

3. 5个事件

Sprint翻译成什么？ 冲刺、 迭代、周期？？？无所谓

Sprint 是 Scrum 的核心，其长度（持续时间）为一个月或更短的限时（按需可以设置1周到4周不等），这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。每个Sprint都可以作为一个小项目来对待，就如同项目一样，Sprint 被用于完成某些事情。每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。之所以将Sprint设置在一个月内，是因为当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个月的成本上。

Spring Planning Meeting（Sprint 计划会议）

	Sprint Planning
Why	Sprint 中要做的工作在 Sprint 计划会议中来做计划。
Who	Scrum团队（包括开发团队、ScrumMaster以及产品负责人）
When	Sprint开始
What/How	Part1 - 开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该 目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。在 Sprint 计划会议中，Scrum 团队还草拟一个 Sprint 目标。 Part2 - 在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定 如何在 Sprint 中把这些功能构建成“完成”的产品增量。开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。
How Long	一个月（4周）的Sprint上限是8小时；2周的Sprint上限是4小时等
Input	产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预测以及开发团队的以往表现。
Output	Sprint 目标、Sprint待办列表

Daily Scrum Meeting（每日站会）

	Daily Scrum
Why	开发团队展示进度；开发团队每日检视进度，并根据具体情况进行调整。
Who	开发团队
When	每日 Scrum 站会在同一时间同一地点举行
What/How	在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队 协作和性能。每日站会可能会回答如下3个问题（举例）： • 昨天，我为帮助开发团队达成 Sprint 目标做了什么? • 今天，我为帮助开发团队达成 Sprint 目标准备做什么? • 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?
How Long	15分钟为上限(不同人数不同项目时间不确定)
Input	Sprint目标，及每日工作进展
Output	更新后的Sprint待办列表，及问题（风险）更新

Sprint Review（每个Sprint结束以后的demo等）

	Sprint Review
Why	检视所交付的产品增量并按需调整产品待办列表。演示增量的目的是为了获取反馈并促进合作。
Who	Scrum团队（包括开发团队、ScrumMaster以及产品负责人）及干系人
When	Sprint 快结束时举行
What/How	Sprint 评审会议包含以下内容: • 产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议; • 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”; • 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的; • 开发团队演示“完成”的工作并解答关于所交付增量的问题; • 产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的目标交付日期(如果有需要的话); • 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下来的Sprint 计划会议提供有价值的输入信息; • 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变; 同时，为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
How Long	一个月（4周）的Sprint上限是4小时；2周的Sprint上限是2小时等
Input	Sprint内“完成”的产品增量，Sprint待办列表，产品待办列表
Output	更新后的产品待办列表

Sprint Retrospective（Sprint 回顾会议）

	Sprint Retrospective
Why	Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。Sprint 回顾会议的目的在于: • 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何; • 找出并加以排序做得好的和潜在需要改进的主要方面; 同时制定改进 Scrum 团队工作方式的计划。
Who	Scrum团队（包括开发团队、ScrumMaster以及产品负责人）
When	Sprint 评审会议结束后，下一个Sprint计划会议前
What/How	回顾会套路：1. 设定场景2. 收集数据3. 产生洞察4. 决定做什么（行动计划）5. 结束
How Long	一个月（4周）的Sprint上限是3小时；2周的Sprint上限是1.5小时等
Input	Sprint内的数据（客观数据和主观数据）
Output	下一个Sprint要实施的改进行动

简易版流程：

1. 已经拥有产品backlog清单
2. 进行SPRINT的计划会议，根据计划会议，确定当前的这个 SPRINT的BACKLOG
3. 每日站会，对当前SPRINT的story进行状态追踪；
4. SPRINT Review会议时，针对潜在可交付产品增量进行demo
5. Sprint Retrospective会议，对当前sprint遇到的问题以及scrum的改进意见等进行讨论和不断的总结

详细版

项目启动以后，BA通过和PO以及 stakeholder不断的梳理需求以后，梳理 / 重新定义/ 变更 Product Backlog

定义 Sprint周期，比如每两周一个 Sprint周期，每个Sprint开始会进行 Sprint Planning Meeting，根据优先级等属性，来将 Product Backlog内容排期到当前的 Sprint Backlog中，并进行assign以及打分等

Daily Scrum会议上，DEV团队对各自的story进行进度介绍和更新以及问题暴露，Scrum Master/PO针对block的问题找到相关的suggestion或者配合的部门等来解决问题。

随着 Sprint的不断进行，潜在“完成”的产品增量成果物将不断的产出

Sprint Review会议上，可以对完成的成果物进行demo等。

Sprint Retrospective会议上，对这个 Sprint 中遇到的问题，流程上等问题以及好的地方进行整理总结；

进行下一个Sprint周期，重复上述的操作。

我们可以使用Jira来作为Scrum的管理工具，Jira的kanban也更好的去展示user story的状态，当然，jira的功能远远不止于此，感兴趣的可以免费注册1个月账号。可以在jira上维护 product backlog以及sprint的sprint backlog，然后通过teams来进行约会议实现上面的几个scrum事件。

比如，我们进行两周一次的sprint，每周三的早晨９点进行Sprint Plan Meeting，在Sprint Plan Meeting中，我们将Product Backlog中的内容，按照优先级以及resource情况进行排期，添加或者删除当前的 sprint backlog。每天早晨9点也进行daily meeting，每个团队成员去汇报 sprint backlog的status，以及block内容需要协调等等信息。针对状态是完成的user story，我们可以隔一周的每周二的下午3点到5点进行 sprint review meeting，当然，我们也可以将retrospective meeting和review meeting一起开，演示一下demo，并且看一下当前 sprint还有哪些没有完成以及后续的操作。从而保证风险控制在两周以内，也可以尽快的tracking整体的项目进展和风险状态。

三. 针对 lifecycle　scrum常见考题

What is a main characteristic of an agile team?
A. The team uses Scrum, Kanban, and Extreme Programming.
B. The team has biweekly sprints to ensure on-time delivery.
C. The team delivers new releases on dates defined in the beginning of the project, following a
project plan
D. The team improves and evolves its processes and frequently delivers value to the endusers.
Answer: D
 
分析：　敏捷团队的特性是改进和发展其流程，可以频繁的交付有价值内容给终端用户

Universal Containers (UC) is embarking on a large program of work, with different projects and different vendors. UC created a center of excellence (COE) that is struggling with scope creep between the different projects.
What role should the architect suggest be added to the COE?
A. Scrum master
B. Release managers
C. Product owner
D. Change managers
Answer: A
 
分析：　可以查看文中的敏捷大师的用处

总结：篇中很多的内容都是ｃｏｐｙ了参考的链接内容，结合着自己的目前的实际项目管理模式进行了一些的自己看的懂的总结。主要针对后期自己去学习使用。篇中有错误地方欢迎指出，有不懂欢迎留言。