你一定要知道的关于Scrum的30个问题

1.敏捷Scrum如何开始？

为了成功实施Scrum，团队必须坚持Scrum的基本要素。

• 团队必须理解Scrum的规则

• 团队成员必须学习Scrum的基本机制

• 给予足够的时间

• 不要在项目中途实施Scrum

• 保证为持续学习分配时间

要知道Scrum是一个框架，提供的是一整套规则，而不是一个指南。

2.如何自下而上实施？

• 取得大家的支持

• 耐心：让其他人领悟你已经理解的东西，找到其他人的动机

• 提供信息

大部分的Scrum都是自下而上实施的，也就是领导没有特别强硬的推行，而是团队内部觉得这种框架很合适，于是在自己团队内做尝试。

3.资源冲突如何解决？

有的公司项目多，人力不足，特别是资深的经验丰富的人比较缺乏。

• 依赖于管理层的支持

• 长时间在小范围内做尝试

• 选择核心团队，并决定需要哪些专家

• 小心团队顾问过度承诺

• 计划可能的空闲时间

• 顾问团队不应该替代专职团队，应该是一个核心的团队，辅以顾问团队。

4.如何确定团队的速率？

确定团队的速率一般有三种方法：历史数据、走着瞧、猜测。

• 对于组建的团队，熟悉的技术：优先选择历史数据，其次选择走着瞧，最后选择猜测

• 对于已组建的团队，不熟悉的技术：优先选择走着瞧，其次选择历史数据，最后选择猜测

• 对于新成立的团队，熟悉的技术；以及新成立的团队，不熟悉的技术：优先选择猜测，其次选择历史数据，最后选择走着瞧。其中历史数据可以，依赖于其他团队的历史数据。

5.Scrum的三大角色如何平衡？

Scrum的三大角色，包括关于Scrum Master，Product Owner以及团队成员。

虽然有人不赞成Scrum轮值，认为不够专注，但是我尝试过。

6.如何确定Spring长度？

一般建议是1~4周。而长还是短是与项目、团队等多种因素决定的，各有利弊。

长周期的Spring，意味着需要更长的时间才能发现风险，但好处是互动干扰会少一些。

7.Sprint完成的标准？

制定并发布一个DoD。

• 有助于团队成员建立密切联系

• 为项目干系人提供清楚的交流方式，间接降低了把技术债务推迟到项目后期的风险

• 使团队保持正确的方向，保持专注

8.Scrum Master到底做什么？

Scrum Master主要职责有：

• 消除障碍，解决问题

• 结束争论当团队的保姆

• 报告团队的行为表现

• 引导并在必要时提供帮助

• 教育组织并驱动组织变革

也许这也是为什么大部分人都建议Scrum Master要专职的原因吧。

9.真正的Scrum应该包含的实践有哪些？

我觉得如果下面这几点缺少了一个，就不能称之为Scrum了。

• 测试驱动开发TDD

• 持续集成：团队成员频繁地集成他们的工作，通常每个人每天至少集成一次，这样每天就有多次机场。每次集成都通过一个自动化构建，包括测试来尽快检测错误。团队可在任何时间构建发布。

• 结对编程：一人驾驶一人导航，一起工作，共同完成一个任务。

• 自动化集成与验收测试：集成测试是用来测试系统中各种集成点，验收测试用来模拟用户行为的测试

10.团队成员工作时间不一致，如何处理？

现在很多公司为了提倡人性化，对于员工上班时间不做强制规定，也就是所谓的弹性制。

11.什么是发布计划？

一般来说Scrum都是有节奏的进行发布。

• 沟通和交流，并且要频繁

• 每个Sprint后都更新发布计划

• 努力做优先级最高的条目

• 更新对大条目的估计

• 每个Sprint都交付可工作的软件

12.何时进行故事分解？

我有时候会被问及，这个故事足够小了吧，是否还需要拆得更小？要拆到多小才合适？

• 团队能够用故事点来评估产品列表吗？

• 产品列表中的故事是否清楚定义了？

• 故事是否精确？

• 我是否对这个故事有足够的了解？

13.Scrum的缺陷管理方式是怎样的？

首先和其他框架一样，我们需要为缺陷区别等级：

• P0灾难：主功能无法使用且没有可行的变通方案

• P1高：主功能不可用，但有变通方案

• P2中：系统的使用性受损

• P3低：影响较小，无关紧要或不便利，可以等到下次产品发布时解决

如果是P0或者P1级别，那发现者及其搭档有一个小时来完成以下任务：

• 停止手上当前任务

• 确定该缺陷的根本原因

• 修复

• 更新所有测试

• 生成或重新构建验证测试

• 保证所有测试都能通过

• 提交代码

• 向前逼近一步，至少到集成环境中验验证

