在百度参与过Native APP、PC客户端、PC Web网站几种互联网产品的敏捷改进，无论是团队主动诉求希望转为敏捷开发模式，还是以敏捷流程作为问题解决方案，都是需要从一种模式变革为另一种模式的，在这个过程中，团队会不断地有顾虑和疑问；不同的依托设备或平台又有各自的特点，以至于产品在开发和发布方式上有些许差异；再加上目标或者待解决的问题的不同；所以在进行敏捷流程导入的时候，需要有一定的区别性，不可直接复制或套用。
目前Native APP（以下简称APP）和WEB比较主流，本文结合在百度的一些具体实践，对这两类产品在敏捷导入上的共同注意点和不同点进行了分析，希望给大家一些启发和帮助。
1.敏捷引入出发点
不同产品线实施敏捷的出发点各有不同，不管我们支持的是什么样的团队，事先了解清晰团队敏捷实施的目标是非常必要的。对于APP和WEB来说，他们引入敏捷的出发点有相同之处也有不同之处，我们一起来看一下：
●共同点：传统管理往往是事后的、静态的，各角色各部门之间缺乏及时的交流和沟通，计划与实际偏差大、效率不够高、资源分配不均和重复劳动等等，希望通过敏捷方式的引入来改进信息横向和纵向沟通、任务合理估算和拆分，以及建立稳定主干模式确保始终可验收测试等。
●不同点：APP通常希望通过引入敏捷能建立稳定的发版节奏，并且每个版本要有明显的用户体验改善或重大功能点，同时提升APP质量比如降低Crash率等。而WEB产品通常希望能够通过敏捷改进实现多分支高频上线同时建立用户线上反馈的快速闭环。
2.引入敏捷的思路和方式的共同注意点
不管给什么样的团队引入敏捷，我们都要慎重考虑是否需要直接全面引入所以实践。我们都知道，在研发模式和流程改变的同时，会伴随有团队成员变动、团队士气变化、业务发展变化等情况；如果最后整体效果没有达到预期，而团队又没有深刻理解流程改进的思路，会以为是因为流程改进带来的变化导致，甚至可能回退到原来的模式。针对这样的情况，提出有两点建议供参考：
●调研时深刻理解团队最希望改进什么，如果这个改进是一切的前提，那么首先需要先完成这个改进的基础上，再思考如何引入敏捷。
●在现有流程的基础上，量化团队的产能、周期和效率等，比如每周可以完成多少个需求、是什么样难度和粒度的需求等大概有个了解，在引入敏捷的开始需要保持这样的团队产能，同时带来其他方面的一些改进变化，以保证团队对敏捷引入的信心。
3. 需求拆分和工作量估算和排期方式
●需求拆分：
APP产品比较合理需求拆分方式是按用户价值拆分和依赖关系拆分：比如可以按照闹钟、私信这样对用户直接产生价值的故事拆分；而歌词和播放进度条有依赖，而且一起测试比较合理，可以整合在一起。
WEB产品比较合理的拆分方式是按工作量拆分：因为WEB产品需求点的特点就是小而且互相没有太多依赖，如果按用户价值拆，可能会拆出来一大批小的需求点，不利于规划。比如，批量下载、批量收藏、批量修改都是小的点，可以考虑合并为“批量”这一个故事。
●工作量估算：
关于估算下面有几条比较具体的比较：
上面表格中提到人天和点数这两种基本单位，这里顺带做一点说明：在敏捷中，直接估算人天的好处是直观，坏处是跟具体人员绑定可能产生高估和低估、且不能比较生产率的提升或下降，而故事点数则恰恰相反。所以建议根据实际情况灵活运用，不必过于死板。比如，需要逐渐建立基础故事集（类似增删改这种被高频作为比较基准的故事），或需要把生产率具象化的场景下，使用人天就很方便。
●迭代排期
在按照故事估点等方法进行估算之后，通常需要产出一个排期计划。这里根据实际经验有一点提示：APP产品需要预留20%时间buffer给紧急插入或线上bug，WEB产品需要预留5-10%时间buffer给紧急插入或线上bug（因为web产品修改相对容易）。
4. 迭代划分与优先级
5. 沟通管理方式
6. 验收与测试
7. 其他区别点
关于这两类产品在其他方面的区别点还有很多，这里列举两个：
●运营活动：APP运营活动大多以H5页面的形式展示，需要长期运营的才会直接做在APP中，因此联调起来费时。而WEB网页上相对要快很多，特别是有专题系统和广告系统的话，运营可以自己直接配置。
●线上bug的处理方式：APP只能再发版解决，因此需要估算排期规划。而WEB直接修复上线，甚至可以回滚。
小结
以上是个人基于实际产品线实践的一些心得体会，希望能给正在实施敏捷的团队一些信心，在遇到实践无法实现理想状态时，能够相信自己，也许我们可以选择另外一条路试试：）
（本资讯于2016-03-14首次发布）
