我們總結了“協作建模”（以下簡稱“ CoMo”）背後的想法和概念。在“敏捷”和“領域驅動”之後，我們將“ CoMo”視為商業軟體開發的下一個重大步驟。

什麼是協作建模？

幾年前，我們的三個同事被要求更換客戶的舊系統。客戶聘請了一名需求工程師來幫助他們瞭解新系統的期望。需求工程師做得很好，但是，我們的同事在圍繞這個新領域尋找方法時遇到了問題。因此，他們要求與需求工程師和一組關鍵使用者舉行研討會。通過使用一些視覺敘事技術，他們成功地激發了使用者講述其工作的故事：他們如何使用舊版系統來完成其任務（從而提供了一個解釋需求的需求和優先順序的背景）以及他們打算如何使用該系統。新系統（為需求提供上下文）。他們甚至在故事中發現了“漏洞”，從而產生了新的要求。

CoMo是許多成功方法的基礎，傳統上將這些方法歸類為“需求工程”。IT專家需要了解領域，即使用者的任務和工作流程。軟體只能反映開發人員對領域的瞭解，否則無法建立好的軟體。相反，領域專家和使用者需要了解可以開啟哪些潛在軟體以及數字化將如何影響他們的日常工作。

開發人員和領域專家需要一種通用語言，以便能夠討論領域和軟體要求。CoMo旨在將領域知識從使用者頭傳遞到開發人員，測試人員，產品所有者，產品經理，業務分析人員的頭部，並傳播給參與軟體開發的每個人。這裡的關鍵因素是所有相關人員之間的直接反饋。例如，這將CoMo方法與經典的需求技術區分開來，在經典的需求技術中進行訪談和從中得出方案。

CoMo在域驅動設計（DDD）中是必不可少的-域驅動設計（DDD）–這可能是當前可用的最成功的方法，它將域知識置於軟體開發的核心。領域的語言，事件，動作，資源和領域的結構形成了所謂的領域模型，開發人員可以在軟體中進行對映。有效的領域模型只能由開發人員和領域專家共同建立。現在，Paul Rayner等DDD專家將協作建模視為DDD的支柱（參見圖1）。

CoMo的本質

隨著DDD的成功，CoMo技術獲得了普及和接受。我們經常使用其中的幾種，並且正在自行開發一種技術（域講故事）。在本文中，我們將研究四種CoMo方法，並將其實質提煉為一些基本概念。我們對方法的選擇不完整，是基於我們的個人經驗。由於我們假設許多讀者熟悉這些方法，因此我們僅簡要介紹它們：

• 在EventStorming [Brandolini] 期間，各個部門的開發人員和專家使用貼紙和筆來繪製複雜的業務流程。圖片是根據域事件“自下而上”建立的。在故意混亂的開始（因此稱為“風暴”）之後，一個故事出現了，並被記錄為領域事件的流。

  圖2：“大圖”事件儲存事件和熱點

• 域敘事 [Hofer]是一種視覺敘事技術，著重強調人員（和軟體系統）如何協同工作。領域專家講述有關業務流程具體示例的故事時，主持人使用象形文字來記錄故事。該圖片是域專家和開發人員之間討論的基礎。

  圖3

• 使用者故事對映 [Patton]從使用者的角度將需求（大致描述為使用者故事）構建為一個連貫的故事。參與者在便籤或卡片上簡要描述了他們將如何與軟體互動。使用者故事地圖的水平維度描述了業務流程或使用者旅程。垂直維度可用於詳細說明需求和優先順序（請參見圖4）。

  圖4

• 在示例對映 [Wynne]中，使用者案例是更詳細地瞭解問題域的起點。使用示例，業務部門，開發人員和測試人員的代表尤其應該確定業務規則或使用者故事的邊界條件，以便得出驗收測試。使用者故事，帶有示例的規則和未解決的問題均在不同顏色的卡片上註明（請參見圖5）。

  圖5

CoMo的基本概念

我們看到了各種CoMo技術背後的以下常見概念：

• 所涉及小組的團隊合作：來自業務部門（領域專家，使用者，產品所有者等）和來自IT部門（軟體開發人員，架構師，UX專家等）的人員一起建模。他們使用建模來轉移領域知識並闡明範圍，工作流或需求。CoMo研討會可能需要一大批參與者或一些角色的幾個代表。跨角色的協作與進行訪談，分析文件併產生文字輸出的個人專家形成了鮮明的對比，這些文字輸出被他人使用。
• 講故事：在CoMo講習班中，參與者講關於過去發生的場景或他們想在將來發生的場景的故事。場景是關於業務流程的一個例項（而不是所有可能例項的抽象描述）。每個方案都描述了與該領域相關的事件，活動或示例的時間表。一旦瞭解了場景，討論就可以繼續進行軟體開發所必需的抽象，規則和大小寫區別。
• 旨在通過一種通用語言在所有參與者之間達成相互理解：人們經常抱怨業務部門和IT部門生活在各自的世界中，並且彼此交談。但是，所有CoMo方法都著眼於使用者的語言。應該採用各種研討會技巧來幫助參與者更好地瞭解彼此。
• 建立應用程式域的通用模型：講故事時生成的模型不僅僅是副產品。即使它們是非正式的，並且通常是由圖紙，索引卡或便籤紙製成的，但它們還是可以在以後的工作中使用的明顯結果。建模的另一個甚至可能更重要的目的是推動故事的發展。模型將所有參與者的討論狀態視覺化。協作建模的符號必須為所有人所理解，即不需要專業知識即可理解該符號。

達成對CoMo的共識

通過這篇文章，我們想開始討論CoMo不同方法的本質。我們認為，從嚴格意義上講，這超出了DDD方法的範圍，而超出了一般敏捷社群和TDD / BDD方法的範圍。討論可能會揭示每種方法在哪些情況下以及針對哪些問題特別合適，而在哪裡不合適。此外，我們想找出如何在實際專案中結合這些方法，以便在不中斷概念的情況下獲得持續的支援。這也是Visual Collaboration Tools [Baas]的目標之一，這是一本為從業者社群編寫的書。

最後，我們希望不同的CoMo方法的擁護者能夠在共同的概念基礎上達成共識，以使許多好的想法可以彼此補充，從而得到更廣泛的應用。