你一定要知道的关于Scrum的30个问题
Scrum
1.敏捷Scrum如何开始？
为了成功实施Scrum，团队必须坚持Scrum的基本要素。
- 团队必须理解Scrum的规则
- 团队成员必须学习Scrum的基本机制
- 给予足够的时间
- 不要在项目中途实施Scrum
- 保证为持续学习分配时间
要知道Scrum是一个框架，提供的是一整套规则，而不是一个指南。
小婧以前觉得我可以把Scrum中的一部分拿来实施，其他的比如结对编程、重构等不纳入也就不纳入了。
近些年发现自己错了。
因为Scrum框架的各个部分是相互支撑的，如果你进行裁剪，不是倒塌就是变成了另外一个东西，不是Scrum了。
所以在实施Scrum的时候一定要先明确和学习Scrum的规则和机制。
2.如何自下而上实施？
- 取得大家的支持
- 耐心：让其他人领悟你已经理解的东西，找到其他人的动机
- 提供信息
大部分的Scrum都是自下而上实施的，也就是领导没有特别强硬的推行，而是团队内部觉得这种框架很合适，于是在自己团队内做尝试。
这个时候你就要特别注意，一定要及时的向外部，特别是领导层汇报项目的进展情况，使得信息透明。
3.资源冲突如何解决？
有的公司项目多，人力不足，特别是资深的经验丰富的人比较缺乏。
当一个项目出现问题时，大家都想要协调多的资源，特别是那种能够以一敌三的。
但是资源毕竟是有限的。
搞到最后就像是救火一般，哪里紧急就把资源派到哪里。
这样不仅打乱了项目团队的节奏（团队不稳定），而且也让这些资源疲于应对。
针对这样的情况，Scrum提议使用团队顾问。
也就是让员工自愿是否愿意作为顾问，服务所有团队。
这样的解决方案在实施时要特别注意：
- 依赖于管理层的支持
- 长时间在小范围内做尝试
- 选择核心团队，并决定需要哪些专家
- 小心团队顾问过度承诺
- 计划可能的空闲时间
- 顾问团队不应该替代专职团队，应该是一个核心的团队，辅以顾问团队。
4.如何确定团队的速率？
确定团队的速率一般有三种方法：历史数据、走着瞧、猜测。
- 对于组建的团队，熟悉的技术：优先选择历史数据，其次选择走着瞧，最后选择猜测
- 对于已组建的团队，不熟悉的技术：优先选择走着瞧，其次选择历史数据，最后选择猜测
- 对于新成立的团队，熟悉的技术；以及新成立的团队，不熟悉的技术：优先选择猜测，其次选择历史数据，最后选择走着瞧。其中历史数据可以，依赖于其他团队的历史数据。
5.Scrum的三大角色如何平衡？
Scrum的三大角色，包括关于Scrum Master，Product Owner以及团队成员。
很多公司会让一人身兼两职，甚至三职。
相较于让一个团队成员身兼数职，有一个专职的Scrum Master要好很多。
这样可以更好的保持三个角色所固有的检查与平衡。
虽然有人不赞成Scrum轮值，认为不够专注，但是我尝试过。
我个人觉得轮值可以提升团队成员的责任心。
6.如何确定Spring长度？
一般建议是1~4周。而长还是短是与项目、团队等多种因素决定的，各有利弊。
短周期的Sprint能使你更快地发现潜在的风险。
但其代价是团队得花更多的时间与客户互动，受到的干扰也更多一些。
可以尝试一周的sprint强制用户故事更小，让团队有更多机会来反映和纠正问题。
长周期的Spring，意味着需要更长的时间才能发现风险，但好处是互动干扰会少一些。
7.Sprint完成的标准？
制定并发布一个DoD。
这里面包括团队一致同意的内容清单。
比如：所有的Story都已经接受；对应的帮助文档已经更新……
这样一份DoD：
- 有助于团队成员建立密切联系
- 为项目干系人提供清楚的交流方式，间接降低了把技术债务推迟到项目后期的风险
- 使团队保持正确的方向，保持专注
8.Scrum Master到底做什么？
Scrum Master主要职责有：
- 消除障碍，解决问题
- 结束争论当团队的保姆
- 报告团队的行为表现
- 引导并在必要时提供帮助
- 教育组织并驱动组织变革
也许这也是为什么大部分人都建议Scrum Master要专职的原因吧。
别以为Scrum Master看着很轻松，其实一点儿也不。
要不你试试看？
9.真正的Scrum应该包含的实践有哪些？
我觉得如果下面这几点缺少了一个，就不能称之为Scrum了。
-
测试驱动开发TDD
首先写一个新的单元测试用例，但不写通过这个测试所需的代码；
然后写新的代码，使之刚好能够通过这个用例；
最后重构：重构在不改变，而是在已有意图和行为的情况下加强或改善其设计。外部行为保持不变，内部行为更流畅 -
持续集成：团队成员频繁地集成他们的工作，通常每个人每天至少集成一次，这样每天就有多次机场。每次集成都通过一个自动化构建，包括测试来尽快检测错误。团队可在任何时间构建发布。
-
结对编程：一人驾驶一人导航，一起工作，共同完成一个任务。
-
自动化集成与验收测试：集成测试是用来测试系统中各种集成点，验收测试用来模拟用户行为的测试
10.团队成员工作时间不一致，如何处理？
现在很多公司为了提倡人性化，对于员工上班时间不做强制规定，也就是所谓的弹性制。
只要你每天工作满8个小时即可。
而这样对于Scrum却是个挑战。
如果团队没有办法保证一定的时间在一起办公，如何进行结对编程？如何开站会？如何进行有效沟通？
所以我们需要确保团队核心时间。
核心时间就是大家对各自喜欢的工作时间和工作习惯所取得的共识。
比如有的人喜欢一大早7点到公司，下午4点左右就下班回家。而有的人喜欢快到中午11点才来上班，然后工作到晚上7、8点回家。这个时候的核心时间就是除去午休时间的共同时间。
在每个项目开始的时候，以及整个项目过程中需要的时候确定核心时间。
鼓励团队保持一定的灵活性。
11.什么是发布计划？
一般来说Scrum都是有节奏的进行发布。
那么为什么还需要发布计划？
因为Scrum是为了“敏捷”的应对，所以每次Demo或者Plan Meeting需求可能会有增加、修改、取消，那么你的发布计划也需要随之更新。
发布计划的目的是：为特定功能和整个项目何时能够完成提供答案。
- 沟通和交流，并且要频繁
- 每个Sprint后都更新发布计划
- 努力做优先级最高的条目
- 更新对大条目的估计
- 每个Sprint都交付可工作的软件
12.何时进行故事分解？
我有时候会被问及，这个故事足够小了吧，是否还需要拆得更小？要拆到多小才合适？
要知道任何事情都有一个度，不能过度拆分，这样会造成不必要的浪费。
搞清楚一个故事或任务太大还是太小，可以下面的问题帮助确定分解的级别：
- 团队能够用故事点来评估产品列表吗？
- 产品列表中的故事是否清楚定义了？
- 故事是否精确？
- 我是否对这个故事有足够的了解？
13.Scrum的缺陷管理方式是怎样的？
首先和其他框架一样，我们需要为缺陷区别等级：
- P0灾难：主功能无法使用且没有可行的变通方案
- P1高：主功能不可用，但有变通方案
- P2中：系统的使用性受损
- P3低：影响较小，无关紧要或不便利，可以等到下次产品发布时解决
如果是P0或者P1级别，那发现者及其搭档有一个小时来完成以下任务：
- 停止手上当前任务
- 确定该缺陷的根本原因
- 修复
- 更新所有测试
- 生成或重新构建验证测试
- 保证所有测试都能通过
- 提交代码
- 向前逼近一步，至少到集成环境中验验证
如果能一个小时完成则无需记录，如果不能完成：
- 在一个小时结束时停止
- 在缺陷管理系统中记录
- 继续修复
- 完成并关闭缺陷
- 更新Sprint列表及小时数
14.如何处理遗留系统的维护工作？
很多时候，我们在进行新功能开发的同时，还需要兼顾遗留系统的维护工作。
这一部分如果不妥善安排，不仅会打乱团队的Sprint节奏，还会影响整体计划。
有两种方案可以解决这个问题：
-
专用时间
从现在进行的Sprint中划出专用时间来处理遗留或现有系统维护。
比如每个Sprint20个小时。 -
专职团队
划分出专职人员进行维护工作，而且这个团队的Sprint要相对的使用更短的周期。
15.为何要组织demo会？
在每个Sprint的最后一天，Scrum Master需要组织Demo会议。
其目的是：让团队给客户和项目干系人演示他们在这个Sprint中完成的任务。
在这个过程中，最重要的不是演示是否顺利，而是客户和干系人的意见反馈，这样才能敏捷的调整。
16.为何要组织回顾会？
我不止一次的听人抱怨，回顾会就是浪费时间的检讨大会。
但是我们需要正视回顾会的重要性。
回顾会是团队检视调整周期中的关键部分。
团队趁此机会学习如何提高，如何更有效工作，如何以更高的速率与优良的品质交付价值。
这个环节必不可少，如果你的Sprint是一周，那么可以抽15~30分钟回顾一下，但是不可自行取消。
并且在结束会议前可以尝试用1-5分来评估“你觉得这个Sprint如何？”
17.为何要组织每日站会？
同样的一个问题，很多人说每日站会太浪费时间，而且站着开很累。
每日站会的目的就是要同步团队状态，并暴露任何可能影响工作的障碍。
站着不要坐着，这样能使团队更专心，更专注，更有效率。
毕竟可以有效的缩短会议时间，时间一长大家都站不住了。
18.每日站会上的第四个问题是什么？
我们都知道每日站会上需要问三个问题：
我昨天做了什么？
我今天要做什么？
我有什么障碍？
其实还有第四个问题是：
对于团队完成Sprint目标，如果以1~10来度量，你的信心有多少？
第四个问题可以避免团队成员在不愿意面对冲突的情况下表达自己的意见。
19.结对编程有哪些玩法？
结对编程能够在相对较短的时间内产生高质量的软件。
一般的情况是一个人“驾驶”，一个人“导航”。
这样其实可以做及时的Code Review。
但是一般来说“驾驶”的人会更专注，“导航”不自觉得就会走神了。
所以我们可以尝试以下两种玩法：
- 无序结对编程
大家交换结对
你一定要知道的关于Scrum的30个问题
-
微结对
你一定要知道的关于Scrum的30个问题
你一定要知道的关于Scrum的30个问题
20.如何让新人快速融入团队？
第一步，选对人。
这点非常重要。
这也是为什么一般来说我面试的时候会问：你平时有什么业余活动？
如果团队本身的成员都比较open，而比较闷的人可能会比较难融入。
更复杂的情况是，对Scrum的排斥，会让新人更难融入。
第二步，帮助新成员学习而制定测试。
比如定期让新成员回答以下问题：
- 描述系统架构
- 为何结对和TDD很重要？
- 谁拥有代码所有权？
21.如何应对与团队格格不入的新成员？
有的时候我们把一个人招进来后却发现这个人与团队格格不入，并不是说这个人的能力有什么问题，而是他会给团队带来负面的影响。
比如无法接受敏捷，并且试图让大家放弃敏捷。
有一个概念叫做社会异常，就是违背以确立文化规范的行为做事方式。
敏捷和瀑布没有谁对谁错的问题，只有合适和不合适的问题。
而当一个团队都觉得自己按照一定的节奏前进时，却出现一个不合群的声音，甚至影响到前进的速度和大家的心情，那么就属于社会异常。
对这个概念如果感兴趣的话可以去搜一下。
那怎么办呢？
首先，避免增加与团队不协调的新成员。有一些预判可以帮助你。
如果已经加入团队，那么尝试和行政主管、HR反馈这个问题。
如果实在不行，就只能尝试和他沟通，让他主动退出团队或者做一些边缘性的工作了。
22.Sprint可以取消吗？
当有异味影响到团队实现Sprint目标能力时，可以：
消除障碍
获得帮助
缩小范围
取消Sprint
一般我们不会建议你取消Sprint的，而是尽力去消除障碍或者获得帮助。
如果一切都行不通，才会取消Sprint。
可能的情况是，需求突然变化，有个异常紧急的需求需要处理。
而我们知道Sprint是不能被打断，临时添加任务的。
所以可以采取取消的方式。
但是一定要注意的是，取消的同时要将代码回滚到上一Sprint。
23.Scrum如何看待加班？
Scrum一致强调“可持续”。
而我们知道，一旦加班抢时间，团队在超负荷状态下工作时间越长，就需要更多时间来恢复。
这种“殉道”行为完全无法实现“可持续”。
所以，如果正在经历精疲力尽，首要任务是缩短周期时间。
这样可以提升每次Sprint的专注力。
另外，大家都必须承认，团队的完成量是有极限的。
24.如何保证每次交付可工作的软件？
记得多年前，小婧所在的团队做一个模块，计划半年后交付。
这个模块比较大，于是我们将所有的需求拆分成Story进行开发。
前几个Sprint，我们的主要精力集中在了“业务配置”功能的开发上。
因为我们当时的想法是，不进行业务配置，后面的功能是无法实现的。
后来我们发现，业务配置的部分开发完成都已经过去了三分之一的时间了，而我们的核心功能、业务场景尚未开始。
后来和公司的敏捷教练交流这件事情的时候。
她告诉我，应该先进行的不是业务配置，而是主业务场景和流程涉及的Story。
因为Scrum强调每个版本都可工作，可交付。
但是业务配置功能的发布并不可交付，用户拿着脱离了模块主业务场景的业务配置功能，其实价值为0。
那应该怎么处理呢？
这里有个概念，叫做“核心故事”：最基本的需求。
我们应该鉴别出一个核心故事，固定其他变量，让这个核心故事贯穿于整个系统。
也就是说，之前我们应该一上来就规划开发核心故事，而不支持可配置的功能。
然后逐步的在随后的Sprint中不断的锦上添花。
还有一种方式，可能会适合于互联网软件，就是控制用户数。
限制使用者或访问系统用户数。
无论如何都应该从风险最大的功能开始，避免后续发生风险后失控。
25.如何优化Scrum的效率？
我们都知道在时间管理的话题中有一项非常重要的工作是：时间记录。
也就是你要想省钱，那就必须先知道你钱都花哪里去了。
对于Scrum提升效率也是如此，你需要知道自己每类工作的花费，才能更好的提升效率。
有这样几类工作，大家可以尝试来进行观察和记录。
- 功能工作：向用户交付商业价值的功能
- 额外工作：企业服务或强制要求，比如审核或会议
- Spike穿刺：研究类工作
- 必要性工作：要达到完成标准需要做的工作
26.利用Scrum如何进行项目成本估算？
一般来说我们估算一个项目的成本有几种方式：人天、功能数。
而Scrum会提供给你一个更准确的评估方式。
- 生成用户故事：列出带评估项目的所有用户故事。
- 确定用户故事的优先级：按照优先级由高到低，逐一排列。
- 估算用户故事的大小：主要是为了是确定速率。计算所有用户故事的总点数。以以往的速率计算需要多少人在规定时间内能完成。
- 确定团队的成本：上一步得到的人数，乘以团队平均工资等成本。
- 计算项目的成本
- 承诺是否能做
27.Scrum后就不用写文档了吗？
有好多人说，我们是Scrum，我们不需要写文档，只有你们瀑布才会要写那么多文档。
对不起，我没听清。
谁告诉你Scrum可以不写文档的？
Scrum只是说，不写没用的文档。
也就是说，首先我们需要决定，项目需要什么什么文档以及什么时候做文档最有意义。
然后，按计划交付承诺的文档及及时汇报项目状态和白板照片。
并且，最好是投入自动化，部分文档可以通过自动化工具来生成。
比如我们以前写Online Help文档，后来就自动化转成操作手册进行交付。
28.外包与离岸开发要注意什么？
不管相距多远都要营造出一种氛围，让大家觉得是在同一个地方，工作的同一个团队。
以下几点要特别注意：
- 选择合适的离岸团队：雇佣敏捷团队，并且时差小于三个小时
- 以痛苦最小的方式分配工作：
让团队按工作包交付
让多个团队在同一代码机上工作
把特定的开发功能外包，如，测试、UI - 坚持Scrum框架
- 建立团队文化
- 持续集成
- 准备差旅
- 配合一个项目或团队协调人
以下情况建议绝不考虑离岸：
- 高度复杂技术高风险的第一个发布
- 本地团队还在挣扎于开发实践如TDD等，或缺乏纪律
- 公司没有成功必备的差旅预算和远程沟通技术的预算
29.大型列表如何进行优先级评定和估算？
像一般开发周期在3个月以上，涉及三类以上干系人的项目，其Story的数量和复杂度是非常可观的。
我们不可能逐一评判优先级，这个工作量太大了，需要协调的干洗人也会非常多。
这里有一个办法，可以快速的（一天内）完成Story列表的优先级评定和估算。
首先，你需要将所有的Story都准备好。
然后，让团队先大致将所有的Story按照大小排序：小的、中等的、大的、超大的。
这种排序是模糊的，不精确的。
接着组织所有干系人对同一区域内的Story进行优先级高低调整。
最后，Scrum Master一定要记录干系人讨论的内容及有争议的地方，以便后续进行进一步的跟踪。
30.你见过这样的合同吗？
一般来说，软件合同分成：固定总价合同和人天合同。
固定总价合同很好理解，就一笔钱，做多做少都这么多钱。
一般对需求比较明确的项目建议使用固定总价合同。
人天合同更多见于软件咨询类的合同。
顾问来多少天就给多少钱。
当然还有一些合同的变形，我这里就不展开讲了。
而Scrum给了我们另外一种合同的可能。
主要是两部分组成：调研合同和项目合同。
首先，签订的是调研合同。
由团队业务人员进行业务调研，并进行分析后给出Story清单和评估。
如果甲方觉得满意可以继续签项目合同，如果觉得不满意可以找别人来进行开发。
这个合同基本上会以“人天”合同为主。
接下来如果签“项目合同”，则是分Sprint签订、给钱。
如果甲方对这个Sprint的交付不满意，可以拒付。
也可以在几个Sprint后随时喊停。只需要提前通知即可。
但是我觉得要做到这点，真的是需要使用Scrum框架的每个实践，保证每次交付都是可用的软件。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
