1、Scrum不是药，要在时机成熟时推行。

　　什么时候算时机成熟呢？我们的经验是需要两点：一、团队有三名或以上的研发工程师；二、团队内有一名合适的Scrum Master。

　　刚开始的时候，一个开发团队可能只有一名或者两名研发工程师。这时候并没有全面推行Scrum的必要，而可以借鉴Scrum中的一些做法。比如有道云笔记的Web团队初是这个情况。当Web团队只有一名研发工程师时，我们尽可能地尊重他的工作方式。同时为了保证项目进度可控，我们引入了Scrum的sprint机制——以sprint为开发周期，每个sprint进行一次Web产品演示。这不但能够让工程师有一个以sprint为期限的压力，还能够让其他同事即时地了解项目的进展，以便做出相应调整。当Web团队扩充为两名工程师时，我们又引入了结对编程、持续集成、相互代码审核等做法。直到Web团队的规模进一步扩张时，我们才开始考虑全面启用Scrum。

　　当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。

　　合适的Scrum Master需要具备几个特质：首先，他要认可敏捷开发这种方式；其次，他要熟悉业务，起到教练的作用，能带领团队走正确的流程；并且，当团队遇到问题时，他要有能力和担当引导团队做出决定，在团队成员遇到困难时，他要协助成员解决；后，他要能识别重要和紧急的事情，而并不是事无巨细的反馈到产品负责人那里。

　　敏捷开发虽然希望团队自我管理，但是这需要一个过程，开始的时候，一个合适的Scrum Master至关重要。有道云笔记的Web团队在成立一年多以后才开始推行Scrum，很大的一个原因是在培养合适的Scrum Master。依据我们的经验，胜任Scrum Master的人选是技术主管。我们也曾尝试过让产品经理担任Scrum Master，但是由于产品经理本身往往担当产品负责人，兼任Scrum Master会影响他在产品机会和产品体验等方面的投入。

　　2、限制Scrum团队的规模，建立Scrum团队之间的协作机制。

　　随着业务的发展，团队会变大。这个时候不拆分团队的话，效率会变低。

　　有道云笔记移动端团队经历过这样一个过程。很长一段时间Android和iOS的研发工程师组成一个Scrum团队，有共同的产品负责人和Scrum Master。但是随着移动端团队人数的增长，Scrum会议的效率却降低了。虽然Scrum会议只有不到半小时，但是当说一个平台的事情的时候，另一个平台的工程师会觉得无所事事。发现了这个情况后，我们把移动端团队按照平台拆分成了两个Scrum团队，以确保Scrum会议上说的是每一名参与者都关心的事情。总的来说，参加Scrum会议的所有人，包括产品、开发和测试，不应该超过9个人。

　　按照平台拆分团队，限制了Scrum团队的规模，提高了Scrum的效率。与此同时，多个Scrum团队之间必须进行有效的协作。

　　在初期，我们鼓励研发工程师通过面对面地商量，快速推进来处理平台之间协作的需求。但是随着业务的发展，这样的协作越来越多，也越来越复杂，这样面对面的讨论往往会疏忽细节需求。比如说，有道云笔记3.0版本中的待办事项功能，需要PC、Web、Android、iPhone以及Server等多个Scrum团队一起，对这个功能进行产品定义和确定技术方案。这样复杂的协同需求需要额外的机制来保证。这个机制是Scrum Master的定期会议。在这个会议上，我们会讨论各个Scrum团队相互依赖的项目，安排好各Scrum团队的开发顺序。对某一件具体的事情，其中的一位Scrum Master会被指定为具体负责人来驱动跨Scrum团队的协作。同样，只有当Scrum团队间的协作任务比较复杂的时候才需要引入这个机制。

　　3、产品经理和研发工程师要拥抱Scrum带来的变化。

　　在引入Scrum之前，一般的项目管理方式是版本式(瀑布式)的，产品经理决定下一个版本做什么，预期发布的时间，然后由产品负责人或者技术负责人来兼做项目经理。这个时候遇到的问题是项目往往会延期，但是产品经理会有一种对项目把控的感觉。

　　引入敏捷开发之后，这个事情变了，发布是跟着sprint走的。基于持续交付的原则，一次发布包含一个或者多个sprint的内容，而这些内容是由团队整体决定的，而不是产品经理个人决定。产品经理只是定义了功能需求的优先级，这些功能需求与代码重构、开发工具、以及市场运营等的推广支持等需求一起排期，后由整个团队决定一个sprint做哪些东西。

　　从表面上看起来，产品经理对产品的把控小了，为此，团队一位产品经理有过质疑。后，我们还是说服了他接受敏捷。事实上，接受Scrum并不困难。这样，产品经理可以把重心放在对产品需求的把握上，而不必整天问这个咋样了那个咋样了。而且，团队的开发效率，功能点完成的速度并没有因此而降低。

　　研发工程师同样要拥抱Scrum，调整自己的工作方式。Scrum不鼓励过度设计，而采用涌现式设计。这意味着开始往往不会把技术架构做得大而全，而是鼓励快速出成果。当然这并不是说程序架构能够设计得很糟糕，而是说不要花太多的精力在未知的事情上，小步快跑。为此，代码重构是必须的(编者注：在不改变软件现有功能的基础上，通过调整程序代码改善软件)。我们并不建议整个sprint都去做重构，更建议持续重构，把代码调整也分解成任务，每个sprint做一些。在一些大版本发布之后，重构任务的比例可以适当高一些。