Agile

2021/09/28 的晚上，台灣敏捷協會 ACT 舉辦了一場線上直播【Agile Talks 敏捷論壇系列】全台敏捷大調查，Scrum Master 的三兩事。剛好那一天晚上有一些空閒，於是就來當了一下雅婷逐字稿，邊聽邊記錄了一些自己有聽見的重點，這些重點筆記當晚已經有直接分享於 FB 貼文，本文只是再做一次簡單的校稿與整理。 活動基本資訊 （基本資訊轉貼自活動報名頁面。） 敏捷是這幾年最熱門的話題，Scrum 也是台灣普遍使用的 framework。Scrum Master 這個角色，普遍對他的定位也充滿爭議。感謝 Josh 陳俊樺 佛心對敏捷在台灣社會的發展做了深入研究，並撰述論文發表。 這次 Agile Talks 論壇除了邀請 Josh，還邀請幾位 Scrum Master 一起來對話，來聽聽彼此的看法與研究。 與談人 敏捷實踐者 敏捷行者 / Josh 陳俊樺 魚尾 Agile Coach / Russi 王泰瑞 Jason 廖健勝 主持人 敏捷總舵主 / Hermes 張昀煒 直播影片網址 https://www.youtube.com/watch?v=UPNqzuJnPSQ 筆記 Q: 使用看板方法是否需要 Scrum Master？ 要，因為看板有更多的資訊流與資訊需要解讀，如果有一個角色可以適度的幫助大家解讀，令團隊能有所改善是好的。（謎之音：但這樣的角色還叫做 Scrum Master 嗎？） Q: Scrum 的正確性？ Russi：還是應該要回到為何要做這件事？ 為了團隊自主管理、有助於團隊實現商業價值、對齊商業指標、響應變化的能力⋯⋯。敏捷可以運用在更多領域。 王泰瑞：組織有響應變化的能力不等於組織有能力賺比較多的錢。我當初認為 Scrum 是用來幫助團隊可以不再受到 Waterfall 的壓榨，避免不懂的人只知道壓時程。因為有很多時候，不懂技術、工程的人只懂的壓時程，這當然也不是他的錯，因為他有他要負責的考量。我認為 Scrum 只有適合不適合，沒有正確不正確。Scrum 是一種可以幫助團隊成長的框架。...

（本文於 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 最後一場議程的筆記，壓軸場當然是非同小可，是由絕無冷場的 91 哥為大家帶來「Scrum Estimation Model」這個題目。 同系列所有文章可以點此連結前往《Agile Tour Taipei 2015 筆記與心得》 因為欠筆記文欠太久，91 哥早已將他分享的內容整理成兩篇文章： Scrum Estimation - 如何估算專案時程 Scrum Estimation - Scrum Estimation Model 既然講者都已經把內容寫成文章了，所以老實說我有沒有寫這篇筆記文好像也沒差，那本文就此結束吧。（揍飛） 筆記文由此開始，在一開場 91 哥就直接先用他自己今天的簡報總頁數當作範例，點出本場主題的三大關鍵重點「範圍」、「 時程」與「速率」。 範圍 = 簡報總頁數 時程 = 演講可用的時間 速率 = 每分鐘要講幾頁（才能不超時將內容講完） 基本上這是簡單的數學計算，由「範圍」除以「時程」可得出「速率」，反之你也可以由「範圍」除以「速率」得出「時程」，又或是由「時程」與「速率」得出「範圍」，總之這三個重點是彼此互相關聯的。 但實際上講者講話的速率有限，不可能提升至預期的速率，因此勢必只能延後結束時間或減少簡報頁數。這個開場白其實直接就比喻了專案執行的情況，因為專案執行時也同樣是在「範圍」、「 時程」與「速率」中不斷地協調。 透過開場白 91 哥很快的在聽眾們的心中埋下了「範圍」、「時程」與「速率」的基本概念，整場分享即是完全圍繞著這三大關鍵。 接著 91 哥繼續用「兩個人決定步行前往探視朋友的一段旅程」比喻說明了在專案執行中常見會導致「專案延誤」的意外狀況。 在這個小故事中一樣有「範圍」、「 時程」與「速率」： 範圍 = 交通距離 時程 = 與朋友約定的到達時間 速率 = 一天要移動多少距離 於是隨著小故事的發展，每一天都有不同的意外，但因為「範圍 = 交通距離」是無法變更的（但有可能會錯估），於是故事主角每天都在「 時程」與「速率」中不斷的協調與修正，嘗試要完成這趟旅程。旅程中就發生了各種突發狀況，例如： 錯估交通距離 = 錯估專案範圍 受傷導致行進速度變慢 = 開發速率下降 打電話通知朋友會晚幾天到達 = 嘗試延後 Due Time ⋯⋯等等 藉此案例 91哥再次強調這場分享就是一直圍繞在「範圍」、「時程」與「速率」這三個重點打轉，換句話說這場分享重點就是在講 Burn Down Chart 燃盡圖。 那「範圍」到底是啥？範圍就是專案要完成的工作項目有哪些，你的 product backlog 有多少，估算出來的 story point 有多少。...

