進階專案知識

到底是誰殺了敏捷?

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

該怎樣估價自己的專案價值?我想用商業思維來談

在手上這麼多的專案裡,我如何決定專案執行的輕重緩急?衡量其價值?以及如何有效的切分階段?其實,這幾個疑問其實都指向同一個規則:你沒有一套專案價值估算方法。如果你能估算一個專案價值,那你應該也能估算專案中一個工作包,或一個user story的價值,若一個專案若包含10個工作包,你也能排出這10個工作包的順序。問題是,該怎樣建立自己的專案價值估算法呢?

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

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

為什麼團隊總是對目標無感?你可以用「一個前提」和「一個公式」避免自己落入傳聲筒角色

你的團隊有多麼目標導向,取決於你有多強大,可以讓團隊精準理解並聚焦目標能力,這需要練習,更需要準備。做的到位,不僅能夠讓自己逃出自彈自唱的獨角戲舞台,且常能在數字管理型的組織裡閃閃發亮。但是,應該要怎麼做呢?你可以用「一個前提」和「一個公式」避免自己落入傳聲筒角色。

誰能救救敏捷開發團隊裡的菜鳥?

「如果敏捷團隊中有菜鳥,是不是時間就會估不準?進度就會被延誤?」這個是課堂上常被提問的熱門議題。原因多半是提問者對「菜鳥是否有能力參與好這兩種活動」心存疑慮!現在我們就來看看,Scrum 敏捷式團隊合作方法有哪些設計可以解除或舒緩這種疑慮。

怎麼樣才能建立專案經理的專業感?

對很多專案經理而言,尤其是技術職轉上的專案經理,常常都有很深的焦慮感。因為過去擔任技術職時,會有個感知上很扎實的一技在身,面對別人往往也能拿出技術文獻或是量化數據來佐證。但當了專案經理,聽起來雖然是升職了,但心態上卻感覺虛了很多。因為當管理職,必然會開始接觸一些過去不懂的技術,再加上「大部分時間都只是靠一張嘴去協調」,做久了不免自我懷疑:長久以往,到底該以何服人?

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

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