敏捷方法的成功密技（三）：Scrum 如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？

在上一篇文章《敏捷方法的成功密技（二）：專案管理的「溝通斷層」》中，我們談到了為什麼客戶／用戶的需求總是這麼難捉摸，為何我們要先談這個問題呢？理由其實很簡單，在這個溝通的鴻溝沒有被妥善處理、弭平之前，所有後續的努力與投入都會事倍功半，形成「產品客戶不愛，團隊熱情不再」這個賠了夫人又折兵的窘境。那該怎麼做才能「盡可能」地弭平這個溝通鴻溝呢？

敏捷方法的成功密技（二）：專案管理的「溝通斷層」

在上一篇文章《敏捷方法的成功密技：Scrum 為何對你很重要？》中，我們談到了Scrum這個在敏捷開發方法中頗受歡迎的一派，也談到了敏捷式與瀑布式，在產品開發和專案執行成功率上的巨大差異。可是，既然這個東西這麼讚，又簡單易懂，那為什麼還是有很多公司和組織在導入這個方法的時候，不盡人意，東卡西卡的，無法體驗到敏捷法的巨大好處呢？

大錯特錯！敏捷大師 (Scrum Master) 不是團隊的助理或秘書！

最近，幾位學員在下課之後，都不約而同地問了我一些關於敏捷與職涯發展的問題，有研發經理想轉職當專案經理的，也有品保人員想轉職做專案經理的，我就以此篇文章來做個小整理，提供些淺見給大家參考。

Scrum敏捷方法裡，渾然天成的9大「風險把關」設計

「老師，要管好專案的風險，您覺得是用傳統式的方法比較好，還是用敏捷式的方法比較好？」一位學員在課後向我這樣提問。當下我還真楞了一下，倒不是因為我不會回答這個問題，而是自從教授敏捷相關課程這麼多年以來，這還是頭一遭有人問到這樣的議題。先說我的結論，總體而言，我認為，敏捷方法技高一籌。

到底是誰殺了敏捷？

某次教完【專案管理一日特訓班】的課，下課後，有個問題讓我印象深刻，問問題的，是使用了敏捷大概3年左右研發單位的經理：「老師，我發現最近在使用敏捷的團隊，好像不似幾年前那麼多，好奇怪，敏捷的方法和原則都沒有什麼變化，難道是台灣的組織環境不合適，所以大老闆決定放棄敏捷？開始評估其他的方法？」

敏捷開發就是不用寫文件？該怎樣取捨？優缺如何？

敏捷開發中要不要寫文件是一個問題。該寫多少內容？該寫多深？這類文件製作「質」與「量」的問題，都應該回歸到該文件的原始初衷是什麼來思考。

為什麼 Scrum 敏捷方法倡導「專職專注在一個專案上」

有位學員在課程的中場休息時間跑來問我 :「老師，我們公司都是一個人要同時負責好幾個案子的，你講的『專職專注在一個專案上』，根本就不可能實現的啊？那是不是我們公司就無法使用敏捷方法了？」 說實話，這兩個問題不只一個人問過，我相信，這必定也是許多對敏捷方法有興趣的人心中的疑惑。既然如此，我們就先來聊聊「一人專職專注在一個專案上」這個主題好了