Scrum

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

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

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

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

到底是誰殺了敏捷?

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

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

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

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

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