背景資訊 在 2022 年底時，有一個機會和 DDD Taiwan Community 的社群朋友聊天，本來是聊天，但聊到最後變成邀請他來幫團隊帶了幾次 Event Storming。
因為有了當時的經驗，後續順利將這項「引導工具」引入公司、團隊，甚至是客戶端，因此秉持著「取之於社群，回饋於社群」的想法，將自身獲得的經驗，於 2024.02.29 回饋分享至 DDD Taiwan Community。
KKTIX 的活動報名頁面 DDD Taiwan Community 在 FB 上發佈的活動貼文 筆記女神 Anna Su 為當晚活動留下的筆記文 因為這是一個來自於我個人、團隊及運用在客戶端的經驗談，因此我將主題與內容設定為較軟性的主題「Event storming 是個好東西：幫助團隊看見全貌，引發團隊變革新契機」，主題的簡介如下：
當你想要導入 CI/CD、DevOps 或 OOXXOps 時，你會如何幫助所有的夥伴建立相同的共識？讓大家可以看見相同的全貌及痛點？
當團隊開始重視 DevOps 核心精神中的「交付價值、持續改善」時，我們確實需要一些不同於傳統會議與組織溝通的方法，來輔助不同的部門及團隊打破 silos 共同看見整體流程的完整面貌，畢竟我們都知道 DevOps 從來都不是一條龍工程師自己的事情。
在本次的 Meetup，我將會聊一聊幾個來自真實場景的小故事，分享這段由 Event Storming 所觸發的團隊變革旅程。
內容分享 因為這次分享的經驗都來自於目前任職的職場，因此針對內容有做了一些去識別化，就請容我不公開釋出完整的簡報，下面就以幾張簡報快速說明這次分享的內容。
如前面提到的，這次設定的是一個很軟性的主題，主軸就是想要分享這一段時間以來，基於 Event Storming 得到的一些經驗與學習。
其中，最深的感受就是，Event Storming 是一個很棒的「引導工具」（好東西），這個好東西它好在哪裡呢？它好的地方在於，透過它我們有機會能幫助團隊「看見全貌」，藉此為「變革」這件事，創造一個「契機」。
同樣如前面所述「取之於社群，回饋於社群」，我個人能夠認識與學習 Event Storming，歸功於過去在社群中認識的國昭與 Tim，再次特別感謝他們兩位。
本來 DevOps Taiwan Community 二月底也要舉辦 Meetup，但後來因為原定的講師時間喬不攏，再加上剛過完農曆新年，也不容易臨時安排其他備援講師，最後因緣際會的就跟 DDD Taiwan Community 的組織者 Kim 談定，二月底就由 DDD Taiwan 主辦 + DevOps Taiwan 協辦的方式來結束這一回合，這裡也再次感謝 Kim 接受我的臨時提議。...
今晚 DevOps Taiwan 舉辦了 Meetup #2 。感謝葉秉哲與 Erica Liu 兩位講師的鼎力相助，以及五倍紅寶石出礦坑贊助場地，讓本次 Meetup 能順利舉辦！
本次活動報名人數 45，實際到場人數約 30，看來免費活動常見的通病依然再次發生。有限名額被占據，但未能到場參加活動，導致其他很想參予的社群朋友沒有名額。這樣的情況實在很可惜，因為今晚的活動真的很精彩，希望能讓更多人可以現場參予。
這次 Meetup 的主題是「思維引導、持續改善，引發團隊改變新契機」。
延續 iThome DevOps Summit 2016 的熱度，我們計畫邀請葉大再次分享在 Summit 中大獲好評的講題「從限制理論看 DevOps」，並期望能讓講題更有感，所以規劃加入小遊戲，透過實際體驗的方式，讓大家能更有所收穫。畢竟觀念很容易聽，但要做卻是不易，特別 DevOps 與團隊文化有關，而人並不是這麼容易被改變的。
主題一：「從限制理論看 DevOps」 同樣的題目「從限制理論看 DevOps」，但本次 Meetup 可是獨家擴充版！比起 iThome DevOps Summit 2016 講得更慢更多更詳細。講題由葉大從多場 Ansible Workshop 中收集到的 DevOps 痛點開始說起，將痛點歸納成 11 大項之後，接著該怎麼解決它們呢？
一般的想法大概是各個擊破吧？但這樣做正確嗎？會不會是治標不治本？另外，這些問題似乎彼此牽連，好像並不是這麼容易各個擊破的，那該如何處理呢？於是切入本主題的核心重點「高德拉特的『限制理論』」。
葉大藉著一步一步的解釋他如何運用高德拉特的理論來推導前面 11 個痛點的因果關係，讓聽眾彷彿跟著走了一遭，相信有認真聽講的朋友，應該不時在心中點頭，並且腦袋也跟著一起運轉了一回。
當透過推導畫出 CRT 圖表之後，再拿它對照原本的 11 個痛點，恐怕大家都會希望自己的團隊中，也能經歷這樣的過程，將單一的問題轉化成有系統的 CRT 圖表，讓問題可以像串肉粽一樣的產生關聯，找出真正的肉粽頭，從源頭解決核心問題。
這場分享並未到此打住，接著再回到另一個重點「老闆主管都是豬頭嗎？」，我們應該正面一點，「老闆主管不一定是豬頭，他們只是遇到了無法解決的『衝突』。」
什麼樣的衝突？如果要持續的交付客戶滿意的軟體，到底團隊該將資源投入在「產品研發」還是「DevOps」上呢？在資源有限、資源搶奪的狀況下，主管當然很苦惱阿！所以主管不一定是豬頭，而是碰到了無法解決的衝突。
而偉大的高德拉特博士依然有解！面對衝突要找出其中的「錯誤假設」。難道投入研發就對「改善團隊體質 (DevOps)」沒有幫助嗎？反之難道投入 DevOps 就對「提供優質產品」沒有幫助嗎？這是值得思考的！
這場分享個人覺得值得多次回味，對於沒有接觸過高德拉特及 TOC 的人來說，應該是一個很好的魚餌，能讓人稍微一窺這些理論工具並非只是空談，吸引你更深入的了解認識它，甚至學習運用它。
葉大已經將今晚的分享錄影釋出，也寫了一篇導讀，對此主題有興趣者，可以深入閱讀。 http://school.soft-arch.net/blog/157917/devops-a-toc-perspective
主題二：「持續改善：找出流程中的瓶頸與浪費」 這場分享我們邀請到泰迪軟體的 Erica 來帶大家用小遊戲的方式進行。...
接續上篇文章《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 之後讓一切的資訊變得「透明」，在資訊公開且交流順暢的狀況之下，團隊都能了解明白目前的現狀，這有助建立團隊彼此（包含上層與下層之間）的信任。
第二階段：...