▲ 題圖

什么是 RAD ？

快速應(yīng)用程序開發(fā)（RAD）是一種專注于設(shè)計和原型設(shè)計階段的開發(fā)方法，目的是獲得用戶的即時反饋。與先進(jìn)行初始計劃再進(jìn)一步執(zhí)行的傳統(tǒng)開發(fā)模型不同，RAD 有著更多的靈活性。通過快速增量更新和即時用戶反饋的不斷迭代，使得最終能獲得更好的產(chǎn)出結(jié)果。

詹姆斯·馬?。↗ames Martin）于 1991 年定義了快速應(yīng)用程序開發(fā)（RAD）的模型，提供了除瀑布式開發(fā)過程之外的另一種開發(fā)過程。經(jīng)典的瀑布方式能完美地適應(yīng)建筑領(lǐng)域和其他一些行業(yè)，這些行業(yè)中，需求范圍一般很少變動，且變動的代價非常高。例如，如果開始建造一座橋梁，則不可能在完成一半時將其改建成一條渡輪。

相反，軟件的開發(fā)過程卻是比較靈活的。對同一業(yè)務(wù)需求的解決方案通常不止一個，且變換解決方案的成本較低。因此，基于瀑布式的詳細(xì)設(shè)計和提前規(guī)劃通常會輸給快速試錯的開發(fā)方式，還有，站在用戶的角度，往往只有在看到具體的產(chǎn)品時，才能有思路并提供更好的反饋。

快速應(yīng)用程序開發(fā)方法論的核心是從費時費力的計劃工作轉(zhuǎn)移到快速建立產(chǎn)品的原型上來。具體來說，RAD 模型將軟件開發(fā)過程分為四個階段：

▲ RAD 流程

1. 需求計劃

在此階段，用戶和項目團(tuán)隊一起確定目標(biāo)系統(tǒng)未來要達(dá)到的目標(biāo)。主要關(guān)注于需要實現(xiàn)的業(yè)務(wù)目標(biāo)，對于需求的嚴(yán)謹(jǐn)性沒有太多要求。在原型設(shè)計階段快速調(diào)整業(yè)務(wù)目標(biāo)及需求的能力是關(guān)鍵。

2. 用戶設(shè)計

用戶設(shè)計是快速應(yīng)用程序開發(fā)方法的核心部分，是與瀑布模型相區(qū)別的關(guān)鍵點。這時，開發(fā)人員開始構(gòu)建系統(tǒng)原型。目標(biāo)是通過最快、成本最低的方式給用戶提供一些可演示的內(nèi)容。原型產(chǎn)品可以只滿足一部分需求，或者只覆蓋少數(shù)場景，并且，在代碼編寫時，也可以抄近路。

在原型準(zhǔn)備好后，會拿給用戶演示。開發(fā)團(tuán)隊盡可能收集所有的反饋，這里，原始需求會不可避免地發(fā)生改變：紙上似乎正確的東西在應(yīng)用程序中可能完全不同。根據(jù)這些反饋，開發(fā)人員會重新修改原型，直到用戶對結(jié)果感到滿意。

3. 軟件開發(fā)

現(xiàn)在我們已經(jīng)確切地知道了需要完成的內(nèi)容。開始進(jìn)行實質(zhì)性地開發(fā)并測試，以便按期交付產(chǎn)品。這個階段不能再走捷徑了，需要關(guān)注產(chǎn)品的質(zhì)量、可伸縮性、可維護(hù)性等等。并且，用戶會一直參與對產(chǎn)品進(jìn)行反饋，直到開發(fā)的最后階段。在快速應(yīng)用程序開發(fā)的周期的這個階段，仍然可以接收需求的一些小調(diào)整。

根據(jù)我們選擇的開發(fā)工具和其他因素，我們在設(shè)計階段開發(fā)的原型可能會直接廢棄不用。

4. 部署上線

這是最后階段，包括驗收測試、產(chǎn)品上線和用戶培訓(xùn)。

快速應(yīng)用程序開發(fā)的優(yōu)缺點

RAD 將天平從可預(yù)測性傾向至敏捷性，這樣會帶來一些正面和負(fù)面的影響。

• 優(yōu)點

1. 高質(zhì)量

有了用戶在原型階段的深度參與，最終的完成的系統(tǒng)能更加貼合他們的需求，用戶的滿意度相對較高。

2. 降低風(fēng)險和成本

使用瀑布式開發(fā)方法，用戶只能在項目交付時看到結(jié)果并提供反饋。在這一階段如果再進(jìn)行需求變更，將會費錢又費力。而使用 RAD 方法時，在原型階段用戶已經(jīng)參與對成型的產(chǎn)品提供反饋，此時修改后面的需求開銷不大。

• 缺點

1. 缺乏可擴(kuò)展性

RAD 開發(fā)模型需要開發(fā)團(tuán)隊與最終用戶之間的緊密合作。當(dāng)團(tuán)隊太大或利益相關(guān)者太多時，原型制作過程不可避免地會變慢。如果每個人都參與，對變更需求的頻繁討論也變得非常困難。因此，RAD 被認(rèn)為是中小型團(tuán)隊的最佳選擇。

2. 軟件設(shè)計不佳

在原型設(shè)計階段偏重于特定的業(yè)務(wù)功能和走捷徑的做法有時會導(dǎo)致整個解決方案設(shè)計不佳。

3. 前期難以控制

顯然，在項目完成原型開發(fā)階段之前，是無法對項目范圍、預(yù)算和時間進(jìn)行預(yù)測。不過，仍然可以基于需求計劃階段的結(jié)果來確定一個大概的預(yù)期。

4. 對用戶依賴大

RAD 方法假設(shè)用戶在項目生命周期的所有階段都要參與，特別是需要深度了解需求的業(yè)務(wù)專家的參與，而他們通常是是公司中最忙的人。

RAD vs. Agile

如果你知道敏捷開發(fā)，此時，你也許覺得，快速應(yīng)用程序開發(fā)與敏捷開發(fā)似乎是一樣的？

RAD 這個術(shù)語的出現(xiàn)比敏捷早 10 年，而且也同樣使用了迭代的方法，所以通常被認(rèn)為是敏捷開發(fā)的前身。但事實上，RAD 是一種具體的方法論，而敏捷則涉及到哲學(xué)立場，不僅僅指軟件開發(fā)。所以公平一點說，RAD 與 Scrum、 KanBan、 TDD 等開發(fā)方法一樣，都屬于敏捷軟件開發(fā)方法學(xué)的內(nèi)容。

我的項目能用 RAD 嗎？

如上所述，RAD 無法在嚴(yán)苛的環(huán)境中使用，例如：

• 需要預(yù)先知道預(yù)算和開發(fā)時間表
• 用戶無法定期參與或者用戶不想過多消耗時間和精力
• 項目范圍大，參與團(tuán)隊多，利益相關(guān)者多

大型企業(yè)或政府組織的項目通常滿足這些特點。但是，即使在這種情況下，也可以使用一些 RAD 的理念。例如，對于固定價格的項目，可以分割一部分預(yù)算用于原型和需求變更；如果有客戶愿意參與，則將原型的范圍限定在需求最難以確定的部分。

而另一方面，對于中小型企業(yè)或部門內(nèi)的項目，則使用 RAD 會非常有效。在這些項目中，業(yè)務(wù)人員自己控制預(yù)算并且對項目成果非常用心。非常典型的例子就是各種業(yè)務(wù)線（LOB）應(yīng)用系統(tǒng)，指的是業(yè)務(wù)流程自動化或者為了更有效地運行特定業(yè)務(wù)而開發(fā)的應(yīng)用系統(tǒng)。

同樣，對于創(chuàng)建網(wǎng)站這種項目來說，RAD 也非常適合。這種項目一般規(guī)模不大，涉及的相關(guān)人員也不多，但是需要他們盡早地參與，因為設(shè)計這個東西，是非常主觀的，每個人的想法都不一樣！

快速應(yīng)用開發(fā)的工具

RAD 方法論的成功很大程度上依賴于快速地出原型以及緊密的協(xié)作，因此，選擇合適的工具非常重要。

設(shè)計與原型制作

例如：Figma、Balsamiq、Invision、Sketch、Adobe XD。

使用諸如 Figma 和 InVision 之類的快速應(yīng)用程序開發(fā)工具，圖形設(shè)計師和用戶體驗專家能夠快速完成原型，為用戶提供完整的設(shè)計和可點擊操作的原型來收集他們的反饋。一旦原型的某個迭代版本獲得用戶的認(rèn)可，就可以將項目導(dǎo)出為前端開發(fā)人員可重用的格式，從而進(jìn)入實質(zhì)性的開發(fā)階段。這些工具主要用于創(chuàng)建網(wǎng)站，但也可以為更復(fù)雜的應(yīng)用系統(tǒng)或用戶界面設(shè)計用戶體驗和原型。

▲ 使用 Figma 進(jìn)行設(shè)計

