项目管理 之二 敏捷开发方法 Scrum 最全指导

??接受项目管理培训至今已经有三年时间了，一直没有机会来整理一下自己在项目管理方面的学习历程和经验。好记性不如烂笔头，从今天开始就一步一步分享一下我在项目管理方面的学习历程以及一些在工作中累积的经验，希望可以帮助到从事项目管理的人！

历史

• 1986 年，竹内弘高（Hirotaka Takeuchi）和野中郁次郎（Ikujiro Nonaka）在 《哈佛商业评论》（Harvard Business Review）杂志上发文《新型的新产品开发策略》（The New New Product Development Game），文中阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：

  • 他们将这种新的整体性方法与橄榄球相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而团队“作为一个整体前进，把球传来传去”。
  • 他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究，提出了一种提高速度和灵活性的商业产品开发新方法。

  该文章可以在 https://hbr.org/1986/01/the-new-new-product-development-game 查看

• 1995年，在德克萨斯州奥斯汀举办的业务对象设计和实现研讨会（ Object-Oriented Programming, Systems, Languages & Applications ’95 (OOPSLA ’95) 的一部分）上，萨瑟兰（Sutherland ）和施瓦伯（Schwaber）联合发表了论文首次提出了Scrum 概念。在接下的几年里，Schwaber 和 Sutherland 合作将这些材料与他们的经验和不断发展的良好实践相结合，形成我们现在所知的 Scrum。

• 2001 年，施瓦伯（Schwaber）与麦克·比窦（Mike Beedle）合著了《Agile Software Development with Scrum》一书，介绍了 Scrum 方法

• 2002 年，Schwaber 和其他人成立了 Scrum 联盟，并建立了 Scrum 认证系列。Schwaber 在 2009 年末离开了 Scrum 联盟，并创建了 Scrum.org 来监督平行的专业 Scrum 认证系列。

规范

??2010 年，Schwaber 和 Sutherland 发布了名为 《The Scrum Guide》 （ Scrum 指南）的公共文档。该文档给出了对于 Scrum 的的各种定义，可以说是 Scrum 的官方指导规范。该指南的官方 址：https://www.scrumguides.org/index.html

Scrum.org

• 使用 产品待办事项列表（Product Backlog） 来管理产品需求，它是按优先级排序的需求列表。
• 在每次迭代中，Scrum Team 都会从 Product Backlog 中选择优先级最高的需求进行工作。
• 在 Sprint 计划活动中对所选择的需求进行讨论、分析和评估，以获得相应的迭代目标和交付计划，我们称之为 Sprint Backlog
• 在迭代中，每天都有一个固定的 Daily Scrum 。在每次迭代的最后，Scrum Team 都会邀请业务人员和利益相关这来评审潜在的产品交付成果。
• 通过 回顾会议来总结并准备下一次迭代

Scrum 的英文意思是橄榄球运动的一个专业术语，表示 “争球” 的动作；把一个开发流程的名字取名为 Scrum，相当于大家像打橄榄球一样迅速、富有战斗激情。而 Scrum 就是这样的一个开发流程。

??据 统计，在 Scrum 的帮助下交付的项目的总体成功率是 62%。Scrum Alliance 对近 5000 人进行了关于 Scrum 使用情况的年度调查。以下是 Scrum Alliance 2015 State of Scrum Report 提供的 4 个统计数据：

Scrum Roles

??Scrum 当中定义了许多角色。Scrum 具有三个致力于项目的核心角色，分别为 产品负责人（Product Owner）、流程管理员（Scrum Master）、开发团队（Development Team） 。

• 猪组的成员： 在 Scrum 过程中全身投入项目的各种人物，他们在项目中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。例如：产品负责人（Product Owner）、Scrum 主管（Scrum Master）、Team
• 鸡组的成员： 鸡仅仅是通过蛋参与，并不是实际 Scrum 过程的一部分，但是必须考虑他们。例如：用户、经理、利益相关者（客户，提供商）

需要注意的是：

