網路效應與路徑依賴，談為什麼要推廣敏捷文化

為什麼有這麼多大大努力的到處推廣敏捷文化呢？不是自己公司搞好就好了？何苦到處找人分享和討論呢？為什麼要辦那麼多活動呢？有些人不能參加活動，又為什麼要在網路上鍵盤推廣敏捷呢？(咦？) 在探討這些問題前，我們先來瞭解兩個經濟學的名詞：網路效應與路徑依賴

薩提爾與麥肯錫菁英的思考習慣如何解決負面情緒

麥肯錫經營的思考習慣 這本書中主要在講如何避免在面對高強度的壓力下產生負面情緒，裡面提到了情緒 ABC：

A (起源事因) —> B (信念) —> C ( 情緒與行為)
A 是既存事實不會導致 C
真正促成C 的是B

而負面情緒則是由錯誤的堅定信念所產生，這在薩提爾的鬆動核心觀點(信念)有提到，對應的核心觀點的keyword就是：

• 永遠應該怎樣 ...
• 這必須怎樣... 
• 一定得怎樣...

而書中建議的就是，從必須型思維變成願望型思維(有時也可以，不是絕對的，希望可以達到..)
如何從“必須型”轉變為“願望型” 五個步驟：

第一步，要肯定你的願望或者目標是有重要價值的﹔
第二步，要去否定絕對的要求，但它不是必須要實現的﹔
第三步，要考慮多種結果的可能性﹔
第四步，現實地評價壞的結果發生的情況﹔
第五步，就是盡最大的努力去實現最好的結果。


這與薩提爾的教練策略不謀而合：

1. 觀察不尋常(有盲點)的行為模式
2. 詢問/反映行為模式背後的核心觀點
3. 探索過去學習的經驗
4. 肯定此觀點"過去"對夥伴的價值
5. 探詢此觀點"現在"對夥伴的意義 (想法/情緒)
6. 詢問夥伴是否想改變
7. 引導夥伴探索改變的第一步
8. 讓夥伴整理鬆動核心觀點得時機 

差別在於薩提爾是在幫助夥伴改變，而本書的思維是幫助自己改變思維，進而遠離壓力下產生的負面情緒。

從法律經濟學的責任監管問題談 DevOps 間的關係

這題目是不是看起來有點太高深了，怎麼還可以跟DevOps扯上關係？

會有這樣的聯想，主要是啟發自薛兆丰的北大經濟學 - 法律經濟學單元，談論的主題是責任與監管問題，聽完的當下就突然覺好多東西似乎都可以用法律經濟學的角度來分析與解釋，因為在現實世界中很多東西都是 Tradeoff，不是非黑及白，但是總還是得做出判斷和抉擇，這時候法律經濟學的一個重要作用，那就是通過經濟分析，給我們的決策者提供可行性方案的比較和選擇。

[引導型敏捷領導力課程] 談管理、領導與追隨

趁著假日陸續整理和和消化之前上課的筆記，有許多東西值得好好回味和思考，話說引導型敏捷領導力課程的第二天，我們談到了管理（Management），領導（Leadership）與追隨（Follow hood），前面兩個詞相信大家一定都不陌生，畢竟這就是我們想學習的東西，但是追隨呢？到底什麼是追隨，在討論中我們不時的把追隨想成追隨者，也就是有人領導就要有人追隨，但是在一個Autonomy 的組織中誰是領導者？誰要追隨誰？如何追隨？怎樣算是好的追隨？

DevOps HandBooks - 第二章 The First Way 流程的原則

在鳳凰專案這本書中一直提到卻沒有詳細說明的三步法(不知道翻三扳斧如何XD)，作者故意留到DevOps Handbooks 這本書才詳細說明，這就是傳說中得埋梗。

第一步： 流程的原則 (the principle of flow)


所謂的流程談論的就是如何有效率的傳遞價值流程（ Value Stream）：也就是從 Business 端產生想法和需求，到 Customer 真正使用並且給予回饋（不論是金錢或是評價），所以第一部流程的原則就是減少 lead time，也就是減少從需求到部署商轉的時間。

書中整理出優化流程的步驟，也是我們每天努力改善的項目：

1. 把工作視覺化 

2. Limit WIP

這兩個步驟應該不用多說，之前在鳳凰項目沙盤推演 workshop 遊戲流程也有提到，想要深入瞭解可以參考"看板實戰"。

3. 減少Batch Size (single piece flow)

4. 減少工作移交的數量

圖片來源：The DevOps HandBooks

所謂Single Piece Flow 翻成白話文就減少批次處理的量，最好是一次做好一件事，只要做到這點就能減少工作移交的數量，越多工作移交的數量，就會需要更多的溝通和更多的文件。

5. 持續找出並鬆綁瓶頸

這也是鳳凰專案中不斷引用高德拉特博士的移除瓶頸的聚焦五步驟：

1. 找出系統的制約因素
2. 決定如何利用系統的制約因素
3. 根據上述的決定，調整其他的一切
4. 把系統的制約因素鬆綁
5. 加入四打破了原有的制約因素，回到步驟一

既然第一步是要找出制約的因素，作者也幫忙列出 DevOps 常見的瓶頸產生處：

• 環境建立 (不管是開發和營運環境)
• 程式部署 (程式從git 拉下來到部署到Production 需要多少時間？)
• 測試建置與執行
• 過緊密的架構

消除價值流中得困難和浪費

除了瓶頸外，在整個價值流中處處都可能藏著浪費，等著我們找出來消滅：

• Particaly Done Work（開發過程中的半成品，甚至是等待review 的工作）
• Extra Processes（對於客戶與開發沒價值的SOP/文件/簽核）
• Extra Features（傳說中得 Over Design和 Gold plating）
• Task Switching（萬惡的Content Switch)
• Waiting（等待指示或簽核，等待資訊，等待誰同意....)
• Motion/ Handoffs （工作交流和換手的過程一些資訊很有可能跟著遺失或變質)
• Defects（不正確/遺失/不清楚的資訊和產品產生，從發現到解決拖的越長越浪費時間）
• Nonstandard or Manual work （工程師都知道重複做超過三次的東西都該自動化~XD）
• Heroics    

最後一點 Heroics (action that is dramatic)特別值得拿出來講，書中舉的例子就是為了達成組織的某個(恐怖的)目標，某些人或某些team 必須承受一些不合理的行動，而這些動作甚至會變成他們每天的工作，每次半夜兩點部署新的程式到Production ，都會產生一堆新的ticket 要處理（那變少測試，那邊要微調，那邊忘了升級，那邊配合人員沒通知....）

結論

瓶頸和浪費不會消失，但是希望可以透過視覺化的方式加速發現的過程，並且透過系統化的方式減少甚至消滅這些浪費。這時候就要透過第二步 Feedback 來幫忙。

謎之音

要注意！上面輕描帶寫的列出許多要改進的地方，要注意的事項，但是隨便一項就可以做到死，要怎麼從Day1 就把這些概念Build in 在日常的開發中就是硬實力，不是靠嘴巴講出來的，是要靠做出來的。這也是為什麼直到Docker出現後，DevOps 的議題才如烈火燎原般燒開，他從根本解決了許多瓶頸，有興趣可以參考這篇文章： Docker and the Three Ways of DevOps Part 1: The First Way – Systems Thinking