关于Scrum运行当中常见问题及解决方法，我曾写过一个slides，在公司内部分享，现在重新整理了以后共享在这里：近距离接触Scrum

关于Scrum，最常见的误解是Scrum master == team lead，这是不对的。Scrum master可以是任何人，不需要担当任何管理职责，在Scrum中只是一个推动者。

除了Scrum过程本身，还需要整个team共同遵守一些游戏规则。这些规则可以根据实际情况来制定，不过尽量不要超过3项，毕竟人能同时记住的事情一 般不超过4项，还得留1项给当前的工作。

例如，可以制定以下规则：

1. No suprise：大家都有义务保持信息通畅，及时有效的将stakeholders关心的消息传递给他们，尽量不要让任何人对结果产生suprise。对于不紧急的沟通，可以选择在daily scrum的时候将信息传递出来，尽量不打断其他人的日常工作。
2. Focus on one thing：很少有人能够快速的在多个任务之间切换还不影响效率，集中精力干好一件事情是提高效率的最简单的做法。要做到这一点，必须懂得如何对手头工作进行排序，最简单的就是focus on high priority work，这也就是Scrum过程中安排work item并对它们排序的意义。

无论如何，Scrum过程只是一个工具，而非目的，任何事情还是以delivery为重，流程本身执行是否合乎规范完全是次要的。

欢迎发表不同意见。

误区：敏捷开发 == 极限编程/Scrum/…

敏捷开发是一种方法论，只是一些基本原则的集合，并非具体流程。

极限编程、Scrum等流程是具体的实施方法，它们都声称符合敏捷开发的思想，但执行起来是否真的“敏捷”，还得看参与者究竟思想上是否真的接受敏捷开发的原理。

如果把结对编程、daily scrum当做是敏捷开发的表现，那更是本末倒置，可悲的是，不少人还真是这么认为的。

误区：敏捷开发 == 简化流程

敏捷开发不一定能简化工作流程，而且简化流程也并非提出敏捷开发的初衷。敏捷开发最重视的是拥抱变化，至于怎么拥抱，只能随机应变。实际应用中，既有流程相当简单的经典Scrum过程，也有极为冗繁、不亚于CMMI的RUP，根据应用场景不一样，项目组应该使用最适合的流程。

选择敏捷开发流程时也应带着敏捷开发的思维去选择，即快速响应项目实际的流程需求、拥抱流程应用过程中遇到的各种变化。没有银弹，也没有长期适合的项目流程，生搬硬套某个看似成熟的敏捷开发流程是大忌。

误区：敏捷开发 == 快速开始编码

敏捷开发强调迭代，鼓励开发人员用代码说话，不过绝对不鼓励没想明白就写代码。

符合敏捷开发思想的流程往往主张在一个稳定的基础之上迭代完成各种功能。如果基础都不牢固，迭代就无法进行，整个开发过程就退化成不断重写的过程，浪费开发时间。敏捷开发实际非常重视“设计”，并且对开发人员的设计水平提出了极高的要求，既要“持续重构”又不能“过度设计”，稍有不慎就会陷入反复推翻已有代码的窘境。对于内功不够的开发人员最好还是想好再写代码，设计的时候慢一点没关系，尽量少的做无用功才是最重要。

误区：传统开发能随时转变成敏捷开发

敏捷开发过于诱人，很容易让深受传统软件开发思想折磨的开发人员感觉敏捷开发就是灵丹妙药。

要想转变，首先需要从思想上正确认识敏捷开发的含义，了解它能解决什么问题、会带来什么新的问题、对现有软件/硬件资源有什么要求等。

例如在原先采用CMM的团队中，想利用敏捷开发简化冗余的文档、降低沟通成本，那么敏捷开发确实能在一定程度上缓解这些问题，但也会造成内部文档缺失、沟通不够深入的问题，在应用敏捷开发之前需要先确定适合团队的新的文档流程（代码注释能够自动/半自动的变成团队需要的文档么？），并且确定沟通的一些原则（比如，对于一些重要的沟通，是否还是用邮件来进行，不要过于“敏捷”？）。

