The Phoenix project 導讀

鳳凰計劃  The Phoenix Project：一本關於IT、DevOps及幫助業務成功的小說

想了解 DevOps的讀者必讀的小說，PPT 在此: 導讀

掀起愛閱讀人士的瘋狂傳閱(我以為 …，但是)

原本以為，這本書在一定程度上會引起IT從業人員的共鳴，並因為DevOps的吸引力，會造成許多人更深層次的了解敏捷的精神。甚至對某些人而言，這似乎正是發生在他們身上的故事。一定會掀起愛閱讀人士的瘋狂傳閱。

但結果是；意外發現資訊人員的「閱讀焦慮症」。工程師在第一次打開來閱讀時，翻不到36頁就放下來的人比比皆是。原因；大部分工程師還是拿閱讀技術書籍的心態在看它。一直急著找到技術的重點，這種心態會讓你越讀下去就越慌，然後在一直找不到重點的情境下，就選擇放下書本，停下來；不自覺的放棄繼續閱讀，真是可惜! 因為重點全在後頭!

常常跟工程師們打賭，你一定讀不到36頁

資訊閱讀焦慮症

一種在閱讀書籍時一直急著找到重點的心態。這種心境普遍存在科技人之間。大抵上是因為他們早已經習慣閱讀大量的科技書籍，擅長快速的在眾多資訊的洪流中搜尋對自己有意義、有價值的資料，而且是一種先求找到再去求證的習慣，久而久之就很容易養成只求快的心態。若拿它來看小說，則因為遍尋不到重點(忽略了小說裡一定會有地鋪陳)，就會被越來越感到焦急的心情所打敗，很容易的就中途放棄了。(我個人認為這可能是常常用Google 搜尋所造成的後遺症)

書本的目錄就很容易引發閱讀焦慮症

完全是航海日誌的目錄形式。它僅僅採用日期做章節標題沒有說明。起始日: 由 9 月2日星期二開始，一路寫到1月9日，共分成三部分，看起來是始終沒有牽扯到DevOps的技術，反倒是接著的簡介部分，才包含了DevOps領域裡著名的「三步工作法」The three ways。為此必須經常事先告知學員，如果你急著看DevOps的技術解答，請直接翻到第327頁，從這裡就只剩下技術了。

這種章節安排方式，讓我肯定三位作者一定也是技術人員，也一樣有閱讀焦慮症的心態，這種只有順序的章節就可以讓那些急著找重點的人，更不容易找到重點，更容易焦慮。也就大大的提升了中途而廢的機率。請耐住性來；看完者篇導讀，再決定從哪裡開始。

第一部分、故事鋪陳，引述IT人的工作生活，為了解決各式各樣的BUG而忙碌。

第二部分、急轉直下的DevOps剖析(建議不愛閱讀小說的人士，從這裡開始就對了)。

第三部分、在給客戶魔法棒的手法之下，盡快取得回饋、重視回饋，才能夠真正解決客戶的問題，因而讓明天變得更好。(這招很好用，試過幾次通常都能拿到客戶所許下願望)

技術人閱讀書籍時，總是有快速尋找重點的習慣，此時第二部分就很適合你的閱讀了。第三部分讓人有好萊塢式電影的感覺，真是兵來將擋順暢的不得了，此時Micro service 的隱喻也悄悄的誕生。

 

給Sprint 取一個好名字

Scrum 的每一個 Sprint 最好都能取一個便於記憶的名稱(最好的名稱是能代表開發工作要達成的目標)，並且拿這個名稱來代表這個Sprint，這麼做的好處在所有的人員都能清楚的知道要達成的目標是甚麼，而客戶也可以知道Demo meeting 他會看到什麼。

透露一下「鳳凰項目」的內容

第一部分，完全在鋪陳IT的立場難為。

• 9 月2號的開始是序曲，尚未進入鳳凰計劃。作者拿因為IT部門的Bug而造成公司花不出薪水的窘境當開始。

• 第 35頁才開始進入鳳凰計劃的氛圍。

• 第 42頁把危機讓整個團隊都知道，讓大家一起知道處境。

• 45頁才出現 ITIL的概念。

• 57 頁，布倫特先生，書裏頭描述造成IT部門瓶頸出現的關鍵人物。

• 第七章，72頁神秘的卡其褲男Eric 出現了(他就是提出The Three ways的傢伙)。

• 77 頁出現 Work In Progress 半成品的觀念，很明顯的三位作者都有看板的概念。

• 85頁，申請增加六個人手卻遭拒絕。理由: 我們IT部門的支出已高於業界標準。

• 94頁，描述如何作才能不要靠英雄(布倫特)來度過難關。

• 104頁，說明讓下屬發揮他的能力並減少干擾。

• 112頁，看板方法運用WIP來限制活動的技巧，在這裡出現了! Blocked 住流程的真正目的是看見問題! 只有在看見真正的問題後才有機會持續改善它，否則就像瞎子摸象，很難看清全局的。

• 116頁，冒煙測試: 打開電路板的電源，只要他沒冒煙，那基本上就能用。隱喻的是軟體在每日構建完成後，對系統的基本功能進行簡單的測試。這種測試強調功能的覆蓋率，而不對功能的正確性進行驗證。

• 137頁，真正交代了書本最後封面所說的 90天期限及IT工作全數外包。

• 142頁，Dev 與 Ops的戰爭情節從這裡開打。

 ※ 請大家告訴大家第17章也就是第二部分的開始，才是真正面對DevOps進行絕地大反攻的開始。

 

第二部分，開始解決許多IT的難題 ，太太重要了!

• 182頁，提出IT部門應該知道自己的能力範圍，是對需求抱著來者不拒的態度呢? 還是依自己的能力，考量接多少案子是IT目前的理想產出才對?

》看板方法的奧義

運用產能來看(找)到團隊的真實生產能力，以便讓生產流程能夠正常化，並以此作為持續改善的依據。

• 194頁，第一工作法出現

• 200頁，第三工作法出現

• 201頁，第二工作法出現

The Three Ways 說明

• 213頁，越早啟動監控系統，便可以獲利越多。

• 214頁，哈哈!第一個 Task Board 出現了(它翻譯成看板，但因為沒有設定WIP限額，所以很難稱之為看板，只是廣義的看板牆，只夠稱之為工作板Task Board)。

• 223頁，引出一段精彩的資源忙碌(百分比)等待說明。

                    等待時間 = (忙碌百分比) / (空閒百分比)

• 233頁，描述"真實對話“是訪談需求時的依據。

• 237/238 頁出現財務總監 CFO對公司全面性的策略說明。

• 248頁，啟動客戶快速回饋的魔術用語:「假如你手上握著魔法棒，你會怎麼做?」，換句話說；就是請許個願吧! 在這裡作者引出了第二工作法: 快速取得客戶的回饋。

• 258頁，安全性議題的重生。約翰再次讓大家跌破眼鏡。

• 263頁開始追尋 ERIC的第三工作法: 持續改善。

• 萬聖節之日 = 鳳凰專案部署日，10/27日 星期一。哈哈! 天下依然大亂。但嚴謹的測試讓我們漸少了太多無意料中的問題。畢竟測試還是值得的。

 第三部分 盡速取得客戶的回饋

• 到了306頁，Micro Service 的概念終於出現了!

…

以下就交給讀者自行去閱讀了(在這裡；必須對愛讀小說的人士致歉，透漏太多訊息了，很抱歉! 但實在是因為太多工程師都讀不下去，只好寫一篇導讀推播一下)。

PPT 在此: 導讀

進一步參考資料:  From: IT Revolution Press  Part 1 ,  Part 2