转载自
作者：尘中之光（简书作者）
原文链接：http://www.jianshu.com/p/0127f8f7b3e2
对于敏捷开发，讲它的价值、方法的内容已经够多。而对于需求、设计、测试这三个环节，如何适配并融入敏捷开发的流程，却着墨寥寥。本文主要从产品设计及需求表达两个方面，介绍如何在敏捷开发的背景下，保证产品设计不挖坑，并为开发人员提供的高效支撑。文中所述适用于中小规模的团队，产品形态以web端非成熟期产品为最匹配。
1.远粗近细，规划先行
在整个敏捷流程开始之前，应该先检视如下几项：
（1）BRD & roadmap
此时产品团队已经确定了所有大方向，以及达到这些方向的路径。
（2）外部环境中的关键时间节点
此时应该对接下来两次迭代以内的外部环境（如行业周期、市场压力、节假日等运营引爆点）有较为明确的把握，确保版本方向不会受迫产生较大的变动。
（3）需求池
此时可能已经积累有来自各方的需求，以及产品规划中预计要新增的模块。而每次迭代，需求来源都出自这个表格中。
根据以上，首先通过关键时间节点来修正产品roadmap，细化roadmap中距离当前最近的一段时间，颗粒度最细须达到完成一次敏捷开发的所需要的时间。关于最终细化出来的产品路线，产品经理的脑中一定要有非常清晰的节奏，明确每一步的整体目标。完成后，应该明确下一步迭代的两个内容，一是新增哪个模块/栏目，二是优化哪些功能、页面。
对于新增的模块，我们要让它单独进入敏捷开发流程，必须保证它是相对独立的，不会受到另一个未开发模块的牵制。如果不是，那么这些模块应该在同一次迭代中，以最基本（基本到只剩关键流程）的形态同时上线。
2.先加后减，解构产品
确保新增模块的独立性后，就到了产品设计的环节了。对于产品设计经验不是非常丰富的PM来说，此时，一定确保设计环节的完整，需求分析、用户任务和流程设计、产品结构决不能被“敏捷”掉。直接动手做流程和原型，无论时间多紧都不应该，反而会因为挖坑，导致在以后浪费更多的时间去反复填坑。
我在做敏捷设计的时候，倾向于经由完整的设计流程，产出相对完整的产品设计，然后根据敏捷周期，来对产品进行精简。这样不会因为后期丰富该功能时，由于思考不全面和先前没有一个明确的理想解决方案，而推翻重做或者有较大改动；也保证了产品功能拆分后，各个子单元在不同版本迭代完全时的产品一致性。
我们需要对完整稿进行拆分和优先级排序，找出主要流程、关键信息，先保证主线跑通，再考虑提升用户体验的辅助性功能，以及提升用户停留时长或提高转化率的信息丰富手段。
由于这个完整稿，本身就是用来试错的，那么，我们在细化需求的时候，可以先细化主线需求到能够交付开发执行的程度，而对于可能有变动甚至整体舍弃的其他分支，暂时到特性层面就可以了。
基于完整稿，我们可以提出几种拆分方案，在需求评审时，与开发团队讨论确定最终的目标方案。对于该方案，我们需要在方案内的特性中，再次排出优先级。目的是，让开发先做高优先级特性，如果遇到不可预估的困难，可以马上决策并削减优先级低的特性，保证主流程的完成，尽量弱化工程延期的不利后果。
3.简短明了，文尽其用
关于产品设计后的需求表达，我一直以来的原则就是不参考模板，灵活使用。在敏捷开发中，我们通常不可能去写全面啰嗦的PRD，移动端更甚。我的做法是，使用excel做产品backlog，省去所有对开发无意义的描述说明文字，从feature list直接获得。审视自己写下的每一个列首项，是不是对开发有用，省去所有无用项。
如果团队中没有专职测试，甚至可以将测试功能融合进backlog中，仅需增加测试结果与状态两列，而只要需求想的透彻，特性说明完全可以做基本的功能测试用例。
同时，该表格也可以融入项目管理的功能。状态列中，单元格为下拉菜单，分别有待开发、待测试、完成三个状态。
backlog表头示例
适合每个团队的文档形式各不相同，有的开发喜欢原型结合文档进行开发，有的喜欢看原型做，文档备查，这些都需要PM提前沟通，了解PRD的用户需求，砍掉无效的工作，制作出适合自己团队的文档形式，并自己保证花在文档上的时间，都是有效的。