1. 角色不是职位。因为 scrum 的本质是经验主义、自我组织和持续改进，所以这三个角色仅仅是给出了责任的最小定义。
2. Scrum 对于团队中成员的个人能力要求比较高

流程管理员（Scrum Master）

??Scrum Master 确保 Scrum 团队遵守 Scrum 价值、实践和规则，保证项目按照 Scrum 的要求顺利实施和进行。Scrum Master 是清除障碍的人，比如解决团队对外部的硬件或者软件依赖问题；需要其他团队的支持问题；需要工具的支持等。Scrum Master 是变革代言人，要促成组织内部人员转变思维，迎接敏捷开发方式，改变项目经理过去安排任务的习惯；改变团队成员等着分配任务习惯；引进新的测试工具；推进更多的敏捷实践到团队。

• Scrum Master 本身可能也是开发人员。
• Scrum Master 不对 Scrum 团队进行管理及决策，团队是自组织的。
• ScrumMaster 绝对不能是产品负责人

产品负责人（Product Owner）

??产品负责人（Product Owner）代表客户的声音。该人员被授权制定关于产品的全局决策、维护产品待办事项列表、定义所有待办事项列表项并确定优先级。确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资 酬率负责。
??沟通是产品负责人的核心职责。 传达优先级和传递团队成员和利益相关者的能力对于将产品开发引向正确的方向是至关重要的。产品负责人的角色是团队和干系人之间沟通的桥梁，是团队干系人的代理，也是整个干系人 区的团队代表

• 一个 Scrum 团队应该只有一个产品所有者（尽管一个产品所有者可以支持一个以上的团队），且不应将此角色与 Scrum 管理员的角色相结合。
• 对于商业开发，产品负责人可能就是产品经理。对内部开发而言，产品负责人可能来自其业务会被该产品自动化的职能部门经理。
• 产品负责人可以是团队成员，承担开发任务。但是这样可能会牵掣其精力，影响产品负责人和利益相关人协调工作
• 产品负责人绝对不能是 Scrum Master。

开发团队（Development Team）

??Scrum 的基本单位是一个小团队，由产品负责人（Product Owner）、流程管理员（Scrum Master）和开发人员（Developers）组成。好多文章中也称为 Scrum Team，都一个意思。团队是 自我管理的，跨职能的，并且一次只关注一个目标：产品目标。
??Scrum Team 执行软件产品在 Scrum 规定流程下的开发工作，人数控制在 5 ~ 10 人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到 Sprint 的目标。
??团队同时是跨职能的；团队成员必须具备创造产品增量所需要的技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。简单来说，开发团队并不等于开发工程师，开发团队可以由各种各样的人组成，包括设计师、文档工程师、程序员等。

• 团队同时是自组织的。任何人，包括 ScrumMaster 都没有权利规定团队如何将产品待办事项列表转化成可交付的功能增量，而是由团队自己确定。
• 团队的构成在 Sprint 结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。
• 团队中没有头衔（职位）的概念
• 团队不允许包括测试或业务分析等在特定领域工作的子团队
• 架构师或设计人员而不愿意编码的人不适合成为团队成员

Artifacts

??Scrum 的工件代表了工作或价值，为检视和适应提供了透明度和机会。Scrum 定义的工件是专门设计来最大化关键信息的透明度的，这样每个人都能对工件有相同的理解。

Product Backlog

??产品待办事项列表（Product Backlog）是对待完成工作的分解，包含 Scrum 团队维护的产品需求的有序列表。常见的格式包括用户故事（User Story） 和 用例 。
??产品负责人负责为团队制定产品待办事项列表项，只有在产品负责人同意的情况下才可以更改。产品负责人根据风险、业务价值、依赖关系、大小和所需日期等考虑因素，对产品待办事项安排优先级。
??若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用产品待办事项列表的特征对条目进行分组。分组可以根据特性集、技术或架构进行。这也是 Scrum 团队经常采用的一种组织工作的方法。

• 由 Product Owner 负责维护，包括增删及决定优先级。
• 用户故事是其中一种最佳实践。
• 每项需求都需要描述其外部价值。

用户故事（User Stories ）

??在软件开发和产品管理中，用户故事是对软件系统的一个或多个特性的非正式、自然的描述。用户故事是敏捷软件开发中用来从最终用户的角度获取软件特性描述的工具。用户故事描述了用户的类型，他们想要什么以及为什么。 用户故事有助于创建对需求的简化描述。

??一般来说，Epic 是要开发产品的宏观功能。史诗还可以描述为按类别或主题分组的多个用户故事集合。在实际开发中，我们可以将某些任务划归为一个大的目标：里程碑。

Task（任务）

??任务（可能还有子任务）是帮助响应用户描述的技术活动。理想情况下，这些活动应该是相同的规模（从工作复杂性的角度来看），但可能具有不同的性质：设计、开发、测试等。在当下各种互联 项目管理工具（绝大多数是依据 Scrum 的）中，Task 是处理的最小单元。

Sprint Backlog

??Sprint Backlog 是团队在下一个 sprint 中必须处理的工作列表。这个列表是由 scrum 团队根据优先级顺序从产品待办事项列表的顶部逐步选择产品待办事项列表项，直到他们觉得有足够的工作来完成 sprint。

• 由团队评估和选择 Product Backlog 中哪些放入Sprint Backlog。
• 团队需要一起定义 “完成” 的标准。

Product Increment

??可交付产品增量（Product Increment）即 sprint 结束后可对外发布的产品功能增量部分，也被称着 “潜在可交付的产品增量”（Potential shippable product increment, PSPI）。它由所有已完成的 sprint 待办事项构成，并与所有先前 sprint 的工作集成在一起。
??每个 Sprint 能否生成满足质量定义的 PSPI 是 Scrum 执行效果的试金石。因此这里关键的是团队内有一致同意的 DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。同样，随着时间推移，团队 DOD 内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。

Sprint planning

??Sprint 计划会议制定迭代计划。Sprint 计划会议会在 Sprint 一开始召开。产品负责人和团队将共同决定将在这个 Sprint 完成那些故事。

• 确定 Sprint 的目标
• 对产品 backlog 中 item 进行估算，以作为是否放入下期的参考。
• 对于需求不清楚的 item，请 Product Owner 说明。
• 输入是 Product backlog
• 输出是 Sprint backlog

评估（Estimation）

??评估是由整个团队在 Sprint 计划会议上完成的。评估的目标是根据优先级和团队在 Sprint 时间范围内交付的能力来考虑 Sprint的用户故事。Scrum 团队负责产品增量的交付，因此需要根据产品增量的大小和所需的工作，谨慎地为 Sprint 选择用户故事（即生成的 Sprint Backlog）。

??传统的 IT 项目中，往往使用“人天”来作为工作量评估的量词。在软件项目开发经典著作《人月神话》中，明确的指出了按“人月”或“人天”来评估需求工作量的巨大弊端，主因之一就是在于这个词让人产生了“可以使用更多的开发人员就可以更快速的完成软件开发”这一错觉。

用户故事点（User Story Points）

??产品增量的大小是根据 用户故事点（User Story Points） 来估计的。Scrum 对用户故事的评估是根据每个用户描述的困难程度来进行的。为了评估困难程度，使用了一种特殊的度量衡（尺度）。Scrum 评估中使用了几种类型的尺度。下面是一些例子

• 数字大小 (1 到10)
• T 恤的 码大小 (XS, S, M, L, XL XXL, XXXL)
• 斐波纳契序列 (1, 2, 3, 5, 8, 13, 21, 34, etc.)
• 狗的品种 (吉娃娃,………,大丹犬)

这些度量衡就被称为用户故事点（User Story Points）（其实就是对于用户故事难度的一个抽象值）。至于选择哪一种抽象方式，就需要根据团队的适应程度来决定了。最常用和最流行的评估技术是基于斐波那契数列规划扑克。

规划扑克技术（Planning Poker Technique）

??在规划扑克估算技术中，用户故事的估算是通过玩规划扑克得出的。 整个 Scrum 团队都参与其中，并且可以快速但可靠地进行估算。所谓的计划扑克（Planning Poker）是一种标有斐波那契数列数字的扑克牌。上面标的数字就表示用户故事点（User Story Points）。具体玩法如下：

1. 其中一个团队成员当主持人。主持人阅读正在进行评估的用户故事的描述。如果有人有任何疑问，产品负责人则需要给与解释。
2. 剩余人员每人一副牌，私下选择一张代表自己的评估的卡片（不受其他人干扰）。所有人员选择完毕后，大家同时将自己的卡牌翻过来，以便所有的团队成员都能看到每个评估。
3. 在第一轮中，大家的估计（选择的牌上的数字）很可能会有较大的差距。 选择了最高和最低估计量人员需要说明估计的原因。 应该注意的是，所有的讨论都是为了理解，没有什么是针对个人的。主持人必须确保这一点。讨论结束后，每个人收回自己原来的牌，重复上一步。

重复这个过程，直到估算收敛到一个可以用于故事的单一估算。最后将所有人的评估点数加起来就是这个用户故事最终的故事点。评估的轮数可能因用户描述的不同而不同。在评估中，每个成员必须清楚的认识到以下几点：

1. 不是轮流出牌，而是大家考虑好之后同时出牌，这样就可以避免后出牌的人被先出牌的人干扰
2. 他们需要估计所有的是这个用户故事，而不仅仅是他们自己将要做的那些部分
3. 数值越大，表示用户故事难度越大

Daily scrum

??又名 Sprint Daily Standup，每日站会，在 15 分钟以内，团队成员相互交流任务的进展，计划以及是否遇到困难。Scrum Master 要确保团队举行每日例会，团队则负责召开会议。

• 回答 3 个问题
  • 本次会议之前，我做了哪些事情/li>
  • 本次会议之后，我准备做什么事情/li>
  • 目前我是否碰到障碍，阻碍我达成目标/li>
• 每天 15 分钟
• 不是深入的问题讨论
• 每天固定时间召开，同一地点进行

??然而，在实际开发过程中，该活动往往会难以正常进行。在最初运行阶段，还可能严格按照 Scrum 方式进行，在试运行一段以后，就会发现大家的参与度非常低，经常是 Scrum master 和发言者进行交流，其他人基本上都游离在外。这就需要我们自己制定一些符合自己团队的措施了！

Sprint review

??Sprint 评审会议发生在 Sprint 将要结束的时候，团队、产品负责人和 Stakeholder 一起评审本次 Sprint 的产出是否如何预期，可以被接受。

• 团队全体参与
• 邀请相关干系人参与
• 2 – 4 小时
• Product Owner 可以拒绝接收成果

Sprint retrospective

??这个回顾会议发生在 Sprint 的最后，由 Scrum Master 负责召集团队召开。会中大家会回顾和小结这个 Sprint 的好的地方以及有那些不足。保证团队能够持续改进，不断提高。回顾会议旨在对前一个 Sprint 周期中的人、关系、过程和工具进行检验。

• Sprint 评审会结束后召开
• 时间 2 – 4 小时
• 团队全体参与

Scrum 价值观

理论

??Scrum 基于测试过程控制理论(经验过程，或所谓的经验主义)。经验主义认为，知识来自于当前已知情况下的实际经验和观察。(注意，它不同于教条主义，不同于完全基于过去经验的固定思维，不同于忽略理论指导的部分经验主义)。Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险。Scrum 是一种反馈驱动的经验方法，与所有经验过程控制一样，它由 透明度、检视和适应 这三个支柱支撑。

• 透明： 过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。
• 检视： Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。
• 适应： 如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进一步的偏离。

价值观

这三个支柱需要团队的信任和开放，而下面的 5 个 Scrum 价值观则是个保证。