Lean

（本文於 2018-06-14 21:56:01 更新。） 在某次機緣之下，與尊敬的 Ruddy 老師針對「 DevOps 推薦書籍」有一些簡單的交流。那時整理了手上的筆記，將收集到的 DevOps 書單整理在本文之中。如果你也有推薦的 DevOps 書單，歡迎與我交流！（本文將持續更新，歡迎推薦 DevOps 好書。） （本文同步發表於 Medium） DevOps 不只涉及觀念，也與許多的工具相關，但因為技術工具書，例如：Ansible、Docker、K8S 這一類著重於工具操作與使用的書籍，通常隨著工具更新的緣故，書籍的壽命都比較短。同時並非每一種工具都適用於所有的團隊，因此這類書籍就不收錄在此書單中。 這份書單會以保存期限較為長久的觀念型書籍為主。 Effective DevOps - Building a Culture of Collaboration, Affinity, and Tooling at Scale 這是一本由技術人撰寫的非技術書籍，本書主要在談 DevOps 文化，圍繞在書名副標的那四個項目 Collaboration、Affinity、Tool、Scale，以文化與組織發展為主軸貫穿全書。另外書籍的前面幾章也針對 DevOps 及 DevOps 相關的關鍵字提供了基本簡介，某種程度可以當成一本 DevOps 入門書，可由此再延伸閱讀更多的書籍。（繁中、簡中） Continuous Integration: Improving Software Quality and Reducing Risk 關於持續整合（CI，Continuous Integration）的經典必讀書籍，缺點是目前沒中譯本。 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 關於持續交付（CD，Continuous Delivery）的經典必讀書籍，比較要注意的是因為英文版是 2010 年出版的書籍，因此書中範例提到的軟體會比較老牌一點。另外，在社群中也有前輩表示現今 Microservices、Serverless 等新觀念抬頭，這本書的部分內容應該可以配合這些觀念而有所更新。（繁中） The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 知名的 DevOps 小說，如果當工具書來讀會大失所望，按其他前輩的說法，此書就是要當成小說與實際案例來看，請細細品味書中的劇情及小說人物遇到的困境，並且對照自己的經歷而有所反思，同時嘗試換位思考如果你是小說內的主角你會怎麼面對問題，如此一來才能體會書中的醍醐味。本書也是讓玄妙的 DevOps「三步工作法」首次面世的書籍。（繁中、簡中） The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations 由目前世界知名的 DevOps 顧問 Gene Kim 與他的好朋友們延續《The Phoenix Project》而撰寫的另一本書。如果覺得看完《The Phoenix Project》之後，對於玄妙的三步工作法依然不得要領，那麼這本《DevOps Handbook》就是你的救星。這本書透過案例與說明幫助你一步步實踐「三步工作法」，這些案例不乏許多知名的公司，像是 Google、Netflix、Etsy⋯⋯。（簡中） The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece 另一本值得列為 DevOps 必讀書籍的輕薄好書。本書簡短、輕快且直擊紅心的點出軟體開發的核心關鍵—交付價值，這也正是藏在 DevOps 背後的重要關鍵。若希望讓你的團隊順利踏上 DevOps 之旅，那麼最好讓組織、團隊及個人皆能共同意識到「交付價值」的重要性。（簡中） Site Reliability Engineering - How Google Runs Production Systems 有些人是這麼評論的 “SRE is Google’s version of DevOps”，在《SRE》書中也自己寫到「SRE 是 DevOps 模型在 Google 的具體實踐」。另外在 Gartner 所推出的 Gartner DevOps Model 中，也可以看見 SRE 有被列入其中。這是一本兼具觀念與技術實務的書籍，內容包含很硬的技術實踐與很軟的團隊文化，對於 SRE 有興趣者非讀不可，另外若對你而言 DevOps 與 Cloud Architect 的關係密不可分，那這也是非讀不可的好書。 The DevOps 2....

