Ruddy Lee 分享空間

Emergent Design 演化設計

The Phoenix project 導讀

with 4 comments

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

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

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

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

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

36頁

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

資訊閱讀焦慮症

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

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

完全是航海日誌的目錄形式。它僅僅採用日期做章節標題沒有說明。起始日: 由 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頁,第二工作法出現

0 避免

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

 

 

Written by ruddyllee

2016 年 01 月 26 日 於 12:15:16

張貼於未分類

4 回應

Subscribe to comments with RSS.

  1. 請問簡體書在哪可以買的到?

    RogerWu

    2016 年 01 月 26 日 at 13:23:34

    • 已知,目前國內的幾家主要簡體書局(天龍文創、光華的大亨書局)都已經下訂單了,相信很快就可以到貨了。

      ruddyllee

      2016 年 01 月 26 日 at 14:45:14


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: