# Sprint #2 確認是否在進度上

## 考核重點
* **確認任務的執行是否 on schedule，以及任務是否需要調整與重新釐清。**
* **確認團隊成員手上執行的任務，是否是符合目前需求的。**
此時不能只看最初的「規格」，還需要搭配團隊定義的 acceptance criteria，確認是否符合描述，以及最終 defintion of done 中的定義標準。

**問題思考：**

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

## 執行方法
### 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

## 相關連結
* [Twitter 專案開發說明](https://hackmd.io/9b83PiNtRxmyUnjDox9hGA?view)
* [Sprint #1 確認任務與分工](https://hackmd.io/@twitter-2022/spring_1)
* [Sprint #3 上線準備 & Demo](https://hackmd.io/@twitter-2022/spring_3)

###### tags: `Sprint`