产品研发模式思考：双驱动研发模式

本文作者

孟翔宇

挑战、不断前行的创新实践者。

PMP, CSM, NPDP, FLMI, Management 3.0， 担任过的角色有工程师、项目经理、开发部长、敏捷教练、设计思维引导师等。在工业、金融等领域有10年以上的技术团队管理和产品研发经验。

引子

近期在启动一个基于人工智能技术的知识管理平台项目，一直在思考采用什么样的研发模式，才能让我们快速形成产品，推向市场。

正文

当今时代是一个快速变化的时代，创业团队通常都希望通过短时间，高效率，低成本的方式推出自己的产品或服务，笔者所熟知的传统项目管理方法通常达不到这样的效果，而敏捷产品开发的思路却可以帮助大部分团队实现这个愿望。

什么是敏捷开发？

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。“ 固定时间，弹性范围（Fix time, Flex Scope）”是敏捷迭代的核心理念。

通常的敏捷开发都采用Scrum方式，一般是由产品经理维护产品功能列表，迭代中对功能进行澄清、排列优先级、估算工作量，然后研发团队在迭代计划会议上根据优先级和自身开发速率拉取功能进入迭代功能列表，进行开发、最终形成产品或产品增量。

常规敏捷研发流程

这个方式适合我们吗？

通常的敏捷开发，大都采用前述的模式，但我们的现状是产品人员较多，与研发人员接近一比一的比例，采用前述模式会造成工作负荷严重不均衡。

经过研究与思考，我发现可以采用下述的双驱动研发模式。将前述的迭代改称为研发迭代，将产品人员组合为产品团队，以团队为单位通过产品迭代对产品功能列表进行不间断维护。在这种模式中，产品团队与研发团队要保持相同的迭代周期，产品团队要先于研发团队一到两个迭代将潜在需求梳理为用户故事放入产品功能列表，之后的研发迭代与前述模式相同。

双驱动模式敏捷研发流程

两个团队如何协作？

采用双驱动研发模式进行产品开发，必须要明确两个团队的分界线以及完工标准。在这里，我们采用用户故事的DOR和DOD来分别界定两个团队的工作范围。

DOR—Definition of Ready

用户故事已就绪可以交付研发人员进行开发

DOD—Definition of Done

研发团队和产品团队从流程角度共同制定的用户故事开发完成标准

后记

未来，越来越多的团队会采用敏捷方式进行研发，希望我们的思考会帮助大家做得更好，产品更出色。

Reviewed by Tina

推荐书籍

书名丨《敏捷回顾：团队从优秀到卓越之道》

作者丨Esther Derby , Diana Larsen,Ken Schwaber著

内容介绍丨本书被作为PMI-ACP的考试指定教材。结合实际案例，本书深入阐述了敏捷回顾的基本理论和可操作性的工具、方法及流程，您将看到如何构建敏捷回顾会议，如何专门针对团队和组织设计回顾方法，如何使回顾方法有效地运行在敏捷会议中，并且如何进行必要的更改以及如何扩展这些回顾会议方法。 同时您将学习如何处理问题，并在整个项目中有效地实施解决方案。这是一本值得所有团队领导、Scrum Master以及致力于提升团队应对能力、学习能力和执行能力的有志之士的选择！

想获取更多人工智能行业的本地资讯和活动，想与行业内大咖交流和互动，请关注本公众号。