如果能一个小时完成则无需记录，如果不能完成：

• 在一个小时结束时停止

• 在缺陷管理系统中记录

• 继续修复

• 完成并关闭缺陷

• 更新Sprint列表及小时数

14.如何处理遗留系统的维护工作？

很多时候，我们在进行新功能开发的同时，还需要兼顾遗留系统的维护工作。

• 专用时间

• 专职团队

15.为何要组织demo会？

在每个Sprint的最后一天，Scrum Master需要组织Demo会议。

16.为何要组织回顾会？

我不止一次的听人抱怨，回顾会就是浪费时间的检讨大会。

17.为何要组织每日站会？

同样的一个问题，很多人说每日站会太浪费时间，而且站着开很累。

18.每日站会上的第四个问题是什么？

我们都知道每日站会上需要问三个问题：

其实还有第四个问题是：

第四个问题可以避免团队成员在不愿意面对冲突的情况下表达自己的意见。

19.结对编程有哪些玩法？

结对编程能够在相对较短的时间内产生高质量的软件。

• 无序结对编程

大家交换结对

图片发自简书App

• 微结对

  

  图片发自简书App

  

  图片发自简书App

20.如何让新人快速融入团队？

第一步，选对人。

第二步，帮助新成员学习而制定测试。

• 描述系统架构

• 为何结对和TDD很重要？

• 谁拥有代码所有权？

21.如何应对与团队格格不入的新成员？

有的时候我们把一个人招进来后却发现这个人与团队格格不入，并不是说这个人的能力有什么问题，而是他会给团队带来负面的影响。

有一个概念叫做社会异常，就是违背以确立文化规范的行为做事方式。

那怎么办呢？

22.Sprint可以取消吗？

当有异味影响到团队实现Sprint目标能力时，可以：

一般我们不会建议你取消Sprint的，而是尽力去消除障碍或者获得帮助。

23.Scrum如何看待加班？

Scrum一致强调“可持续”。

24.如何保证每次交付可工作的软件？

记得多年前，小婧所在的团队做一个模块，计划半年后交付。

后来和公司的敏捷教练交流这件事情的时候。

那应该怎么处理呢？

也就是说，之前我们应该一上来就规划开发核心故事，而不支持可配置的功能。

还有一种方式，可能会适合于互联网软件，就是控制用户数。

无论如何都应该从风险最大的功能开始，避免后续发生风险后失控。

25.如何优化Scrum的效率？

我们都知道在时间管理的话题中有一项非常重要的工作是：时间记录。

对于Scrum提升效率也是如此，你需要知道自己每类工作的花费，才能更好的提升效率。

• 功能工作：向用户交付商业价值的功能

• 额外工作：企业服务或强制要求，比如审核或会议

• Spike穿刺：研究类工作

• 必要性工作：要达到完成标准需要做的工作

26.利用Scrum如何进行项目成本估算？

一般来说我们估算一个项目的成本有几种方式：人天、功能数。

• 生成用户故事：列出带评估项目的所有用户故事。

• 确定用户故事的优先级：按照优先级由高到低，逐一排列。

• 估算用户故事的大小：主要是为了是确定速率。计算所有用户故事的总点数。以以往的速率计算需要多少人在规定时间内能完成。

• 确定团队的成本：上一步得到的人数，乘以团队平均工资等成本。

• 计算项目的成本

• 承诺是否能做

27.Scrum后就不用写文档了吗？

有好多人说，我们是Scrum，我们不需要写文档，只有你们瀑布才会要写那么多文档。

也就是说，首先我们需要决定，项目需要什么什么文档以及什么时候做文档最有意义。

28.外包与离岸开发要注意什么？

不管相距多远都要营造出一种氛围，让大家觉得是在同一个地方，工作的同一个团队。

• 选择合适的离岸团队：雇佣敏捷团队，并且时差小于三个小时

• 以痛苦最小的方式分配工作：

• 坚持Scrum框架

• 建立团队文化

• 持续集成

• 准备差旅

• 配合一个项目或团队协调人

以下情况建议绝不考虑离岸：

• 高度复杂技术高风险的第一个发布

• 本地团队还在挣扎于开发实践如TDD等，或缺乏纪律

• 公司没有成功必备的差旅预算和远程沟通技术的预算

29.大型列表如何进行优先级评定和估算？

像一般开发周期在3个月以上，涉及三类以上干系人的项目，其Story的数量和复杂度是非常可观的。

30.你见过这样的合同吗？

一般来说，软件合同分成：固定总价合同和人天合同。

而Scrum给了我们另外一种合同的可能。

接下来如果签“项目合同”，则是分Sprint签订、给钱。

但是我觉得要做到这点，真的是需要使用Scrum框架的每个实践，保证每次交付都是可用的软件。