敏捷開發 | DSDM 在非 IT 領域也同樣適用？

• 2020 年 12 月 11 日
• 筆記

動態系統開發方法（Dynamic Systems Development Method：DSDM）是在快速應用程序開發（RAD）方法的基礎上改進的。作為敏捷方法論的一種，DSDM方法倡導以業務為核心，進行快速、有效的系統開發，不僅適用于敏捷開發模式，也同樣適用於傳統的開發模式。它既能滿足單個團隊同一地點的簡單產品開發，還能滿足多個團隊不同地點、不同時區的複雜項目開發。

一、DSDM依賴於嚴格的時間控制

與傳統開發方法不同的是，DSDM強調項目的時間是固定的，功能和資源是可變的。也就是說，項目功能和資源的規劃需要配合實際開發效果進行規劃：如果在一周的時間內，功能太多無法交付，那麼就要去掉部分功能，以順利結束這一迭代。其基本觀點是，任何事情都不可能一次性完成，應該用20%的時間來完成80%的有用功能，以適應商業目的為準。因此，對項目任務的優先級排序是十分重要的，DSDM應用MosCow優先級排序方法，將項目任務分解為四種不同類型的要求：

• Must：必須做的；
• Should：應該做的；
• Could：可以做的；
• Would not：不要做的。

那麼，為了順利完成「80%」的有用功能，可以首要完成Must、Should項，或者說在完成Must、Should項的基礎上酌情考慮完成Could項。

二、DSDM的角色

任何敏捷開發方法論都有註明他們所構建的系統中應具備的角色，DSDM也不例外：

• 項目負責人——該職位上的人員由用戶或客戶方面推出，他們代表用戶或客戶行使決策權，並能夠根據需要分配資金及資源。
• 項目指導——項目指導者需要深入了解用戶業務、具備敏銳性，並有遠見卓識，能夠儘快鎖定最高優先級要求，並基於此指導團隊來初始化項目。 
• 用戶代表——一個理想的「測試用戶」，可以將用戶社群的觀點帶入到整個項目中。他們是整個開發過程中重要的反饋來源。 
• 用戶顧問——另一種類型的用戶，應對手中的項目提出新穎或十分重要的觀點，因此，用戶顧問需要有資深的專業知識或其他獨特的專業能力。 
• 項目經理——項目經理是管理整個項目的人。 
• 團隊負責人——負責協調和促進團隊之間的協作。 
• 解決方案開發人員——瀏覽系統要求，進行系統建模，開發可交付的代碼並創建原型。
• 解決方案測試器——測試產品，並在出現錯誤時提供注釋和文檔。在實施更正後，它們還能夠重新測試。 
• 抄錄員——記錄項目進度的要求、協議、決定和其他有用信息。 
• 主持人——他們負責激勵和準備研討會，以保持進度的持續穩定。他們必須是使每個人都步入正軌的協調者。 
• 專家角色——這些角色由各自領域或行業的專家擔任，根據項目需求提供額外的支持。他們可能因項目而異，也因團隊而異。這樣的角色包括業務架構師、質量經理、系統集成商等等。 

三、DSDM的基本原則

• 用戶必須持續參與

用戶不僅提出產品需求，還要參與到開發過程中，及時給出反饋。

• 授予DSDM團隊決策權

DSDM團隊成員被授予能夠在出現問題後直接做出決定的權力。

• 強調產品的經常交付

產品的經常交付能夠讓開發團隊得到快速的反饋，並及時處理交付中發現的問題。

• 滿足業務需求

不要做過多無意義的功能增加，交付完成的標準就是實現產品的業務需求。

• 迭代開發

迭代開發能夠不斷完善業務解決方案，滿足業務需求。

• 開發過程中的所有變化可逆

開發過程要適應變化。

• 在高層次上制定需求的基線

要先達成高層次的目標，再進行需求細化。

• 測試自始自終貫穿於開發周期之中

開發人員完成一個模塊的開發後，自己會進行單元測試。當模塊集成到現有系統後，測試人員需要執行集成測試。另外，回歸測試在DSDM中佔有很重要的地位。

• 所有利益相關者之間的通力合作是不可或缺的

產品的交付需要各方的參與、努力，單靠開發團隊是無法成功交付的。

四、DSDM的優勢

DSDM中既有傳統開發的優勢，又有先進的敏捷思維及理念，因此有效實施DSDM能夠幫助團隊得到切實有效的提高：

• 開發過程及結果能夠清晰、明確地展現出來；
• 用戶積极參与開發過程，更能滿足他們的需求；
• 有效的溝通能夠打破中間各環節的交流壁壘；
• DSDM更易於與其他敏捷方法論結合，因地制宜發展適合自己組織的開發方法；
• DSDM不局限於IT領域，在非IT領域也有着廣泛的應用。