敏捷研发在10年以前就已经发起，到现在是如火如荼，大有取代瀑布式开发的趋势，然而是否所有的软件研发都可以用敏捷研发呢？这个还不能轻易下结论。
回顾一下敏捷研发的优势，如果要总结一句话，那就是“快速响应用户的需求变化”，这里有几个关键词，“快速响应”，“用户”，“变化”。
先说“用户”
敏捷是一种很好的方法可以打造用户喜爱的产品，这里的用户是人。因此，敏捷研发用的好的地方多是面向人的业务系统，或者toC的产品。敏捷里用于收集需求的方法叫“user story”，里面的第一项内容就是“作为...角色的用户，她/他想要....,因此才能....”. 这种需求收集是以用户为中心的。因此，凡事遇到重交互的系统，敏捷方法都可以很好的工作。
反之如果是平台系统，比如开发一套后台系统，或者一套数据采集和分析系统，大量的工作都是后台的计算逻辑，这种需求分析的方式就不工作了。
再说“需求变化”
敏捷方法里还有一种假设是用户的需求会频繁的变化，这种变化的原因体现在一下几点
- toC的市场变化快
- toC的用户的反馈难以预测
- toB的用户难以把需求一次描述清楚
基本是以上几点，导致了“需求变化”这个假设。这几种假设通常发生在下面的情境中
- 新产品，新投入市场的产品需要快速响应用户的反馈
- 大项目，项目的相关方太多，各方的意见无法一次性的表达清楚，需要逐步的迭代
因此，有一些小的内部项目，历时1个月，产品出个PRD，2，3个研发去开发，这类项目无所谓用什么方法，也出不了大问题。
最后说“快速响应”
提到快速响应这个敏捷优势，很多瀑布式研发表示不服，“我们也可以快速响应，也可以2周发一次版本”，虽然他们没有单元测试以及其他自动化测试等技术。
在这一点上，自然敏捷研发所强调的自动化技术是非常先进的。快速响应要建立在质量的基础之上。而自动化技术较之手工测试是保证质量的利器。
互联网公司往往通过某一款产品而雄霸天下，这时候，像自动化测试，持续集成，持续发布，灰度发布，线上监控和回滚已经被打散到很多的环节甚至是部门之中，并且对于质量呈现出多级防御体系，线下，灰度，线上等等，做到这种程度，响应不可说不快。
敏捷的优势“快速响应”以及“高质量”在互联网公司已经被平台化
为什么要写这个文章呢？因为在互联网公司的敏捷研发其实已经到了持续交付的阶段，基本上发布通道已经形成了，也就是说，只要功能完成，测试通过，一个命令就上去了。
在这样的环境下，通常一个系统的研发会分成两个阶段：
- 第一本大版本上线。也就是初始版本；
- 增量需求，持续的改进；
除非遇到大的改版，否则，一个产品除了1～2个月的初试研发，其余的大部分时间都在做小步的增量，快速发版。这种强发布支撑的产品研发模式，已经为快速响应铺了路。在QA以及灰度发布等强大的质量支撑前提下，研发不写单元测试问题也不大，第一个版本是用瀑布还是敏捷的需求管理方式，问题也不大，只要保证1～2个月做完就可以了。也就是说，快速发布以及质量保证已经平台化了，在这个前提下，研发过程被解放了出来，可以随意发挥。
因此在研发的相关方比较简单的情况下，其实研发管理的很多事情就落到了产品的身上。
互联网公司为什么需要PMO
互联网公司的发布以及质量保证体系已经很厉害了，研发管理又有产品经理和tech leader负责，这个结构类似于一个在研发流程下的职能组织，业务运营，产品部，研发部，QA部，运维，各个部门的人按照产品线来分组，每个人都是双向汇报。
项目经理的价值在于某些事情需要综合多个产品线，多个部门，比如产品整合，流程改造等等，就需要一个人来统一协调，这个角色由任何的产品线中的人来负责都不合适。
而换言之，如果一个产品研发没有横跨多个产品线，PMO的管理工作就有些画蛇添足了。
网友评论