軟體架構・絮語

Automate everything, make life easier!

導入的參考順序

這是個改革方案層出不窮的年代。 在研究任何改變或改革方案時,我總喜歡順便調研一下,方案倡議者,是否有明示出任何導入順序? 每個個案,當然各有獨特的脈絡,無法強求 100% 相同的導入順序;但若有一些路線圖作為參考基準,會讓人更放心嘗試。 可惜的是,許多改革方案都是淪為個人經驗談,沒有跳脫黑手經驗,沒有歸納出可偽證檢驗的建議實施順序,以及過程中可能遇到的抵制改革層次。 這是高風險的。 所以,當我看到 TOC 的「應用專題」,真的是嚇了一大跳。 怎麼會有這麼縝密的改革戰略及戰術? 高德拉特在《絕不是靠運氣》書中,展現 Thinking Processes...

READ MORE

工作分解講座・閱讀材料

我在〈One-Week Sprint 的節奏〉一文提到個人的 Scrum (subset) 首航經驗: 第一個 sprint 順利達標,儘管變數層出不窮。萬萬沒想到第一次嘗試帶 Scrum,而且是「1 舊人 + 2 新人」的高風險組合,就很有機會實現。除了天時地利人和的配合,事先認真的 WBS 分析,應是重要因素。 後來幾個 sprints,大體上也都順利達到 due-date performance。回顧經驗,我仍然認為「事先認真的 WBS 分析」,應是重要因素。 所以,當我想試著將成功經驗推廣到其他專案上面,有一個重要的前置作業,就是灌輸全員 decomposition...

READ MORE

專案的一般症狀

高德拉特《關鍵鏈》一書,藉由 EMBA 課堂的師生問答,點出專案預估及執行的許多盲點,尤其是根深柢固的錯誤假設。 非常犀利。光是看這整個論證過程,就值回書價。 即使在我處的軟體研發產業,有許多異於一般專案的問題(這也是敏捷方法誕生的主因),但共通問題仍然過半。所以,研究一般專案的問題,仍然會有啟發(即使你最後不採用 CCPM 解法)。 高德拉特的書,特色就是論證嚴謹,尤其是因果推理。可惜的是,《關鍵鏈》這本書,對於專案問題的整套論證,完全形諸文字,尤其是對話,而沒有像前一本《絕不是靠運氣》那樣好心地將 CRT 畫出來。 少了 CRT...

READ MORE

明示的藝術

明示,許多時候是正解。 但過程要細膩,尤其是心理安全感,慎防挑起防衛機制。 在專案管理上,我至少看到兩個地方值得仔細處理這議題。 其一。 高德拉特《關鍵鏈》一書,藉由 EMBA 課堂的師生問答,點出專案預估及執行的其中一個盲點: (一)我們一貫以為,要保障專案整體,唯一之途就是保障專案所有步驟的完工日期。此舉的結果是:(二)我們在所有步驟都添加了很多安全時間。(三)我們受困於學生症候群 (students' syndrome)、多重任務,及逾期的時間累積(而提前完工所賺得的時間卻不會累積)等這三個現象。這三個現象一旦結合,會浪費絕大部分的安全時間。 姑且不提全套...

READ MORE

物的狀態

精實生產與限制理論都講究辨析「物」的狀態。儘管兩者偏重角度不同,優先順序不同,但並列比較,是很有意義的。 豐田生產方式的特點是「物的流動化」。《流的傳承》pp.131–138...

READ MORE

看板 = 看到黑影就開槍?

Kanban in Action 這本書,一直是我很珍愛的實戰寶典。我也多次從這本書第 13 章取材一些簡單但寓意深刻的遊戲,像我在〈有了 Agile,為什麼還要有 DevOps?〉演講前半段所示範的,就是改編自本章的 "The Dot Game"。 看板方法最吸睛的,就是號稱「讓瓶頸無所遁形」的看板。所以,看這本書時,不要一下子就跳到作者開的處方,應該忍住,先仔細端詳看板,思考一下,眼前的看板,哪裡是瓶頸?該如何採取必要的措施?或者,先不急著採取措施? 把你的假設說出來,把你的論證說出來。這樣才會進步。 就拿本書 §7.3.2...

READ MORE

「透明度」是導入敏捷方法的罩門嗎?

不止一次被人問到:「想推動 Kanban 方法,但擔心實施後,進度太過於透明,有疑慮」、「想推動 Scrum 方法,但擔心實施後,燃盡圖太過於透明,有疑慮」⋯⋯blah blah blah 當下我往往會直接反問:「難道,在沒有導入這些 xx yy zz 敏捷方法時,你們專案都沒有任何進度透明化的機制嗎?」 在敏捷方法尚未出現的年代,就有一堆進度透明化的機制,像 PMP 陣營講究的實獲值管理 (EVM),甚至連成本都綁在進度裡面呢。 所以,問題不在於敏捷與否,在於公司的專案治理機制。 不管要不要用敏捷方法,你都得面對進度透明化議題。 再度搬出我的...

READ MORE

Kanban 對 TOC 的抬槓

有時候,看不同陣營的抬槓,真的很有趣。 像 Kanban 就是一例。 眾所周知,Kanban 方法有一部分淵源來自 TOC,尤其是同屬 pull 系統的「鼓-緩衝-繩」(Drum-Buffer-Rope; DBR)。當然啦,後來 Kanban 將主要的思想淵源獻給 Toyota Production System 及 Lean 思維,甚至如〈与精益大师论剑摘录〉此文所說,更直接的淵源,是 Donald Reinertsen。 英雄所見略同,相互交融最佳實務,本就是業界常態。不過,從 Kanban 之父 David J. Anderson 的 Kanban:...

READ MORE

用 POOGI 角度看 Scrum 案例

手中有 hammer,看到什麼都覺得像 nails。 很神奇,雖然我在看的是 Scrum 之父 Jeff Sutherland 寫的《Scrum:用一半的時間做兩倍的事》第六章,但卻一直嗅到 TOC 聚焦五步驟的蛛絲馬跡⋯⋯ Medco 公司有一個原訂一年要竣工上線的專案,整個華爾街都在看,但幾個月後,專案無明顯進展,眼看半年後就要跳票了,大家卻束手無策: It took the company nearly six months to figure out that they couldn't do it on time. Their calculations...

READ MORE

Story point 的數值

森田直行,是稻盛和夫「部門獨立核算制度」(變形蟲式管理法)的傳道士。對於變形蟲式管理法的基本概念,森田如此說明: 人類擁有追逐數字的本能。只要數字的根據夠可靠,任何人都會很專注地追著數字跑、為數字變得熱血沸騰。不過,唯獨管理部門必須以冷靜目光來看待公司整體的數字。--- Quote: 《稻盛和夫的最後決戰》 數字之於人如此重要,也因此,給數字時要非常謹慎,留意它可能帶來的副作用。 難怪 Scrum 要用 story point 來代替工時預估,就是故意用「創造性模糊」給個初步的估計,但又避免陷入絕對數字的泥淖。 在傳統 PMBOK 體系中,Scope Management...

READ MORE