敏捷or瀑布：你還在糾結(jié)嗎？

工程開發(fā)的本質(zhì)與瀑布模型

自然界的系統(tǒng)大致可以分為兩種主要的類型，一種是自然形成的，一種是人工制造的。我們在這里只關(guān)注人工制造的系統(tǒng)。因為其涉及到工程開發(fā)，所以，可以將其稱為：工程系統(tǒng)（Engineering System）。工程系統(tǒng)實現(xiàn)的過程就是工程開發(fā)的過程。

所有的工程開發(fā)，起點都始于需求。無論是一部手機(jī)，還是一架飛機(jī)，甚至是一棟建筑，它們被開發(fā)出來的目的都是為了滿足某種需求。因為，如果這些系統(tǒng)不能滿足某種特定的需求，就不會有人去花費時間、金錢和體力去實現(xiàn)它。

當(dāng)需求基本確定了之后，接下來要做的就是進(jìn)行設(shè)計。此時需要做的是確定這個系統(tǒng)使用在什么樣的環(huán)境內(nèi)，有哪些主要的組成部分（組件），它們之間是怎么連接（結(jié)構(gòu)）的，需要滿足哪些標(biāo)準(zhǔn)（原則）等。這個相當(dāng)于系統(tǒng)架構(gòu)的設(shè)計，或者是系統(tǒng)的詳細(xì)設(shè)計。如果系統(tǒng)復(fù)雜到需要多個人參與設(shè)計，那么架構(gòu)設(shè)計就是必不可少的。負(fù)責(zé)設(shè)計架構(gòu)的人把系統(tǒng)分為多個子系統(tǒng)，并規(guī)定好每個子系統(tǒng)的邊界和接口等一系列要求，再由相應(yīng)的人進(jìn)行更詳細(xì)的設(shè)計。

設(shè)計完成之后，就是開始實現(xiàn)了。這個時候，施工隊入場了，不同的人負(fù)責(zé)不同的工作。對于電子產(chǎn)品來說，要有軟件、硬件工程師。對于建筑來說，需要泥瓦工、水電、油漆等工種。不論產(chǎn)品如何，這個階段大家都是按照上面的設(shè)計來進(jìn)行實現(xiàn)。

施工完成后，需要做的是驗收。不管產(chǎn)品是哪一種，驗收都可以分為兩類：驗證（Verification）和確認(rèn)（Validation）。驗證活動檢查的是產(chǎn)品是不是按照設(shè)計實現(xiàn)了，確認(rèn)檢查的是產(chǎn)品是不是確實是用戶想要的。對于建筑物來說，設(shè)計的時候是10層樓，結(jié)果蓋成了9層樓，那么就是不合格的，因為不符合設(shè)計?？墒侨绻O(shè)計的時候就注明了每層樓高2米，而客戶需要的是3米的層高，那么即使驗證合格了，確認(rèn)環(huán)節(jié)也不合格。

在驗收結(jié)束后，產(chǎn)品就可以交付給用戶使用了。在一段時間內(nèi)，產(chǎn)品的提供方還需要持續(xù)的對產(chǎn)品進(jìn)行維護(hù)，產(chǎn)品出了問題時，產(chǎn)品的提供方就需要及時給解決。這個過程相當(dāng)于售后的質(zhì)保。

以上的過程就可以采用瀑布模型（Waterfall Model）進(jìn)行表示。

瀑布模型的發(fā)展經(jīng)歷了幾個階段，1956年在一篇關(guān)于軟件開發(fā)的論文中首次提到。在接下來的幾十年里，它被不斷完善，最后被美國國防部采用，作為承包商需要遵循的標(biāo)準(zhǔn)。瀑布模型描述了一種按照一定順序處理開發(fā)過程步驟的方法。

瀑布模型中，所有的工作都是順序的，是一層層流下來的，像瀑布的水流一樣，是單向的。純粹的瀑布模型的本質(zhì)是，在進(jìn)入下一個步驟之前，必須完全完成本步驟的所有任務(wù)?？雌饋磉壿嫼芡?，但實際應(yīng)用的時候卻可能會遇到很多問題。因為，需求（Requirement）可能不全或有錯誤，設(shè)計（Design）的過程中可能會出錯，實現(xiàn)（Implementation）也可能會出錯，從而導(dǎo)致理想的瀑布模型會不適用于很多復(fù)雜的場景。如果完全按照這種模式開發(fā)，就可能出現(xiàn)不斷重啟所有環(huán)節(jié)的情況。

實際的開發(fā)過程中，往往很少完全按照瀑布模型開展，產(chǎn)品一般都要經(jīng)歷多次迭代。我們所熟悉的水果手機(jī)也不是在一出現(xiàn)就這么NB的，而是從1,2,3,4……一代代發(fā)展而來的。

從上面的討論我們可以看出，所有的工程開發(fā)都是從需求開始的，要經(jīng)歷需求-設(shè)計-實現(xiàn)-驗證-維護(hù)的階段。瀑布模型反映的就是這個本質(zhì)。

