# Sprint #1 確認任務與分工

## 考核重點

**小組是否確認完成分工**
- 在分工之前，需要先有對需求內容的紮實理解。

**藉由三種文件確認小組全員對「交付任務」的共同認知**
- [系統分析文件](#系統分析文件（圖形化對系統的認知，列出架構、流程與功能）)
- Acceptance criteria & DoD
- Task list 任務清單

將規格需求轉換成 acceptance criteria
Task list 任務清單（在 trello / notion / sheet 上皆可）
以下是建議的工作流程。

## 三種文件說明
### 1. 系統分析文件（圖形化對系統的認知，列出架構、流程與功能）
* 根據 AC 提供的 user story 以及 figma 的 mockup 理解需求內容。
* 產生一份初步的系統分析文件。分析應用程式的系統架構，列出要實作的功能，確認模組架構與流程。
* 可利用 flowchart、component/class diagram 將應用程式的系統架構圖形化出來，甚至 state machine 等形式來表達，以及與資料庫相關的 database ERD、schema，前後端溝通的 API 文件等。

關於圖形呈現，可略為參考[這篇文章](https://tw.coderbridge.com/series/7fe012fa52a74786a0035f522a4f1667/posts/e5c930b00e3c4e7883b97cf7aadff636)。建議每個人分頭動手繪製，最後合併成一份小組共同認知。**在專案初期進行即可，後續衝刺不需要隨時回頭維護**。因此，盡可能採用紙筆繪製、拍照交流等簡易方式，不要花費時間在尋找「專業繪圖工具」，重點是小組產生共識的過程。

### 2. Acceptance criteria & DoD
根據 user story，進一步補充與強化每一個 story 的 acceptance criteria。呈現形式類似下表：
<br />

確認完成指標 (definition of done, DoD) 的定義，在 Scrum 中，Definition of Done (DoD) 代表了一個團隊的共同約定，約定了「什麼叫做 DONE」，DoD 的項目應由每個團隊共同定義，但大約會包含三個面向：
* 程式碼的完成
* 驗收/測試的完成
* 文件的完成

最後的呈現形式會類似一個 checklist。而每一個功能被交付的時候，都會用同樣的 checklist 來檢查。小組自定義的 acceptance criteria 也需包括在 DoD 項目裡。

### 3. Task list 任務清單
* 將任務細節化，評估可由單人負責實作的最小項目，產生分工用的 task list。
* 任務拆解得愈小愈好，每個人認領的任務盡量不要與其他任務相依，避免造成相互等待的狀況。
* 每個任務的實作時間最好不要超過 3 天，若實作時間超過 3 天，代表該任務一定可以再拆得更細。
<br />

**任務時程的評估，可以參考 Scrum 開發流程的 story points 評估方式：**
* 確認團隊所有人對於該項任務的相對所花費時程的認知。
並在 scrum planning 需求討論完畢後，確認任務的領取與相對時程，使用電子化的看板如 trello 或 notion 列出任務，以便清楚知道目前某項任務的進度，方便團隊隨時討論。

## 相關連結
* [Twitter 專案開發說明](https://hackmd.io/9b83PiNtRxmyUnjDox9hGA?view)
* [Sprint #2 確認是否在進度上](https://hackmd.io/@twitter-2022/spring_2)
* [Sprint #3 上線準備 & Demo](https://hackmd.io/@twitter-2022/spring_3)

###### tags: `Sprint`