無論是面向消費者的應(yīng)用程序，還是內(nèi)部業(yè)務(wù)工具，軟件開發(fā)受兩個原則指導(dǎo):做什么軟件和如何開發(fā)。選擇構(gòu)建什么應(yīng)該由產(chǎn)品和市場策略來驅(qū)動。關(guān)于如何構(gòu)建的決策應(yīng)該通過查看最佳實踐來確定。這意味著我們將放棄傳統(tǒng)的軟件開發(fā)模型，轉(zhuǎn)而選擇快速應(yīng)用程序開發(fā)（RAD）。

我們已經(jīng)知道，快速應(yīng)用程序開發(fā)并不是特定工具和過程的指定列表。隨著時間的推移，軟件開發(fā)的敏捷和其他自適應(yīng)方法已經(jīng)幫助填補了一些細節(jié)，為RAD提供了一些可以共享和擴展的最佳實踐。

然而，無論哪種快速路徑適合企業(yè)的軟件需求，接受并運行RAD仍然需要獨特的文化和戰(zhàn)略選擇。如果沒有對這些決定達成一致意見，那么要釋放迭代的、自適應(yīng)的軟件設(shè)計和開發(fā)的全部潛力就會困難得多。

協(xié)作文化

不管開發(fā)團隊的規(guī)模有多大，協(xié)作和溝通對于RAD的工作是至關(guān)重要的。面對不斷的變化，團隊將一起合作，所以他們需要在整個過程中保持合作和溝通。

協(xié)作不一定意味著接近。如果基礎(chǔ)設(shè)置正確，那么即使是分布式組織也可以進行快速的應(yīng)用程序開發(fā)工作。團隊成員只需要在規(guī)定的工作時間內(nèi)與其他人保持聯(lián)系。

跨職能視角

將軟件構(gòu)建為對象或模塊意味著即使在您的團隊處理細粒度的技術(shù)和業(yè)務(wù)需求時，也要維護一個宏觀的視角?？焖匍_發(fā)在跨功能專業(yè)知識存在的情況下最為成功，但這并不意味著每個團隊成員都必須能夠構(gòu)建軟件、數(shù)據(jù)庫和創(chuàng)建UI線框圖。

這意味即使在獨立的項目管理上，分布在應(yīng)用程序不同末端的開發(fā)人員也要確保是在相同的方向上工作。在需求收集過程中尤其如此，在這個過程中，理解軟件堆棧上下的含義至關(guān)重要。

持續(xù)的客戶訪問

最后，快速開發(fā)在整個過程中與客戶或他們的涉眾進行持續(xù)訪問時效果最好。在傳統(tǒng)的瀑布式開發(fā)中，客戶簽署需求，然后返回來進行UAT。在快速應(yīng)用程序環(huán)境中，客戶將參與整個流程。

客戶希望以最低的成本獲得高質(zhì)量的產(chǎn)品。盡管RAD方法需要花費更多的時間，但投資卻可以通過降低成本和縮短交貨時間獲得回報。最終，他們得到的產(chǎn)品可以完全滿足他們的需求。

模塊和平臺

采用RAD不需要選擇特定的開發(fā)平臺。所選擇的工具將需要匹配正在構(gòu)建的內(nèi)容的復(fù)雜性。

原型

在此階段，原型工具對于快速管理諸如用戶界面之類的細節(jié)很有用。

構(gòu)建

市場上有許多出色的面向?qū)ο蟮膽?yīng)用程序構(gòu)建平臺，可讓構(gòu)建基本的SaaS應(yīng)用程序。它們不像某些原型工具那樣具有高度的靈活性，但是對于基本的工作流數(shù)字化，它們完全可以滿足需求。