敏捷開發(fā)

開發(fā)背景下的敏捷（Agile）一詞最早出現(xiàn)在2001年的猶他州的雪鳥會議上。在這場傳奇性的會議上，一些軟件人士聚集在一起，討論軟件編程的革命性方法。雖然那時極限編程（與Scrum相當(dāng)相似）已經(jīng)建立，但許多人仍然對沉重的軟件開發(fā)過程和非常長的開發(fā)時間感到沮喪。復(fù)雜的系統(tǒng)如航天飛機(jī)的開發(fā)時間超過了20年。

猶他州的那些人創(chuàng)造了敏捷宣言 [ https://agilemanifesto.org/]，描述了敏捷開發(fā)的主要原則，但其根源可以追溯到20世紀(jì)60年代人們開始嘗試快速開發(fā)之時。Scrum這種最流行的敏捷方法之一，也是在1995年初開發(fā)的。

《敏捷宣言》描述了12條原則，如下：

l 客戶的滿意是最優(yōu)先的。

l 在整個開發(fā)周期中，需求可以被改變。

l 在較短的周期內(nèi)頻繁地交付工作軟件。

l 開發(fā)人員和業(yè)務(wù)人員需要有很好的聯(lián)系。

l 能夠?qū)﹂_發(fā)人員產(chǎn)生信任和激勵的支持性環(huán)境是關(guān)鍵。

l 自組織的團(tuán)隊是高質(zhì)量的關(guān)鍵。

l 團(tuán)隊本身定期反思改進(jìn)自己。

l 面對面的會議和同地辦公始終是首選。

l 可以工作的軟件是衡量成功的主要標(biāo)準(zhǔn)。

l 卓越的技術(shù)和強大的設(shè)計是持續(xù)關(guān)注的焦點。

l 簡潔性是必不可少的。

l 可持續(xù)發(fā)展和持續(xù)的步伐是敏捷的本質(zhì)。

敏捷是項目管理和開發(fā)過程的混合物。Scrum以及Kanban可以被認(rèn)為是純粹的項目管理方法。其他的敏捷方法，如測試驅(qū)動開發(fā)、結(jié)對編程和持續(xù)集成，則是在軟件開發(fā)或是質(zhì)量保證方面。

敏捷開發(fā)中，與軟件有關(guān)的和與人有關(guān)的主題被很好的整合了。這就是敏捷的關(guān)鍵因素之一：工程師和他們的合作是成功的關(guān)鍵。對于那些習(xí)慣于以孤立的方式工作而不合作的人來說，他們無法通過Scrum這樣的項目管理方式來管理。

敏捷開發(fā)方法的主要特點是通過小型團(tuán)隊的合作來實現(xiàn)快速迭代。但仍然遵循著需求、設(shè)計、實現(xiàn)、驗證的流程，這一點與瀑布式并無不同。與瀑布式開發(fā)不同的是，它的每一輪迭代的周期要小得多，通常以周為單位。它們的創(chuàng)建是為了快速交付并從用戶或利益相關(guān)者那里獲得早期反饋。這樣做的好處是，產(chǎn)品能更快地到最終用戶手中，而且反饋也能更快地回到開發(fā)團(tuán)隊中。團(tuán)隊致力于根據(jù)反饋和優(yōu)先級迅速調(diào)整方向，所以上述所有問題都通過短的反饋周期和透明度來解決。最后，團(tuán)隊致力于持續(xù)改進(jìn)。每個沖刺結(jié)束時都有一個回顧會，每個人都有機(jī)會發(fā)言，討論下一輪可能進(jìn)行的改進(jìn)。

敏捷還是瀑布？

究竟應(yīng)該采用哪種開發(fā)方式？這個問題就像一個人問：應(yīng)該吃蔬菜還是肉呢？如果籠統(tǒng)的回答，就只能是：看情況了。

不同的公司、不同的項目有不同的特點和要求，無法一概而論。簡單而言，敏捷更適合那種需要不斷快速試錯的項目，而且對團(tuán)隊能力的要求很高。當(dāng)需求不清楚或?qū)崿F(xiàn)方案不清楚的時候，采用敏捷方式可以快速交付原型產(chǎn)品，得到客戶的反饋，并能夠讓團(tuán)隊聚焦在高優(yōu)先級的任務(wù)上，從而提升交付效率。

然而，對于那些需求清晰、團(tuán)隊規(guī)模大的項目，敏捷則并不一定能夠發(fā)揮很好的作用。這種情況下，如果有很好的架構(gòu)設(shè)計，每個模塊或子系統(tǒng)的接口、邊界和需求都清晰的時候，每個子團(tuán)隊完全可以按部就班的開展工作，每個人都有明確的職責(zé)和角色，也無需每兩周就交付一個版本，只需要按照既定的里程碑工作即可。此時，傳統(tǒng)的類似瀑布式的開發(fā)可能更為合適。尤其是在那些增量型的項目中：很多人在一個平臺上修修補補，只要大家能夠各司其職，有人在統(tǒng)一管理也就沒有問題了。

