owned this note   changed 9 months ago  
Linked with GitHub

【DevOps入門班】超越直覺：產品交付階段的數據驅動科學 - Juggernaut (RSG Taipei 2021 總召)

歡迎來到 DevOpsDay Taipei 2024 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/@DevOpsDay/2024
手機版請點選上方 按鈕展開議程列表。

》議程介紹

》填寫議程滿意度問卷｜回饋建言給辛苦的講者

共筆從這開始

什麼是「產品科學」？

運動科學已經很流行了，尤其在美國提升運動員表現，例如 NBA、MLB，以及在美式足球比賽裡，運動員會在嘴裡放感測器，在根據過往記錄去測量當下這個隊員可受撞擊的程度。

還有什麼ＸＸ科學的例子？

ex: 西方醫學 vs 整骨，傳統師傅 vs 科技抓漏…

那產品開發呢？還在依賴直覺嘛，還是可以透過科技的方法來決策。

我的敏捷覺醒之路

  • 「守」
    • 2013 便利貼
    • 2017 開始帶團隊
  • 「破」
    • 2019 引導/工作坊，多團隊經歷
    • 2021 遠端/混合 線上工具
  • 「離」
    • 2023 科學化 data-driven

產品交付三階段

今天 focus 在「產品交付」階段

產品科學的願景與價值

願景：基於科學的原理和方法，協助人們在產品開發上輕鬆做出更好的決策。

價值：
data driven over output driven
data-driven over gut feeling
having insights over owning data

資料是為了協助我們產生 insight，而不是最終結果

產品科學的原則

  • 有條理地探索
  • 理性的規劃
  • 務實的交付
  • 科學的驗證

問：你們的 Scrum/Kanban/DevOps跑得如何？(Slido 答：40 % 普普通通)
截圖 2024-07-12 13.39.53

怎麼定義「好」？

敏捷的迷思

實施敏捷就代表不規劃嗎？

如何預測

  • 團隊 capacity
  • 跨團隊相依性
  • 投資組合（portfolio)
  • 細節模糊 * 在這個階段肯定是模糊的，會慢慢釐清
  • 緊急狀況

團隊的 Capacity 如何？

  • 項目數量

    • 計算最簡單
    • 但你的 1 不等於我的 1（每個項目的難度等級不一樣）

  • 相對程度（Story point/Size) * 比較推薦用這個

    • 也算簡單
    • 透過相對比較
    • 考慮複雜度
    • 1 點 ＝ 幾天？

  • 工時

    • 最難預估（只要搬出實際的時間，大部分都會估比較大的 buffer）
    • 最難預估
    • 相對精準
    • 要花太多時間去估算
    • 沒有成長性（相對Story point來說）

投資組合

切換成各種維度來檢視季規劃的組合

迷思？這不就是瀑布嗎？

  • plans are nothing, planning is everything.
  • 我們依據的是 capacity 不是甘特圖

一個 sprint 能做多少事情

  • definition of 'done'
  • 零碎的事情要記嗎。
  • 避免日復一日，sprint 復 sprint
  • 團隊要穩定
  • 100% 完成率是好事嗎？（感覺是好事，但其實不是，代表我們估的太簡單了，團隊還有突破的可能性）

sprint 期間，可以檢視什麼?

  • burndwon chart
  • sprint 完成率
  • 打擾數量
  • 項目做多久了
  • PR Slots
  • 狀態比例

burndown charts - 還在追求完美的斜率嗎？但每個團隊的狀況都不太一樣

每個 sprint 的完成率都好棒，但…客戶還不能使用

Story Point 會通貨膨脹，但 Cycle time 不會

追求速度，但忽略了品質

所有 bug 都要解嗎？

解了多少 p1 bugs, p2 bugs
還沒解的成為隱憂
一但數量一多，就覺得有些怪怪的

團隊的工程能力如何？

DORA Metrics - 兼顧速度跟品質

  • Deployment Frequency
  • Lead Time for Changes
  • Change Failure Rate
  • Time to Restore Service

部署好之後，怎麼知道沒有問題

SRE Golden Signals

  • Traffic
  • Errors
  • Latency
  • Saturation

retrospective meeting 時用證據來說話

  • 雖然市面上已經有五花八門的各式引導手法
  • 印象派還是數據派？

敏捷方法與數據驅動的項目管理

多維度檢視項目

使用不同的維度來檢視和規劃項目，例如主題、團隊、類型等。

理性規劃

在規劃項目時，考慮平衡和比例，並使用圖解來檢視規劃是否達成目標。

敏捷方法

強調計劃的重要性，但也要靈活應對變化，並根據容量而非時程來安排項目。

Spring規劃

使用Jira來規劃和追蹤Spring的進度，並確保每個項目的完成定義清晰。

避免Spring for Spring

避免將未完成的項目無限期地推到下一個Spring，應重新調整和思考每個Spring的目標。

完成率與估算

完成率過高可能表示估算過於保守，應該挑戰團隊的極限，通常抓80%的完成率。

最後想說的話

科學就是假設, 實驗, 收集數據, 分析, 再繼續調整
別人已經在上太空，我們不要再殺豬公

tags: DevOpsDays Taipei 2024
Select a repo