敏捷方法實務研討會會後筆記2 - 駐廠使用專家與使用者參與

敏捷方法強調溝通，且溝通行為不僅發生在負責軟體開發工作的程序員之間，也要包含使用者。所以敏捷方法的實踐作法中，重視並要求「使用者參與」。陳教授在會中使用「駐廠使用專家 (On-site usage expert)」表示在敏捷開發過程中的使用者代表。一般則稱為「駐點客戶(On-site customer)」。

使用者參與的難處

但在實務經驗中，當我們進行需求訪談時，普遍遇過獨孤木在《Prototyping》中描述的狀況。訪談對象抓不到雛型的重點，並形成過多的預期印象。久而久之，逐漸形成溝通的障礙。最後開發團隊有意地將使用者排除在外，「以免增加不必要的干擾和工作」。

陳教授因此採用「駐廠使用專家」一詞，以強調客戶代表的專業性。客戶代表必須了解企業內部的業務內容，並具有一定的資訊專業知識。若有軟體開發經驗更好。駐廠使用專家是客戶所派駐於開發團隊中的代表，可以和開發團隊溝通，並且可介入開發過程中的案例測試工作。

不幸的是，這點在台灣絕對知易行難。我個人認為「使用者參與」的導入難度比 Pair programming 還高。在討論專案進行過程中遭遇的困擾時，原因往往會指向使用者。我們的經驗可見《與喲哪桑的討論內容》、《甲方、end-user 與需求落差》、《業務流程決定軟體程式，軟體程式追隨業務流程》、《資訊委外策略成功的關鍵在溝通》 等文。

敏捷方法其實並沒有提出什麼嶄新的編程技術或工具。XP 並沒有新的觀念，它的觀念與程式設計的歷史一樣老(Kent Beck)。個人認為敏捷方法之所以能敏捷、能夠擁抱變化 (Embrace change)之原因，在其堅持並貫徹使用者參與的原則。敏捷方法能否帶來令人滿意的軟體開發品質，「使用者參與」是極為重要的關鍵環節。

使用案例、故事與情節

使用者參與可以提供開發團隊較佳的需求訪談結果，並有助於持續調整開發工作內容。當我們在討論這些工作內容時，常常會用使用案例、故事與情節等等術語。在敏捷方法中，我們一般使用「故事(Story)」這個詞。而陳教授則傾向採用內容較詳細的「情節(Scenarios)」。

使用案例(Use case)、故事(Story)與情節(Scenarios)。這三種都是用於記錄與描述使用者使用軟體時的經驗與狀況。概念上互通，我們可以不加以區別。若真要區分，那麼其差異在於描述的形式與細節程度不同。

具體而言，使用案例是用 UML 表示；故事用名片大小的紙卡及一般語句簡短描述；情節則是在 A4 紙張記錄著模擬操作畫面及操作過程的敘述。如果你正為案例、情節等術語所困惑，請不要懷疑，它們的差別真的就只是這樣。看看微軟的 MSF 如何說明:

情節與使用案例

使用案例是用 UML 表達的棒狀小人圖(即「使用案例圖」。此外，由於 RUP 大量使用 UML 進行塑模，所以 RUP 的開發團隊通常採用使用案例描述客戶的軟體使用活動)，旁邊加註沒有具名的角色名稱。而 MSF 認為應儘早將人物具體化，以電影人物性格的方式描述人物，並且在情節中加入操作畫面的簡圖以及畫面切換的資料流。

情節與故事

XP 的故事等於情節的目標。故事應寫成簡短的句子，故事卡(story card)的大小 以名片至 A5 紙張的大小為宜。如果一張故事卡寫不完一個故事，那麼代表這個故事的工作內容太多了，應該要再加以細分。故事卡不需詳細內容，因為 XP 會要求由駐點客戶代表在旁隨時提供說明。

《軟體工程與Microsoft Visual Studio Team System》(ISBN: 9789861810676)及《eXtreme Programming 理論與實務》(ISBN:9575275861)

當我們將故事寫在一張張故事卡之後，我們接著就要決定如何將故事中的內容對應到軟體概念上。要做這件事，我們有很多方法可以用(敏捷方法並不要求做事一定要採用固定的解決途徑)，陳教授則提倡基於 CRC卡 的 CRC 會議。敏捷方法代表性人物之一的 Martin Fowler ，在其著作《UML精華第三版(UML Distilled Third Edition)》中也是如此建議。

國內使用 UML 的問題

陳教授在此提到國內軟體業使用 UML 進行需求分析時的一個弊病：架構師和程序員各搞一套，各行其事。當架構師以 UML 進行分析設計工作時，產生的只是「純文件」。程序員則往往是照自己的設計進行編程。我對此一點都不感到意外。就我所知，國內軟體業對於 UML 的使用，通常是在做表面工夫，用「較先進」的 UML 符號寫 SA/SD 罷了。架構師只是把 UML 塑模工具當作某種較好用的投影片或流程圖繪製工具，並未導入 MDA 的觀念。

我原本以為塑模工具的使用，可以減少這個問題，甚至可以讓使用者自己塑模。但我的想法在實際進入軟體產業後，被批評「太前衛」。實際上連乙方自己都不用塑模工具，又如何能指望甲方會用？ 與喲哪桑的討論內容

雖然我並未實際上操作過 MDA 的開發方式，但就我在 IBM developerWorks Live 看過的操作展示，當架構師使用 UML 塑模之後，整套工具可以按照 UML 的內容產生程式骨架。至於程序員的工作則是實作內容，把程式碼填入骨架中。MDA 是將 UML 視為 程式語言的標準用法(Fowler，UML精華第三版)。讓架構師和程序員各搞一套？我還真不知道那些人在想什麼。

最後補充一點。利用「卡片」幫助我們規劃工作活動的方式，似乎愈來愈受到認同。我去年參加 IBM 2006 developerWorks Live 時，會中介紹由 Dr. Jacobson 融通 RUP, CMMI, Agile Method 三者之長所提出的新軟體工程方法 Essential UP (Ess-UP)。在 Ess-UP 中，就利用故事卡、CRC卡、工作卡(Task card)等等卡片進行工作規劃。

相關文章

• 敏捷方法實務研討會會後筆記1 - 溝通與 Pair programming
• 敏捷方法實務研討會會後筆記3 - 反覆式開發過程
• 敏捷方法實務研討會會後筆記4 - 測試驅動開發與工作時程
• 敏捷方法實務研討會會後筆記5 - 資料結構與虛擬碼