自從參加幾次 Agile 相關的活動之後，切身體會到「玩遊戲」真的是一種很棒的體驗與學習方式，特別是當你對於某些觀念與情境還沒有足夠的「實務經驗」時，遊戲其實是一個很好的情境模擬方式，讓人在短暫的遊戲中，可以稍稍體會到實務現場中的某些狀況。 因此這次看到 C.C. Agile #51 將透過「翻硬幣遊戲」來與大家聊聊 WIP Limits 及 Lead Time，二話不說，立刻向太座大人請示可否外出放風。 本文就簡單的紀錄這個有趣的遊戲及簡短的心得。  翻硬幣遊戲 本次活動將參加者分成兩組，每組 12 人，各別代表一間公司。 每間公司皆有五個部門（經理、員工各一人）、一位老闆及一位客戶。 遊戲的流程大致如下： 客戶將「硬幣」交給公司，「硬幣」會經過這五個部門，最後完工的「硬幣」再傳回給客戶。 每個角色要做的事情都很簡單： 員工 = 將每一枚硬幣翻面，然後傳遞給下一個部門。最後一個部門則是傳給客戶。 經理 = 幫員工計時，看看他完成工作需要花費多少時間。 客戶 = 從交付硬幣開始計時，當收到傳回來的第一枚硬幣時結束計時。 老闆 = 從交付硬幣開始計時，當客戶收到傳回來的最後枚硬幣時結束計時。 那麼在遊戲中間要怎麼體驗 WIP 與 Lead Time 呢？ 這就看遊戲規劃者如何設計每一回合的詳細規則，例如： 第一回合：只能用單手翻，而且必須要翻完 15 個硬幣，才能將硬幣傳給下一個部門。 第二回合：只能用單手翻，只要翻完 5 個硬幣，就能將硬幣傳給下一個部門。 諸如此類 因此透過遊戲規則的設計，就可以讓參與者體驗到不同的 WIP 的限制下，對於 Lead Time 會產生什麼影響，以及不同的 WIP 對於整體 Flow 流動順暢度的影響。 簡短心得 這次遊戲玩得相當激烈，兩組人馬的競爭心非常強烈！我個人在遊戲中選擇擔任員工的角色，玩到最後，翻硬幣翻到手指流血，你就知道大家都是卯起來玩！這就彷彿現實生活，企業之間競爭激烈，如果不能「持續改善」的公司，終將在競爭中敗陣，所以非要拼得你死我活不可 XD。 如前面對遊戲的說明，在主辦者 Erica 精心設計的詳細規則之下，讓人能體驗到不同 WIP 限制對於整體 Flow 的影響，並且透過比較不同回合的計時數據，可以很明顯看出 WIP 限制對於 Lead Time 的影響，當 WIP 從較大數字縮小到一個合適的數字時，可以發現有非常明顯的改善效果。...

接續同系列文章《Agile Tour Taipei 2015 筆記與心得》，本文繼續記錄 Agile Tour Taipei 2015 下午的議程筆記與心得。 下午選擇的是 Track 2，當時在午飯時間苦惱了一陣子，雖然一度很受到 Track 1「How to apply Agile to Growth Hack - Someda Takashi, 染田貴志」的議題吸引想要先聽 Track 1 再換場 Track 2，但 Track 2 的場地視野不佳、座位也少，考慮到換場一定搶不到好位子，因此最後整個下午都留在 Track 2。 邁向 Scrum of scrums - 杜秉穎 講者簡報已經釋出，可以前往線上觀看。 下午第一場是「邁向 Scrum of scrums - 杜秉穎」，但必須要先自首，因為精神不佳，在這場議程中一度陷入昏迷，所以記錄到的內容超少。 這場議程在劇情上是接續上午「如何在組織內有效引領敏捷變革 - 蕭存喻」的案例，也就是遊戲橘子內部的敏捷變革經驗分享。 首先講者向聽眾問了幾個問題： 團隊類型？ 是新創、公司自開發產品、接外包或其他。 團隊規模？ 5 ~ 50 以上是落在哪一個區間。 開發方法或流程？ 是 Waterfall、Being Agile、Doing Agile或自以為 Agile。 透過問題開場之後，講者開始進入正題，前面的題目也是講者在爲自己鋪梗，因為講者所處的團隊正是經歷由小變大與持續引入敏捷變革的過程。 在他們持續引入的中途遇到了一個狀況，即是乍看之下「團隊好像很 Agile」，感覺該做的都有做 (testing、CI、CD)，但隱約還是感覺有些問題，例如會議時間很長、沒效率且難以達成共識、對 sprint failed 好像沒感覺又好像很害怕。因此驅使他們決定新一波的敏捷改革。...

