寫在前面
“老闆，我想辭職。”
“怎麼呢？”
“世界這麼大，我想去看看.....”
不要笑，這不是梗，這确實是讓我從通信行業走到網際網路行業的一個原因。身體走再遠也不及思想往出邁一步。
初入網際網路行業，首先感受到的就是項目開發模式上的一個差異，本文就基于前後兩個不同行業不同産品性質不同開發模式的體驗認知做一些比較和分析，也是記錄一下在學習靈活的過程中的一些思路曆程。
從Waterfall到Agile
對于瀑布開發和靈活開發兩種模型的介紹google百度一下都有很多了，為了後面更好的對比分析，這裡還是先簡單描述一下。
瀑布模型是很早之前就出現的一種被廣泛應用的軟體開發模型，它按軟體生命周期講整個過程劃分成需求分析，系統設計，開發，測試，運作維護等幾個步驟，從上至下固定順序，隻有上一個步驟完成下一個步驟才開始，按部就班。就像瀑布一樣，如此開發模式是不走回頭路的，一旦到中後期出現需求變更或者需要返工的情況，花費成本會很大。
瀑布模型的幾個關鍵字：文檔，計劃，裡程碑。
瀑布模型
再說靈活，靈活相較于文檔驅動的瀑布開發，更強調人與人之間溝通的作用，以人為驅動。這裡先暫且将它解釋成一種理念，有多種開發模型方法貫徹了這種理念，例如XP（Extreme Programming）, FDD（Feature-Driven Development），DSDM(Dynamic System Development Method)等，應用最為廣泛也最為大家熟悉的Scrum自然也在其中。
Scrum源于橄榄球裡争球的概念，意為團隊作為一個整體，團隊内部傳球一齊往前進。Scrum是一個增量疊代的開發過程，這個過程在時間上由若幹個Sprint(疊代周期)組成，每個sprint一般為2-4周；在團隊組成上，scrum由三個角色組成：Product Owner，Scrum Master，Scrum Team；産品負責人比較好定位，即我們的PD角色。流程管理者類似一個項目經理的崗位定位，很多公司企業的組織架構中沒有明确的崗位來對應這個角色，這時候可能就會是其他崗位的成員來承擔這部分的任務。ScrumTeam就不過多解釋了，就是包括PO，SM和開發團隊的成員。對于這三個角色比較官方的定義是這樣：
産品負責人（Product Owner）
主要負責确定産品的功能和達到要求的标準，指定軟體的釋出日期和傳遞的内容，同時有權力接受或拒絕開發團隊的工作成果。
流程管理者（Scrum Master）
主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。
開發團隊（Scrum Team）
主要負責軟體産品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以采用任何工作方式，隻要能達到Sprint的目标。
在Scrum中，首先PO将産品需求按優先級形成一個需求清單(産品backlog)，然後按照這個需求清單經過讨論評估确認每個疊代周期裡需要完成的内容(Sprint backlog),在每一個疊代周期之後送出一個産品增量。Scrum就是通過重複疊代和增量來應對激烈市場競争所帶來的各種變化，進而更好的預見風險降低成本。
靈活的幾個關鍵字：人，疊代，靈活。
Scrum開發流程
為什麼不靈活
在簡單描述瀑布開發和靈活開發之後，可以發現靈活開發好像更與時俱進，優勢更明顯一點。那麼接下來，就要問一個問題了，既然靈活開發更有優勢，更好用，在網際網路行業已經風生水起，為什麼像以前老東家那樣的一些公司企業不推行靈活？又或者問為什麼網際網路行業會青睐靈活開發？筆者就目前有限的一些的認知來對比分析一下，覺得以下幾個方面的差異應該是其中一部分原因。為了友善比較，暫且将類似電信通訊行業等典型的傳統企業簡稱T公司，将常見網際網路行業企業簡稱E公司。
T公司
- 産品：企業級産品/解決方案；
- 使用者：需求目标明确，定制化程度高；
- 按照合同傳遞驗收産品；
- 合約制度牽絆需求變化。
E公司
- 産品：面向個體的SaaS(Software-as-a-Service)；
- 使用者：不太清楚自己想要什麼；
- 使用者回報推動産品改進；
- 競争激烈，需求變更頻繁。
首先從産品性質來說，T公司是為客戶提供企業級的軟體産品和解決方案，對于承載産品的相關硬體裝置，網絡等都是不做管理的，大家比較熟悉的金蝶，用友，Oracle等都屬于這一類，常見的企業級軟體有ERP，BI，OA，etc. T公司的盈利收益方式是比較傳統的商品交易模式，甲乙雙方簽訂購買合同，一手交錢 一手交貨，不能說這個是一錘子買賣，但是至少這個産品傳遞會是一個比較規範流程化的過程。T公司項目開發過程往往是乙方認可甲方的解決方案後，從一個PO（purchase order）開始，制定産品傳遞計劃，乙方開始對甲方的具體業務需求做分析，再進入設計編碼測試等後面的步驟，在乙方完成内部産品的測試之後，甲方會真正最終産品的使用者進行驗收測試，簽訂PAC(初驗證書)，隻有最後拿下FAC(終驗證書)，才能進入運作維護階段，而且在驗收過程中，甲方需要向乙方提供比較詳盡完善的文檔。而E公司的産品則是傾向于面向個體(個人/商戶)的軟體服務，使用者通過遠端通路即可使用對應的應用和服務。E公司這種收益模式一般是通過使用者自主線上付費或者收取中間服務費用，又或者像一些免費應用，通過擴大使用者量吸引一些廣告及周邊收費服務。對快速發展的網際網路行業來說，産品多樣化以及收益模式的多樣化也使得産品開發需要通過一種适應性比較強的方式來實作。
再來看使用者需求差異，E公司面對的使用者很多時候往往不清楚自己想要的是什麼，使用者自己也是一直處于一種尋找自己想要的産品的過程中。這個時候就需要我們能快速推出一個使用者能看到能使用的産品版本，強占市場的先機，再通過使用者的回報來改進我們的産品，這個改進過程就是不斷的疊代。再者，在百花齊放創新意識引領主導的網際網路氛圍下，産品競争相比也是愈加激烈的，為了應對這種快速的市場變化，需求變更自然會比較頻繁。相比之下，T公司面對的企業使用者一般都已經有自己固有的業務模式和流程規範，是以需求目标會比較明确，在需求分析階段，大部分的需求變更調整都會落實，再加上合約制度的牽絆，在後續設計開發過程中需求變化沒有那麼頻繁。
基于上述幾個方面的原因，雖然這裡沒有做全方面分析，像企業的組織架構等因素都未放在列，至少可以管中窺豹，意識到兩種不同的開發模式各有特點，靈活開發是好，但不盡适用。沒有最好，隻有最合适。
參考資料及部分圖檔來源：https://www.versionone.com/agile-101/agile-methodologies/
本文來自網易雲社群，經作者陳晨授權釋出。
原文位址：靈活初體驗--沒有最好隻有最合适
更多網易研發、産品、營運經驗分享請通路網易雲社群。