其他的一些工具，比如 Balsamiq，主要是業(yè)務(wù)分析師使用。通過簡單的線框圖設(shè)計業(yè)務(wù)原型，而漂亮的最終設(shè)計通常在后期完成。這類工具對于具有復(fù)雜用戶交互功能的大型系統(tǒng)是不錯的選擇。

▲ 使用 Balsamiq 創(chuàng)建原型

軟件開發(fā)

現(xiàn)階段，軟件開發(fā)仍然是創(chuàng)建應(yīng)用系統(tǒng)中最耗時、最昂貴且最不確定的部分。因此，現(xiàn)代快速應(yīng)用開發(fā)平臺整合了堅實的基礎(chǔ)體系框架、提供了實現(xiàn)典型功能的完備組件，當(dāng)然，還有可以促進(jìn)快速開發(fā)的工具。所有這些都是為了在項目的原型開發(fā)階段和后續(xù)構(gòu)建過程中更快地交付成果。

Gartner 和 Forrester 這樣的咨詢公司一直在引入新的術(shù)語來區(qū)分這些平臺：低/零代碼應(yīng)用平臺（LCAP）、高效率應(yīng)用平臺即服務(wù)（HPAPaaS）、多體驗開發(fā)平臺（MXDP）。但其實，這些可以按其目標(biāo)受眾進(jìn)行分類。

• 低代碼/零代碼平臺

例如：Mendix、Outsystems。

這些平臺的核心理念是使沒有開發(fā)技能的業(yè)務(wù)用戶（指高級用戶或業(yè)余開發(fā)人員）能夠非常快速地交付可用的應(yīng)用程序。當(dāng)然，追求這種簡單性的同時便意味著失去了靈活性，并且還有各種限制。我們在低代碼 – 危險的賭注文章中介紹了這些限制和相關(guān)的風(fēng)險。這種類型平臺的產(chǎn)出要么是原型，要么是非常基礎(chǔ)的系統(tǒng)。

▲ 低代碼工作流

• 為專業(yè)開發(fā)人員服務(wù)的平臺

例如：Embarcadero RAD Studio、Jmix、Ruby on Rails。

這些平臺主要通過提供更高級別的 API 和代碼生成來提升軟件開發(fā)的速度和樂趣，開發(fā)人員無需編寫重復(fù)的樣板代碼和通用基礎(chǔ)功能。

Embarcadero RAD Studio（即以前的 Borland Delphi）是該領(lǐng)域的先驅(qū)之一，以可視化的 UI 設(shè)計器而聞名。誕生在網(wǎng)絡(luò)時代之前，目前仍然能用于桌面和移動應(yīng)用開發(fā)。

其他快速開發(fā)平臺則更加關(guān)注 Web 應(yīng)用的開發(fā)，因為現(xiàn)在用戶主要通過 Web 進(jìn)行交互。例如，在 Jmix 平臺，我們嘗試提供便利、快速的數(shù)據(jù)模型和界面的可視化設(shè)計，并結(jié)合了現(xiàn)代開源技術(shù)的強大功能。這種方式不僅可以提高原型制作速度，還可以將原型進(jìn)行繼續(xù)開發(fā)，成為可靠且可擴(kuò)展的全功能企業(yè)應(yīng)用系統(tǒng)。

▲ 在 Jmix 中設(shè)計應(yīng)用程序界面

還不了解 Jmix？ Jmix 快速開發(fā)框架適合我嗎？

如果您有興趣深入研究 RAD 平臺，我們還有一篇關(guān)于 RAD 發(fā)展的企業(yè)級快速開發(fā)平臺的演進(jìn)供您閱讀。

結(jié)語

快速應(yīng)用程序開發(fā)是遵循敏捷哲學(xué)的開發(fā)方法之一。RAD 的關(guān)鍵原則是最終用戶的緊密參與以及基于用戶反饋的快速迭代原型設(shè)計。一旦用戶對原型滿意了，重點便轉(zhuǎn)移到了交付最終成型的產(chǎn)品上。

在項目中快速制作原型和成功實施 RAD 方法的最重要因素就是選擇正確的工具。針對不同類型的應(yīng)用系統(tǒng)、項目階段和團(tuán)隊技能，可選的工具和平臺也相當(dāng)多。

RAD 是一個古老的概念，但如今隨著數(shù)字化轉(zhuǎn)型的趨勢以及快速推出產(chǎn)品的需求推動，它正在經(jīng)歷著復(fù)興。對于適合的項目類型和團(tuán)隊配置，RAD 方法有助于在降低風(fēng)險和縮短交付時間的同時提高用戶滿意度。