---
# System prepended metadata

title: 'Sprint #2 確認是否在進度上'
tags: [規格]

---

# Sprint #2 確認是否在進度上
Sprint #2 是專案的中段，我們要確認任務的執行是否 on schedule，以及任務是否需要調整與重新釐清 (在 scrum 中叫做 refinement 或者 grooming)。

首先，**確認團隊成員手上執行的任務，是否是符合目前需求的**。

此時不能只看最初的「規格」，還需要搭配團隊定義的 acceptance criteria，確認是否符合描述，以及最終 defintion of done 中的定義標準。

建議進一步思考：

* 我們是否清楚任務的目標？各項 task 完成的時間是否足夠？我們是否需要重新安排 tasks 執行的 priority？
* 需要對需求做調整嗎？可否刪減一些不必要的完成項目，就能完成最小化可交付的產品 (MVP)？
* 若時間不夠，能不能先用 workaround 來解決？或者有無其他可支援的resources？

注意，workaround 不是指假資料，而是指用比較偏門、非正統的方式來修正問題。

### 1. 提前驗收

要能紮實地回答以上問題，小組需要針對既有功能進行「提前驗收」，以便評估下半場有哪些問題要解決。

具體作為包括：

* 根據 acceptance criteria 手動驗收
* 執行自動化測試
* 讓前後端先接起來，以便判斷後端傳出來的數據是否需要更新

### 2. Refinement

透過提前驗收掌握狀況後，進行 Refinement 評估。嘗試回答：

* 評估剩餘 task 的先後順序，最重要完成任務的 key factor 是什麼？
* 是否有一些規格要縮減
* 是否在某些卡住的東西上用 workraound 先解決？

### 3. 團隊分工調整 & 更新 Task list
在充分了解開發現況後，接著**確認是否團隊成員有人進度超前**，可以跨功能的支援其他可以先完成的事情。比如：

* 協助 QA 角色，幫助小組提前知道哪有哪些隱藏的 issue 要處理
  * 針對已完成的 tasks，先協助其跑自動與手動測試，包含確認其驗收條件 (acceptance criteria) 是否符合，列出可能的已知 issues。
  * 除了技術上的 acceptancy criteria 與 Definition of Done(DoD)，app 是否符合使用上的需求？是否有 follow user story？實作出來的 app 和 UI 畫面有沒有差異？有差異的地方的解釋是什麼？

* 協助 PM 與設計角色：確認 task 完成是否符合 user story 以及 app 的畫面是否 match 當初的 mockup 設計。
* 協助前後端 coordinator 角色：如果是前後端分離的專案，可協助確認前後端是否已經清楚的完成串接程序；若是原本前端角色可否協助後端先產出假資料(mock server)；若是後端角色可否協助前端設計出更符合頁面結構的API資料，供其方便串接。
* 
最後別忘了要更新團隊的 Task list，以符合最新情況。在此階段通常會需要更新：

* 某些項目的 acceptancy criteria
* 調整 product backlog 的先後順序
  * 較優先的項目，先拿出來分析
  * 不重要的丟進 backlog


\
[回到首頁](https://hackmd.io/@2022-Oct-Twitter/Hk9m-Pn-j/%2Feax7gnB7R3KcclDqf27iDA%3Fview)

###### tags: `規格`