作者介绍
邱戈川，现任唯品会基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。16个年头的IT老兵，除了销售和老板角色，做过IT中的各种角色，游走于架构与产品间。关注Docker、Mesos等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统，以高性能、低延迟广受好评。个人订阅号：vipdocker。
1产品开发节奏的思考
谈到产品开发节奏，不得不说一下Scrum中的Backlog、迭代和Planning Game。Backlog和Planning Game的操作细节后面细讲，这里只是说下和开发节奏的关联性。
迭代上一般的指引是2-6周，但是具体如何做更合适就没有人说清楚了。这里可以给我们实践的作为参考。
首先我们要区分是否是需要发布生产的产品还是只是发布开发包给业务做开发产品。对于发布生产的产品，我们做法是5周一个大迭代，前面每两周一个小迭代，最后一周是大迭代的总结，下个大迭代的Planning game，以及做发布的相关事宜等。对于只是发布开发包的产品如只需发布到maven库等，则4周一个大迭代，每两周一个小迭代。
无论哪种产品，对于一次大迭代的结束都要以可发布的版本作为成果。
每个大的迭代中总会遇到不同的情况，如就要到来的双十一的支持工作等，但是需要做的不是去推迟版本的发布，而是去判定哪些是重要的高优先级的需求，将其缩小到可以发布为止。
谈到版本的管理，下一篇再细谈，也买个关子。不过有个搞笑的事，有同学竟然问我什么时候可以不用出版本？我只能笑而不语，因为从产品的角度，没有版本可出就将意味着产品已经到头了。
简单而言，每次大迭代都要让团队看到可以运行的产品，能给客户带来新价值的产品，从而树立对产品的信息和兴趣。
Backlog的管理可以借助多种工具做管理，可以是一张Execl表，也可以放WIKI上描述都可以。但是从开发节奏的角度，迭代的范围从一开始大迭代就要谨慎做出选择。虽然Backlog大家都知道需要明确标明优先级，但是在每个大迭代做选择时是否都是需要选高优先级的呢？我们的答案时“否”。在所有Backlog里有超过5个／最好3个高优先级的需求，这个优先级将失去意义。
产品经理一定要强迫自己根据迭代的人力的一半情况，选出2-3个真正最高优先级的需求，然后配套安排些提高性的需求一起做为大迭代的范围。这样才有可能在每次小迭代总结的时候，确保高优先级的需求在有干扰的情况依然能被完成，而提高性的需求则是可以随时调整出版本范围的。从经验上看，很多时候无法出版本的原因就是同时有多个高优先级的特性功能在开发，而受外界影响时又都无法完成，最终造成产品无可运行的版本，只能延期。
Planning Game对于开发节奏的影响最大在于前期的准备是否足够充分。很多人理解上planning game的目标是为了评估工作量，但是其实最大的目的是让所有人了解需求、了解架构设计、了解外围影响。只有把需求分析、架构设计、风险评估提前做好，才有可能确保开发节奏不受影响。
最后一点，无论遇到什么情况，想到的事情是砍需求，而不是去改变版本计划。因为每次大迭代就像培育一个孩子，中途夭折将打击团队的激情，也同时影响外界对于产品和团队的口碑。当然也有可能遇到需求砍无可砍的地步，如我们最近做的版本，只有一个需求，那么无法完成，唯一可做的就只有延期了。节奏同时也会影响你的生活质量，无序的步骤将是大家加班噩梦的开始。
2产品路线图的定义
产品和项目最大的区别在于产品是有自己的路线图Roadmap，也就是自己的生命周期。Roadmap该如何定义更容易管理？这个问题我们内部有过不小的争议，因为它容易和Release management混淆在一起。先来看看Roadmap的目的，再谈下我个人的看法。
Roadmap的目的是去定义产品的模样Vision以及它的重要特性。就像描述一个人的成长历程，他儿童时什么样，青年时什么样，中年什么样，老年什么样。
Release Mangement则是描述什么时候产品达到什么阶段。例如在0.0.1版本，只是具有爬的功能，并不代表他已经是儿童时了。也就说可能需要多个版本才能描述出产品roadmpa中的某个阶段。
本人不是那种教科书的教条主义者，个人喜欢的做法是用鱼骨头来描述不同版本的功能特性来展示产品的线路图，也就是混淆了Roadmap和Relase managment，如下图例子：
"roadmap"
混淆的好处是管理起来比较简单，不过这个做法见人见此了。
3需求的管理–Backlog
这里可能有些公司还需要管理MRD(Market Requirement Description)，这个通常是与业务紧密度比较高的时候。MRD的做法可以有很多种，比较常见的方式是写一段故事User Story，并不涉及任何实现细节，只是需要将用户的期望描述清楚。
Backlog的做法一般是与产品，与实现技术有某种结合颗粒度比MRD小，当然也可以是写User Story。我们的做法相对“宽松”只要描述清晰就好，形式没有要求。Backlog的管理我们放在了一个Wiki的表格中，每个Backlog的管理，需要考虑以下细节：
id: 需求编号，便于追踪
title: 标题
description: 需求详细描述
priority : 优先级
fesibility study: 是否需要需求分析
solution: 是否需要架构／方案设计
review: 是否需要评审需求分析或方案
status: 当前状态
action: 计划的实施的版本
日常操作上，我们的方式是每个大迭代开始前，和相关的关系人（通常是你的领导，或者商务的代表等）一起过这张表格，在理解、优先级等方面达成一致。
工作Task!=Backlog
在团队日常工作任务管理，包括planning game中需要预先定义出来评估的任务，直接使用backlog是不合适。我们的做法backlog通常是一个比较大的feature(功能特性)，需要做详细的分解如需要分为：前端开发、后端开发、测试点设计、性能测试等等。
用作task管理的工具很多，不过我们为了简便直接使用gitlab的issue来做管理，同时开发在提交代码的时候同时注明issue的id（git commit的时候备注写#xxx），这样做代码评审就可以关联看具体是什么问题做的提交了。Backlog拆解成task的颗粒度的把握是比较讲求艺术的地方，太细的话工作起来比较繁琐，太粗不容易跟踪协调。建议是3天内的工作做为一个大小参考值，不过如果团队比较不够成熟的话，建议控制在1天内的维度比较好，这样每天的站会沟通容易尽早发现问题并作出调整。
4开发与测试的配合
沟通、沟通还是沟通，团队配合无论什么角色，最重要的还是沟通，顺畅的沟通。沟通的效率很大程度上反映了一个团队的成熟程度。但是在工作中，由于工具的多样化，使很多人把人与人之间的沟通变成了人与工具的沟通。有些很搞笑的例子给大家分享下，曾经看见过肩靠肩坐的两位仁兄在互相写一对一的邮件。最经常发生的是，对于可以立即解决的问题，大家的屁股不愿意离开自己的座位相互间说一声，而是大篇幅的和IM工具沟通。其实离开下座位对大家身体也有好处。
开发和测试的信息来源将都来自于产品需求，而不再通过开发提测试提要求的模式。
开发与测试的定位的转化。在Scrum模式下，开发与测试的工作边界将更加模糊。开发在做测试用例开发，测试也在做测试用例的开发。但是测试有个最主要的功能是测试点的设计，如何设计出更全面，更有条理的测试点，协助开发思考实现过程中遗漏的需求、遗漏的异常保护等才是测试的价值所在。而不是通过复杂的重复性工作来体现测试的价值。
测试应该更好的思考如何提供便利的工具、便利环境让开发很快得到代码的测试结果。如在30分钟内就可以评估出来新功能的引入是否对性能造成了影响。
开发则应该配合测试一起详细review测试点的设计，并从而思考开发中潜在的问题。在某些代码作出改变的时候，则应立即提醒测试潜在的风险做好相应的回归。
前面一篇《唯品会敏捷Scrum实践系列1：团队组成和人员配比》，我提到了我个人是反对“提测”这个概念和做法的，因为这样会人为的割裂开发与测试。Scrum模式下开发每做一个特性都应该是可以运行的，测试不应该等待整个迭代完成才开始测试，而是在每个可以端到端运行的功能特性完成的时候就进入测试。开发的迭代是一个一个的小循环，测试也应该是一个一个的小循环。“提测”概念下你总会听到这样的声音：“你真的做完了？你单元测试也做了？别让我重复测哦。”
那么什么尺度把控测试开始工作呢？答案是Demo。每个功能特性，在大家都难以把控是否能做完整的情况下，团队任何成员都可以提出需要开发的作者做演示的要求。一来可以让产品来看看是否满足他的需求，二来测试也可以看看是否有信心开始做相关的测试。
最后，我用我常说的一句话作为总结：开发应该Drive测试，测试应该Drive开发。
版本管理的痛苦
白板的使用
站会说什么，怎么说
如何做Done of Definition:DoD
Planning game–细评估还是初评估
团队氛围
230721
1、导入Mongo Monitor监控工具表结构（mongo_monitor…
上面提到： 在问题描述的架构图中我们可以看到，Click…
PMM不香吗？
如今看都很棒