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

2016-12-04 20:18:00

Scrum

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一定要记录干系人讨论的内容及有争议的地方，以便后续进行进一步的跟踪。