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），如果想与我同行，就请关注我吧！