敏捷項目的主動架構

　　論證主動架構

　　在敏捷中，需求的焦點常常放在用戶故事上。有時，用戶故事和技術任務同時是重點，但不是任何架構或者整體系統設計需求。這對于Web應用也許可以接受，因為Web應用簡單、瑣碎，而且基本上是事件驅動的，但它不能滿足有復雜后端組件的應用的要求，比如：

　　投資組合平衡引擎

　　薪酬引擎

　　網絡優化

　　規劃或匹配引擎

　　有引擎的任何應用，:)

　　然而，敏捷已經把架構和設計文檔的數量大大減少，因為它們數量過于龐大，而且存在浪費。我100%同意是有浪費的，但是我認為：正確的做法是創建一種新的、更精益的架構文檔。放棄傳統的海量被動架構文檔的同時，我推薦一種新的主動架構文檔，由下圖中的組件對話(Component Conversation)組成:

　　傳統架構文檔的問題在于：它們以被動和疏離的方式定義架構，有時類似于路線圖。我建議以主動方式來定義架構。文檔不應該只是定義路線的地圖，而應該定義路線如何前行，并以主動方式描述路線圖。傳統架構文檔與系統的實際行為相距甚遠，似乎與系統沒有多少關系，而且也沒有實際效果。架構文檔需要定義出架構支持哪些行為，就像用戶故事支持用戶使用功能一樣。

　　用戶故事有效地捕獲用戶和系統之間的互動，技術任務捕獲系統需要完成的底層任務?？墒?，在這些精簡的文檔中，我們如何定義系統組件之間的高層互動呢?

　　我推薦的敏捷需求記錄方式包括：

　　用戶故事：這些故事記錄用戶如何與應用交互，或是手動流程

　　組件對話：在應用組件之間的對話

　　技術任務：應用在組件內部要完成的技術任務

　　創建這些組件對話，并在整個系統層面思考思考它們，有以下效果：

　　用戶故事與功能跨組件處理的方式保持一致

　　當以前完成的用戶故事在后面迭代中再次遇到時，不會產生過多重復工作

　　確保整個解決方案在更高層面得到透徹思考

　　只有回過頭去看以前的用戶故事，才能完成某個故事——此類情況幾率降低

　　技術任務在各組件之間的實現方式保持一致

　　它們可以定義復雜的后端高層需求，如果采取一個一個故事的方式，這些需求的收集會不完整，而且可能不一致

　　組件對話可以復查，以確保所有的系統功能都被覆蓋到，而且不存在功能之間的缺口

　　理想狀況下采取圖形方式

　　這些組件對話定義了解決方案的主動架構。組件對話可以采取下面這種格式：(您也可以自定義適合您特定環境的格式)：

　　[編號]：當[事件]發生時， [組件A]完成[基本動作][對象][附加動作]通過[動作][組件B]

　　組件對話示例

　　拿幾個例子來看一下，可以說明這些組件對話會是什么樣子。創建組件對話的時機很重要，應該在用戶故事創建完成之后，理想狀態下應該是在用戶故事映射(User Story Mapping)過程完成后。這些用戶故事和用戶故事地圖能為組件對話的創建提供輸入。

　　Facebook有一個瀏覽建議朋友的函數，是用戶事件驅動系統的知名范例，它可以從組件對話中獲益，我們看看如何完成：

　　聲明：這些故事只是對知名接口的虛擬表示。它們不代表實際的Facebook函數。

　　如果我們已經定義好了用戶故事，我們可以創建下面這些組件對話，提供更多細節和上下文：

　　[1]：當[用戶登錄]發生時，[SuggestedFriends組件]完成[創建][建議朋友列表]通過[在所有朋友中過濾共有聯系][Connection-DB組件]

　　[2]：當[用戶點擊發送朋友請求]發生時，[FacebookUser組件]完成[發送][朋友邀請]通過[選擇聯系邀請按鈕][SuggestedFriendList組件]

　　[3]：當[用戶點擊隱藏朋友]發生時，[FacebookUser組件]完成[更新][建議朋友列表]通過[選擇聯系邀請按鈕][SuggestedFriendList組件][隱藏朋友列表]

　　[4]：當[用戶點擊接受邀請]發生時，[FacebookUser組件]完成[接受][朋友邀請]通過[選擇接受邀請][PendingInvitation組件]

　　現在，這四個故事提供了非?；镜姆独?，但是我希望這可以展示出組件對話捕獲的信息層次。即使是這些基本的例子，我認為也捕獲了下面四個想法：

　　創建這些SuggestedFriendList與用戶的互動是分開的，之間有個流程。

　　Connection-DB被用來創建SuggestedFriendList，而且可能還包括HideFriendList。

　　有一個對象包含PendingInvitation組件。(而且對于其他與推遲相關的對象也可能有類似概念。)

　　HideFriendList可能被持久化，以確保用戶選擇要隱藏的建議列表不再出現。

　　當用戶故事在后面的迭代中開發時，這些想法可能終究會出現并得到討論，但是組件對話的優勢在于：提前把它們拿出來討論，把它們想清楚，保證它們在整個應用中以一致的方式處理。及早討論這些組件對話，還能發現重復工作的風險，比如有些工作項在一些開發工作完成后才發現。舉個例子，由于要支持的對象不同，PendingInvitation對象的設計可能會變。如果我們可以使用組件對話來盡早理解高層需求和行為，以此提供一個流程，我們就能把以后迭代中重復工作的情形最小化。

　　技術任務也會從組件對話中浮現，不過只是技術任務而已，就像從用戶故事中生成的功能任務。(比如：“確保Pending對象持久化，并支持朋友、事件和消息”，這可能是技術任務。)

　　小結

　　我在我當前的項目中使用了這些組件對話，并且大大改進了我和團隊成員對項目的理解。很重要的一點是：這些組件對話不能占用太多精力和時間。我會用1到2天的時間盒確保對現有系統的一致理解。隨著迭代的進行，組件對話可以修改和變更。關鍵是要保持精益，知道做到什么程度可以提供足夠必要的價值。

　　這個理念為我當前的項目提供了巨大的價值。

　　關于作者：

原文轉自：http://www.kjueaiud.com

• 共2頁:
• 上一頁
• 1
• 2
• 下一頁