接續同系列文章《Agile Tour Taipei 2015 筆記與心得》，本文繼續記錄 Agile Tour Taipei 2015 上午第三場議程「從Agile到Lean Startup：趨勢的軟體開發之旅 - Jason L Lin」的筆記與心得。 從Agile到Lean Startup：趨勢的軟體開發之旅 - Jason L Lin 講師的簡報已經釋出，可以由此瀏覽。 第三場議程是由趨勢科技 SQA/SEPG 部門的林立仁為大家分享。講者在自我介紹時特別強調了 SQA/SEPG 部門，根據講者所言趨勢科技很重視軟體開發方法，因此 SEPG 部門的工作之一就是將一些優良的軟體開發實踐帶入公司之中。 趨勢科技推動這些實踐主要是由 Bottom-up 的方式進行，企業文化鼓勵員工做中學並勇敢嘗試錯誤。這種鼓勵學習、容許犯錯的企業文化不知道會戳中多少困在傳統企業文化的開發者？據說趨勢仍然有在徵人，有興趣者不妨可以考慮看看。 （提供一個對照組，上次在 iThome DevOps 2015 研討會中，Yahoo 就提到 Yahoo 推動 CD 時的方式就是 Top-down。） 簡報的前面兩頁是公司簡介，不過講者在提到「經營理念」時，特別強調了「自我提升、保持創新領先地位」，用這一點呼應為何趨勢會在企業內部大力推動導入 Agile 與 Lean statup及前面自我介紹提到企業內部會成立 SEPG 部門。一再的強調趨勢實在是一間鼓勵學習、創新的公司。 接著作為前情提要，講者先快速地介紹趨勢科技導入 Agile 的歷史，主要有幾個重點： 從 2007 年開始嘗試導入。 接著 Bottom-up 遍地開花。 目前已正式成為公司開發者的必讀準則。（但非強制遵守） 現在全公司約 60% 的專案有採用 Agile。 既然趨勢科技已經大幅度的導入 Agile 了，那麼是什麼原因導致趨勢科技仍需要接著導入 Lean startup 呢？主要是因為有下面幾個新的問題與挑戰：...

約在今年 6 月中的時候，iThome 即宣布將在 9 月 1 日 ~ 2 日舉辦 DevOps 2015 研討會，並且開始廣邀徵稿至 7 月 6 日。雖然上次投稿 ModernWeb 2015 沒被選上，但不灰心本次再接再厲再次投稿，想不到還真的有幸被選上，所以除了要上台當講師的時間之外，其他時間則可以免費入場聆聽這兩日的 DevOps 2015 研討會。 網路上似乎已經有一些評論與心得文，所以就不打算重述太多細節，以下就只簡單的記錄個人的幾個心得，針對每一場講題簡短的記錄： 開場致詞 - 吳其勳 / iThome電腦報 總編輯 吳總編輯提到今天的現場約有 300 多人，數量比我個人預期的少？稍微查了一下台大集思的國際會議廳座位有 368 人，首日觀察覺得約 9 成滿，所以人數應該確實是 300 多沒錯，第二天的觀察是約 8 成滿，不知是否大家對於第二日的講題比較沒興趣？ DevOps 運動的全球大趨勢 - 王宏仁 / iThome 新聞主編 王主編再次講了 iThome 網站上已經刊登過的非洲銀行導入 DevOps 的案例，這個案例之所以重要的原因是想要強調就連傳統的銀行業都已經導入 DevOps，那麼身處在軟體、網路、資訊產業你還能不知道什麼是 DevOps 嗎？ CI 伺服器全制霸！活用自動化技術重建「最強」團隊 - 直井 和久 / 樂天 旅遊業務開發維運部 旅遊網站團隊經理 iThome 最近的幾次活動都有找樂天來擔任講者，幾次下來可以理解到樂天的背後確實有強大的技術力，這次來的 直井 和久 先生也是，感覺上在 CI、Jenkins 上的經驗豐富，但實在很可惜因為語言表達的問題，導致這次沒辦法與聽眾們有更多深入的 Q&A 互動，看到他在回答時默默地自言自語說了 How to say 還真是為他捏一把冷汗。不過自己也在自我省察，因為個人在英文的「說」這一方面也是很需要加強，若是在台上遇到英文問題我恐怕也是要冒冷汗了。...