▲ 題圖

什么是 RAD ？

快速應用程序開發（RAD）是一種專注于設計和原型設計階段的開發方法，目的是獲得用戶的即時反饋。與先進行初始計劃再進一步執行的傳統開發模型不同，RAD 有著更多的靈活性。通過快速增量更新和即時用戶反饋的不斷迭代，使得最終能獲得更好的產出結果。

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

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

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

▲ RAD 流程

1. 需求計劃

在此階段，用戶和項目團隊一起確定目標系統未來要達到的目標。主要關注于需要實現的業務目標，對于需求的嚴謹性沒有太多要求。在原型設計階段快速調整業務目標及需求的能力是關鍵。

2. 用戶設計

用戶設計是快速應用程序開發方法的核心部分，是與瀑布模型相區別的關鍵點。這時，開發人員開始構建系統原型。目標是通過最快、成本最低的方式給用戶提供一些可演示的內容。原型產品可以只滿足一部分需求，或者只覆蓋少數場景，并且，在代碼編寫時，也可以抄近路。

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

3. 軟件開發

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

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

4. 部署上線

這是最后階段，包括驗收測試、產品上線和用戶培訓。

快速應用程序開發的優缺點

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

• 優點

1. 高質量

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

2. 降低風險和成本

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

• 缺點

1. 缺乏可擴展性

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

2. 軟件設計不佳

在原型設計階段偏重于特定的業務功能和走捷徑的做法有時會導致整個解決方案設計不佳。

3. 前期難以控制

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

4. 對用戶依賴大

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

RAD vs. Agile

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

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

我的項目能用 RAD 嗎？

如上所述，RAD 無法在嚴苛的環境中使用，例如：

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

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

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

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

快速應用開發的工具

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

設計與原型制作

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

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

▲ 使用 Figma 進行設計

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

▲ 使用 Balsamiq 創建原型

軟件開發

現階段，軟件開發仍然是創建應用系統中最耗時、最昂貴且最不確定的部分。因此，現代快速應用開發平臺整合了堅實的基礎體系框架、提供了實現典型功能的完備組件，當然，還有可以促進快速開發的工具。所有這些都是為了在項目的原型開發階段和后續構建過程中更快地交付成果。

Gartner 和 Forrester 這樣的咨詢公司一直在引入新的術語來區分這些平臺：低/零代碼應用平臺（LCAP）、高效率應用平臺即服務（HPAPaaS）、多體驗開發平臺（MXDP）。但其實，這些可以按其目標受眾進行分類。

• 低代碼/零代碼平臺

例如：Mendix、Outsystems。

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

▲ 低代碼工作流

• 為專業開發人員服務的平臺

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

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

Embarcadero RAD Studio（即以前的 Borland Delphi）是該領域的先驅之一，以可視化的 UI 設計器而聞名。誕生在網絡時代之前，目前仍然能用于桌面和移動應用開發。

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

▲ 在 Jmix 中設計應用程序界面

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

如果您有興趣深入研究 RAD 平臺，我們還有一篇關于 RAD 發展的企業級快速開發平臺的演進供您閱讀。

結語

快速應用程序開發是遵循敏捷哲學的開發方法之一。RAD 的關鍵原則是最終用戶的緊密參與以及基于用戶反饋的快速迭代原型設計。一旦用戶對原型滿意了，重點便轉移到了交付最終成型的產品上。

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

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