敏捷在很大程度上還涉及團(tuán)隊精神、團(tuán)隊授權(quán)和合作。如果一個團(tuán)隊中的氛圍不好，也沒有得到充分授權(quán)，那么采用敏捷也無法提升效率。另外，假如每個工程師都需要同時負(fù)責(zé)多個項目的事情，敏捷也沒有辦法開展起來。

在有些人的眼中，瀑布就代表著落后，敏捷就代表著先進(jìn)，這個未免有失偏頗。如同青菜與肉、跑車與拖拉機(jī)一樣，沒有好壞，只有適合與否。而且，我還從沒有看到過那個項目是完全按照瀑布式開發(fā)的。所有的項目都是按照計劃在最終版發(fā)布前有多個過程版本發(fā)布的，這也就是說，實際工程開發(fā)中也是按照敏捷的思想在開展的，只不過形式不同，迭代的周期不同而已。

當(dāng)你的軟件項目有幾十個開發(fā)人員，產(chǎn)品規(guī)模遠(yuǎn)大于一個團(tuán)隊所能開發(fā)的規(guī)模，而且還需要快速地進(jìn)行交付，那該怎么辦？業(yè)界已經(jīng)定義了一些方法來將Scrum擴(kuò)展到更大的軟件產(chǎn)品。擴(kuò)展的Scrum方法包括Nexus、LeSS（Large Scale Scrum）和SAFe（Scaled Agile Framework）。基本的思想是：小的開發(fā)團(tuán)隊向更高層次的團(tuán)隊交付，以此類推，直到完整的產(chǎn)品完成。可能需要一些新的規(guī)則、工件、團(tuán)隊和會議。

在古老的汽車行業(yè)，雖然軟件越來越重要，但軟件不是汽車中的唯一組件，軟件還需要與硬件和機(jī)械相結(jié)合才能有用武之地，軟件的開發(fā)也要匹配整車開發(fā)的時間線和SOP節(jié)點的要求。

總結(jié)

1.開發(fā)的本質(zhì)都是要從需求開始，經(jīng)歷需求-設(shè)計-實現(xiàn)-驗證-維護(hù)的階段。只不過不同的項目或不同的組織選擇了不同的迭代周期和開發(fā)方式。不同復(fù)雜度的產(chǎn)品經(jīng)歷的迭代輪次不同，開發(fā)周期也不同，但目的都是相同的：滿足需求，交付系統(tǒng)！

2.如果從大的時間尺度來看，所有被持續(xù)更新的工程系統(tǒng)都是逐漸增長起來的，這與敏捷的思想很接近。產(chǎn)品都是從簡單到復(fù)雜的，功能是逐漸增長的，大樓也是一層的蓋起來的，汽車在剛剛出現(xiàn)的時候與現(xiàn)在所看到的完全不同，Windows操作系統(tǒng)也是逐漸演進(jìn)的，控制器的軟件也是演進(jìn)而來的。

3.Kanban和Sprint等都是一種工具或方法，而工具和方法都必然有自己的適用范圍，在不同的情況下，要靈活使用，沒有萬能的工具。

4.選擇敏捷還是瀑布，需要考慮的點很多，至少包括：團(tuán)隊規(guī)模，項目規(guī)模，開發(fā)需求是否明確，人員能力，人員穩(wěn)定性，團(tuán)隊氛圍，項目是否需要持續(xù)維護(hù)等。

5.當(dāng)需求明確，技術(shù)方案也明確，也就是比較簡單的時候，使用瀑布。當(dāng)需求不明確或技術(shù)方案不明確，使用敏捷。

6.敏捷的好處是減少試錯成本，快速交付，不斷優(yōu)化開發(fā)過程（資源、能力、流程等）。

7.敏捷也是一種流程，而非沒有流程。

8.敏捷與瀑布并非對立的，如同青菜與肉一樣，兩者的適度結(jié)合才能有更好地產(chǎn)出。敏捷是一種思想和意識，而非教條。

最后，想說的兩點是：

1.如果你的項目不是一錘子買賣，也就是還需要不斷迭代升級和維護(hù)，那么還是老老實實寫好文檔。這與敏捷還是瀑布無關(guān)，因為你的團(tuán)隊不可能沒有人員變動，人員也不可能永遠(yuǎn)都清楚地記得自己幾年前做了什么。

2.看清事物本質(zhì)就不會迷茫，盲目的采用敏捷并不能保證效率一定高。瀑布還是敏捷，本質(zhì)上都是一種方式，靈活的在不同的時期采用不同的方式才是明智之舉。固執(zhí)的認(rèn)為某種方式可以普適于所有情況，就是守株待兔、刻舟求劍、枉曲直湊！

end