Browsed by
Category: Agile

2022年度回顧

2022年度回顧

Comments 0 Comment
2022年底身體出了點狀況，雖然在年終考評時作了回顧，但一直到今天 (2023/1/13) 才作了比較完整的整理。

在醫院智慧醫療專案方面：

  • CXR-AI：胸部 X 光的 AI 辨識模型主要是 Mora 在帶領，我只是在一旁敲邊鼓、用嘴巴做專案(提出一些 Ops上的想法)，一些成果摘要
    • 藍綠部署：可以用 Zero Down Time 的形式進行 AI model 的升降版，而不會中斷醫院胸部 X 光的即時判斷流程
    • Dashboard：以視覺化的方式，進行 AI model 的效能監控
    • 以數據為基礎進行 iterative & continuous AI learning cycle
    • 專案成果由我們的 AI 數據科學家 Mora，投稿了 PyCon APAC 2002 「醫療影像AI產品落地挑戰與持續優化的歷程分享」( https://bit.ly/3Zm40hj )
  • 企業健檢資訊系統：醫院承接了中部世界級科技廠的健檢業務，面對嚴格的服務需求，我們也重新開發並整合了資訊化的健檢資訊系統。
    • 整個健檢系統包含：體檢現場關卡工作站、RIS2.0 (w/ CXR-AI)、智慧總評報告系統
    • 整套系統讓社福部同仁及家醫科醫師的工作流程能更順暢地進行
    • 建構流程 Pipeline Dashboard，協助社福部數據化管理，加速 Lead Time
    • 我們的產出品質，獲得廠商不錯的評價，也多爭取到今年新竹廠的健檢 Case
    • 這個專案也驗證了動態電子表單架構的技術可行性
  • 管路&個案管理資訊系統：
    • 培養第二個 Scrum Master
    • 建立可與 Legacy HIS 互動的微服務
    • 探索出在 Legacy HIS 逐步抽取出(abstract) HIS 2.0 微服務的開發模式
    • 企業健檢、管路&個案專案經驗已投稿 Agile Summit 2022 「為醫療加裝敏捷的引擎」 ( https://bit.ly/3VdRqPa )
  • 電子表單：可以類比為醫療用的 Google Form
    • 實現醫療欄位化表單
    • 動態生成介面的醫療用電子表單
    • 建立可共用的微服務範例
    • 投稿了 PyCon APAC 2002 「Python Design Patterns」( https://bit.ly/3IBXFrV )

工程實踐

  • Monitoring：
    • 導入 Zabbix 監控系統狀態
    • 導入 Graylog: 記錄 log &  使用者的操作
    • 導入 Grafana: 建立 Dashboard，視覺化地呈現系統狀態及使用者的操作歷程
  • CI：導入 Harbor, Gitlab CI, 提升 DevOps 成熟度(自動化、安全性)
  • Clean Architecture：以 Clean Architecture 實作了院內用戶的 Single Sign On，並分享給團隊成員

團隊建立

  • 1 on 1：
    • 做得不好的地方是頻率降低了，
    • 但在年底時帶著 Member 針對他個人的 output/outcome/impact 做了一次 ORID 的回顧，大家都覺得自己在今年有不少成長，也頗有成就感。這部份明年應該要持續做
  • 跨團隊專案執行：
    以前都是單一團隊執行獨立專案，這部份已經可以成功複製；但跨團隊執行共同的專案，團隊與團隊間的溝通與成果介接仍然有很大的成長空間。

讀書：

應該是讀了不少書，就記錄些還有印象的書

    • Design Pattern ：讀了很多本，算是稍微能分享 Design Pattern 概念
    • Clean Architecture：
      • Clean Architecture
      • 架構模式-使用 Python
    • Domain Drive Design
      • Domain Drive Design, 領域趨動設計
      • Domain Drive Design Distilled
    • 專案相關與溝通
      • 經理人之道
      • 獨角獸專案
      • 我想和你好好說話
      • 李崇建-薩堤爾系列

2023目標

  • 之前太忽略了生活的平衡，今年最主要的目標是把鍛練身體放在第一位，應該會以超慢跑，穴道導引為主。另外也會多安排跟家人相處的時間
  • 技術研究：
    • DDD, Clean Architecture
    • 公司內分享
    • 投稿： PyCon, Clean Architecture
  • 定期公司讀書會
    • 修練非暴力溝通
  • blog: 努力作做到二週一篇文章
[閱讀筆記]目標：簡單而有效的常識管理

[閱讀筆記]目標：簡單而有效的常識管理

Comments 0 Comment
這一本「目標」是高德拉特介紹「限制理論」四部曲的第一本。
全書以小說的形式來介紹「持續改善的流程」，故事發生在一間工廠，廠長及其主要幹部為主角，劇情以廠長羅哥接收到 BU Head 皮區的最後通碟–若三個月工廠的虧損沒有改善，就要關掉整間工廠！
書中以羅哥為第一人稱針對工廠生產流程，分析問題、找出關鍵（瓶頸）、帶領全工廠的幹部逐漸發展出「持續改善」的系統性思考及方法。
記得剛出社會的時候也閱讀了高德拉特這一系列書籍，但當時並没有辦法了解其中的精髓。在經過了十多年軟體專案開發經驗以及學習了 “Kanban” 方法，重新看這一本經典，書中的許多場景在在都引起心中的共鳴。
書中有一場描述羅哥擔任兒子童子軍健行領隊，觀察個別小朋友速度的變動如何影響整個隊伍行進速度的因果推論，真是非常生動而且精準地描寫專案開發當中不同工作階段人員個別的工作變動不可避免地造成整體專案進度的延後
自己延伸的想法：一般專案的時程預估通常都是用平均速率來規畫專案的開發時程，但是每個人的真正開發速率是會有變動的 （個人因素如生病、家裡有事；外在因素：插件、颱風…），而這些的變動會慢慢的遞延到 之後的開發人員，若後面的開發人員想要追上一開始訂定的專案時程就必須要付出近乎兩倍的趕工速度，這不是一個可以持續（sustainable）的工作方式。因此用平均速度來預估專案時程一定是會落後的。
書中提到了聚焦五步驟：
步驟一、找出系統的瓶頸。
步驟二、決定如何利用瓶頸。
步驟三、根據上述的決定，調整其他的一切。
步驟四、把系統的的瓶頸鬆綁。(就是解決它)
步驟五、假如步驟四打破了系統原有的瓶頸，那麼就回到步驟一。
要有能回答三個問題的能力：
  • 應該改變哪些事情？
  • 要什麼方向改變？
  • 要如何改變？
若想要更了解聚焦五步驟，google 一下， David Ko  、 Rudy 老師 、 Project Up 、 William Yeh 都有更深入的介紹，就不在此文中再細談。
接下來摘錄一些自己很有共鳴的句子：
  • 根據我的觀察,這個工廠的訂單可以區分為四種優先次序級別:緊急, 非常緊急, 緊急得不得了, 以及立刻完成!總之,我們就是没有辦法依進度完成訂單.  [P2]
    • 相信大家在執行專案的經驗中，常聽到主管都是這樣的心情及表達吧
  • 工廠要賺錢的衡量指標:有效產出(throughput), 存貨(inventory), 營運成本(operational expense) [P93]
  • 我們一定要把眼光放在整個組織上, 而不是只談製造部門, 或是一家工廠, 或是工廠裡的一個部門. 我們不著眼於局部效益(local optimum) [95]
  • 有效產出是我們收進來的錢, 存貨是目前積壓在系統中的錢, 而營運費用則是為了讓有效產出能夠發生, 我們必須付出去的錢.[P114]
    • 在傳統的工作場域，主管會很在乎個人員工是否有在做事，反而没能注意到團隊真正對外的有效產出，對一個軟體團隊而言就是用戶喜歡的功能，以真正為公司賺到錢為考量。
  • 每個人都時時刻刻都在工作的工廠, 是非常没有效率的工廠. [P132]
  • 大多數的廠長都傾向於盡可能地調節產能, 不要有任何資源閒一旁, 讓每個人的手上都有工作做[P135]
  • 啟動資源（ activating）並不等於有效利用資源（ utilizing ）[P331]
  • 絕對不可以試圖把系統中的每一種資源都發揮到極致。追求局部效益的系統絕對不是好的系統，而是非常没有效率的系統[P331]
    • 軟體專案有時工程師在學習新技術、重構、撰寫測試，就主管的角度來看可能没有實際產出，但卻有很大的價值。反過來說工程師要讓自己看起來很忙似乎也不是太難就是了。
  • 每個工廠都並存著兩個現象: 依存關係(dependent events) & 統計波動(statistical fluctuations)[P137]
  • 一個事件（例如作業程序）或一系列的事件必須等待其他事件發生之後，才能發生。[P137]
  • 當這些相關事件都和另外一個叫「統計波動」的理象結合起來，事情就變大了。
    • 個別成員的波動和相依性相結合就會讓事情更為複雜，因此專案管理需要系統性的全局思考。
  • 假如工廠裡出現了一個瓶頸, 那裡就可能會有堆積如山的在製品存貨[P229]
  • 在零件到達瓶頸之前,就先作品管[P250]
    • 如果測試人員已經是瓶頸，那工程師若能經由單元測試提升品質可以讓產出效率更高
    • 其實若從需求進來時品質是很好的，那開發人員的產出也是會提高啊
這本書的情節緊湊，快則一天慢則三天就可以閱讀完畢，若有朋友對 TOC、Kanban等理論有興趣，這本是一定要閱讀的經典。