敏捷研發(fā)在10年以前就已經(jīng)發(fā)起，到現(xiàn)在是如火如荼，大有取代瀑布式開(kāi)發(fā)的趨勢(shì)，然而是否所有的軟件研發(fā)都可以用敏捷研發(fā)呢？這個(gè)還不能輕易下結(jié)論。

回顧一下敏捷研發(fā)的優(yōu)勢(shì)，如果要總結(jié)一句話，那就是“快速響應(yīng)用戶的需求變化”，這里有幾個(gè)關(guān)鍵詞，“快速響應(yīng)”，“用戶”，“變化”。

先說(shuō)“用戶”

敏捷是一種很好的方法可以打造用戶喜愛(ài)的產(chǎn)品，這里的用戶是人。因此，敏捷研發(fā)用的好的地方多是面向人的業(yè)務(wù)系統(tǒng)，或者toC的產(chǎn)品。敏捷里用于收集需求的方法叫“user story”，里面的第一項(xiàng)內(nèi)容就是“作為...角色的用戶，她/他想要....,因此才能....”. 這種需求收集是以用戶為中心的。因此，凡事遇到重交互的系統(tǒng)，敏捷方法都可以很好的工作。
反之如果是平臺(tái)系統(tǒng)，比如開(kāi)發(fā)一套后臺(tái)系統(tǒng)，或者一套數(shù)據(jù)采集和分析系統(tǒng)，大量的工作都是后臺(tái)的計(jì)算邏輯，這種需求分析的方式就不工作了。

再說(shuō)“需求變化”

敏捷方法里還有一種假設(shè)是用戶的需求會(huì)頻繁的變化，這種變化的原因體現(xiàn)在一下幾點(diǎn)

• toC的市場(chǎng)變化快
• toC的用戶的反饋難以預(yù)測(cè)
• toB的用戶難以把需求一次描述清楚

基本是以上幾點(diǎn)，導(dǎo)致了“需求變化”這個(gè)假設(shè)。這幾種假設(shè)通常發(fā)生在下面的情境中

• 新產(chǎn)品，新投入市場(chǎng)的產(chǎn)品需要快速響應(yīng)用戶的反饋
• 大項(xiàng)目，項(xiàng)目的相關(guān)方太多，各方的意見(jiàn)無(wú)法一次性的表達(dá)清楚，需要逐步的迭代

因此，有一些小的內(nèi)部項(xiàng)目，歷時(shí)1個(gè)月，產(chǎn)品出個(gè)PRD，2，3個(gè)研發(fā)去開(kāi)發(fā)，這類項(xiàng)目無(wú)所謂用什么方法，也出不了大問(wèn)題。

最后說(shuō)“快速響應(yīng)”

提到快速響應(yīng)這個(gè)敏捷優(yōu)勢(shì)，很多瀑布式研發(fā)表示不服，“我們也可以快速響應(yīng)，也可以2周發(fā)一次版本”，雖然他們沒(méi)有單元測(cè)試以及其他自動(dòng)化測(cè)試等技術(shù)。
在這一點(diǎn)上，自然敏捷研發(fā)所強(qiáng)調(diào)的自動(dòng)化技術(shù)是非常先進(jìn)的。快速響應(yīng)要建立在質(zhì)量的基礎(chǔ)之上。而自動(dòng)化技術(shù)較之手工測(cè)試是保證質(zhì)量的利器。
互聯(lián)網(wǎng)公司往往通過(guò)某一款產(chǎn)品而雄霸天下，這時(shí)候，像自動(dòng)化測(cè)試，持續(xù)集成，持續(xù)發(fā)布，灰度發(fā)布，線上監(jiān)控和回滾已經(jīng)被打散到很多的環(huán)節(jié)甚至是部門之中，并且對(duì)于質(zhì)量呈現(xiàn)出多級(jí)防御體系，線下，灰度，線上等等，做到這種程度，響應(yīng)不可說(shuō)不快。

敏捷的優(yōu)勢(shì)“快速響應(yīng)”以及“高質(zhì)量”在互聯(lián)網(wǎng)公司已經(jīng)被平臺(tái)化

為什么要寫這個(gè)文章呢？因?yàn)樵诨ヂ?lián)網(wǎng)公司的敏捷研發(fā)其實(shí)已經(jīng)到了持續(xù)交付的階段，基本上發(fā)布通道已經(jīng)形成了，也就是說(shuō)，只要功能完成，測(cè)試通過(guò)，一個(gè)命令就上去了。

在這樣的環(huán)境下，通常一個(gè)系統(tǒng)的研發(fā)會(huì)分成兩個(gè)階段：

• 第一本大版本上線。也就是初始版本；
• 增量需求，持續(xù)的改進(jìn)；

除非遇到大的改版，否則，一個(gè)產(chǎn)品除了1～2個(gè)月的初試研發(fā)，其余的大部分時(shí)間都在做小步的增量，快速發(fā)版。這種強(qiáng)發(fā)布支撐的產(chǎn)品研發(fā)模式，已經(jīng)為快速響應(yīng)鋪了路。在QA以及灰度發(fā)布等強(qiáng)大的質(zhì)量支撐前提下，研發(fā)不寫單元測(cè)試問(wèn)題也不大，第一個(gè)版本是用瀑布還是敏捷的需求管理方式，問(wèn)題也不大，只要保證1～2個(gè)月做完就可以了。也就是說(shuō)，快速發(fā)布以及質(zhì)量保證已經(jīng)平臺(tái)化了，在這個(gè)前提下，研發(fā)過(guò)程被解放了出來(lái)，可以隨意發(fā)揮。

互聯(lián)網(wǎng)公司研發(fā)是小瀑布

事實(shí)上，互聯(lián)網(wǎng)公司的產(chǎn)品不負(fù)責(zé)需求的拆分，也就是說(shuō)沒(méi)有user story，整個(gè)需求就是一個(gè)PRD傳到研發(fā)隊(duì)伍手上，至于研發(fā)如何拆分，那是研發(fā)需要考慮的事情。研發(fā)接到PRD以后，通常在人力資源短缺的情況下，是按照技術(shù)棧來(lái)劃分的，比如前端H5把所有的前端頁(yè)面都干了，后端的java把所有后端的API全干了，IOS研發(fā)把所有手機(jī)端都干了。這種做法是一種效率最高的方式，當(dāng)然如果第一個(gè)版本時(shí)間拉的過(guò)長(zhǎng)，比如3個(gè)月到半年，這種瀑布做法就有集成風(fēng)險(xiǎn)。如果時(shí)間只有1～2個(gè)月，這種小瀑布、小團(tuán)隊(duì)的工作方式就問(wèn)題不大。到了第一個(gè)版本以后，之后每個(gè)版本的發(fā)版周期會(huì)比較短，產(chǎn)品就會(huì)按照不同的版本來(lái)拆分后續(xù)的需求。

這種產(chǎn)品和研發(fā)配合的方式，解放了PM拆分需求的時(shí)間，跟Scrum中的BA相比，他們可以把更多的時(shí)間放到客戶的分析上產(chǎn)品設(shè)計(jì)上。

除了沒(méi)有user story，敏捷的中的站會(huì)，持續(xù)集成等技術(shù)也會(huì)有選擇的應(yīng)用在研發(fā)實(shí)踐中。

