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

最新推荐文章于 2024-06-23 14:49:41 发布

原创最新推荐文章于 2024-06-23 14:49:41 发布 · 321 阅读

0 ·

CC 4.0 BY-SA版权

有道云笔记负责人蒋炜航分享了团队敏捷开发经验，包括适时推行Scrum、限制团队规模、产品经理与研发工程师的角色调整等内容。这些实践有助于提高团队执行力及协作效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

有道云笔记到现在已经升级到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需要配备合适的工程实践，例如单元测试、代码审核、持续集成、项目管理工具。

目前，由于对测试驱动开发和结对编程目前还有许多争议，他们没有贸然尝试。

在持续集成方面：