敏捷實踐Showcase的七宗罪

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

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, QualityAnalyst）通常是團隊跟業務打交道最多的，是最瞭解業務的，而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一定能做好。