敏捷研发在10年以前就已经发起，到现在是如火如荼，大有取代瀑布式开发的趋势，然而是否所有的软件研发都可以用敏捷研发呢？这个还不能轻易下结论。
回顾一下敏捷研发的优势，如果要总结一句话，那就是“快速响应用户的需求变化”，这里有几个关键词，“快速响应”，“用户”，“变化”。
先说“用户”
敏捷是一种很好的方法可以打造用户喜爱的产品，这里的用户是人。因此，敏捷研发用的好的地方多是面向人的业务系统，或者toC的产品。敏捷里用于收集需求的方法叫“user story”，里面的第一项内容就是“作为...角色的用户，她/他想要....,因此才能....”. 这种需求收集是以用户为中心的。因此，凡事遇到重交互的系统，敏捷方法都可以很好的工作。
反之如果是平台系统，比如开发一套后台系统，或者一套数据采集和分析系统，大量的工作都是后台的计算逻辑，这种需求分析的方式就不工作了。
再说“需求变化”
敏捷方法里还有一种假设是用户的需求会频繁的变化，这种变化的原因体现在一下几点
- toC的市场变化快
- toC的用户的反馈难以预测
- toB的用户难以把需求一次描述清楚
基本是以上几点，导致了“需求变化”这个假设。这几种假设通常发生在下面的情境中
- 新产品，新投入市场的产品需要快速响应用户的反馈
- 大项目，项目的相关方太多，各方的意见无法一次性的表达清楚，需要逐步的迭代
因此，有一些小的内部项目，历时1个月，产品出个PRD，2，3个研发去开发，这类项目无所谓用什么方法，也出不了大问题。
最后说“快速响应”
提到快速响应这个敏捷优势，很多瀑布式研发表示不服，“我们也可以快速响应，也可以2周发一次版本”，虽然他们没有单元测试以及其他自动化测试等技术。
在这一点上，自然敏捷研发所强调的自动化技术是非常先进的。快速响应要建立在质量的基础之上。而自动化技术较之手工测试是保证质量的利器。
互联网公司往往通过某一款产品而雄霸天下，这时候，像自动化测试，持续集成，持续发布，灰度发布，线上监控和回滚已经被打散到很多的环节甚至是部门之中，并且对于质量呈现出多级防御体系，线下，灰度，线上等等，做到这种程度，响应不可说不快。
敏捷的优势“快速响应”以及“高质量”在互联网公司已经被平台化
为什么要写这个文章呢？因为在互联网公司的敏捷研发其实已经到了持续交付的阶段，基本上发布通道已经形成了，也就是说，只要功能完成，测试通过，一个命令就上去了。
在这样的环境下，通常一个系统的研发会分成两个阶段：
- 第一本大版本上线。也就是初始版本；
- 增量需求，持续的改进；
除非遇到大的改版，否则，一个产品除了1～2个月的初试研发，其余的大部分时间都在做小步的增量，快速发版。这种强发布支撑的产品研发模式，已经为快速响应铺了路。在QA以及灰度发布等强大的质量支撑前提下，研发不写单元测试问题也不大，第一个版本是用瀑布还是敏捷的需求管理方式，问题也不大，只要保证1～2个月做完就可以了。也就是说，快速发布以及质量保证已经平台化了，在这个前提下，研发过程被解放了出来，可以随意发挥。
互联网公司研发是小瀑布
事实上，互联网公司的产品不负责需求的拆分，也就是说没有user story，整个需求就是一个PRD传到研发队伍手上，至于研发如何拆分，那是研发需要考虑的事情。研发接到PRD以后，通常在人力资源短缺的情况下，是按照技术栈来划分的，比如前端H5把所有的前端页面都干了，后端的java把所有后端的API全干了，IOS研发把所有手机端都干了。这种做法是一种效率最高的方式，当然如果第一个版本时间拉的过长，比如3个月到半年，这种瀑布做法就有集成风险。如果时间只有1～2个月，这种小瀑布、小团队的工作方式就问题不大。到了第一个版本以后，之后每个版本的发版周期会比较短，产品就会按照不同的版本来拆分后续的需求。
这种产品和研发配合的方式，解放了PM拆分需求的时间，跟Scrum中的BA相比，他们可以把更多的时间放到客户的分析上产品设计上。
除了没有user story，敏捷的中的站会，持续集成等技术也会有选择的应用在研发实践中。
反观IT服务公司，为什么一定要BA拆分细粒度的需求呢？因为是强调每个迭代交付的是价值，强调的是需求变化的响应力。在保证这种响应力的同时，对于变更管理就造成了极大的挑战，为了规避风险，需求必须要拆细，每个迭代都要确认，这是IT服务公司作为乙方不得不做的事情。而对于互联网公司，在第一个版本研发阶段，大可不必这么紧张，因为目标不是控制成本，而是抢占市场，所以速度第一，之后还可以逐步改进嘛。
小瀑布下项目的度量
瀑布式项目的度量难点在于工作的拆分不一定是按照需求拆分的，可能是首先按照系统模块拆分，然后再按照需求的时间划分milestone。比如一个2个月的项目，按照瀑布式操作，研发拿到了PRD，然后需要分工，前端，后端分开几乎是定律了，然后就是每个迭代（2周）的计划是什么？有的互联网公司其实连小迭代都不做了，通过每日的站会就可以看到大家的进度。这里还是要建议有阶段性的milestone，有一个迭代的计划，让大家有节奏感。对于研发的leader而言，如果对于手下的工作十分了解，那通过每日的站会就可以做基于经验的管理。这种管理方式是比较原始的，不能说无效，但是当大领导想看项目进展的时候，就难了，因为没有度量，大领导又不了解项目细节，因此即使有周报，在大领导看来也是感觉“大杂烩”，没有可比性，没有度量，没有指标，无法管理，甚至无法给意见。
由此产生的困难是，大家感觉都很忙，都需要人手，但是高层领导不晓得你们到底在忙什么？为什么需要这么多人。这是一个野蛮式增长的企业的通病。这个就涉及到项目组合（portfolio的）管理。因此，研发体制是否需要改为项目制，谁是系统的owner，又是另外一个话题。
互联网公司为什么需要PMO
互联网公司的发布以及质量保证体系已经很厉害了，研发管理又有产品经理和tech leader负责，这个结构类似于一个在研发流程下的职能组织，业务运营，产品部，研发部，QA部，运维，各个部门的人按照产品线来分组，每个人都是双向汇报。
项目经理的价值在于某些事情需要综合多个产品线，多个部门，比如产品整合，流程改造等等，就需要一个人来统一协调，这个角色由任何的产品线中的人来负责都不合适。
而换言之，如果一个产品研发没有横跨多个产品线，PMO的管理工作就有些画蛇添足了。
