Myths and Patterns of Organizational Change - Linda Rising 現場聆聽 Linda rising 的演講後，真正感受到大師的說故事功力，語調沉穩堅定，內容句句切入基本功，淺顯易懂說明了 Agile mindset 的核心觀念與輔助觀念。 1.Agile mindset(我自己認為是 agile 核心的精神，最容易可以向人說明的方式) just do it small success Baby step time to reflection 2.Story over facts 你一定遇過一種人，他/她跟你說話【只會】實事求是，說數據講道理，常常讓你聽不下去，覺得很難溝通，但總是說不出問題出在哪裡。Linda 提醒我們【發揮引響力需要先與人建立連結】，而故事就是你與對方連結(connection)一種很好的方式。 ...
...
探險 今年是第一次搶到票，參加 Agile Tour Taipei 盛會，會說是『一場深度跨領域交流的探險』來自於A,B,C Track 分別是探討的issue是 Product、Dev/Test、UX，可說是三個願望一次滿足，讓我的選擇困難症完全發作，好想同時聽三軌呀呀。同時，一次匯聚三種群體到一場研討會中，更能激發豐富的討論，探索不同觀點的價值，讓對話能夠突破各自熟悉的同溫層，說是一場探險一點也不為過！ ...
文章要點 文章主要分成 第一篇 Part I 是『讓李小龍你看見 Kanban 的美好』的統整和心得，參雜一些個人的解釋 第二篇 Part II 則是我嘗試使用學習到的kanban觀念，改進我的『個人看板』（尚未完成） Kanban 簡介 如果你上網搜尋 Kanban 可能會出現，兩種最常見的解釋，其一是豐田生產模式的 kanban ，發明人為大野耐一，致力於工廠生產效率改善；其二為應用於軟體流程開發的 Kanban (Development)，此方法著名得提倡者 David J. Anderson，他是微軟導入 kanban 方法等敏捷方法的先驅，解救微軟績效不佳的支援部門，設法尋找一套方法讓部門問題自然浮現；早期著名著作有 Kanban: Successful Evolutionary Change for Your Technology Business。 ...
Speaker: odd-e 柴叔(柴鋒) (P.S. 本文演講消化後心得，加入部分我自己觀點) 歷史脈絡 開發、維運，分分合合 柴叔從開發歷史的脈絡娓娓道來，從服務或應用簡單的年代，開發（Development)與維運(Operation)可以一起包辦，但隨著複雜度的提高，逐漸將開發（Development) 與維運(Operation)獨立成兩個團隊。久而久之，雙方的溝通本成增加，合作程度低下，最終造成總體效能下降(開發與測試的關聯，但這邊不詳細敘述)。人們開始思考需要一個穿針引線的角色，他/她需打通開發與維運流程，增進溝通效率，共同協作完成任務，目前當紅的 DevOps的一種解釋。 你以為過去沒有 DevOps? 在遠古開發時代(?)，沒有 Docker 或 Ansible 這類工具。但別忘了其實底層絕大多數的工作，都可以用 shell script 完成，可見 shell script 這類基本功有多重要。時代在改變，但要完成的工作並沒有改變，大多是變複雜，解決問題的觀念類似。 再者，microservice 這類型的觀念，其實也早在 Unix 哲學(Unix philosophy)中被提及，差異是在不同系統層級實作( Do One Thing and Do It Well. 可以對照到 microservice)，當代有更方便工具，抽象化細節與簡化操作流程。 框架工具之於觀念 工具只是溝通工具，而不是溝通的本身 舉例：Jenkins只是CI的工具，CI的關鍵是CI觀念本身，不管用任何方式達成都好 框架工具之於基本功 框架不會幫你解決產品的問題，幾乎與你的產品無關 基礎不紮實，只花時間在學習框架或工具，遭遇的狀況牽扯底層或基本面，也是無法處理 舉例：Java 工程師 v.s Ops 維運工程師 上圖比較 Java 工程師與 Ops 工程師的技能對照，一目了然自己缺少哪個技能。一般前段或後端工程師的 skill set 從 bottom-up 到 top-down 大家都很清楚，但提到 DevOps 大家似乎被 Top-down 工具給迷惑住了！這算是一張check list，提醒自己是否還缺少哪個部分。...