反觀IT服務(wù)公司，為什么一定要BA拆分細(xì)粒度的需求呢？因?yàn)槭菑?qiáng)調(diào)每個(gè)迭代交付的是價(jià)值，強(qiáng)調(diào)的是需求變化的響應(yīng)力。在保證這種響應(yīng)力的同時(shí)，對(duì)于變更管理就造成了極大的挑戰(zhàn)，為了規(guī)避風(fēng)險(xiǎn)，需求必須要拆細(xì)，每個(gè)迭代都要確認(rèn)，這是IT服務(wù)公司作為乙方不得不做的事情。而對(duì)于互聯(lián)網(wǎng)公司，在第一個(gè)版本研發(fā)階段，大可不必這么緊張，因?yàn)槟繕?biāo)不是控制成本，而是搶占市場(chǎng)，所以速度第一，之后還可以逐步改進(jìn)嘛。

小瀑布下項(xiàng)目的度量

瀑布式項(xiàng)目的度量難點(diǎn)在于工作的拆分不一定是按照需求拆分的，可能是首先按照系統(tǒng)模塊拆分，然后再按照需求的時(shí)間劃分milestone。比如一個(gè)2個(gè)月的項(xiàng)目，按照瀑布式操作，研發(fā)拿到了PRD，然后需要分工，前端，后端分開(kāi)幾乎是定律了，然后就是每個(gè)迭代（2周）的計(jì)劃是什么？有的互聯(lián)網(wǎng)公司其實(shí)連小迭代都不做了，通過(guò)每日的站會(huì)就可以看到大家的進(jìn)度。這里還是要建議有階段性的milestone，有一個(gè)迭代的計(jì)劃，讓大家有節(jié)奏感。對(duì)于研發(fā)的leader而言，如果對(duì)于手下的工作十分了解，那通過(guò)每日的站會(huì)就可以做基于經(jīng)驗(yàn)的管理。這種管理方式是比較原始的，不能說(shuō)無(wú)效，但是當(dāng)大領(lǐng)導(dǎo)想看項(xiàng)目進(jìn)展的時(shí)候，就難了，因?yàn)闆](méi)有度量，大領(lǐng)導(dǎo)又不了解項(xiàng)目細(xì)節(jié)，因此即使有周報(bào)，在大領(lǐng)導(dǎo)看來(lái)也是感覺(jué)“大雜燴”，沒(méi)有可比性，沒(méi)有度量，沒(méi)有指標(biāo)，無(wú)法管理，甚至無(wú)法給意見(jiàn)。

由此產(chǎn)生的困難是，大家感覺(jué)都很忙，都需要人手，但是高層領(lǐng)導(dǎo)不曉得你們到底在忙什么？為什么需要這么多人。這是一個(gè)野蠻式增長(zhǎng)的企業(yè)的通病。這個(gè)就涉及到項(xiàng)目組合（portfolio的）管理。因此，研發(fā)體制是否需要改為項(xiàng)目制，誰(shuí)是系統(tǒng)的owner，又是另外一個(gè)話題。

互聯(lián)網(wǎng)公司為什么需要PMO

互聯(lián)網(wǎng)公司的發(fā)布以及質(zhì)量保證體系已經(jīng)很厲害了，研發(fā)管理又有產(chǎn)品經(jīng)理和tech leader負(fù)責(zé)，這個(gè)結(jié)構(gòu)類似于一個(gè)在研發(fā)流程下的職能組織，業(yè)務(wù)運(yùn)營(yíng)，產(chǎn)品部，研發(fā)部，QA部，運(yùn)維，各個(gè)部門的人按照產(chǎn)品線來(lái)分組，每個(gè)人都是雙向匯報(bào)。

項(xiàng)目經(jīng)理的價(jià)值在于某些事情需要綜合多個(gè)產(chǎn)品線，多個(gè)部門，比如產(chǎn)品整合，流程改造等等，就需要一個(gè)人來(lái)統(tǒng)一協(xié)調(diào)，這個(gè)角色由任何的產(chǎn)品線中的人來(lái)負(fù)責(zé)都不合適。

而換言之，如果一個(gè)產(chǎn)品研發(fā)沒(méi)有橫跨多個(gè)產(chǎn)品線，PMO的管理工作就有些畫蛇添足了。