快速應用程式開發
什麼是 RAD ？
快速應用程式開發（RAD）是一種專注於設計和原型設計階段的開發方法，目的是獲得使用者的即時反饋。與先進行初始計劃再進一步執行的傳統開發模型不同，RAD 有著更多的靈活性。通過快速增量更新和即時使用者反饋的不斷迭代，使得最終能獲得更好的產出結果。
詹姆斯·馬丁（James Martin）於 1991 年定義了快速應用程式開發（RAD）的模型，提供了除瀑布式開發過程之外的另一種開發過程。經典的瀑布方式能完美地適應建築領域和其他一些行業，這些行業中，需求範圍一般很少變動，且變動的代價非常高。例如，如果開始建造一座橋樑，則不可能在完成一半時將其改建成一條渡輪。
相反，軟體的開發過程卻是比較靈活的。對同一業務需求的解決方案通常不止一個，且變換解決方案的成本較低。因此，基於瀑布式的詳細設計和提前規劃通常會輸給快速試錯的開發方式，還有，站在使用者的角度，往往只有在看到具體的產品時，才能有思路並提供更好的反饋。
快速應用程式開發方法論的核心是從費時費力的計劃工作轉移到快速建立產品的原型上來。具體來說，RAD 模型將軟體開發過程分為四個階段：
- 需求計劃
在此階段，使用者和專案團隊一起確定目標系統未來要達到的目標。主要關注於需要實現的業務目標，對於需求的嚴謹性沒有太多要求。在原型設計階段快速調整業務目標及需求的能力是關鍵。
- 使用者設計
使用者設計是快速應用程式開發方法的核心部分，是與瀑布模型相區別的關鍵點。這時，開發人員開始構建系統原型。目標是通過最快、成本最低的方式給使用者提供一些可演示的內容。原型產品可以只滿足一部分需求，或者只覆蓋少數場景，並且，在程式碼編寫時，也可以抄近路。
在原型準備好後，會拿給使用者演示。開發團隊儘可能收集所有的反饋，這裡，原始需求會不可避免地發生改變：紙上似乎正確的東西在應用程式中可能完全不同。根據這些反饋，開發人員會重新修改原型，直到使用者對結果感到滿意。
- 軟體開發
現在我們已經確切地知道了需要完成的內容。開始進行實質性地開發並測試，以便按期交付產品。這個階段不能再走捷徑了，需要關注產品的質量、可伸縮性、可維護性等等。並且，使用者會一直參與對產品進行反饋，直到開發的最後階段。在快速應用程式開發的週期的這個階段，仍然可以接收需求的一些小調整。
根據我們選擇的開發工具和其他因素，我們在設計階段開發的原型可能會直接廢棄不用。
- 部署上線
這是最後階段，包括驗收測試、產品上線和使用者培訓。
快速應用程式開發的優缺點
RAD 將天平從可預測性傾向至敏捷性，這樣會帶來一些正面和負面的影響。
優點
- 高質量
有了使用者在原型階段的深度參與，最終的完成的系統能更加貼合他們的需求，使用者的滿意度相對較高。
- 降低風險和成本
使用瀑布式開發方法，使用者只能在專案交付時看到結果並提供反饋。在這一階段如果再進行需求變更，將會費錢又費力。而使用 RAD 方法時，在原型階段使用者已經參與對成型的產品提供反饋，此時修改後面的需求開銷不大。
缺點
- 缺乏可延伸性
RAD 開發模型需要開發團隊與終端使用者之間的緊密合作。當團隊太大或利益相關者太多時，原型製作過程不可避免地會變慢。如果每個人都參與，對變更需求的頻繁討論也變得非常困難。因此，RAD 被認為是中小型團隊的最佳選擇。
- 軟體設計不佳
在原型設計階段偏重於特定的業務功能和走捷徑的做法有時會導致整個解決方案設計不佳。
- 前期難以控制
顯然，在專案完成原型開發階段之前，是無法對專案範圍、預算和時間進行預測。不過，仍然可以基於需求計劃階段的結果來確定一個大概的預期。
- 對使用者依賴大
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 之類的快速應用程式開發工具，圖形設計師和使用者體驗專家能夠快速完成原型，為使用者提供完整的設計和可點選操作的原型來收集他們的反饋。一旦原型的某個迭代版本獲得使用者的認可，就可以將專案匯出為前端開發人員可重用的格式，從而進入實質性的開發階段。這些工具主要用於建立網站，但也可以為更復雜的應用系統或使用者介面設計使用者體驗和原型。
其他的一些工具，比如 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 平臺，我們嘗試提供便利、快速的資料模型和介面的視覺化設計，並結合了現代開源技術的強大功能。這種方式不僅可以提高原型製作速度，還可以將原型進行繼續開發，成為可靠且可延伸的全功能企業應用系統。
如果您有興趣深入研究 RAD 平臺，我們還有一篇關於 RAD 發展的文章供您閱讀。
總結
快速應用程式開發是遵循敏捷哲學的開發方法之一。RAD 的關鍵原則是終端使用者的緊密參與以及基於使用者反饋的快速迭代原型設計。一旦使用者對原型滿意了，重點便轉移到了交付最終成型的產品上。
在專案中快速製作原型和成功實施 RAD 方法的最重要因素就是選擇正確的工具。針對不同型別的應用系統、專案階段和團隊技能，可選的工具和平臺也相當多。
RAD 是一個古老的概念，但如今隨著數位化轉型的趨勢以及快速推出產品的需求推動，它正在經歷著復興。對於適合的專案型別和團隊設定，RAD 方法有助於在降低風險和縮短交付時間的同時提高使用者滿意度。
如果對我們提供的內容有意見或者建議，歡迎聯絡我們：
blog：https://blog.abmcode.com
wechat：abmcode_gh