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点回家。这个时候的核心时间就是除去午休时间的共同时间。
在每个项目开始的时候，以及整个项目过程中需要的时候确定核心时间。
鼓励团队保持一定的灵活性。
写在最后：
这个主题会分成三个部分，每个部分对10个问题进行说明。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行就请关注我吧！
