打怪升級路線圖
27 December, 2016
已移到 https://william-yeh.net/post/2016/12/game-frame/
License:
CC BY-NC-SA 4.0
(姓名標示-非商業性-相同方式分享 4.0 國際)
軟體架構・絮語
Automate everything, make life easier!
Delegation Poker 也可以很催淚
09 December, 2016
如我在〈明示的藝術〉後半段所介紹的，我最近一直在找機會推介 Delegation Poker。
整個過程可分三階段。
第一階段，先找自己直接帶的組員牛刀小試。有足夠的默契及心裡安全感，讓我可以放膽實驗，初步掌握這道具的眉眉角角。
我先從 Delegation poker pres V3.0 投影片當中，擷取其中的 "Delegation Poker Stories" 十大示範案例做為暖身。暖身完後，自認有把握了，索性直接進入真實題：「你們認為，我對你們的授權等級是什麼數字？」
結果還滿成功的，也跟自我的認知相符。
第二階段，我打算找另一個小組合作，密謀排演一齣...
導入的參考順序
01 December, 2016
這是個改革方案層出不窮的年代。
在研究任何改變或改革方案時，我總喜歡順便調研一下，方案倡議者，是否有明示出任何導入順序？
每個個案，當然各有獨特的脈絡，無法強求 100% 相同的導入順序；但若有一些路線圖作為參考基準，會讓人更放心嘗試。
可惜的是，許多改革方案都是淪為個人經驗談，沒有跳脫黑手經驗，沒有歸納出可偽證檢驗的建議實施順序，以及過程中可能遇到的抵制改革層次。
這是高風險的。
所以，當我看到 TOC 的「應用專題」，真的是嚇了一大跳。
怎麼會有這麼縝密的改革戰略及戰術？
高德拉特在《絕不是靠運氣》書中，展現 Thinking Processes...
工作分解講座・閱讀材料
30 November, 2016
我在〈One-Week Sprint 的節奏〉一文提到個人的 Scrum (subset) 首航經驗：
第一個 sprint 順利達標，儘管變數層出不窮。萬萬沒想到第一次嘗試帶 Scrum，而且是「1 舊人 + 2 新人」的高風險組合，就很有機會實現。除了天時地利人和的配合，事先認真的 WBS 分析，應是重要因素。
後來幾個 sprints，大體上也都順利達到 due-date performance。回顧經驗，我仍然認為「事先認真的 WBS 分析」，應是重要因素。
所以，當我想試著將成功經驗推廣到其他專案上面，有一個重要的前置作業，就是灌輸全員 decomposition...
專案的一般症狀
24 November, 2016
高德拉特《關鍵鏈》一書，藉由 EMBA 課堂的師生問答，點出專案預估及執行的許多盲點，尤其是根深柢固的錯誤假設。
非常犀利。光是看這整個論證過程，就值回書價。
即使在我處的軟體研發產業，有許多異於一般專案的問題（這也是敏捷方法誕生的主因），但共通問題仍然過半。所以，研究一般專案的問題，仍然會有啟發（即使你最後不採用 CCPM 解法）。
高德拉特的書，特色就是論證嚴謹，尤其是因果推理。可惜的是，《關鍵鏈》這本書，對於專案問題的整套論證，完全形諸文字，尤其是對話，而沒有像前一本《絕不是靠運氣》那樣好心地將 CRT 畫出來。
少了 CRT...
明示的藝術
23 November, 2016
明示，許多時候是正解。
但過程要細膩，尤其是心理安全感，慎防挑起防衛機制。
在專案管理上，我至少看到兩個地方值得仔細處理這議題。
其一。
高德拉特《關鍵鏈》一書，藉由 EMBA 課堂的師生問答，點出專案預估及執行的其中一個盲點：
（一）我們一貫以為，要保障專案整體，唯一之途就是保障專案所有步驟的完工日期。此舉的結果是：（二）我們在所有步驟都添加了很多安全時間。（三）我們受困於學生症候群 (students' syndrome)、多重任務，及逾期的時間累積（而提前完工所賺得的時間卻不會累積）等這三個現象。這三個現象一旦結合，會浪費絕大部分的安全時間。
姑且不提全套...
物的狀態
22 November, 2016
精實生產與限制理論都講究辨析「物」的狀態。儘管兩者偏重角度不同，優先順序不同，但並列比較，是很有意義的。
豐田生產方式的特點是「物的流動化」。《流的傳承》pp.131–138...
看板 = 看到黑影就開槍？
21 November, 2016
Kanban in Action 這本書，一直是我很珍愛的實戰寶典。我也多次從這本書第 13 章取材一些簡單但寓意深刻的遊戲，像我在〈有了 Agile，為什麼還要有 DevOps？〉演講前半段所示範的，就是改編自本章的 "The Dot Game"。
看板方法最吸睛的，就是號稱「讓瓶頸無所遁形」的看板。所以，看這本書時，不要一下子就跳到作者開的處方，應該忍住，先仔細端詳看板，思考一下，眼前的看板，哪裡是瓶頸？該如何採取必要的措施？或者，先不急著採取措施？
把你的假設說出來，把你的論證說出來。這樣才會進步。
就拿本書 §7.3.2...
「透明度」是導入敏捷方法的罩門嗎？
20 November, 2016
不止一次被人問到：「想推動 Kanban 方法，但擔心實施後，進度太過於透明，有疑慮」、「想推動 Scrum 方法，但擔心實施後，燃盡圖太過於透明，有疑慮」⋯⋯blah blah blah
當下我往往會直接反問：「難道，在沒有導入這些 xx yy zz 敏捷方法時，你們專案都沒有任何進度透明化的機制嗎？」
在敏捷方法尚未出現的年代，就有一堆進度透明化的機制，像 PMP 陣營講究的實獲值管理 (EVM)，甚至連成本都綁在進度裡面呢。
所以，問題不在於敏捷與否，在於公司的專案治理機制。
不管要不要用敏捷方法，你都得面對進度透明化議題。
再度搬出我的...
Kanban 對 TOC 的抬槓
18 November, 2016
有時候，看不同陣營的抬槓，真的很有趣。
像 Kanban 就是一例。
眾所周知，Kanban 方法有一部分淵源來自 TOC，尤其是同屬 pull 系統的「鼓-緩衝-繩」(Drum-Buffer-Rope; DBR)。當然啦，後來 Kanban 將主要的思想淵源獻給 Toyota Production System 及 Lean 思維，甚至如〈与精益大师论剑摘录〉此文所說，更直接的淵源，是 Donald Reinertsen。
英雄所見略同，相互交融最佳實務，本就是業界常態。不過，從 Kanban 之父 David J. Anderson 的 Kanban:...