接續同系列文章《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 呢？主要是因為有下面幾個新的問題與挑戰：...

接續上篇文章《Agile Tour Taipei 2015 筆記與心得 (一)》，本文繼續記錄 Agile Tour Taipei 2015 上午第二場議程的筆記與心得： 如何在組織內有效引領敏捷變革 - Richard Hsiao, 蕭存喻 這場議程是屬於「經驗分享型」的內容，講者將過去的經驗歸納重點後，將過程中遭遇的狀況與經驗談一一向大家分享。整場簡報的主軸即是講者所處的團隊如何逐步引入 Agile 的心路歷程。 講師的簡報已經公佈上網，可以直接線上瀏覽。 同時 Agile Tour Taipei 2015 已經釋出錄影。 首先講者用一個問題及一張圖作為開場帶出主題「組織在引入敏捷時常見的阻礙爲何？」 這問題的答案有很多，有來自上層或下層的不同的阻礙，例如常見的阻礙有「如何說服老闆接受 Agile？」或「如何說服工程師開始寫測試？」⋯⋯，當然還有更複雜的阻礙。講師則利用簡報 P.3 的圖片作為說明。 圖片中的 X 軸代表的是 Autonomy 由低至高、Y 軸代表的是 Alignment 一樣是低至高。 那麼你的團隊是屬於哪一個象限呢？是左上角的象限，需要由上層下達明確的指令，團隊才能準確的依據指令行動；或是右上角的象限，同時具備高度 Alignment 與 Autonomy，上層只要提需出問題，團隊即能展現高度自治完成任務。又不幸的是左下角，上層與團隊是一整個渾沌的狀態？ 以此開場之後，講師延伸提到了當年他有了一個機會可以開始在團隊中引入 Agile，而這個經驗帶來的第一個心得是「危機就是轉機」，但有一個重要前提是「你需要證明給其他人看」。 「危機就是轉機」這句話大家都能朗朗上口，可是現實社會並沒有這麼簡單。「轉機」來到不等於後面全都會一帆風順，等著看你落水的人比比皆是。所以「轉機」只是一個開始，讓你有機會能取得權責來解決問題。只有在你真正解決了問題，你才能贏得別人的信任，為自己開創新局。 接著講師開始分享過去團隊引入 Agile 的實際經歷，共分成三個階段。細節我就不多描述，因為閱讀簡報就足以說明其中 7~8 成的內容。 第一階段： 這是滿常聽見的一種團隊窘境。團隊處於將要發展並力求表現之時，卻遇到專案進展不順及新主管的介入干擾，面對此窘境想要有所突破，因此決定引入 Agile 嘗試帶來新的火花。 當然團隊不可能立馬全面 Agile，所以在此階段先從可運行的最小實踐開始，先嘗試在團隊中導入了一個 Scrum 看版與 Daily Scrum 會議。 而第一階段最寶貴的經驗是「透明度」！ Scrum 不是萬靈丹，不會因為導入 Scrum 就能讓已經延期的專案忽然變得準時。重要的是導入 Scrum 之後讓一切的資訊變得「透明」，在資訊公開且交流順暢的狀況之下，團隊都能了解明白目前的現狀，這有助建立團隊彼此（包含上層與下層之間）的信任。 第二階段：...