敏捷实践之产品规划

任志强 Roger

2019年02月

序  言

敏捷开发近些年在国内软件公司中越来越流行起来，越来越多的公司开始采用敏捷方法并投入精力去研究推广敏捷方法，因此也造就了国内一批又一批敏捷实践者和爱好者，我想当初Kent Beck等敏捷宣言的创始人也未必预见今天敏捷遍地开花的景象吧。

本人从2011年开始在IBM开始接触敏捷开发到后来做Scrum Master到现在的做敏捷教练，在敏捷的学习和实践中受益匪浅。我欣赏甚至是崇拜精益思想和敏捷方法，也特别希望能总结一些想法和心得来记录在这敏捷之路上遇到的困难和问题，从而分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。

系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。如内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目录

序  言... 2

1       概述... 4

从构想开始... 4

2       建立愿景... 4

3       创建产品列表... 4

4       产品发布计划... 5

4.1       固定日期的发布计划... 5

4.2       固定范围的发布计划... 5

4.3       总结... 5

1        概述

敏捷宣言中第四条：“响应变化胜过遵循计划”，很多人说这句话传递的思想告诉我们不需要做各种项目计划和产品规划，探索式开发按需调整、视情况发布版本就可以。我认为敏捷宣言不是告诉大家不做任何计划，而是不提倡耗费时间和金钱去做复杂的、长远的、重仪式的各种计划，因为软件工程尤其是在当今市场环境下，唯一不变的就是变化。而敏捷宣言第四条是说响应变化的能力价值胜过遵循预先制定的计划。

本文要阐述的内容是产品规划，想和读者分享一下敏捷项目中如何做产品规划。本文内容是参考Kenneth S. Rubin的《Scrum精髓》并结合本人在做工作中的实践经历。

从构想开始

产品的诞生一般都是从一个idea开始的。曾经做过一个产品，客户是品牌管理业务部门负责人，第一次和她交流的时候她只是告诉我想做一个图档（各种格式的图片、PSD源文件等）管理系统，只要用户可以在同一个地方上传下载就行。最后这个产品变成了一个在线图档审核、授权、管理和统计系统。

2        建立愿景

在客户有了初步构想后，需要产品负责人在业务层面帮助客户建立一个愿景，引导他将其真正的痛点和业务诉求表达出来。在敏捷中，愿景不是精心制作的冗长的文档，即使很复杂的产品其愿景也应该尽可能的简单描述，体现的是我们理解客户诉求、未来产品的主要特性。如果再加上我们的解决方案足够漂亮，理论上我们可以赢得这个客户的合作信心了。

3        创建产品列表

在传统开发模式中如瀑布模型，我们会将用户需求通过各种手段弄得一清二楚，其实所谓的一清二楚都是在基于“预测”，因为团队辛苦很长时间开发出来的产品也许不是他想要的，也或许客户认为当初的需求和现在的业务或市场已经严重不一致了。

所以，敏捷中我们从概要产品列表即粗略的需求开始，根据价值、风险和依赖关系来排列优先级，一个概要产品列表中总有一些是必须要有的、可以有的甚至是不会有的。需要重点关注的一定是必须有的，因为这些必须有的才是产品列表里面最具价值的条目，是产品规划的重点输入。那些可以有的存在着很大的不确定性，比如成本、时间等制约因素限制。

4        产品发布计划

发布计划对于很多产品来说是个长期的计划，但是在项目初期我们对产品的未来没有足够的预测，产品每个版本应该包含的特性也会随着内外部因素的变化而变化，因此个人建议是引导客户用迭代加增量的方式去开发，将产品列表中价值最大优先级最高的条目作为发布计划的输入，并且发布计划不是一次性事件，而是根据需要和市场反馈随时调整。

第一季度你会发几个版本？第二季度结束产品会包含那些特性？需要花多少钱？其实发布计划要真正落地需要总和考虑客户价值、范围和质量、进度和预算等等因素。既然这么多可变因素，我们就不能用复杂的解法去解决复杂的问题，考虑简单的解法就是固定一部分变量。

4.1      固定日期的发布计划

本人经历的项目采用固定日期发布的比较多，比如在第一季度末3.31要发布第一版本，第二季度发布两个版本。这种情况下，我们需要知道团队在发布日期前能完成哪些产品列表条目以下简称PBI。首先，确定这个版本可以包含多少个冲刺，其次，估算团队的平均速率范围请注意是速率范围，比如一个冲刺可以完成100到120个故事点，用冲刺个数乘以故事点数就是开发团队在这个版本能完成的故事点总数范围，再将必须有的PBI按照价值和优先级映射到各个冲刺中，这样我们可以利用图标的方式得到一个固定日期的发布计划。这种情况下日期和预算可以固定，但范围是灵活的。

4.2      固定范围的发布计划

固定范围听起来貌似和敏捷“响应变化”的价值观冲突，但如果对于简单或者很熟悉的产品，我们可能知道包含哪些特性（这种情况不多见）。这样的话我们就根据确定范围内的PBI的工作量除以团队的速率就可以得到多少个冲刺能完成既定的PBI，再将PBI按照价值和优先级顺序映射到各个冲刺中就可以很容易得到各个PBI大致在哪个冲刺和时间点完成，在你的发布计划里面也比较容易体现某个时间发布的话产品包含哪些特性。

当然由于团队速率是个范围，所以可以按照团队的最大和最小速率算出两个时间点，比较稳妥的方式是用最小速率计算出来的冲刺数来做发布计划，并根据项目进展情况更新发布计划，如果某些特性能比最初的发布计划保质保量提前发布，应该也是所有利益干系人喜闻乐见的好事吧。

4.3      总结

上述两种发布计划固定日期范围可变的方式是敏捷最常见的方式，毕竟我们能清楚准确预测产品所有特性的情况是极少的。