盧鄭麟 William Lu - 作者系列文章

盧鄭麟 William Lu

盧老師曾任HTC軟體專案經理團隊主管,掌管上百個智慧型手機軟體專案(包含全球首款WiMAX 4G手機),總出貨量超過 1,500 萬支。亦曾於趨勢科技、友立資訊、華康科技、文生真空科技等企業擔任研發部門主管、產品經理,以及總經理室協理等職務,領導軟體研發團隊與管理專案之實務經歷超過20年。 盧老師在教學上善於利用遊戲化教學,將真實情境轉換為模擬個案,引導學員透過動手實作來學習管理知識。授課經驗包含兩岸多家知名企業,例如台達電子、華碩電腦、揚智科技(台北/上海/珠海)、久元電子、飛宏科技、宜鼎國際、精技電腦、震旦集團、南僑集團 (上海)、杏輝醫藥集團、新北市政府等。

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

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

想優化敏捷成效不只靠員工,主管也有應盡的責任!我在龍頭企業高層身上學到的事

敏捷方法表面上看起來相當精簡,只有些簡單的框架、流程,和原則,因此讓許多人誤以為,敏捷方法是一劑可讓專案神速完美完工的特效成藥,自己上藥房買來吃就能見效,然而事實上,卻一點也不是這麼回事。

一定要知道!最易影響專案開發進度的8大障礙

在《開車旅行跟敏捷式專案管理有什麼關係?》一文當中,我們談到了,只要能掌握團隊的產品開發速度,幾乎就等於掌握了整個專案的進展。其實,不論是傳統式還是敏捷式的專案管理,道理都是一樣的。但,到底有哪些因素會影響到團隊的開發速度呢?我們還是先來看看開車旅行的例子。

敏捷雖如專案管理巧婦,無米無灶也難為炊

日前為一家規模龐大的組織進行敏捷式專案管理課程,課前一天傍晚,副執行長熱情晚宴款待,席間提及,某個老舊資訊系統更新專案,執行兩年以來延誤不斷,掌握不了可靠的結案日期,令他相當頭疼,不過在他的話語之間,我倒是感受不到絲毫的怪罪之意!

這2件事沒做好,「敏捷式管理」將難以發揮功效

日前與前來邀課的客戶進行課程對焦會議,根據 IT 主管說法,IT 單位已自行實施敏捷式專案管理方法好幾年了,照理說,這個組織對於敏捷式專案管理的手法應該已經相當熟悉,可是不知道為什麼,卻還有這麼多的痛點,並且痛到下定決心尋求外部顧問的協助。我想,客戶的組織不是缺了兩個重要角色,就是這兩個重要角色因某些因素(如組織結構設計)而無法發揮應有的功能。

找對教練,導入敏捷方法的幫助更明顯!理想輔導者該具備的3項特質

「老師,上課前,我以為 Scrum 很簡單,自己上網看就好了,根本沒必要來上課,今天上完課才知道,原來還有這麼多實務上的眉角(台語)要配,敏捷方法才會有明顯成效,而且,這些都是在網路上沒看過的!還好當初我沒有拒絕老闆派我來上課…」

敏捷專案管理模式下,開發團隊成員能不能動態進出專案?

日前在為某企業進行敏捷式專案管理的導入輔導時,有位同仁這樣問我,「老師,敏捷開發團隊的成員,從頭到尾都不能換人嗎?譬如,臨時加人進來,或有人完成工作後就離開,去做其他專案的事?」「你為什麼會想在要這樣做呢?」「因為有的人比較熟悉這個衝刺要做的任務,有的人比較熟悉下個衝刺的任務,這樣安排不是可以讓他們工作得更有效率嗎?」

從《西方極樂園》看敏捷:生物突變VS.組織變革

生物的演化,的確是靠基因複製時發生「錯誤」,誤打誤撞所造成的,這也就是我們常說的「基因突變」。然而,未必每一種突變都是好的。透過物競天擇的自然機制,適合當下環境者就會生存下來,不適合的就會被淘汰。Ford 博士的這句話讓我聯想到,「組織為什麼會想要變革」的這個議題,頗為有趣。

敏捷方法下,開好「每日立會」的五個小技巧

這件事讓我重新思考了一下「每日立會」這個議題,有些點子和概念應該可以再分享給大家,讓這個會可以開得更有效率和效果,也不會變成流水帳。各位可以試試在開會的時候,聚焦在下面這些點上看看。

敏捷品質管理:笨蛋!問題不在是否能做到「零瑕疵」,而是在「看待瑕疵的態度」

日前於敏捷課堂上,有學員問到,應不應把瑕疵(以下簡稱 bug )列為用戶故事來處理? 這個問題,其實可以分為好幾個層次來探討,我們就先從根源來談起吧! 瑕疵該發生嗎?是理所當然的嗎?瑕疵可以放任多久再處理?瑕疵該以用戶故事紀錄、跟催嗎?

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

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

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

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

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

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

被溝通工具疲勞轟炸? 讓敏捷方法拯救你的團隊效能

有了 email 、 Line 之後,大家用電話分機溝通的頻率就少得多了,同事之間面對面討論事情的機會也變得越來越少!而那些還喜歡用分機或是直接找人開會討論事情的,就算時間都控制得宜,似乎還是會不太受人歡迎。這到底是為什麼?為什麼大家總喜歡在 email 上你一嘴、我一句地,回過來又回過去,結果造成同一主題的 email 討論串愈來愈長,而每個收件人都變成是這一大群 email 轟炸的受害者......

什麼是「忙而不急」的上乘職場功夫?跟敏捷方法又有什麼關係?

我們之所以把專案團隊關在大會議室裡一起近距合作,目的就是希望專案團隊表現得像是「一個人」那樣,1 + 1 > 2,沒有多餘的內耗,就像上面武俠小說裡閉關練功的掌門人一樣。閉關中的敏捷團隊(掌門人)需要有能專注、不被任意打擾的環境,才能展現出超高的效率(練成蓋世神功)。 然而,組織當中一定會有許多意外事件或是新專案欠缺人力等事情發生(邪教來踢館),這些都會讓組織的中高階主管們想伸手去調動閉關中的團隊成員來因應,要他們同時兼顧兩三個專案(出關救門派)。雖然這是常見的兩難,但請務必深思這樣做的長期利弊與得失,會不會變成「賠了夫人又折兵」的窘境呢(掌門人