有趣的是，有可能在回答这几个问题之后会发现，敏捷开发并不能解决项目中遇到的问题，反倒是其他方面出了问题。

举例来说。如果之前开发方法是简单的目标管理，遇到的问题是项目进度不可控、开发+测试的周期较长、不能及时响应需求变化，那么敏捷开发能解决的是快速响应需求变化，对项目进度和开发测试周期帮助不大（没有一种流程能够承诺改善项目的开发效率！），但前提是开发人员必须懂得怎样正确的去迭代开发，并且必须认识到一次迭代的结束是以完成测试为标准的。

在这个例子中可以看到，敏捷开发能带来的好处非常有局限性，如果开发人员达不到一定的层次是很难受益的。与其号召使用敏捷开发，不如想想如何增加执行力，以及找到周期偏长的根本原因（是因为设计不充分而返工？还是因为没有可以快速回归的测试用例？等等）。

Scrum是一种敏捷开发方法，具体的细节我就不说了，网上随便都可以搜索到。Scrum的本意是“橄榄球中的并列争球”，引申到这个开发方法之中就是：思维碰撞与迅速交流。

Scrum中最有特色的是“净室”（Clear Room）理论，提倡在有限的资源之中获取可用的结果。举一个很形象的例子，假如计划在一段时间内榨取一定量的橙汁，那么Scrum就会要求在这一段时间内一定要得到橙汁，无论是多是少都无所谓，但一定要得到的是橙汁而不是榨到一半的橙子。这也就是说，在Scrum里面，延期交付是不应该有的，加班也是不应该发生的，如果实在快要完不成任务了，应该去删减不必要的需求，而不是拖延交付时间。通过这样的开发模式，整个软件都能在一个可观测的进度中进行，每过一段时间都可以拿到一个功能并没有完全实现、但主要功能已达成并且经过完整测试的版本。

Scrum中还有名为Scrum会议的一种每日例会形式。这种会议其实对我来说并不陌生，因为我曾经就在团队中宣传过每日会议，每日会议的五个问题（本来只有三个，我根据《敏捷迭代开发——管理者指南》这本书的建议，又加上了两个问题）早就在Dian团队的各个实验室贴满（除了东一以外），而且现在应该还找得到。微软的Scrum会议是原始的三个问题版本，包括“之前完成的任务”、“将要进行的任务”和“有没有阻碍目标的事宜”，这是最经典的问题模式。关于每日会议，可以看看我原来写的文章做一个回顾软件开发中的理想与现实（五）——知己知彼，百战不殆。

Scrum是一种典型的“个体软件工程”。在“个体软件工程”之中，开发者是以个体存在，并没有一个项目经理统管全局。不过确实有一个和开发者平级的Program Manager，他负责收集需求和驱动开发人员进行开发。所谓的“驱动”而不是“管理”，这意味着他并不干涉开发者的工作，也并不决定开发者的工作表，而是拿着自己手中的需求“求着”开发者来为自己干活，如果项目进度紧张，他还要主动地砍掉低优先级的需求以满足时间点要求，这样，他就必须用一种非常亲和的姿态与开发者进行沟通。同样，在测试那边，Program Manager的角色也是类似，也是一种驱动的方式进行管理。这种方式充分的保证开发、测试和Program Manager都能充分发挥自己的能力，让个体个性充分体现。同时，通过Scrum会议和其他各种方式（还有很多，Scrum还有很多东西我无法说出来），让项目还能按照既定的方向顺利进展。

当然，所有的敏捷软件开发都会要求用测试先行的方式开发，任何的形式上的模仿可能都会造成很大的副作用。个体软件工程本身往往并没有什么问题，但是对个体的素质要求却限制了它在低水平开发中应用，真是可惜呢。

希望大家都能练好编码和测试的基本功，然后大声疾呼：Let’s Scrum!