---
tags: work-flow
---
# 「目標達成」方法論：Scrum
>根據我的獨斷偏見，摘要出來的內容
[TOC]
## 什麼是 Scrum？
- Scrum 是一種管理框架，團隊可將其用於自我組織並實現共同目標
- 特色是以固定的短衝週期去開發產品，並在每個短衝新增有價值的交付
- Scrum 產品開發，如同英式橄欖球一樣，那顆球會在團隊內持續傳下去並在球場上移動
- Scrum 重視持續改善流程。在衝刺活動一開始時，成員可能不知道任何事，可以根據sprint 期間取得的資訊，視需要調整流程
- 不是追求快，而是追求「快速適應改變、自我改善的體制」-> 有質量的產出、高效率的工作方法
- 343口訣
- 三種角色(PO,SM,DT)
- 四個會議(Planning,Daily,Review,Retro)
- 三種產出(產品待辦清單,衝刺代辦清單,燃盡圖)
## Scrum 角色
- PO - 產品負責人 - Product 擁護者
- SM - Scrum教練 - Scrum 擁護者
- DT - 開發團隊 - Backlog 擁護者?
---
### PO
- 了解使用者以及 Stakeholder 需求
- 依照市場需求，決定產品需求、願景(Vision)
- 依照市場需求，規劃一個推出後會讓市場發出 wow 的產品
- 負責規劃團隊的 roadmap
- 該應：只提出目標、衡量指標與大里程碑
- 不應：過分干涉團隊執行細節，讓團隊發揮專業
- 對外：應扛得住壓力，守住團隊共識與方向
- 對內：協調資源，監控方向，讓團隊往目標衝刺
### SM
- 初次導入 scrum：建立團隊對 scrum 的基本認知
在團隊尚未建立對 scrum 的認知時，就貿然開始執行 scrum 活動
容易導致團隊花費過多心力，處理彼此對 scrum 認知差異
從而走向 scrum 流程執行失敗，而又重複「想要轉型」的循環
- 熟悉整個 scrum 框架
- 宣傳、教育 Scrum 方法給團隊
- 主持 Scrum 相關會議
- 釐清混亂的來源，並一步步明確化，像傳教士般感染團隊
- 持續改善流程及幫助團隊解決困難(或找到對的人幫忙解決)
- 可由團隊成員輪流擔任
- 避免有人離職，Scrum 就崩潰(公車指數)
- 加深團隊成員對 Scrum 的認識
### DT
- 參與 Scrum 的成員，包含 PO, SM, PM, UI, UX, RD, QA
- 最多 5–9 人，超過就分組
### Stakeholder
- 通常是業務方、客戶、股東或是老闆本人
- 有權利「否決產品」且非 DT 的人
## Scrum 典型活動：1個週期，5種會議
1. 衝刺精煉會議（Sprint Refinement）
2. 衝刺計畫會議（Sprint Planning）
3. Sprint
4. 每日站立會議（Sprint Daily Standup）
5. 衝刺檢視會議（Sprint Review）
6. 衝刺回顧會議（Sprint Retrospective）
---
- 1週(40hr)的 Sprint，所應對的『時間盒』設計
| Topic | 時長 | 活動比率 | 時間點 |
| ---------- | ---------- | -------- |---------- |
| 衝刺精煉會議 | < 2hr/week | 2.5% | 第二週週五 |
| 衝刺計畫會議 | < 1hr/week | 5% | 第一週週一 |
| 每日站立會議 | < 15m/day | ~3% | 每天早上 |
| 衝刺檢視會議 | < 1hr/week | 2.5% | 第二週週五 |
| 衝刺回顧會議 | < 1hr/week | 2.5% | 第二週週五 |
| Sprint |33.75hr/week| ~ 84% | |
- 開發人員的細部交付期程
第二週週三 - PR, DeployTest, 交付 QA
第二週週三四五 - Debug
第二週週五會後 - DeployProd, 交付 PO
[參考資料](https://medium.com/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81/%E6%96%87%E6%80%9D%E4%B8%8D%E8%97%8F%E7%A7%81-timebox-%E7%9A%84%E5%A4%A7%E5%AD%B8%E5%95%8F-19f12b860f77)
### 衝刺精煉會議（Sprint Refinement）
- 會議目地：
- 產出 **Product 待辦清單**
- 精煉 **Product 待辦清單** (模糊變明確，未知變已知，複雜變單一)
- 會議時長：2hr
- 會議主持：SM
- 會前準備
- 會議流程：
- 若無PB，產出 [**Product 待辦清單**](#產品待辦清單)
- 若有PB，精煉PBI
- DT 將「PBI」派發給 Person in charge
- DT 對「PBI」添加詳細資訊
- DT 對「PBI」定義交付條件
- DT 對「PBI」估算大小
- PO 對「PBI」排序
- 配合工具：Jira
- SM 確保團隊充分理解「PBI」內容
#### DT 對「PBI」添加詳細資訊
- 或可收斂到事實來源中心：Spec、設計稿、API文件，再將連結貼到 PBI
- featue測試方式、bug再現方式
- 文字說明、測站連結、畫面截圖
#### DT 對「PBI」定義交付條件
- 讓團隊就何謂「完成」取得共識
- 「完成」並不表示「無法再更好了」，而是團隊暫停再投入心力
- 「完成」定義的舉例
- 產品已就緒，可供發佈
- 產品已經過測試並就緒，可在 Beta 環境中發佈
- 產品已接受驗收測試，可向所有使用者發佈
- 保存結論：將它存放在一個**事實來源中心**，並經常參照此定義
- 衝刺審查：在衝刺審查期間，來出來檢視工作成果
#### DT 對「PBI」估算大小
- 注意包含研究時間、規劃時間、測試時間等，非實作因素
- DT 無法估點時，評估如何排除不確定因素
- 估點，使用相對數字(評估工時很難精確，但可以輕易衡量相對大小)
[敏捷開發 - SCRUM 執行 ARTIFACT，如何將需求明確化](https://hoohoo.top/blog/agile-development-artifactscrum-file-management/)
### 衝刺計畫會議（Sprint Planning）
- 會議目地：
- 產出 **Sprint 待辦清單**
- 開啟下個 Sprint
- 會議時長：1hr
- 會議主持：SM
- 會議內容：
- 配合工具：Jira
- DT 決定哪些「PBI」納入該次 Sprint
-> 產出 **Sprint 待辦清單**
---
#### PO 決定哪些「PBI」納入該次 Sprint
- By 緊急重要程度
- By 估點結果
一個Sprint 大約總點數 ~= 48點 / Sprint
= 一天6點 x 一週4天(扣除會議?) x 2週(Sprint週期)
### Sprint
- 定義：Scrum 團隊完成一定數量工作所需的短暂、固定的周期
- 目的：完成符合交付條件的增量(increment)
- 行為：
- 燃盡 **Sprint 待辦清單**
- 根據工作狀況，更新專案管理工具
- 有什麼問題「即時且面對面的討論」
### 每日站立會議（Sprint Daily Standup）
- 會議目地：
- 同步所有人的工作情況、使整個團隊資訊透明同步
- 即時發現任務 Fail 的原因，可制定改善方針、提供協助
- 會議時長：總時長 < 15 分鐘，每人時長 < 3 分鐘
- 會議主持：SM
- 由 SM 把空每人發言時間
- 由 SM 確保需要花超過3分鐘討論的事，會後個別討論
- 會議流程：
- 會前 Sprint Log
- 大家依序同步工作內容給所有成員
- 內容快速帶過：昨天做什麼/今天做什麼/目前面臨的問題是什麼？
- 配合工具：專案管理工具、SprintLog
### 衝刺檢視會議（Sprint Review）
- 會議目地：審查、驗收「產品」
- 會議時長：1hr
- 會議主持：SM
- 會議內容：
- DT 依照定義好的驗收條件，展示 Sprint 結果
- PO 依照定義好的驗收條件，檢視 Sprint 結果(達成率)
### 衝刺回顧會議（Sprint Retrospective）
- 會議目地：回顧、檢討、改善「工作方法」
- 會議時長：1hr
- 會議主持：SM
- 會議內容：
- 當規劃的 Sprint 待辦清單做不完(fail)
PO + RD leader 來檢視
- why fail？
- why 在立會沒有提出遇到的問題？
- DT 提出可以優化的工作方式
- 調整SOP
- 建立知識庫
- 進化、優化的機會
- 亞洲人的性格就是不敢面對面得罪人
- SM 示範發言、鼓勵發言
- SM 鼓勵所有人，至少提一個需要改進的地方
<!-- - 由 SM 在會議結束時跟大家說：「大家真的好棒！我相信之後會越來越好的」 -->
---
- 常見問題是：估點時，低估一個 PBI 的規模
在 Review 會議上，報告完成了哪些事項
未能完成事項在下一個 Planning 會議考慮進去即可
通常團隊對專案會越來越熟悉 > 工作拆解能力提高 > 評估精準度越來越高
- 如何究責？
Scrum 重視團隊一起承擔責任，雖然工作展開每項PBI都有一位 Person In Charge，但是某人遭遇困難時，是大家一起想辦法化解，不能只是旁觀，因為萬一專案失敗了，不可能有某位成員還能獨享尊榮
- 擺爛的團員
每天的 Daily 很容易凸顯出來，不用兩週，就會開始主動談離開這個專案了
## Scrum 產出
執行 Scrum，應產生如下成果
- 產品待辦清單(Product Backlog)
- 衝刺待辦清單(Sprint Backlog)
- 燃盡圖(Burndown Chart)
- 事實來源中心(各種共識的文件、會議記錄、產品規格文件)
- 產品交付增量
---
### DOC：產品待辦清單
- 隨時隨地都能新增PBI，不拘於會議上
- 完成產品，需要執行的 task
- 包含跨職能的 task (PM, UI, UX, RD, QA.)
- 包含技術團隊提出的需求(研究、系統優化、重構...)
- 建議的建立流程
1. PO 闡述產品需求、願景(Vision)
2. PM 依照願景，形成一個個明確的 UserStory(目標)
3. PM 依照 UserStory，形成一個個明確的 BPI
```javascript
// PBI 應具備以下屬性
const PBI = {
title:
desc?:
priority:
storyTopic:
howToTest?:
howToDemo?:
howToAcceptance:
estimate?:
}
// 也可依循目標管理方案 SMARTER，建立 PBI
S-明確性 --> desc
M-可衡量 --> howToTest
A-可行性 --> estimate
R-相關性 --> userStory, priority
T-時效性 --> sprint, estimate
E-激勵性 --> version
R-挑戰性 -->
```
### DOC：衝刺待辦清單
- 劃入 Sprint 的 task
### DOC：事實來源中心
- 產品相關：規劃書、設計稿、API文件
- 工作流相關：工作協議、流程改善、「完成」的定義
- 公司制度
- ...
### DOC：燃盡圖
- 圖表化呈現，一個時間區段，剩餘的工作量
### RESULT:產品交付增量
## Scrum 原則
有六個 Scrum 原則可協助您應用 Scrum 架構，並獲益於 Scrum。分別說明如下：
- **掌控實證流程**：Scrum 團隊的信念是透明度、檢驗及適性調整。
- **自我組織**：儘管您的 Scrum 團隊會有角色和規則，但每位 Scrum 成員都應被賦予權能，以便對其任務及工作勇於承擔。Scrum 的信念是，共同擔責可帶來更富有創意和更積極主動的團隊。
- **協作**：若您的團隊在 Scrum 衝刺期間及之後能共同合作，將能締造最佳成果。
- **價值導向的優先順序**：Scrum 衝刺的目標是締造最高的商業價值。為此，您必須打從 Scrum 流程的一開始，就安排工作的優先順序。
- **規劃時間箱**：Scrum 流程會有基於時間的各種活動，例如衝刺活動本身、每日站立會議以及回顧會議。由於 Scrum 運作的信念是持續改善，因此將工作劃分為時間盒至關重要，如此才能邁向下一個任務，並改善未來的工作。
- **疊代式開發**：採用 Scrum 法時，您的第一個專案不會是完美的，但藉由疊代式建構，您的團隊將有最大的能力因應客戶的需求，並根據價值導向的優先順序，來修改產品和產出。
---
## 工具使用：Jira
- 大型工作 - 大目標
- 故事 - 小目標
故事很適合用 SMART 分析，可以總結出更適恰的任務
- 任務 - 具體行動
Sign in with Wallet
Connect another wallet