【筆記文】全台敏捷大調查,Scrum Master 的三兩事

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:還是應該要回到為何要做這件事? 為了團隊自主管理、有助於團隊實現商業價值、對齊商業指標、響應變化的能力⋯⋯。敏捷可以運用在更多領域。...

November 21, 2021 · Cheng Wei Chen

DevOps 推薦書單

(本文於 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....

November 30, 2016 · Cheng Wei Chen

C.C. Agile #51 - 「翻硬幣遊戲」簡短紀錄

自從參加幾次 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 從較大數字縮小到一個合適的數字時,可以發現有非常明顯的改善效果。...

November 25, 2016 · Cheng Wei Chen

Agile Tour Taipei 2015 筆記與心得(五)| Scrum Estimation Model - Joey Chen (91)

在得到「欠筆記文欠過年」的成就之後,硬是擠出一個下午的時間,終於整理完 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 有多少。...

February 29, 2016 · Cheng Wei Chen

Agile Tour Taipei 2015 筆記與心得(四)| 邁向 Scrum of scrums - 杜秉穎、練出精實UX - Mike Chou

接續同系列文章《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 好像沒感覺又好像很害怕。因此驅使他們決定新一波的敏捷改革。...

December 14, 2015 · Cheng Wei Chen

Agile Tour Taipei 2015 筆記與心得(三)| 從 Agile 到 Lean Startup:趨勢的軟體開發之旅 - Jason L Lin

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

December 5, 2015 · Cheng Wei Chen

Agile Tour Taipei 2015 筆記與心得(二)| 如何在組織內有效引領敏捷變革 - Richard Hsiao, 蕭存喻

接續上篇文章《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 之後讓一切的資訊變得「透明」,在資訊公開且交流順暢的狀況之下,團隊都能了解明白目前的現狀,這有助建立團隊彼此(包含上層與下層之間)的信任。 第二階段:...

November 21, 2015 · Cheng Wei Chen