有道云笔记蒋炜航分享敏捷开发的实战经验

阅读数:1469 2013 年 1 月 23 日

话题:Scrum文化 & 方法

蒋炜航是有道云笔记负责人、网易技术总监,他在新浪“创事记”的一篇文章中分享了有道云笔记团队的敏捷开发实战经验。

有道云笔记到现在已经升级到 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有些不同的看法:

要提敏捷,别整那些中国特色剪裁,谁都知道是怎么回事,老老实实的“傻到愿意相信”。……其实吧,软件开发就是找几个你花的起钱里面最好的,告诉他们要做什么,隔三差五聊聊问题进度,其它问题是人才就会自己搞定。