自適應軟體開發 - 實踐
自適應軟體開發實踐基於持續適應的理念，其生命週期能夠接受持續變化作為常態。
自適應軟體開發生命週期致力於：
- 持續學習
- 面向變化
- 重新評估
- 展望不確定的未來
- 開發人員、管理人員和客戶之間緊密合作
自適應SDLC
自適應軟體開發將RAD與軟體工程最佳實踐相結合，例如：
- 專案啟動。
- 自適應週期規劃。
- 併發元件工程。
- 質量審查。
- 最終QA和釋出。
自適應軟體開發實踐可以如下所示：
如上所示，自適應軟體開發實踐分佈在三個階段：
推測 - 啟動和規劃
專案啟動
為整個專案設定時間框
確定迭代次數併為每個迭代分配時間框
為每個迭代制定主題或目標
為每個迭代分配功能
協作 - 併發功能開發
分散式團隊的協作
小型專案的協作
大型專案的協作
學習 - 質量審查
從客戶角度來看的結果質量
從技術角度來看的結果質量
交付團隊的運作以及團隊成員正在使用的實踐
專案狀態
推測 - 啟動和規劃
在自適應軟體開發中，“推測”階段有兩個活動：
- 啟動
- 規劃
“推測”階段有五個實踐，可以在啟動和規劃階段重複執行。它們是：
- 專案啟動
- 為整個專案設定時間框
- 確定迭代次數併為每個迭代分配時間框
- 為每個迭代制定主題或目標
- 為每個迭代分配功能
專案啟動
專案啟動包括：
- 設定專案的使命和目標
- 瞭解約束條件
- 建立專案組織
- 識別和概述需求
- 進行初步規模和範圍估計
- 識別關鍵專案風險
專案啟動資料應在初步的JAD會議上收集，並將速度作為主要方面考慮。對於中小型專案，啟動可以在集中進行的二到五天內完成，而大型專案則需要二到三週的時間。
在JAD會議期間，需求的收集應足夠詳細，以識別功能並建立物件、資料或其他架構模型的概述。
為整個專案設定時間框
整個專案的時間框應基於專案啟動工作產生的範圍、功能集需求、估計和資源可用性來確定。
眾所周知，“推測”並不意味著放棄估計，而僅僅意味著接受估計可能出錯。
迭代和時間框
根據專案的整體範圍和不確定性程度，確定迭代次數和各個迭代的長度。
對於中小型應用：
- 迭代通常為四到八週。
- 一些專案最適合兩週的迭代。
- 一些專案可能需要超過八週。
根據您的實際情況選擇時間。一旦確定了迭代次數和每個迭代的長度，就為每個迭代分配時間表。
制定主題或目標
團隊成員應為每個迭代制定主題或目標。這類似於Scrum中的衝刺目標。每個迭代都應交付一組可以展示產品功能的功能，使客戶能夠看到產品，以便進行審查和反饋。
在迭代中，構建應最好每天交付可工作的功能，從而實現整合過程並使開發團隊能夠看到產品。測試應成為功能開發中持續且不可或缺的一部分，不應推遲到專案結束。
分配功能
開發人員和客戶應共同為每個迭代分配功能。此功能分配最重要的標準是每個迭代都必須向客戶交付一組具有相當功能的可見功能。
在將功能分配給迭代期間：
開發團隊應提出功能估計、風險和依賴關係，並將其提供給客戶。
客戶應使用開發團隊提供的資訊來決定功能優先順序。
因此，迭代規劃是基於功能的，並且是由開發人員和客戶組成的團隊共同完成的。經驗表明，與專案經理進行的任務型規劃相比，這種型別的規劃能夠更好地理解專案。此外，基於功能的規劃反映了每個專案的獨特性。
協作 - 併發功能開發
在“協作”階段，重點在於開發。“協作”階段有兩個活動：
開發團隊協作並交付可工作的軟體。
專案經理促進協作和併發開發活動。
協作是共享創作的行為，它包含開發團隊、客戶和管理人員。共享創作透過信任和尊重來促進。
團隊應在以下方面進行協作：
- 技術問題
- 業務需求
- 快速決策
以下是與自適應軟體開發中“協作”階段相關的實踐：
- 分散式團隊的協作
- 小型專案的協作
- 大型專案的協作
分散式團隊的協作
在涉及分散式團隊的專案中，應考慮以下事項：
- 不同的聯盟夥伴
- 廣泛的知識
- 人們互動的方式
- 他們管理相互依賴關係的方式
小型專案的協作
在小型專案中，當團隊成員在物理上靠近時，應鼓勵非正式的走廊聊天和白板塗鴉等協作方式，因為這種方式被證明是有效的。
大型專案的協作
大型專案需要額外的實踐、協作工具以及專案經理的互動，並應根據具體情況進行安排。
學習 - 質量審查
自適應軟體開發鼓勵“實驗和學習”的概念。
從錯誤和實驗中學習需要團隊成員儘早共享部分完成的程式碼和工件，以便：
- 發現錯誤
- 從中學習
- 透過在小問題變成大問題之前發現它們來減少返工
在每個開發迭代結束時，有四個總體類別需要學習：
- 從客戶角度來看的結果質量
- 從技術角度來看的結果質量
- 交付團隊和實踐團隊的運作
- 專案狀態
從客戶角度來看的結果質量
在自適應軟體開發專案中，獲取客戶反饋是首要任務。推薦的做法是客戶焦點小組。這些會議旨在探索應用程式的工作模型並記錄客戶更改請求。
客戶焦點小組會議是類似於JAD會議的引導式會議，但它們並非用於生成需求或定義專案計劃，而是用於審查應用程式本身。客戶會對迭代產生的工作軟體提供反饋。
從技術角度來看的結果質量
在自適應軟體開發專案中，應重視對技術工件的定期審查。應持續進行程式碼審查。對其他技術工件（例如技術架構）的審查可以每週進行或在迭代結束時進行。
在自適應軟體開發專案中，團隊應定期監控自身的績效。回顧鼓勵團隊作為一個團隊一起了解自身和工作。
迭代結束後的回顧促進定期的團隊績效自我審查，例如：
- 確定哪些方面不起作用。
- 團隊需要更多做什麼。
- 團隊需要少做什麼。
專案狀態
專案狀態審查有助於規劃進一步的工作。在自適應軟體開發專案中，確定專案狀態是基於功能的方法，每個迭代的結束都以完成的功能（生成可工作的軟體）為標誌。
專案狀態審查應包括：
- 專案進展到哪裡了？
- 專案進展與計劃相比如何？
- 專案應該進展到哪裡？
由於自適應軟體開發專案中的計劃是推測性的，因此與上述問題2相比，問題3更為重要。也就是說，專案團隊和客戶需要不斷地問自己：“到目前為止我們學到了什麼，這是否改變了我們對未來方向的看法？”