# Sprint #1 確認任務與分工
在 Sprint #1，考核的重點是「小組是否確認完成分工」，而在分工之前，需要先有對需求內容的紮實理解。

這個階段應該要產生三種文件，形成了小組全員對「交付任務」的共同認知：

* 系統分析文件（圖形化對系統的認知，列出架構、流程與功能）
* 將規格需求轉換成 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。

呈現形式類似下表：


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

* 程式碼的完成
* 驗收/測試的完成
* 文件的完成

最後的呈現形式會類似一個 checklist。而每一個功能被交付的時候，都會用同樣的 checklist 來檢查。

小組自定義的 acceptance criteria 也需包括在 DoD 項目裡。

### 3. Task list 任務清單

接著，將任務細節化，評估可由單人負責實作的最小項目，產生分工用的 task list。

* 此時，任務拆解得愈小愈好，每個人認領的任務盡量不要與其他任務相依，避免造成相互等待的狀況。
* 每個任務的實作時間最好不要超過 3 天，若實作時間超過 3 天，代表該任務一定可以再拆得更細。

**任務時程的評估**，可以參考 Scrum 開發流程的 [story points 評估方式](https://dotblogs.com.tw/hatelove/2015/11/23/scrum-estimation-story-points-and-planning-poker)：

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

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

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