BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 郑柯 关注 3 他的粉丝 发布于 2013年1月24日. 估计阅读时间: 7 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

RE by cao Alex

是不是敏捷,已不重要。关键要打造正能量的团队文化。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT