什么是Scrum?
Scrum是敏捷软件开发过程的一种框架，用以实现迭代式增量开发。
好吧，很抽象。
那是不是 —— 只要有了sprint、IPM、Showcase、Retrospective、可视化卡墙、每日站会，这些流程和工具，就已经实现Scrum了呢？
也许有人会说是。这看起来基本就是一个Scrum的MVP(Minimum viable product)。
好，那假设我们的团队已经实现了Scrum流程的MVP。
现在，我们来进行一下每日站会。请每个人依次对三个问题进行描述。
三个问题，哪三个问题？
- 你昨天做了什么？
- 今天计划做什么？
- 遇到什么阻碍或问题？
一般大家都认为是这三个问题是不是？
很多人都容易把每日站会视为一个简单的个人报告会。
但其实，Scrum的原版三个问题是：
- 你昨天做了什么去帮助团队完成冲刺？
- 今天你打算做什么来帮助团队完成冲刺？
- 什么因素阻碍了团队的前进之路？
请注意，有两个字在这三个问题中一再出现 —— “团队/团队/团队”。
也许有人会认为区别不大 —— 每个人做好自己的工作，就是在推进团队整体的进度。
团队之力
实行scrum的目标之一，提升团队能效，项目进展速度应该是越来越快的。
团队学习和知识共享
假设有一堆3个月以上工作量story卡，有两种选择：
- 分给5个工程师，他们各自都有充足的业务上下文来开发，但这5个工程师相互之间都不在同一个team，需要每人独立完成工作。
- 分给一个有5个工程师的team，团队性完成工作。
从做卡速率来考虑，你会倾向于哪一种选择？
估计在有的PM看来，如果这些工程师的技能Level都相同的话，这两种选择根本没有太大区别。
但是其实不然。
如果可以选择，将这里的工程师都替换成10倍效率工程师，选择一的整体做卡速度会提升10倍；而选择二中即使替换成5倍效率工程师，整个团队整体做卡速度也会远远大于10倍。
为什么？
一个简单的场景：假设story卡中涉及到新的技术知识，选择一，整体花费的从零开始独立的学习时间是5人份；而选择二，只需要团队中一个人从零开始学习，然后通过有效的知识分享和传递，快速的让整个团队所有人掌握此项技术。
消除单人进度的瓶颈
当然也不只是学习新技术的场景，联想一下平时有没有这样的场景：
A工程师在站会上表示当前进度被一个技术性问题困扰，正好B有相关经验，于是B主动表示今天会跟A pair来为其加速和传递相关知识。
每个个体都有长短板和瓶颈，团队正是相互之间以己之长、补彼之短。
即使很不巧，一个团队中长短板都相同，这里可以想象一下鸣人利用影分身学习的场景————多线程不同角度的试错，再通过交流和知识共享，最终还是能让团队快速克服瓶颈、获得更全面的成长。
小规模的加持
从上面两点可以观察到团队之中相互之间信息透明、沟通交流非常重要。
Scrum团队中，每个成员都必须知道其他人在做什么。同时每个人自己正在做什么工作，正面临着哪些挑战，取得了哪些进步等等，都必须透明，让别人知道。
这里其实会花费一些沟通成本，如果团队过大，固然是会让沟通成本增加，同时会给每个成员关注的沟通渠道数带来很大的压力。
团队成员增加之后，相互之间沟通渠道就会大幅增加。
团队总沟通渠道数 = n * (n - 1) / 2
# n为成员数量
如果是7人，团队总沟通渠道数是21，9人是36，10人则是45。
人类的大脑可能根本无法应付这么多的沟通渠道。
相信大家都在站会和code review的时候有这样的感觉，当人数上升之后，越来越不能充足的了解其他成员正在干什么，更别说主动发现并给予帮助了。
快速反馈和改进之力
Scrum的目标是为了实现迭代增量开发，从而产生反馈，从中学习，之后调整我们正在构建的东西和我们的构建方式。
sprint为团队提供了相应的机制。
我们先过一下sprint整体流程。
sprint之初 —— IPM：在每次冲刺之初，都会举行一次会议，产品负责人讲解需求，并由开发团队规划冲刺内容，即在未来两周内能完成多少工作，明确sprint结束时可交付的产品增量目标。
sprint运行中：在sprint中，团队有两项工作：完成在当前sprint计划的工作以及准备下一个sprint。
sprint结束之前 —— review（showcase）: 不展示成果，就没有效果。每次sprint的交付物应该是潜在可交付的产品增量，在showcase上展示已明确完成的增量成果，与sprint开始之前的完成目标进行对比，接受评审反馈。
sprint最后 —— team Retrospective: 团队回顾会议，在会议中回顾整个sprint过程，反思过去以改善将来的sprint。
快速反馈
每个sprint可看做是一种实验。
通过迭代sprint这种短期的time-box，每一次sprint结束之后，潜在可交付的产品增量可以让客户和团队快速评估该实验，获得反馈。
他们可以根据在上一个sprint中的发现来判断自己的前进方向是否正确，以及判断他们下一步打算做的事情是不是恰当的。
失败得快，才能迅速改正。
检查和调整
Scrum的一个重要意义就是改变团队对时间的看法。实行sprint和每日站会一段时间之后，团队就不会再把时间看成一支径直飞向未来的箭，而是从周期性的视角去看待时间。
利用这一个个周期，形成戴明PDCA循环（Plan-Do-Check-Action）。
Review和Retrospective，就是scrum中形成检查和调整的一环。
不只是”检查和调整“团队构建的东西，还要”检查和调整“团队构建的过程。
每经过一次sprint，检验一下团队做的事情，看看是否朝着正确的方向前进？结果是不是真正希望看到的？是否有什么办法能改善目前正在做的事情？如何才能做得更快更好？存在哪些潜在的障碍？这一点看似容易，做起来并非易事，需要有思想，善于自省，有实事求是基于事实的数据和依据、自我约束的意识。
有人曾经发问：如果团队成员都不想开Retrospective，作为PM你打算怎么办？
当时的一个答案是：其实敏捷实践施于团队，都是可以根据团队实际情况进行剪裁的。如果团队觉得没有必要开，那就可以不开。
但我想说的是，对于Scrum，如果没有其他手段形成周期性最后的”检查和调整“闭环，那Retrospective就一定要开。即使是团队成员对于当前的Sprint状态、速度、步调非常满意，因为 —— 即使是这种情况，在Retrospective meeting上，团队也要回答一个重要问题：”你们如何才能做得更好？“
短期详细计划，消除浪费之力
在最早的软件开发方法 —— 瀑布式软件开发中，前期会做大量的分析、设计和计划，编写大量详细的文档文档、绘制大量的甘特图报告企图体现和控制软件的开发进度。而当现实进度与计划报告有矛盾时，认为往往认为问题出在现实上，认为图表是正确的。
本身这种长期计划和进度控制办法，建立的这种制度 —— 无异于强迫自己一味地空想。
首先，这种付出大量努力去规划细节，限制潜在变化，并预知未知因素的长期计划，最后往往会徒劳无功。每一个项目在开发过程中都需要人们去发现新问题，去激发自己的灵感。
其次，企图回避现实的不确定性。
另外，无法响应外在环境和商业的不断变化。
最后，是非常现实的一个问题 —— 人类其实非常不擅长于预测一件事情需要耗费的时间。
而在scrum中团队只需要对下一个sprint做详细计划，使用短周期来增加确定性、应对变化、快速反馈。节省长期计划中起不到作用的分析、设计、沟通协调的时间。
专注目标、可持续的步调之力
sprint之所以叫冲刺，是可以让人产生一种紧张激烈的感觉。
但它强调的并不是 —— 长跑马拉松始终以最后200米冲刺的不可持续的节奏进行开发，反而十分强调可持续性开发节奏。
首先，不要改变当前sprint的目标。
一旦一个团队决定要完成某些任务，那么这些任务就锁定了，团队之外的任何人都不能再给他们增加任务，干预和扰乱团队只会大幅放缓团队的工作进度。
即使一些人质问敏捷不就是要拥抱变化吗？Scrum的拥抱变化不意味着可以在同一个sprint内进行改变。
其实，很少有企业身处“变化迅猛以至于企业不能在2周sprint的开始就设定优先级然后保持这些优先级不变”这样的行业中。许多企业也许认为他们就处于那样的环境，但事实上不然。
要达到不要轻易改变当前sprint的目标，这通常要求我们慢慢习惯于“提前思考”，不要“缺乏远见”。
其次，不要台球短跑。
台球短跑指，团队刚完成一个sprint，还没准备开始下一个，下一个sprint又开始启动。第二个sprint经常只是所谓的开始，实际上团队还根本没有准备好做这个sprint的工作，以致于他们不得不花费几天时间学会要干什么。
要记住，在当前sprint中，团队有两个目标：完成在当前sprint计划的工作以及准备下一个sprint。
特别PO、UED这些团队对其有前置依赖的角色，需要及时提前准备下一个sprint。这样可以让整个团队的交付步伐一直处于顺畅、可持续的状态。
可预测之力
团队内，需要知道自己的速度。
每个团队都应该准确知道自己在每个sprint阶段中完成了多少工作，并且应该知道如何以更加聪明的方法去消除障碍，加快工作速度。
知道自己的工作速度之后，就能计算出交付日期，速度 × sprint次数＝交付工作量。
团队外，稳定、短期的交付频次，可以带给客户明确的”可预测性“ —— 基本上提出的需求和问题只要等待一个固定周期就可以上线。
当然如果客户在明知”可预测性“的基础上，仍然总是要求”快速响应“，没有耐心等待一个固定周期时间过去，那就可以考虑缩短这个固定周期的时间长度。比如，如果是2次sprint才release一次，则可以考虑是否能1次sprint就release。
总结
学习Scrum框架，使用其进行软件开发过程管理，往往很容易。
但，是不是总有那么一些团队，明明用了Scrum仍然每日疲于奔命？
是否是只见Scrum其形，不见其神呢？
如果是，可以检查一下是否有 其神中未发挥出来的力量？
如果是，可能团队需要考虑有一位专职的Scrum守护者 —— Scrum master。
参考文献
- 《敏捷革命》，Jeff Sutherland 著
- 《Scrum 敏捷软件开发》，Mike Cohn 著
- 《硝烟中的 Scrum和 XP》，Henrik Kniberg 著