一期：活動描述，之一，之二，之三，之四，之五

二期：活動描述，之一，之二，之三，之四，之五，之六

三期：活動描述，之一，之二，之三，之四，之五

之三：使用者故事樹與MVC中Controller和Action的關係

陳勇-創業-北京(**9107533) 13:26:18當然，只解決模組設計，還是不夠的。不過，再仔細看看兩張圖：程式碼圖：故事樹：對比上面最近的兩張圖下圖SprintCalendars = 上圖SprintCalendarsController，下圖Sprints = 上圖SprintsController……我們上次提到的那種“檔案故事”，也就是使用者可以理解的“業務資料”，其實和MVC裡邊的Controller可以很好地一一對應（並非完全如此）這就大大簡化了“一個系統裡邊，有哪些Controller？”這個設計問題。再細看：上圖是使用者故事的“業務資料-業務操作”對應關係陳勇-創業-北京(**9107533) 13:31:28而上圖，則是使用者故事的Controller（它複用了ItemsController，可以認為StroiesController = ItemsController）及其方法上圖檢視所有故事 = 下圖Index，上圖檢視使用者故事詳情 = 下圖 Details……下面還有很多函式沒有展示出來，他們也是一一對應的。這樣就解決了：“我的Controller裡邊應該有多少個Action，分別是什麼啊？”這個設計問題出。所以，若使用者故事樹合理安排，則MVC常見的三個層次：Area-Controller-Action，可以直接借用使用者故事的結構，而無需重新設計。這是MUP裡邊一個很重要的概念。 

 tinny-PM-深圳(**722310) 13:36:32沒太明白，如何解決確定有多少個action的問題。是設計同學自行合併來解決的麼？陳勇-創業-北京(**9107533) 13:35:26比如原來問：這個使用者故事的程式碼在哪裡？如果不靠腦子記，多半需要個什麼跟蹤矩陣。但現在基本上不需要了，按照使用者故事的結構挖下去，直接可以找到。這也是為什麼我們現在在使用者故事後面加上英文的原因，這個英文，就是對應的Areas/Controller/Action的位置。比如下圖中“編輯使用者故事”，程式碼在哪裡？現在問題簡單了，“編輯使用者故事”，位於Products/Stories/Edit，程式碼自然就找到了。@tinny：有多個個“業務操作”型別的使用者故事，就有多少個Actoin 

又比如：

將分別對應 Stories/Index, Stories/Edit, Stories/ChangeType, Stories/ChangeStatus, Stoires/Hide....

有幾個故事沒寫英文，原因是後來發現直接寫在Title上不好，會導致某些使用者故事名字太長還資訊冗餘，所以未來會做個欄位，可以顯示或不顯示。