加入星計劃,您可以享受以下權(quán)益:

  • 創(chuàng)作內(nèi)容快速變現(xiàn)
  • 行業(yè)影響力擴(kuò)散
  • 作品版權(quán)保護(hù)
  • 300W+ 專業(yè)用戶
  • 1.5W+ 優(yōu)質(zhì)創(chuàng)作者
  • 5000+ 長期合作伙伴
立即加入
  • 正文
    • 工程開發(fā)的本質(zhì)與瀑布模型
    • 敏捷開發(fā)
    • 敏捷還是瀑布?
    • 總結(jié)
    • 最后,想說的兩點(diǎn)是:
  • 推薦器件
  • 相關(guān)推薦
  • 電子產(chǎn)業(yè)圖譜
申請入駐 產(chǎn)業(yè)圖譜

敏捷or瀑布:你還在糾結(jié)嗎?

2023/06/24
2232
閱讀需 14 分鐘
加入交流群
掃碼加入
獲取工程師必備禮包
參與熱點(diǎn)資訊討論

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

自然界的系統(tǒng)大致可以分為兩種主要的類型,一種是自然形成的,一種是人工制造的。我們在這里只關(guān)注人工制造的系統(tǒng)。因?yàn)槠渖婕暗焦こ涕_發(fā),所以,可以將其稱為:工程系統(tǒng)(Engineering System)。工程系統(tǒng)實(shí)現(xiàn)的過程就是工程開發(fā)的過程。

所有的工程開發(fā),起點(diǎn)都始于需求。無論是一部手機(jī),還是一架飛機(jī),甚至是一棟建筑,它們被開發(fā)出來的目的都是為了滿足某種需求。因?yàn)?,如果這些系統(tǒng)不能滿足某種特定的需求,就不會有人去花費(fèi)時間、金錢和體力去實(shí)現(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è)計完成之后,就是開始實(shí)現(xiàn)了。這個時候,施工隊入場了,不同的人負(fù)責(zé)不同的工作。對于電子產(chǎn)品來說,要有軟件硬件工程師。對于建筑來說,需要泥瓦工、水電、油漆等工種。不論產(chǎn)品如何,這個階段大家都是按照上面的設(shè)計來進(jìn)行實(shí)現(xiàn)。

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

在驗(yàn)收結(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ù)??雌饋磉壿嫼芡槪珜?shí)際應(yīng)用的時候卻可能會遇到很多問題。因?yàn)?,需求(Requirement)可能不全或有錯誤,設(shè)計(Design)的過程中可能會出錯,實(shí)現(xiàn)(Implementation)也可能會出錯,從而導(dǎo)致理想的瀑布模型會不適用于很多復(fù)雜的場景。如果完全按照這種模式開發(fā),就可能出現(xiàn)不斷重啟所有環(huán)節(jié)的情況。

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

從上面的討論我們可以看出,所有的工程開發(fā)都是從需求開始的,要經(jīng)歷需求-設(shè)計-實(shí)現(xiàn)-驗(yà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條原則,如下:

  • 客戶的滿意是最優(yōu)先的。
  • 在整個開發(fā)周期中,需求可以被改變。
  • 在較短的周期內(nèi)頻繁地交付工作軟件。
  • 開發(fā)人員和業(yè)務(wù)人員需要有很好的聯(lián)系。
  • 能夠?qū)﹂_發(fā)人員產(chǎn)生信任和激勵的支持性環(huán)境是關(guān)鍵。
  • 自組織的團(tuán)隊是高質(zhì)量的關(guān)鍵。
  • 團(tuán)隊本身定期反思改進(jìn)自己。
  • 面對面的會議和同地辦公始終是首選。
  • 可以工作的軟件是衡量成功的主要標(biāo)準(zhǔn)。
  • 卓越的技術(shù)和強(qiáng)大的設(shè)計是持續(xù)關(guān)注的焦點(diǎn)。
  • 簡潔性是必不可少的。
  • 可持續(xù)發(fā)展和持續(xù)的步伐是敏捷的本質(zhì)。

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

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

敏捷開發(fā)方法的主要特點(diǎn)是通過小型團(tuán)隊的合作來實(shí)現(xiàn)快速迭代。但仍然遵循著需求、設(shè)計、實(shí)現(xiàn)、驗(yàn)證的流程,這一點(diǎ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)的回答,就只能是:看情況了。

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

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

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

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

當(dāng)你的軟件項(xià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é)點(diǎn)的要求。

總結(jié)

1. 開發(fā)的本質(zhì)都是要從需求開始,經(jīng)歷需求-設(shè)計-實(shí)現(xiàn)-驗(yàn)證-維護(hù)的階段。只不過不同的項(xiàng)目或不同的組織選擇了不同的迭代周期和開發(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. 選擇敏捷還是瀑布,需要考慮的點(diǎn)很多,至少包括:團(tuán)隊規(guī)模,項(xiàng)目規(guī)模,開發(fā)需求是否明確,人員能力,人員穩(wěn)定性,團(tuán)隊氛圍,項(xiàng)目是否需要持續(xù)維護(hù)等。

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

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

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

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

最后,想說的兩點(diǎn)是:

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

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

 

 

推薦器件

更多器件
器件型號 數(shù)量 器件廠商 器件描述 數(shù)據(jù)手冊 ECAD模型 風(fēng)險等級 參考價格 更多信息
M39029/56-348 1 Glenair Inc Connector Accessory,
$0.89 查看
CRCW04024K99FKEDC 1 Vishay Intertechnologies Fixed Resistor, Metal Glaze/thick Film, 0.063W, 4990ohm, 50V, 1% +/-Tol, 100ppm/Cel, Surface Mount, 0402, CHIP
$0.06 查看
CRCW040210K0FKTDBC 1 Vishay Intertechnologies Fixed Resistor, Metal Glaze/thick Film, 0.063W, 10000ohm, 50V, 1% +/-Tol, 100ppm/Cel, Surface Mount, 0402, CHIP
$0.01 查看

相關(guān)推薦

電子產(chǎn)業(yè)圖譜

既搞過通信,也做過零部件,正在做整車;既做過開發(fā),也搞過測試,參與過生產(chǎn);經(jīng)歷過民企、合資,也去過外資、國企;既醉心于工程技術(shù),也研究人文歷史;豐富的經(jīng)歷,跨界的經(jīng)驗(yàn),造就了不一樣的思考角度。

TA的熱門作品
車圈兒好卷啊!
  • 集中式架構(gòu)-想集中要咋辦?
  • 集中式架構(gòu)-多集中算集中?
  • 管理之道:汽車電子電氣系統(tǒng)-四類關(guān)系管理解讀
  • 從無到有—如何開發(fā)汽車電子電氣架構(gòu)
  • 查看更多