1. 準備工作沒做好
所有人就位，準備開始展示的時候，突然發現環境沒有搭建好，連不上了！
好不容易把環境弄好了，開始展示，可是資料又沒有準備好，還要臨時建立，花了大半天時間（建立和準備資料）才終於展示到了真正要演示的功能……主講人手忙腳亂，而其他人都要在這種忙亂中等待，浪費了很多寶貴的時間，尤其是對於po等重要人物來說。
正確做法：充分做好準備工作
確定要做展示的功能後，需要提前把以下事情做好。
從業務的角度把整個要演示的功能盡可能串起來，準備好展示的步驟。
演示資料也需要準備好，展示的時候可以直接使用，只需要操作所演示功能部分，不需要臨場建立準備資料。
演示環境要提前準備好，包括部署好需要演示的應用程式版本，而且要告訴團隊不要破壞準備好的環境。
2. 沒有上下文鋪墊
著急忙慌地準備好一切之後，就開始頁面操作了，既不先介紹一下要演示功能的來龍去脈，也不說明這個功能是幹嘛的。那些日理萬機的po等業務人員很有可能沒見過這個系統功能，很容易被搞得雲裡霧裡、不知所云……
正確做法：開始演示前要先介紹上下文。
根據自己對所演示功能的理解，先介紹該功能的業務價值，滿足了使用者的什麼需求，讓在座的各位業務人員能夠更容易理解後續showcase的內容。
3. 逐條過ac
展示會的過程就是按照使用者故事（story）的驗收標準（ac，acceptance criteria）一條一條地過一遍，沒有連貫性。這樣的演示很難讓觀眾把每條ac跟整體的系統特性、真正的業務場景聯絡起來，容易迷失。因此，常常會有「演示完了乙個故事，而客戶卻問這是實現了什麼業務需求」的情況發生。
正確做法：以功能為單位演示。
不要乙個乙個使用者故事的演示，而是將整個功能串起來，最好定義出單獨的業務場景演示給客戶看，並且盡量使用業務語言描述。這樣能讓客戶的業務人員感覺更有親切感，看到開發團隊的人員能夠用業務語言進行描述和演示，他們一定會留下好的印象。
4. 企圖覆蓋所有路徑
在系統功能中，通常會有「用不同路徑實現相同或類似功能」的情況，比如乙個上傳檔案的功能有多個入口，但到達的上傳檔案頁面是相似的。有人在演示這個檔案上傳功能的時候，企圖把所有入口的檔案都完整演示一遍，到後來根本沒有觀眾願意關注，都在私下討論了，有時也會有客戶業務人員直接出來制止。
正確做法：只演示最關鍵路徑。
在遇到多個路徑實現相同或相似功能的時候，對其中一條最複雜／重要的路徑進行詳細演示，其他路徑提到即可，並指出其他路徑不同的地方，不需要一一演示，以節省時間。
5. 過多提及跟演示功能無關內容
有人天生能聊，展示的時候也喜歡囉囉嗦嗦的說一大堆，經常會提及一些跟正在演示功能無關的東西，或者提及團隊採用的技術方案等業務人員不感興趣的內容，導致展示過程不能按時結束，甚至忽略掉某些重要的反饋。
正確做法：只提及要演示的功能。
6. 認為展示僅僅是ba或qa的事情
業務分析師（ba，business analyst）和質量分析師（qa，quality analyst）通常是團隊中跟業務打交道最多的，也是最了解業務的，而展示就是給客戶的業務團隊做系統演示，於是團隊其他角色就會有人覺得展示僅僅是ba或者qa的事情，跟自己無關，也不關注。
正確做法：人人都可以展示
展示不是某個角色獨佔的。團隊中的所有人只要對業務、對要演示的系統功能足夠了解就可以負責展示。通常可以採用讓團隊中的不同人員輪換負責展示的方式，以增加團隊成員在客戶面前的**率，同時也能增強團隊中不同角色人員熟悉系統、熟悉業務的意識。另外，就算不主導展示，團隊人員也可以盡量多參加展示會，這是乙個了解系統、聽取客戶反饋的絕佳機會。
7. 不熟悉的新人負責展示
既然展示不僅是ba或qa的事情，常常也會有其他角色來參與負責這件事情。從團隊能力建設的角度考慮，pm有時候會讓一些資歷淺的同事或者新來不久還沒有好好了解系統的同事來做展示，結果就是演示過程非常生硬，甚至會有很多說不清楚的部分，而在一旁聽著的ba/qa只好著急的上來幫忙解釋。
正確做法：展示前先充分了解系統和業務
雖然人人都可以展示，但不建議採用給青澀新人提供展示機會的方式來幫助他們提高能力，如果要給新人鍛鍊機會，可以讓新人在結對程式設計、story kickoff、提前驗收的時候多多主導，等到對系統和業務有了一定了解時再給客戶展示比較好；或者新人非常有意願直接主導展示會，那麼一定要在演示前做好對系統和業務的充分了解，以能應付和解答客戶的挑戰和疑問。
敏捷展示會的七宗罪與團隊實踐反思
最近在看 深入核心的敏捷開發 這本書，發現確實有不少乾貨的，能夠解答我不少問題，特別是其中對於展示會的論述很到位。由於參與展示會的目的是展示迭代成果，參與人員大多是關係到專案成功與否的關鍵人物，因此會有不少的上級領導或客戶代表等大佬，他們時間都很忙，所以如果到了預約時間無法進行演示那麼情況就不好了，...
Scrum 常見錯誤實踐 之 過長的站會
站會看起來很簡單，在實踐過程中，卻經常會出現控制不當而導致達不到應用效果的狀況。我只是結合自己的一些過往經歷作一些淺顯的總結。乙個很常見的就是站會拖得太長。一般來說站會不應該超過15分鐘，每個人應該不超過兩分鐘 但是很多時候都會因為在站會上討論 具體的技術問題而拖長時間 這是應該重點避免的情況。一是...
薪資談判應該避免的7個錯誤
得到乙個新的工作機會，或者談成一筆新的生意是非常令人振奮的 那麼問題來了，接下來該如何談判呢？談判過程很傷腦筋，而且非常容易犯錯誤，特別是如果你還不具備足夠的談判經驗的話。在你進入下乙個談判之前，請務必注意這七個常見的談判錯誤。1.缺乏信心 很多人認為他們需要表現出某種自信，為了能談判成功需要例如說...