Showcase介紹

Showcase就是開發團隊把開發好的功能給客戶的Product Owner（以下簡稱PO）等業務相關人員演示，以獲取他們對所開發系統的反饋，是敏捷開發流程中的一個實踐，一般的頻率是一個迭代一次，也可以根據專案具體情況做調整。Showcase的目的是做功能演示，這同時也是展示開發團隊面貌的時刻，其重要性不言而喻，但在我經歷的專案中，總能看到一些不是很理想的地方。

Showcase之七宗罪

1.準備工作沒做好

所有人就位，準備開始showcase的時候，突然發現環境沒有ready，連不上了！

好不容易把環境弄好了，開始showcase，可是資料又沒有ready，還要臨時建立，花了大半天時間（建立、準備資料）才終於show到了真正要演示的功能……

主講人手忙腳亂，而其他人都要在這種忙亂中等待，浪費了很多寶貴的時間，尤其是對於PO那些重要人物來說。

正確做法：充分做好準備工作

確定要做showcase的功能後，需要提前把以下事情提前做好：

• 從業務的角度把整個要演示的功能儘可能的串起來，準備好showcase演示的步驟；
• 演示資料也需要準備好，showcase的時候可以直接使用，只需要操作所演示功能部分，不需要臨場建立準備資料；
• 演示環境要提前準備好，包括部署好需要演示的應用程式版本，而且要告訴團隊不要破壞準備好的環境。

2.沒有上下文鋪墊

著急忙慌的準備好一切之後，就開始頁面操作了，既不先介紹一下要演示功能的來龍去脈，也不說明這個功能是幹嘛的。那些日理萬機的PO等業務人員很有可能沒見過這個系統功能，很容易被搞得雲裡霧裡、不知所云……

正確做法：開始演示前要先介紹上下文

根據自己對所演示功能的理解，先介紹該功能的業務價值，滿足了使用者的什麼需求，讓在座的各位業務人員能夠更容易理解後續showcase的內容。

3.逐條過AC

Showcase的過程就是按照使用者故事（story）的驗收標準（AC, Acceptance Criteria）一條一條的過一遍，沒有連貫性。這樣的演示很難讓觀眾把每條AC跟整體的系統特性、真正的業務場景聯絡起來，容易迷失。因此，常常會有“演示完了一個story，而客戶卻問這是實現了什麼業務需求”的情況發生。

正確做法：以功能為單位演示

不要一個一個使用者故事的演示，而是將整個功能串起來，最好定義出單獨的業務場景演示給客戶看，並且儘量使用業務語言描述。這樣能讓客戶的業務人員感覺更有親切感，看到開發團隊的人員能夠用業務語言進行描述和演示，他們一定會留下好的印象。

4.企圖覆蓋所有路徑

在系統功能中，通常會有“用不同路徑實現相同或類似功能”的情況，比如一個上傳檔案的功能有多個入口，但到達的上傳檔案頁面是相似的。有人在演示這個檔案上傳功能的時候，企圖把所有入口的檔案都完整演示一遍，到後來根本沒有觀眾願意關注，都在私下討論了，有時也會有客戶業務人員直接出來制止。

正確做法：只演示最關鍵路徑

在遇到多個路徑實現相同或相似功能的時候，對其中一條最複雜/重要的路徑進行詳細演示，其他路徑提到即可，並指出其他路徑不同的地方，不需要一一演示，以節省時間。

5.過多提及跟演示功能無關內容

有人天生能聊，showcase的時候也喜歡囉囉嗦嗦的說一大堆，經常會提及一些跟正在演示的功能無關的東西，或者提及團隊採用的技術方案等業務人員不感興趣的內容，導致showcase過程不能按時結束，甚至忽略掉某些重要的反饋。

正確做法：只提及要演示的功能

有時候在一個showcase週期內可能開發了一個主要的功能，以及對一些小的feedback進行了改動等，這時候showcase可以考慮只演示最主要的功能，那些小的feedback就不需要show了，也不要提及任何還未完成的功能模組，特別是對於團隊正在開發的技術卡或者還不成熟的技術方案等，一定不要提及。因為對方是業務人員，不會對技術相關內容感興趣。

6.認為showcase僅僅是BA或QA的事情

業務分析師（BA, Business Analyst）和質量分析師（QA, Quality Analyst）通常是團隊中跟業務打交道最多的，也是最瞭解業務的，而showcase就是給客戶的業務團隊做系統演示，於是團隊其他角色就會有人覺得showcase僅僅是BA或者QA的事情，跟自己無關，也不關注。

正確做法：人人都可以showcase

Showcase不是某個角色獨佔的。團隊中的所有人只要對業務、對要演示的系統功能足夠了解就可以負責showcase。通常可以採用讓團隊中的不同人員輪換負責showcase的方式，以增加團隊成員在客戶面前的曝光率，同時也能增強團隊中不同角色人員熟悉系統、熟悉業務的意識。另外，就算不主導showcase，團隊人員也可以儘量多參加showcase會議，這是一個瞭解系統、聽取客戶反饋的絕佳機會。

7.不熟悉的新人負責showcase

既然showcase不僅是BA或QA的事情，常常也會有其他角色來參與負責這件事情。從團隊能力建設的角度考慮，PM有時候會讓一些比較junior的同事或者新來不久還沒有好好了解系統的同事來做showcase，結果就是演示過程非常生硬，甚至會有很多說不清楚的部分，而在一旁聽著的BA/QA只好著急的上來幫忙解釋。

正確做法：showcase前先充分了解系統和業務

雖然人人都可以showcase，但不建議採用給青澀新人提供showcase機會的方式來幫助他們提高能力，如果要給新人鍛鍊機會，可以讓新人在結對程式設計、Story Kickoff、Desk Check的時候多多主導，等到對系統和業務有了一定了解時再給客戶展示比較好；或者新人非常有意願直接主導showcase，那麼一定要在演示前做好對系統和業務的充分了解，以能應付和解答客戶的挑戰和疑問。

總結

前面關於showcase的正確做法都是圍繞“專業（Professional）”和“高效（Efficient）”展開的，showcase的目標觀眾是客戶的PO等業務人員，他們是決定是否認可開發團隊所開發功能的重要人物，因此在showcase過程中表現出專業性和高效率非常重要。因此，只要記住這兩個詞，並嚴格遵循，showcase一定能做好。