蒋炜航是有道云笔记负责人、网易技术总监，他在新浪“创事记”的一篇文章中分享了有道云笔记团队的敏捷开发实战经验。
\有道云笔记到现在已经升级到3.0版本，有5个主要平台，共发布46个版本，累计近千万用户。蒋炜航开门见山指出：
\\\在这个过程中，我们逐渐摸索出一套适合以产品和技术创新为核心的中等规模(数十人)研发团队的Scrum实践经验。
\
接下来，他总结了8条经验。
\一、Scrum不是万能药，要在时机成熟时推行。
\成熟时机需要两点：
\- 团队有三名或以上的研发工程师\
- 团队内有一名合适的Scrum Master\
在蒋炜航眼中，合格的Scrum Master要具备如下特质：
\- 首先，他要认可敏捷开发这种方式；\
- 其次，他要熟悉业务，起到教练的作用，能带领团队走正确的流程；\
- 并且，当团队遇到问题时，他要有能力和担当引导团队做出决定，在团队成员遇到困难时，他要协助成员解决；\
- 最后，他要能识别重要和紧急的事情，而并不是事无巨细的反馈到产品负责人那里。 \
二、限制Scrum团队的规模，建立Scrum团队之间的协作机制。
\蒋炜航列举了有道云笔记自己的例子：
\\\很长一段时间Android和iOS的研发工程师组成一个Scrum团队，有共同的产品负责人和Scrum Master。但是随着移动端团队人数的增长，Scrum会议的效率却降低了。
\……
\按照平台拆分团队，限制了Scrum团队的规模，提高了Scrum的效率。
\
针对多平台之间的协作，蒋炜航引入了Scrum Master的定期会议。
\\\在这个会议上，我们会讨论各个Scrum团队相互依赖的项目，安排好各Scrum团队的开发顺序。对某一件具体的事情，其中的一位Scrum Master会被指定为具体负责人来驱动跨Scrum团队的协作。同样，只有当Scrum团队间的协作任务比较复杂的时候才需要引入这个机制。
\
三、产品经理和研发工程师要拥抱Scrum带来的变化。
\以前的瀑布式开发，虽然项目常常延期，但是产品经理会有对项目把控的感觉。在引入敏捷之后：
\\\表面上看起来，产品经理对产品的把控小了。...事实上，接受Scrum并不困难。这样，产品经理可以把重心放在对产品需求的把握上。...而且，团队的开发效率，功能点完成的速度并没有因此而降低。
\
……
\蒋炜航指出：研发工程师也要调整工作方式，不要花太多的精力在未知的事情上，而是小步快跑，要持续重构。
\四、量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度。
\但是不一定一上来就量化：
\\\当Scrum团队不大的时候，可以依靠主观感觉来评估执行力。有道云笔记团队在初创的一年内，对sprint的完成情况是没有量化的评估的。
\
接下来，他列举了几个他们团队使用的指标：
\\\最重要的是完成度，我们用这个指标来衡量团队的执行力：
\完成度=1-计划内未完成任务的剩余时间/计划内任务评估时间
\(完成度的数值在80~90%之间比较好。过高的完成度说明sprint计划过于保守。)
\……
\我们还定义了两个指标来作为辅助参考。一个是评估准确度(计划内任务评估时间/实际使用时间)，一个是计划合理度(计划内任务使用时间/计划外任务使用时间)。这两个指标的历史数值可以让我们更加了解团队执行的情况。
\
五、高效的sprint计划会的要素：预先梳理需求、合适的任务粒度、随机认领任务、运营调研任务、任务评估。
\对于需求的预先梳理，蒋炜航团队采用过多种方式：
\\\发邮件、产品与研发面对面沟通、开需求梳理会。哪种方式更好，目前还没有定论。
\
对于任务的粒度：
\\\我们经过较长时间的实践，发现0.5至3天一个任务是一个合适的粒度范围。
\
在任务领取方面，团队面临挣扎：
\\\是让大家做自己熟悉擅长的事情，还是随机认领任务以达到团队人员对所有模块都很熟悉的状态。一个短期见效，另一个长期可发展。
\有道云笔记PC平台的Scrum团队经历了一个从前者转向后者的过程。
\
六、流水化安排开发环节与测试环节。
\具体来说：
\\\就是在开发sprint结束后再开始测试这个sprint的产出版本；而在开发的sprint内，开发团队解决上一个sprint的产出版本测试出的bug。虽然这意味着开发团队要在测试环节还未开始之时(Sprint计划会上)，就要估计并预留出上个sprint产出版本的bug修改时间，但在实际操作中，开发团队能够通过历史数据做出比较准确的估计。因此这种方式的效果是良好的。
\
七、版本发布基本按照sprint周期
\他们通常在一个或者多个sprint之后(在测试环节之后)发布版本。具体选取会参考一些市场情况的考虑，但不会为了某个大版本打乱sprint周期。
\八、Scrum需要配备合适的工程实践，例如单元测试、代码审核、持续集成、项目管理工具。
\目前，由于对测试驱动开发和结对编程目前还有许多争议，他们没有贸然尝试。
\在持续集成方面：
\\\每天凌晨持续集成系统会自动下载前一天的代码，进行编译和部署。Web端会直接部署到Web测试服务器，而客户端(PC、iPhone、iPad、Android)会自动拷贝到一个内部服务器上。测试人员或者感兴趣的人每一天一上班就可以用到最新的版本。
\
有道云笔记团队的这些经验引起微博上不少讨论。
\边缘雏鸟认为：
\\\好的战术需要有好的士兵，对于一个团队来说，适合程序员的方法就是好方法，不在于是否敏捷。程序员素质跟不上，一两年后，产品可能需要推倒重写。最重要的一点是要有合适的管理者，他能选择合适的方法，能保证产品不至于为求快而蹦掉。敏捷，估计很多团队能做到的是只是快而已。
\
Walter_Fan提到：
\\\说得不错, 自己参与了四个sprint, 对于敏捷有了更深切的体会, Scrum master虽然比较关键,可是不断成长的 team 更重要, 一个个个积极主动, 互相帮助, 共同促进的scrum team 战斗力非比寻常, 找个时间也要做点总结
\
sagasw有些不同的看法：
\\要提敏捷，别整那些中国特色剪裁，谁都知道是怎么回事，老老实实的“傻到愿意相信”。……其实吧，软件开发就是找几个你花的起钱里面最好的，告诉他们要做什么，隔三差五聊聊问题进度，其它问题是人才就会自己搞定。
\
585
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
